Design Patterns

The following patterns are proven and derived from the Wombat principles. They are formulated in a cloud-agnostic manner, with provider-specific notes.

Pattern 1: Region-Pinned Landing Zone

Problem

Without a structured landing zone, individual teams can create resources in arbitrary regions.

Solution

A landing zone with built-in region pinning overrides all other measures through technical upfront constraints.

Structure

Organization Root
├── Management Account
│   └── Service Control Policy: DenyOutsideApprovedRegions
├── Sovereign Workload OU
│   ├── Production Account
│   │   ├── Terraform: provider.region = var.aws_region (validated)
│   │   ├── VPC Endpoints: S3, KMS, ECR, STS
│   │   └── CloudTrail: multi-region, log-validation, sovereign S3
│   └── Non-Production Account
│       └── Same constraints, different data classification
└── Shared Services Account
    └── Central Logging: CloudWatch Logs, S3 (eu-central-1 enforced)

Controls

WAF-SOV-010: Residency policy reflected in IaC defaults
WAF-SOV-020: SCP prevents outside-region deployments
WAF-SOV-040: Central logging stored sovereignly

Anti-Pattern

Individual accounts without SCP guardrails
"Default VPC" with open security group configuration
No central logging account

Pattern 2: Sovereign Key Hierarchy

Problem

Standard encryption with provider-managed keys gives the provider theoretical access.

Solution

A three-tier key hierarchy based on data criticality:

Tier 1 – Public/Low-sensitivity Data
└── Provider-Managed Key (PMK) – acceptable

Tier 2 – Internal/Operational Data
└── Customer-Managed Key (CMK) in Cloud-KMS
    ├── Rotation: automatic (annual)
    └── Key Policy: restrict to specific services/principals

Tier 3 – PII / Financial / Health Data
└── BYOK: Customer-Key, Cloud-managed HSM (CloudHSM, Azure HSM, Cloud HSM)
    or
    HYOK: Key in external HSM (Thales, Utimaco, Securosys)
    ├── Access for cloud provider: technically not possible
    └── Rotation: manual / process-driven

Controls

WAF-SOV-050: Key ownership, rotation, deletion

Recommendations

CloudHSM (AWS) or Azure Dedicated HSM for Tier-2/3 keys
Document and conduct key ceremonies for HYOK annually
Plan cryptographic erasure as GDPR Art. 17 implementation

Pattern 3: Sovereign Observability Stack

Problem

Standard monitoring setups export telemetry data to US-based SaaS providers.

Solution

A sovereign observability stack processes data within approved regions:

Application
└── OpenTelemetry SDK (vendor-neutral)
    ├── Traces → Sovereign Trace Backend (Jaeger/Tempo in eu-central-1)
    ├── Metrics → Sovereign Metrics Backend (Prometheus/Thanos in eu-central-1)
    └── Logs → CloudWatch/S3 (eu-central-1, retention=90d, KMS-encrypted)
                    └── Optional export to DPA-secured SIEM

If external SIEM is necessary:

Conclude DPA and verify data processing region
Data masking before export (remove PII fields)
Export via Private Link / VPN (no public internet)
Regular review: which data leaves the sovereignty boundary?

Controls

WAF-SOV-040: Logging residency
WAF-SOV-090: Egress control

Pattern 4: Break-Glass with Zero Standing Privilege

Problem

Permanent admin roles are a permanent attack target.

Solution

Zero Standing Privilege: admin access does not exist permanently, but is only activated on demand.

Normal Operations:
├── Developers: read-only or scoped write (application level)
├── Operations: operations role (no IAM access)
└── Platform: platform role (IaC deploy, no data access)

Break-Glass Activation:
├── Trigger: documented incident / approval (Dual Control)
├── Activation: JIT system (IAM Identity Center / Azure PIM)
├── Duration: max. 4h, automatic deactivation after expiry
├── Logging: CloudTrail captures all actions
└── Review: post-incident review within 5 business days, record archived

Controls

WAF-SOV-060: Privileged access, SoD
WAF-SOV-070: Break-glass process & logging

Pattern 5: Sovereign Egress Gateway

Problem

Applications with open egress configuration can send data to arbitrary destinations.

Solution

Centralized egress point with domain allow-list and anomaly detection:

Workload Subnet (Private)
└── all outgoing connections → Egress Gateway

Egress Gateway
├── AWS Network Firewall / Azure Firewall / GCP Cloud Armor
├── Domain Allow-List (FQDN-based)
│   ├── Approved: *.amazonaws.com (via VPC Endpoint)
│   ├── Approved: *.internal.company.com
│   └── Blocked: * (default deny)
├── DNS: Route53 Resolver / Azure Private DNS
└── Logging: Flow Logs → sovereign S3

VPC Endpoints (no internet routing):
├── com.amazonaws.eu-central-1.s3
├── com.amazonaws.eu-central-1.kms
├── com.amazonaws.eu-central-1.ecr.api
└── com.amazonaws.eu-central-1.sts

Controls

WAF-SOV-090: Controlled egress
WAF-SOV-040: VPC Flow Logs

Pattern 6: Exit-Ready IaC Architecture

Problem

Proprietary IaC with hard-coded provider dependencies makes migration extremely expensive.

Solution

Portable IaC with abstract modules and open standards:

IaC Abstraction Layer
├── Module: network/vpc → AWS VPC or Azure VNet
├── Module: storage/object → S3 or Azure Blob or GCS
├── Module: database/relational → RDS PostgreSQL or Azure PostgreSQL
└── Module: compute/container → EKS or AKS or GKE

Data Standards:
├── PostgreSQL (open) instead of Aurora Serverless v2 (proprietary)
├── OpenTelemetry instead of X-Ray (proprietary)
└── S3-compatible API instead of proprietary object store features

Exit-Readiness:
├── Quarterly Data Export Test: all data exported and validated
├── Terraform Plan in target cloud: IaC adapted and planned
└── Lessons Learned documented

Controls

WAF-SOV-100: Exit plan & portability
WAF-SOV-080: Dependency & subprocessor inventory