Container deployment runbooks for AWS teams

The moment this problem surfaces is when a developer joins a team, inherits an ECS or EKS setup nobody fully documented, and spends days reverse-engineering IAM trust policies and task definition JSON to understand why a deployment behaves unexpectedly — or breaks silently. It also surfaces when a new project starts and the team must rebuild all that configuration from scratch, again.

The gap persists because AWS's incentive is breadth, not guided setup. They document every individual service exhaustively, but the connective tissue — the specific sequence in which IAM roles, VPC settings, security groups, ECR repos, and cluster task definitions must relate to each other for a working deployment — is left to the user to discover. AWS Proton exists but targets platform engineers building internal abstractions, not individual developers trying to understand what they already have.

What's actually missing is a layer that reads a live AWS environment and produces a step-by-step, human-readable account of how the current setup works — what IAM role is assumed by which task, which security group allows traffic to which target group, what would break if you changed X. Users say debugging is hard because 'ECS doesn't provide direct access to the server where containers are hosted,' meaning when something fails, there's no clear trail from symptom to cause across these interconnected resources.

This is a business rather than a feature because the configuration drift and knowledge loss recur every time someone leaves the team, every time a new service is added, and every time an incident happens. The cost of not having it is a recurring tax: senior engineers spend hours in the AWS console tracing relationships that could be mapped automatically, and junior engineers can't act without escalating. AWS has no incentive to build this because confusion drives support contract sales and solution architect engagement.

What to build

Build a CLI and web dashboard that connects to an existing AWS account, reads ECS or EKS cluster configuration via read-only IAM access, and generates a human-readable runbook showing exactly how IAM roles, task definitions, target groups, and security groups relate — plus a diff view when any of those change.

Where to start

Start with teams that have just experienced a failed ECS deployment they couldn't diagnose — offer a free one-time 'audit report' of their cluster configuration that shows exactly what's misconfigured, using that as the proof of value that converts to a paid subscription.

The hard part

Getting read-only AWS access granted by security-conscious customers is politically difficult early on — many teams won't approve even read-only cross-account roles for an unknown vendor, so the sales cycle requires building trust before the product can prove its value.

How it makes money

Monthly subscription per AWS account connected, starting around $99/month, with a higher tier for multi-account organizations that need runbooks across environments (dev, staging, prod).