"
# aws service-owned buckets written via forward access sessions must be exempted explicitly as well
# (e.g. "arn:aws:s3:::*aws-data-exchange*/*" for aws data exchange)
exclude_resource_arns = optional(list(string), [])
# identity provider arns which are exempted from "deny_identity_provider_modification" in addition to eks oidc providers
# e.g. "arn:aws:iam::*:oidc-provider/token.actions.githubusercontent.com" for github actions
exclude_identity_provider_arns = optional(list(string), [])
# regions in which oidc providers of eks clusters are exempted from "deny_identity_provider_modification" (IRSA)
# e.g. ["eu-central-1", "eu-central-2"]. if empty, eks oidc providers are denied as well
eks_oidc_provider_regions = optional(list(string), [])
# account ids of share owners whose ram invitations can be accepted despite "deny_accepting_resource_shares_from_outside_org"
# e.g. accounts of the organization if ram sharing with aws organizations is not enabled or trusted third parties
trusted_resource_share_owner_account_ids = optional(list(string), [])
iam_arns_to_protect = optional(list(string), [])
blacklisted_services = optional(list(string), [])
tagged_resource_actions = optional(list(string), [])
tag_key = optional(string, "")
tag_values = optional(list(string), ["true"])
org_id = optional(string, "")
allowed_regions = optional(list(string), [])
whitelist_for_allowed_regions = optional(list(string), ["*"])
# actions which are exempted from "deny_outside_allowed_regions" in every region, regardless of "aws:RequestedRegion".
# only use this for harmless, region-agnostic read/discovery actions which are legitimately called from any region
# (e.g. a central networking account describing transit gateways/vpn gateways across all regions)
whitelist_for_other_regions = optional(list(string),
[
"ec2:DescribeRegions",
"ec2:DescribeTransitGateways",
"ec2:DescribeVpnGateways"
]
)
# regions which are partially opened for specific actions, in addition to "allowed_regions". in each mapped region
# only the listed actions (and "whitelist_for_other_regions") are exempted from "deny_outside_allowed_regions".
# use this for global services which pin their control plane to a specific region (most use "us-east-1", while
# globalaccelerator, networkmanager, route53-recovery-* and s3 multi-region access points use "us-west-2") and to
# allow selected services in a region (e.g. "lambda:*" in "us-east-1" for lambda@edge). an action can be listed
# for multiple regions, and patterns may overlap across regions (e.g. "lambda:*" in one region and "lambda:Get*"
# in another). overriding this input replaces the default map, so include the default entries you want to keep.
# for other partitions (e.g. aws-eusc) set the partition's global service region(s) or use an empty map
whitelist_for_specific_regions = optional(map(list(string)),
{
"us-east-1" = [
"a4b:*",
"account:Get*",
"account:List*",
"acm:*",
"aws-marketplace-management:*",
"aws-marketplace:*",
"aws-portal:*",
"billing:*",
"billingconductor:*",
"budgets:*",
"ce:*",
"chime:*",
"cloudfront:*",
"config:*",
"consolidatedbilling:*",
"cost-optimization-hub:*",
"cur:*",
"directconnect:*",
"ecr-public:GetAuthorizationToken",
"fms:*",
"freetier:*",
"health:*",
"iam:*",
"importexport:*",
"invoicing:*",
"kms:*",
"mobileanalytics:*",
"notifications-contacts:*",
"notifications:*",
"organizations:*",
"payments:*",
"pricing:*",
"route53:*",
"route53domains:*",
"s3:GetAccountPublic*",
"s3:ListAllMyBuckets",
"s3:PutAccountPublic*",
"savingsplans:*",
"shield:*",
"sts:*",
"support:*",
"supportplans:*",
"tax:*",
"trustedadvisor:*",
"waf-regional:*",
"waf:*",
"wafv2:*",
"wellarchitected:*"
]
"us-west-2" = [
"globalaccelerator:*",
"networkmanager:*",
"route53-recovery-cluster:*",
"route53-recovery-control-config:*",
"route53-recovery-readiness:*",
"s3:CreateMultiRegionAccessPoint",
"s3:DeleteMultiRegionAccessPoint",
"s3:DescribeMultiRegionAccessPointOperation",
"s3:GetMultiRegionAccessPoint",
"s3:GetMultiRegionAccessPointPolicy",
"s3:GetMultiRegionAccessPointPolicyStatus",
"s3:ListMultiRegionAccessPoints",
"s3:PutMultiRegionAccessPointPolicy"
]
}
)
}))
```
Default: `[]`
### service\_principal\_domain
Description: Domain of AWS service principals (e.g. "logging.s3.amazonaws.com") used in policy templates. Service principal names do not follow the partition dns suffix (e.g. aws-eusc also uses "amazonaws.com"), so only change this if a partition uses a different service principal domain.
Type: `string`
Default: `"amazonaws.com"`
## Outputs
The following outputs are exported:
### aiservices\_opt\_out\_policies
Description: AI Services Opt-Out Policies grouped by policy name.
### resource\_control\_policies
Description: Resource Control Policies (RCPs) grouped by policy name.
### service\_control\_policies
Description: Service Control Policies (SCPs) grouped by policy name.
Source: https://docs.nuvibit.com/ntc-building-blocks/templates/ntc-guardrail-templates/
---
# Whitepapers
Welcome to the Nuvibit **Whitepapers** section! Here, you'll find in-depth resources authored by Nuvibit experts, covering advanced architectural concepts, best practices, and innovative solutions for AWS cloud environments.
Whether you're looking to streamline your Infrastructure-as-Code (IaC) workflows, design scalable hybrid networking, or implement robust security strategies, our whitepapers are designed to guide you every step of the way.
---
## Why Read Nuvibit Whitepapers?
Our whitepapers are crafted by subject matter experts with extensive hands-on experience in AWS, Infrastructure-as-Code, and platform engineering. These resources offer:
- **Actionable Insights**: Practical guidance to address real-world challenges.
- **Best Practices**: Recommendations aligned with AWS Well-Architected Framework.
- **Innovative Solutions**: Cutting-edge strategies to optimize your cloud journey.
---
## Explore the Architecture Center
All our whitepapers are conveniently categorized and searchable within the **[Nuvibit Architecture Center](https://docs.nuvibit.com/architecture-center/)**. Use the dashboard to filter and find content tailored to your specific needs.
The Architecture Center includes:
- **Search & Filter**: Quickly find whitepapers relevant to your topics of interest.
- **Comprehensive Resources**: Explore technical guides, architectural patterns, and implementation best practices.
[Go to the Architecture Center →](https://docs.nuvibit.com/architecture-center/)
Source: https://docs.nuvibit.com/whitepapers/
---
# Navigating the AWS European Sovereign Cloud: Practical Strategies for a Multi-Partition Future
## Abstract
The AWS European Sovereign Cloud (ESC) represents a fundamental shift in cloud computing for EU public sector and regulated industries. ESC is an independent AWS partition, physically and logically separate from the commercial partition, operated entirely within the EU to address digital sovereignty requirements. This whitepaper provides a practical framework for organizations adopting ESC through a strategic dual‑partition approach that combines ESC sovereignty with commercial AWS capabilities.
We examine the architectural implications of partition boundaries, control plane separation, and the operational complexities of managing infrastructure across multiple AWS partitions. Through detailed analysis of connectivity patterns, identity federation, and compliance mapping, this paper presents proven strategies for navigating ESC adoption whilst maintaining operational excellence.
Key takeaways: ESC solves sovereignty challenges but introduces operational complexity; dual‑partition strategies offer targeted sovereignty with retained innovation velocity; success requires deliberate operating models and partition‑aware tooling from day one.
---
## 1. Introduction
The European regulatory landscape increasingly demands data sovereignty, operational autonomy, and governance structures that align with EU values and oversight. Digital sovereignty has evolved from a policy aspiration to a technical requirement, particularly for public sector entities and organizations operating in highly regulated industries such as financial services, healthcare, and critical infrastructure.
The **AWS European Sovereign Cloud (ESC)** addresses these requirements through a new AWS partition that is operated, governed, and controlled entirely within the EU. **Launched in January 2026**, ESC provides complete independence of control planes, metadata handling, and operational oversight that goes beyond regional data residency features within the commercial partition. This creates both opportunities and challenges for organizations seeking to leverage cloud computing whilst meeting stringent sovereignty requirements.
This paper provides practical engineering patterns and operating models for ESC adoption and multi‑partition environments. We examine the technical implications of partition boundaries, present proven integration patterns, and offer guidance for organizations navigating the complexity of operating across multiple AWS partitions whilst maintaining operational excellence and innovation velocity.
:::info Callout
This document is informational and not legal advice. Engage legal and compliance experts for interpretations of regulatory obligations.
:::
**Summary:**
* ESC addresses EU sovereignty requirements through independent partition operation
* Multi‑partition strategies introduce complexity but enable targeted sovereignty
* Practical patterns exist for managing identity, connectivity, and operations across partitions
* Success requires deliberate operating models and partition‑aware architectural decisions
---
## 2. AWS Partitions
*Figure 1: Partition model and control‑plane boundaries*
AWS partitions represent fundamentally separate cloud environments with independent control planes, billing systems, and operational boundaries. The global commercial partition serves most customers worldwide, whilst specialised partitions like AWS GovCloud (US) and the upcoming ESC address specific regulatory and sovereignty requirements.
ESC operates with complete separation from other partitions, including its own identity and access management system, billing infrastructure, and service control planes. This comprehensive separation ensures that all administrative actions, metadata, and operational telemetry remain within ESC's EU governance domain. For ESC, this means customer content, customer‑created metadata (including IAM roles, resource tags, and configuration data), and operational oversight remain entirely under EU control with no shared components or cross‑partition dependencies.
The implications extend beyond data residency. Organizations must establish new AWS accounts within each partition, as accounts cannot span partition boundaries. Service availability, feature roadmaps, and ecosystem maturity may differ between partitions. Support boundaries align with partition operations, meaning ESC support is provided by EU‑resident staff operating under EU governance structures.
Tooling and automation must be partition‑aware. APIs, CLI configurations, and Infrastructure as Code templates require specific endpoints and credentials for each partition. Cross‑partition resource references are impossible; integration occurs through application‑level connectivity patterns or shared external systems.
| **Partition** | **Identifier** | **Primary Use Case** | **Geographic Scope** |
|---------------|----------------|----------------------|----------------------|
| Commercial | `aws` | Global commercial cloud services | Worldwide (excluding China) |
| China | `aws-cn` | China-specific cloud services operated by local partners | China mainland |
| GovCloud (US) | `aws-us-gov` | US federal government and regulated industries | United States |
| ESC | `aws-eusc` | EU sovereignty and regulatory compliance | European Union |
:::info Partition and Region Identifier
The AWS European Sovereign Cloud launches with the initial region Brandenburg (`eusc-de-east-1`) in Germany. This represents the first EU-sovereign AWS region with complete operational independence from commercial AWS partitions.
ESC uses a distinct domain namespace (`*.amazonaws.eu`) separate from commercial AWS (`*.amazonaws.com`), reinforcing the complete partition separation at the API and service endpoint level.
:::
The partition identifier forms part of every Amazon Resource Name (ARN), enabling precise resource identification within the appropriate governance domain:
arn:`partition`:service:region:account:resource
**ARN Examples across partitions:**
```
# Commercial partition
arn:aws:iam::123456789012:role/my-role
# GovCloud partition
arn:aws-us-gov:iam::123456789012:role/my-role
# ESC partition (anticipated format)
arn:aws-eusc:iam::123456789012:role/my-role
```
**Summary:**
* Partitions provide complete control plane separation and independent governance
* Cross‑partition account sharing is impossible; new accounts required per partition
* Service availability and ecosystem maturity may differ between partitions
* Tooling must be explicitly designed for partition‑aware operations
---
## 3. Why ESC Exists and What It Solves
The AWS European Sovereign Cloud (ESC) addresses three primary challenges facing EU organizations: data residency requirements that extend beyond customer content to include metadata and operational telemetry; operational autonomy ensuring that cloud infrastructure management occurs within EU governance frameworks; and EU‑centric oversight providing independent governance aligned with European values and regulatory expectations.
ESC delivers these benefits through EU‑based operations with staff residing in and operating from EU member states. Customer content and customer‑created metadata remain within EU borders, including IAM configurations, resource tags, CloudTrail logs, and billing data. An independent governance structure provides European oversight of operations, security practices, and business decisions affecting ESC customers.
:::info Important Distinction: AWS Operations vs. Customer Location
**AWS Staff Requirements:** ESC infrastructure is operated exclusively by EU‑resident AWS personnel under EU governance. This includes data centre operations, support escalations, security monitoring, and infrastructure management.
**Customer Location Flexibility:** ESC customers can be located anywhere globally. A US‑based multinational corporation, Asian financial institution, or Australian government agency can all use ESC to meet EU sovereignty requirements for their European operations, data processing, or regulatory compliance needs. Customer location, citizenship, or corporate domicile do not restrict ESC access.
**The Value Proposition:** ESC enables global organizations to leverage EU‑sovereign cloud infrastructure regardless of their headquarters location, providing EU data residency and governance without requiring the customer organisation itself to be EU‑based.
:::
*Figure 2: AWS European Sovereign Cloud (ESC) Governance Overview*
The trade‑offs are significant. Organizations start from scratch and must rebuild their AWS foundation within the ESC partition. Service parity will evolve gradually, with initial ESC regions offering core services whilst niche capabilities and newest instance types arrive later. Pricing and procurement processes may differ from commercial AWS. Geographic redundancy is initially limited until multiple ESC regions become available, creating disaster recovery considerations that don't exist in the mature commercial partition.
Organizations must weigh stronger sovereignty posture against reduced service breadth, potentially higher costs, and operational complexity. The decision requires careful analysis of regulatory requirements, service dependencies, performance needs, and operational readiness for managing multi‑partition environments.
| **Benefits** | **Trade‑offs** |
|--------------|----------------|
| EU‑based operations and governance | Start from scratch and rebuild infrastructure |
| Customer content and metadata residency | Evolving service parity and feature availability |
| Independent European oversight | Potentially different pricing and procurement |
| Regulatory compliance assurance | Limited geographic redundancy initially |
| Familiar AWS APIs and tooling | Operational complexity for multi‑partition setups |
### 3.1 Regulatory Compliance Alignment
ESC addresses specific regulatory frameworks prevalent in EU public sector and regulated industries. Understanding how ESC characteristics map to compliance requirements enables organizations to leverage ESC capabilities effectively whilst maintaining comprehensive compliance postures.
**GDPR (General Data Protection Regulation)** benefits from ESC's EU‑resident data processing and storage capabilities. Customer content and metadata remain within EU jurisdiction, supporting data protection impact assessments and privacy by design requirements. EU‑resident operations provide direct accountability under European legal frameworks.
**NIS2 (Network and Information Systems Directive)** requirements for security measures and incident reporting align with ESC's EU‑based security operations and incident response capabilities. Critical infrastructure operators can demonstrate EU‑controlled cybersecurity measures and governance structures that align with national implementation requirements.
**DORA (Digital Operational Resilience Act)** for financial services benefits from ESC's independent governance and EU‑resident operations. Financial institutions can demonstrate operational resilience through EU‑controlled cloud services whilst maintaining ICT risk management frameworks that align with European supervisory expectations.
**Sector‑specific regulations** overlay additional requirements that ESC's governance model supports. Healthcare data processing under national implementations of GDPR, defence and security applications requiring national oversight, and public sector applications with citizen data protection requirements all benefit from ESC's sovereignty characteristics.
**Artifact collection and evidence generation** require partition‑aware approaches. Audit logs, configuration evidence, and compliance reports remain within appropriate jurisdictional boundaries whilst providing comprehensive evidence for regulatory examinations and assessments.
**Summary:**
* ESC provides complete sovereignty through EU‑based operations and governance
* Benefits include metadata residency and independent European oversight
* Trade‑offs include service parity evolution and operational complexity
* ESC addresses key EU regulatory frameworks through sovereignty and governance characteristics
* Evidence collection requires partition‑aware approaches to maintain jurisdictional boundaries
* Decision requires balancing sovereignty needs against functionality and complexity
---
## 4. Comparison: AWS GovCloud (US) and ESC
AWS GovCloud (US) provides a useful reference point for understanding partition design patterns and operational models. Both ESC and GovCloud represent separate partitions created to address specific regulatory and sovereignty requirements, operating with distinct control planes and governance structures.
Key commonalities include partition‑based isolation ensuring complete separation from commercial AWS operations, compliance‑driven design addressing specific regulatory frameworks, and distinct operational models with specialised staffing and oversight. Both partitions require new account establishment and feature staged service availability compared to commercial regions.
The differences reflect distinct regulatory contexts and operational requirements. ESC targets EU sovereignty requirements with EU‑resident operations, whilst GovCloud addresses US federal requirements with US‑person operations. Regulatory frameworks differ significantly: ESC aligns with GDPR, NIS2, and emerging EU digital sovereignty legislation, whilst GovCloud focuses on FedRAMP, ITAR, and US federal security standards.
Access eligibility varies significantly between partitions. ESC will be available to any organisation or individual, similar to commercial AWS, enabling broad adoption for sovereignty requirements. GovCloud (US) has strict access restrictions requiring account holders to be US entities incorporated to do business in the United States, based on US soil, and operated by US persons (citizens or active Green Card holders) capable of handling ITAR export‑controlled data.
Staffing and operations residency requirements vary, with ESC emphasising EU residency and governance, whilst GovCloud requires US persons for certain operations. Service availability trajectories reflect different market priorities and regulatory approval processes. Marketplace ecosystems develop independently, with different vendor participation patterns and compliance requirements.
:::info Billing Differences
**AWS European Sovereign Cloud (ESC)** operates with dedicated billing systems independent from commercial AWS, providing complete financial sovereignty and EU-resident billing operations.
**AWS GovCloud (US)** has significant billing limitations: all billing and cost management must be accessed through an associated standard commercial AWS account. GovCloud accounts cannot view billing directly within the GovCloud console. Cost and Usage Reports for GovCloud are only available in the commercial partition, and Savings Plans must be purchased through the commercial account to apply to GovCloud usage.
:::
**Summary:**
* Both partitions address sovereignty through separate control planes and governance
* Regulatory contexts differ significantly between US federal and EU sovereignty requirements
* Operational models reflect distinct staffing and oversight requirements
* Service and marketplace evolution follows different trajectories based on market needs
### 4.1 Service Availability Comparison
AWS maintains an official, up-to-date service and feature availability list for the European Sovereign Cloud. Use the link below to explore available services, filter by category, and compare across partitions:
**[AWS European Sovereign Cloud — Service & Feature Availability](https://builder.aws.com/build/capabilities/explore?tab=service-feature&f=eJyrVipOzUlNLklNCUpNz8zPK1ayUoqOUUotLU7WTUnVTU0sLtE1jFGKVdKBK3QsS8zMSUzKzMksqQSqdsyrVEARqgUA4l8dog)**
---
## 5. Adoption Scenarios and Decision Framework
Organizations face three primary adoption scenarios when considering ESC. Each scenario presents distinct advantages and challenges that must be evaluated against specific requirements for sovereignty, service availability, operational complexity, and innovation velocity.
**Scenario A: All‑in on ESC** provides the strongest sovereignty posture by operating exclusively within the ESC partition. This approach simplifies compliance assurance and audit evidence collection, as all operations occur within the sovereign environment. However, organizations accept service availability limitations, reduced ecosystem maturity, and geographic redundancy constraints until multiple ESC regions become available.
**Scenario B: Remain in Commercial Partition** maintains full service parity and access to the global AWS ecosystem. Organizations benefit from mature services, extensive marketplace offerings, and proven operational patterns. This approach may not satisfy sovereignty requirements for regulated workloads or public sector entities with strict data residency mandates.
**Scenario C: Selective ESC + Commercial (Dual‑Partition)** offers targeted sovereignty where regulatory requirements demand it whilst retaining innovation velocity for non‑regulated workloads. Organizations can place sensitive data and regulated processes in ESC whilst leveraging commercial AWS for development, testing, and non‑sensitive operations. This approach introduces the highest operational complexity but enables both compliance and innovation.
The following decision tree provides a starting point for evaluating ESC adoption scenarios based on core regulatory and operational drivers. While sovereignty requirements and service dependencies form the primary decision criteria, organizations must also consider additional factors including latency sensitivity, cost constraints, operational readiness, and long-term strategic objectives.
*Figure 3: Decision tree mapping regulatory, architectural, and operational drivers*
Organizations should use this decision tree as an initial assessment tool, then conduct deeper analysis of their specific requirements. Beyond the primary sovereignty and service considerations, factors such as existing multi-region compliance experience, organizational change readiness, vendor relationship complexity, and technical team capabilities all influence the optimal adoption path. The decision tree simplifies complex trade-offs to provide directional guidance, but each organization's unique context requires thorough evaluation of all relevant considerations.
**Summary:**
* Three primary scenarios address different sovereignty and operational priorities
* All‑in ESC maximises sovereignty but limits service availability
* Dual‑partition enables targeted sovereignty with operational complexity trade‑offs
* Decision framework should weigh compliance needs against service and operational requirements
---
## 6. Operating Across Multiple AWS Partitions
Operating across both commercial AWS and ESC (or any other partition) requires deliberate organisational design, clear ownership models, and partition‑aware operational procedures. The dual‑partition approach shares many characteristics with multi‑cloud strategies, introducing similar complexity patterns whilst offering unique value propositions that make the operational overhead worthwhile for organizations with sovereignty requirements.
**The Multi‑Cloud Parallel:** Like multi‑cloud environments, dual‑partition operations present a "best of both worlds" opportunity alongside significant complexity challenges. Organizations gain access to innovation velocity from commercial AWS, with its rapid service development, extensive marketplace, and mature ecosystem, whilst meeting strict compliance requirements through ESC's EU‑sovereign operations. However, this approach introduces the familiar multi‑cloud challenges of disparate service portfolios, configuration drift risks, operational complexity, and the need for unified visibility across heterogeneous environments.
**Benefits: Innovation Meets Compliance:** The primary value proposition lies in targeted sovereignty deployment. Regulated workloads benefit from ESC's complete EU residency and governance whilst non‑regulated workloads leverage commercial AWS's full service breadth and global reach. This enables organizations to adopt emerging AI/ML services, leverage extensive marketplace offerings, and access bleeding‑edge capabilities for development and innovation workloads, whilst ensuring that customer data processing and regulated operations meet the strictest sovereignty requirements.
**Complexity: The Multi‑Environment Tax:** The operational overhead mirrors multi‑cloud challenges but with partition‑specific constraints. Service availability differences require constant gap analysis and alternative implementations. Configuration drift becomes a persistent risk as changes in one partition may not replicate to the other, demanding robust automation and governance processes. Consolidated visibility requires external tooling and aggregation platforms, as native AWS observability services cannot span partition boundaries. Organizations must maintain duplicate foundational infrastructure, manage separate billing relationships, and develop partition‑aware operational procedures.
The operating model establishes ownership boundaries and responsibilities across partitions. Platform teams typically own the foundational infrastructure in both partitions, including account vending, networking, and security tooling. Application teams focus on workload deployment within appropriate partitions based on data classification and regulatory requirements. Security and compliance teams develop partition‑specific policies whilst maintaining consistent control objectives.
*Figure 4: Reference operating model for two partitions*
### 6.1 Risks and Anti‑Patterns
Multi‑partition operations introduce specific risks that require active monitoring and mitigation. Understanding these risks and avoiding common anti‑patterns enables successful long‑term operations across partition boundaries.
**Primary Risk Categories:** Top risks include tooling fragmentation leading to operational blind spots and increased complexity, hidden cross‑partition data flows that violate sovereignty boundaries or compliance requirements, and configuration drift between partitions creating security vulnerabilities or operational inconsistencies. Service parity evolution risks include dependency on services that may not migrate to ESC or features that differ between partitions.
**Cost and Security Escalation:** Cost escalation risks emerge from duplicate infrastructure, increased licensing, and operational overhead. Security risks include credential sharing across partitions, misconfigured cross‑partition networking, and inconsistent security policies. Operational risks encompass incident response complexity, knowledge fragmentation across teams, and reduced operational efficiency due to partition constraints.
**Critical Anti‑Patterns to Avoid:**
- **Sharing IAM credentials or access keys across partitions** violates security boundaries and complicates audit trails
- **Unmanaged public endpoints without proper authentication** create security vulnerabilities and potential data exfiltration risks
- **Copy‑paste Infrastructure as Code without partition‑aware configuration** leads to deployment failures and maintenance overhead
- **Ignoring service parity differences** leads to deployment failures when services or features are unavailable
- **Bypassing approved connectivity patterns** creates security risks and operational complications
**Mitigation Strategies:** Mitigation strategies include automated policy enforcement through Service Control Policies and guardrails, regular configuration audits to detect drift and non‑compliance, partition‑aware monitoring and alerting to maintain operational visibility, and comprehensive documentation of approved patterns and procedures.
| **Risk** | **Likelihood** | **Impact** | **Indicator** | **Mitigation** |
|----------|----------------|------------|---------------|----------------|
| **Tooling Fragmentation** | High | Medium | Multiple tool instances | Unified dashboards, automation |
| **Cross‑Partition Data Flows** | Medium | High | Unexpected network traffic | Network monitoring, Data Loss Prevention |
| **Configuration Drift** | High | Medium | Policy violations | Automated compliance scanning |
| **Service Parity Issues** | Medium | High | Deployment failures | Service matrix tracking |
| **Cost Escalation** | Medium | Medium | Budget variance | Unified cost reporting |
**Summary:**
* Dual‑partition operations require clear ownership models and governance boundaries
* Organisational structures can mirror across partitions or maintain separate hierarchies
* AWS operational constraints in ESC affect customer incident response and change management
* Multi‑partition operations introduce systematic risks requiring active management
* Anti‑patterns like credential sharing and unmanaged endpoints create significant security risks
* Mitigation requires automated enforcement, regular auditing, and comprehensive monitoring
* Success depends on deliberate risk management and adherence to approved patterns
---
## 7. Lessons Learned from Multi‑Region Compliance Strategies
Many organizations have implemented multi‑region compliance strategies to address data residency and regulatory requirements. These experiences provide valuable insights for multi‑partition architectures, though partition boundaries introduce harder constraints than regional separation.
Regulated industries often run sensitive workloads in specific regions (such as Zurich for Swiss government or financial requirements) whilst operating innovation workloads in broader regions like Frankfurt. This pattern establishes data classification frameworks, workload placement policies, and operational boundaries that translate to partition environments.
Key patterns that transfer to multi‑partition environments include workload classification based on data sensitivity and regulatory requirements, network segmentation ensuring traffic isolation between compliance domains, telemetry handling with appropriate data residency controls, and audit evidence collection tailored to regulatory frameworks.
**Service Availability Challenges Exist in Both Models:** Multi‑region compliance strategies already deal with service availability drift, particularly when using opt‑in regions. Zurich (eu‑central‑2) exemplifies this challenge. As an opt‑in region designed for Swiss data residency requirements, it offers a significantly reduced service portfolio compared to Frankfurt (eu‑central‑1). Organizations operating across Zurich and Frankfurt must architect workloads that accommodate service gaps, implement alternative solutions for missing capabilities, and manage the complexity of multi-region deployments. This mirrors the partition challenge but within the same governance domain. However, partitions introduce harder constraints that don't exist in multi‑region deployments.
The lesson for ESC adoption is that existing multi‑region compliance expertise provides a foundation, but partition‑specific patterns require additional consideration for identity, networking, and service parity management.
**Summary:**
* Multi‑region compliance strategies provide foundation patterns for partition architectures
* Workload classification, network segmentation, and audit evidence patterns transfer effectively
* Partition boundaries introduce harder constraints than regional separation
* Existing compliance expertise accelerates ESC adoption but requires partition‑specific adaptation
---
## 8. Core Challenges in Multi‑Partition Engineering
Multi‑partition architectures introduce specific engineering challenges that require deliberate mitigation strategies. These challenges span infrastructure management, tooling integration, service availability, cost optimisation, workload connectivity, and security operations.
**Dual Landing Zone Complexity**
A Landing Zone provides the foundational infrastructure and governance framework for AWS environments, including account structures, networking components, security baselines, and operational procedures that enable teams to deploy workloads safely and consistently. Two Landing Zones create duplication versus divergence risks:
- Organizations must maintain foundational infrastructure in both partitions, including account vending, networking components, and security tooling
- Configuration drift becomes a significant risk as changes in one partition may not propagate to the other
- Baseline configurations require partition‑aware templates and mechanisms to prevent divergence
**Cross‑Partition Connectivity Constraints**
AWS provides no native networking mechanisms between partitions, eliminating traditional connectivity options and forcing alternative architectural patterns:
- VPC peering, Transit Gateway connectivity, and PrivateLink options are unavailable across partition boundaries
- Workload communication requires alternative patterns including application‑level APIs, VPN tunnels over the internet, or routing through on‑premises via Direct Connect
- Each approach introduces latency, complexity, and potential security considerations that must be carefully evaluated
**Security Operations Fragmentation**
Unified security operations become significantly more complex across partition boundaries, requiring external systems and processes:
- Security services operate independently within each partition, requiring external aggregation for consolidated visibility
- Incident response procedures must accommodate different operational models and partition‑specific constraints
- Cross‑partition security correlation whilst maintaining appropriate data residency controls for telemetry originating from sovereign environments
**Tooling and Integration Complexity**
Tooling fragmentation affects every aspect of operations, multiplying administrative overhead and integration requirements:
- Identity systems require separate configurations for each partition with potential federation challenges
- Billing and cost management span multiple systems, complicating financial reporting and optimization
- Monitoring and SIEM solutions need partition‑specific deployments with aggregation capabilities
- Backup and disaster recovery solutions must accommodate partition boundaries and data residency requirements
**Service Parity Drift**
Service availability differences create ongoing architectural and operational challenges as partitions evolve at different rates:
- Commercial AWS introduces new services and features continuously, whilst ESC service availability evolves based on regulatory approval and operational readiness
- Organizations must maintain service parity matrices and track capability gaps between partitions
- Development teams need workarounds for missing capabilities and migration paths as services become available
- Feature inconsistencies can create technical debt and limit architectural flexibility
**Cost and Procurement Complexity**
Multi‑partition operations introduce financial and procurement challenges that extend beyond technical considerations:
- Organizations need to manage separate billing relationships and potentially different pricing models
- Software licence entitlements may not transfer between partitions, requiring duplicate procurement
- Marketplace availability is anticipated to differ, potentially affecting vendor relationships and sourcing strategies
- Cost attribution and optimization become more complex across multiple billing systems and governance domains
| **Challenge** | **Impact** | **Mitigation** |
|---------------|------------|----------------|
| **Dual Landing Zones** | Configuration drift, duplicate maintenance | Shared configuration, partition‑aware IaC templates |
| **Cross‑partition connectivity** | Limited networking options, latency, complexity | Application APIs, VPN tunnels, on-premises routing |
| **Unified security operations** | Fragmented visibility, complex incident response | cross-partition aggregation, partition‑aware playbooks |
| **Tooling fragmentation** | Operational overhead, licence proliferation | Aggregated dashboards, centralised identity |
| **Service parity drift** | Feature gaps, technical debt | Service matrix tracking, architectural flexibility |
| **Cost complexity** | Split billing, unclear attribution | Unified reporting, partition‑aware tagging |
**Summary:**
* Multi‑partition engineering introduces systematic complexity across all operational domains
* Configuration management and tooling fragmentation require architectural solutions
* Service parity drift demands ongoing tracking and flexible architectural patterns
* Cost and procurement complexity needs unified reporting and governance approaches
---
## 9. Multi-Partition Integration Patterns (Blueprints)
This chapter presents seven comprehensive pattern areas that address the core integration challenges in multi-partition environments. Each pattern area provides detailed implementation approaches, trade-off analysis, and practical guidance for organizations managing infrastructure across AWS partitions.
Each pattern area includes:
- **Multiple implementation options** with detailed pros/cons analysis
- **Comprehensive comparison matrices** for pattern selection
- **Practical code examples** and configuration guidance
- **Real-world considerations** including costs, complexity, and operational impact
- **ESC-specific constraints** and service availability considerations
---
### 9.1 Landing Zone and Account Vending
A Landing Zone provides the foundational infrastructure and governance framework for AWS environments, including account structures, networking components, security baselines, and operational procedures that enable teams to deploy workloads safely and consistently. Multiple partitions require multiple Landing Zones, leading duplication and divergence risks:
- Organizations must maintain foundational infrastructure in both partitions, including account vending, networking components, and security tooling
- Configuration drift becomes a significant risk as changes in one partition may not propagate to the other
- Baseline configurations require partition‑aware templates and mechanisms to prevent divergence
Managing Landing Zones across partitions requires careful consideration of operational models that balance governance consistency with partition isolation. Organizations face two primary approaches based on their Infrastructure as Code maturity and tolerance for operational complexity.
:::tip Why IaC Is Crucial for Multi-Partition Success
**Infrastructure as Code (IaC) is absolutely essential** for managing multi-partition Landing Zones and account vending without operational failure. The complexity of maintaining consistent configurations across separate AWS partitions makes manual management approaches unsustainable at scale.
**Preventing Configuration Drift:** IaC templates ensure identical configurations deploy across partitions, with version control tracking all changes and automated drift detection identifying deviations between partitions.
**Compliance Parity Assurance:** Template-driven deployments guarantee that compliance controls remain consistent across partitions, enabling auditors to verify control implementation through code review rather than environment-by-environment inspection.
**Operational Scalability:** Automated account vending and baseline deployment workflows ensure consistent user experiences and security configurations without manual intervention or partition-specific procedures.
**Change Management:** Centralized IaC repositories with proper branching strategies and approval workflows ensure that changes undergo review before deployment to either partition, reducing the risk of introducing inconsistencies.
:::
:::warning Control Tower and Landing Zone Accelerator Limitations
**AWS Control Tower** requires separate deployment in each partition, as it operates within the scope of a single AWS Organization and cannot manage resources across partition boundaries.
**Landing Zone Accelerator on AWS (LZA)** has the same limitation - it maps to a single AWS Organization and requires duplication of configurations for multi-partition deployments. Organizations using LZA must maintain separate configuration files and operational procedures for each partition.
**Multi-Partition Implications:**
- Each partition requires its own Control Tower setup with separate organizational unit structures, guardrails, and account baselines
- Account vending becomes a separate process for each partition
- Configuration synchronization between partitions requires manual coordination or custom automation
- Operational overhead increases significantly compared to single-partition deployments
**Mitigation Strategy:** Organizations should evaluate Terraform/OpenTofu-based Landing Zone solutions like the Nuvibit Terraform Collection (NTC) that natively support multi-partition deployment through provider aliasing and shared configuration templates.
:::
---
#### `Pattern 1` Independent Landing Zone Operations
**Nuvibit Terraform Collection (NTC)**
*Figure 5a: Completely independent Landing Zone management*
**Landing Zone Accelerator on AWS (LZA)**
*Figure 5b: Completely independent Landing Zone management*
This pattern maintains completely independent Landing Zone deployments with separate Infrastructure as Code pipelines, governance processes, and operational procedures for each partition. Each partition operates its own Landing Zone with isolated account vending, baseline configurations, and organizational structures.
**Implementation:** Deploy separate Landing Zone solutions (Landing Zone Accelerator on AWS, Nuvibit Terraform Collection) in each partition with independent configuration management. Each partition maintains its own organizational unit structures, Service Control Policies, and account baselines without shared components or cross-partition coordination.
**Account Vending:** Separate account vending processes operate independently in each partition, requiring users to request accounts through partition-specific interfaces. Account baseline configurations may differ between partitions due to service availability differences and independent configuration management.
**Infrastructure as Code Approaches:**
- **Nuvibit Terraform Collection (Terraform/OpenTofu):** Separate Terraform configurations with independent state management and deployment pipelines for each partition. Requires careful version management and testing across partitions.
- **Landing Zone Accelerator on AWS (CloudFormation):** Requires complete duplication of configuration files for each partition. Each partition's CloudFormation stacks operate independently with separate parameter files and organizational mappings.
**Benefits:** Maximum partition isolation with no cross-partition dependencies, simplified compliance boundaries with clear separation of concerns, independent operational procedures that can accommodate partition-specific constraints, and reduced complexity in governance structures.
**Challenges:** Code duplication across partition configurations increases maintenance overhead, configuration drift risk without automated synchronization, separate account vending processes create user experience friction, and increased operational overhead for platform teams managing dual environments.
**Operational Considerations:** Platform teams require expertise in partition-specific operational constraints. Change management processes must coordinate across separate environments to maintain consistency whilst respecting partition boundaries.
---
#### `Pattern 2` Unified Landing Zone Operations
**Nuvibit Terraform Collection (NTC)**
*Figure 6a: Shared configuration with unified deployment pipelines*
**Landing Zone Accelerator on AWS (LZA)**
:::warning Multi-Partition Limitation
**Landing Zone Accelerator on AWS cannot be deployed in a unified pattern.**
LZA maps to a single AWS Organization and requires complete duplication of configurations for multi-partition deployments. Each partition needs its own LZA setup with separate configuration files, organizational structures, and operational procedures.
For unified multi-partition operations, consider Terraform/OpenTofu-based solutions like the Nuvibit Terraform Collection (NTC) that natively support provider aliasing and shared configuration templates.
:::
This pattern uses shared Infrastructure as Code configurations with unified deployment pipelines that target multiple partitions from a single source of truth. Shared templates and configurations minimize code duplication whilst maintaining partition isolation through provider aliasing and conditional logic.
**Implementation:** Single Infrastructure as Code repository with partition-aware templates that deploy to multiple AWS Organizations simultaneously. Shared organizational unit structures, policy definitions, and baseline configurations adapt to partition-specific service availability through feature flags and conditional resource creation.
**Account Vending:** Unified account vending interface abstracts partition complexity while routing requests to appropriate partition-specific provisioning logic. Single account request workflow with partition selection capability, shared approval processes, and consistent user experience across partitions.
**Infrastructure as Code Approaches:**
- **Nuvibit Terraform Collection (Terraform/OpenTofu):** `**Native support**` for multi-partition deployment through provider aliasing, shared module libraries, and conditional resource creation based on partition characteristics.
- **Landing Zone Accelerator on AWS (CloudFormation):** `**Not supported**` Landing Zone Accelerator maps to a single AWS Organization and cannot deploy across multiple partitions.
:::info Terraform/OpenTofu Advantages for Multi-Partition Deployment
**Provider Aliasing:** Terraform/OpenTofu natively supports multiple AWS provider configurations in a single configuration, enabling deployment to multiple partitions simultaneously from shared templates.
**Conditional Logic:** Rich conditional expressions and feature flags allow templates to adapt to partition-specific service availability without code duplication.
**Module Reusability:** Shared module libraries with partition-aware parameters eliminate code duplication whilst maintaining consistency across partitions.
**Cross-Partition Resources:** Single Terraform/OpenTofu configuration can manage resources across partitions, enabling unified account vending and baseline deployment workflows.
:::
**Benefits:** Minimized code duplication through shared configurations reduces maintenance overhead, consistent organizational structures and policies across partitions, unified account vending provides superior user experience, and single source of truth for governance configurations.
**Challenges:** Increased complexity in template design with partition-aware logic, dependency on Infrastructure as Code tooling that supports multi-partition deployment, potential for cascading failures affecting multiple partitions, and higher skill requirements for platform teams managing shared configurations.
**Account Vending Workflow:** Users request accounts through a single interface with partition selection based on workload classification and data residency requirements. Conditional logic routes requests to appropriate partition-specific account factories whilst maintaining consistent baseline configurations and approval workflows. Any self-service portal can be easily integrated via GitOps workflows, where account requests trigger git push operations to update the account factory repository, enabling automated provisioning through Infrastructure as Code pipelines.
 \
*Figure 7: Self-service account vending implementation with multi-partition support*
---
#### Landing Zone Pattern Comparison
| **Pattern** | **Best For** | **Pros** | **Cons** | **Operational Model** | **Complexity** | **Governance** |
|-------------|--------------|----------|----------|-----------------------|----------------|----------------|
| **1. Independent Landing Zone Operations** | Organizations prioritizing maximum partition isolation, simple governance boundaries, Landing Zone Accelerator on AWS users | ✅ Maximum partition isolation
✅ Independent operational procedures
✅ Clear compliance boundaries
✅ No cross-partition failure risk
✅ Supports any IaC approach | ❌ Code duplication overhead
❌ Configuration drift risk
❌ Separate account vending processes
❌ Increased maintenance burden
❌ User experience friction | **Dual Operations**
Separate teams or procedures per partition | **Low-Medium**
Independent but duplicated | **Separated**
Independent governance per partition |
| **2. Unified Landing Zone Operations** | Organizations with Terraform/OpenTofu expertise, unified operational preferences, emphasis on consistency | ✅ Minimized code duplication
✅ Consistent governance structures
✅ Unified account vending
✅ Single source of truth
✅ Reduced operational overhead | ❌ Increased template complexity
❌ Cross-partition failure risk
❌ Higher skill requirements
❌ Limited to Terraform/OpenTofu
❌ Potential cascading issues | **Unified Operations**
Single team managing both partitions | **Medium-High**
Shared configuration logic | **Unified**
Consistent policies across partitions |
**Summary:**
* Landing Zone management is the foundation of successful multi-partition operations
* Infrastructure as Code is critical for maintaining consistency and preventing configuration drift
* Pattern selection depends on organizational IaC maturity and governance preferences
* Terraform/OpenTofu provides significant advantages over CloudFormation for multi-partition architectures
* Account vending complexity varies significantly between separated and aggregated approaches
---
### 9.2 Infrastructure as Code and CI/CD
Managing Infrastructure as Code across partitions requires partition‑aware templates, dynamic resource configuration, and careful handling of partition‑specific constraints. The primary challenge lies in creating reusable configurations that adapt to different partition characteristics without hardcoding partition‑specific values.
**Infrastructure as Code: The Foundation for Multi-Partition Consistency**
Infrastructure as Code is absolutely critical for managing consistent configurations across partitions whilst accommodating service availability differences and partition‑specific constraints. Manual configuration management becomes unsustainable when dealing with partition boundaries and service parity gaps.
**Preventing Hardcoded Partition Dependencies:** Existing IaC code often contains hardcoded ARNs, service endpoints, or partition identifiers that break when deployed across different partitions. Templates must use dynamic resource references and partition‑aware logic to ensure portability.
**Partition-Aware Resource Configuration:** IaC modules include partition detection logic that adapts resource configurations based on target partition characteristics. Feature flags handle service availability differences, disabling resources or substituting alternatives when services are unavailable in specific partitions.
**Dynamic Service Discovery:** Rather than hardcoding service endpoints or ARNs, templates use data sources and dynamic references to discover partition‑appropriate resources and endpoints at deployment time.
**Avoiding Hardcoded Partition Dependencies**
Existing Infrastructure as Code often contains hardcoded references that break when deployed across different partitions. Common issues include hardcoded ARNs with partition identifiers, service endpoints using commercial AWS domains, and resource references that assume specific partition characteristics.
**Terraform Example:**
```hcl
# Use data source for dynamic discovery
data "aws_caller_identity" "current" {}
data "aws_partition" "current" {}
locals {
partition = data.aws_partition.current.partition
account_id = data.aws_caller_identity.current.account_id
}
output "role_arn" {
# Instead of hardcoded ARN (e.g. arn:aws:iam::123456789012:role/MyRole)
value = "arn:${local.partition}:iam::${local.account_id}:role/MyRole"
}
```
**CloudFormation Example:**
```yaml
# Use pseudo parameters
Outputs:
RoleArn:
# Instead of hardcoded ARN (e.g. arn:aws:iam::123456789012:role/MyRole)
Value: !Sub arn:${AWS::Partition}:iam::${AWS::AccountId}:role/MyRole
```
:::warning ESC Service Endpoint Differences
**Service Endpoints Use Different Domains:** AWS European Sovereign Cloud uses `*.amazonaws.eu` domain endpoints instead of the commercial `*.amazonaws.com` domains. This affects:
- **API Endpoints:** Service APIs use ESC-specific endpoints
- **S3 Bucket URLs:** S3 bucket access URLs use the ESC domain namespace
- **CloudFormation Template URLs:** Template and artifact references must use appropriate domain endpoints
- **Third-Party Tool Configuration:** External tools and integrations require ESC-specific endpoint configuration
**Terraform AWS Provider Support:** The Terraform AWS provider is expected to support ESC from day one, with AWS SDKs already updated for ESC compatibility. Any unexpected behavior can be tracked via [GitHub Issue #44437](https://github.com/hashicorp/terraform-provider-aws/issues/44437).
:::
:::danger Landing Zone Accelerator and Control Tower AFT Limitations
**CodeBuild and CodePipeline Dependencies:** Landing Zone Accelerator on AWS (LZA) and Control Tower Account Factory for Terraform (AFT) requires AWS CodeBuild and CodePipeline services for its deployment automation and ongoing configuration management.
**ESC Launch Service Gap:** CodeBuild and CodePipeline are **not currently included** in the initial AWS European Sovereign Cloud launch services, making the deployment of those solutions currently impossible in ESC.
**Alternative Approach:** Terraform/OpenTofu-based solutions like Nuvibit Terraform Collection (NTC) can deploy to ESC immediately using available services and don't have a mandatory dependency on CodeBuild/CodePipeline.
:::
---
#### `Pattern 1` Individual Pipelines per Partition
**Nuvibit Terraform Collection (NTC)**
*Figure 8a: Independent CI/CD pipelines with partition-specific deployment workflows*
**Landing Zone Accelerator on AWS (LZA)**
*Figure 8b: Independent CI/CD pipelines with partition-specific deployment workflows*
This pattern maintains completely separate CI/CD pipelines for each partition, providing maximum isolation and partition-specific optimisation whilst requiring careful coordination to maintain consistency across deployments.
**Implementation:** Deploy separate CI/CD infrastructure in each partition or use external CI/CD platforms with partition-specific pipelines. Each pipeline handles source code checkout, testing, artifact creation, and deployment for its respective partition independently. Authentication, service endpoints, and deployment targets remain partition-specific throughout the pipeline execution.
**Benefits:** Complete pipeline isolation with no cross-partition dependencies, partition-specific optimisation for testing and deployment strategies, clear operational boundaries aligned with compliance requirements, and independent failure domains preventing cascading issues across partitions.
**Challenges:** Code duplication across pipeline configurations increases maintenance overhead, configuration drift risk between partition-specific pipelines, separate artifact management requiring manual synchronisation, and increased operational complexity for platform teams managing multiple pipeline infrastructures.
**Coordination Mechanisms:** Version tagging strategies ensure consistent releases across partitions, shared configuration templates minimise pipeline code duplication, cross-partition promotion workflows enable testing in one partition before deploying to another, and unified monitoring provides visibility across all partition-specific pipelines.
:::tip OIDC Authentication Best Practice
**Use OpenID Connect (OIDC) for Authentication of External Pipelines:** CI/CD pipelines should use OIDC identity providers to authenticate with AWS instead of static access keys. OIDC provides temporary, scoped credentials that improve security and eliminate the need to manage long-lived access keys in pipeline configurations.
**ESC OIDC Configuration:** For AWS European Sovereign Cloud, ensure your OIDC identity provider is configured with the ESC-specific STS endpoint:
- **ESC STS Endpoint:** `sts.eusc-de-east-1.amazonaws.eu` (Brandenburg region)
- **Commercial STS Endpoint:** `sts.amazonaws.com` (default)
**Implementation:** Configure your CI/CD platform (GitHub Actions, GitLab CI, Azure DevOps, etc.) to assume IAM roles via OIDC rather than using stored AWS access keys. This provides automatic credential rotation, improved audit trails, and eliminates credential storage security risks.
:::
---
#### `Pattern 2` Unified Pipelines for Multi-Partition Deployment
**Nuvibit Terraform Collection (NTC)**
*Figure 9a: Single pipeline with multi-partition deployment capabilities*
**Landing Zone Accelerator on AWS (LZA)**
:::warning Multi-Partition Limitation
**Landing Zone Accelerator on AWS cannot be deployed in a unified pattern.**
LZA maps to a single AWS Organization and requires complete duplication of configurations for multi-partition deployments. Each partition needs its own LZA setup with separate configuration files, organizational structures, and operational procedures.
For unified multi-partition operations, consider Terraform/OpenTofu-based solutions like the Nuvibit Terraform Collection (NTC) that natively support provider aliasing and shared configuration templates.
:::
This pattern uses a single CI/CD pipeline that can deploy to multiple partitions from shared source configurations, providing operational efficiency and consistency whilst handling partition-specific deployment requirements through conditional logic and feature flags.
**Implementation:** Single CI/CD pipeline with partition-aware deployment stages that can target multiple AWS partitions based on configuration parameters. Pipeline includes conditional logic to handle service availability differences, partition-specific authentication mechanisms, and environment-specific deployment parameters.
**Benefits:** Single source of truth for deployment configurations reduces maintenance overhead, consistent deployment processes across all partitions, shared artifact management with unified promotion workflows, and reduced operational complexity through single pipeline management interface.
**Challenges:** Increased pipeline complexity handling multiple partition scenarios, potential cascading failures affecting multiple partitions simultaneously, higher skill requirements for teams managing multi-partition pipeline logic, and dependency on CI/CD platforms supporting complex conditional deployment workflows.
**Partition-Aware Features:** Dynamic endpoint configuration based on target partition, conditional resource deployment handling service availability gaps, partition-specific authentication and credential management, and environment-specific testing and validation strategies.
**Example: Multi-Partition Configuration with Nuvibit Terraform Collection (NTC)**
```hcl
# --------------------------------------------------------------------------------------------
# ¦ PROVIDER - MULTI-PARTITION
# --------------------------------------------------------------------------------------------
provider "aws" {
alias = "aws_frankfurt"
region = "eu-central-1"
# OpenID Connect (OIDC) integration
assume_role_with_web_identity {
role_arn = "arn:aws:iam::111111111111:role/oidc-role"
session_name = "unified-pipeline"
web_identity_token_file = "/tmp/web-identity-token"
}
}
provider "aws" {
alias = "aws_eusc_brandenburg"
region = "eusc-de-east-1"
# OpenID Connect (OIDC) integration
assume_role_with_web_identity {
role_arn = "arn:aws-eusc:iam::222222222222:role/oidc-role"
session_name = "unified-pipeline"
web_identity_token_file = "/tmp/web-identity-token"
}
}
# --------------------------------------------------------------------------------------------
# ¦ LOCALS
# --------------------------------------------------------------------------------------------
# Define shared configuration that will be deployed across multiple partitions
locals {
organizational_unit_paths = [
"/root/core",
"/root/sandbox",
"/root/suspended",
"/root/transitional",
"/root/workloads",
"/root/workloads/prod",
"/root/workloads/dev",
"/root/workloads/test"
]
}
# --------------------------------------------------------------------------------------------
# ¦ NTC ORGANIZATIONS - COMMERCIAL
# --------------------------------------------------------------------------------------------
module "ntc_organizations" {
source = "github.com/nuvibit-terraform-collection/terraform-aws-ntc-organizations?ref=X.X.X"
# list of nested (up to 5 levels) organizational units
organizational_unit_paths = local.organizational_unit_paths
# additional inputs...
providers = {
aws = aws.aws_frankfurt
}
}
# --------------------------------------------------------------------------------------------
# ¦ NTC ORGANIZATIONS - ESC
# --------------------------------------------------------------------------------------------
module "ntc_organizations_esc" {
source = "github.com/nuvibit-terraform-collection/terraform-aws-ntc-organizations?ref=X.X.X"
# list of nested (up to 5 levels) organizational units
organizational_unit_paths = local.organizational_unit_paths
# additional inputs...
providers = {
aws = aws.aws_eusc_brandenburg
}
}
```
---
#### Multi-Partition CI/CD Pattern Comparison
| **Pattern** | **Best For** | **Pros** | **Cons** | **Operational Model** | **Complexity** | **Consistency** |
|-------------|--------------|----------|----------|-----------------------|----------------|-----------------|
| **1. Individual Pipelines per Partition** | Organizations prioritizing maximum partition isolation, partition-specific deployment requirements, strict compliance boundaries | ✅ Complete pipeline isolation
✅ Partition-specific optimisation
✅ Independent failure domains
✅ Clear operational boundaries
✅ Supports any CI/CD platform | ❌ Pipeline code duplication
❌ Configuration drift risk
❌ Separate artifact management
❌ Increased maintenance overhead
❌ Complex cross-partition coordination | **Separated Operations**
Independent pipeline teams or processes | **Medium**
Duplicated but isolated | **Manual**
Requires coordination mechanisms |
| **2. Unified Pipelines for Multi-Partition** | Organizations with advanced CI/CD maturity, emphasis on consistency, unified operational preferences | ✅ Single source of truth
✅ Consistent deployment processes
✅ Shared artifact management
✅ Reduced operational overhead
✅ Unified promotion workflows | ❌ Increased pipeline complexity
❌ Cross-partition failure risk
❌ Higher skill requirements
❌ Platform dependency for multi-partition support
❌ Potential cascading issues | **Unified Operations**
Single team managing multi-partition pipeline | **High**
Complex conditional logic | **Automated**
Built-in consistency mechanisms |
**Summary:**
* Infrastructure as Code is essential for consistent multi-partition configuration management
* Dynamic resource discovery prevents hardcoded partition dependencies
* ESC introduces endpoint and service availability differences requiring careful handling
* CI/CD pattern selection depends on organizational maturity and isolation requirements
---
### 9.3 Identity and Access Management (SSO)
Managing identity and access across partitions requires careful consideration of authentication patterns, permission management, and operational complexity. Organizations face four primary approaches based on their identity infrastructure maturity and external system dependencies.
**Infrastructure as Code: The Foundation for Multi-Partition Identity Management**
Infrastructure as Code is absolutely critical for managing IAM Identity Center across multiple partitions without configuration drift. Manual console-based configuration of permission sets, account assignments, and user/group mappings quickly becomes operationally unsustainable and introduces significant security risks when scaled across partitions.
**Preventing Configuration Drift:** IaC templates ensure identical identity configurations deploy across partitions, with version control tracking all permission set changes and automated drift detection identifying deviations between partitions. This eliminates the manual errors that commonly occur when administrators configure identity settings separately in each partition.
**Permission Set Consistency:** Template-driven permission set deployments guarantee that access controls remain consistent across partitions, enabling security teams to verify permissions through code review rather than partition-by-partition inspection. Policy-as-code approaches embed access requirements directly into infrastructure definitions.
**Account Assignment Automation:** Automated account assignment workflows ensure users receive consistent access across appropriate partitions based on their role and data classification requirements. Templates can deploy conditional assignments based on partition-specific service availability or compliance requirements.
---
#### `Pattern 1` Independent Identity Centers Without External IdP
*Figure 10: Independent Identity Centers with separate user stores*
Organizations without external identity providers such as Microsoft Entra ID or Okta must maintain separate IAM Identity Center instances with independent user stores across partitions. This approach provides maximum simplicity but introduces significant operational overhead and user experience challenges.
**Implementation:** Deploy IAM Identity Center in each partition with separate user directories. Users must register separately in each partition, set independent passwords, and configure separate multi-factor authentication devices. Each partition provides distinct access portal URLs requiring separate bookmark management.
**User Experience:** Users maintain separate credentials for each partition and must remember which applications reside in which partition. Password policies, MFA requirements, and account lifecycle management operate independently.
**Operational Considerations:** Identity administrators must maintain separate user directories, duplicate password reset procedures, and manage independent MFA device registrations. User onboarding requires separate account creation workflows for each partition where access is required.
**Security Implications:** Independent MFA devices reduce security correlation across partitions but provide stronger isolation if one partition is compromised. Password complexity and rotation policies can differ between partitions unless explicitly standardized through operational procedures.
:::warning Operational Complexity
Independent identity centers create significant operational challenges:
**Duplicate User Management:** Every user requiring access to both partitions needs separate account creation, password management, and MFA configuration. This doubles administrative overhead and increases the likelihood of configuration inconsistencies.
**Inconsistent Access Patterns:** Users may have different permission levels across partitions due to separate assignment processes, creating security risks and compliance challenges. Manual synchronization of access rights becomes error-prone at scale.
**Support Fragmentation:** Password resets, account lockouts, and MFA issues require partition-specific support procedures. Help desk teams need training on multiple systems and access to separate administrative consoles.
:::
---
#### `Pattern 2` Identity Centers with External IdP Integration
*Figure 11: External IdP integration with SCIM synchronization*
External identity providers such as Microsoft Entra ID or Okta serve as the authoritative source for user identities and group memberships across partitions. SCIM (System for Cross-domain Identity Management) protocols synchronize user and group information to IAM Identity Center instances in both partitions.
**Implementation:** Configure SCIM provisioning from external IdP to IAM Identity Center instances in both partitions. Users and groups synchronize automatically, maintaining consistent identity representation whilst preserving partition isolation. External IdP provides centralized authentication with partition-specific authorization.
**User Experience:** Users access a centralized application portal (such as myapps.microsoft.com, Okta dashboard, or corporate intranet) containing links to partition-specific AWS access portals. Single sign-on (SSO) provides seamless authentication to both partitions with partition-aware application tiles.
**Permission Management:** Permission sets replicate across partitions with partition-specific adaptations for service availability differences. Attribute-based access control (ABAC) patterns use user attributes and group memberships to determine access rights across partitions. Role-based access control (RBAC) provides structured permission hierarchies that adapt to partition capabilities.
**Group-Based Access Control:** External IdP groups control access to specific partitions and permission levels. Groups like "ESC-Developers" and "Commercial-Admins" provide granular control over who can access which partition with what permissions. Group membership changes in the external IdP automatically propagate to appropriate partitions via SCIM.
---
#### `Pattern 3` External IdP with Just-in-Time Elevated Access
*Figure 12: Just-in-time elevated access through external IdP automation*
Organizations requiring temporary elevated permissions can implement just-in-time (JIT) access patterns through external IdP automation. This approach provides time-bound administrative access with appropriate approval workflows and audit trails across partitions.
**Implementation:** Custom automation workflows temporarily add users to privileged groups in the external IdP, triggering SCIM synchronization to grant elevated permissions in target partitions. Approval workflows gate access requests with time-bound assignments that automatically expire. Integration with ticketing systems provides audit trails and business justification.
**Workflow Process:** Users request elevated access through self-service portals or API integrations, specifying justification, duration, and target partition(s). Approval workflows route requests to appropriate managers or security teams. Upon approval, automation temporarily adds users to privileged IdP groups, enabling elevated access that automatically expires at the specified time.
**Cross-Partition Coordination:** Automation workflows can grant elevated access across multiple partitions simultaneously or independently based on request requirements. Permission elevation in ESC may require separate approval workflows due to sovereignty requirements, whilst commercial partition access follows standard procedures.
**Audit and Compliance:** All elevation requests, approvals, and access grants generate comprehensive audit logs across external IdP and AWS CloudTrail. Time-bound access ensures privileged permissions don't persist beyond business requirements, reducing security exposure and simplifying compliance reporting.
:::info AWS TEAM Limitation
**AWS TEAM (Temporary Elevated Access Management)** is a custom AWS solution for just-in-time access management. However, AWS TEAM does not support multi-partition environments and must be deployed independently in each partition where elevated access is required.
**Multi-Partition Implications:** Organizations using AWS TEAM must:
- Deploy separate TEAM instances per partition with independent workflows
- Maintain separate approval processes and audit trails
- Train administrators on partition-specific TEAM operations
- Accept operational overhead of managing multiple TEAM deployments
**Alternative Approaches:** External IdP automation or third-party JIT solutions provide better multi-partition support with unified workflows and centralized audit trails.
:::
---
#### `Pattern 4` Third-Party Just-in-Time Access Tools
*Figure 13: Third-party just-in-time access management platform*
Specialized third-party tools like Apono, CyberArk, Tenable, or Entitle provide advanced just-in-time access management with single entry points and sophisticated approval workflows. These platforms offer unified access request interfaces whilst handling partition-specific integration requirements.
**Implementation:** Deploy third-party JIT platforms with custom integrations to each AWS partition. Platforms provide centralized request interfaces with approval workflows that can route to partition-specific approvers. Integration APIs handle permission elevation across multiple partitions through a single user interface.
**Advanced Features:** Third-party tools often provide sophisticated features including risk-based access decisions, session recording, privileged account discovery, and automated access reviews. Integration with identity governance platforms enables comprehensive access certification and compliance reporting.
**Single Pane of Glass:** Users submit access requests through unified interfaces without needing to understand partition boundaries. Administrative teams manage approval workflows, policies, and compliance reporting through centralized dashboards that span multiple AWS partitions and cloud providers.
**Custom Integration Requirements:** Each third-party tool requires custom integration development to support multiple AWS partitions effectively. Integration complexity varies significantly between platforms, with some providing built-in multi-cloud support whilst others require extensive customization.
:::warning Third-Party ESC Support
**ESC Compatibility:** Third-party identity and access management tools are expected to support AWS European Sovereign Cloud following general availability, but support is not guaranteed from day zero.
**Expected Challenges:**
- **Integration Development:** Vendors need time to develop and test ESC-specific integrations
- **API Compatibility:** ESC-specific endpoints and authentication patterns may require platform updates
- **Feature Parity:** Initial ESC support may lack feature parity with commercial AWS integrations
- **Certification Timelines:** Security certifications and compliance validations may delay ESC support
**Planning Recommendations:** Organizations should engage with identity platform vendors early to understand ESC roadmaps and support timelines. Plan for potential delays or limitations in third-party tool support during ESC early adoption phases.
:::
---
#### Multi-Partition Identity Pattern Comparison
| **Pattern** | **Best For** | **Pros** | **Cons** | **User Experience** | **Complexity** | **Cost Profile** |
|-------------|--------------|----------|----------|---------------------|----------------|------------------|
| **1. Independent Identity Centers** | Small organizations without external IdP infrastructure, maximum partition isolation requirements | ✅ Maximum partition isolation
✅ No external dependencies
✅ Simple initial setup
✅ AWS-native authentication
✅ No additional licensing | ❌ Duplicate user management overhead
❌ Inconsistent access patterns
❌ Multiple credential sets per user
❌ Fragmented support procedures
❌ Manual synchronization required | **Poor**
Multiple logins, passwords, MFA devices | **Medium**
Dual administration | **Low**
No additional licensing costs;
High operational overhead |
| **2. External IdP Integration** | Organizations with existing IdP infrastructure, need for consistent identity management, SCIM provisioning capabilities | ✅ Centralized identity management
✅ Automatic user/group synchronization
✅ Consistent permission models
✅ Single authentication source
✅ Familiar user experience | ❌ External IdP dependency
❌ SCIM configuration complexity
❌ Potential sync delays
❌ Additional licensing costs
❌ Permission set replication overhead | **Good**
Centralized portal with partition links | **Medium**
SCIM configuration & maintenance | **Medium**
External IdP licensing;
SCIM provisioning costs |
| **3. External IdP JIT Access** | Organizations requiring temporary elevated permissions, strong audit requirements, time-bound administrative access | ✅ Time-bound elevated access
✅ Comprehensive audit trails
✅ Automated approval workflows
✅ Centralized request interface
✅ Cross-partition coordination | ❌ Custom automation development
❌ Complex approval workflow design
❌ External IdP dependency
❌ Potential sync delays for elevation
❌ Limited to IdP group-based permissions | **Good**
Self-service elevation requests | **High**
Custom automation & workflows | **Medium-High**
External IdP licensing;
Custom development costs |
| **4. Third-Party JIT Tools** | Large enterprises with complex access requirements, advanced audit needs, multi-cloud environments | ✅ Advanced JIT capabilities
✅ Unified access request interface
✅ Sophisticated approval workflows
✅ Session recording & monitoring
✅ Multi-cloud platform support | ❌ Additional platform licensing
❌ Custom integration development
❌ Vendor dependency
❌ Potential ESC support delays
❌ Complex platform management | **Excellent**
Single interface for all access requests | **High**
Platform integration & management | **High**
Third-party platform licensing;
Integration development costs |
**Summary:**
* Identity management complexity increases significantly across partitions without external IdP integration
* External IdP integration provides the best balance of user experience and operational efficiency
* Just-in-time access patterns require careful design but significantly improve security posture
* Infrastructure as Code is essential for maintaining consistent identity configurations across partitions
* Third-party tool support for ESC may be delayed, requiring fallback planning for early adoption
---
### 9.4 Security and Compliance
Maintaining consistent security posture across partitions whilst respecting sovereignty boundaries requires partition‑aware security architectures and compliant telemetry handling. Organizations face three primary approaches based on their operational preferences, sovereignty requirements, and existing security infrastructure investments.
**Infrastructure as Code: The Foundation for Multi-Partition Security Management**
Infrastructure as Code is absolutely critical for achieving multi-partition security and compliance parity whilst preventing configuration drift. Without IaC, maintaining consistent security postures across partitions becomes operationally unsustainable and introduces significant compliance risks.
**Preventing Configuration Drift:** IaC templates ensure identical security configurations deploy across partitions, with version control tracking all changes and automated drift detection identifying deviations. This eliminates the manual configuration errors that commonly occur when managing multiple environments through console-based administration.
**Compliance Parity Assurance:** Template-driven deployments guarantee that compliance controls remain consistent across partitions, enabling auditors to verify control implementation through code review rather than environment-by-environment inspection. Policy-as-code approaches embed compliance requirements directly into infrastructure definitions.
**Partition-Aware Templates:** Use conditional logic and feature flags to adapt to service availability differences between partitions. Templates can deploy alternative implementations based on the current partition, ensuring functional equivalence despite service parity gaps.
**Guardrails Consistency:** Shared guardrails include fundamental security controls such as root account restrictions, encryption requirements, network access limitations, and audit logging mandates. Partition-specific guardrails adapt to service availability, implementing alternative controls when services are unavailable or configuring partition‑aware resource restrictions.
*Figure 14: Guardrails distribution across partitions*
---
#### `Pattern 1` Separate Native AWS Security Operations
*Figure 15: Independent security operations with partition-specific teams*
Operating Security Hub independently in each partition provides native AWS integration whilst maintaining clear sovereignty boundaries. Each partition operates its own security dashboard with partition-specific alerting and response procedures, ensuring ESC security events remain within EU governance domains.
**Implementation:** Deploy Security Hub, GuardDuty, Config, and other security services in both partitions with separate configuration and alerting. Security operations teams maintain partition-specific playbooks and escalation procedures, with alerts routing to appropriate regional or compliance-specific response teams.
**Operational Model:** Dedicated security teams or team members focus on specific partitions, developing deep expertise in partition-specific service availability and operational constraints. Incident response procedures accommodate AWS operational differences between partitions, particularly ESC's EU-resident support model.
**Benefits:** Complete sovereignty compliance with no cross-partition data movement, native AWS tooling integration without additional platform costs, clear operational boundaries aligned with compliance requirements, and simplified compliance auditing with partition-specific evidence trails.
**Dashboard Management:** Separate CloudWatch dashboards, Security Hub findings, and compliance reports maintain clear partition boundaries whilst requiring security analysts to monitor multiple interfaces. Custom tagging strategies help maintain context when switching between partition-specific tools.
---
#### `Pattern 2` Cross-Partition Security Hub Forwarding
*Figure 16: Centralised Security Hub with cross-partition finding forwarding*
Designating one partition's Security Hub as the primary aggregation point enables centralised security operations whilst leveraging native AWS tooling. Lambda functions forward security findings from the secondary partition to the primary Security Hub, providing a single pane of glass within AWS native infrastructure.
**Implementation:** Deploy Security Hub in both partitions but designate one as the primary aggregation point. Lambda functions in the secondary partition consume Security Hub findings and forward them to the primary partition via APIs. Custom tagging and metadata preserve finding origin and partition context.
**Forwarding Architecture:** Event-driven Lambda functions trigger on Security Hub finding updates, transforming and enriching findings with partition context before forwarding via cross-partition API calls. Custom finding formats maintain traceability whilst enabling unified reporting and dashboards.
**Benefits:** Native AWS tooling throughout the security stack, centralised security operations reducing operational overhead, familiar Security Hub interface for security analysts, and reduced third-party licensing costs compared to external platforms.
**Data Residency Considerations:** Careful evaluation required when forwarding ESC security findings to commercial partition Security Hub, as this may violate sovereignty requirements depending on organisational compliance obligations. Consider implementing filtering to exclude sensitive ESC findings from cross-partition forwarding.
---
#### `Pattern 3` Third-Party Security Aggregation Platforms
*Figure 17: Third-party security aggregation with unified dashboards*
External security platforms like Wiz.io, Splunk, QRadar, PagerDuty, and Datadog provide unified security dashboards by aggregating findings from both partitions into a single pane of glass. These platforms offer advanced correlation capabilities, custom alerting, and comprehensive reporting that spans partition boundaries.
**Implementation:** Deploy security services (Security Hub, GuardDuty, Config) in both partitions with API integrations forwarding findings to external platforms. Configure data pipelines to aggregate security telemetry whilst maintaining appropriate metadata for partition identification and compliance tracking.
**Benefits:** Unified security visibility across all environments, advanced correlation and threat hunting capabilities, custom dashboards tailored to organisational needs, and integration with existing security operations workflows. Many platforms provide pre-built connectors for AWS services and can normalise findings across different security tools.
**Advanced Features:** Third-party platforms often provide sophisticated capabilities including machine learning-based anomaly detection, automated incident response workflows, cross-cloud security posture management, and integrated vulnerability assessment that spans multiple cloud providers and on-premises environments.
**Data Residency Considerations:** Organizations must carefully evaluate data residency requirements, particularly for ESC-originated security telemetry. Assessment of whether external platforms can meet sovereignty requirements or if telemetry aggregation violates compliance obligations is essential for ESC adoption.
:::warning ESC Support Disclaimer
**ESC Compatibility:** Third-party security platform support for AWS European Sovereign Cloud (ESC) is expected but not yet guaranteed. Platform vendors are anticipated to develop ESC integrations following general availability, but support timelines, feature parity, and compliance certifications may vary.
**Planning Recommendations:** Organizations should verify ESC compatibility with their chosen security platforms and plan for potential integration delays or feature limitations during ESC early adoption phases.
:::
---
#### Multi-Partition Security Pattern Comparison
| **Pattern** | **Best For** | **Pros** | **Cons** | **Sovereignty** | **Complexity** | **Cost Profile** |
|-------------|--------------|----------|----------|-----------------|----------------|------------------|
| **1. Separate Native AWS Operations** | Organizations with strict sovereignty requirements, simplified compliance auditing, partition-specific SOC teams | ✅ Complete sovereignty compliance
✅ No cross-partition data movement
✅ Native AWS tooling integration
✅ Clear operational boundaries
✅ Simplified compliance auditing | ❌ Operational overhead of dual dashboards
❌ Potential blind spots in attack correlation
❌ Duplicate security tool costs
❌ Increased training requirements
❌ No unified security view | **High**
Complete partition isolation | **Medium**
Dual operations model | **Medium**
Duplicate AWS security service costs;
No additional platform fees |
| **2. Cross-Partition Security Hub Forwarding** | Organizations prioritizing centralized operations, cost optimization, AWS-native security stacks | ✅ Centralized security operations
✅ Native AWS tooling throughout
✅ Familiar Security Hub interface
✅ Reduced third-party costs
✅ Single pane of glass | ❌ Data residency concerns for ESC findings
❌ Lambda execution & API costs
❌ Non-seamless investigation experience
❌ Synchronization complexity
❌ Potential finding duplication | **Low-Medium**
ESC findings forwarded to commercial | **Medium**
Custom forwarding logic | **Low-Medium**
Lambda execution costs;
Cross-partition API calls;
Single AWS security service deployment |
| **3. Third-Party Security Platforms** | Organizations with existing SIEM investments, advanced threat hunting requirements, complex multi-cloud environments | ✅ Unified security visibility
✅ Advanced correlation capabilities
✅ Custom dashboards & alerting
✅ Integration with existing SOC workflows
✅ Multi-cloud platform support | ❌ Additional licensing costs
❌ Data residency compliance risks
❌ External platform dependencies
❌ Integration complexity
❌ Potential vendor lock-in | **Medium**
May require careful ESC telemetry handling | **Medium-High**
Platform integration & management | **Medium-High**
Platform licensing scales with data volume;
API & log forwarding costs |
**Summary:**
* Security patterns range from complete partition separation to unified aggregation with varying sovereignty trade-offs
* Infrastructure as Code is essential for maintaining consistent security configurations across partitions
* Native AWS security operations provide sovereignty compliance but require separate management overhead
* Third-party platforms provide advanced capabilities but require careful data residency evaluation
---
### 9.5 Connectivity
Cross‑partition connectivity represents one of the most significant technical challenges, as AWS provides no native mechanisms for VPC peering, Transit Gateway connectivity, or PrivateLink between partitions. Traditional AWS networking patterns cannot span partition boundaries, forcing organizations to implement alternative connectivity approaches that balance security, performance, and operational complexity.
The connectivity patterns for cross‑partition architectures mirror those used in multi‑cloud and hybrid on‑premises environments. Organizations with experience connecting AWS to other cloud providers (Azure, Google Cloud) or integrating cloud workloads with on‑premises data centres will find familiar architectural patterns and trade‑offs. The same considerations around latency, security, cost, and operational complexity that apply to multi‑cloud connectivity also apply to multi‑partition scenarios.
Three viable patterns address cross‑partition connectivity requirements, each with distinct trade‑offs regarding security, performance, cost, and operational complexity. The selection depends on application requirements, existing infrastructure, security posture, and performance needs.
:::info Traffic Routing Note
**Backbone Network Architecture:** Traffic routing behavior varies by partition due to separate backbone infrastructures:
- **Commercial ↔ GovCloud (US):** Traffic between these partitions remains on AWS's backbone network and does not traverse the public internet, as both partitions share the same global AWS backbone infrastructure.
- **ESC ↔ Commercial/GovCloud:** ESC operates with a completely separate backbone infrastructure (similar to AWS China), meaning cross-partition traffic between ESC and other partitions **will traverse the public internet** rather than AWS's private backbone network. This separation reinforces ESC's sovereignty model but affects network performance and security considerations for cross-partition connectivity.
- **China ↔ Any Partition:** AWS China operates with a separate backbone, so all traffic to/from China regions traverses the public internet.
This backbone separation is fundamental to ESC's sovereignty architecture, ensuring complete infrastructure independence whilst requiring careful planning for cross-partition connectivity patterns.
:::
---
#### `Pattern 1` Connectivity over the Internet using Native TLS Encryption
*Figure 18: TLS encryption at the application layer between partitions using Application Load Balancers (ALBs)*
This pattern leverages application‑native TLS encryption for cross‑partition communication through managed AWS services that provide secure external endpoints. Rather than exposing backend services directly, this approach uses Application Load Balancers (ALBs) or API Gateways as secure intermediaries that handle TLS termination and traffic routing to private backend services.
**Implementation:** Deploy backend services in private subnets within both partitions, configure Application Load Balancers or API Gateways with TLS certificates to provide secure public endpoints, and establish cross‑partition communication through these managed service endpoints. Backend services remain private and communicate only with the load balancers or API Gateways within their respective partitions.
**Security Architecture:** Backend compute resources (EC2, ECS, EKS) operate in private subnets without direct internet access. ALBs or API Gateways serve as the only public‑facing components, handling TLS termination, authentication, and request routing. Security groups restrict backend access to only the load balancer or API Gateway security groups, ensuring no direct public exposure of application services.
**Service Options:**
- **Application Load Balancer (ALB):** Ideal for HTTP/HTTPS traffic with advanced routing capabilities, health checks, and integration with AWS Certificate Manager for automatic TLS certificate management
- **API Gateway:** Optimal for REST APIs, providing built‑in authentication, throttling, caching, and request/response transformation capabilities
- **Network Load Balancer (NLB):** Suitable for non‑HTTP protocols requiring high performance and low latency
**Security Considerations:** Organizations remain responsible for ensuring encryption‑in‑transit modules and algorithms meet compliance requirements. Implement mutual TLS authentication where supported, use AWS Certificate Manager for certificate lifecycle management, and configure appropriate security group rules to restrict access to authorised cross‑partition communication only.
:::warning Misconfiguration Risks
Improper security group configuration or load balancer settings can inadvertently expose backend services directly to the public internet, allowing unintended public-facing traffic rather than the intended secure cross‑partition communication. Implement defence‑in‑depth controls including restrictive security groups that only allow traffic from load balancers, regular security audits of public‑facing endpoints, and automated compliance scanning to detect and alert on unintended public exposure. Use AWS Config rules and Security Hub findings to continuously monitor for compliance violations.
:::
---
#### `Pattern 2` Connectivity using IPSec AWS Site‑to‑Site VPN over the Internet
*Figure 19: Site‑to‑Site VPN between partitions using Transit Gateway and self‑managed EC2‑based appliances*
AWS Site‑to‑Site VPN uses Internet Protocol Security (IPSec) to create encrypted tunnels between partitions, providing network‑layer encryption for applications that cannot support application‑layer encryption or require private connectivity without internet exposure.
**Implementation:** Deploy third‑party virtual appliances (such as Cisco CSR, Palo Alto Networks VM‑Series, Fortinet FortiGate, or open‑source solutions like StrongSwan) in one or both partitions. Configure IPSec tunnels between appliances, with Transit Gateway providing connectivity within each partition. Virtual appliances handle tunnel establishment, encryption, routing, and can provide additional security services including deep packet inspection, intrusion detection/prevention, and application-layer filtering.
**Security Enhancement:** Modern firewall appliances combine VPN capabilities with comprehensive traffic inspection, enabling organizations to implement unified security policies across partition boundaries. These appliances can perform application identification, threat detection, content filtering, and compliance logging whilst maintaining encrypted connectivity between partitions.
**Performance:** Maximum bandwidth per VPN tunnel is 1.25 Gbps. Enable Equal‑Cost Multi‑Path (ECMP) routing to aggregate throughput across multiple VPN connections and scale beyond the default 1.25 Gbps limit. This approach can achieve higher aggregate bandwidth but introduces additional complexity.
**Security Requirements:** Ensure IPSec implementations use NIST‑approved algorithms and FIPS‑validated cryptographic modules to meet compliance requirements. Configure strong authentication and encryption policies appropriate for your security posture.
:::warning Operational Complexity
Pattern 2 introduces operational challenges that require careful planning and ongoing management:
**VPC CIDR Overlap Constraints:** VPC CIDR ranges cannot overlap across partitions when using VPN connectivity. This requires careful IP address space planning between partitions to prevent address conflicts. Consider implementing a centralized IPAM (IP Address Management) strategy to manage address allocation across both partitions.
**Third-Party Appliance Dependencies:** VPN connectivity relies on third-party virtual appliances (EC2 instances) that introduce operational overhead including regular patching, security updates, monitoring, and high availability configuration. If these appliances fail or require maintenance, cross-partition connectivity is disrupted, potentially affecting critical business operations.
**Single Points of Failure:** Without proper redundancy design, VPN appliances can become single points of failure for cross-partition communication. Implement active-passive or active-active clustering with health monitoring and automated failover to maintain connectivity during appliance failures or maintenance windows.
:::
---
#### `Pattern 3` Connectivity through Direct Connect
This hub‑and‑spoke model routes cross‑partition traffic through a customer gateway infrastructure connected via AWS Direct Connect, enabling centralised security controls and traffic inspection. The pattern accommodates two primary deployment scenarios based on existing infrastructure.
**Option A: On‑Premises Datacenter Gateway**
*Figure 20: Connectivity through on‑premises datacenter gateway infrastructure*
For organizations with existing datacenter infrastructure, establish Direct Connect connections from both partitions to the on‑premises datacenter. Deploy firewall and routing appliances in the datacenter to control cross‑partition communication.
- **Implementation:** Connect each partition to on‑premises datacenter using AWS Direct Connect transit virtual interfaces (VIFs)
- **Gateway Infrastructure:** Customer‑managed routing and security appliances in physical datacenter
- **Benefits:** Leverages existing datacenter investments and operational expertise
- **Considerations:** Requires existing datacenter infrastructure and operational teams
**Option B: Cloud Exchange Provider Gateway**
*Figure 21: Connectivity through cloud exchange provider gateway infrastructure*
For organizations without datacenter infrastructure, establish a customer gateway at cloud exchange providers (Equinix, Digital Realty, etc.) with Direct Connect connectivity to both partitions.
- **Implementation:** Deploy virtual customer gateway infrastructure at cloud exchange facilities with Direct Connect connections
- **Gateway Infrastructure:** Virtual appliances (firewalls, routers) hosted at provider facilities
- **Benefits:** No datacenter infrastructure required, provider‑managed physical infrastructure
- **Considerations:** Recurring costs for provider space, power, and connectivity
**Direct Connect Architecture:** Direct Connect gateways are global constructs that enable connectivity to any AWS Region but do not enable BGP prefix propagation between associated Transit Gateways, preventing direct east‑west traffic. Communication occurs through advertised supernets that overlap with VPC address spaces.
**Routing Behaviour:** VPCs can communicate through Direct Connect endpoints when supernets (such as 10.0.0.0/8) are advertised that encompass the VPC address ranges. This enables controlled inter‑VPC communication through customer gateway infrastructure.
**Performance Impact:** Hair‑pinning traffic through customer gateway infrastructure introduces additional latency, data transfer out (DTO) costs, and Transit Gateway data transfer charges. Network performance depends on gateway infrastructure capacity and Direct Connect location proximity.
:::info Direct Connect Locations
**ESC Direct Connect Availability:** AWS European Sovereign Cloud will launch with Direct Connect support, but the specific Direct Connect locations have not yet been announced.
**Impact on Cross-Partition Connectivity:** Organizations planning to connect ESC and commercial partitions via Direct Connect (Pattern 3) should anticipate:
- **New Cross-Connect Requirements:** ESC may launch at different Direct Connect facilities than existing commercial AWS locations, requiring additional cross-connects between facilities
- **Increased Infrastructure Costs:** Cross-connects between different Direct Connect locations typically incur monthly recurring charges and installation fees
- **Extended Lead Times:** Establishing new cross-connects can take weeks or months depending on facility availability and carrier provisioning
- **Geographic Considerations:** ESC Direct Connect locations may prioritize EU facilities, potentially affecting latency and routing optimization for global organizations
**Planning Recommendations:** Organizations should budget for potential additional cross-connect costs and extended deployment timelines when designing Direct Connect-based cross-partition connectivity. Consider engaging AWS sales teams early to understand ESC Direct Connect location planning and availability timelines.
:::
:::warning Infrastructure Dependencies
Pattern 3 introduces infrastructure and operational dependencies that require careful consideration:
**VPC CIDR Planning Constraints:** Direct Connect requires that VPC CIDR ranges do not overlap with on-premises networks (for Option A) and across partitions. This demands comprehensive IP address space planning between on-premises and partitions to prevent routing conflicts and ensure proper traffic flow.
**Direct Connect Redundancy Requirements:** Achieving high availability requires redundant Direct Connect connections across multiple locations and diverse paths to avoid single points of failure. Organizations must establish multiple Direct Connect connections at different facilities, implement diverse network paths, and ensure proper BGP routing configurations. This significantly increases infrastructure complexity and costs, as organizations need multiple Direct Connect ports, cross-connects, and carrier relationships to achieve enterprise-grade redundancy.
**Customer Gateway Management:** Success depends on properly configured, maintained, and managed customer gateway infrastructure (routers, firewalls). These gateways require regular firmware updates, security patching, configuration management, and 24/7 monitoring. Gateway failures directly impact cross-partition connectivity, making robust operational procedures and redundancy planning essential.
:::
---
#### Security Considerations Across All Patterns
All cross‑partition connectivity patterns require careful security implementation:
- **Split‑horizon DNS:** Ensure appropriate name resolution per partition to prevent misrouted traffic
- **Egress controls:** Implement strict egress filtering to prevent unintended cross‑partition communication
- **TLS policy enforcement:** Mandate TLS encryption for all cross‑partition application traffic regardless of network‑layer encryption
- **Network segmentation:** Use security groups and NACLs to restrict traffic to authorised flows only
- **Monitoring and logging:** Implement comprehensive flow logging and traffic analysis for all cross‑partition communication
- **Certificate management:** Establish robust PKI for TLS certificates and VPN authentication
#### Performance and Cost Optimisation
Optimise cross‑partition connectivity for performance and cost:
- **Latency optimisation:** Select connectivity patterns and routing that minimise additional latency
- **Bandwidth planning:** Size connections and appliances appropriately for expected traffic volumes
- **Caching strategies:** Implement intelligent caching to reduce cross‑partition traffic
- **Data transfer optimisation:** Use compression and efficient data formats to minimise bandwidth consumption
- **Cost monitoring:** Track data transfer costs and optimise traffic patterns based on usage analysis
---
#### Cross-Partition Connectivity Pattern Comparison
| **Pattern** | **Best For** | **Pros** | **Cons** | **Performance** | **Complexity** | **Cost Profile** |
|-------------|--------------|----------|----------|-----------------|----------------|------------------|
| **1. TLS over Internet** | Modern applications with native TLS support, API-based integrations, microservices | ✅ Excellent performance
✅ AWS best practices
✅ Simple implementation
✅ No additional infrastructure | ❌ Requires application-level TLS
❌ Not suitable for legacy apps
❌ Public endpoint required
❌ No centralized traffic inspection | **High**
Minimal latency | **Low**
Standard ALB/API Gateway | **Low-Medium**
ALB/API Gateway + NAT Gateway fees;
Internet data transfer rates |
| **2. IPSec VPN** | Legacy applications, network-layer encryption requirements, centralized security policies within AWS partitions | ✅ Works with any application
✅ Network-layer encryption
✅ Centralized security at VPN appliances
✅ Predictable performance
✅ Familiar VPN patterns | ❌ 1.25 Gbps per tunnel limit
❌ Higher latency
❌ Appliance management overhead
❌ Costs scale with bandwidth | **Medium**
VPN tunnel overhead | **Medium**
Virtual appliance management | **Medium-High**
VPN connection fees scale linearly;
Virtual appliance costs;
Higher data transfer rates |
| **3. Direct Connect** | Centralized security controls at customer premises, highest bandwidth requirements, existing datacenter integration | ✅ Centralized security at customer gateway
✅ Highest bandwidth potential
✅ Works with/without datacenters
✅ Predictable performance
✅ Long-term data transfer savings | ❌ Higher latency (hair-pinning)
❌ High initial investment
❌ Gateway infrastructure dependency
❌ Complex redundancy requirements | **Medium**
Varies by infrastructure | **High**
Gateway infrastructure + redundancy | **High initial, Low ongoing**
Direct Connect port fees;
Gateway infrastructure costs;
Lower data transfer rates at scale |
**Summary:**
- Three distinct patterns address cross‑partition connectivity with different trade‑offs
- Application‑layer TLS provides optimal performance but requires native encryption support
- IPSec VPN enables network‑layer encryption for legacy applications at performance cost
- Direct Connect routing centralises security controls but introduces latency and complexity
---
### 9.6 Observability and Operations
Unified observability across partitions whilst maintaining compliant data residency requires careful consideration of telemetry collection, cross‑partition correlation, and partition‑aware incident response workflows. Organizations must balance operational visibility requirements with sovereignty constraints and data residency regulations.
The fundamental challenge lies in providing unified operational views whilst respecting partition boundaries and service availability differences. CloudWatch, X‑Ray, and other observability services operate independently within each partition, requiring coordination mechanisms to achieve comprehensive monitoring and alerting across multi‑partition environments.
Customer incident response playbooks require adaptation to ESC's operational model whilst maintaining consistent service level objectives across partitions.
---
#### `Pattern 1` Independent Observability per Partition
*Figure 22: Independent observability with partition-specific operational procedures*
This pattern maintains completely separate observability stacks in each partition, providing maximum data residency compliance and partition isolation whilst requiring manual coordination for cross‑partition operational visibility and incident correlation.
**Implementation:** Deploy independent CloudWatch, X‑Ray, and monitoring infrastructure in each partition with separate dashboards, alerting configurations, and operational procedures. Each partition operates its own observability stack without cross‑partition data sharing or automated correlation.
**Data Residency:** Telemetry data never leaves its originating partition, ensuring complete compliance with data residency requirements. Metrics, logs, traces, and operational data remain within appropriate sovereignty boundaries throughout their lifecycle.
**Operational Model:** Platform teams maintain separate monitoring dashboards and alerting systems for each partition. Incident response procedures operate independently per partition, with manual coordination required for issues affecting multiple partitions simultaneously.
**Benefits:** Maximum data residency compliance with no cross‑partition data movement, complete partition isolation eliminating cross‑partition failure scenarios, simplified compliance boundaries with clear data provenance, and independent operational procedures that can accommodate partition‑specific constraints.
**Challenges:** Manual correlation required for cross‑partition issues, duplicate dashboard and alert configuration maintenance, separate operational procedures increasing response complexity, and potential blind spots for issues spanning multiple partitions.
**Use Cases:** Organizations with strict data residency requirements, regulatory frameworks prohibiting cross‑border telemetry data, maximum partition isolation priorities, and acceptance of manual cross‑partition correlation overhead.
---
#### `Pattern 2` Centralized Observability with Log Forwarding
*Figure 23: Log forwarding to main partition for centralized analysis*
This pattern forwards telemetry data from distributed partitions to a centralized observability stack in a designated "main" partition, providing unified operational views whilst requiring careful consideration of data residency implications and cross‑partition connectivity requirements.
**Implementation:** Configure log forwarding from ESC partition to commercial partition (or vice versa) using Kinesis Data Firehose with HTTP endpoint delivery to Lambda function URLs, API Gateway endpoints, or other HTTP-accessible services in the target partition. Centralized partition aggregates telemetry data for unified analysis, alerting, and operational dashboards.
**Data Flow Architecture:** ESC partition forwards logs, metrics, and traces to the commercial partition over the internet through secure HTTPS endpoints. Kinesis Data Firehose delivers log streams to Lambda function URLs or API Gateway endpoints in the target partition, which then process and store the data in centralized CloudWatch, OpenSearch, or other analysis tools providing unified operational views with data from both partitions.
**Compliance Considerations:** Log forwarding may conflict with data residency requirements depending on regulatory interpretation and data classification. Organizations must evaluate whether telemetry forwarding violates sovereignty constraints or compliance obligations.
**Benefits:** Unified operational dashboards providing complete cross‑partition visibility, centralized alerting with correlation across partitions, single operational interface reducing complexity for platform teams, and shared observability infrastructure reducing maintenance overhead.
**Challenges:** Potential data residency compliance violations requiring legal evaluation, cross‑partition connectivity dependencies affecting reliability, network egress costs for telemetry forwarding, and potential data loss during connectivity disruptions.
**Use Cases:** Organizations with acceptable data residency implications for telemetry data, established cross‑partition connectivity infrastructure, unified operational team preferences, and tolerance for compliance complexity in observability data handling.
:::warning Data Residency Implications
**Regulatory Compliance Risk:** Forwarding telemetry data across partitions may violate data residency requirements depending on regulatory interpretation and data classification schemes.
**Legal Evaluation Required:** Organizations must engage legal and compliance teams to evaluate whether operational telemetry forwarding conflicts with sovereignty obligations, particularly for:
- **Personal Data in Logs:** Application logs may contain customer identifiers or personal information subject to GDPR residency requirements
- **Business Data Correlation:** Aggregated telemetry patterns may reveal business-sensitive information requiring specific jurisdictional protection
- **Regulatory Interpretation:** Different regulatory frameworks may classify operational telemetry differently regarding cross-border transfer restrictions
**Mitigation Strategies:** Implement data classification and filtering at forwarding points, anonymize or pseudonymize telemetry data before cross‑partition transfer, maintain parallel independent observability as fallback, and document compliance rationale for regulatory examination.
:::
---
#### `Pattern 3` External Third‑Party Observability Platform
*Figure 24: Third-party observability platform aggregating telemetry from multiple partitions*
This pattern uses external third‑party observability platforms to aggregate telemetry data from multiple partitions, providing unified operational views whilst maintaining clear data provenance and potentially addressing data residency concerns through platform jurisdiction selection.
**Implementation:** Deploy observability agents or configure native integrations to forward telemetry data from both partitions to external platforms such as Datadog, New Relic, Splunk, or Dynatrace. External platforms provide unified dashboards, alerting, and analysis capabilities across partitions.
**Platform Selection:** Choose observability platforms with appropriate jurisdictional presence to align with data residency requirements. EU‑based observability platforms or platforms with EU data centers may provide better alignment with ESC sovereignty objectives.
**Integration Architecture:** Use native AWS integrations, observability agents, or API‑based forwarding to send telemetry data to external platforms. Maintain consistent data classification and filtering across partitions to ensure appropriate data handling.
**Benefits:** Unified cross‑partition observability without AWS‑specific limitations, advanced analytics and correlation capabilities beyond native AWS services, potential data residency alignment through platform jurisdiction selection, and vendor expertise in multi‑cloud observability scenarios.
**Challenges:** Additional vendor relationships and licensing costs, external dependency for critical operational visibility, potential data residency complications depending on platform architecture, and vendor lock‑in risks for observability infrastructure.
**Advanced Features:** Third‑party platforms often provide sophisticated capabilities including anomaly detection, predictive analytics, automated incident correlation, and integration with incident management workflows that span multiple cloud providers and partitions.
**Use Cases:** Organizations with existing third‑party observability investments, requirements for advanced analytics beyond native AWS capabilities, acceptable external dependencies for operational visibility, and budget for additional observability platform licensing.
:::info Third‑Party Platform Considerations
**Jurisdiction Alignment:** Select observability platforms with data processing and storage aligned to your sovereignty requirements:
- **EU‑Based Platforms:** European observability vendors or EU data centers for ESC alignment
- **Jurisdictional Flexibility:** Platforms offering data residency controls and regional deployment options
- **Compliance Certifications:** Platforms with relevant compliance certifications (ISO 27001, SOC 2, etc.)
**ESC Integration Support:** Third‑party observability platforms may require time to develop ESC‑specific integrations:
- **Early Adoption Risk:** Limited platform support during ESC early adoption phases
- **Integration Development:** Vendors need time to develop and test ESC‑specific connectors
- **Feature Parity:** Initial ESC support may lack feature parity with commercial AWS integrations
**Planning Recommendations:** Engage with observability platform vendors early to understand ESC roadmaps and integration timelines. Plan for potential delays or limitations in platform support during ESC adoption.
:::
---
#### Multi‑Partition Observability Pattern Comparison
| **Pattern** | **Best For** | **Pros** | **Cons** | **Data Handling** | **Operational Model** | **Compliance** |
|-------------|--------------|----------|----------|-------------------|-----------------------|----------------|
| **1. Independent Observability per Partition** | Organizations with strict data residency requirements, maximum partition isolation priorities | ✅ Maximum data residency compliance
✅ Complete partition isolation
✅ Simplified compliance boundaries
✅ No cross‑partition dependencies
✅ Partition‑specific operational procedures | ❌ Manual cross‑partition correlation
❌ Duplicate configuration maintenance
❌ Separate operational procedures
❌ Potential blind spots
❌ Increased operational complexity | **Isolated**
Data never leaves partition | **Separated**
Independent procedures per partition | **Maximum**
Clear compliance boundaries |
| **2. Centralized Observability with Log Forwarding** | Organizations with unified operational preferences, acceptable data residency implications for telemetry | ✅ Unified operational dashboards
✅ Centralized alerting and correlation
✅ Single operational interface
✅ Reduced infrastructure overhead
✅ Complete cross‑partition visibility | ❌ Potential compliance violations
❌ Cross‑partition connectivity dependency
❌ Network egress costs
❌ Data loss risk during outages
❌ Complexity in data classification | **Centralized**
Forwarded to main partition | **Unified**
Single operational interface | **Complex**
Requires legal evaluation |
| **3. External Third‑Party Observability Platform** | Organizations with existing platform investments, requirements for advanced analytics, acceptable external dependencies | ✅ Advanced analytics capabilities
✅ Unified multi‑partition visibility
✅ Vendor expertise and features
✅ Potential jurisdiction alignment
✅ Multi‑cloud support | ❌ Additional licensing costs
❌ External dependency for operations
❌ Potential vendor lock‑in
❌ Platform‑specific data residency
❌ ESC integration development delays | **External**
Forwarded to third‑party platform | **Vendor‑Managed**
Platform‑specific interfaces | **Platform‑Dependent**
Varies by vendor jurisdiction |
**Summary:**
* Observability patterns balance operational visibility with sovereignty and compliance requirements
* Independent observability provides maximum compliance but requires manual correlation overhead
* Centralized patterns improve operational efficiency but introduce compliance complexity
* Third‑party platforms offer advanced capabilities but introduce external dependencies and costs
* Pattern selection should consider data classification, regulatory requirements, and operational maturity
---
### 9.7 Backup and Recovery
Multi‑partition backup and recovery introduces significant complexity beyond traditional single‑partition operations. Organizations must navigate cross‑partition data movement constraints, service availability differences, and sovereignty requirements whilst maintaining comprehensive data protection and recovery capabilities across distributed environments.
**The Multi-Partition Backup Challenge**
Traditional AWS backup strategies assume unified control planes and cross‑region replication capabilities within a single partition. Multi‑partition environments break these assumptions, requiring alternative approaches for data protection, disaster recovery, and business continuity across partition boundaries.
**Service Availability Gaps:** AWS Backup availability may differ between partitions, with ESC potentially launching with limited backup service capabilities compared to the mature commercial partition. Organizations must plan for service parity evolution and implement alternative solutions for missing capabilities.
**Single Region Limitations:** ESC launches with a single region (Brandenburg, `eusc-de-east-1`), eliminating traditional cross‑region backup patterns within the ESC partition. Organizations cannot leverage multiple ESC regions for geographic backup redundancy until additional ESC regions become available, creating dependency on alternative backup strategies for disaster recovery.
**Cross-Partition Replication Constraints:** Native AWS backup services cannot replicate data directly between partitions, eliminating traditional cross‑region backup patterns. Data protection requires alternative replication mechanisms that respect partition boundaries whilst providing comprehensive coverage.
**Sovereignty and Compliance Implications:** Backup data movement across partitions may violate data residency requirements depending on regulatory interpretation and data classification. Organizations must carefully evaluate whether cross‑partition backup storage conflicts with sovereignty obligations.
**Recovery Time and Point Objectives:** Multi‑partition recovery scenarios may introduce additional complexity and latency compared to single‑partition recovery operations. Organizations must reassess Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) to account for partition‑specific constraints and cross‑partition coordination requirements.
**Operational Complexity:** Managing backup policies, retention schedules, and recovery procedures across multiple partitions increases operational overhead and requires partition‑aware automation to maintain consistency and prevent configuration drift.
:::warning AWS Backup Partition Boundaries
**AWS Backup is Partition-Bound:** AWS Backup operates exclusively within partition boundaries and cannot export backup data to other partitions or offsite. This creates fundamental limitations for cross-partition backup strategies:
**Cross-Partition Limitations:**
- ❌ **Cross-Partition Export:** AWS Backup cannot export or replicate backup data to different AWS partitions
- ❌ **Cross-Partition Sharing:** Backup vaults cannot be shared across partition boundaries
- ❌ **Cross-Partition Recovery:** Direct recovery from AWS Backup to a different partition is not supported
**Implications:** Organizations requiring cross-partition backup capabilities must implement alternative solutions such as application-level backup tools, third-party backup platforms, or custom backup orchestration using S3 replication and external storage systems.
:::
Three primary patterns address multi‑partition backup and recovery requirements, each with distinct trade‑offs regarding sovereignty compliance, operational complexity, and recovery capabilities.
---
#### `Pattern 1` Independent Backup Operations per Partition
*Figure 25: AWS Backup deployed independently in each partition with isolated data protection*
This pattern deploys separate AWS Backup infrastructure in each partition, providing maximum sovereignty compliance by ensuring backup data never crosses partition boundaries. Each partition operates independent backup policies, retention schedules, and recovery procedures without cross‑partition coordination or data sharing.
**Implementation:** Deploy AWS Backup in both partitions with partition‑specific backup vaults, policies, and schedules. Configure backup jobs to protect resources within each partition independently, with recovery operations constrained to the same partition where backup data resides.
**Backup Vault Configuration:** Create separate backup vaults in each partition with appropriate encryption keys, access policies, and retention configurations.
**Policy Management:** Implement consistent backup policies across partitions using Infrastructure as Code templates with partition‑aware configurations. Shared policy definitions adapt to service availability differences between partitions whilst maintaining equivalent data protection coverage.
**Benefits:** Maximum sovereignty compliance with backup data never leaving originating partition, simplified compliance boundaries with clear data provenance, independent recovery operations eliminating cross‑partition dependencies, and familiar AWS‑native backup tooling and procedures.
**Challenges:** No cross‑partition disaster recovery capabilities without additional solutions, duplicate backup infrastructure increasing costs and operational overhead, separate recovery procedures requiring partition‑specific operational knowledge, and potential backup storage optimization limitations due to partition isolation.
**Recovery Scenarios:** Point‑in‑time recovery operates within each partition independently. Geographic disaster recovery within ESC is not possible due to single region availability, making cross‑partition or external backup solutions necessary for comprehensive disaster recovery capabilities. Cross‑partition disaster recovery requires alternative mechanisms such as application‑level replication, database clustering, or external backup solutions that can operate across partition boundaries.
**Use Cases:** Organizations with strict data residency requirements prohibiting cross‑partition data movement, regulatory frameworks requiring complete data sovereignty for backup operations, maximum compliance simplicity priorities, and acceptance of partition‑isolated recovery capabilities.
:::warning AWS Backup Service Availability
**ESC Launch Considerations:** AWS Backup availability in AWS European Sovereign Cloud may be limited during initial launch phases. Organizations should verify AWS Backup service availability and feature parity before implementing partition‑specific backup strategies.
**Single Region Impact:** ESC's single region deployment (Brandenburg) eliminates cross‑region backup capabilities within the ESC partition. Organizations cannot use AWS Backup's cross‑region backup features for geographic redundancy until additional ESC regions become available.
**Mitigation Planning:** Organizations should plan alternative backup approaches for ESC environments until full AWS Backup feature parity is achieved, including manual backup procedures, application‑level backup solutions, cross‑partition backup strategies, or third‑party backup tools for geographic redundancy.
:::
---
#### `Pattern 2` Cross-Partition Backup via Offsite Storage
*Figure 26: Cross‑partition backup coordination through offsite storage infrastructure*
This pattern uses offsite storage infrastructure as an intermediary for cross‑partition backup coordination, enabling disaster recovery capabilities whilst maintaining control over data movement and residency through customer‑managed infrastructure. Offsite storage options include on‑premises datacenters, other cloud providers, or even the alternate AWS partition depending on sovereignty requirements and operational preferences.
**Implementation:** Configure application‑level backup tools (pg_dump, MySQL backup, application exports) to create backup artifacts that are stored in Amazon S3 within each partition. Use AWS DataSync, S3 replication, or custom automation to copy backup artifacts to offsite storage infrastructure for centralized backup management and cross‑partition recovery coordination.
**Application-Level Backup Tools:**
- **Database Backups:** Use native database backup tools (pg_dump, mysqldump, Oracle RMAN) to create portable backup artifacts
- **Application Data:** Implement application‑specific export procedures for business data, configuration, and state information
- **File System Backups:** Use file‑level backup tools for persistent storage volumes and application data directories
**Data Flow Architecture:** Backup jobs create artifacts within each partition's S3 storage, then copy data to offsite storage via Direct Connect, VPN, or internet connectivity. Offsite storage provides centralized backup management with the ability to restore data to either partition based on recovery requirements.
**Offsite Storage Options:**
- **On‑Premises Datacenters:** Traditional datacenter infrastructure with customer‑controlled storage systems
- **Other Cloud Providers:** Azure Blob Storage, Google Cloud Storage, or other cloud provider storage services
- **Alternate AWS Partition:** Commercial partition for ESC backups, or ESC partition for commercial backups (subject to sovereignty evaluation)
- **Cloud Storage Gateways:** Hybrid storage solutions that bridge on‑premises and cloud storage environments
**Benefits:** Cross‑partition disaster recovery capabilities through centralized backup storage, customer control over backup data movement and residency decisions, flexible recovery options with ability to restore to either partition, and leverage existing backup infrastructure investments across various storage platforms.
**Challenges:** Requires offsite storage infrastructure and operational expertise, network bandwidth constraints for backup data transfer, increased backup storage costs across multiple locations, and complex recovery coordination procedures across partitions and external storage systems.
**Recovery Procedures:** Standard recovery restores data within the same partition from local S3 backup artifacts. Cross‑partition disaster recovery retrieves backup data from offsite storage and restores to the target partition, potentially requiring data format conversion or application reconfiguration.
**Data Sovereignty Considerations:** Customer‑controlled offsite storage enables organizations to maintain data residency control throughout the backup lifecycle. Organizations can implement geographic restrictions, encryption standards, and access controls that align with specific sovereignty requirements. Storage location selection (on‑premises, specific cloud regions, or alternative partitions) must align with regulatory obligations and compliance frameworks.
**Use Cases:** Organizations with existing backup infrastructure (on‑premises, multi‑cloud, or cross‑partition), requirements for cross‑partition disaster recovery capabilities, need for geographic redundancy beyond ESC's single region deployment, acceptable operational complexity for customer‑managed backup coordination, and tolerance for increased backup storage and network costs.
:::info Offsite Storage Requirements
**Infrastructure Considerations:** Successfully implementing Pattern 2 requires robust offsite storage infrastructure with sufficient capacity, performance, and redundancy to handle backup data from multiple partitions.
**Storage Platform Selection:**
- **On‑Premises:** Requires physical infrastructure, operational expertise, and capital investment
- **Other Cloud Providers:** May offer cost advantages but introduces additional vendor relationships and data egress charges
- **Alternate AWS Partition:** Simplifies operational procedures but may conflict with sovereignty requirements
- **Hybrid Solutions:** Storage gateways provide flexibility but add architectural complexity
**Capacity Planning:** Calculate total backup storage requirements across all partitions, including retention periods, backup frequency, and data growth projections. Factor in additional storage for backup retention policies and disaster recovery scenarios.
**Network Bandwidth:** Ensure adequate network connectivity between partitions and offsite storage for backup data transfer. Consider backup windows, data transfer costs, and network performance impact during backup operations.
**Security and Encryption:** Implement appropriate encryption for backup data in transit and at rest within offsite storage systems. Maintain consistent encryption standards across partition boundaries to ensure data protection compliance.
:::
---
#### `Pattern 3` Third‑Party Backup Solutions
*Figure 27: Third‑party backup platforms providing unified backup management across partitions*
This pattern uses specialized third‑party backup solutions designed for multi‑cloud and hybrid environments to provide unified backup management, advanced features, and cross‑partition recovery capabilities through external backup platforms.
**Implementation:** Deploy third‑party backup agents or configure API integrations with platforms such as N2WS (N2W Software), Veeam Backup for AWS, Druva Cloud Platform, or Rubrik Cloud Data Management. These platforms provide centralized backup management with cross‑partition visibility and recovery coordination.
**Platform Capabilities:**
- **N2WS (N2W Software):** Enterprise AWS backup with cross‑region replication, disaster recovery orchestration, and compliance reporting capabilities
- **Veeam Backup for AWS:** Native AWS backup with advanced recovery options, application‑aware backup, and cloud‑native integration
- **Druva Phoenix:** SaaS‑based backup platform with multi‑cloud support, automated backup policies, and ransomware protection
- **Rubrik Polaris:** Cloud data management platform with unified backup, disaster recovery, and data governance across multiple cloud providers
**Advanced Features:** Third‑party platforms often provide sophisticated capabilities including automated backup policy management, application‑aware backup and recovery, advanced compression and deduplication, ransomware detection and recovery, compliance reporting and audit trails, and cross‑cloud disaster recovery orchestration.
**Cross‑Partition Coordination:** External backup platforms can orchestrate backup and recovery operations across multiple partitions through unified interfaces, providing centralized policy management, cross‑partition disaster recovery capabilities, and consistent backup standards regardless of underlying partition constraints.
**Benefits:** Unified backup management across partitions through single interface, advanced backup features beyond native AWS capabilities, cross‑partition disaster recovery coordination, vendor expertise in multi‑cloud backup scenarios, and potential cost optimization through backup deduplication and compression.
**Challenges:** Additional vendor relationships and licensing costs, external dependency for critical backup operations, potential data residency implications depending on platform architecture, and vendor‑specific operational procedures and skill requirements.
**Data Residency Control:** Evaluate third‑party platform data handling, storage locations, and data processing capabilities to ensure alignment with sovereignty requirements. Some platforms offer regional deployment options or customer‑controlled data residency configurations.
**Use Cases:** Organizations with existing third‑party backup platform investments, requirements for advanced backup features beyond native AWS capabilities, acceptable external dependencies for backup operations, and budget for specialized backup platform licensing and operational expertise.
:::warning Third‑Party ESC Support Timeline
**ESC Integration Development:** Third‑party backup platforms will require time to develop and test ESC‑specific integrations following general availability. Support timelines vary significantly between vendors based on development priorities and customer demand.
**Expected Challenges:**
- **API Integration:** Platforms need time to develop ESC‑specific API integrations and endpoint configurations
- **Agent Deployment:** Backup agents may require updates for ESC‑specific networking and authentication patterns
- **Feature Parity:** Initial ESC support may lack feature parity with commercial AWS integrations
- **Certification Requirements:** Security certifications and compliance validations may delay ESC support availability
**Planning Recommendations:** Engage with backup platform vendors early to understand ESC roadmaps and support timelines. Plan for potential delays or manual backup procedures during ESC early adoption phases. Consider fallback approaches (Pattern 1 or Pattern 2) until third‑party platform support is fully available.
:::
---
#### Multi‑Partition Backup Pattern Comparison
| **Pattern** | **Best For** | **Pros** | **Cons** | **Cross‑Partition Recovery** | **Complexity** | **Cost Profile** |
|-------------|--------------|----------|----------|------------------------------|----------------|------------------|
| **1. Independent Backup Operations per Partition** | Organizations with strict data residency requirements, maximum sovereignty compliance, simple backup operations | ✅ Maximum sovereignty compliance
✅ Familiar AWS‑native tooling
✅ Simple compliance boundaries
✅ Independent partition operations
✅ No external dependencies | ❌ No cross‑partition disaster recovery
❌ Duplicate backup infrastructure
❌ Separate operational procedures
❌ Potential service availability gaps
❌ Limited backup optimization | **Not Supported**
Partition‑isolated recovery only | **Low**
Standard AWS Backup | **Medium**
Duplicate AWS Backup costs;
Separate backup storage |
| **2. Cross‑Partition Backup via Offsite Storage** | Organizations with existing backup infrastructure, cross‑partition disaster recovery requirements, customer‑controlled data movement | ✅ Cross‑partition disaster recovery
✅ Customer‑controlled data residency
✅ Leverages existing infrastructure
✅ Flexible recovery options
✅ Multiple storage platform options | ❌ Offsite infrastructure required
❌ Network bandwidth constraints
❌ Complex recovery procedures
❌ Increased operational overhead
❌ Multiple backup storage locations | **Supported**
Via offsite coordination | **High**
Multi‑location coordination | **High**
Offsite storage costs;
Network transfer fees;
Operational overhead |
| **3. Third‑Party Backup Solutions** | Organizations with advanced backup requirements, existing platform investments, unified operational preferences | ✅ Advanced backup features
✅ Unified management interface
✅ Cross‑partition recovery coordination
✅ Vendor expertise and support
✅ Multi‑cloud platform support | ❌ Additional platform licensing
❌ External operational dependency
❌ Potential ESC support delays
❌ Vendor‑specific procedures
❌ Data residency platform dependency | **Supported**
Platform‑coordinated recovery | **Medium**
Platform‑managed operations | **High**
Third‑party licensing;
Platform operational costs |
**Summary:**
* Multi‑partition backup requires careful consideration of sovereignty, recovery, and operational requirements
* ESC's single region deployment eliminates geographic redundancy within the partition, making cross‑partition or external backup strategies necessary for comprehensive disaster recovery
* Independent backup operations provide maximum compliance but limit disaster recovery capabilities
* Offsite coordination enables cross‑partition recovery with customer‑controlled data movement across various storage platforms
* Third‑party solutions offer advanced features but introduce external dependencies and potential ESC support delays
* Pattern selection should balance compliance requirements, recovery capabilities, and operational complexity whilst addressing single‑region limitations
---
## 10. Nuvibit Multi-Partition Reference Architecture
**The Challenge:** Organizations face months of complex implementation work to deploy multi-partition AWS architectures while maintaining security, compliance, and operational excellence. Traditional approaches using AWS Control Tower or Landing Zone Accelerator cannot span partition boundaries, forcing manual duplication and creating significant configuration drift risks. Each partition requires separate organizational structures, identity systems, and networking infrastructure, multiplying operational overhead whilst introducing security vulnerabilities through inconsistent configurations.
**The Solution:** Nuvibit's Multi-Partition Reference Architecture, built on the battle-tested Nuvibit AWS Reference Architecture (NARA) and powered by the Nuvibit Terraform Collection (NTC), provides day-zero ESC support with partition-aware Infrastructure as Code that deploys consistently across AWS partitions using provider aliasing. This approach eliminates configuration drift, reduces implementation timelines from months to weeks, and enables organizations to adopt ESC the moment it becomes available (Q4 2025) with proven architectural patterns and operational procedures.
### 10.1 Architectural Framework Options
Three foundational architectural patterns serve as starting points for multi-partition implementation planning, each addressing different organisational priorities and regulatory requirements:
**Pattern A: Regulated Core in ESC, Innovation Edge in Commercial** optimises for compliance whilst preserving innovation velocity through workload-based data classification. Regulated workloads handling sensitive data (customer PII, financial records, healthcare data, government information) operate in ESC for sovereignty compliance. Non-regulated workloads requiring advanced services (AI/ML experimentation, analytics platforms, content delivery, developer tooling, third-party integrations) leverage commercial AWS service breadth and innovation capabilities.
**Pattern B: All-in ESC with External Integration** maximises sovereignty compliance by operating entirely within ESC whilst maintaining essential business connectivity. Highly regulated entities adopt this pattern, using secure API gateways and approved external connectivity patterns for SaaS integrations and business partner connectivity.
**Pattern C: Commercial Core with Sovereign Offering** positions commercial AWS as the primary platform whilst ESC serves as a fully isolated sovereign offering for specific customers or markets. ISVs and enterprise software providers operate their main SaaS platforms in commercial AWS for global reach and service breadth, then deploy specialized sovereign instances (such as SAP Sovereign Cloud) in ESC for customers requiring data residency compliance. This pattern enables dual-market strategies with complete partition isolation.
#### Selecting Your Architectural Pattern
| **Pattern** | **Best For** | **Primary Driver** | **Key Trade-off** |
|-------------|--------------|--------------------|-------------------|
| **A: Regulated Core in ESC, Innovation Edge in Commercial** | Organizations with mixed workload sensitivity requiring both sovereignty and innovation | Data classification & service breadth | Operational complexity vs innovation velocity |
| **B: All-in ESC with External Integration** | Highly regulated public sector entities with strict sovereignty mandates | Maximum sovereignty compliance | Service limitations vs regulatory assurance |
| **C: Commercial Core with Sovereign Offering** | ISVs and SaaS providers serving distinct customer segments | Dual-market strategy | Infrastructure duplication vs market reach |
**Decision Questions:**
1. **Workload Classification:** Do all your workloads require EU sovereignty, or can you classify by data sensitivity?
2. **Service Requirements:** Can your applications accept ESC's initial service limitations, or do you need commercial AWS service breadth?
3. **Customer Segmentation:** Are you serving distinct customer segments with different sovereignty requirements?
4. **Operational Tolerance:** What's your tolerance for multi-partition operational complexity and coordination overhead?
5. **Innovation Velocity:** How critical is access to the latest AWS services and features for your competitive advantage?
**Pattern Selection Guide:**
- **Choose Pattern A** if you need sovereignty for regulated data whilst maintaining innovation capabilities for development and analytics workloads
- **Choose Pattern B** if regulatory requirements mandate complete EU sovereignty with no exceptions for external services
- **Choose Pattern C** if you operate a SaaS platform requiring both global commercial reach and specialized sovereign offerings
---
### 10.2 Nuvibit's Implementation Approach
#### Foundation: Nuvibit AWS Reference Architecture per Partition
The **[Nuvibit AWS Reference Architecture (NARA)](https://docs.nuvibit.com/whitepapers/nuvibit-aws-reference-architecture)** serves as the proven, battle-tested foundation for enterprise and regulated industries. This secure and compliant AWS foundation provides the essential building blocks that can be adapted to support any of the multi-partition architectural patterns outlined above.
NARA's core components, including Organization Management, Security Tooling, Log Archive, Connectivity, and dedicated Workload Accounts, form the single-partition backbone that gets either replicated with partition isolation or extended with cross-partition integration based on your chosen architectural pattern. The modular design ensures that whether you implement Pattern A, Pattern B, or Pattern C, you maintain the same level of governance, security, and operational excellence.
#### Multi-Partition Implementation Strategy
The **Nuvibit Terraform Collection (NTC) will support all multi-partition architectural patterns** outlined in this whitepaper, providing Infrastructure as Code blueprints that adapt to customer requirements. NTC streamlines deployment across any pattern whilst preventing configuration drift and delivering the best possible user experience through unified, partition-aware automation.
**Key Implementation Areas:**
- **Account Management:** Unified account factory with partition-aware provisioning workflows
- **Identity Management:** External IdP federation, SCIM provisioning, break-glass procedures
- **Security:** Cross-partition security tooling, audit logging, compliance controls
- **Connectivity:** VPC architecture, Transit Gateway, Network Firewall, centralized connectivity patterns
- **Observability:** Independent monitoring, log forwarding, third-party platform integration
- **Backup & Recovery:** Partition-isolated, cross-partition, and third-party backup strategies
---
#### Terraform/OpenTofu-Based Multi-Partition Blueprints
NTC is designed with partition awareness from the ground up, enabling single Terraform/OpenTofu configurations to deploy resources across multiple AWS partitions whilst maintaining operational continuity. Provider aliasing enables seamless multi-partition deployments when ESC becomes available.
**Why Unified Terraform/OpenTofu Deployment Matters:**
Traditional AWS Landing Zone solutions require complete duplication of configurations across partitions. This creates:
- ❌ **Configuration Drift:** Manual synchronization of OUs, policies, and baselines across partitions
- ❌ **Maintenance Overhead:** Changes must be applied twice with partition-specific modifications
- ❌ **Testing Complexity:** Separate validation required for each partition deployment
- ❌ **Human Error Risk:** Manual processes introduce inconsistencies and security vulnerabilities
The NTC approach uses Terraform/OpenTofu provider aliasing to deploy identical configurations to multiple partitions from a single source of truth:
- ✅ **Single Configuration:** One OU structure, one set of policies, one deployment workflow
- ✅ **Automatic Consistency:** Changes apply to both partitions simultaneously
- ✅ **Reduced Overhead:** Maintain one codebase instead of two separate configurations
- ✅ **Version Control:** Unified change tracking and audit trail across partitions
The following code snippets demonstrate how to implement NTC in a unified multi-partition pattern, where a single Terraform/OpenTofu configuration deploys shared configurations across both commercial AWS and ESC partitions using provider aliasing.
```hcl title="providers.tf"
# --------------------------------------------------------------------------------------------
# ¦ PROVIDER - MULTI-PARTITION
# --------------------------------------------------------------------------------------------
provider "aws" {
alias = "aws_frankfurt"
region = "eu-central-1"
# OpenID Connect (OIDC) integration
assume_role_with_web_identity {
role_arn = "arn:aws:iam::111111111111:role/oidc-role"
session_name = "unified-pipeline"
web_identity_token_file = "/tmp/web-identity-token"
}
}
provider "aws" {
alias = "aws_eusc_brandenburg"
region = "eusc-de-east-1"
# OpenID Connect (OIDC) integration
assume_role_with_web_identity {
role_arn = "arn:aws-eusc:iam::222222222222:role/oidc-role"
session_name = "unified-pipeline"
web_identity_token_file = "/tmp/web-identity-token"
}
}
```
**NTC Organizations**
```hcl title="ntc_organizations.tf"
# --------------------------------------------------------------------------------------------
# ¦ LOCALS
# --------------------------------------------------------------------------------------------
locals {
# shared OU structure across partitions
organizational_unit_paths = [
"/root/core",
"/root/sandbox",
"/root/suspended",
"/root/transitional",
"/root/workloads",
"/root/workloads/prod",
"/root/workloads/dev",
"/root/workloads/test"
]
}
# --------------------------------------------------------------------------------------------
# ¦ NTC ORGANIZATIONS - COMMERCIAL
# --------------------------------------------------------------------------------------------
module "ntc_organizations" {
source = "github.com/nuvibit-terraform-collection/terraform-aws-ntc-organizations?ref=X.X.X"
# list of nested (up to 5 levels) organizational units
organizational_unit_paths = local.organizational_unit_paths
# additional inputs...
providers = {
aws = aws.aws_frankfurt
}
}
# --------------------------------------------------------------------------------------------
# ¦ NTC ORGANIZATIONS - ESC
# --------------------------------------------------------------------------------------------
module "ntc_organizations_esc" {
source = "github.com/nuvibit-terraform-collection/terraform-aws-ntc-organizations?ref=X.X.X"
# list of nested (up to 5 levels) organizational units
organizational_unit_paths = local.organizational_unit_paths
# additional inputs...
providers = {
aws = aws.aws_eusc_brandenburg
}
}
```
**NTC Identity Center**
```hcl title="ntc_identity_center.tf"
# --------------------------------------------------------------------------------------------
# ¦ LOCALS
# --------------------------------------------------------------------------------------------
locals {
# permission sets can be a combination of aws and customer managed policies
# https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetcustom.html
permission_sets = [
{
name : "AdministratorAccess"
description : "This permission set grants administrator access"
session_duration : 2
inline_policy_json : ""
managed_policies : [
{
managed_by : "aws"
policy_name : "AdministratorAccess"
policy_path : "/"
}
]
boundary_policy : {}
},
{
name : "Billing+ViewOnlyAccess"
description : "This permission set grants billing and read-only access"
session_duration : 10
inline_policy_json : ""
managed_policies : [
{
managed_by : "aws"
policy_name : "Billing"
policy_path : "/job-function/"
},
{
managed_by : "aws"
policy_name : "ViewOnlyAccess"
policy_path : "/job-function/"
}
]
boundary_policy : {}
},
{
name : "SupportUser+ReadOnlyAccess"
description : "This permission set grants support and read-only access"
session_duration : 10
inline_policy_json : ""
managed_policies : [
{
managed_by : "aws"
policy_name : "SupportUser"
policy_path : "/job-function/"
},
{
managed_by : "aws"
policy_name : "ReadOnlyAccess"
policy_path : "/"
}
]
boundary_policy : {}
}
]
}
# --------------------------------------------------------------------------------------------
# ¦ NTC IDENTITIY CENTER - COMMERCIAL
# --------------------------------------------------------------------------------------------
module "ntc_identity_center" {
source = "github.com/nuvibit-terraform-collection/terraform-aws-ntc-identity-center?ref=X.X.X"
# automatic provisioning (synchronization) of users and groups from external identity provider
# using the System for Cross-domain Identity Management (SCIM) v2.0 protocol
is_automatic_provisioning_enabled = true
permission_sets = local.permission_sets
# additional inputs...
providers = {
aws = aws.aws_frankfurt
}
}
# --------------------------------------------------------------------------------------------
# ¦ NTC IDENTITIY CENTER - ESC
# --------------------------------------------------------------------------------------------
module "ntc_identity_center_esc" {
source = "github.com/nuvibit-terraform-collection/terraform-aws-ntc-identity-center?ref=X.X.X"
# automatic provisioning (synchronization) of users and groups from external identity provider
# using the System for Cross-domain Identity Management (SCIM) v2.0 protocol
is_automatic_provisioning_enabled = true
permission_sets = local.permission_sets
# additional inputs...
providers = {
aws = aws.aws_eusc_brandenburg
}
}
```
**NTC Core Network**
```hcl title="ntc_core_networking.tf"
# --------------------------------------------------------------------------------------------
# ¦ LOCALS
# --------------------------------------------------------------------------------------------
locals {
transit_gateway_route_tables = [
"tgw-core-rtb-hub",
"tgw-core-rtb-spoke-prod",
"tgw-core-rtb-spoke-dev",
"tgw-core-rtb-spoke-int",
"tgw-core-rtb-onprem",
]
}
# --------------------------------------------------------------------------------------------
# ¦ NTC CORE NETWORK - FRANKFURT - COMMERCIAL
# --------------------------------------------------------------------------------------------
module "ntc_core_network" {
source = "github.com/nuvibit-terraform-collection/terraform-aws-ntc-core-network?ref=X.X.X"
transit_gateway = {
name = "tgw-core-frankfurt"
description = "core network in frankfurt"
amazon_side_asn = 64512
default_route_table_association = false
default_route_table_propagation = false
dns_support = true
multicast_support = false
vpn_ecmp_support = true
security_group_referencing_support = true
cidr_blocks = []
route_table_names = local.transit_gateway_route_tables
# (optional) share Transit Gateway with Organizations, OUs or Accounts
auto_accept_shared_attachments = true
ram_share_principals = [
local.ntc_parameters["mgmt-organizations"]["ou_ids"]["/root/workloads"]
]
ram_share_allow_external_principals = false
}
# additional inputs...
providers = {
aws = aws.aws_frankfurt
}
}
# --------------------------------------------------------------------------------------------
# ¦ NTC CORE NETWORK - BRANDENBURG - ESC
# --------------------------------------------------------------------------------------------
module "ntc_core_network_esc" {
source = "github.com/nuvibit-terraform-collection/terraform-aws-ntc-core-network?ref=X.X.X"
transit_gateway = {
name = "tgw-core-brandenburg"
description = "core network in brandenburg"
amazon_side_asn = 64512
default_route_table_association = false
default_route_table_propagation = false
dns_support = true
multicast_support = false
vpn_ecmp_support = true
security_group_referencing_support = true
route_table_names = local.transit_gateway_route_tables
# (optional) share Transit Gateway with Organizations, OUs or Accounts
auto_accept_shared_attachments = true
ram_share_principals = [
local.ntc_parameters["mgmt-organizations"]["ou_ids"]["/root/workloads"]
]
ram_share_allow_external_principals = false
}
# additional inputs...
providers = {
aws = aws.aws_eusc_brandenburg
}
}
```
---
#### Account Factory with Partition Awareness
The account factory implementation uses a GitOps-driven approach with a single repository containing shared configuration that deploys to both partitions through unified pipelines. Account requests are captured through flexible interfaces, with user partition selection determining the deployment target while maintaining consistent configuration and operational procedures.
A partition-isolated approach is also possible with individual repositories for each partition.
**Implementation Options:**
- **Self-Service Portals:** Integrate with platforms like Port, Backstage, ServiceNow, or custom portals that can push account details to the repository (unified or partition-specific)
- **API Integration:** Direct API calls that create account definition files in the appropriate repository based on selected approach
- **Direct Git Workflow:** Users create Pull Requests directly in the chosen repository structure (unified or partition-isolated)
- **Hybrid Approaches:** Combination of portals, APIs, and direct Git access based on user preferences and organizational workflows
**Unified Deployment**
 \
*Figure 28a: Nuvibit's partition-aware account factory implementation*
:::note Unified Repository Architecture
1. **Single Source of Truth:** One repository contains shared account templates, policies, and configuration for both partitions
2. **Partition Selection:** User chooses target partition (commercial or ESC) during account request process
3. **Unified Pipeline:** Single CI/CD pipeline deploys accounts to the selected partition using provider aliasing
4. **Shared Configuration:** Consistent account standards, security policies, and operational procedures across partitions
5. **Partition-Aware Deployment:** Pipeline logic routes deployment to appropriate partition based on user selection
:::
**Partition-Isolated Deployment**
 \
*Figure 28b: Partition-isolated account factory with separate repositories and pipelines*
:::note Partition-Isolated Repository Architecture
1. **Separate Repositories:** Independent repositories for commercial and ESC partition account factory configurations
2. **Partition-Specific Routing:** User interface directs account requests to the appropriate repository based on partition selection
3. **Independent Pipelines:** Each repository has its own CI/CD pipeline deploying exclusively to its target partition
4. **Duplicate Configuration:** Account templates and policies maintained separately in each repository for maximum isolation
5. **Compliance Boundaries:** Clear separation ensures no cross-partition data or configuration sharing
:::
**Architecture Selection Considerations:**
- **Unified Deployment:** Choose for operational efficiency, reduced configuration drift, and simplified maintenance
- **Partition-Isolated Deployment:** Choose for maximum compliance separation, clear audit boundaries, and regulatory requirements demanding complete partition isolation
---
#### Modular Repository and CI/CD Pipeline Architecture
The Nuvibit approach leverages a modular repository structure with dedicated CI/CD pipelines for each functional area, providing superior operational flexibility and risk management compared to monolithic implementations.
**Unified Multi-Partition Pipelines**
 \
*Figure 29a: Unified CI/CD pipelines deploying to multiple partitions using provider aliasing*
:::note Architecture Characteristics
- Single CI/CD pipeline per functional area with multi-partition deployment logic
- Provider aliasing enables deployment to both commercial and ESC partitions
- Shared pipeline configuration with partition-specific conditional logic
- Unified artifact management and promotion workflows
- Single pipeline monitoring and operational interface
:::
**Partition-Isolated Pipelines**
 \
*Figure 29b: Partition-isolated CI/CD pipelines with separate deployment workflows*
:::note Architecture Characteristics
- Dedicated CI/CD pipeline per functional area per partition
- Complete isolation between commercial and ESC deployment workflows
- Separate pipeline configurations, credentials, and monitoring
- Independent artifact management and promotion per partition
- Partition-specific operational procedures and troubleshooting
:::
:::info Tooling Flexibility
This architecture can be implemented with a wide selection of tools based on organizational preferences and existing infrastructure:
**Repository Platforms:** GitHub, GitLab, Bitbucket, AWS CodeCommit (deprecated), Azure Repos
**Generic CI/CD Tooling:** GitHub Actions, GitLab CI/CD, Jenkins, AWS CodePipeline, Azure DevOps Pipelines
**Specialized IaC Platforms:** Spacelift, HCP Terraform, env0, Scalr, Atlantis
The modular repository and pipeline approach works consistently across all platforms, enabling organizations to leverage existing tooling investments whilst maintaining the architectural benefits of segregation of duty, smaller blast radius, and team independence. Choose the tools that best align with your operational preferences and compliance requirements.
:::
**Repository Structure:**
- **Organizations Repository:** Organizational structure, organizational policies (guardrails), organizational cloudtrail
- **Account Factory Repository:** Account vending and lifecycle, baseline configurations
- **Identity Management Repository:** IAM Identity Center, permission sets, user/group provisioning
- **Log Archive Repository:** Audit relevant log archive
- **Security Repository:** Security tooling, compliance controls
- **Connectivity Repository:** Transit Gateway, Direct Connect, VPN configurations, network routing
- **Observability Repository:** Monitoring, logging, alerting, dashboard configurations
- **Backup Repository:** Backup policies, disaster recovery
Each repository operates with its own dedicated CI/CD pipeline that can deploy to either single partitions or multiple partitions based on the chosen architectural pattern.
**Key Advantages:**
🎯 **Smaller Blast Radius**
- Pipeline failures are isolated to specific functional areas
- Broken connectivity pipeline doesn't block security deployments
- Failed observability updates don't impact account provisioning
- Infrastructure changes can be deployed incrementally with controlled risk
⚡ **Segregation of Duty**
- Different teams can own and operate separate repositories and pipelines
- Network team manages connectivity repository independently
- Security team controls security tooling without dependencies
- Platform team handles account factory with clear ownership boundaries
- Role-based access controls align with organizational responsibilities
🔧 **Flexibility and Efficiency**
- Use only the building blocks needed for your specific requirements
- Expand with additional Terraform/OpenTofu modules as requirements evolve
- Upgrade individual components without impacting other areas
- Run deployments only when changes are needed in specific functional areas
- Scale team responsibilities based on organizational structure
**Operational Workflow:**
1. **Incremental Development:** Teams work on functional areas independently without coordination overhead
2. **Selective Deployment:** Deploy only changed components, reducing deployment time and risk
3. **Parallel Operations:** Multiple teams can deploy simultaneously to different functional areas
4. **Targeted Rollbacks:** Rollback specific functional areas without affecting other components
5. **Scaling Teams:** Add new teams and repositories as organizational requirements grow
This modular approach enables organizations to start with essential components and gradually expand their multi-partition infrastructure as capabilities and team maturity evolve, while maintaining operational excellence and clear ownership boundaries throughout the journey.
---
### 10.3 Multi-Partition Migration Path
Organizations with existing AWS commercial partition infrastructure must balance ESC adoption with operational continuity. A phased, risk-mitigated approach establishes ESC capabilities in parallel with existing infrastructure before progressively migrating workloads based on sovereignty requirements.
#### Phased Migration Approach
**Phase 1: Foundation Deployment (Months 1-2)**
- Deploy NTC in ESC partition using proven architectural patterns
- Establish organizational structure, identity federation, and security baselines
- Configure cross-partition connectivity if required (e.g. Direct Connect, VPN)
- Maintain complete operational independence of existing commercial infrastructure
- Validate ESC patterns with non-production pilot workloads
**Key Activities:**
- Set up AWS Organizations structure in ESC partition
- Configure IAM Identity Center with external IdP federation
- Deploy core networking (Transit Gateway, VPC architecture)
- Establish security tooling and audit logging
- Configure cross-partition connectivity based on architectural pattern requirements
- Document operational procedures and runbooks
**Success Criteria:**
- ESC foundation operational with complete security baseline
- Cross-partition connectivity validated and documented (if required)
- Pilot workload successfully deployed and operational
- Team trained on ESC-specific operational procedures
---
**Phase 2: Progressive Workload Migration (Months 3-6)**
- Classify existing workloads by data sensitivity and sovereignty requirements
- Migrate regulated workloads handling sensitive data to ESC partition
- Maintain innovation and development workloads in commercial partition
- Establish operational procedures for dual-partition management
- Implement cross-partition observability and cost management
**Migration Priorities:**
1. **High Sovereignty Requirements:** Customer PII, financial records, healthcare data, government information
2. **Medium Sovereignty Requirements:** Internal business data, employee information, operational systems
3. **Low Sovereignty Requirements:** Development environments, analytics platforms, third-party integrations
**Migration Methodology:**
- **Lift and Shift:** Recreate infrastructure in ESC for stateless workloads
- **Database Migration:** Use AWS DMS or native tools for database transfers
- **Application Refactoring:** Adapt applications for ESC service availability
- **Data Synchronization:** Establish temporary cross-partition data flows during transition
**Risk Mitigation:**
- Maintain parallel operations during migration
- Test thoroughly in ESC before commercial decommissioning
- Implement rollback procedures for critical workloads
- Document lessons learned and update procedures iteratively
---
**Phase 3: Operational Optimization (Month 6+)**
- Consolidate monitoring and observability across both partitions
- Optimize cross-partition connectivity patterns and costs
- Refine account factory and vending procedures based on operational experience
- Implement advanced automation for multi-partition operations
- Document comprehensive operational playbooks and disaster recovery procedures
**Optimization Focus Areas:**
- **Cost Management:** Rightsize resources, eliminate redundancy, optimize data transfer
- **Operational Efficiency:** Automate repetitive tasks, streamline workflows, reduce manual intervention
- **Security Posture:** Continuous compliance monitoring, automated remediation, regular audits
- **Team Training:** Build expertise in multi-partition operations, document tribal knowledge
**Continuous Improvement:**
- Regular architecture reviews and pattern refinement
- Stay current with ESC service launches and capability updates
- Adapt procedures as organizational requirements evolve
- Share learnings across teams and improve documentation
---
#### NTC Advantage for Migration
**Non-Disruptive Adoption:** Organizations can deploy NTC in ESC alongside existing infrastructure without replacement, enabling gradual adoption and risk mitigation. Existing commercial infrastructure remains untouched during ESC foundation deployment.
**Proven Patterns:** Nuvibit's reference architecture in ESC mirrors commercial best practices, reducing operational learning curves and enabling consistent management procedures across both partitions.
**Unified Operations:** Once both partitions run NTC-based infrastructure, unified Terraform/OpenTofu configurations enable consistent policy management, security controls, and operational procedures with reduced overhead.
**Flexible Timeline:** Organizations control migration pace based on business priorities, resource availability, and risk tolerance. No forced cutover dates or all-or-nothing decisions.
---
**Summary:**
* Nuvibit's reference architecture provides a comprehensive framework for multi-partition deployment
* Terraform/OpenTofu foundation with provider aliasing enables seamless multi-partition operations
* Modular repository structure delivers operational flexibility with controlled blast radius
* Clear team ownership boundaries support organizational scaling and responsibility distribution
* **NTC accelerate ESC adoption from months to weeks**
---
## 11. Conclusion
The AWS European Sovereign Cloud (ESC) represents a significant advancement for organizations requiring EU sovereignty whilst leveraging cloud computing capabilities. The decision framework presented in this paper requires careful consideration of sovereignty requirements, service dependencies, operational complexity, and cost implications.
All‑in ESC adoption maximises sovereignty assurance but accepts service parity limitations and operational constraints. Commercial partition retention preserves full service availability but may not satisfy regulatory requirements. Dual‑partition strategies enable targeted sovereignty whilst retaining innovation velocity, though at the cost of operational complexity.
Success in multi‑partition environments requires deliberate operating models that address identity federation, connectivity patterns, compliance mapping, and cost management. The integration patterns and reference architectures presented provide proven approaches for managing these complexities whilst maintaining operational excellence.
Organizations must approach ESC adoption incrementally, starting with comprehensive assessment of sovereignty requirements and service dependencies. Pilot implementations validate architectural patterns and operational procedures before broader rollout. The lessons learned from multi‑region compliance strategies provide valuable foundation knowledge, though partition‑specific patterns require additional consideration.
Multi‑partition strategies will become increasingly important as organizations balance sovereignty requirements with innovation velocity in the evolving EU cloud landscape. Success depends on operational excellence, robust architectural patterns, and continuous evolution as ESC service parity and geographic redundancy mature.
**Final Recommendations:**
* Assess sovereignty requirements comprehensively before making partition decisions
* Invest early in partition‑aware tooling and operational procedures
* Start with pilot implementations to validate patterns before production adoption
* Maintain flexibility as ESC service parity and capabilities evolve
* Focus on operational excellence and incremental improvement over time
---
## Ready to Navigate Your ESC Journey?
As an **AWS European Sovereign Cloud (ESC) Launch Partner**, Nuvibit brings deep expertise in AWS Landing Zone architectures and sovereign cloud operations to help organizations navigate their ESC adoption journey.
The **Nuvibit Terraform Collection (NTC) will support ESC from day zero**, accelerating your ESC deployment from months to weeks with battle-tested, enterprise-grade Infrastructure as Code building blocks that adapt seamlessly to multi-partition AWS environments.
Through our **strategic partnerships with leading system integrators in Germany**, we provide comprehensive ESC implementation support that combines cloud-native expertise with local regulatory knowledge and enterprise integration capabilities.
:::tip Get Expert ESC Guidance
- 🎯 **[Schedule your ESC strategy session](https://calendly.com/stefano-franco-nuvibit/aws-esc-session)** - Book a free 30-minute meeting with our specialists
- 📧 **Contact our experts directly**: [**aws-esc@nuvibit.com**](mailto:aws-esc@nuvibit.com?subject=AWS%20ESC%20Consultation&body=Hi%20Nuvibit%20team%2C%0A%0AI%20read%20your%20AWS%20European%20Sovereign%20Cloud%20multi-partition%20whitepaper%20and%20would%20like%20to%20discuss%20how%20these%20patterns%20might%20apply%20to%20our%20organization.%0A%0A%5BList%20any%20specific%20questions%20about%20the%20patterns%20or%20implementation%5D%0A%0ABest%20regards%2C%0A%5BYour%20name%5D)
:::
**What You'll Get:**
- ESC readiness assessment for your specific requirements
- Custom multi-partition architecture recommendations
- NTC implementation roadmap tailored to your timeline
- Regulatory compliance strategy aligned with your industry
---
## References
[1] [About Amazon EU - ESC Governance, EU Operations, Trust and DNS/Direct Connect Notes](https://www.aboutamazon.eu/news/aws/built-operated-controlled-and-secured-in-europe-aws-unveils-new-sovereign-controls-and-governance-structure-for-the-aws-european-sovereign-cloud)
[2] [AWS Security Blog - Initial Services Available in the AWS European Sovereign Cloud](https://aws.amazon.com/blogs/security/announcing-initial-services-available-in-the-aws-european-sovereign-cloud-backed-by-the-full-power-of-aws/)
[3] [AWS Security Blog - EU Trust Service Provider and EU CA](https://aws.amazon.com/blogs/security/establishing-a-european-trust-service-provider-for-the-aws-european-sovereign-cloud/)
[4] [AWS Security Blog - €7.8B Investment and Brandenburg Region Timeline](https://aws.amazon.com/blogs/security/aws-plans-to-invest-e7-8b-into-the-aws-european-sovereign-cloud-set-to-launch-by-the-end-of-2025/)
[5] [AWS Digital Sovereignty Pledge and Independent ESC](https://aws.amazon.com/blogs/security/aws-digital-sovereignty-pledge-announcing-a-new-independent-sovereign-cloud-in-europe/)
Source: https://docs.nuvibit.com/whitepapers/aws-multi-partition-strategies
---
# CI/CD Pipelines for Infrastructure-as-Code Delivery
## Introduction
Infrastructure as Code (IaC) revolutionizes the way cloud environments are built, managed, and maintained. To achieve scalable, secure, and efficient IaC deployments, **Continuous Integration/Continuous Deployment (CI/CD) pipelines** play a critical role. This whitepaper explores how to set up CI/CD pipelines tailored for IaC delivery, highlighting best practices, recommended tools, and strategies to streamline the deployment process.
---
## Why Use CI/CD Pipelines for IaC?
CI/CD pipelines are essential for delivering Infrastructure as Code (IaC) efficiently, securely, and reliably. By automating the provisioning, updating, and maintenance of cloud infrastructure, pipelines create a structured and consistent deployment process.
### **Advantages of CI/CD Pipelines**
1. **Security**:
- CI/CD pipelines securely handle credentials and sensitive data, integrating with tools like AWS Secrets Manager, HashiCorp Vault, or OpenID Connect (OIDC).
- Centralized deployment ensures that sensitive information is not exposed during manual processes or stored locally. Pipelines also enforce best practices like role-based access control (RBAC).
2. **Reliability**:
- Pipelines automate deployments, ensuring consistent execution and reducing the risk of human error.
- Built-in stages like `terraform plan` and validation steps catch issues before they are deployed to production environments.
3. **Traceability**:
- CI/CD pipelines provide a clear audit trail for every change, detailing who initiated a deployment, what was changed, and when.
- This is invaluable for compliance, debugging, and understanding the history of infrastructure changes.
4. **Compliance**:
- Pipelines can enforce organizational and regulatory compliance by integrating tools like Open Policy Agent (OPA) or Sentinel.
- They automatically validate infrastructure against predefined policies, such as enforcing encryption, tagging standards, and network restrictions, ensuring consistent adherence to governance requirements.
- This reduces the risk of deploying non-compliant infrastructure and simplifies audits.
5. **Single Source of Truth**:
- With CI/CD pipelines, the IaC configuration stored in version control (e.g. Git repositories) becomes the **single source of truth**.
- All changes are deployed through the pipeline, ensuring consistency between the IaC configuration and the deployed infrastructure. This eliminates discrepancies caused by ad-hoc manual changes.
6. **Drift Prevention**:
- Automated pipelines ensure that the infrastructure state remains consistent with the IaC configuration.
- This prevents configuration drift, where the deployed environment deviates from the defined codebase due to unauthorized or manual changes.
7. **Consistency Across Teams**:
- Pipelines enforce standardized workflows, ensuring that teams follow the same process regardless of the environment or team member involved.
- This standardization simplifies onboarding and collaboration across multiple teams.
8. **Scalability**:
- CI/CD pipelines simplify the management of complex, multi-account, and multi-region environments.
- Modular workflows allow for incremental deployments, scaling with your organization’s growth.
9. **Automation of Testing and Validation**:
- Pipelines integrate testing stages to validate IaC changes before they are deployed.
- Examples include static code analysis, compliance checks, and `terraform validate` to catch errors early in the process.
10. **Faster Rollbacks**:
- Pipelines enable automated rollbacks in case of deployment failures.
- Version control integration ensures that you can revert to a previous, stable version of your IaC configuration seamlessly.
### **Why It Matters**
By adopting CI/CD pipelines, organizations establish a secure, automated, and traceable framework for deploying IaC. This approach not only increases operational efficiency but also ensures that infrastructure remains aligned with the IaC configuration, reducing risk and simplifying management.
Whether you're building a small-scale project or managing a multi-account enterprise environment, CI/CD pipelines provide the foundation for scalable, secure, and compliant infrastructure delivery.
---
## Generic CI/CD Tools or Purpose-Built CI/CD Tools for IaC?
When setting up CI/CD pipelines for Infrastructure as Code (IaC), one of the first decisions to make is whether to use generic CI/CD tools or tools specifically built for infrastructure management. Both options have their advantages, but purpose-built tools often provide features that streamline and enhance IaC workflows.
---
### **Generic CI/CD Tools**
Generic CI/CD tools, such as **[GitHub Actions](https://github.com/features/actions)**, **[GitLab CI/CD](https://about.gitlab.com/solutions/continuous-integration/)**, **[Jenkins](https://www.jenkins.io/)**, and **[CircleCI](https://circleci.com/)**, are versatile platforms designed to automate various software development tasks, including testing, building, and deploying applications. While they are not specifically designed for IaC, they can be adapted for this purpose with custom scripting and configurations.
#### **Advantages of Generic Tools**
- **Familiarity**: Often already used within organizations for application delivery, making adoption straightforward.
- **Flexibility**: Can be customized to handle a variety of workflows beyond IaC.
- **Ecosystem Integration**: Extensive plugins and integrations for non-IaC use cases. For example:
- **Jenkins**: Large library of plugins, including Terraform-specific integrations.
- **GitHub Actions**: Pre-built actions for IaC tools like Terraform and Pulumi.
- **CircleCI**: A developer-friendly platform designed to handle IaC pipelines efficiently.
#### **Challenges with Generic Tools**
- **Complex Configuration**: Setting up state management, drift detection, and IaC-specific workflows often requires custom scripting.
- **Lack of Native Features**: Generic tools don’t natively handle IaC requirements like Terraform state management or policy enforcement.
- **Limited Visibility**: Debugging IaC-specific issues can be more challenging without dedicated dashboards or workflows.
---
### **Purpose-Built CI/CD Tools for IaC**
Tools like Spacelift, Terraform Cloud, Terramate, Scalr, and Env0 are designed specifically to cater to IaC workflows. These platforms include built-in features that address the unique challenges of infrastructure management.
#### **Advantages of Purpose-Built Tools**
1. **State Management**:
- Native support for managing Terraform state files, including encryption and locking, eliminates the need for additional configuration.
2. **Drift Detection**:
- Automatically monitors for changes made outside of IaC pipelines, helping ensure consistency between your code and deployed infrastructure.
3. **Policy Enforcement**:
- Tools like Spacelift, Terraform Cloud, and Scalr integrate with policy-as-code frameworks (e.g. Open Policy Agent, Sentinel) to enforce compliance standards during deployments.
4. **IaC-Specific Dashboards**:
- Purpose-built tools provide intuitive dashboards for tracking plans, applies, and runs, simplifying debugging and auditing.
5. **Seamless Authentication**:
- Native support for secure authentication methods like OpenID Connect (OIDC), reducing the need to manage long-lived credentials.
6. **Collaboration and Workflows**:
- Features like role-based access controls (RBAC), workspace isolation, and detailed logging simplify team collaboration on IaC projects.
#### **Examples of Purpose-Built Tools**
- **[Spacelift](https://spacelift.io/)**: Offers features like drift detection, policy-as-code integration, and built-in state management.
- **[Terraform Cloud](https://www.hashicorp.com/products/terraform)**: Provides a native experience for Terraform users, with remote state management, team collaboration, and cost estimation.
- **[Terramate](https://terramate.io/)**: Enhances Terraform workflows with automation features like stack orchestration, dependency management, and code generation, enabling efficient and scalable multi-stack IaC management.
- **[Scalr](https://www.scalr.com/)**: Enterprise-grade features for IaC governance, including hierarchical policy management and multi-cloud support.
- **[Env0](https://www.env0.com/)**: Focuses on collaborative IaC deployments, with support for multiple frameworks and cost management.
---
### **Combination of Generic and Purpose-Built CI/CD Tools**
Organizations often face the decision of choosing between generic and purpose-built CI/CD tools. However, these two approaches are not mutually exclusive. A hybrid approach combining both types of pipelines can offer the best of both worlds, leveraging the flexibility of generic tools alongside the specialized features of purpose-built platforms. Below are two effective combination strategies:
#### **1. Infrastructure Deployment with Purpose-Built Pipelines, Workload Deployment with Generic Pipelines**
In this approach, purpose-built CI/CD pipelines (e.g. Spacelift, Terraform Cloud) are used to manage infrastructure deployments, ensuring robust state management, policy enforcement, and drift detection. Meanwhile, generic CI/CD pipelines (e.g. GitHub Actions, Jenkins) handle application or workload deployments.
- **Advantages**:
- Ensures infrastructure and workloads are managed with tools tailored to their specific requirements.
- Segregates responsibilities, reducing complexity and potential conflicts between infrastructure and application workflows.
- **Use Case**:
- Ideal for environments where infrastructure and workload changes are handled by different teams or require distinct deployment processes.
#### **2. Code Validation with Generic Pipelines, Deployment with Purpose-Built Pipelines**
This method utilizes generic CI/CD tools for pre-deployment validation tasks, such as code formatting, linting, and security checks, before handing over the deployment to purpose-built pipelines.
- **Advantages**:
- Leverages the extensive ecosystem of generic tools for validation and testing.
- Ensures deployments benefit from the advanced state management and policy enforcement of purpose-built tools.
- **Use Case**:
- Suitable for organizations that prioritize rigorous pre-deployment validation or need to standardize validation workflows across both infrastructure and application pipelines.
:::tip
For effective pre-deployment validation, consider integrating the following tools into your Terraform workflow:
- **[TFLint](https://github.com/terraform-linters/tflint)**: A Terraform linter to catch syntax issues and enforce best practices.
- **[Trivy](https://aquasecurity.github.io/trivy/)**: A security scanner for IaC configurations to detect vulnerabilities and misconfigurations.
- **[Terraform-Docs](https://terraform-docs.io/)**: Automatically generates and validates documentation for Terraform modules.
- **[Open Policy Agent (OPA)](https://www.openpolicyagent.org/)**: A policy-as-code engine for validating compliance and enforcing organizational policies.
- **[Infracost](https://www.infracost.io/)**: Shows cloud cost estimates and FinOps best practices for Terraform.
These tools ensure code quality, security, and maintainability, creating a seamless handoff for deployment.
:::
---
### **Key Benefits of Combining CI/CD Tools**
- **Enhanced Flexibility**: Combines the versatility of generic tools with the IaC-specific capabilities of purpose-built platforms.
- **Optimized Workflows**: Ensures that the right tool is used for the right task, maximizing efficiency and effectiveness.
- **Streamlined Collaboration**: Allows teams to adopt tools best suited to their roles, improving collaboration between infrastructure and application teams.
- **Reduced Costs**: Avoids overloading purpose-built tools with tasks better suited to generic platforms, optimizing resource utilization.
By adopting a hybrid approach, organizations can build CI/CD workflows that are tailored to their specific needs while maintaining consistency, security, and scalability.
:::tip
Many Git providers, such as **GitHub** and **GitLab**, already include integrated CI/CD tools. These can be leveraged for tasks like code checks, linting, and security validation. By combining these built-in tools with a purpose-built IaC platform (e.g. Spacelift), you can create powerful and cost-efficient pipelines tailored to your organization's needs.
:::
---
### **Which Should You Choose?**
The decision depends on your organization’s needs:
- **Generic CI/CD Tools Are Ideal When**:
- You’re already using them for application deployments and want a unified platform.
- Your IaC requirements are simple and don’t need features like drift detection or policy enforcement.
- Your team has the expertise to script and configure custom workflows for IaC.
- **Purpose-Built Tools Are Best When**:
- You manage complex, multi-account environments that require robust state management and compliance checks.
- Your team wants to minimize custom configurations and leverage built-in IaC workflows.
- You have a central team (e.g. platform engineering team) responsible for infrastructure deployments.
- **Combination of Tools Is Optimal When**:
- You want to split responsibilities, using purpose-built tools for infrastructure deployment and generic tools for workload deployments.
- You need a streamlined workflow where generic tools handle pre-deployment tasks (e.g. code checks, linting, and validation) while purpose-built tools manage the actual deployment.
- Your organization spans multiple teams with distinct responsibilities, requiring specialized tools tailored to their needs.
:::tip
When choosing a CI/CD tool, consider whether the tool itself can be managed with Infrastructure as Code (IaC). This ensures your pipeline configurations are version-controlled, easily reproducible, and aligned with your infrastructure management strategy.
:::
---
### **Recommendation**
For most IaC-heavy workflows, purpose-built CI/CD tools offer significant advantages, reducing complexity while enhancing security and reliability.
We at Nuvibit love Spacelift's unrivaled flexibility and advanced features tailored to infrastructure management.
Here’s why Spacelift stands out for us:
- **Flexibility Across IaC Tools**: Spacelift supports a wide range of IaC frameworks, including Terraform, OpenTofu, Pulumi, and more, making it ideal for diverse environments.
- **Native OPA Integration**: With built-in support for Open Policy Agent (OPA), Spacelift simplifies policy enforcement, ensuring compliance and governance from day one.
- **Streamlined Workflows**: Spacelift excels in managing complex workflows, such as multi-account AWS environments or intricate state management, reducing operational overhead.
- **Seamless Integration with NTC**: Spacelift provides amazing synergies with **Nuvibit Terraform Collection (NTC)**, enabling you to build robust, compliant, and secure AWS platforms effortlessly.
For organizations aiming to unlock the full potential of AWS, the combination of Spacelift and NTC provides the ultimate solution.
:::note
Due to Spacelift's exceptional value and perfect alignment with NTC, **Nuvibit has partnered with Spacelift to maximize and enhance our synergies**.
As a certified partner with deep expertise in complex Spacelift implementations, Nuvibit is uniquely positioned to deliver best-in-class solutions.
:::
:::tip
NTC also offers a **[Spacelift administration](https://docs.nuvibit.com/ntc-building-blocks/operations/ntc-administration-spacelift/)** building block, making it extremely easy to set up and manage Spacelift environments alongside your AWS infrastructure.
This integration reduces setup time and streamlines day-to-day operations.
:::
---
## Authentication Strategies for CI/CD Pipelines
Proper authentication is critical for securely deploying IaC. Two primary methods are widely used:
### **1. OpenID Connect (OIDC)**
OIDC provides short-lived tokens for pipeline authentication, eliminating the need for static credentials. AWS supports OIDC for CI/CD tools like GitHub Actions, GitLab, and Spacelift.
- **Advantages**:
- Secure, short-lived tokens reduce credential exposure.
- Simplifies credential management by linking directly to the identity provider.
- **Configuration**:
- Set up an OIDC identity provider in AWS.
- Assign roles with specific permissions to pipelines.
- Link pipelines to OIDC for secure authentication.
- [Learn more about AWS OIDC setup](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html).
### **2. IAM Access Keys (Legacy Alternative)**
Static IAM access keys can be used but are less secure and require regular rotation.
- **Recommendations**:
- Limit permissions attached to the IAM user.
- Use dedicated users for each pipeline to maintain accountability.
- Rotate keys frequently and automate key expiration.
---
## Types of CI/CD Pipelines for IaC Delivery
Choosing the right pipeline architecture depends on the size and complexity of your infrastructure. Below are three recommended approaches:
### **1. Single Pipeline Deploying into a Single AWS Account (Default Approach)**
- **Description**: A dedicated pipeline for each AWS account, typically linked to a specific IaC repository.
- **Advantages**:
- Minimizes blast radius; changes affect only one account.
- Easier state management with reduced dependency conflicts.
- Simplifies troubleshooting and accountability.
- **Use Case**: This approach should be the standard way to deploy infrastructure, as it minimizes the blast radius between accounts and stages.
### **2. Multiple Pipelines Deploying into a Single AWS Account**
- **Description**: Splits IaC deployment into multiple pipelines for the same account, separating infrastructure by logical components (e.g. networking, security, compute).
- **Advantages**:
- Isolates Terraform state files, reducing dependency conflicts.
- Facilitates incremental deployments and parallel workflows.
- **Use Case**: Useful for large, complex accounts with many distinct IaC resources to minimizes the blast radius in the account.
### **3. Single Pipeline Deploying into Multiple AWS Accounts**
- **Description**: A single pipeline manages deployments across multiple AWS accounts.
- **Advantages**:
- Centralized management for small-scale environments.
- **Disadvantages**:
- Increases blast radius; changes can inadvertently affect multiple accounts.
- More complex to maintain and troubleshoot.
- **Use Case**: Use only for uncritical infrastructure. Cross-account deployments have the biggest blast radius and risk.
---
## Naming Strategy Recommendations
Adopting a consistent naming convention simplifies pipeline management, provides clarity, and enhances traceability across infrastructure and application deployments. A thoughtful naming strategy becomes even more critical in environments with multiple AWS accounts and complex CI/CD workflows.
### **Separate Infrastructure and Application Deployments**
It is highly recommended to separate infrastructure and application deployments into distinct pipelines and repositories. This separation offers several advantages:
1. **Improved Governance**: Different teams or roles can manage infrastructure and application independently, reducing cross-impact risks.
2. **Simplified Maintenance**: Updates to infrastructure components, such as networking or IAM configurations, are isolated from application deployments, minimizing potential disruptions.
3. **Enhanced Security**: Permissions can be tailored to the specific needs of infrastructure or application pipelines, reducing the attack surface.
4. **Different Workflows**: Infrastructure and application deployments usually require different pipeline workflows, allowing for optimized processes tailored to each domain.
:::tip
For applications, maintain a single repository and pipeline across environments while linking to infrastructure pipelines that handle environment-specific resources.
:::
### **AWS Account Naming**
Account names should reflect their purpose, environment, or stage to ensure clarity and traceability.
- **Format**: `{prefix}-{application}-{environment}` or `{prefix}-{core-account-name}`
- **Examples**:
- `aws-webshop-prod` (AWS Production environment for Webshop App)
- `aws-webshop-dev` (AWS Development environment for Webshop App)
- `aws-log-archive` (AWS Centralized logging and audit account)
- `aws-connectivity` (AWS Centralized networking account)
### **Pipeline Naming**
Pipelines should clearly indicate whether they handle **infrastructure** or **application** deployment and align with the associated AWS account. This separation ensures better organization, minimizes confusion, and allows for more granular access controls.
- **Infrastructure Repository Format**: `{prefix}-{account-name}`
- Use a prefix like `infra-` for infrastructure pipelines for easy differentiation between infrastructure and application pipelines.
- **Application Repository Format**: `{prefix}-{application}`
- **Examples**:
- `infra-aws-webshop-prod` (Pipeline for provisioning infrastructure in the production environment of Webshop App)
- `app-webshop` (Pipeline for deploying application code, typically tied to the application repository)
### **Repository Naming**
Repository names should match the pipeline or resource they represent, maintaining alignment with the account and purpose.
Since applications often have a single repository, while infrastructure is split across stages or environments, the naming convention reflects this:
- **Infrastructure Repository Format**: `{prefix}-{application}-{environment}` or `{prefix}-{core-account-name}`
- **Application Repository Format**: `{application}`
- **Examples**:
- `infra-aws-connectivity` (IaC repository for the centralized networking account)
- `infra-aws-webshop-prod` (IaC repository for the production environment)
- `infra-aws-webshop-dev` (IaC repository for the development environment)
- `webshop` (Single repository for application code, independent of the environment)
By aligning AWS accounts, pipelines, and repositories with a consistent naming strategy, organizations can streamline CI/CD workflows, simplify onboarding for new team members, and improve operational efficiency.
---
## Best Practices for CI/CD Pipelines with IaC
1. **Implement Least Privilege**:
- Limit pipeline permissions to only those necessary for the deployment.
- Use separate roles for production and non-production environments.
2. **Automate State Management**:
- Use state backends like AWS S3 with DynamoDB locking or native state management from Spacelift or Terraform Cloud.
- Protect state files with encryption and access controls.
3. **Enable Drift Detection**:
- Monitor for changes made outside the pipeline to prevent configuration mismatches.
4. **Implement Testing**:
- Incorporate plan checks, linting, and unit tests to catch issues before deployment.
5. **Secure Secrets**:
- Store sensitive information (e.g. keys, tokens) securely using tools like AWS Secrets Manager or HashiCorp Vault.
---
## Conclusion
Setting up CI/CD pipelines for IaC deployments ensures a secure, scalable, and efficient infrastructure delivery process. Purpose-built CI/CD tools like Spacelift and Terraform Cloud enhance workflows, while proper authentication strategies such as OIDC minimize security risks. By adhering to best practices and adopting a modular pipeline architecture, you can significantly improve the reliability, security, and traceability of your IaC deployments.
For additional resources, explore the [Nuvibit Building Blocks](https://nuvibit.com/ntc-building-blocks) and start optimizing your AWS infrastructure today.
Source: https://docs.nuvibit.com/whitepapers/cicd-pipelines-iac-delivery
---
# Nuvibit AWS Reference Architecture
## Introduction
The **Nuvibit AWS Reference Architecture (NARA)** is the result of years of experience in building best-in-class AWS foundations and landing zones.
Refined and optimized through numerous iterations in real-world projects, this battle-tested framework now provides a reliable, scalable and secure solution for managing enterprise-grade AWS environments.
Tailored to meet the needs of modern organizations, NARA addresses critical challenges such as cloud governance, operational efficiency, and regulatory compliance.
By focusing on scalability, reliability, and security, it empowers organizations to unlock the full potential of AWS while safeguarding sensitive workloads and maintaining governance.
At the core of this architecture lies the **Nuvibit Terraform Collection (NTC)**, a suite of modular, enterprise-grade building blocks.
These building blocks streamline the implementation of the reference architecture, automating complex tasks such as account provisioning, connectivity, security tooling, and compliance management.
With **NARA** and **NTC**, organizations can confidently rely on a proven framework designed to accelerate cloud adoption, enforce best practices, and enable long-term operational excellence.
---
## Core Principles
### **Scalability**
The Nuvibit AWS Reference Architecture (NARA) ensures scalability by organizing the AWS environment into a structured multi-account framework.
This approach allows organizations to scale horizontally by adding new accounts for specific workloads, environments, or teams, and vertically by expanding resources within individual accounts as needed.
With integrated automation for provisioning, lifecycle management, and account baselining, organizations can seamlessly adjust their infrastructure to meet evolving business demands while maintaining control and efficiency.
### **Enterprise-Grade**
Enterprise-grade reliability lies at the core of the NARA design.
This is achieved through the deliberate segregation of critical functionalities into dedicated accounts, ensuring operational isolation and minimizing risk.
By compartmentalizing workloads, connectivity, and security operations, the architecture ensures that issues, such as misconfigurations or failures in one account, do not cascade across the entire organization.
This isolation strategy is bolstered by centralized logging, monitoring, and security tooling, providing comprehensive visibility and control.
The result is a robust and resilient foundation that safeguards the stability and availability of critical services, supporting uninterrupted operations and rapid issue resolution.
### **Compliance**
Designed for highly regulated industries, NARA integrates governance, customizable guardrails, and automated compliance features to meet stringent industry standards such as ISO 27001, GDPR, and HIPAA.
Centralized security tooling, log archiving, and fine-grained access controls ensure consistent enforcement of policies across all accounts.
By aligning with AWS best practices and providing built-in compliance capabilities, NARA enables organizations to confidently operate within regulatory frameworks while maintaining full sovereignty over their data.
### **Accelerated Cloud Adoption**
With pre-configured building blocks provided by the Nuvibit Terraform Collection (NTC), NARA removes the complexities and delays of manual configurations.
These modular building blocks automate key tasks like account provisioning, networking setup, and compliance enforcement, enabling organizations to quickly establish a secure and scalable AWS foundation.
By streamlining cloud adoption, NARA empowers teams to focus on innovation and deliver value at a faster pace.
---
## Core Accounts
Core accounts are the cornerstone of a multi-account AWS environment, supporting governance, security, and operational efficiency.
These accounts are essential for creating a scalable, secure, and well-governed AWS organization.
Some accounts are highly recommended, while others can be implemented based on specific organizational requirements.
### **Organization Management Account**
The Organization Management Account serves as the operational backbone for managing and governing all AWS accounts within the organization.
It enables the configuration of **AWS Organizations**, which allows defining a hierarchical structure of accounts and the enforcement of guardrails for consistent and centralized governance.
Example of an AWS organizational structure:
This centralized management streamlines tasks such as configuring account baselines (e.g. setting up foundational infrastructure, defining budget alerts) and implementing account lifecycle customizations (e.g. removing default VPCs, enabling opt-in regions).
Optional integration with **AWS Control Tower** adds further governance by providing pre-configured guardrails and best practices for multi-account setups.
The Nuvibit Terraform Collection (NTC) complements AWS Control Tower by filling gaps, such as advanced security tooling, automated identity management, and multi-account connectivity, ensuring a comprehensive and seamless solution.
This account is crucial for maintaining consistency, simplifying administration, and ensuring effective governance across the organization.
By centralizing these governance capabilities, the Organization Management Account simplifies administrative overhead, enforces consistency, and ensures robust governance across the entire AWS environment.
:::tip
NTC Building Blocks to streamline the deployment and management of the **Organization Management Account**:
- [NTC Organizations](https://docs.nuvibit.com/ntc-building-blocks/management/ntc-organizations/)
- [NTC Parameters](https://docs.nuvibit.com/ntc-building-blocks/management/ntc-parameters/)
- [NTC Account Factory](https://docs.nuvibit.com/ntc-building-blocks/management/ntc-account-factory/)
- [NTC Identity Center](https://docs.nuvibit.com/ntc-building-blocks/management/ntc-identity-center/)
:::
### **Log Archive Account**
The Log Archive Account provides centralized S3 buckets for securely storing logging and audit data generated across all AWS accounts in the organization.
Services such as **CloudTrail**, **VPC Flow Logs**, **GuardDuty** and **AWS Config** can be configured to forward their logs to this account, ensuring a centralized and comprehensive audit trail for compliance, troubleshooting, and monitoring purposes.
Audit logs are encrypted using **AWS KMS** to maintain their confidentiality and integrity.
By consolidating logs from multiple accounts, this account plays a vital role in achieving regulatory compliance requirements, and in facilitating detailed forensic analysis in the event of a security incident.
Its role in maintaining a centralized and secure log repository makes it indispensable for ensuring operational transparency and regulatory adherence.
:::tip
NTC Building Blocks to streamline the deployment and management of the **Log Archive Account**:
- [NTC Log Archive](https://docs.nuvibit.com/ntc-building-blocks/security/ntc-log-archive/)
- [NTC Organizations](https://docs.nuvibit.com/ntc-building-blocks/management/ntc-organizations/) (organization trail)
:::
### **Security Tooling Account**
The **Security Tooling Account** is a dedicated environment to centralize and manage security services across the AWS organization.
It acts as a focal point for compliance monitoring, analyzing, and enforcing security policies, providing a robust foundation for identifying and mitigating threats.
This account aggregates security findings in **AWS Security Hub**, offering a unified view of the organization’s security posture.
By integrating with tools such as **AWS Config** for resource compliance, **GuardDuty** for threat detection, and **Inspector** for vulnerability management, it ensures comprehensive coverage of potential security risks.
Additionally, **IAM Access Analyzer** helps identify overly permissive roles and policies, enabling administrators to address access-related vulnerabilities proactively.
The **Security Tooling Account** is essential for protecting sensitive data, maintaining compliance, and strengthening the organization’s defense against an ever-evolving threat landscape.
Its central role ensures that security services and policies operate seamlessly across all accounts, contributing to a secure and resilient AWS environment.
:::tip
NTC Building Blocks to streamline the deployment and management of the **Security Tooling Account**:
- [NTC Security Tooling](https://docs.nuvibit.com/ntc-building-blocks/security/ntc-security-tooling/)
- [NTC Organizations](https://docs.nuvibit.com/ntc-building-blocks/management/ntc-organizations/) (admin delegations)
:::
### **Connectivity Account**
The Connectivity Account is dedicated to managing the organization’s central networking infrastructure, ensuring secure and reliable connectivity between AWS accounts, regions, and on-premises environments.
Key components of the Connectivity Account include **AWS Transit Gateway** for interconnecting VPCs and regions, **AWS Direct Connect** or **AWS VPN** for secure access to on-premises environments, **Amazon Route 53** for DNS configurations, and **AWS Network Firewall** for centralized traffic inspection and filtering.
While centralizing network management simplifies governance and reduces operational complexity, not all networking components need to be centralized.
The Connectivity Account can work in conjunction with decentralized networking elements, such as VPC-specific configurations managed directly within workload accounts.
This hybrid approach allows for greater flexibility, enabling teams to expand and customize their network infrastructure while maintaining core security and connectivity standards.
This approach ensures that traffic is routed securely and efficiently, supporting both single-region and multi-region deployments.
The Connectivity Account plays a critical role in maintaining a robust, adaptable, and scalable network infrastructure for the organization.
:::tip
NTC Building Blocks to streamline the deployment and management of the **Connectivity Account**:
- [NTC IP Address Management (IPAM)](https://docs.nuvibit.com/ntc-building-blocks/connectivity/ntc-ipam/)
- [NTC Core Networking](https://docs.nuvibit.com/ntc-building-blocks/connectivity/ntc-core-network/)
- [NTC VPC](https://docs.nuvibit.com/ntc-building-blocks/connectivity/ntc-vpc/)
- [NTC Route53](https://docs.nuvibit.com/ntc-building-blocks/connectivity/ntc-route53/)
:::
### **Monitoring Account (optional)**
The Monitoring Account serves as a centralized hub for monitoring and observability within the AWS environment.
It is particularly useful for consolidating application metrics, logs, and traces generated across multiple accounts into a unified view.
Services such as **Amazon CloudWatch**, **AWS X-Ray**, and third-party integrations for tools like **Prometheus** and **Grafana** can be deployed in this account to manage monitoring at scale.
By separating monitoring into a dedicated account, organizations can isolate monitoring-related permissions and ensure that observability data is securely managed.
This account becomes especially important for organizations that rely on AWS-native tools for monitoring or require a single-pane-of-glass view of their infrastructure's health and performance.
However, if external tools like Splunk or Datadog are preferred, this account may not be necessary.
:::info
NTC Building Blocks to streamline the deployment and management of the **Monitoring Account**:
- NTC Observability (planned)
:::
### **Backup Account (optional)**
The Backup Account is a dedicated environment for managing and securing backups of critical data and resources.
It provides a centralized location for **AWS Backup** services to orchestrate and automate the backup of data across all AWS accounts, ensuring compliance with recovery objectives and minimizing data loss in case of failure.
This account can host encrypted backups of services such as Amazon S3, EBS volumes, and Databases, creating an additional layer of data protection.
By isolating backup management in its own account, organizations can implement robust security policies, limit access to sensitive backup data, and reduce the risk of accidental deletion or modification.
For organizations using external backup tools such as Veeam or Cohesity, this account might not be required.
However, for those relying on AWS-native solutions, a Backup Account is an essential part of a resilient disaster recovery strategy.
:::tip
NTC Building Blocks to streamline the deployment and management of the **Backup Account**:
- [NTC Backup](https://docs.nuvibit.com/ntc-building-blocks/operations/ntc-backup/)
:::
---
## Workload Accounts: Dedicated Accounts for Each Stage
The Nuvibit AWS Reference Architecture emphasizes the importance of separating workloads and workload stages into dedicated AWS accounts.
This approach enhances security, operational efficiency, and governance while aligning with AWS’s best practices.
### **Security and Isolation**
By isolating workloads into separate accounts, the architecture ensures that incidents or configuration errors in one account do not affect others.
For example, critical production workloads are isolated from development and sandbox environments, minimizing the risk of accidental disruptions.
### **Customizable Guardrails**
Guardrails (e.g. Service Control Policies) can be tailored to each account type.
Production accounts typically have stricter guardrails to enforce compliance and prevent risky actions, while development accounts allow more flexibility for experimentation.
Sandbox accounts provide the freedom to test new AWS services and rapid prototyping without risks, making them ideal for research and innovation.
### **Cost and Resource Management**
Separating workloads by stage simplifies cost tracking and allocation.
Each account can have its own budget and quotas, ensuring that resources are used efficiently and within defined limits.
As a result, this enables fine-grained billing without having to implement complex tagging policies for cost allocation.
### **Scalability and Lifecycle Management**
Dedicated accounts make it easier to scale workloads independently and manage their lifecycle.
For example, sandbox accounts can be easily decommissioned when no longer needed, while production accounts can scale vertically or horizontally without impacting other environments.
### **Account Baseline**
Establishing a consistent account baseline ensures that all newly created accounts adhere to organizational governance standards.
This includes pre-configured security settings, connectivity configurations, and log forwarding.
An account baseline simplifies onboarding and ensures compliance even as the number of accounts grows into the hundreds.
---
## Customizing the Architecture
The Nuvibit AWS Reference Architecture (NARA) is designed with scalability, security, and compliance at its core, making it an ideal choice for enterprises in regulated sectors (e.g. governments).
However, its flexibility allows it to be tailored to meet the unique needs of various industries and organizations through customizations.
### **Scalability for Growing Startups**
Rapidly growing startups can leverage this architecture to establish a resilient foundation that scales effortlessly with their evolving needs.
Its modular design ensures that as teams and workloads expand, the infrastructure remains manageable and robust.
Dedicated workload accounts simplify scaling while maintaining strong security and governance.
### **Segmentation for ISVs**
Independent Software Vendors (ISVs) and managed service providers benefit from the architecture’s ability to segment customer environments into dedicated accounts.
This approach ensures strict data separation, reduces cross-environment risks, and simplifies resource tracking.
It also supports contractual and regulatory requirements for customer data isolation.
### **Compliance and Security for Financial Institutions**
For financial institutions in regulated industries, the architecture offers comprehensive compliance and security features.
Centralized logging, robust guardrails, and automated security tooling address key regulatory requirements.
With targeted customization, organizations can meet finance-specific standards such as FINMA or GDPR by closing any remaining compliance gaps.
### **Adaptability Across Industries**
Although initially designed for regulated sectors, the architecture is highly adaptable to different industries such as healthcare, manufacturing, and utilities.
Organizations can extend or modify configurations to align with their specific operational and compliance needs while maintaining scalability and security.
### **Tailored to Your Needs**
Nuvibit’s expertise ensures that this architecture can be customized to precisely meet your organization’s requirements.
Whether you are scaling a startup, isolating customer environments, or achieving compliance with industry-specific regulations, Nuvibit delivers a cloud platform tailored to your operational goals.
The Nuvibit Terraform Collection (NTC) Building Blocks are designed for flexibility, enabling you to design and implement an architecture that aligns perfectly with your needs.
---
## Benefits of the Nuvibit AWS Reference Architecture
The Nuvibit AWS Reference Architecture (NARA) simplifies cloud management by centralizing governance and automating repetitive tasks.
By leveraging AWS Organizations combined with guardrails, administrators can enforce compliance policies across all accounts with minimal effort.
This reduces the administrative burden and ensures that the entire environment operates within those predefined guardrails.
With security as a top priority, the architecture isolates workloads into dedicated accounts and implements robust protections such as automated baselines, centralized logging, and integrated security tooling.
These features provide strong defenses against potential threats while maintaining visibility and control.
Operational efficiency is another key benefit of this architecture.
Pre-configured modules and automated workflows streamline the deployment and management of resources, enabling organizations to focus on innovation rather than infrastructure maintenance.
Finally, the architecture’s compliance and sovereignty features ensure that organizations can meet regulatory requirements without sacrificing agility.
Centralized log storage, customizable guardrails, and AWS KMS encryption provide the tools needed to maintain data sovereignty and align with industry standards.
---
## Conclusion
The **Nuvibit AWS Reference Architecture (NARA)** represents a transformative approach to cloud management, combining scalability, reliability, and compliance into a cohesive framework.
By leveraging the Nuvibit Terraform Collection (NTC), organizations can confidently accelerate their AWS cloud adoption while ensuring governance, scalability, and compliance for the future of their digital transformation.
:::tip
For a step-by-step guide to implementing this architecture, refer to the **[Quickstart Guide](https://docs.nuvibit.com/getting-started/quickstart)** and kickstart your cloud journey with the **Nuvibit Terraform Collection (NTC)**.
:::
Source: https://docs.nuvibit.com/whitepapers/nuvibit-aws-reference-architecture