You're containerising a PHP application for an auto parts retailer in Stuttgart and setting up basic infrastructure monitoring with CloudWatch.
The discipline skills: writing a Dockerfile with multi-stage builds, creating a .dockerignore to keep credentials out of the image, running containers as a non-root user, tagging images with specific versions instead of latest, pushing to ECR with image scanning and lifecycle policies, and reading CloudWatch metrics for CPU, network, and disk — then interpreting what those numbers actually mean for this workload.
The AI-direction lesson: AI generates containers that work. They boot, they serve traffic, they pass every functional test. But they run as root, they bundle development tools into the production image, and they ship without a .dockerignore — which means credential files can end up baked into the image layers. None of these problems produce errors. The application runs fine. You have to inspect the output yourself to catch them. The same pattern shows up with monitoring: AI will provision resources but won't add any visibility. And when you ask it to report metrics, it gives you numbers without telling you whether those numbers are normal for a web server handling 500 orders a day. You're learning to verify things that work but aren't right, and to interpret data that AI presents without context.
Your Role
You're the cloud engineer. Katrin has a deployment that broke checkout on one server but not the other — and nobody knew for four hours. You're addressing both problems: containers deliver the consistency side outright, and basic CloudWatch metrics deliver the foundation layer of visibility — enough to see whether the machine is running and how hard it's working. The visibility Katrin most wants — knowing the moment a checkout flow breaks — sits at a higher layer (alarms, application-level monitoring) that comes in later projects. You'll name that boundary for her honestly as part of the handover.
The scaffolding is the same as last time. You get a detailed brief, a CLAUDE.md, and clear requirements. The CLAUDE.md is provided complete this time — not a template you fill in — because the cognitive load is on two new tool domains, not project governance. You direct Claude Code through the container build, the ECR setup, and the CloudWatch configuration, reviewing every output before it goes live.
What's New
Last time you built a production VPC with an RDS database and Application Load Balancer, organised Terraform across multiple files, and analysed actual costs against AI's estimates.
Two new infrastructure concepts this time. Containers — self-contained packages that carry the application and its dependencies, so the same image runs identically on every machine. And metrics — the first form of visibility into whether your infrastructure is actually running and healthy, not just provisioned.
The hard part is that the security issues in containers are invisible. A Dockerfile that runs as root, includes build tools in the production image, and has no .dockerignore will produce a container that works perfectly. Nothing fails. Nothing warns you. You have to know what to look for and check it yourself.
Tools
- Claude Code — directing the container build, Terraform, and metric queries
- Terraform CLI —
init,fmt,validate,plan,apply,destroy - AWS CLI — resource verification and CloudWatch metric queries
- AWS Console — visual verification and CloudWatch metrics dashboard
- Docker — building, running, and inspecting container images (new)
- ECR — storing container images in the cloud (new)
- CloudWatch — basic infrastructure metrics: CPU, network, disk (new)
- Git and GitHub — version control
- VS Code + Terraform extension — code editor
Materials
In the project folder:
- Katrin's Slack message (
first-contact.md) — the deployment problem, the visibility problem, and what she needs. - Project brief (
project-brief.md) — the full requirements: containerise the PHP application, set up CloudWatch monitoring, scope boundaries. - CLAUDE.md — the project governance file, pre-authored and ready to use.
- The PHP application (
app/) — the webshop code you're containerising. PHP 8.2 with Apache.