Clicking around the AWS console can get a demo up. It does not leave you with something another engineer can review, rebuild, or fix under pressure. Real cloud-native work puts the stack in code, keeps permissions tight enough that a mistake has a known blast radius, and makes failure visible enough that you can tell a timeout from an IAM miss from a bad deploy. That is the bar I work to.
What this actually means
On AWS, the infrastructure is the product surface: Lambda functions, API Gateway routes, queues, tables, and the IAM that decides what each of those is allowed to touch. If a role is wider than the job, a single mistake has nowhere clean to stop. Networking belongs in that same picture whenever traffic should not sit on the open internet by default: private subnets, security groups, and NAT or VPC endpoints so the path in and out is deliberate. The point is not collecting service logos. It is shipping a backend you can rebuild, review, and reason about when something fails.
Define it in code
Terraform and CDK are how the environment should exist: Lambdas, queues, tables, alarms, and the VPC and security groups when the job needs them. A second environment should come from the same definitions, not from memory of what someone clicked last month. Secrets stay out of the repository. Releases go through a pipeline rather than a zip uploaded by hand. Once the console and the stack disagree, you are guessing on a Friday night. If a change is not in code, it is not finished, because nobody else can review it, rebuild it, or trust what production actually is.
Observability has to answer a real question
When something fails, one pretty chart is not enough. CloudWatch holds the metrics and logs that tell you whether the system is slow or broken: latency, errors, throttles, cold starts, queue depth. CloudTrail answers a different question: who changed what. AccessDenied storms, role changes, and quiet API failures often show up there before a customer complains. Mean time to recover only improves if those signals let you separate a timeout from an IAM miss from a bad deploy without hunting through five tabs. Networking belongs in that diagnosis too when traffic moves through a VPC: a dead route can look like a broken Lambda until you check the path. Where Dynatrace is already in the estate, traces across services show which hop died instead of leaving you to guess. I would rather ship fewer widgets and one runbook that names the next step. A dashboard nobody trusts is worse than none.
Hand it over without a mystery tour
Infrastructure is finished when someone else can read the stack, tighten a role, and ship a release without asking which console tab to open. That means clear IaC, named alarms, and enough runbook detail that on-call is not tribal knowledge. When the network is part of the design, the VPC and security groups have to be readable in the same way. The day-to-day stack I work in is TypeScript on Lambda with API Gateway, DynamoDB, SQS, and GitHub Actions for release. I do this from Manchester, usually remotely, and I treat handover as part of the build rather than a document written after the fact.
