Selecting an EU region on AWS or Azure determines where primary data storage resides. It does not, by default, govern where audit logs are delivered, which engineers can access the environment, or how DNS queries are resolved.

For banks operating under the Digital Operational Resilience Act (DORA), which became enforceable on 17 January 2025, the question is no longer “where is our data stored?” It is “where does our data, our access logs, our DNS traffic, and our support exposure actually go?”

The two are not the same. A bank that selects AWS eu-central-1 (Frankfurt) or Azure’s Germany West Central region correctly stores customer data on European soil. But selecting an EU region does not, by default, close the five other paths through which data or access can leave Europe — paths that regulators are now actively auditing.

What “EU Region” Actually Guarantees — and What It Does Not

An EU region on a hyperscaler is a geographic designation for primary data storage. AWS Frankfurt, Azure Germany, and similar configurations guarantee that the data objects you write — database records, files, object storage — reside on servers physically located within the European Union.

That guarantee covers one layer: data at rest in storage services. It does not automatically extend to the operational layer that surrounds that storage: the management plane that controls your infrastructure, the logs generated by every API call, the DNS resolution path used to reach your endpoints, the engineers who respond when something breaks, or the replication behavior of managed backup services. Each of these operational layers has its own data-flow logic — and unless explicitly configured, that logic does not respect regional boundaries.

For banks, this distinction has direct regulatory weight. The European Central Bank’s Guide on outsourcing cloud services, finalized in July 2025, requires banks to document not just where data resides, but the full data-transfer and access topology of their cloud arrangements. DORA Article 30 contracts must capture subcontractor locations and the notification process for any changes.

Path 1: Management Plane Operations Can Route Through the US

Cloud management planes — the control surfaces that handle IAM (Identity and Access Management), billing, configuration, and resource provisioning — are global infrastructure. When a bank’s administrator creates a new EC2 instance in Frankfurt or assigns an Azure role in Germany, that API call travels to a management endpoint. On standard AWS and Azure configurations, those management endpoints are global and may be processed on US infrastructure.

This means an administrative action taken inside the EU can generate a data record — including metadata about resources, configurations, and identities — that passes through US-located systems. For a bank managing regulated workloads, any metadata touching US infrastructure is potentially subject to the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018), which allows US authorities to demand access to data held by US companies regardless of server location.

The counter-case is real: hyperscalers have invested heavily in regionalization. AWS’s European Sovereign Cloud, launched in January 2026, is specifically designed to isolate the management plane within the EU under a legally separate German entity. But that product is distinct from — and priced at an estimated 20–30% premium above — standard EU region deployments. Banks using standard EU regions have not, by default, resolved the management plane exposure.

Path 2: Logs Are Replicated Globally Unless You Explicitly Prevent It

AWS CloudTrail — the service that logs every API call across your AWS account — is enabled on all AWS accounts by default, according to AWS’s own GDPR compliance documentation. The critical detail: when a bank creates a multi-region trail (which CloudTrail supports natively), log files are delivered to the same S3 bucket regardless of where that bucket is located. If the destination bucket is not in an EU region, audit logs describing activity on EU infrastructure leave Europe.

The same applies to Azure Monitor and Azure Activity Logs. Default configurations do not restrict log storage to the region where the monitored activity occurs.

For a bank, these logs are not incidental telemetry. CloudTrail logs capture operator identities, timestamps, resource identifiers, and IP addresses — a detailed record of who accessed what, when. Under GDPR, this is personal data when it includes employee identifiers. Under DORA Article 28 and the Register of Information requirements in Implementing Regulation (EU) 2024/2956, banks must be able to document where this data flows.

The fix is specific and requires active configuration: S3 bucket policies enforcing regional constraints, AWS Service Control Policies blocking log delivery outside approved regions, and equivalent controls in Azure Policy. Neither hyperscaler applies these restrictions by default.

Path 3: US-Based Support Engineers Can Access EU Environments

Cloud support — particularly at the higher tier levels required for production banking workloads — operates from global pools of engineers. When a bank raises a severity-1 support ticket with AWS or Azure, the first available qualified engineer responds. That engineer may be located in the United States.

Access by a US-based support engineer to an EU-regulated banking environment creates two simultaneous problems. First, it is a cross-border data transfer under GDPR Article 46, requiring a valid legal basis. Standard hyperscaler Data Processing Agreements (DPAs) typically include Standard Contractual Clauses to cover this, but those SCCs depend on the EU–US Data Privacy Framework (DPF), which cloud and legal professionals increasingly flag as politically fragile. DanubeData’s 2026 legal analysis notes that Microsoft’s own lawyers told the French Senate that their EU Data Boundary cannot neutralize CLOUD Act obligations.

Second, under DORA’s third-party oversight framework — specifically Articles 28 and 29 — banks must be able to audit who accesses their critical ICT environments. A support access event initiated from the US, handled by an engineer not subject to EU employment law, is a subcontractor relationship that must appear in the bank’s Register of Information and be governed by contractual controls.

AWS’s response to this — the European Sovereign Cloud model, in which all employees are EU residents and US staff have no technical access — illustrates what genuine isolation requires. Standard EU region customers do not receive those operational controls.

Path 4: DNS Requests May Resolve Outside the EU

DNS — the Domain Name System — is the internet’s address book, translating service names into IP addresses. In cloud environments, banks use DNS to reach internal services, API endpoints, managed databases, and control plane APIs. The routing of those DNS queries matters for data sovereignty.

AWS Route 53 and Azure DNS are global services. Resolution requests travel to the nearest available resolver node, which may be located outside the EU. For a bank querying its own internally-named services in Frankfurt, the DNS request itself — which contains service names and resolution metadata — may be processed in a US-located Route 53 node.

This is often considered a lower-risk path because DNS queries contain service names rather than financial data. However, for a bank under DORA’s ICT risk management requirements, any data flow that exits the EU without documentation is a potential compliance gap. More practically, DNS metadata reveals the internal architecture of a bank’s cloud environment — which services exist, how frequently they are called, which are mission-critical.

The resolution is to deploy private DNS resolvers within the EU using AWS Route 53 Resolver or Azure Private DNS Zones, configured with explicit forwarding rules that prevent external resolution. This requires deliberate architecture, not default configuration.

Path 5: Backup Replication Is Cross-Region by Default in Many Managed Services

Managed cloud services — RDS (Relational Database Service), Azure SQL Database, managed Kubernetes, DynamoDB — often include automatic backup and replication features. The default replication targets are not always confined to the EU.

AWS S3 Cross-Region Replication is available for buckets in any region combination and does not restrict replication to EU-only targets. RDS automated backups replicate within the same region by default — but manual snapshots can be copied to any region unless bucket policies explicitly prevent it. Azure’s geo-redundant storage (GRS) options, by default, replicate to a paired region — but the EU region pairs do not always fall within the EU. Sweden Central pairs with Sweden North (both EU), but Germany West Central pairs with Germany North, and older Azure regions have paired non-EU options in configurations that require verification.

For a bank, backup data carries the same regulatory weight as production data. A payment record in an automated backup that replicates to a US-located S3 bucket is a GDPR transfer without adequate safeguards, regardless of where the primary database sits. DORA’s subcontractor documentation requirements under Article 30 require that backup and replication destinations be named and located — a control that demands active inventory of where each managed service stores its secondary copies.

What This Means for Banks Operating Under DORA in 2026

The Digital Operational Resilience Act entered full enforcement on 17 January 2025. According to ECB supervisory data, the ESAs designated 19 Critical ICT Third-Party Providers in November 2025, including AWS EMEA Sarl, Google Cloud EMEA Limited, and Microsoft Ireland Operations Limited — bringing the hyperscalers under direct DORA oversight. ECB supervisors are actively running on-site inspections on DORA compliance, and the SSM Priorities 2025–27 specifically include cloud concentration risk reviews and outsourcing framework assessments.

In this environment, the five paths described above are not theoretical edge cases. They are the questions ECB inspectors ask. Banks that cannot answer where their CloudTrail logs go, which engineer accessed their environment under a support ticket, and where their RDS snapshots are stored are carrying a demonstrable compliance gap — not a documentation gap, but an operational one.

The path forward is not necessarily to abandon major cloud providers. For many workloads, AWS and Azure EU regions with correctly applied controls deliver compliant architectures. However, “correctly applied” requires explicit configuration for each of the five paths: service control policies on log routing, contractual limits on support access geography, private DNS resolver deployment, and backup destination enforcement. None of these are defaults.

How ASEE Approaches This for Banking Clients

ASEE Cloud operates entirely within EU jurisdiction, with all infrastructure, operational staff, and subcontractors located in the EU. This eliminates the extraterritorial exposure that US-headquartered providers cannot fully resolve through configuration alone, because the core legal risk — US entity ownership subject to the CLOUD Act — is architectural, not configurable.

Having supported financial institutions across 55+ countries and provided managed cloud services to banks navigating DORA, EBA outsourcing guidelines, and ECB supervisory expectations, the five paths above are ones we see in implementation, not just in regulatory text. The banks that close these gaps most efficiently are the ones that treat cloud region selection as the beginning of a data-flow architecture exercise, not its conclusion.

Looking Ahead: When “EU Region” Will No Longer Be Sufficient as a Claim

The trajectory from 2025 to 2027 is toward tighter, not looser, enforcement of data localization for regulated financial entities. The European Commission’s June 2026 European Technological Sovereignty Package signals that data residency requirements will expand beyond storage to processing and operational access. The NIS2 Directive amendments proposed on 20 January 2026 are expected to tighten ICT supply chain requirements further, with fines for essential entities reaching €10 million or 2% of global annual turnover.

By Q1 2027, banks that have not resolved the five operational data-flow paths will face inspection findings — not hypothetical ones, but findings based on the Register of Information and the ICT third-party contracts that DORA already requires. The transition from “we use an EU region” to “we can document where every byte of operational data flows and who can access it” is measured in configuration hours, not years.

What Happens If Banks Don’t Comply: Penalties and Timeline

DORA’s penalty framework became enforceable on 17 January 2025 across all 27 EU Member States. The informal tolerance period that characterised most of 2025 is now over. National competent authorities (NCAs) are conducting active enforcement reviews in 2026, cross-checking Register of Information data automatically and, according to supervisory sources, issuing the first compulsion payments.

The financial penalty structure operates on two levels. For financial entities — banks, investment firms, insurers, and payment institutions — the maximum administrative fine is 2% of total annual worldwide turnover or €10 million, whichever is higher. Individual liability extends to senior management: responsible persons, including board members and CISOs, can face personal fines of up to €1 million for compliance failures directly attributable to their oversight. Beyond fines, NCAs hold additional powers: cease and desist orders requiring immediate remediation, temporary restrictions on ICT services, public disclosure of the institution’s identity and the nature of the breach, and in severe cases, suspension of operations.

For Critical ICT Third-Party Providers (CTPPs) — the 19 designated providers including AWS EMEA Sarl and Microsoft Ireland Operations Limited — the penalty framework is more stringent still: daily penalty payments of up to 1% of average daily global turnover for continued non-compliance, for up to six months, plus fixed fines reaching €5 million. The Lead Overseer can also publish non-compliance recommendations, which trigger contractual consequences as financial entities are obligated to reassess those provider relationships.

For context, GDPR fines operate in parallel and carry higher ceilings: up to 4% of annual worldwide turnover or €20 million for serious infringements. According to EDPB data, the median GDPR fine on financial services entities in 2025 was €890,000. A bank that fails to address the five data-flow paths described in this post faces the possibility of simultaneous DORA and GDPR enforcement action, since the same control gaps — audit logs leaving the EU, US-based access to EU personal data, backup replication to third countries — engage both regulatory frameworks at once.

On the enforcement timeline: the first administrative fines under DORA are expected in the second half of 2026, targeting entities with no demonstrable compliance effort. The second annual Register of Information submission cycle (due March 2026) is a key enforcement trigger — entities that submitted incomplete or inaccurate data in the first cycle are under particular scrutiny. By 2027–2028, enforcement is expected to follow patterns established under GDPR, where cumulative EU-wide fines exceeded €4.5 billion by 2025. The critical distinction from GDPR is that DORA enforcement is faster-moving: it operates through supervisory integration with the ECB’s SREP cycle, meaning compliance gaps discovered in annual reviews translate directly into capital and operational requirements, not just eventual fines.

For banks specifically, the non-financial consequences may be more immediately damaging than the penalties themselves. Public disclosure of a breach under DORA’s transparency requirements — naming the institution and the nature of the failure — affects counterparty confidence, correspondent banking relationships, and retail customer trust in ways that are difficult to quantify and impossible to reverse quickly. A bank that receives a DORA finding on cloud data-flow controls in late 2026 faces a reputational event as well as a remediation programme, the latter of which, when conducted under supervisory direction rather than self-initiated, is consistently more disruptive and more expensive than proactive compliance work.

The Cost of Sovereign Alternatives: What Banks Should Expect

Selecting an EU region on AWS or Azure is cheaper than the genuinely sovereign alternatives — and that price gap is measurable, though it varies by provider and by how completely the bank needs to close the five operational exposure paths.

The most direct comparison is AWS. Independent pricing analysis conducted at the January 2026 launch of the AWS European Sovereign Cloud (ESC) found a consistent premium of approximately 15–17% above standard EU regions (such as eu-central-1 in Frankfurt) across core compute, storage, database, and serverless services. One technical analysis found roughly a 17% uplift compared to Frankfurt pricing, with no Free Tier available at launch. Comparable analysis from another cloud consultancy put the figure at 10–15% across EC2, S3, RDS, and Lambda. For AWS GovCloud — the US equivalent sovereign partition — the established premium is approximately 20%. The ESC sits below that level but above standard commercial pricing, and the gap is structural: the additional cost reflects the isolated control plane, the EU-resident-only operations model, and the separate legal entity structure that together provide the sovereignty guarantee.

There are also trade-offs beyond price. The AWS ESC launched with approximately 90 services compared to 240+ available in commercial EU regions. Key gaps at launch include CloudFront (planned late 2026), AWS Identity Center (planned Q1 2026), GPU instances, most Amazon Bedrock models (only Amazon Nova Lite and Nova Pro are available; Claude, Llama, and Mistral are absent), and Shield Advanced. Banks that depend on these services face a choice between architectural workarounds or a hybrid model that keeps non-sensitive workloads in the standard partition — which reintroduces some of the operational complexity the sovereign migration was meant to resolve.

On the Microsoft Azure side, the picture is more differentiated. Microsoft’s Sovereign Public Cloud — which keeps data and operations within EU borders under European personnel — carries no additional cost for existing Azure customers as of the full implementation of the EU Data Boundary in February 2025. However, it does not achieve the same level of structural isolation as the AWS ESC: the control plane remains on Microsoft’s global infrastructure, and Microsoft’s own legal team confirmed to the French Senate in June 2025 that it cannot guarantee EU data will never be subject to US government orders. For banks that need stronger operational isolation, the national partner cloud options — Bleu (France, operated by Orange and Capgemini) and Delos Cloud (Germany, operated by an SAP subsidiary) — offer that isolation but at a significantly higher cost. Analyst estimates cited in independent cloud sovereignty research put the premium for national partner cloud models at 20–40% above standard hyperscale regions, reflecting the additional operational overhead of a separately governed, partner-run environment.

For banks considering European cloud providers as an alternative to US hyperscalers entirely — OVHcloud, Hetzner, Scaleway, and others — the compute pricing can be substantially lower. A February 2026 benchmark found one European provider delivering more than 14 times the compute performance per euro than AWS on-demand, combining higher benchmark scores with lower headline prices. These providers operate entirely outside the US CLOUD Act’s jurisdiction, which eliminates the extraterritorial exposure at the entity level rather than attempting to manage it through configuration or contractual overlay. The trade-off is service breadth: no European provider currently matches the depth of managed services available on AWS or Azure, and for banks with significant existing investment in AWS-native or Azure-native tooling, migration costs can offset compute savings.

The cost calculus for banks under DORA is therefore not simply “sovereign cloud costs more.” It is: what is the cost of closing each of the five operational paths on the current platform, what is the residual risk that cannot be eliminated through configuration on a US-headquartered provider, and what is the expected cost of a regulatory finding or enforcement action against that residual risk. For most banks, a phased approach — closing the configurable gaps immediately and evaluating sovereign migration for the highest-sensitivity workloads — is more operationally realistic than a full migration. The EU Data Act eliminates cloud switching fees by January 2027, which reduces the future cost of migration decisions taken today.

Key Takeaways

1. Selecting an AWS or Azure EU region guarantees primary data storage within the EU but does not automatically restrict five critical operational data flows: management plane routing, audit log replication, support engineer access, DNS resolution, and backup replication.
2. The US CLOUD Act (2018) applies to AWS, Azure, and Google Cloud regardless of server location, because jurisdiction follows corporate headquarters, not data center geography — a risk that EU Data Boundary commitments reduce but do not eliminate, as Microsoft’s lawyers confirmed to the French Senate in testimony.
3. DORA Article 30 contracts and the Register of Information under Implementing Regulation (EU) 2024/2956 require banks to document not just data storage location but the full operational topology of cloud arrangements, including subcontractor locations and support access geography.
4. The ECB finalized its Guide on outsourcing cloud services in July 2025 and is actively conducting on-site inspections under the SSM Priorities 2025–27 framework, meaning banks that cannot account for where their CloudTrail logs, backup snapshots, and DNS queries go are exposed to findings in the current supervisory cycle.

FAQ

What does “EU region” mean on AWS or Azure?

An EU region on AWS or Azure means that the primary data storage services — databases, object storage, compute instances — are located on servers physically within the European Union. It guarantees data residency for storage but does not, by default, restrict management plane operations, audit logs, support engineer access, DNS resolution traffic, or backup replication to EU-only destinations.

Does using AWS Frankfurt or Azure Germany make a bank GDPR compliant?

Using an EU region is a necessary but not sufficient condition for GDPR compliance in a banking context. GDPR compliance requires that all processing — including log storage, DNS resolution, and support access — either stays within the EU or is covered by a valid transfer mechanism such as Standard Contractual Clauses. Standard EU region deployments transfer some operational data outside the EU unless explicitly configured to prevent it.

What is the CLOUD Act and why does it matter for European banks?

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) allows US government authorities to compel US companies — including AWS, Microsoft, and Google — to produce customer data regardless of where the data is stored. A bank storing data in AWS Frankfurt is using a service operated by a US parent company, which means the CLOUD Act exposure exists at the entity level, not the server location level.

What is the difference between a standard AWS EU region and the AWS European Sovereign Cloud?

A standard AWS EU region stores data in Europe but is operated by AWS’s global organization, with US-based management infrastructure and US-based support engineers who may access the environment. The AWS European Sovereign Cloud, launched in January 2026, is operated by a legally separate German entity with EU-resident staff, isolated management infrastructure, and no US-staff access — resolving the operational exposure that standard EU regions leave open, at an estimated 20–30% cost premium.

What does DORA require banks to document about cloud data flows?

DORA Article 30 requires that ICT outsourcing contracts with cloud providers include documentation of subcontractor locations, data storage and processing locations, and notification procedures for any changes to the supply chain. The Register of Information under Implementing Regulation (EU) 2024/2956 must capture these details and be submitted annually to national competent authorities and available for ECB inspection at any time.

Can audit logs (CloudTrail, Azure Monitor) leave the EU by default?

Yes. AWS CloudTrail is enabled by default on all AWS accounts and supports multi-region trail delivery to a single S3 bucket. If that bucket is not constrained by a regional bucket policy and a Service Control Policy blocking cross-region delivery, logs from EU infrastructure can flow to buckets located outside the EU. Azure Monitor has equivalent behavior. Restricting log routing to EU-only destinations requires explicit policy configuration.

How does DNS routing create a data sovereignty risk for banks?

DNS (Domain Name System) requests in cloud environments are typically resolved by the cloud provider’s global resolver network. For AWS Route 53 and Azure DNS, queries may be answered by resolver nodes located outside the EU, meaning service name resolution metadata — which reveals internal architecture details — can be processed in the US. Private DNS resolvers deployed within EU VPCs and configured with explicit forwarding rules eliminate this exposure.

What happens if a US support engineer accesses a bank’s EU cloud environment?

Access by a US-based support engineer constitutes a cross-border data transfer under GDPR Article 46 and a subcontractor relationship that must be documented in the bank’s DORA Register of Information. The transfer requires a valid legal basis (typically SCCs under the EU–US Data Privacy Framework). Under DORA Articles 28–29, the bank must be able to audit this access and have contractual controls governing the engineer’s access scope and obligations.

Sources

• AWS Security Blog — AWS European Sovereign Cloud achieves first compliance milestone: SOC 2 and C5 reports plus seven ISO certifications
• ASEE — DORA Cloud Provider Requirements: How EU Managed Cloud Reduces the Evidence Burden
• DanubeData — The US CLOUD Act Explained: Why European Businesses Need Non-US Cloud Alternatives (2026)
• Digital Operational Resilience Act — ECB finalises Guide on outsourcing cloud services, July 2025
• IT Pro — What the new AWS European Sovereign Cloud means for enterprises
• AWS Documentation — Receiving CloudTrail log files from multiple Regions
• Orbiq — DORA Compliance: Complete Guide
• DORA GRC — DORA Penalties & Fines: What Non-Compliance Costs
• Legiscope — DORA Penalties and Enforcement: What to Expect
• Regulation-DORA.eu — DORA in 2026: The Grace Period Is Over
• Devoteam — AWS European Sovereign Cloud: Architecture, Costs and CIO Recommendations
• Cloudvisor — Sovereignty as a Service: The AWS European Sovereign Cloud is Live (pricing analysis)
• StormIT — AWS EUSC Pricing: Higher Costs, New Challenges
• Xebia — Digital Sovereignty In Microsoft Azure: Why It Matters
• From Europe With Love — 7 European Cloud Providers vs AWS: Real Pricing (2026)