Cloud platform foundations

Cloud Platform Foundations

Overview

Cloud fluency is not knowing three consoles — it's deeply understanding the shared primitives: identity, network, compute, storage, and the managed services built on them. Learn one cloud well (AWS, Azure, or GCP); the concepts transfer, the shallow triple-certification doesn't.

Identity is the real perimeter. In the cloud, the firewall is not the wall — IAM is. Most catastrophic cloud incidents are identity failures (over-privileged roles, leaked keys), not network failures.

Everything through code. Cloud resources are provisioned with Terraform (see terraform-infrastructure-as-code). Console work is for exploration and emergencies — logged and reconciled.

Design to the floor. The simplest architecture that satisfies integrity, scalability, and security — at the lowest TCO — is the correct architecture. Every component beyond that (a second region, a service mesh, a managed service at 5× the self-managed price) must justify its complexity and its cost against the actual requirements, and that justification goes in an ADR. Cutting below the floor — skipping HA where it's required, dropping backups, loosening the security baseline to save money — is not thrift; it's risk accumulation. Price the design before building it (see cost-estimation-and-finops).

When to Use

• Designing a new environment or landing zone
• Reviewing IAM policies, roles, or service identities
• Designing network topology (VPC/VNet, subnets, routing, peering)
• Choosing between self-managed and managed services
• Reviewing cloud architecture for security or cost
• Planning multi-environment account/subscription structure

The Ten Primitives You Must Understand

For each primitive, you should be able to explain the AWS, Azure, and GCP equivalent of at least your primary cloud:

Primitive	AWS	Azure	GCP
Identity & permissions	IAM (roles, policies)	Entra ID + RBAC	IAM (members, roles)
Virtual network	VPC	VNet	VPC
Virtual machines	EC2	Virtual Machines	Compute Engine
Object storage	S3	Blob Storage	Cloud Storage
Load balancing	ALB/NLB	App Gateway / LB	Cloud Load Balancing
DNS	Route 53	Azure DNS	Cloud DNS
Managed database	RDS / Aurora	Azure SQL / Database for PostgreSQL	Cloud SQL
Managed Kubernetes	EKS	AKS	GKE
Monitoring	CloudWatch	Azure Monitor	Cloud Monitoring
Secret management	Secrets Manager	Key Vault	Secret Manager

Design Order (every new environment)

1. ACCOUNT STRUCTURE   → isolation boundary first
2. IDENTITY            → who/what can do anything at all
3. NETWORK             → where things live and what can reach them
4. COMPUTE + DATA      → the actual workloads
5. OBSERVABILITY       → logging/monitoring wired from day one
6. COST GUARDRAILS     → budgets and alerts before the first bill shock

Skipping to step 4 is how you get a production database in a default VPC with a public IP.

1. Account / Subscription / Project Structure

Environments are isolated at the account level, not by naming convention.

• Separate accounts (AWS), subscriptions (Azure), or projects (GCP) for production and non-production at minimum.
• Production never shares credentials, networks, or identities with development.
• Central logging/security account for audit trails that production workloads can't tamper with.
• Naming/tagging convention defined before resources exist: env, owner, cost-center, criticality, data-classification.

2. Identity (IAM) Rules

1. Humans authenticate via SSO/federation (IAM Identity Center, Entra ID, Cloud Identity) with MFA. No long-lived IAM users for people.
2. Workloads use roles/managed identities, never static access keys. EC2 instance profiles, managed identities, service accounts with workload identity.
3. CI/CD uses OIDC federation to assume short-lived roles (see ci-cd-pipeline-engineering). Zero stored cloud keys in CI secrets.
4. Least privilege as a process: start from the actions the workload actually calls (check the logs — AWS Access Advisor, CloudTrail; GCP Policy Analyzer), not from *:* trimmed later (it never gets trimmed).
5. Separate identities per service and per environment. One god-role shared by everything is unauditable and unrevocable.
6. Privilege escalation paths reviewed: who can iam:PassRole, who can attach policies, who can create keys.

# Pattern: narrowly-scoped role, assumable only by the specific workload
data "aws_iam_policy_document" "app" {
  statement {
    actions   = ["s3:GetObject"]
    resources = ["arn:aws:s3:::org-app-assets/protected/*"]
  }
}

3. Network Design Rules

VPC (e.g., 10.20.0.0/16)
├── Public subnets (one per AZ)     → load balancers, NAT only
├── Private subnets (one per AZ)    → compute, containers
└── Data subnets (one per AZ)       → databases, caches — no route to internet

1. Multi-AZ by default. Anything that matters spans at least two (preferably three) availability zones.
2. Databases are never publicly reachable. No public IPs, no 0.0.0.0/0 inbound, data subnets with no internet route.
3. Admin access via VPN, bastion, or Zero Trust brokered access — never SSH/RDP open to the internet. Prefer Session Manager (AWS) / Azure Bastion / IAP (GCP) over self-managed jump boxes.
4. Security groups / NSGs are least-privilege both ways. Default-deny inbound; outbound restricted where practical (especially data subnets).
5. East-west traffic is controlled too. Service-to-service rules, not one flat network where everything reaches everything.
6. DNS as code (Route 53 / Azure DNS / Cloud DNS via Terraform), with TTL strategy documented for migrations (see network-troubleshooting-and-dns).

4. Compute and Data Rules

• Managed over self-managed when the managed service fits: RDS over self-installed PostgreSQL, EKS over self-built k8s. You pay the provider to do patching, failover, and backups — undifferentiated heavy lifting.
• Understand what "managed" still leaves to you: backup configuration and restore testing, parameter tuning, major version upgrades, network placement. Managed ≠ operated-for-you.
• VMs come from golden images (Packer, see ansible-configuration-management), not from manual setup.
• Block storage and object storage encrypted at rest (default-on where available, enforced by policy).
• Object storage is private by default. Public buckets are the #1 self-inflicted cloud breach — enable account-level public access blocks.

5. Observability From Day One

• Cloud audit logs on and exported: CloudTrail / Azure Activity Log / Cloud Audit Logs → immutable storage in the security account, retention defined.
• Flow logs on for VPCs (network forensics you can't reconstruct later).
• Metrics and logs centralize to the monitoring stack (see observability-and-alerting).
• You cannot retrofit an audit trail. The logs from the day of the incident either exist or they don't.

6. Cost Guardrails

• Budgets with alerts per account/subscription from day one (50%, 80%, 100% thresholds).
• Tags enforced so cost is attributable (cost-center, env).
• Quotas known before you need them — quota increases take time.
• Review idle resources monthly (stopped-but-attached disks, orphaned IPs, old snapshots).

Choosing Your Primary Cloud

• AWS — broadest service catalog, most transferable patterns, deepest community. Default choice when there's no other signal.
• Azure — the right call in Microsoft-centric enterprises: Windows Server, Active Directory/Entra ID, Microsoft 365, .NET workloads, hybrid corporate agreements.
• GCP — strong data/analytics and Kubernetes lineage; often the cleanest UX.

Pick one for depth. Learn the other two's names for the same primitives (table above), not their consoles.

Common Rationalizations

Rationalization	Reality
"We're small, one account is fine"	One account means dev experiments share blast radius, credentials, and quotas with production. Account separation is cheap; the incident is not.
"This role needs : for now, we'll tighten later"	Later never comes, and the over-privileged role outlives its creator. Start narrow; expand on evidence from access logs.
"The database needs a public IP so I can connect"	You need a bastion, a VPN, or a brokered session — not a public database.
"Managed RDS is too expensive, we'll self-host"	Price the engineer-hours for patching, failover testing, backup verification, and 3 AM page response. Managed is usually cheaper.
"Audit logs cost money, enable them later"	The cost of not having them is paid during the incident: "we don't know what the attacker touched." Turn them on now, lifecycle the retention.
"Tags are bureaucracy"	Tags are how you answer "who owns this," "what does it cost," and "can I delete it" — the three questions every month-end brings.

Red Flags

• Root/account-owner credentials in daily use (or without MFA)
• IAM users with access keys for humans
• 0.0.0.0/0 inbound on anything but public load balancers
• Production databases with public IPs
• No audit logging, or audit logs writable by the accounts they audit
• Resources with no tags and no known owner
• Console-created production resources that exist in no Terraform state
• First budget alert configured after a surprise bill

Verification

• Production and non-production are isolated in separate accounts/subscriptions/projects
• Zero human IAM users with static keys; SSO + MFA for all humans
• All workload and CI identities are roles/managed identities with short-lived credentials
• IAM policies scoped to specific actions on specific resources (evidence-based from access logs)
• Databases and internal services have no public IPs and no 0.0.0.0/0 routes
• Admin access only via VPN/bastion/Zero Trust — no internet-facing SSH/RDP
• Audit logs enabled, exported to a security account, tamper-resistant
• Budgets and alerts configured; tagging convention enforced by policy
• Everything above exists as Terraform code in version control — console diffs are zero