GDPR-Compliant AWS Architecture: Keeping Data in the EU

Sooner or later, every managing director asks: is our data on AWS GDPR-compliant? The usual answer, "we are in Frankfurt", sounds reassuring and falls short. Where the data sits is only half the question. The other half is who can legally compel access, and that is exactly where it gets complicated in 2026.

This article separates the two halves cleanly, places the legal situation in context, shows three tiers of EU-ready on AWS, and provides a checklist a team can use to review its own setup. One thing up front: this is an architecture and decision guide, not a legal opinion. The legal assessment ultimately belongs with a lawyer specialized in IT law. The architecture creates the foundation, the contract makes it hold up.

As of July 2026, region eu-central-1 (Frankfurt) as reference.

Data Residency Is Not Data Sovereignty

The most important distinction of the whole topic sits in two words that are often used interchangeably, even though they mean different things.

Data residency is where the data physically sits. eu-central-1 keeps it in Frankfurt, eu-west-1 in Ireland. That is the simple, technical half, and it is settled by choosing an EU region.

Data sovereignty is who can legally compel access, regardless of the physical location. This is where the CLOUD Act comes in. A US-controlled provider can be compelled under US law to hand over data, even if that data sits in the EU and the access contradicts EU law. The data is in Frankfurt, the legal reach stays American.

The consequence is uncomfortable: an EU region solves residency, not automatically sovereignty. Confuse the two, and you think you are safer than you are. That is no cause for panic, but it is the starting point for any honest assessment.

The Legal Situation in 2026

Schrems II and the End of Privacy Shield

In 2020, the Court of Justice of the European Union struck down Privacy Shield in the Schrems II ruling, the prior basis for transatlantic data transfers. The reason: US surveillance law, specifically Section 702 FISA and Executive Order 12333, grants US intelligence agencies access to data held by US companies that goes beyond what is proportionate under EU law. That is structurally incompatible with the guarantees of the GDPR.

Data Privacy Framework and Schrems III

In July 2023, the European Commission adopted the adequacy decision for the EU-US Data Privacy Framework, the successor to Privacy Shield. The problem: it is already back in court, on substantially the same grounds. The Schrems III case is before the CJEU, and a decision is expected in late 2026. The underlying conflict is unresolved in 2026.

Standard Contractual Clauses remain the valid transfer mechanism, and AWS customers can continue to rely on them for data transfers outside the EEA. But the European Data Protection Board and the European Commission assume that data held by US-controlled providers carries a residual risk that contractual clauses alone cannot eliminate. The honest assessment for 2026: anyone relying solely on the framework is building on a position the European judiciary has already rejected once and is being asked to reject again. It is a reason to choose your risk position deliberately rather than ignore it.

Three Tiers of EU-Ready on AWS

In practice there is no "compliant or not", but three tiers that differ in effort and residual risk.

Tier 1: EU Region Plus Basics

An EU region like eu-central-1, encryption at rest and in transit, Standard Contractual Clauses, and a signed data processing agreement. For many mid-sized companies this is the pragmatic choice, with a deliberately accepted CLOUD Act residual risk. The word "deliberately" matters: the tier is legitimate as long as the decision is made and documented, not accidental.

Tier 2: Plus Hard Controls

The same basis, plus customer-managed KMS keys instead of the AWS-managed ones, blocked cross-region replication, EU-only guardrails via service control policy, and a real data classification. This does not eliminate the legal residual risk, but it considerably reduces the practical attack surface, because the customer controls the keys and no data leaves the EU unnoticed.

Tier 3: European Sovereign Cloud

Since January 15, 2026, the AWS European Sovereign Cloud has been generally available in Brandenburg. It is physically and logically separate from the existing AWS regions and operated exclusively by EU-resident staff. It has its own partition (aws-eusc), its own region (eusc-de-east-1), its own IAM, its own billing, and its own Route 53 name servers, all within the EU. It is operated through an EU legal entity under German law. That is more than data residency: operational sovereignty with technical controls meant to prevent any access from outside the EU.

The honest assessment: most mid-sized companies are right with tier 1 or 2. Tier 3 is for health, public sector, finance, and comparably regulated areas, or when a customer or regulator demands demonstrable sovereignty. And not every service is immediately available in the Sovereign Cloud, which belongs in the check before a decision.

Practical Architecture to Keep Data in the EU

Region Pinning and Guardrails

The first and most important step is mundane and still often skipped: allow only EU regions and block all others via service control policy. That prevents someone from accidentally deploying into us-east-1, the default region of many tools and tutorials. An SCP that does exactly that:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonEuRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "route53:*",
        "cloudfront:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["eu-central-1", "eu-west-1"]
        }
      }
    }
  ]
}

The excluded services are global and have no region concept in the classic sense. Exactly these global services, IAM, CloudFront, and Route 53, belong in the review: with CloudFront, for example, you have to know where content is cached and, if needed, restrict the edge locations.

Encryption With Your Own Keys

Whoever controls the key controls the access. That is why sensitive data belongs under customer-managed KMS keys, not under the ones AWS manages by default. The key policy sets who may use the key, and thus who can read the data at all:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableRootAccount",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowAppRole",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:role/laravel-task-role" },
      "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
      "Resource": "*"
    }
  ]
}

On top comes blocking cross-region replication into non-EU regions, also enforced via SCP, a data classification that knows and tags personal data, and CloudTrail with logs in an EU region, so the audit log of all things does not break residency.

DPA and Shared Responsibility

The technology is one half, the contract the other. AWS offers a GDPR-compliant data processing agreement, the DPA. In it, the customer is the controller and AWS is the processor. This split of roles matters, because it draws responsibility clearly.

The shared responsibility model means concretely: AWS secures the infrastructure, the customer is responsible for data, configuration, and access. A publicly reachable S3 bucket with personal data is the customer's problem, not AWS's. Most GDPR incidents in the cloud are misconfigurations on the customer side, not failures of the provider.

What belongs with a lawyer: the DPA itself, the transfer impact assessment, and the wording in the privacy policy, where AWS must be named as processor with its sub-processors. The architecture can be as clean as it likes, without the contract the legal foundation is missing.

The Compliance Checklist

This checklist covers architecture, encryption, contract, and governance. A team can walk through it and ends up with a list of concrete gaps.

That is the free version. The detailed one with a reference architecture, an IaC starter, and a DPA checklist is what I am building as a GDPR pack (more on that at the end).

When the Standard Region Is Enough, When the Sovereign Cloud

Four questions settle the tier before you invest effort. Do we process special categories of personal data, such as health or biometrics? Are we subject to industry-specific regulation? Does a customer or regulator demand demonstrable sovereignty? And how high is our tolerance for the CLOUD Act residual risk?

What Management Should Ask

You do not need to be an architect to ask the right questions. In which region does our personal data sit? Who controls the encryption keys? Do we have a signed DPA, and do we know the sub-processors? If the answers are uncertain, that is an action item, not a detail.

The honest risk question comes at the end: if a regulator asks tomorrow, can we demonstrate that personal data is processed in compliance with the GDPR? GDPR compliance is a deliberate decision about accepted risk, carried jointly by management and engineering, not a checkbox a team ticks off alone.

Anti-Patterns

"Frankfurt equals GDPR-safe". Ignores the sovereignty half. The region solves residency, not the CLOUD Act.

Default region us-east-1. Personal data ends up outside the EU, often unnoticed, because it is the default region of many tools.

No region guardrails. A deploy into the wrong region happens eventually, and without an SCP nobody notices.

AWS-managed keys for sensitive data. No control lever over access. Sensitive data belongs under customer-managed keys.

Cross-region replication into the US. Undoes residency again, often set up as a convenient backup strategy and forgotten.

No DPA. The legal foundation is missing, regardless of how clean the technology is.

Compliance as a purely technical project. Without contract and risk assessment it stays piecemeal. It is architecture, contract, and decision together.

Ignoring sub-processors. The privacy policy must name them, that is not optional.

Conclusion

GDPR compliance on AWS is the intersection of architecture, contract, and an honest risk assessment, not the choice of a region. Data residency is the simple half and quickly solved with an EU region and guardrails. Data sovereignty is the hard half, and in 2026, with the European Sovereign Cloud, cleanly addressable for the first time, for those who need it.

Most mid-sized companies are well positioned with tier 1 or 2 plus a deliberate risk decision. Those who process regulated or especially sensitive data evaluate tier 3. The decisive step is not the technology alone, but the deliberate decision that management and engineering make together and document. That is what turns "we are in Frankfurt" into a position that holds up.

Do you process personal data on AWS and are not sure whether architecture and contract fit together? Contact me for a GDPR and architecture audit that reviews region, encryption, guardrails, and contractual situation in a few days. I align the legal assessment with your lawyer and bring the architecture.

I am currently building an EU/GDPR-Ready AWS Architecture Pack, a reference architecture with an IaC starter and a DPA checklist. If you want to know early, you can get on the list without obligation. No newsletter barrage, just one message when it is ready.