Infrastructure Cheat Sheet
Need X → use Y, with the reason and the price. Every row carries a cost column on purpose: this domain does not recommend anything without saying what it costs you to run.
Compute
| Need | Use | Why | Cost |
|---|---|---|---|
| Long-running service, ordinary OS needs | Managed containers, or plain VMs behind a load balancer | Least machinery that still gives you replacement and rollout | You own the image and the deploy path |
| Short, event-driven, bursty work | Serverless functions | Scales to zero and per-use billing suits spiky work | Cold starts, runtime limits, and a connection problem against a pooled database |
| Custom kernel, custom drivers, strong isolation | Virtual machines | Containers share the host kernel; a VM does not | You own patching, images and the lifecycle |
| Many containers across many machines | Consider orchestration — then check whether a managed platform suffices | Placement, restarts, rollout and discovery stop being manual | A control plane is a distributed system you now operate |
| Two engineers, one API, modest traffic | Not Kubernetes | The cluster costs more attention than the workload does | You may outgrow it — migrating later is a known, bounded project |
Networking
| Need | Use | Why | Cost |
|---|---|---|---|
| Backend must call an external API but accept nothing inbound | Private subnet plus a NAT gateway | Outbound-only by construction: no inbound entry to translate | Per-gigabyte processing charges and a per-zone resource to make redundant |
| Reading a lot from provider object storage | A private endpoint, not the NAT path | Keeps the traffic off the metered gateway and out of the public path | One more network construct to declare and understand |
| Database must never be reachable from the internet | Private subnet, no public address, security group scoped to the app | Removes the entire class of direct external attacks | Not a substitute for authentication and authorization |
| Global static and media delivery | CDN in front of object storage | Serves from the edge and shields the origin | Cache invalidation becomes your problem; egress still bills |
| Route by health, geography or latency | DNS-level routing with health checks | Failover and locality without touching the application | DNS caching makes failover slower than the TTL suggests |
Storage
| Need | Use | Why | Cost |
|---|---|---|---|
| Images, video, backups, documents, static files | Object storage | Cheap, effectively unbounded, built for whole-object access | No transactions, no joins, per-request cost, listing is not a query |
| Large user uploads | Signed direct upload to object storage | The bytes never traverse your application | Signed-URL scope and expiry become part of your security model |
| A disk for a VM or a database | Block storage | The only shape that gives you a filesystem and durable random writes | Attached to one machine; you own snapshots and growth |
| Several machines sharing one filesystem | File storage | POSIX semantics across hosts without inventing your own sync | Per-operation latency, and a tempting anti-pattern as a queue |
| Relational data with real queries | Managed database | Backups, patching, replication and failover stop being your weekend | Schema, queries, indexes, access control, capacity and cost stay yours |
| Old data nobody reads but nobody may delete | Storage lifecycle policy into an archive tier | Storage cost falls by an order of magnitude | Retrieval from archive is slow and costs money |
Identity
| Need | Use | Why | Cost |
|---|---|---|---|
| An application needs cloud permissions | A workload identity assuming a role for short-lived credentials | Nothing long-lived to leak, and the audit log names the workload | A role, a trust policy and a credential refresh path to get right |
| A worker only reads one bucket | A policy granting exactly those read actions on exactly that resource | Blast radius on compromise is one bucket, read-only | Narrow policies break when the workload changes; that is the point |
| A database password an application needs | A secret manager, fetched at runtime by workload identity | Rotation, revocation and an audit trail become possible | A runtime dependency on the secret store, and a cache to design |
| Kubernetes Secret objects feel like secret management | Treat them as configuration until you have added encryption and access control | By default they are encoded, not encrypted, and broadly readable | A real secret store is another component to run |
Delivery
| Need | Use | Why | Cost |
|---|---|---|---|
| The same build must reach staging and production | Build one artifact, promote it unchanged | Staging tested exactly what production runs | Configuration must live outside the artifact |
| Deploy without an outage window | Rolling deployment | Capacity stays up while instances are replaced | Both versions run at once, so every change must be backward compatible |
| Rollback must be instant | Blue/green | Rollback is a traffic switch, not a redeploy | Double capacity during the switch, and the database does not switch with it |
| A risky release with real users | Canary with metric gates | A bad release reaches a small share before you stop it | Only works if the metrics are good enough to decide on |
| Deploys drop in-flight requests | Graceful shutdown on the termination signal | Stop accepting, drain, close, exit — in that order | A termination grace period long enough for your slowest request |
| Infrastructure changes should be reviewable | Infrastructure as code with remote, locked state | Changes become diffs a colleague can read before they happen | State is sensitive and concurrent applies must be prevented |
Reliability
| Need | Use | Why | Cost |
|---|---|---|---|
| One instance failing must not be an outage | Several instances across zones behind a load balancer | Health checks remove the failed one and traffic reroutes | Cross-zone data transfer and more capacity than one instance |
| Three replicas that all die together | Check the failure domain, not the replica count | Three replicas in one zone is one failure domain in disguise | Spreading them costs latency and cross-zone transfer |
| A zone outage must be survivable | Multi-zone, including the NAT and the database | The zone-redundant app is useless behind a single-zone egress path | One NAT and one database standby per zone, billed per zone |
| A region outage must be survivable | Multi-region — after you have answered the data question | Regional failure stops being an extinction event | Consistency, routing, operational complexity and a much larger bill |
| "How much data can we lose, how long can we be down?" | Write down RPO and RTO first, then derive the architecture | The numbers pick the design; the design cannot pick the numbers | Tighter numbers cost more, continuously |
| You have backups | Restore one, on a schedule, and time it | A backup you have never restored is not proven recovery | A recurring drill somebody has to actually run |
| Health checks cause outages during deploys | Separate liveness from readiness | Readiness removes traffic; liveness restarts the process | Two probes to reason about instead of one |
Scaling
| Need | Use | Why | Cost |
|---|---|---|---|
| Traffic varies through the day | Metric-based autoscaling on the signal that represents pressure | Capacity follows demand instead of the worst hour | New capacity is always minutes late; size the headroom for that |
| CPU is at 30% and the service is saturated | Scale on concurrency, queue depth or pool saturation instead | CPU is the default signal and frequently the wrong one | A custom metric to publish and trust |
| Scaling reacts too late | Cut startup time and raise the headroom | Metric window plus provisioning plus image pull plus warm-up is minutes | Headroom is capacity you pay for and do not use |
Security
| Need | Use | Why | Cost |
|---|---|---|---|
| Is this public endpoint a problem? | Ask what it serves and who it is for before calling it a finding | A load balancer on 443 is the design; a database on 5432 is not | Context takes judgement; a scanner alone will cry wolf |
| Who changed production infrastructure? | Audit logs plus per-workload identities | The log is only meaningful if identities are not shared | Log retention and someone whose job is to read them |
Production pulls a moving :latest tag | Pin an image digest | Two deploys of "the same" version can otherwise run different code | A promotion step that resolves and records the digest |
Cost
| Need | Use | Why | Cost |
|---|---|---|---|
| The bill tripled and compute did not change | Look at data movement before compute | Egress, cross-region transfer and NAT processing are the usual answer | Attribution needs tagging you have to maintain |
| 32 GB allocated, 4 GB used | Right-size — but check peaks and failover first | Average utilization alone will size you into an outage | Less headroom for the traffic spike you have not seen yet |
| Idle capacity looks like waste | Separate headroom from waste before cutting | Some idle capacity is the reliability budget | Cutting to zero headroom fails at the next spike |
| Nobody knows what each service costs | Tag resources and attribute spend per service | Cost becomes a design input instead of a monthly surprise | A tagging discipline that decays without enforcement |
Strategy
| Need | Use | Why | Cost |
|---|---|---|---|
| "We should be multi-cloud to avoid lock-in" | Name the business requirement first | Without one, you buy every provider's complexity and none of their depth | If the requirement is real, budget for duplicated IAM, networking and expertise |
| Moving an existing estate to the cloud | Inventory and dependency map before choosing a strategy | Migrations fail on the undocumented job nobody owns | The inventory is slow, unglamorous work |
| The architecture feels too complicated | Score the operational complexity and ask what can be removed | Complexity must be justified by workload and organization | Removing something means admitting you did not need it |