Everpure Cloud Azure Native: A closer look at the Platform Console

In this post, I thought to take a closer look at the Platform Console for Everpure Cloud Azure Native. It provides access to a Storage Pool through the familiar Purity GUI, REST API, and CLI, giving storage administrators an additional way to handle advanced configurations.

The important distinction here is that the Platform Console complements the Azure-native experience. It does not replace it. Azure remains the primary interface for day-to-day management, while the Platform Console is intended for specific tasks that Azure does not expose.

What does it add?

Let's start with the practical use cases.

Storage configuration outside Azure Resource Manager

The Platform Console allows you to create and manage Purity resources such as standalone volumes, hosts, host groups, protection groups, and snapshot policies outside Azure Resource Manager (ARM).

This gives administrators more flexibility when a supported storage workflow requires objects or settings that are not available through the Azure-native interface. For teams already familiar with Purity, it also means working with interfaces they already know.

Snapshot management

For resources managed through the Platform Console, you can create manual snapshots, configure snapshot schedules, and restore snapshots.

The benefit here is control over when recovery points are created and how snapshot protection is configured for those resources. However, it is important to keep resource ownership clear when using both Azure and the Platform Console. More on that below.

Automation and monitoring

Supported storage workflows can be automated through the REST API, SDKs, or CLI. Local users can generate API tokens for REST access and upload SSH public keys for command-line access.

Array metrics can also be collected through the OpenMetrics endpoint using a local-user API token. This provides a way to collect storage metrics for monitoring workflows, alongside the ability to script supported administrative tasks rather than perform each operation manually.

Getting access

One Platform Console is available per Storage Pool. It is disabled by default and must be explicitly enabled from Azure.

In the Azure portal, open the Storage Pool and navigate to Settings → Platform console. Web console and REST API access are enabled together, while SSH can be enabled independently. Once the configuration is applied, the portal provides the management IP address and the pre-created cloudadmin user name.

Initial access uses a one-time password generated from Azure. The cloudadmin account is temporary: it’s reserved for this first sign-in and removed when the password expires. Generating a new password recreates it. After signing in, create your own local users for ongoing administration.

The management interfaces use the same delegated subnet as the storage data path. Because of that, use Network Security Groups to restrict management access to the administrative hosts that need it. Application VMs do not need Platform Console access to consume storage.

Two interfaces, but not interchangeable resource management

This is probably the most important operational consideration.

Resources created through Azure are tracked in Azure. Resources created through the Platform Console exist on the array, but are not visible to the Azure-native interface.

There is also no hard isolation between the two. Changing or deleting an Azure-created resource through the Platform Console can leave Azure with stale information, causing subsequent operations to fail or report an incorrect state.

A practical rule is therefore:

• Manage the lifecycle of Azure-created volumes and volume groups through Azure.
• Use the Platform Console for resources created there, or for specifically documented advanced configuration.
• Keep a record of resources created outside Azure so they are not overlooked during decommissioning.

The summary

The Platform Console adds flexibility where the Azure-native interface does not expose a supported storage operation. Familiar Purity tools, snapshot management, automation, and access to array metrics give administrators more options for advanced workflows.

The key is to use those options deliberately: keep routine management in Azure, limit console access to the people and systems that need it, and maintain clear ownership of resources across the two interfaces.

For the supported workflows, access requirements, and configuration instructions, refer to the Platform Console for Everpure Cloud Azure Native KB.