Presenters

Source

Cloud Compliance in Europe: Navigating the Sovereignty Maze (AWS Outposts vs. European Sovereign Cloud) 🌐💡

Hey there, tech enthusiasts! 👋 Dmytro Hlotenko, Senior Cloud Operations Engineer at Sage Gamai, AWS Community Builder, and AWS User Group Leader in Vienna, recently took us on an illuminating journey through the complex world of cloud compliance. With 6 AWS certifications and a deep understanding of both telecommunications and business management, Dmytro shared invaluable insights into keeping your cloud operations compliant without abandoning your tech stack.

Let’s dive into how engineering teams can navigate the tightrope of cloud compliance, especially with the ever-evolving landscape in Europe!

☁️ The Cloud Compliance Tightrope: Pressures on Engineering Teams

Modern engineering teams face an unprecedented convergence of pressures when it comes to cloud adoption and compliance. It’s a tricky situation, with forces pushing from all sides:

  • Emotional Pressure: Customers naturally want to know where their data resides and how it’s accessed. A general skepticism and lack of trust in public clouds, often fueled by fear-mongering and confusing marketing, can lead to emotional decisions.
  • Political & Legal Pressure: Regulations like the Cloud Act, FISA 702, GDPR, DORA, and NIS2 create a complex web of requirements. Conflicting analyses, even within the EU, add to the confusion.
  • Technical Pressure: A lack of skilled personnel for niche stacks, difficulties in managing diverse environments, and the sheer challenge of maintaining growth and innovation while addressing these compliance hurdles weigh heavily on teams.

The goal? To ship amazing products while staying compliant. But what happens when companies make multi-million dollar migrations out of public clouds, replacing robust managed services with open-source alternatives that often lack R&D budgets? This can lead to a loss of velocity, increased costs, and a hit to time-to-market.

💡 Demystifying the Hype: Cloud Act, FISA 702, and EU Regulations

Let’s cut through the noise and clarify some common misconceptions:

Cloud Act & FISA 702: Understanding the Real Risk 🛡️

Many believe that simply placing servers in Europe makes them immune to US jurisdiction. This is a fundamental misunderstanding. The Cloud Act targets service providers and legal entities managing the environment, not just the location of your servers or the origin of your software. If a US entity has operational control over your environment (e.g., manages admin keys, telemetry access), you are subject to US jurisdiction, regardless of physical data location.

Similarly, FISA 702 permits data gathering on non-US citizens without a warrant and recently expanded its definition of electronic communication service providers.

However, Dmytro highlights a crucial point: the theoretical risk of these acts affecting your data is statistically low. AWS data shows the last Cloud Act/FISA 702 warrant was issued in July 2020. Don’t redesign your entire IT infrastructure based on low probability risks. The goal is to minimize risk, not eliminate all possibilities.

EU Regulations: DORA & NIS2 Don’t Ban, They Mandate Maturity! 🇪🇺

There’s a widespread misconception that new EU regulations like DORA and NIS2 ban the use of AWS, Azure, or GCP. This is simply not true.

  • DORA (Digital Operational Resilience Act): Applicable to financial services, DORA focuses on concentration risk, exit strategies, and ensuring operational resilience against IT disruptions. It demands that you manage your risks and have a clear exit strategy if a provider fails.
  • NIS2 (Network and Information Systems Directive 2): This expanded cybersecurity directive for critical entities emphasizes supply chain security and jurisdiction analysis.

Neither of these regulations explicitly states that you cannot use major cloud providers. Instead, they mandate that you stop doing it blindly. You need a Transfer Impact Assessment (TIA), a documented access strategy, and strong governance. The focus is on operational maturity and understanding your risks, not on abandoning robust, secure platforms. Forcing a bank to use a less mature, less secure cloud solution would increase systemic risk, which is the opposite of what these regulations intend.

🎯 The “Who Controls What?” Question: Operational Control is King

This is the core subject of the discussion: jurisdiction attaches to the entity, not to the data.

The most critical question you must ask any vendor or service provider is: “Who operates the control plane?”

  • Operational Control, Not Physical Location: If a US-based entity holds root credentials, manages the control plane, or has administrative access to your environment, you are subject to US jurisdiction, even if your data physically resides in a European data center.
  • Managed Services Trap: Even “managed services” running on your own hardware or with “bring your own key” solutions can expose you if the managing entity is under US jurisdiction. This can be even worse than a public cloud, as you might falsely believe you’re fully sovereign.

💸 The Siren Song of Self-Hosting: Hidden Costs and Lost Agility

Many companies consider expensive migrations out of public clouds or building their own “sovereign” solutions. However, Dmytro highlights significant challenges and tradeoffs:

  • Human Factor & Operational Costs: Spreadsheets often miss the true cost of human resources. Hiring senior DevOps engineers for obscure, undocumented stacks is incredibly difficult. You risk losing top talent and spending R&D budgets on infrastructure maintenance instead of product innovation.
  • Reduced Velocity & Time-to-Market: Operating different environments, upskilling teams, and managing complex multi-vendor setups destroys velocity and hits your time-to-market.
  • Loss of Cloud Benefits: You lose the dynamic scalability, elasticity, and cost savings that public clouds offer. Instead, you face excessive planning, double payments, and the burden of managing infrastructure yourself.
  • Vendor Management Nightmare: With multiple vendors for different components (e.g., seven SLAs, seven escalation paths), incident management becomes a high-stress, complex orchestration challenge.

🚀 Enter the European Sovereign Cloud (ESC): A Game Changer?

AWS made a significant move to address European sovereignty concerns with the launch of the European Sovereign Cloud (ESC) in January 2026. This is not just another region; it’s a completely new legal entity, operated entirely by Europeans, with all data and metadata (including CloudTrail, IAM) staying within the Brandenburg region.

Key Features & Benefits:

  • Partition as Perimeter: This is a fundamental shift. Unlike the global AWS partition where some data might flow to US-east-1, everything in ESC stays within Europe.
  • Compliance Fortification: Certified for DORA and by German authorities, ESC directly addresses data placement and processing concerns for German companies and provides significant fortification for GDPR, DORA, and NIS2 compliance across the EU.
  • Familiar Technology: It leverages familiar AWS technology, allowing teams to maintain their existing skillsets and tooling while meeting strict compliance requirements.

Remaining Challenges & Tradeoffs:

While a huge step forward, ESC is not a 100% solution for every single, extreme scenario. Some authorities (e.g., BSI) still require even more technical separation from US management. Indirect exposure, though significantly reduced and much harder to achieve, is still theoretically possible. However, for 90% of companies, ESC will be more than sufficient.

🚢 The Outpost Dilemma: Physical Presence vs. True Sovereignty

AWS Outposts, initially designed for low-latency edge compute (e.g., real-time data processing, telecom providers), often get mistakenly considered for compliance.

Outposts Benefits:

  • Physical Data Residency: Outposts perfectly solve the physical data residency requirement. If customers need to know their server is in this specific rack, in this building, in this city, Outposts deliver.
  • Familiar AWS Experience: You get familiar AWS hardware, APIs, and services on-premises.

Outposts Drawbacks & Tradeoffs:

  • No Operational Sovereignty: The biggest hurdle is that Outposts function as an extension of an AWS region. Their control plane metadata resides in the parent region (e.g., Frankfurt), leading to direct Cloud Act exposure identical to a standard region.
  • Limited Services: Outposts come with a stripped-down set of services. You won’t find Lambda, Glue, SageMaker, Redshift, Transit Gateways, ALB in EKS, or full-featured S3. This often leaves you with “plain compute that looks like AWS but in reality looks even worse than the regular data center.”
  • Performance Caveats: Benchmarking revealed that while vCPUs on AWS can perform well, the underlying core/thread configuration can impact performance, especially for certain applications. Storage IOPS are also significantly limited (e.g., 16,000 IOPS compared to 200-300k on SAN-attached VMware).
  • High Operational Overhead: Outposts are power-hungry, require specific cooling, redundant uplinks, external firewalls, and significant preparatory work from your data center and team. This effectively means you’re building a data center yourself using AWS APIs, losing the benefits of managed services.
  • Backup Trap: Standard AWS backup for Outposts pushes EBS snapshots to the parent region (US jurisdiction), unless you have expensive S3 storage on the Outpost itself. This complicates compliance and forces reliance on external, non-AWS backup solutions, increasing management complexity and requiring full environment rebuilds for recovery.
  • DR Challenges: Achieving a 3-2-1 backup strategy or robust DR means doubling your Outpost infrastructure and costs, or accepting partial resiliency and awful recovery times.

🌳 Navigating Your Cloud Sovereignty Journey: A Decision Tree

There’s no universal answer, but Dmytro provides a helpful decision tree to guide your choices:

  1. How strict is your operational security?
    • Not that strict? Standard AWS/Azure/GCP region might be sufficient.
    • Strict? Proceed to the next question.
  2. Must data physically stay in your country?
    • No? AWS European Sovereign Cloud (ESC) is likely sufficient.
    • Yes? Proceed.
  3. Is it acceptable to stay in Germany (or a unified EU region)?
    • Yes? ESC, or ESC + Outposts (accepting Outposts’ limitations).
    • No? Consider an exit strategy, bare metal, or a truly local sovereign provider.
  4. Does regulation force a specific local physical presence?
    • Yes? Outposts in conjunction with ESC might be an option, but be aware of the significant risks and overhead.
    • No? Stick with ESC.

The key is to keep your architecture adaptable with cloud-agnostic tools. Understand your exit strategy, as mandated by NIS2 and DORA.

👋 Final Thoughts: Build Smart, Stay Compliant

Dmytro’s talk provided a powerful recap:

  • Geography is not jurisdiction: The control plane determines exposure, not the zip code.
  • DORA and NIS2 demand risk assessment and controls: They don’t ban public clouds.
  • AWS European Sovereign Cloud (ESC) offers operational sovereignty: While not 100% perfect for all extreme cases, it significantly reduces risks.
  • Outposts solve physical presence but create operational headaches: They don’t solve the legal aspects of sovereignty on their own.
  • ESC + Outposts is the most compliant architecture possible: But it brings substantial overhead.
  • Benchmarking is crucial: There’s no direct translation of capacity from on-premises to cloud/Outposts. You need to understand your workload.
  • Ask your regulators, legal, and compliance teams: Who has operational access? What truly exposes us?

Ultimately, you must make informed decisions based on a full understanding of the information, not just LinkedIn posts or marketing hype. Sometimes, a well-managed local data center might even be a better, simpler solution than a complex, misapplied edge service.

Thank you, Dmytro, for such a long, insightful, and thought-provoking session! Your expertise helps us all build smarter and stay compliant in the ever-evolving cloud landscape.

Keep building, everyone! You are all amazing! See you in the clouds! 🚀✨

Appendix