The modern AWS foundation, in the right order

Every few weeks I get a version of the same question: "We're on AWS, things mostly work — where do we start fixing it?" People expect me to say Terraform. I usually say monitoring.

That surprises founders, because infrastructure as code is the fashionable answer, and it's where a consultancy's billable work naturally starts. But in this work — early startups, large regulated data platforms, most things in between — the order that actually holds up is: monitoring, then IaC, then CI/CD, then automation. Skip a step and everything after it gets built on guesses.

Monitoring first, because it takes the longest to mature

Good observability isn't a tool you install. It's a habit your team grows: dashboards nobody opens get deleted, alerts get tuned until on-call stops resenting their phone, and slowly the team learns what normal looks like for this system. That process takes a year or more, and there's no shortcut — which is exactly why it has to start on day one. Everything you build later gets judged against the baseline you start recording now.

The practical version: pick Datadog or CloudWatch — either is fine, the attention matters more than the vendor — instrument the application and not just the boxes, and make one person own alert quality. An alert that isn't actionable gets deleted, not snoozed.

Then infrastructure as code — DRY, or don't bother

I've inherited accounts where the same security group existed nine times under nine names, each one hand-tweaked at some point in its life. IaC that's copy-pasted per environment isn't much better than clicking — it just moves the drift into git.

The bar worth clearing: reusable modules, blueprints for whole service shapes, and as few hardcoded variables as you can get away with. When a pattern needs to change, you change it once and watch every environment inherit the fix. That single property is what makes the next layer possible.

Then CI/CD — shared workflows, not per-repo snowflakes

Same principle, one level up. A frontend deploys one way. An ECS service deploys one way. A Lambda backend deploys one way. Three reusable workflows, and every new repo starts life on a paved road. Fix a pipeline bug and you've fixed it for every service at once. I've watched a team go from dreading Friday deploys to genuinely not noticing them, and the shared workflows were most of that story.

Then automation — and only now the AI

Once you have signals, declarative infrastructure, and one repeatable path to production, automation stops being frightening. Self-healing first: autoscaling, rollback paths, guardrails that correct problems before they page anyone. Then the agentic layer — docs that update themselves on every merge, code-review agents, Claude skills that let your developers ship their own IaC and pipeline changes inside the guardrails.

AI is the layer everyone wants to start with, and it's the one that most needs the other three underneath it. An agent grounded in clean IaC and a real pipeline is leverage. The same agent pointed at nine hand-edited security groups is a liability with API access.

The honest caveat

If production is on fire, put the fire out — this order is for building, not triage. And a two-person startup doesn't need all four layers this quarter. But whichever layer you add next, add it in this order. Most of the teams I've watched compound their speed built it in that order.