WAF++ WAF++
Back to WAF++ Homepage

Architecture Reference

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

Layer Model

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

Layer Components WAF++ 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

WAF++ 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. wafpass 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

WAF++ 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

WAF++ recommendation

Default – operational effort always has hidden costs

Only when data sovereignty or specific requirements force it

Network & Zero-Trust Architecture

Decision WAF++ 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 WAF++ 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 (wafpass). 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 WAF++ 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]

## WAF++ 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