Tags: aws, 12-factor, cloud-native, microservices, ecs, serverless
Level: intermediate
TL;DR: Mapping the 12-Factor App methodology to AWS services to build stateless, scalable, and robust cloud-native applications.
1. Codebase & 2. Dependencies: One Git repository (CodeCommit/GitHub) per app; package dependencies explicitly using ECR (Docker) or CodeArtifact.
3. Config: Store configuration in environment variables, never in code. Use AWS Systems Manager Parameter Store or AWS Secrets Manager.
4. Backing Services: Treat databases (RDS, DynamoDB) and caches (ElastiCache) as attached, interchangeable resources.
5. Build, release, run: Strictly separate stages using AWS CodePipeline, CodeBuild, and CodeDeploy.
6. Processes: Execute the app as stateless, share-nothing processes using AWS Fargate or AWS Lambda.
7. Port binding: Export services by binding to a port, routed via Application Load Balancer (ALB) or API Gateway.
8. Concurrency: Scale out horizontally via process cloning using Application Auto Scaling for ECS or native Lambda concurrency.
9. Disposability: Maximize robustness with fast startup and graceful shutdown. Use ECS tasks that handle SIGTERM correctly.
10. Dev/prod parity: Keep environments identical using Infrastructure as Code (AWS CDK, Terraform, CloudFormation).
11. Logs & 12. Admin tasks: Stream logs directly to Amazon CloudWatch; run admin tasks as one-off ECS tasks or via AWS Systems Manager.
Q: How do you handle 12-Factor configuration (Factor 3) in an AWS environment?R: I retrieve plain text values from Parameter Store and sensitive data from Secrets Manager, injecting them into ECS containers or Lambda functions as environment variables at runtime.
Q: How do AWS serverless computing options align with the "Processes" and "Disposability" factors?R: Services like Lambda and Fargate inherently enforce statelessness and handle rapid provisioning and teardown, perfectly matching the requirement for disposable, share-nothing processes.
Hardcoding configuration or AWS credentials in the source code instead of using IAM roles and Secrets Manager.
Storing session state on the local disk or in memory instead of externalizing it to a backing service like ElastiCache (Redis).
Failing to implement graceful shutdown handlers in containers, leading to interrupted connections during ECS scaling events or deployments.
// Example: Injecting AWS Secrets Manager values into an ECS Task Definition (Factor 3)
{
"containerDefinitions": [
{
"name": "app-container",
"image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:latest",
"secrets": [
{
"name": "DATABASE_URL",
"valueFrom": "arn:aws:secretsmanager:us-east-1:123456789012:secret:db-url-secret"
}
]
}
]
}