Night Mode LabsBlue Book
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

CapabilityCommon AWS services
Accounts and landing zoneAWS Organizations, Control Tower
IdentityIAM Identity Center, IAM, STS, OIDC federation
NetworkingVPC, Transit Gateway, PrivateLink, Route 53
ContainersECS, Fargate, EKS, ECR
ServerlessLambda, EventBridge, Step Functions
DataRDS, DynamoDB, S3, Redshift, Glue
Secrets and keysSecrets Manager, Parameter Store, KMS
ObservabilityCloudWatch, X-Ray, Managed Prometheus, OpenSearch
SecurityGuardDuty, 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.

On this page