Wombat

Architecture Reference

This page describes the abstract reference model on which Wombat is built, and provides decision guides for recurring architectural questions in cloud platforms.

Layer Model

Wombat views cloud platforms through four stacked layers. Each layer has its own controls, best practices, and responsibilities.

Layer Components Wombat Relevance

Infrastructure Layer

Compute, storage, networking, KMS, IAM

Pillar 1 (Security), Pillar 2 (Cost), Pillar 7 (Sovereign) – physical controls, encryption, tagging, region pinning

Platform Layer

Kubernetes, service mesh, CI/CD, observability, secret management

Pillar 3 (Performance), Pillar 4 (Reliability), Pillar 5 (Operations) – scaling, SLOs, deployment automation

Application Layer

Microservices, APIs, databases, queues, batch jobs

All pillars – workload-specific controls, tagging, resilience patterns

Cross-Cutting Concerns

Security, compliance, cost, resilience, sustainability

All 7 pillars – overarching governance, audit trail, regulatory mapping

The layers are not isolated: a decision at the infrastructure level (e.g. region pinning) pulls controls at the platform and application level (e.g. log residency, backup location).

Architecture Principles

Wombat is built on seven architecture principles that apply across all pillars:

AP-1 – Explicit over Implicit

Every configuration that affects security, cost, or compliance must be explicitly defined in IaC. Implicit cloud defaults (regions, encryption, network ACLs) are not acceptable.

Relevant controls: SOV-020 (Region Pinning), SOV-050 (Key Ownership), COST-010 (Tagging)

AP-2 – Policy-as-Code

All policies – security, cost, residency – must be machine-readable and version-controlled. Manual policies in PDFs are not auditable and drift away from reality.

Relevant controls: SOV-010 (Data Residency Policy), COST-050 (ADR Cost Impact), COST-100 (Cost Debt Register)

AP-3 – Shift Left

Compliance and cost checks belong in the PR process, not in post-deployment audits. wombat in CI/CD is the primary implementation of this principle.

Relevant controls: COST-010, COST-020, SOV-020 – all with automated: true

AP-4 – Least Privilege by Default

All roles, network rules, and access rights are defined with minimal scope. Wildcards (Action: *, 0.0.0.0/0) are explicitly prohibited.

Relevant controls: SOV-060 (Privileged Access), SOV-090 (Egress Control)

AP-5 – Data Sovereignty as a Design Principle

Data classification, jurisdiction requirements, and deletion obligations are considered at the first design of an architecture – not retroactively.

Relevant controls: SOV-010, SOV-020, SOV-030, SOV-040, SOV-050

AP-6 – Cost Transparency as a Prerequisite for Optimization

Without complete cost allocation (tagging, budgets, alerts), no optimization is possible. Cost optimization always starts with visibility.

Relevant controls: COST-010 (Tagging), COST-020 (Budgets), COST-060 (FinOps Cadence)

AP-7 – Exit Capability as a Design Criterion

Every architectural decision is also evaluated by how reversible it is. Vendor lock-in is not fate – it is a design decision.

Relevant controls: SOV-080 (Dependency Inventory), SOV-100 (Exit Plan), COST-050 (ADR Cost Impact)

Decision Guides

Multi-Cloud vs. Single-Cloud

Criterion Single-Cloud Multi-Cloud

Operational complexity

Low – one provider, one tooling stack

High – multiple control planes, different IAM models

Vendor lock-in risk

High – deep integration into proprietary services

Low – portability via abstraction layer

Compliance (GDPR/BSI C5)

Simpler – one DPA, one audit scope

More complex – multiple DPAs, cross-data flows to verify

Cost

Lower egress costs, volume discounts

Higher egress costs, more complex reserved capacity planning

Wombat recommendation

Default for new platforms

Only when resilience or portability requirements demand it

Before choosing multi-cloud: fully complete SOV-100 (Exit Plan) and COST-050 (ADR Cost Impact).

Managed Services vs. Self-Hosted

Criterion Managed Service Self-Hosted

Operational effort

Low – provider handles patches, backups, HA

High – full responsibility with the team

Data sovereignty

Limited – provider’s subprocessor chain applies

Full – own control over data location and access

Cost

Predictable, but premium over self-hosted

Variable, risk of hidden operational costs

Compliance evidence

Provider certificates (SOC2, BSI C5, ISO 27001)

Own certification required

Wombat recommendation

Default – operational effort always has hidden costs

Only when data sovereignty or specific requirements force it

Network & Zero-Trust Architecture

Decision Wombat Guideline

Segmentation

Each workload in its own network segment (VPC/VNET/Subnet). No flat networks.

Egress

No public egress by default (0.0.0.0/0). VPC endpoints for cloud services. (SOV-090, COST-090)

Ingress

Only explicitly defined ports and CIDRs. No security groups with 0.0.0.0/0 except ALB/NLB.

Internal communication

mTLS preferred (service mesh). No plain HTTP between internal services.

Zero Trust

Identity rather than network position as the trust basis. Short token lifetimes, regular rotation.

Encryption – Decision Matrix

Data category At Rest In Transit Key management

PII / Health / Financial

CMK (Customer Managed Key) mandatory

TLS 1.2+ mandatory

HSM or Cloud KMS with rotation (SOV-050)

Operational / Internal

CMK recommended, SSE-S3/AES256 acceptable

TLS 1.2+

Cloud KMS, annual rotation

Public / Logs (non-PII)

SSE-S3 / AES256 sufficient

TLS 1.2+

Cloud-managed

Backup

CMK recommended

TLS 1.2+

Separate KMS region preferred (SOV-030)

Maturity – Cross-Pillar Model

The Wombat Maturity Model has 5 levels. The overall maturity of a platform is the minimum across all assessed pillars.

Level Name Characteristics

1

Ad hoc

No structured controls. Individual decisions without documentation. High variance between teams.

2

Standardized

Basic policies documented. Manual implementation. First reuse of IaC modules.

3

Integrated

Controls integrated into CI/CD. Automated checks (WOMBATpass). KPIs in place. Compliance reporting possible.

4

Sovereign

Fully automated and auditable. Drift detection active. Regulatory mappings evidenced.

5

Optimized

Continuous improvement. Automatic remediation. Real-time dashboards. Contribution to framework controls.

Typical Starting Points by Context

Context Typical entry level Priority

Greenfield (new project)

Level 2

Target Level 3 immediately: CI gates, tagging, region pinning

Brownfield (existing platform)

Level 1–2

Gap analysis first, then prioritized remediation plan

Pre-audit (BSI C5 / ISO 27001)

Level 2–3

Level 4 for Sovereign pillar is minimum requirement

FinOps initiative

Level 1–2

Level 3 for Cost pillar (tagging, budgets, CI gates)

ADR Template with Wombat Cost Impact

Architectural decisions (ADRs) should always include a cost impact section (WAF-COST-050):

# ADR-NNN: [Decision title]

## Status
Proposed | Accepted | Deprecated

## Context
[Why is this decision being made?]

## Decision
[What is being decided?]

## Consequences
[Positive and negative impacts]

## Wombat Cost Impact
- **Ongoing costs:** [estimated monthly additional costs / savings]
- **Egress risk:** [Yes / No – justification]
- **Lock-in assessment:** [Reversibility level 1–5, 1=easily switchable]
- **Architectural cost debt:** [Does this create cost debt? If yes: add to cost debt register]
- **Reserved capacity:** [Is the resource suitable for commitment? If yes: set capacity-commitment tag]

Further Reading