SaaS design levers for sovereignty on AWS

Encryption key management

This lever gives customers confidence that their data is inaccessible without their consent. Encryption is a powerful sovereignty lever that’s often overlooked.

There are three main options for data encryption on AWS, each providing incremental control:

• AWS managed keys – AWS handles everything. This is the most streamlined option with zero operational overhead. Includes server-side encryption with Amazon Simple Storage Service (Amazon S3) managed keys (SSE-S3) (fully transparent, no config) and server-side encryption with AWS Key Management Service (AWS KMS) keys (SSE-KMS) that are managed by AWS (adds audit logging). Neither the provider nor tenant controls the key.
• SaaS provider-managed keys – The SaaS provider creates and controls KMS keys in their own AWS account. Can be shared across tenants or can be one key per tenant. The per-tenant approach enables crypto-shredding (deleting the key makes data unrecoverable). The tenant can’t revoke independently.
• Tenant-managed keys – The tenant controls the key and can revoke the provider’s access at any time. Options range from least to most control: tenant KMS key with AWS generated key material and cross-account access, bring your own key (BYOK) where the tenant imports their own key material into AWS KMS, AWS CloudHSM with dedicated single-tenant HSMs, AWS External Key Store (XKS) where the key material doesn’t enter AWS and stays in the tenant’s own key manager, and client-side encryption where the tenant encrypts before data reaches the provider.

Beyond key ownership, there are patterns that address processing-time security. AWS Nitro Enclaves with AWS KMS attestation restrict decryption to a verified enclave so the provider can process tenant data without exposing plaintext in memory. Multi-party or split-key approaches require both provider and tenant to participate in decryption so neither party can access data unilaterally. This is typically seen in regulated financial services or dual-control scenarios.

Operator access

Sovereignty requirements can extend beyond where data is stored to those who can access it. It can also extend to how the software supply chain works. For SaaS providers, operator access can be one of the most scrutinized levers by regulators and customers.

To help customers meet their requirements, SaaS providers should offer operator access models with increasing levels of access restriction:

• Shared operations team – A global team manages all tenants regardless of geography, with operators located anywhere. The default for most SaaS, sufficient when tenants have no jurisdictional access constraints.
• Geo-restricted operators – Only personnel physically located in-country or in-region can access sovereign environments. Common for European Union (EU) data residency, government workloads, or where data export restrictions apply to viewing data.
• Security-cleared personnel – Operators hold government-issued security clearances or equivalent vetting, with access requiring both clearance and location. Used for defense, intelligence, and critical national infrastructure workloads.
• Customer-managed operators – The customer provides and manages their own operations staff, and the SaaS provider relinquishes day-to-day operational access entirely. Maximum sovereignty where the customer accepts operational responsibility in exchange for full access control.

For the latter three options, SaaS providers might have to develop a handover process for software updates from global teams to respective operators.

SaaS providers should implement defense-in-depth for operator access, where each layer—AWS service control policies (SCPs), AWS resource control policies (RCPs), and Region-scoped IAM permissions—is evaluated independently, and an operator must satisfy all layers to gain access. A misconfiguration at one layer can’t bypass controls at another. By parameterizing the access model per tenant and storing the access tier as tenant metadata, a single SaaS architecture can serve tenants across the full sovereignty spectrum without requiring separate control plane deployments.

Resilience

SaaS tenants require continuity assurance: that failover and disaster recovery don’t inadvertently violate jurisdictional boundaries. A SaaS provider that replicates to an out-of-jurisdiction Region during a disruption has broken its sovereignty contract. This includes geopolitical scenarios where an entire Region might become unavailable, requiring failover to an alternative Region or service provider within the same jurisdiction.

Building on the deployment topology lever, SaaS providers must confirm both the control plane and application plane can sustain operations within sovereign boundaries:

• Multi-Availability Zone within a Region – Both the control plane and application plane should be deployed across multiple Availability Zones (AZs) for high availability. Data doesn’t leave the Region boundary. This is the standard pattern and satisfies most sovereignty requirements with no additional architecture.
• Multi-Region within a jurisdiction – Disaster recovery across Regions within the same sovereign boundary, for example eu-central-1 and eu-west-1 for EU sovereignty, in active-passive or active-active configurations. If the control plane is global, it must be designed so a Regional failure doesn’t prevent sovereign tenants from operating. Requires explicit routing logic to prevent failover to non-approved Regions. To learn more, refer to Architecting Multi-Region SaaS Solutions on AWS.
• AWS European Sovereign Cloud – An additional in-jurisdiction Region option purpose-built for sovereignty requirements, usable as a primary deployment target or failover destination within Europe.

AI sovereignty

As SaaS products embed AI for features such as chat assistants, workflow automation, and autonomous agents, sovereignty requirements extend to the AI layer. The AWS approach to AI sovereignty identifies key controls that we recommend SaaS providers offer across the sovereignty spectrum:

• Model choice and deployment location – Options range from using models through  Amazon Bedrock (including open weight models) in the Region where the tenant is deployed, cross-Region inference where jurisdictional boundaries allow, self-hosting open source models on GPU instances within a specific Region, or self-trained models where the tenant controls the training data and artifacts.
• Inference and data protection – Where customer data is involved, such as in prompts, fine-tuning, or training, it must be treated with the same sovereignty controls as the rest of the tenant’s data. Nitro backed instances confirm model inputs and outputs remain confidential. Amazon SageMaker AI allows fine-tuning within a single Region.
• AI agent governance – As AI agents take autonomous actions on behalf of tenants, they must operate within tenant-scoped permissions. Amazon Bedrock AgentCore Identity and Amazon Bedrock AgentCore Policy provide identity propagation and policy enforcement so agents can only access resources the tenant has authorized.

Putting it together: A tiered sovereignty architecture

Not every tenant needs maximum sovereignty. Smart SaaS design offers tiered sovereignty, meaning customers can self-select the level of control they need. We recommend creating multiple tiers such as standard, enhanced, and premium that are available out-of-the-box, addressing the common sovereignty requirements of customers.