Akka Automated Operations on AWS with your own Kubernetes

Run Akka Automated Operations (AAO) on an EKS cluster you provision and operate. This page is the complete BYOK8s-on-AWS path: the shared requirements first, then the AWS specifics.

Download BYOK8s on AWS as a PDF, or the full overview.

Once the region is running, do not change any provisioned infrastructure without first informing Akka. It could break the Akka region.

Installation flow

  1. Understand: review the technical overview and contact your Akka Success Team for a BYOK8s package.

  2. Capacity planning: size the environment with your Akka Success Team.

  3. Infrastructure requirements: agree on DNS subdomain zones, certificate provider, and related decisions.

  4. Infrastructure provisioning: provision the network, cluster, and database, and set up the egress domain allowlist.

  5. Customer smoke tests: run the checklist below before handing the cluster to Akka.

  6. Teleport: install the Akka-provided Teleport Helm chart. Deploy it promptly: the join token has a 3-hour TTL.

  7. Installation: Akka configures the cluster as an application-plane region and sets up platform observability. You seed database credentials into the namespaces Akka provides.

  8. Akka smoke tests: Akka attaches the region to the Federation Plane and runs smoke tests.

  9. Region handover: Akka assigns the region to your organization. A production-labeled region is not fully handed over until you complete the region-readiness steps.

Infrastructure requirements

Requirement Specification

Kubernetes

Version 1.34 at minimum. Cilium or Calico is mandatory for network-policy enforcement. Configure it as an overlay network only when the cloud-native CNI is unfeasible due to IPAM constraints.

Cluster CIDRs

/17 for the pod network and /17 for the service network.

Network

Minimum /21 CIDR block from your IPAM allocation, subdivided into three database subnets (/27 each) and three private subnets (/24 each).

Nodes

16 vCPU / 64 GB RAM instances (for example AWS m5.4xlarge, GCP n2d-standard-16, Azure Standard_D16s_v6). Minimum one node. Kubernetes autoscales the node count with demand.

Service Mesh

Akka deploys Linkerd, currently the only supported service mesh.

Load Balancer

Public Layer 4 by default. An internal load balancer is supported, and a subnet or IP can be specified on supported clouds.

DNS and Certificates

Two subdomain DNS zones, one for platform APIs and one for deployed services (for example akka.acme.com, apps.akka.acme.com), plus cert-manager ClusterIssuer objects for automatic certificate generation on both.

PostgreSQL

Version 17 or later, provisioned and configured by you, highly available across zones (RDS on AWS, CloudSQL on GCP, Azure Database for PostgreSQL flexible server).

CSI Driver

The cloud-specific secrets-store CSI (Container Storage Interface) driver provider.

Registry

Platform images can be pulled through your Artifactory, using Akka’s container registry as a mirror.

Database credentials

Seed the connection credentials (username, password, host, database name) as Kubernetes Secrets into both the kalix-system and kalix-management-system namespaces. You create these namespaces if needed, but do not manage them: AAO imports them into its management scope and reconciles them. Akka recommends the external-secrets operator to mirror credentials from your cloud secret store.

Access

Within a customer-provisioned cluster, Akka uses least-privilege permissions scoped to the Akka-managed namespaces and limits its access to customer-owned Kubernetes resources.

Capacity planning

Database size is driven by total application data operations per second at peak load. Work with your Akka Success Team to determine sizing.

DB Size Data ops/sec CPU Memory (GB) Storage (GB) Max Connections

XSmall

1,000

1

4

100

200

Small

3,000

2

16

200

500

Medium

6,000

4

32

400

1,000

Large

12,000

8

64

800

1,500

XLarge

24,000

16

128

1,600

2,000

Egress allowlist and Teleport

Akka reaches the cluster through Teleport, which uses ports 3023, 3024, and 3026 in addition to 443. Teleport is a certificate authority and identity-aware proxy; the non-standard ports segment traffic types, and the security boundary is mutual TLS rather than the port. The full egress hostname and IP allowlist (Teleport, console, Federation Plane, Control Tower, observability, and container registry endpoints) is on the data flows page.

Customer smoke-testing checklist

  • Check connectivity between the database instance and the Kubernetes cluster.

  • Ensure the ClusterIssuer is ready and in a good state, and verify all tokens it uses.

  • In multi-region configurations, ensure traffic flows in both directions between regions.

AWS specifics

Apply these AWS additions to the requirements above.

Route 53 records: create these in your hosted zone (public or private):

Record Type Target

akka.[zone]

A

Network Load Balancer (platform APIs)

*.akka.[zone]

CNAME

akka.[zone]

services.akka.[zone]

A

Network Load Balancer (user services and app support APIs)

*.services.akka.[zone]

CNAME

services.akka.[zone]

  • Certificates: cert-manager ClusterIssuer with the Route 53 dns01 solver, authorized through IRSA (IAM Roles for Service Accounts) to write validation TXT records.

  • EKS cluster: node groups (one On-Demand, optionally one Spot) at 16 vCPU / 64 GB (for example m5.4xlarge); AMI AL2023_x86_64_STANDARD; managed addons coredns, aws-ebs-csi-driver, vpc-cni, kube-proxy, and the AWS secrets-store CSI driver provider; Calico in policy-only mode.

  • RDS for PostgreSQL: PostgreSQL 17, Multi-AZ, automatic minor upgrades and deletion protection; parameter group rds.force_ssl = 1. Because SSL is required, install the RDS CA bundle (https://truststore.pki.rds.amazonaws.com/<region>/<region>-bundle.pem) into the kalix-system and kalix-management-system namespaces.

  • Database credentials: use the external-secrets operator to mirror them from AWS Secrets Manager.

See also