Shared responsibility model

Cloud account provisioning

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.

Quotas and service limits

Customer

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

Execute akka-bootstrap

Customer

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

Terraform state backend

Customer

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

Akka permissions

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.

Billing

Customer

Customer owns and operates the account and pays the bill.

Private connectivity pattern selection

Customer

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

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.

DNS records

Customer

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

Platform bootstrapping

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.

Federation via Teleport

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

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.

Infrastructure patching and vulnerability management

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.

Kubernetes and database upgrades

Akka

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

Releases (runtime, region machinery, Federation Plane)

Akka

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

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.

Scalability planning

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

Akka

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

Region decommission

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.

Feature requests

Customer

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

Encryption in transit and at rest

Akka

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

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.

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

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.

Database point-in-time recovery (PITR)

Akka

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

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)

Akka

Akka uses Velero to back up stateful Kubernetes resources.

Backup restore testing

Akka

Akka performs 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

Akka

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

RTO/RPO commitments

Akka

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

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 runs akka-bootstrap which sets up IAM for the cloud account where the region is installed.

Service accounts and keys (Akka-managed)

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

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 for the customer’s installation on request. Database-level audit logging available where required.

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.

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

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.

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

AAO

Akka Automated Operations, Akka’s managed PaaS that runs inside the customer’s cloud account.

BYOC

Bring Your Own Cloud, deployment model where AAO runs inside the customer’s cloud account.

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.