Cloud Provider Notes
AWS Platform Notes
Use these notes to translate the blue book patterns into common AWS services. Prefer the client's existing AWS standards when they already exist and are working.
Common service mapping
| Capability | Common AWS services |
|---|---|
| Accounts and landing zone | AWS Organizations, Control Tower |
| Identity | IAM Identity Center, IAM, STS, OIDC federation |
| Networking | VPC, Transit Gateway, PrivateLink, Route 53 |
| Containers | ECS, Fargate, EKS, ECR |
| Serverless | Lambda, EventBridge, Step Functions |
| Data | RDS, DynamoDB, S3, Redshift, Glue |
| Secrets and keys | Secrets Manager, Parameter Store, KMS |
| Observability | CloudWatch, X-Ray, Managed Prometheus, OpenSearch |
| Security | GuardDuty, Security Hub, Inspector, Config, CloudTrail |
Baseline practices
- Use AWS Organizations with separate accounts for production, non-production, security, logging, and shared networking.
- Use IAM Identity Center for human access and OIDC federation for CI/CD.
- Keep CloudTrail, Config, GuardDuty, and security findings centralized.
- Prefer workload roles over static access keys.
- Use VPC endpoints or PrivateLink for sensitive managed-service access where practical.
- Define tagging, budget, and cost allocation standards early.
Runtime guidance
- Use ECS or Fargate for simple containerized services.
- Use EKS when Kubernetes-specific platform needs justify cluster operations.
- Use Lambda for event-driven and bursty workloads with clear timeout and retry behavior.
- Use Step Functions for explicit workflow orchestration when function chains become hard to reason about.
Watchouts
- IAM policies become unmaintainable without naming and ownership standards.
- Security groups, routes, and VPC endpoints can create invisible connectivity dependencies.
- Account sprawl needs lifecycle and ownership controls.
- Service quotas should be reviewed before large migrations or launches.