| name | cloud-infrastructure |
| description | Designs and runs cloud infrastructure — environments, infrastructure as code, networking and isolation, scaling, and cost. Use this to design a cloud environment, control infrastructure spend, set up environment separation, plan for scale or region failure, or review infrastructure someone configured by hand. |
Cloud infrastructure
Cloud replaces capital cost with an operating cost that scales with carelessness. The discipline is
mostly about making the environment reproducible and the spend visible.
Everything reproducible from code
Infrastructure created by hand cannot be reviewed, reproduced, or recovered. Define it as code,
review it like code, and apply it through a pipeline rather than from a laptop.
The test: could you rebuild the environment from an empty account, and do you know that because you
have done it? Untested reproducibility is a belief.
Console access for humans should be read-only in production by default. Write access exists for
emergencies, is time-bound, and is logged — see security:access-and-identity for the policy this
implements.
Environments that mean something
Separate environments by blast radius, not by name. Separate accounts or subscriptions give a hard
boundary; separate namespaces in one account give a soft one that a misconfigured permission
crosses.
Production data does not belong in lower environments. Where realistic data is needed, mask or
synthesize it — a copied production database is a breach waiting for a misconfigured bucket, and it
is one of the most common ways personal data escapes.
Networking and isolation
Default deny, then open what is needed. Public exposure should be a deliberate, reviewable act rather
than the residue of a default.
Keep the trust boundary explicit and few: what is reachable from the internet, what is reachable
between services, what reaches data stores. Most cloud incidents are not exotic — they are a storage
bucket, a database, or a management interface that was reachable and should not have been.
Scaling and failure
Scale horizontally where you can and know your actual limits — the database connection ceiling, the
third-party rate limit, the single-threaded component nobody remembers. Autoscaling in front of a
hard downstream limit converts a slow system into an outage.
Design for the failure of a single instance and a single zone as routine. Region failure is a
business continuity decision with a real price attached, made with
operations:business-continuity-and-resilience rather than assumed by engineering.
Cost
Cost is an architectural property. Attribute spend by team and workload from the start; without
tagging, cost becomes an unattributable aggregate that only ever gets addressed in a panic.
The usual large wins are unglamorous: idle non-production resources, over-provisioned instances,
storage nobody deleted, and cross-zone data transfer nobody accounted for.
Tooling
Platforms: AWS, Google Cloud, Microsoft Azure, and similar; managed application platforms —
Fly.io, Render, Vercel, Railway — remove most of this work and are the right answer more often than
engineering pride admits.
Orchestration where you need it: Kubernetes with a managed control plane, or a container service
like ECS. Kubernetes is a platform team's worth of work; adopt it when you have the team.
Infrastructure as code and secrets: Terraform, OpenTofu, Pulumi, and similar, with secrets in a
managed store rather than in the state file. it-operations:cloud-administration covers the
corporate cloud estate, which is a different problem with overlapping tools.
Never
- Make a production change by hand that is not reflected in code.
- Put production data in a lower environment unmasked.
- Autoscale a tier in front of a hard downstream limit.
- Run without cost attribution until the bill forces it.
