Running containers on EC2 is not cloud-native. I’m sorry. Here’s what it actually means and the honest checklist to find out where your stack really stands.
I’ve sat through a lot of conference talks where companies describe their “cloud-native journey.” The term has been so thoroughly diluted by marketing that it’s become nearly meaningless. Let me offer something more useful: a checklist. Run your stack against it.
1 Are your applications designed for ephemeral infrastructure?
Cloud-native: your services expect instances to disappear without warning. No local state. No in-memory session that can’t be reconstructed. Graceful shutdown on SIGTERM in under 10 seconds.
Not cloud-native: your app assumes the server it started on will be there tomorrow.
2 Is your configuration externalized?
Cloud-native: configuration lives in environment variables or a secrets manager. The same image runs in dev, staging, and production.
Not cloud-native: you have environment-specific build artifacts. Config is baked into the container image.
3 Do you treat infrastructure as code — all of it?
Cloud-native: every piece of infrastructure is declared in version-controlled code. No manual console clicks in production. Drift detection is active.
Not cloud-native: your VPC was created in 2019 by someone who no longer works there, and nobody knows exactly what’s in it.
4 Is your CI/CD fully automated, including production?
Cloud-native: code merged to main → automated pipeline → production. No human approval required for routine deployments. Rollback is automated and tested.
Not cloud-native: you need a human to push the button for production. Deployments happen after a change board approval.
5 Are you building for failure?
Cloud-native: circuit breakers, retries with exponential backoff, bulkheads, and health checks are standard. Chaos engineering is part of your testing practice.
Not cloud-native: when a downstream service is slow, your service hangs indefinitely. You’ve never intentionally killed a production pod to test recovery.
6 Do you have observability, and not just monitoring?
Cloud-native: logs, metrics, and distributed traces are correlated. You can trace a single request across 12 microservices. You have SLOs and burn rate alerts.
Not cloud-native: you have CloudWatch dashboards showing CPU and memory. You find out about problems from customer support tickets.
7 Is security embedded, not bolted on?
Cloud-native: SAST, dependency scanning, and container image scanning run in CI. IAM follows least privilege. Secrets never appear in environment variables or logs.
Not cloud-native: the last pen test was 18 months ago. Credentials are in .env files committed to Git repos.
8 Are your teams organized for cloud-native delivery?
Cloud-native: stream-aligned teams own their services end to end. On-call is team-owned. Deployment frequency is daily or higher.
Not cloud-native: dev and ops are separate teams. There’s a change advisory board that reviews infrastructure changes weekly.
Your Honest Score
- 7–8: You’re legitimately cloud-native. The term applies.
- 5–6: You’re on the journey. Strong foundation, specific gaps to close.
- 3–4: You’ve migrated to the cloud. You haven’t migrated to cloud native.
- 0–2: You’re running legacy workloads on rented infrastructure. Nothing wrong with that just be honest about it.
The gap between “running in cloud” and “cloud-native” is where most enterprise engineering debt lives. Closing it isn’t about ideological purity, it’s about shipping faster, recovering faster, and spending less to do it.
