Shared responsibility model

This page describes how responsibilities are divided between Akka and the customer when running Akka Automated Operations (AAO) inside a Kubernetes cluster the customer provides and operates, under the BYOK8s (Bring Your Own Kubernetes) deployment model.

The policies published on trust.akka.io and the Customer Support Policy take precedence over any summary here.

Executive summary

Akka Automated Operations is a managed platform. Under the BYOK8s model, Akka runs inside a Kubernetes cluster the customer provides and operates. Akka takes responsibility for the platform itself: the runtime, operators, inter-component mTLS, region installation, scaling, patching, observability of the platform, and the operational rituals that surround them. Encryption of customer data (database at rest and in transit, ingress TLS) is the customer’s responsibility (see the Encryption section). The customer takes responsibility for the cloud account, the Kubernetes cluster and its underlying infrastructure, database backups, the network, the human identities that access the Akka console, the applications built with the Akka SDK, and the data those applications process.

Because Akka runs inside infrastructure the customer operates, the model is genuinely shared. Akka manages the platform layer end-to-end; the customer manages the layers above and below it; a number of activities are jointly owned with the lead and consulted parties named explicitly.

What you own in BYOK8s

In BYOK8s you own the infrastructure beneath the platform, not just the application. Beyond the application, you own:

The Kubernetes cluster: creation, node pools, capacity and scaling, patching, and version upgrades.
The database: provisioning, capacity, version upgrades, backups, and restores.
The network and ingress: connectivity, ingress TLS (provide a certificate issuer or grant Akka DNS access), and IP allowlists.
The Teleport proxy the Federation Plane uses to reach the cluster: install, upgrade, and operational health.
Encryption of your data at rest and in transit (database and ingress).
Cluster and node audit logs (the Kubernetes and infrastructure layer you operate).
For Business Continuity (multi-region): standing up and operating a cluster, database, and cross-region networking in each region.

Akka owns the platform layer: the runtime, operators, inter-component mTLS, region installation, scaling logic, platform observability, and releases.

Shared responsibility extends to going live. Akka has a set of standards it expects of customer applications before flipping prod traffic on: sizing, observability, CI/CD, functional and non-functional testing, DR (disaster recovery) and rollback rehearsal. The production readiness checklist captures those standards and the sign-off gate Akka recommends before launch.

Catch-all

Anything not explicitly listed in this document is the customer’s responsibility. This includes customer application code, customer-side operational tooling, and any concern not explicitly assigned to Akka. The customer may request additional operational support from Akka through the standard support channel.

Layered view of Akka on BYOK8s

The customer owns the applications and the underlying cloud account, Kubernetes cluster, and database; Akka runs inside that cluster and manages the platform components.

Layer	Owner	Responsibilities
Customer Applications (Akka SDK services)	Customer	Source, build, deploy; service config and secrets; app ACLs / IAM (JWTs); app observability / SDK logs
Akka Platform (managed by Akka, deployed into the customer’s cluster)	Akka	Akka runtime and operators; inter-component mTLS; scaling, patching, releases; Federation Plane integration; platform observability
Cloud Account, Kubernetes cluster, and database	Customer	Billing, quotas, dedicated cloud account; Kubernetes cluster (creation, upgrades, capacity); database (creation, upgrades, backups); IAM that grants Akka access into the cluster; CIDR allocation, peering, DNS, IP allowlists; customer-managed KMS keys, cloud audit logs

Layer

Owner

Responsibilities

Customer Applications (Akka SDK services)

Customer

Source, build, deploy; service config and secrets; app ACLs / IAM (JWTs); app observability / SDK logs

Akka Platform (managed by Akka, deployed into the customer’s cluster)

Akka

Akka runtime and operators; inter-component mTLS; scaling, patching, releases; Federation Plane integration; platform observability

Cloud Account, Kubernetes cluster, and database

Customer

Billing, quotas, dedicated cloud account; Kubernetes cluster (creation, upgrades, capacity); database (creation, upgrades, backups); IAM that grants Akka access into the cluster; CIDR allocation, peering, DNS, IP allowlists; customer-managed KMS keys, cloud audit logs

How to read this

Each activity in the matrix has an owner, the party that is Responsible and Accountable. The other party may be Consulted or Informed; called out in the description where relevant.

Owner	Meaning
Customer	The customer is Responsible and Accountable for the activity. Akka may be Consulted or Informed.
Akka	Akka is Responsible and Accountable for the activity. The customer may be Consulted or Informed.
Shared	Akka and the customer share responsibility. The split is described in the row’s description.

Owner

Meaning

Customer

The customer is Responsible and Accountable for the activity. Akka may be Consulted or Informed.

Akka

Akka is Responsible and Accountable for the activity. The customer may be Consulted or Informed.

Shared

Akka and the customer share responsibility. The split is described in the row’s description.

Because Akka operates inside infrastructure you control, coordinate with Akka before infrastructure changes that could affect the Region.

Reaching the reliability and availability your deployment is built for depends on both sides meeting the responsibilities below, worked through with your Akka team; your agreement and the Federation Plane SLA Policy remain the authoritative statement of what is committed. See the production readiness overview and the BYOK8s production readiness checklist.

Responsibility summary at a glance

Area	Lead	One-line summary
Cloud account, cluster and billing	Customer	Customer owns the cloud account and Kubernetes cluster, pays the bill, and controls the access Akka uses to operate inside the cluster.
Networking and DNS	Customer	Customer owns the cluster’s networking end-to-end: CIDR, peering, allowlists, DNS, and private connectivity.
Region install and federation	Akka	Akka provisions, federates, and validates the Akka region.
Platform patching and releases	Akka	Akka maintains the runtime and platform components.
Kubernetes and database upgrades	Customer	Customer schedules and runs upgrades after consulting Akka on certified target versions.
Compute and storage scaling	Shared	Customer ensures cluster and database can scale; Akka manages elasticity of the application workloads on top.
Encryption (customer data)	Customer	Customer is responsible for database encryption (at rest and in transit) and ingress TLS.
Encryption (platform-internal)	Akka	Akka manages mTLS between Akka components, TLS to the Federation Plane, and encryption of FP-synced secrets.
Platform observability	Akka	Akka monitors the platform and publishes uptime reports on request.
Application observability	Customer	Customer exports app telemetry to their own observability stack.
Database backups	Customer	Customer runs database point-in-time recovery (PITR); Akka is informed.
K8s resource backups and restore testing	Shared	Akka uses Velero to back up K8s resources; customer provides the IAM binding and object storage. Restore testing is performed jointly.
Disaster recovery exercises	Shared	Annual or as-agreed joint exercises.
Multi-region failover	Shared	Akka and the customer work together on failover; Akka provides the tooling and runbooks.
Akka console and CLI identity	Customer	Customer’s identity provider (IdP) authenticates console/CLI users with MFA.
Akka platform-side privileged access	Akka	Teleport-mediated, session-recorded; logs available to customer on request.
Compliance posture (SOC 2, pen test)	Akka	Akka maintains and publishes compliance evidence on trust.akka.io.
GDPR / PII for application data	Customer	Customer is the controller of application data and handles DSRs (Data Subject Requests).
Customer applications (SDK services)	Customer	Customer owns source, deploy, config, secrets, ACLs end-to-end.

Area

Lead

One-line summary

Cloud account, cluster and billing

Customer

Customer owns the cloud account and Kubernetes cluster, pays the bill, and controls the access Akka uses to operate inside the cluster.

Networking and DNS

Customer

Customer owns the cluster’s networking end-to-end: CIDR, peering, allowlists, DNS, and private connectivity.

Region install and federation

Akka

Akka provisions, federates, and validates the Akka region.

Platform patching and releases

Akka

Akka maintains the runtime and platform components.

Kubernetes and database upgrades

Customer

Customer schedules and runs upgrades after consulting Akka on certified target versions.

Compute and storage scaling

Shared

Customer ensures cluster and database can scale; Akka manages elasticity of the application workloads on top.

Encryption (customer data)

Customer

Customer is responsible for database encryption (at rest and in transit) and ingress TLS.

Encryption (platform-internal)

Akka

Akka manages mTLS between Akka components, TLS to the Federation Plane, and encryption of FP-synced secrets.

Platform observability

Akka

Akka monitors the platform and publishes uptime reports on request.

Application observability

Customer

Customer exports app telemetry to their own observability stack.

Database backups

Customer

Customer runs database point-in-time recovery (PITR); Akka is informed.

K8s resource backups and restore testing

Shared

Akka uses Velero to back up K8s resources; customer provides the IAM binding and object storage. Restore testing is performed jointly.

Disaster recovery exercises

Shared

Annual or as-agreed joint exercises.

Multi-region failover

Shared

Akka and the customer work together on failover; Akka provides the tooling and runbooks.

Akka console and CLI identity

Customer

Customer’s identity provider (IdP) authenticates console/CLI users with MFA.

Akka platform-side privileged access

Akka

Teleport-mediated, session-recorded; logs available to customer on request.

Compliance posture (SOC 2, pen test)

Akka

Akka maintains and publishes compliance evidence on trust.akka.io.

GDPR / PII for application data

Customer

Customer is the controller of application data and handles DSRs (Data Subject Requests).

Customer applications (SDK services)

Customer

Customer owns source, deploy, config, secrets, ACLs end-to-end.

1. Cloud account

The customer owns the cloud-provider account that hosts the Akka region. Akka receives narrowly scoped programmatic access to install, operate, and maintain the platform inside that account. The customer can revoke that access at any time.

At a glance

Customer: Owns the cloud account, pays the bill, and creates the IAM permissions that Akka uses. Can cut off Akka’s access at any time.
Akka: Documents the access Akka requires into the customer’s cluster. Operates within the access the customer grants, and nothing outside it.

Responsibilities

Activity	Owner	Description
Cloud account provisioning	Customer	Customer sets up a dedicated AWS account, GCP project, or Azure subscription that hosts the Kubernetes cluster Akka runs in. A dedicated account is recommended to simplify cost tracking and security boundaries; Akka advises against provisioning other resources in it to avoid management conflicts, and anything the customer adds outside this scope is the customer’s responsibility.
Quotas and service limits	Customer	Customer ensures sufficient quota for compute, storage, and networking. Akka advises on expected consumption.
Billing	Customer	Customer owns and operates the account and pays the bill.

Activity

Owner

Description

Cloud account provisioning

Customer

Customer sets up a dedicated AWS account, GCP project, or Azure subscription that hosts the Kubernetes cluster Akka runs in. A dedicated account is recommended to simplify cost tracking and security boundaries; Akka advises against provisioning other resources in it to avoid management conflicts, and anything the customer adds outside this scope is the customer’s responsibility.

Quotas and service limits

Customer

Customer ensures sufficient quota for compute, storage, and networking. Akka advises on expected consumption.

Billing

Customer

Customer owns and operates the account and pays the bill.

2. Networking and connectivity

Akka creates the VPC (Virtual Private Cloud) and all in-region networking using cloud-provider best practices. The customer provides the CIDR range and owns the surrounding network: peering or hub-and-spoke topologies, IP allowlists, DNS, and any private-connectivity bridge to the corporate network.

At a glance

Akka: Builds the in-region VPC, load balancers, and certificate issuer. Publishes the connectivity-pattern whitepaper so the customer can choose.
Customer: Allocates the CIDR block, configures peering or hub-and-spoke to the corporate network, maintains IP allowlists and DNS records.

Responsibilities

Activity	Owner	Description
Private connectivity	Customer	The customer designs, implements, and operates private connectivity into and out of the cluster using whatever pattern fits their environment.
Connectivity pattern whitepaper	Akka	Akka publishes implementation details for each supported pattern, which the customer reviews when choosing.
Public ingress/egress	Akka	Akka installs a load balancer for the region and configures a certificate issuer (Let’s Encrypt by default) for platform APIs and generated application hostnames.
Private ingress/egress	Akka	Where private connectivity is selected, Akka installs the region using the chosen pattern, with an automatically generated load-balancer IP so internal traffic does not traverse the public internet.
CIDR allocation	Customer	Customer assigns an appropriately sized CIDR block, especially where peering or hub-and-spoke is required.
VPC peering / hub-and-spoke	Customer	Customer configures peering or hub-and-spoke between the Akka region’s VPC and other corporate networks. Availability depends on cloud provider.
IP allowlist on NAT and load balancers	Customer	Customer configures and maintains the IP allowlist for the NAT (Network Address Translation) gateways and the public load balancer. The customer informs Akka of changes that may affect Platform connectivity.
DNS records	Customer	Customer creates and maintains DNS records for platform machinery and applications in the cloud-provider DNS zones configured by Akka.

Activity

Owner

Description

Private connectivity

Customer

The customer designs, implements, and operates private connectivity into and out of the cluster using whatever pattern fits their environment.

Connectivity pattern whitepaper

Akka

Akka publishes implementation details for each supported pattern, which the customer reviews when choosing.

Public ingress/egress

Akka

Akka installs a load balancer for the region and configures a certificate issuer (Let’s Encrypt by default) for platform APIs and generated application hostnames.

Private ingress/egress

Akka

Where private connectivity is selected, Akka installs the region using the chosen pattern, with an automatically generated load-balancer IP so internal traffic does not traverse the public internet.

CIDR allocation

Customer

Customer assigns an appropriately sized CIDR block, especially where peering or hub-and-spoke is required.

VPC peering / hub-and-spoke

Customer

Customer configures peering or hub-and-spoke between the Akka region’s VPC and other corporate networks. Availability depends on cloud provider.

IP allowlist on NAT and load balancers

Customer

Customer configures and maintains the IP allowlist for the NAT (Network Address Translation) gateways and the public load balancer. The customer informs Akka of changes that may affect Platform connectivity.

DNS records

Customer

Customer creates and maintains DNS records for platform machinery and applications in the cloud-provider DNS zones configured by Akka.

3. Platform setup and bootstrap

Akka installs the platform machinery into the Kubernetes cluster the customer has provisioned, federates it to the Akka Federation Plane, and runs smoke tests before handing it over.

At a glance

Akka: Installs the platform machinery (Akka runtime, operators, observability) into the customer’s cluster and configures region groups.
Customer: Provisions the cluster and database, installs Teleport for federation using the short-lived token Akka provides, identifies region groupings, and provides a preferred maintenance window that Akka aims to use for operations that may cause downtime.

Responsibilities

Activity	Owner	Description
Platform bootstrapping	Akka	Akka installs the platform machinery (runtime, operators, observability) into the customer’s Kubernetes cluster after the customer provisions the underlying infrastructure.
Teleport identity-aware proxy	Customer	The customer installs and maintains the Teleport identity-aware proxy used by the Federation Plane to reach private Kubernetes API servers, including ongoing operational health and version upgrades. Akka provides a short-lived token and the installation command at setup time. See the Teleport appendix.
Kubernetes access via Teleport	Akka	Akka uses Teleport for human access to platform infrastructure, with full session recording and audit logging. Access requires explicit justification and approval per the Access Control Policy.
Region group identification	Customer	Customer identifies region groupings appropriate for the workloads (e.g., for cross-region replication scope) and informs Akka.
Region group configuration	Akka	Akka configures region groups on the Federation Plane to match the customer’s groupings.
Maintenance window	Customer	Customer provides a preferred maintenance window. Akka aims to use this window for operations that may cause downtime.

Activity

Owner

Description

Platform bootstrapping

Akka

Akka installs the platform machinery (runtime, operators, observability) into the customer’s Kubernetes cluster after the customer provisions the underlying infrastructure.

Teleport identity-aware proxy

Customer

The customer installs and maintains the Teleport identity-aware proxy used by the Federation Plane to reach private Kubernetes API servers, including ongoing operational health and version upgrades. Akka provides a short-lived token and the installation command at setup time. See the Teleport appendix.

Kubernetes access via Teleport

Akka

Akka uses Teleport for human access to platform infrastructure, with full session recording and audit logging. Access requires explicit justification and approval per the Access Control Policy.

Region group identification

Customer

Customer identifies region groupings appropriate for the workloads (e.g., for cross-region replication scope) and informs Akka.

Region group configuration

Akka

Akka configures region groups on the Federation Plane to match the customer’s groupings.

Maintenance window

Customer

Customer provides a preferred maintenance window. Akka aims to use this window for operations that may cause downtime.

4. Platform maintenance and releases

Akka manages the lifecycle of the platform itself: patching, runtime/infra releases, and security remediations. The customer operates Kubernetes and database upgrades on their own infrastructure, consulting Akka first on certified versions.

At a glance

Akka: Patches platform infrastructure (JVM, container base image, Akka runtime) and ships regular releases of the runtime, region machinery, and Federation Plane.
Customer: Schedules and runs K8s and database upgrades after consulting Akka on certified versions. Receives advance notice of Akka-led maintenance.

Responsibilities

Activity	Owner	Description
Infrastructure patching and vulnerability management	Akka	Akka manages patching and vulnerability remediation for the Platform components, including the JVM, container base image, and Akka runtime that ship with the customer’s deployed services. Vulnerability reports available from trust.akka.io.
Kubernetes and database upgrades	Customer	The customer schedules and runs Kubernetes and database upgrades. The customer must consult Akka in advance so that Akka can certify the target versions against the Platform. Running an unverified version may break Platform functionality and is the customer’s responsibility.
Releases (runtime, region machinery, Federation Plane)	Akka	Akka schedules regular releases to installations covering the Akka runtime, region machinery, and Federation Plane components.

Activity

Owner

Description

Infrastructure patching and vulnerability management

Akka

Akka manages patching and vulnerability remediation for the Platform components, including the JVM, container base image, and Akka runtime that ship with the customer’s deployed services. Vulnerability reports available from trust.akka.io.

Kubernetes and database upgrades

Customer

The customer schedules and runs Kubernetes and database upgrades. The customer must consult Akka in advance so that Akka can certify the target versions against the Platform. Running an unverified version may break Platform functionality and is the customer’s responsibility.

Releases (runtime, region machinery, Federation Plane)

Akka

Akka schedules regular releases to installations covering the Akka runtime, region machinery, and Federation Plane components.

5. Operations and scaling

Akka elastically scales the application workloads to match traffic, within the region’s sizing standards; this depends on the customer ensuring the underlying cluster and database have capacity headroom. The customer retains visibility and control over cost and capacity decisions with business impact.

At a glance

Akka: Auto-provisions and de-provisions compute and persistence to match utilization. HA (high availability) is the default. Triages and prioritizes customer feature requests.
Customer: Reviews their cloud-account spend, selects sizing options, and signals expected demand spikes (e.g., performance testing) so Akka can pre-warm.

Responsibilities

Activity	Owner	Description
Cost controls	Customer	Customer reviews their cloud-account subscription and monthly charges. Akka auto-provisions and de-provisions to match utilization; HA is the default posture; sizing options keep cost in check.
Infrastructure scalability	Customer	Customer is responsible for ensuring scalability of the underlying infrastructure, including compute capacity for node pools and database scaling.
Application elasticity	Akka	Akka dynamically adds and removes compute and persistence to accommodate real-time traffic against the customer’s performance SLA (Service Level Agreement) targets. This elasticity is contingent on the customer ensuring sufficient cluster compute and database capacity headroom (see Infrastructure scalability).
Region decommission	Shared	On customer request (end of contract, scope change, topology adjustment), Akka follows the documented decommissioning runbook to gracefully remove the region from the Federation Plane and clean up stale platform resources. The customer is responsible for deleting the underlying cloud infrastructure.
Feature requests	Customer	Customer submits feature requests via the support channel. Akka triages, prioritizes, and communicates status.

Activity

Owner

Description

Cost controls

Customer

Customer reviews their cloud-account subscription and monthly charges. Akka auto-provisions and de-provisions to match utilization; HA is the default posture; sizing options keep cost in check.

Infrastructure scalability

Customer

Customer is responsible for ensuring scalability of the underlying infrastructure, including compute capacity for node pools and database scaling.

Application elasticity

Akka

Akka dynamically adds and removes compute and persistence to accommodate real-time traffic against the customer’s performance SLA (Service Level Agreement) targets. This elasticity is contingent on the customer ensuring sufficient cluster compute and database capacity headroom (see Infrastructure scalability).

Region decommission

Shared

On customer request (end of contract, scope change, topology adjustment), Akka follows the documented decommissioning runbook to gracefully remove the region from the Federation Plane and clean up stale platform resources. The customer is responsible for deleting the underlying cloud infrastructure.

Feature requests

Customer

Customer submits feature requests via the support channel. Akka triages, prioritizes, and communicates status.

6. Encryption, keys, and certificates

In BYOK8s, encryption of customer data is the customer’s responsibility: database (at rest and in transit) and ingress TLS in transit (either by providing a certificate issuer or by granting Akka enough access to solve DNS-01 / HTTP-01 challenges). Akka manages encryption internal to the platform: mTLS between Akka components and TLS to the Federation Plane (see the Architecture appendix), and encryption of secrets synced from the Federation Plane (see the Data protection appendix). Lifecycle of cryptographic materials follows Akka’s Key Management and Cryptography Policy.

At a glance

Customer: Owns customer-data encryption end-to-end: database (at rest and in transit), ingress TLS via certificate issuer or DNS/HTTP-01 access. Manages CMEK key material.
Akka: Manages encryption internal to the platform: mTLS between Akka components, TLS to the Federation Plane, and encryption of FP-synced secrets.

Responsibilities

Activity	Owner	Description
Customer-data encryption	Customer	The customer is responsible for setting up encryption of customer data: database (at rest and in transit) and ingress TLS (certificate issuer, or DNS-01 / HTTP-01 access for Akka).
Platform-internal encryption	Akka	Akka manages encryption internal to the platform: mTLS between Akka components (per the Architecture appendix), TLS to the Federation Plane, and encryption of FP-synced secrets (per the Data protection appendix).
Cryptographic key management	Customer	Lifecycle, rotation, and access control of cryptographic materials follow the Akka Key Management and Cryptography Policy. Cloud-native KMS handles lifecycle for Akka-managed materials. Customer-managed keys (CMEK, BYO certificates) are managed by the customer per the same policy.
Customer-managed database encryption keys (CMEK)	Customer	Where CMEK is selected, customer creates and maintains key material in their KMS and shares the identifier with Akka. Customer is responsible for ensuring continued access to the CMEK.
Customer-provided TLS certificates	Customer	Where Akka cannot automatically provision TLS (e.g., private load balancers, customer-owned domains), the customer provides certificates or configures cert-manager. Akka validates and deploys.

Activity

Owner

Description

Customer-data encryption

Customer

The customer is responsible for setting up encryption of customer data: database (at rest and in transit) and ingress TLS (certificate issuer, or DNS-01 / HTTP-01 access for Akka).

Platform-internal encryption

Akka

Akka manages encryption internal to the platform: mTLS between Akka components (per the Architecture appendix), TLS to the Federation Plane, and encryption of FP-synced secrets (per the Data protection appendix).

Cryptographic key management

Customer

Lifecycle, rotation, and access control of cryptographic materials follow the Akka Key Management and Cryptography Policy. Cloud-native KMS handles lifecycle for Akka-managed materials. Customer-managed keys (CMEK, BYO certificates) are managed by the customer per the same policy.

Customer-managed database encryption keys (CMEK)

Customer

Where CMEK is selected, customer creates and maintains key material in their KMS and shares the identifier with Akka. Customer is responsible for ensuring continued access to the CMEK.

Customer-provided TLS certificates

Customer

Where Akka cannot automatically provision TLS (e.g., private load balancers, customer-owned domains), the customer provides certificates or configures cert-manager. Akka validates and deploys.

7. Observability and monitoring

Monitoring follows the same platform/application boundary as the rest of this model: Akka watches the platform layer it operates, and the customer watches their own applications plus the cluster and access tooling on their side. Application telemetry flows to whichever observability vendor the customer chooses.

At a glance

Akka: Watches the health of the platform it operates, for example its system and infrastructure pods, database health and resource use, platform runtime errors, and internal processing-lag signals, and acts on them as part of running the region. Also tracks platform availability and region telemetry, with uptime reports on request.
Customer: Watches their own Akka applications, for example pod resource use, projection health, and any service-specific metrics, along with the cluster, node, and database infrastructure they operate. Sets the thresholds that make sense for their services, configures Teleport alerting on their side, exports application telemetry over OTLP, and owns cloud-native audit logging on the cloud account.

This lays out the division of responsibility between the platform and application layers. It is not a fixed catalog of alerts, a set of committed thresholds, or a service-level guarantee, the signals and tooling Akka uses to run the platform change over time, and availability and support commitments live in the Akka Federation Plane SLA Policy and the Customer Support Policy. Monitoring of the customer’s own application pods sits with the customer rather than Akka, since they are best placed to define what healthy looks like for their services, and Akka can share recommended metrics and thresholds on request.

Responsibilities

Activity	Owner	Description
Platform health monitoring	Akka	Akka monitors and responds to the health of the platform it operates, for example its system and infrastructure pods, database health and resource use, platform runtime errors, and internal processing-lag signals. Described generically; the specific signals and tooling change as the platform evolves.
Platform availability monitoring	Akka	Akka monitors and reports availability of the Akka Platform. Uptime reports available on request. Platform availability commitments are governed by the Akka Federation Plane SLA Policy. Availability of customer-deployed services running on the platform is the customer’s responsibility, see the customer applications section.
Platform logs (excluding SDK logs)	Akka	Akka monitors all platform logs other than SDK logs, which are not ingested into Akka’s observability stack.
Akka region platform telemetry	Akka	Akka monitors region-level metrics and logs and notifies the customer as needed.
Application monitoring	Customer	The customer monitors their own application pods, for example resource use, projection health, and service-specific metrics, and sets the thresholds that matter for their services. Recommended metrics and thresholds are available from Akka on request.
Teleport access monitoring	Customer	Teleport sits at the boundary between the customer’s infrastructure and Akka’s, so meaningful coverage needs both sides; the customer configures alerting for Teleport access on their side.
Customer-side platform telemetry (optional)	Customer	Customer may optionally configure their own telemetry over the cluster and database since they own the cloud account. Akka can advise on which components are appropriate to observe externally.
Cloud-native audit logging	Customer	Customer enables cloud-native audit/security services (e.g., CloudTrail, Cloud Audit Logs, equivalents) and notifies Akka if any suspicious SIEM alerts are observed.
Application telemetry export	Customer	Customer configures export of application logs, metrics, and traces to their observability platform via Akka’s OpenTelemetry (OTLP) exporters, which support any OpenTelemetry-compatible backend.

Activity

Owner

Description

Platform health monitoring

Akka

Akka monitors and responds to the health of the platform it operates, for example its system and infrastructure pods, database health and resource use, platform runtime errors, and internal processing-lag signals. Described generically; the specific signals and tooling change as the platform evolves.

Platform availability monitoring

Akka

Akka monitors and reports availability of the Akka Platform. Uptime reports available on request. Platform availability commitments are governed by the Akka Federation Plane SLA Policy. Availability of customer-deployed services running on the platform is the customer’s responsibility, see the customer applications section.

Platform logs (excluding SDK logs)

Akka

Akka monitors all platform logs other than SDK logs, which are not ingested into Akka’s observability stack.

Akka region platform telemetry

Akka

Akka monitors region-level metrics and logs and notifies the customer as needed.

Application monitoring

Customer

The customer monitors their own application pods, for example resource use, projection health, and service-specific metrics, and sets the thresholds that matter for their services. Recommended metrics and thresholds are available from Akka on request.

Teleport access monitoring

Customer

Teleport sits at the boundary between the customer’s infrastructure and Akka’s, so meaningful coverage needs both sides; the customer configures alerting for Teleport access on their side.

Customer-side platform telemetry (optional)

Customer

Customer may optionally configure their own telemetry over the cluster and database since they own the cloud account. Akka can advise on which components are appropriate to observe externally.

Cloud-native audit logging

Customer

Customer enables cloud-native audit/security services (e.g., CloudTrail, Cloud Audit Logs, equivalents) and notifies Akka if any suspicious SIEM alerts are observed.

Application telemetry export

Customer

Customer configures export of application logs, metrics, and traces to their observability platform via Akka’s OpenTelemetry (OTLP) exporters, which support any OpenTelemetry-compatible backend.

8. Backups, disaster recovery, and multi-region

The customer runs the database with point-in-time recovery (PITR) on their infrastructure; Akka uses Velero for Kubernetes resource backups with infrastructure the customer provides. Restore testing, disaster-recovery exercises, and replication topology are joint decisions, and Akka provides multi-region failover tooling.

At a glance

Akka: Operates Velero for K8s resource backups (against customer-provided IAM and object storage), provides multi-region failover tooling and runbooks. RTO/RPO targets are set by the agreement.
Customer: Configures database point-in-time recovery (PITR), notifies Akka after ad-hoc backups, specifies replication mode per service, is consulted before failover.
Shared: Velero (customer provides IAM/storage, Akka operates), restore testing, and the annual or as-agreed disaster-recovery exercise.

Responsibilities

Activity	Owner	Description
Database point-in-time recovery (PITR)	Customer	Customer configures continuous point-in-time recovery (PITR) for the database in their environment. Akka is informed. Retention of at least 8 days is recommended.
Ad-hoc database backups	Customer	Customer notifies Akka after taking ad-hoc database backups (e.g., before high-risk changes, or snapshots taken for incident handling).
Kubernetes resource backups (Velero)	Shared	Akka uses Velero to back up stateful Kubernetes resources. Customer provides the necessary IAM binding and object storage.
Backup restore testing	Shared	Akka and the customer perform periodic restore testing against backups; results are summarized on request. The Disaster Recovery Exercise row covers joint exercises.
Disaster recovery exercise	Shared	Akka and the customer work together, annually or as agreed, to simulate a disaster and fully recover from it, ensuring the recovery meets or exceeds the customer’s needs.
Cross-region replication configuration	Shared	Customer specifies replication mode (e.g., region-pinned, replicated) per service. Akka enables and operates the underlying replication.
Multi-region failover procedure	Shared	Akka and the customer work together on failover: Akka provides the tooling and runbooks, and the customer is consulted before failover and informed of execution.
RTO/RPO commitments	Akka	RTO/RPO targets are defined in the customer’s agreement.

Activity

Owner

Description

Database point-in-time recovery (PITR)

Customer

Customer configures continuous point-in-time recovery (PITR) for the database in their environment. Akka is informed. Retention of at least 8 days is recommended.

Ad-hoc database backups

Customer

Customer notifies Akka after taking ad-hoc database backups (e.g., before high-risk changes, or snapshots taken for incident handling).

Kubernetes resource backups (Velero)

Shared

Akka uses Velero to back up stateful Kubernetes resources. Customer provides the necessary IAM binding and object storage.

Backup restore testing

Shared

Akka and the customer perform periodic restore testing against backups; results are summarized on request. The Disaster Recovery Exercise row covers joint exercises.

Disaster recovery exercise

Shared

Akka and the customer work together, annually or as agreed, to simulate a disaster and fully recover from it, ensuring the recovery meets or exceeds the customer’s needs.

Cross-region replication configuration

Shared

Customer specifies replication mode (e.g., region-pinned, replicated) per service. Akka enables and operates the underlying replication.

Multi-region failover procedure

Shared

Akka and the customer work together on failover: Akka provides the tooling and runbooks, and the customer is consulted before failover and informed of execution.

RTO/RPO commitments

Akka

RTO/RPO targets are defined in the customer’s agreement.

9. Identity, access, and permissions

The customer owns enterprise identity for human users and configures access in the Akka console. Akka manages its own non-human identities and any privileged human access into customer environments.

At a glance

Customer: Provides the IdP that authenticates console/CLI users, enforces MFA, and manages own users, teams, and role assignments.
Akka: Uses Teleport for session-recorded privileged access and provides access-control reports on request. Operates within the service-account access the customer grants.

Responsibilities

Activity	Owner	Description
Akka IAM integration	Akka	Akka Federation Plane integrates with the customer’s identity provider to manage organizations, users, and team access controls.
IAM (CLI and console)	Customer	Customer provides the enterprise identity, authentication, and authorization systems and policies used to access the Akka console and CLI.
Customer user and team management	Customer	Customer manages its own users, teams, and role assignments within the Akka console.
MFA on Akka Console and CLI	Customer	Customer’s IdP enforces MFA for users accessing the Akka console and CLI. Akka enforces MFA on its own internal access.
Infrastructure access control and IAM (cloud account)	Customer	Customer is responsible for maintaining strict access control to the cloud infrastructure.
Service accounts and keys	Customer	Customer creates and manages the service accounts, keys, and IAM bindings required for Platform operation within the cloud account.
Privileged access via Teleport	Akka	Akka uses Teleport for human access to platform infrastructure, with session recording and audit logging. Access requires explicit justification and approval. Audit logs available to the customer on request.
Just-in-time access for customer data	Akka	Where access to customer-confidential data is required (e.g., for incident handling), Akka requests authorization per the Access Control for Customer-Confidential Data policy. Audit logs available on request.
Access-control reports	Akka	Akka provides access-control reports covering Akka’s own privileged access to the customer’s installation, on request. The customer manages their own IAM independently.

Activity

Owner

Description

Akka IAM integration

Akka

Akka Federation Plane integrates with the customer’s identity provider to manage organizations, users, and team access controls.

IAM (CLI and console)

Customer

Customer provides the enterprise identity, authentication, and authorization systems and policies used to access the Akka console and CLI.

Customer user and team management

Customer

Customer manages its own users, teams, and role assignments within the Akka console.

MFA on Akka Console and CLI

Customer

Customer’s IdP enforces MFA for users accessing the Akka console and CLI. Akka enforces MFA on its own internal access.

Infrastructure access control and IAM (cloud account)

Customer

Customer is responsible for maintaining strict access control to the cloud infrastructure.

Service accounts and keys

Customer

Customer creates and manages the service accounts, keys, and IAM bindings required for Platform operation within the cloud account.

Privileged access via Teleport

Akka

Akka uses Teleport for human access to platform infrastructure, with session recording and audit logging. Access requires explicit justification and approval. Audit logs available to the customer on request.

Just-in-time access for customer data

Akka

Where access to customer-confidential data is required (e.g., for incident handling), Akka requests authorization per the Access Control for Customer-Confidential Data policy. Audit logs available on request.

Access-control reports

Akka

Akka provides access-control reports covering Akka’s own privileged access to the customer’s installation, on request. The customer manages their own IAM independently.

10. Federation Plane procedures and engagement

Akka operates the Federation Plane and the recurring rituals that surround it: incidents, maintenance notifications, operations reviews, customer onboarding/offboarding.

At a glance

Akka: Runs the Federation Plane, 24/7 incident response, advance maintenance notice, postmortems, ops sync, and executive review. Response times and notice periods follow the Customer Support Policy.
Shared: BYOK8s onboarding, support and communication channels, customer portal training, and end-of-contract decommission.

Responsibilities

Activity	Owner	Description
Federation Plane disaster recovery	Akka	Akka maintains uptime for the Federation Plane and configures its disaster recovery. Even in the rare event the Federation Plane is unavailable, running Akka applications continue to operate.
Support and communication channels	Shared	At onboarding, Akka and the customer agree on operational and engagement-level communication channels (e.g., shared Slack, distribution lists, cadence). Formal support and incident channels are governed by the Customer Support Policy and the Incident Response row.
Incident response	Akka	Akka provides 24/7 incident response per the Customer Support Policy, which defines the severity classifications and response-time targets. Incidents are opened via support.akka.io, the Akka console, or [email protected]. Subsequent updates per the Incident Management Process.
Postmortem delivery	Akka	Akka delivers post-incident reviews for Severity 1 and 2 incidents within an agreed cadence following resolution.
Maintenance notifications	Akka	Akka notifies the customer in advance of planned maintenance windows that could affect availability, and via release-notify emails for runtime/SDK releases. Notice periods follow the Customer Support Policy.
Operations sync	Akka	Recurring operational review covering system health, maintenance, incidents, and roadmap items relevant to the customer.
Strategic steering	Akka	Periodic alignment session covering usage, capacity, product direction, and customer priorities.
Executive partnership review	Akka	Executive-level partnership review covering relationship health, escalation status, and strategic items.
BYOK8s onboarding	Shared	Joint onboarding covering account setup, region provisioning, connectivity validation, and acceptance criteria.
Customer portal access and training	Shared	Customer is assigned access to the portal; Akka assigns the region and walks the customer through console, CLI, and ticketing flows.
Customer offboarding and data return	Shared	At end of contract, Akka coordinates region decommission, return or destruction of customer data, and revocation of access per the Data Retention Policy and the terms of the agreement.
Issue tracking	Akka	Akka tracks customer-raised issues and remediation through to closure with status visibility to the customer.

Activity

Owner

Description

Federation Plane disaster recovery

Akka

Akka maintains uptime for the Federation Plane and configures its disaster recovery. Even in the rare event the Federation Plane is unavailable, running Akka applications continue to operate.

Support and communication channels

Shared

At onboarding, Akka and the customer agree on operational and engagement-level communication channels (e.g., shared Slack, distribution lists, cadence). Formal support and incident channels are governed by the Customer Support Policy and the Incident Response row.

Incident response

Akka

Akka provides 24/7 incident response per the Customer Support Policy, which defines the severity classifications and response-time targets. Incidents are opened via support.akka.io, the Akka console, or [email protected]. Subsequent updates per the Incident Management Process.

Postmortem delivery

Akka

Akka delivers post-incident reviews for Severity 1 and 2 incidents within an agreed cadence following resolution.

Maintenance notifications

Akka

Akka notifies the customer in advance of planned maintenance windows that could affect availability, and via release-notify emails for runtime/SDK releases. Notice periods follow the Customer Support Policy.

Operations sync

Akka

Recurring operational review covering system health, maintenance, incidents, and roadmap items relevant to the customer.

Strategic steering

Akka

Periodic alignment session covering usage, capacity, product direction, and customer priorities.

Executive partnership review

Akka

Executive-level partnership review covering relationship health, escalation status, and strategic items.

BYOK8s onboarding

Shared

Joint onboarding covering account setup, region provisioning, connectivity validation, and acceptance criteria.

Customer portal access and training

Shared

Customer is assigned access to the portal; Akka assigns the region and walks the customer through console, CLI, and ticketing flows.

Customer offboarding and data return

Shared

At end of contract, Akka coordinates region decommission, return or destruction of customer data, and revocation of access per the Data Retention Policy and the terms of the agreement.

Issue tracking

Akka

Akka tracks customer-raised issues and remediation through to closure with status visibility to the customer.

11. Compliance and audit

Akka maintains the platform’s compliance posture (SOC 2, encryption, vulnerability management, sanctions screening, personnel security). The customer remains the controller of any data their applications process.

At a glance

Akka: Maintains SOC 2 Type II, annual third-party pen test, continuous vulnerability scanning, sanctions screening, data-residency commitments, and audit log delivery.
Customer: Secures Federation Plane tokens and project access. Is the controller of application PII; handles GDPR Data Subject Requests directly.

Responsibilities

Activity	Owner	Description
SOC 2 Type II	Akka	Akka maintains SOC 2 Type II for the Akka Platform. Report available under NDA via trust.akka.io. SOC 3 is also available as a publicly-shareable companion.
Penetration testing	Akka	Annual third-party penetration testing as part of the SOC 2 audit cycle. Executive summary available under NDA via trust.akka.io.
Vulnerability scanning	Akka	Akka performs continuous vulnerability scanning of platform components and dependencies; findings are tracked to remediation per the Vulnerability Management Policy. Customers are notified of critical and high severity security patches via security advisory emails and the trust center; disclosure occurs no later than the date the patch is made available.
Personnel security and background checks	Akka	Akka performs background checks on personnel with access to customer environments and provides security awareness training, per the Personnel Security Policy.
Data residency	Akka	Customer data is stored within the cloud region(s) configured for the customer’s installation. Multi-region installations replicate within customer-selected regions only. Each customer’s data is isolated in dedicated database resources; no shared data plane across customers.
Multi-tenant data security (Federation Plane)	Akka	Akka secures all customer data located within the Federation Plane.
Customer data security (Federation Plane tokens and projects)	Customer	Customer is responsible for securing Federation Plane tokens and access to projects.
GDPR / application data	Customer	Customer is responsible for how its services handle PII and for ensuring compliance with GDPR or other applicable privacy regulations. Akka acts as neither controller nor processor of data handled by the customer’s services.
GDPR / Federation Plane data	Shared	The Federation Plane does not handle customer application data; it processes only minimal PII consisting of customer user and administrator identities, in accordance with Akka’s GDPR-compliant privacy policy.
Subprocessor list	Akka	Current subprocessor list maintained at trust.akka.io.
Customer audit log delivery	Akka	Akka maintains audit logs of control-plane actions (authentication, project and service lifecycle, IAM and token changes). Logs delivered on request; recurring cadences can be arranged.
Security questionnaire response	Akka	Akka responds to customer CAIQ/SIG and bespoke security questionnaires drawing on the ISMS control library.
Data breach notification	Akka	Akka notifies the customer without undue delay where a breach of Akka-held customer data poses risk, including nature, scope, and remediation.
Sanctions screening	Akka	Customer organizations are screened against sanctions lists periodically. The customer is informed if a screening result requires action.
End-of-life notification	Akka	Akka provides advance notice of any planned product or feature end-of-life with sufficient lead time for migration planning.

Activity

Owner

Description

SOC 2 Type II

Akka

Akka maintains SOC 2 Type II for the Akka Platform. Report available under NDA via trust.akka.io. SOC 3 is also available as a publicly-shareable companion.

Penetration testing

Akka

Annual third-party penetration testing as part of the SOC 2 audit cycle. Executive summary available under NDA via trust.akka.io.

Vulnerability scanning

Akka

Akka performs continuous vulnerability scanning of platform components and dependencies; findings are tracked to remediation per the Vulnerability Management Policy. Customers are notified of critical and high severity security patches via security advisory emails and the trust center; disclosure occurs no later than the date the patch is made available.

Personnel security and background checks

Akka

Akka performs background checks on personnel with access to customer environments and provides security awareness training, per the Personnel Security Policy.

Data residency

Akka

Customer data is stored within the cloud region(s) configured for the customer’s installation. Multi-region installations replicate within customer-selected regions only. Each customer’s data is isolated in dedicated database resources; no shared data plane across customers.

Multi-tenant data security (Federation Plane)

Akka

Akka secures all customer data located within the Federation Plane.

Customer data security (Federation Plane tokens and projects)

Customer

Customer is responsible for securing Federation Plane tokens and access to projects.

GDPR / application data

Customer

Customer is responsible for how its services handle PII and for ensuring compliance with GDPR or other applicable privacy regulations. Akka acts as neither controller nor processor of data handled by the customer’s services.

GDPR / Federation Plane data

Shared

The Federation Plane does not handle customer application data; it processes only minimal PII consisting of customer user and administrator identities, in accordance with Akka’s GDPR-compliant privacy policy.

Subprocessor list

Akka

Current subprocessor list maintained at trust.akka.io.

Customer audit log delivery

Akka

Akka maintains audit logs of control-plane actions (authentication, project and service lifecycle, IAM and token changes). Logs delivered on request; recurring cadences can be arranged.

Security questionnaire response

Akka

Akka responds to customer CAIQ/SIG and bespoke security questionnaires drawing on the ISMS control library.

Data breach notification

Akka

Akka notifies the customer without undue delay where a breach of Akka-held customer data poses risk, including nature, scope, and remediation.

Sanctions screening

Akka

Customer organizations are screened against sanctions lists periodically. The customer is informed if a screening result requires action.

End-of-life notification

Akka

Akka provides advance notice of any planned product or feature end-of-life with sufficient lead time for migration planning.

12. Customer applications (Akka SDK services)

Applications that the customer builds with the Akka SDK are owned end-to-end by the customer: source, deployment, configuration, secrets, runtime monitoring, and access control.

At a glance: Customer (end-to-end): Source, build, deploy, version, roll back. Service config and secrets. Application IAM (JWT/JWKS), Service ACLs, security logs. SDLC tooling (IDE, repos, CI/CD). All application observability.

Responsibilities

Activity	Owner	Description
Application code and dependency patching	Customer	Customer reviews their application code and any libraries or dependencies they introduce for security issues and vulnerabilities. The JVM, container base image, OS, and Akka runtime packaged into the deployed service are patched by Akka (see Platform maintenance and releases, Infrastructure patching).
Service configuration (incl. secrets)	Customer	Customer configures services to enable their functionality, including secrets used to access other services.
Integrations setup (broker, object storage, etc.)	Customer	Where services depend on integrations such as message brokers or object storage, the customer configures these for the Akka Project before service deployment.
Application deployments	Customer	Customer owns and manages the lifecycle of Akka SDK applications: build, version, deploy, roll back.
Source code management	Customer	Source code management for Akka service implementations is the customer’s responsibility.
Service scaling limits	Customer	Customer controls service instance counts within configured platform limits.
Application logs	Customer	Metrics and logs from services built with the Akka SDK are sent to the customer’s logging platform and are not ingested into Akka’s observability stack.
SDK logs	Customer	Customer monitors SDK and application logs in their own observability platform.
Application security logs	Customer	Customer can configure dashboards over cloud security logs and stream them to a GSOC (Global Security Operations Center) or observability tool.
Service ACLs	Customer	Customer configures Service ACLs to protect access to non-public service endpoints.
Application IAM (JWT/JWKS)	Customer	Akka SDK supports access scoping through JWTs and JWKS. The customer configures issuer trust, claims, and ACLs appropriate for their application.
SDLC tooling (IDE, repos, CI/CD)	Customer	Customer owns and operates the SDLC environment used to build services running on Akka. Akka ships developer tooling that the customer integrates into their SDLC.

Activity

Owner

Description

Application code and dependency patching

Customer

Customer reviews their application code and any libraries or dependencies they introduce for security issues and vulnerabilities. The JVM, container base image, OS, and Akka runtime packaged into the deployed service are patched by Akka (see Platform maintenance and releases, Infrastructure patching).

Service configuration (incl. secrets)

Customer

Customer configures services to enable their functionality, including secrets used to access other services.

Integrations setup (broker, object storage, etc.)

Customer

Where services depend on integrations such as message brokers or object storage, the customer configures these for the Akka Project before service deployment.

Application deployments

Customer

Customer owns and manages the lifecycle of Akka SDK applications: build, version, deploy, roll back.

Source code management

Customer

Source code management for Akka service implementations is the customer’s responsibility.

Service scaling limits

Customer

Customer controls service instance counts within configured platform limits.

Application logs

Customer

Metrics and logs from services built with the Akka SDK are sent to the customer’s logging platform and are not ingested into Akka’s observability stack.

SDK logs

Customer

Customer monitors SDK and application logs in their own observability platform.

Application security logs

Customer

Customer can configure dashboards over cloud security logs and stream them to a GSOC (Global Security Operations Center) or observability tool.

Service ACLs

Customer

Customer configures Service ACLs to protect access to non-public service endpoints.

Application IAM (JWT/JWKS)

Customer

Akka SDK supports access scoping through JWTs and JWKS. The customer configures issuer trust, claims, and ACLs appropriate for their application.

SDLC tooling (IDE, repos, CI/CD)

Customer

Customer owns and operates the SDLC environment used to build services running on Akka. Akka ships developer tooling that the customer integrates into their SDLC.

Appendix A: Architecture in brief

Details

Akka Automated Operations consists of two planes:

Federation Plane, a globally-accessible coordination service managed by Akka. Handles organizations, accounts, role assignments, key rotation, access tokens, and application deployment across regions. Designed to be highly resilient. In the rare event that the Federation Plane is unavailable, applications running in the Application Plane continue to operate.
Application Plane, one or more federated regions. In BYOK8s, each region runs inside a Kubernetes cluster that the customer provides and operates inside their cloud account. The cluster hosts the Akka operators for routing, elasticity, deployment, certificate management, key rotation, and cross-region failover, together with the persistence store. The customer is responsible for the cluster, its upgrades, the database, and their own container registry; Akka manages the Akka components running on top.

Communication between Federation Plane and Application Plane uses TLS with token-based authentication. Inter-region communication between applications uses mutual TLS (mTLS) with per-component certificates.

Appendix B: Data protection in brief

Details

All application data stays within the customer’s cloud region and VPC and is isolated from the Federation Plane. Data at rest is encrypted using the cloud provider’s encryption mechanism. Customers can rely on Akka-managed encryption or use Customer-Managed Encryption Keys (CMEK).

Akka applies an additional encryption layer for sensitive material that is synced from the Federation Plane to regional execution clusters: project secrets, authentication tokens, OpenID refresh tokens, and customer-supplied secrets. Lifecycle, rotation, and access control of cryptographic materials follow the Akka Key Management and Cryptography Policy.

Recovery objectives (RTO/RPO)

RTO and RPO targets are defined in the customer’s agreement.

Compliance posture (SOC 2 Type II, annual third-party penetration test, current subprocessor list) is published on trust.akka.io.

Appendix C: Private connectivity via Teleport

Details

Some enterprises require that Kubernetes API servers in their cloud accounts have no public endpoint. Akka supports this through Teleport, an identity-aware proxy and certificate authority that creates an authenticated, encrypted bridge between the Federation Plane and private Kubernetes clusters.

No public Kubernetes API endpoints, API servers remain entirely private.
Reverse tunnels, Teleport agents in each region initiate outbound connections to the Teleport proxy; the Federation Plane never connects directly into the region.
Complete audit trail, all authentication and API calls are logged. Audit logs are available to the customer on request.
Cloud-portable, works across AWS, GCP, Azure, and on-premises.

Appendix D: Glossary

Glossary

Term	Definition
AAO	Akka Automated Operations, Akka’s managed PaaS that runs inside the customer’s environment (cloud account in BYOC, Kubernetes cluster in BYOK8s).
BYOC	Bring Your Own Cloud, deployment model where Akka provisions and operates the Kubernetes cluster inside the customer’s cloud account.
BYOK8s	Bring Your Own Kubernetes, deployment model where Akka runs inside a Kubernetes cluster the customer provides and operates.
Akka SDK	The software development kit used to build Akka services (APIs, workflows, streaming consumers, timers, views).
Application Plane	The runtime environment within a region that hosts Akka applications. Runs inside the customer’s cloud account.
Federation Plane	The global coordination service managed by Akka that federates regions, handles accounts/billing, and orchestrates cross-region operations.
Region	A single Akka Application Plane installation inside a cloud-provider region.
Region Group	A logical grouping of regions used to scope cross-region replication and routing.
CMEK	Customer-Managed Encryption Key. When used, the customer’s KMS provides the key material that Akka uses to encrypt the database.
Federation Plane SLA Policy	The policy on trust.akka.io that defines platform availability commitments.
Customer Support Policy	The policy on trust.akka.io that defines severity classifications, response time SLOs, and escalation procedures.
Teleport	An identity-aware proxy and certificate authority used to bridge the Federation Plane to private Kubernetes API servers.
RTO / RPO	Recovery Time Objective / Recovery Point Objective. Targets are defined in the customer’s agreement.
FDE	Forward Deployed Engineer. The named Akka engineer assigned to your account who guides production readiness and stays engaged through operations.
SRE	Site Reliability Engineering. Akka’s operations function responsible for platform health, incident response, and runbook execution.
DR	Disaster Recovery. The plan and procedures for restoring service after a region or platform-level outage.
SLA	Service Level Agreement. The contractual commitment Akka makes to the customer (see Federation Plane SLA Policy).
VPC	Virtual Private Cloud. The isolated network in your cloud account where the Akka region is deployed.
CIDR	Classless Inter-Domain Routing. The notation Akka uses to scope the IP address range allocated to a region.
DSR	Data Subject Request. A request made under GDPR or similar privacy regulation to access, correct, or delete personal data.
IAM	Identity and Access Management. The system controlling who can access what, covering both cloud-account access and Akka console access.
ACL	Access Control List. Akka SDK construct restricting which callers can invoke a given service or endpoint.
JWT / JWKS	JSON Web Token / JSON Web Key Set. Token format and key publication mechanism used for application authentication.
IdP	Identity Provider. The customer’s enterprise identity system (Okta, Entra, etc.) federated with the Akka console.
KMS	Key Management Service. The cloud-provider service that stores and manages encryption keys.
NAT	Network Address Translation. Gateway used for outbound traffic from a VPC.
GSOC	Global Security Operations Center. The customer’s security operations function consuming application security logs.
SOC 2	Service Organization Controls 2. Audit framework Akka maintains for security and availability.
HA	High Availability. Architecture pattern designed to remain operational despite individual component failures.
CAIQ	Consensus Assessments Initiative Questionnaire. The Cloud Security Alliance’s standard cloud-security questionnaire used by enterprise procurement.
SIG	Standard Information Gathering. The Shared Assessments Group’s standard security and risk questionnaire used by enterprise procurement.
ISMS	Information Security Management System. The set of policies, procedures, and controls Akka uses to manage information security risk; the basis for SOC 2 attestation.
OTLP	OpenTelemetry Protocol. Standard wire format for emitting traces, metrics, and logs to observability backends.

Term

Definition

AAO

Akka Automated Operations, Akka’s managed PaaS that runs inside the customer’s environment (cloud account in BYOC, Kubernetes cluster in BYOK8s).

BYOC

Bring Your Own Cloud, deployment model where Akka provisions and operates the Kubernetes cluster inside the customer’s cloud account.

BYOK8s

Bring Your Own Kubernetes, deployment model where Akka runs inside a Kubernetes cluster the customer provides and operates.

Akka SDK

The software development kit used to build Akka services (APIs, workflows, streaming consumers, timers, views).

Application Plane

The runtime environment within a region that hosts Akka applications. Runs inside the customer’s cloud account.

Federation Plane

The global coordination service managed by Akka that federates regions, handles accounts/billing, and orchestrates cross-region operations.

Region

A single Akka Application Plane installation inside a cloud-provider region.

Region Group

A logical grouping of regions used to scope cross-region replication and routing.

CMEK

Customer-Managed Encryption Key. When used, the customer’s KMS provides the key material that Akka uses to encrypt the database.

Federation Plane SLA Policy

The policy on trust.akka.io that defines platform availability commitments.

Customer Support Policy

The policy on trust.akka.io that defines severity classifications, response time SLOs, and escalation procedures.

Teleport

An identity-aware proxy and certificate authority used to bridge the Federation Plane to private Kubernetes API servers.

RTO / RPO

Recovery Time Objective / Recovery Point Objective. Targets are defined in the customer’s agreement.

FDE

Forward Deployed Engineer. The named Akka engineer assigned to your account who guides production readiness and stays engaged through operations.

SRE

Site Reliability Engineering. Akka’s operations function responsible for platform health, incident response, and runbook execution.

Disaster Recovery. The plan and procedures for restoring service after a region or platform-level outage.

SLA

Service Level Agreement. The contractual commitment Akka makes to the customer (see Federation Plane SLA Policy).

VPC

Virtual Private Cloud. The isolated network in your cloud account where the Akka region is deployed.

CIDR

Classless Inter-Domain Routing. The notation Akka uses to scope the IP address range allocated to a region.

DSR

Data Subject Request. A request made under GDPR or similar privacy regulation to access, correct, or delete personal data.

IAM

Identity and Access Management. The system controlling who can access what, covering both cloud-account access and Akka console access.

ACL

Access Control List. Akka SDK construct restricting which callers can invoke a given service or endpoint.

JWT / JWKS

JSON Web Token / JSON Web Key Set. Token format and key publication mechanism used for application authentication.

IdP

Identity Provider. The customer’s enterprise identity system (Okta, Entra, etc.) federated with the Akka console.

KMS

Key Management Service. The cloud-provider service that stores and manages encryption keys.

NAT

Network Address Translation. Gateway used for outbound traffic from a VPC.

GSOC

Global Security Operations Center. The customer’s security operations function consuming application security logs.

SOC 2

Service Organization Controls 2. Audit framework Akka maintains for security and availability.

High Availability. Architecture pattern designed to remain operational despite individual component failures.

CAIQ

Consensus Assessments Initiative Questionnaire. The Cloud Security Alliance’s standard cloud-security questionnaire used by enterprise procurement.

SIG

Standard Information Gathering. The Shared Assessments Group’s standard security and risk questionnaire used by enterprise procurement.

ISMS

Information Security Management System. The set of policies, procedures, and controls Akka uses to manage information security risk; the basis for SOC 2 attestation.

OTLP

OpenTelemetry Protocol. Standard wire format for emitting traces, metrics, and logs to observability backends.

Appendix E: Where to find more

Details

trust.akka.io, SOC 2 Type II, SOC 3, subprocessor list, current compliance evidence, applicable policies.
support.akka.io or [email protected], Customer Support Portal and email channel for opening cases.

This document is maintained as a living reference and updated periodically as Akka’s platform and operational practices evolve. To receive notifications of material updates, email [email protected].

Where this document and any Akka policy on trust.akka.io diverge, the policy on trust.akka.io takes precedence.