Account separation. #1
Description
Initially this topic got bubbled up because staging should talk to a different DynamoDB than production. The only way to work around this is to use 1. dynamic table names, 2. use different regions or 3. different accounts. 1. and 2. are terrible solutions. Different accounts is the pragmatic but somewhat more tricky solution as it likely will be hard to fully automate this.
Considerations
Cost: This template should allow you to bootstrap a cost efficient service. This means that for example deploying a load balancer per service is not the right choice. At scale you might want to reconsider this.
Operatability: Dealing with different accounts can be a pain. At lease the operational metrics and pipelines should be created in the same account so that an operator doesn't have to navigate accounts.
Account A:
- VPC
- Route53
- CloudFront
- ApplicationLoadbalancer
- NAT Gateway (Run own NAT gateway to reduce cost (https://hackernoon.com/dealing-with-an-aws-billing-surprise-beware-the-defaults-d8a95f6635a2)
Account B:
- Pipelines for all services including CodeDeploy, CodeBuild, etc.
- All Cloudwatch events of all services (cross-account, see https://aws.amazon.com/blogs/aws/new-cross-account-delivery-of-cloudwatch-events/)
Account C (api-staging):
- API,
- Dependencies like DynamoDB
- Autoscaling
Account D (api):
- API,
- Dependencies like DynamoDB
- Autoscaling
Account E (www-staging):
- WEB,
- Dependencies like Redis
- Autoscaling
Account F (www):
- WEB,
- Dependencies like Redis
- Autoscaling
Account G (static-staging):
- STATIC
- Dependencies like S3
Account H (static):
- STATIC
- Dependencies like S3