Runtime Playbooks
Managed Containers Playbook
Managed container platforms run containerized services without requiring teams to operate Kubernetes. Examples include ECS with Fargate, Cloud Run, and Azure Container Apps.
Good fit
Managed containers are a good fit for:
- HTTP APIs and web services.
- Background workers and queue consumers.
- Scheduled or event-triggered container jobs.
- Teams that need containers but not cluster control.
- Systems where provider-native networking and IAM are acceptable.
Baseline architecture
Required defaults
Define platform standards for:
- Image build, scan, signing, and registry location.
- Service definition as code.
- CPU, memory, concurrency, and scaling limits.
- Health checks and deployment strategy.
- Workload identity and secret injection.
- Network placement and egress controls.
- Logging, metrics, traces, and alert routing.
ECS and Fargate notes
For ECS and Fargate:
- Separate task role from execution role.
- Keep task definitions generated or managed through IaC.
- Use service discovery or load balancers intentionally.
- Watch startup time, image pull size, and autoscaling signals.
- Use CodeDeploy or equivalent when blue-green matters.
Cloud Run and Azure Container Apps notes
For request-driven platforms:
- Set concurrency intentionally.
- Understand cold start behavior.
- Keep request timeout and background work expectations clear.
- Prefer queues or jobs for long-running work.
- Document public versus private ingress behavior.
Watchouts
- Console-managed service definitions drift quickly.
- Default scaling limits can surprise teams during incidents.
- Container platforms still need release, observability, and ownership standards.