Account separation.

[nonken]

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

[nonken]

Looks like this will require some manual steps for now still. Watching: aws/aws-cdk#3401

[nonken]

Will also have to create accounts manually for now, or automate through sdk or even a Lambda. Watching: aws/aws-cdk#2877