Cloud Infrastructure Fundamentals · Module 12 of 12

Capstone: production-shaped cloud architecture

Integrate networking relationships, allowed flows, recovery objectives, risk-to-control mappings, observability, cost and controlled IaC into a machine-checked production-shaped architecture.

Learning objectives

By the end of this module, you should be able to:

Design a multi-AZ application path with public edge and private application/data tiers whose CIDRs are valid and non-overlapping.
Express explicitly allowed flows and reject direct internet paths to the data tier.
Prove numeric RTO/RPO claims against backup and restore-test evidence.
Map one failure, one security threat and one cost risk to concrete controls present in the architecture.
Score the design with a rubric covering network, security, reliability, operations, cost and delivery safety.

Architecture is a set of explicit trade-offs

There is no universal production architecture. Start with availability, security, recovery, performance, compliance and cost requirements, then choose services and boundaries.

Separate ingress, application and data responsibilities

A typical web workload may expose only the load-balancing edge, keep application compute private, and restrict data services to application identities/network paths. Exact services vary by provider.

Operational controls are part of the architecture

Backups, logs, metrics, audit, ownership tags, budgets, deployment verification and rollback are not afterthoughts. They are part of the system design.

A capstone should validate relationships, not honesty checkboxes

A production-shaped manifest should describe which networks contain which tiers, which flows are allowed, what recovery numbers are promised and which controls mitigate identified risks. Validation can then reject contradictions instead of merely confirming that fields were set to true.

Recovery claims require numeric evidence

If the stated RPO is 15 minutes, the modeled backup or recovery-point interval must be no worse than 15 minutes. If the RTO is 60 minutes, a measured restore/recovery test that takes 90 minutes does not meet the objective. Architecture documentation should make such mismatches visible before deployment.

Worked examples

See the idea in practice.

Reference flow

Internet
   ↓ 443
DNS → TLS load balancer (edge subnets, multi-AZ)
   ↓ 8080
private application tier
   ↓ 5432
private managed database
   ↘ object storage via controlled service path

Cross-cutting: temporary identity · KMS/secrets · logs/metrics/flow logs/audit · backups · tags/budgets · Terraform/OpenTofu-safe delivery

The public edge is intentionally narrow; application and data tiers remain private.
Every arrow should correspond to an explicit allowed flow or service path rather than “the network allows everything.”

Core lab · Modes 1–2 · Concept + local simulation

Capstone — Validate architecture relationships, recovery and risk controls

Goal: Build a manifest that fails when tiers escape the VPC, data becomes internet-reachable, recovery claims are inconsistent, or risks point to controls that do not exist.

Before you start

Linux, macOS or Windows 11 with WSL2.
Python 3 only. No cloud account is required.
Allow 2–3 hours for design, validation, deliberate failure tests and rubric review.

STEP 1

Create the architecture manifest

cat > /tmp/cloud-capstone.json <<'JSON'
{
  "vpc_cidr":"10.20.0.0/22",
  "zones":2,
  "tiers":{
    "edge":{"subnets":["10.20.0.0/24","10.20.2.0/24"],"public":true},
    "app":{"subnets":["10.20.1.0/25","10.20.3.0/25"],"public":false},
    "data":{"subnets":["10.20.1.128/25","10.20.3.128/25"],"public":false}
  },
  "flows":[
    {"from":"internet","to":"lb","port":443,"source":"0.0.0.0/0"},
    {"from":"lb","to":"app","port":8080,"source":"edge"},
    {"from":"app","to":"db","port":5432,"source":"app"}
  ],
  "recovery":{"rto_minutes":60,"rpo_minutes":15,"backup_interval_minutes":15,"restore_test_minutes":45,"strategy":"backup_restore"},
  "controls":{"multi_az":true,"temporary_identity":true,"tls":true,"private_data_tier":true,"encryption_at_rest":true,"backups":true,"audit_logs":true,"monitoring":true,"owner_tags":true,"budget":true},
  "risks":{
    "failure":{"scenario":"availability-zone failure","control":"multi_az"},
    "threat":{"scenario":"direct public database exposure","control":"private_data_tier"},
    "cost":{"scenario":"unowned resources continue running","control":"owner_tags"}
  },
  "delivery":{"terraform":true,"reviewed_plan":true,"post_change_health":true,"rollback":true,"cleanup":true}
}
JSON

STEP 2

Create and run the relationship-aware validator

cat > /tmp/validate-cloud-capstone.py <<'PY'
import ipaddress,json,sys
path=sys.argv[1] if len(sys.argv)>1 else '/tmp/cloud-capstone.json'
a=json.load(open(path))
vpc=ipaddress.ip_network(a['vpc_cidr'])
subnets=[]
for tier,meta in a['tiers'].items():
    nets=[ipaddress.ip_network(x) for x in meta['subnets']]
    assert len(nets)>=2, f'{tier} must span at least two subnet ranges'
    for n in nets:
        assert n.subnet_of(vpc), f'{n} is outside {vpc}'
        subnets.append((tier,n))
for i,(ta,a_net) in enumerate(subnets):
    for tb,b_net in subnets[i+1:]:
        assert not a_net.overlaps(b_net), f'overlap: {ta}:{a_net} and {tb}:{b_net}'
assert a['zones']>=2, 'architecture must span at least two availability zones'
assert a['tiers']['edge']['public'] is True, 'edge tier should be the public ingress tier'
assert a['tiers']['app']['public'] is False and a['tiers']['data']['public'] is False, 'application/data tiers must remain private'
required={("internet","lb",443),("lb","app",8080),("app","db",5432)}
actual={(f['from'],f['to'],f['port']) for f in a['flows']}
assert required<=actual, f'missing required flow: {required-actual}'
for f in a['flows']:
    assert not (f['to'] in {'db','data'} and f.get('source') in {'0.0.0.0/0','::/0'}), 'data tier must not accept internet-wide source'
    assert not (f['from']=='internet' and f['to'] in {'db','data'}), 'internet must not connect directly to data tier'
r=a['recovery']
assert r['rto_minutes']>0 and r['rpo_minutes']>=0, 'RTO/RPO must be numeric non-negative objectives'
assert r['backup_interval_minutes']<=r['rpo_minutes'], 'backup interval violates RPO'
assert r['restore_test_minutes']<=r['rto_minutes'], 'measured restore violates RTO'
for kind,item in a['risks'].items():
    assert item['scenario'].strip(), f'{kind} scenario missing'
    key=item['control']; assert key in a['controls'], f'{kind} maps to unknown control {key}'
    assert a['controls'][key] is True, f'{kind} control {key} is not enabled'
for k in ('temporary_identity','tls','private_data_tier','encryption_at_rest','backups','audit_logs','monitoring','owner_tags','budget','multi_az'):
    assert a['controls'].get(k) is True, f'missing required control {k}'
assert all(a['delivery'].values()), 'delivery evidence must include plan review, health verification, rollback and cleanup'
print('PASS: architecture relationships, recovery objectives and risk mappings validated')
PY
python3 /tmp/validate-cloud-capstone.py /tmp/cloud-capstone.json

STEP 3

Deliberately break the data-tier security rule and prove rejection

python3 - <<'PY'
import json,copy
a=json.load(open('/tmp/cloud-capstone.json')); bad=copy.deepcopy(a)
bad['flows'].append({'from':'internet','to':'db','port':5432,'source':'0.0.0.0/0'})
json.dump(bad,open('/tmp/cloud-capstone-bad-flow.json','w'),indent=2)
PY
if python3 /tmp/validate-cloud-capstone.py /tmp/cloud-capstone-bad-flow.json; then
  echo 'ERROR: validator accepted direct internet-to-database flow' >&2; exit 1
else
  echo 'PASS: validator rejected direct internet-to-database flow as expected'
fi

STEP 4

Deliberately break recovery evidence and prove rejection

python3 - <<'PY'
import json,copy
a=json.load(open('/tmp/cloud-capstone.json')); bad=copy.deepcopy(a)
bad['recovery']['backup_interval_minutes']=60
json.dump(bad,open('/tmp/cloud-capstone-bad-recovery.json','w'),indent=2)
PY
if python3 /tmp/validate-cloud-capstone.py /tmp/cloud-capstone-bad-recovery.json; then
  echo 'ERROR: validator accepted a backup interval that violates RPO' >&2; exit 1
else
  echo 'PASS: validator rejected recovery evidence that violates RPO as expected'
fi

STEP 5

Score the design with the rubric

Use the rubric below. For every criterion, point to concrete manifest evidence. A statement such as “secure” earns no credit unless the network/control relationship that makes it true is shown.

Verify

Every tier subnet is non-overlapping and contained inside the VPC CIDR.
Edge is public while application/data tiers are private.
Required flows are present and no 0.0.0.0/0 or direct internet path reaches the data tier.
Backup interval meets the stated RPO and measured restore time meets the stated RTO.
Failure, threat and cost-risk entries each reference an enabled control that actually exists.
Terraform delivery includes plan review, health verification, rollback and cleanup evidence.

Expected outcome

You produce a reviewable architecture artifact whose important relationships can be rejected automatically when they contradict the stated security or recovery design.

Diagnose / troubleshoot

“outside VPC” means at least one tier subnet is not contained by vpc_cidr; compare the prefix and address boundary rather than changing the validator.
“overlap” means two tier CIDRs intersect; redesign the address plan before adding routes.
“data tier must not accept internet-wide source” means a flow exposes DB/data to 0.0.0.0/0 or ::/0; route traffic through the intended application identity/path instead.
“backup interval violates RPO” means the promised data-loss window is tighter than the modeled recovery-point generation frequency.
“measured restore violates RTO” means the tested recovery takes longer than the business objective; improve the recovery design or renegotiate the objective.
“unknown control” means a risk names mitigation evidence that the manifest cannot prove exists.

Real-world connection

A real architecture review would add provider limits, DNS/TLS details, database failover behavior, endpoint routes, IAM policy evidence, logging destinations, pricing, compliance and tested Terraform plans. The capstone intentionally teaches how to make claims falsifiable before provisioning.

Mode 3 · Optional AWS lab

Optional AWS — compare an existing sandbox to the capstone

Use read-only inventory to identify which capstone layers already exist; do not provision the production-shaped stack in this fundamentals lab.

Resources created

None — this is a read-only inspection lab.

Estimated cost / risk

Expected incremental resource cost: none because the supplied commands are read-only.
Existing resources in the account can still incur their normal charges; confirm current AWS pricing for the selected Region/account.

Prerequisites

Optional sandbox AWS account and AWS CLI.
Use a least-privilege or federated identity; do not paste long-lived access keys into course files.

AWS 1

aws ec2 describe-vpcs --query 'Vpcs[].VpcId' --output table

AWS 2

aws elbv2 describe-load-balancers --query 'LoadBalancers[].DNSName' --output table

AWS 3

aws ec2 describe-instances --query 'Reservations[].Instances[].InstanceId' --output table

AWS 4

aws rds describe-db-instances --query 'DBInstances[].DBInstanceIdentifier' --output table

AWS 5

aws s3api list-buckets --query 'Buckets[].Name' --output table

Verify

You can map existing sandbox resources to load-balancer/network/compute/database/object-storage layers or mark the layer absent.
No AWS resources are created by the supplied commands.

Cleanup

No AWS cleanup is required because this lab creates no AWS resources.

Warnings

Optional only: not required for course completion or the main validator.
Do not create NAT Gateway, RDS, ALB or other billable capstone components merely to satisfy this course.

Capstone rubric

Score evidence, not claims.

Use this rubric after the validator passes. Every score should point to concrete manifest or design evidence.

Network segmentation and allowed flows · 20%

Valid non-overlapping tier CIDRs; public edge only; explicit internet→LB, LB→app and app→DB paths; no internet-wide data-tier source.

Identity and security controls · 20%

Temporary workload identity, TLS, private data tier, encryption at rest, secret/key boundaries and auditable access.

Reliability and recovery · 20%

Multi-zone design, explicit RTO/RPO, backup interval and measured restore result that satisfy the objectives, plus a justified DR pattern.

Observability and operations · 15%

Metrics/logs/audit/flow visibility, health verification and ownership/runbook evidence.

Cost and governance · 10%

Owner tags, budget/cost risk, service-path choices such as endpoint versus NAT where appropriate, and no needless always-on billable lab resources.

IaC and change safety · 10%

Reviewed plan, temporary automation identity, controlled apply, post-change checks, rollback and cleanup.

Trade-off explanation · 5%

One failure, one threat and one cost risk are stated and mapped to controls with a defensible reason.

Avoid these traps

Common mistakes

Designing only the happy path and never testing a failed zone, rejected flow or recovery mismatch.
Making every component public for convenience.
Using boolean checklists without validating network, recovery or risk relationships.
Claiming an RPO/RTO that backup/restore evidence does not meet.
Naming a threat or cost risk without mapping it to a concrete control.
Treating backups, monitoring, budgets, rollback and cleanup as post-launch tasks.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1Why validate tier CIDRs against the VPC?

To prove the network plan is internally consistent and to catch out-of-range or overlapping subnets before provisioning.

2Why should allowed flows be represented explicitly?

So reviewers and automation can distinguish intended communication such as lb→app:8080 from unsafe paths such as internet→db:5432.

3How do numeric RPO/RTO values become testable?

Compare recovery-point generation frequency against RPO and measured restoration time against RTO rather than recording the objectives as unsupported labels.

4Scenario: the manifest states RPO 15 minutes but backups are created every 60 minutes. Can the design pass?

No. The modeled recovery-point interval is worse than the stated 15-minute RPO, so the architecture evidence contradicts the requirement.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Core lab attemptedRecord this after meaningfully completing or attempting the module's core lab.Knowledge checks attemptedThis is marked automatically after you open every answer in the module; you can also record it manually.

Attempt the core lab and knowledge checks before marking the module complete.