Bring Your Own Cloud on Azure

This page covers running Akka Automated Operations (AAO) on Azure. For the architecture and concepts, start with the technical overview.

Download BYOC on Azure as a PDF, or the full overview.

The default architecture. Akka provisions a region into your virtual network with private and database subnets, using Microsoft Entra ID for the deployment identity.

AAO on Azure: default architecture
Figure 1. AAO on Azure: default architecture

Azure resources

AAO on Azure uses these Azure services:

  • Microsoft Entra ID (applications, app registrations, service principals)

  • Microsoft Azure Resource Manager (subscription, resource group, roles and role assignments)

  • Networking: virtual network, subnet, public IP address, NAT gateway, load balancer, private and public DNS zones

  • Compute: AKS cluster, node pools (virtual machine scale sets), network security groups

  • Data: Azure Database for PostgreSQL flexible server

  • Storage: storage accounts and blob containers

  • Identity: managed identities and federated credentials

Identity model

An enterprise application is registered in Microsoft Entra ID to create its identity, and a service principal is created for it. A non-human privileged role with the minimum permissions is configured and used by the Federation Plane to securely bootstrap and manage the environment.

AAO uses four roles: Deployment (created by akka-bootstrap), and Editor, Viewer, and SRE (created by you). The exact permissions are created and managed by akka-bootstrap and are the source of truth; review the generated permission reference rather than a copy here. The Editor role cannot delete resources and cannot read or write federated identity credentials.

Resource providers to register

These register automatically through akka-bootstrap. Verify they are enabled on the subscription:

  • Microsoft.Authorization

  • Microsoft.ContainerService

  • Microsoft.DBforPostgreSQL

  • Microsoft.ManagedIdentity

  • Microsoft.Resources

  • Microsoft.Network

  • Microsoft.Storage

The subscription must also have EncryptionAtHost enabled:

az feature register --name EncryptionAtHost --namespace Microsoft.Compute
az provider register -n Microsoft.Compute

Installation

Prepare your subscription with the akka-bootstrap utility, then Akka provisions the region. Create a values.hcl with your backend configuration and Azure region details:

inputs = {
  backend = {
    type = "azurerm"
    config = {
      bucket = "your-terraform-state-bucket"
      prefix = "akka-bootstrap"
    }
  }
  akka_regions = {
    azure = [
      {
        environment      = "prod"       # dev | stage | prod
        akka_region_name = "az-<tenant>-<region>"
        tenant_id        = "azure-tenant-id"
        subscription_id  = "azure-subscription-id"
      }
    ]
    aws = []
    gcp = []
  }
}

Then run terragrunt init, terragrunt plan, and terragrunt apply. After a successful apply, share the generated service-principal credentials with Akka so the Federation Plane can authenticate and manage resources in your subscription.

Private connectivity

By default, traffic between the region and your internal networks traverses the internet. To keep it private, AAO on Azure uses Virtual Network Peering with a user-defined NAT gateway. The per-flow detail is on the data flows page.

AAO on Azure: private connectivity with Virtual Network Peering and a user-defined NAT gateway
Figure 2. AAO on Azure: private connectivity with Virtual Network Peering and a user-defined NAT gateway

Bringing your own AKS cluster (BYOK8s)

If you provision the cluster yourself, see Akka Automated Operations on Azure with your own Kubernetes for the complete, self-contained guide.

See also