Cloud Architecture Guide
DAY_01 / SECTION_03 // FOUNDATION
MODULE READY

Security as a foundation

You can't bolt security on later — it has to be designed in from the start. The order matters: identity (who can do what?) → network (where can traffic flow?) → audit (what happened?). It's also the order of attack.

SYS.NODE_01
ONLINE
badge

Identity

Who can do what
Least-privilege admin model · federated SSO over local accounts · roles for service access (not long-lived keys) · just-in-time elevation for sensitive ops.
// principle
default = DENY
SYS.NODE_02
IDLE
lan

Network

Where traffic flows
VPC isolation per environment · private subnets for backends · security groups as fine-grained firewalls · egress control — what can leave?
// scope
vpc/subnet/sg
SYS.NODE_03
STANDBY
receipt_long

Audit

What happened
Centralized logs in immutable storage · alerting on suspicious patterns · regular access reviews · the source of truth when something goes wrong.
// retention
≥ 1 year, write-once
// virtual private cloud — the building block

A logical isolation of your cloud network. Same idea across providers — different names: AWS VPC · Azure VNet · GCP VPC.

inside a vpc
  • Subnets · public (internet-facing) or private
  • Route tables · where traffic goes
  • Security groups · instance-level firewalls
  • NACLs · subnet-level firewalls
  • Internet & NAT gateways · controlled egress
across vpcs
  • Peering · VPC ↔ VPC (1:1)
  • Transit gateway / hub · many ↔ many
  • VPN / Direct Connect · VPC ↔ on-prem
// identity & least privilege

The single biggest source of cloud breaches: over-permissioned credentials. The 2012-era Netflix four-account model still holds:

  • paastest — dev / testing, developer-tagged stacks for separation
  • paasprod — production, autoscale only, alert routing + backups by default
  • paasaudit — sensitive workloads (SOX, PCI), extra access controls
  • paasarchive — disaster recovery, long-term backups, ideally different region or vendor
help Knowledge Check
Question 1/1

A teammate suggests storing the AWS access key for the production deploy script in a shared vault, rotated quarterly. What's the better pattern?

// pick one to verify