Shared responsibility model

Cloud account provisioning

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.

Quotas and service limits

Akka

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

Akka permissions

Akka

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

Dedicated account

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

Akka

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

Private connectivity

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.

Ingress/egress

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.

CIDR allocation

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.

VPC peering / hub-and-spoke

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.

IP allowlist on NAT and load balancers

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.

DNS records

Akka

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

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

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.

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

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.

Cloud-native audit logging

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.

SIEM / security monitoring

Akka

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

Cloud security posture

Akka

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

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.

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.

Disaster recovery validation

Akka

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

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 operates the failover tooling and runbooks. 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)

Akka

Akka owns account-level IAM for the dedicated 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 dedicated 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.

Dedicated 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. In Dedicated it runs inside a cloud account that Akka owns and operates.

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.

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.

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 Dedicated it sits in the Akka-operated cloud account.

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.