Shared responsibility model

Cloud account provisioning

Dedicated

Akka

Akka provisions and owns a dedicated cloud account to host the platform, and sets up the account infrastructure and access it needs to run the region. A dedicated account simplifies cost tracking and security boundaries.

Cloud account provisioning

BYOC

Customer

Customer sets up a dedicated AWS account, GCP project, or Azure subscription for Akka to host the platform 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.

Cloud account provisioning

BYOK8s

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

Dedicated

Akka

Akka ensures sufficient quota for compute, storage, and networking in the account it owns. Customer is consulted on expected consumption.

Quotas and service limits

BYOC and BYOK8s

Customer

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

Execute akka-bootstrap

BYOC

Customer

Customer runs the Akka-provided Terragrunt utility to grant Akka programmatic access to the cloud account.

Terraform state backend

BYOC

Customer

Customer owns and secures the Terraform state backend (cloud storage bucket, locking, encryption) used when running akka-bootstrap.

Akka permissions

Dedicated

Akka

Akka creates and maintains the IAM permissions used to operate the platform, managing all roles and bindings within the account it owns.

Akka permissions

BYOC

Customer

Customer creates and maintains the IAM permissions Akka uses. Akka has no permissions outside these and cannot manage anything beyond them. Access can be cut off at any time.

Dedicated account

Dedicated

Akka

Akka provisions and operates a dedicated cloud account exclusively for the platform. To prevent management conflicts, no additional resources are provisioned in it.

Billing

Dedicated

Akka

Akka owns and operates the account and pays the associated bill. The customer’s cost is set by an agreed structure.

Billing

BYOC and BYOK8s

Customer

Customer owns and operates the account and pays the bill.

Private connectivity

Dedicated

Akka

Akka operates connectivity within its own VPC. Where the customer integrates its own network (for example, a transit gateway), the parties coordinate on the integration.

Private connectivity

BYOK8s

Customer

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

Ingress/egress

Dedicated

Akka

Akka installs the load balancer and certificate issuer (Let’s Encrypt by default) for the region’s platform APIs and generated application hostnames. Where private connectivity is used, the load balancer uses an automatically generated IP so internal traffic does not traverse the public internet.

Private connectivity pattern selection

BYOC

Customer

Customer reviews and chooses a private connectivity pattern from the supported AAO patterns. Akka reviews and validates feasibility.

Connectivity pattern whitepaper

BYOC and BYOK8s

Akka

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

Public ingress/egress

BYOC and BYOK8s

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

BYOC and BYOK8s

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

Dedicated

Akka

Akka assigns an appropriately sized CIDR block for the account it owns, especially where peering or hub-and-spoke is required. Customer is informed.

CIDR allocation

BYOC and BYOK8s

Customer

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

VPC peering / hub-and-spoke

Dedicated

Akka

Akka configures peering or hub-and-spoke between the Akka region’s VPC and other networks. Where the connection reaches a customer network, the customer coordinates on their side. Availability depends on cloud provider.

VPC peering / hub-and-spoke

BYOC and BYOK8s

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

Dedicated

Akka

Akka configures and maintains the IP allowlist for the NAT (Network Address Translation) gateways and the public load balancer, using the ranges the customer provides.

IP allowlist on NAT and load balancers

BYOC

Customer

Customer configures and maintains the IP allowlist for the NAT (Network Address Translation) gateways and the public load balancer.

IP allowlist on NAT and load balancers

BYOK8s

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

Dedicated

Akka

Akka creates and maintains DNS records for platform machinery and applications in the cloud-provider DNS zones for the installation. Customer is informed.

DNS records

BYOC and BYOK8s

Customer

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

Platform bootstrapping

Dedicated and BYOC

Akka

Akka provisions the region: networking, Kubernetes cluster, persistence store, registry, observability, and Akka operators. Customer reviews defaults and recommends changes for performance, RTO/RPO, or cost.

Platform bootstrapping

BYOK8s

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

BYOK8s

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.

Federation via Teleport

Dedicated and BYOC

Akka

Akka installs the Teleport identity-aware proxy used by the Federation Plane to reach private Kubernetes API servers. See Appendix C.

Kubernetes access via Teleport

All

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

All

Customer

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

Region group configuration

All

Akka

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

Maintenance window

All

Customer

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

Infrastructure patching and vulnerability management

Dedicated and BYOC

Akka

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

Infrastructure patching and vulnerability management

BYOK8s

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

Dedicated and BYOC

Akka

Akka aims to perform K8s and database upgrades within the preferred maintenance window. Customer is notified prior to any maintenance that causes downtime.

Kubernetes and database upgrades

BYOK8s

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)

All

Akka

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

Cost controls

Dedicated

Akka

Akka pays the cloud bill and periodically reviews the 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.

Cost controls

BYOC and BYOK8s

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

BYOK8s

Customer

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

Scalability planning

Dedicated and BYOC

Shared

Akka monitors utilization and concurrency and auto-scales within sizing standards. Customer notifies Akka in advance of expected rapid expansion or pre-warming needs.

Application elasticity

Dedicated and BYOC

Akka

Akka dynamically adds and removes compute and persistence to accommodate real-time traffic against the customer’s performance SLA (Service Level Agreement) targets.

Application elasticity

BYOK8s

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

Dedicated and BYOC

Akka

On customer request (end of contract, scope change, topology adjustment), Akka follows the documented decommissioning runbook to gracefully remove the region and clean up stale resources.

Region decommission

BYOK8s

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

All

Customer

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

Customer-data encryption

BYOK8s

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

BYOK8s

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).

Encryption in transit and at rest

Dedicated and BYOC

Akka

Akka encrypts customer data in transit (TLS) and at rest using cloud-provider encryption services. Default keys are Akka-managed.

Cryptographic key management

All

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)

All

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

Dedicated

Customer

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

Customer-provided TLS certificates

BYOC and BYOK8s

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.

Platform health monitoring

All

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

All

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 Section 12.

Platform logs (excluding SDK logs)

All

Akka

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

Akka region platform telemetry

All

Akka

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

Application monitoring

All

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

Dedicated

Akka

Teleport bridges the Federation Plane to the private Kubernetes API servers. In Dedicated both ends of the bridge sit in infrastructure Akka operates, so Akka configures alerting for Teleport access.

Teleport access monitoring

BYOC and BYOK8s

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)

BYOC and BYOK8s

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

Dedicated

Akka

Akka enables cloud-native audit/security services (e.g., CloudTrail, Cloud Audit Logs, equivalents) for the dedicated account, collects and retains the logs, and investigates suspicious activity, sharing relevant findings with the customer.

Cloud-native audit logging

BYOC and BYOK8s

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.

SIEM / security monitoring

Dedicated

Akka

Akka operates SIEM and security monitoring for the dedicated cloud account and notifies the customer of relevant findings.

Cloud security posture

Dedicated

Akka

Akka owns cloud security posture management (security-service configuration and guardrails) for the dedicated account.

Application telemetry export

All

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.

Database point-in-time recovery (PITR)

Dedicated and BYOC

Akka

Akka enables continuous point-in-time recovery for the database and notifies the customer once configured.

Database point-in-time recovery (PITR)

BYOK8s

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

BYOC and BYOK8s

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)

Dedicated and BYOC

Akka

Akka uses Velero to back up stateful Kubernetes resources.

Kubernetes resource backups (Velero)

BYOK8s

Shared

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

Backup restore testing

Dedicated

Akka

Akka performs periodic restore testing against backups; results are summarized on request.

Backup restore testing

BYOC

Akka

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

Backup restore testing

BYOK8s

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 validation

Dedicated

Akka

Akka periodically validates disaster recovery for the platform it operates. Joint exercises with the customer can be arranged as agreed.

Disaster recovery exercise

BYOC and BYOK8s

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. See the disaster recovery scenario catalog for the per-scenario procedures.

Cross-region replication configuration

All

Shared

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

Multi-region failover procedure

Dedicated

Akka

Akka operates the failover tooling and runbooks. The customer is consulted before failover and informed of execution.

Multi-region failover procedure

BYOC

Akka

Akka provides tooling and runbooks for failover. The customer is consulted before failover and informed of execution.

Multi-region failover procedure

BYOK8s

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

All

Akka

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

Akka IAM integration

All

Akka

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

IAM (CLI and console)

All

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

All

Customer

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

MFA on Akka Console and CLI

All

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)

Dedicated

Akka

Akka owns account-level IAM for the dedicated cloud account where the region is installed.

Infrastructure access control and IAM (cloud account)

BYOC

Customer

Customer runs akka-bootstrap which sets up IAM for the cloud account where the region is installed.

Infrastructure access control and IAM (cloud account)

BYOK8s

Customer

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

Service accounts and keys

BYOK8s

Customer

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

Service accounts and keys (Akka-managed)

Dedicated

Akka

Akka creates and manages the service accounts, keys, and IAM bindings required for platform operation within the dedicated cloud account.

Service accounts and keys (Akka-managed)

BYOC

Akka

Akka creates and manages the service accounts, keys, and IAM bindings required for platform operation within the customer’s cloud account.

Privileged access via Teleport

All

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

All

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

Dedicated and BYOC

Akka

Akka provides access-control reports for the customer’s installation on request. Database-level audit logging available where required.

Access-control reports

BYOK8s

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.

Federation Plane disaster recovery

All

Akka

Akka operates the Federation Plane and configures its disaster recovery. If the Federation Plane is unavailable, running Akka applications continue to operate.

Support and communication channels

All

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

All

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

All

Akka

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

Maintenance notifications

All

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

All

Akka

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

Strategic steering

All

Akka

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

Executive partnership review

All

Akka

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

Onboarding

All

Shared

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

Customer portal access and training

All

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

All

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

All

Akka

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

SOC 2 Type II

All

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

All

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

All

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

All

Akka

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

Data residency

All

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)

All

Akka

Akka secures all customer data located within the Federation Plane.

Customer data security (Federation Plane tokens and projects)

All

Customer

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

GDPR / application data

All

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

All

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

All

Akka

Current subprocessor list maintained at trust.akka.io.

Customer audit log delivery

All

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

All

Akka

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

Data breach notification

All

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

All

Akka

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

End-of-life notification

All

Akka

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

Application code and dependency patching

All

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 Section 4, Infrastructure patching).

Service configuration (incl. secrets)

All

Customer

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

Integrations setup (broker, object storage, etc.)

All

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

All

Customer

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

Source code management

All

Customer

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

Service scaling limits

All

Customer

Customer controls service instance counts within configured platform limits.

Application logs

All

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

All

Customer

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

Application security logs

All

Customer

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

Service ACLs

All

Customer

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

Application IAM (JWT/JWKS)

All

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)

All

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.

AAO

Akka Automated Operations, Akka’s managed PaaS. It runs inside a cloud account Akka owns and operates (Dedicated), inside the customer’s cloud account (BYOC), or inside a Kubernetes cluster the customer provides and operates (BYOK8s).

Dedicated

Deployment model where AAO runs inside a cloud account that Akka owns and operates, the smallest customer-run surface of the three models.

BYOC

Bring Your Own Cloud, deployment model where AAO runs inside a cloud account the customer owns, and Akka provisions and operates the Kubernetes cluster inside it.

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. In Dedicated it runs inside the Akka-operated cloud account; in BYOC and BYOK8s, 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 where the Akka region is deployed: in the Akka-operated cloud account in Dedicated, in your cloud account in BYOC and BYOK8s.

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.