copilot-cli icon indicating copy to clipboard operation
copilot-cli copied to clipboard

Copilot and central management account

Open Fodoj opened this issue 3 years ago • 2 comments

At the moment, documentation does not specify best practice account structure. While there is plenty information about Environments, it does not say whether the account that holds Copilot's central infrastructure (SSM params, ECR repos, S3 bucket) should be in prod environment, SDLC environment, or a dedicated central account (!= root aws account).

So far I see 3 options, each valid depending on complexity and size of the infra:

1 AWS Account for everything

Dedicated account for Copilot Application, this account hosts all environments, plus central infrastructure of Copilot. Naturally, this account is separate from AWS root account, following AWS best practices (in each case I assume existence of AWS Organisation, with AWS SSO, centralised billing etc etc. This would probably work for some smaller, none-critical setups.

2 AWS accounts, one for preprod/SDLC, one for prod

In this case, Prod account runs production (== prod Copilot environment), and everything else is in another "SDLC" account. Roughly follows Prod/SDLC split described in this blog post: https://aws.amazon.com/de/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/ (though that one speaks about OUs, not accounts)

I think this approach is ok for many small to mid size cases, though I think it's still not ideal from isolation and security perspective. My main problem with this setup is that critical prod-level infra would be inside SDLC account, that is - ECR repos, IAM policies to access production and so on.

3 AWS Accounts: copilot-mgmt account, preprod and prod

In this setup, we have a central account that holds central copilot infrastructure, DNS, ECR repos. Preprod account is only used to run preprod workloads, Prod is for prod. Central account is then also as critical as prod, but used for management purposes, not for running workloads.

Naturally, in 3rd case it's rather 3+ accounts, as there could be more copilot environments (for qa, for dev etc, all connected to central copilot account).

There is a certain path to start with 1 account and slowly move over time to the setup with 3+ accounts, though it's easier to start from multiple accounts from the Day 1. I would specify in docs that the last option is the best practice.

Does it makes sense? :-)

Fodoj avatar Jul 17 '22 07:07 Fodoj

I want to propose 4th option. I used to use 2nd option and thought 3rd one but I didn't want to have any cross-account relation, so I tried this way.

  • dev aws account
    • app: example-app env: dev
  • prod aws account
    • app: example-app env: prod

The point is, I did copilot app inittwice, with each aws accounts' credential. The apps named example-app exist separately in each account, ECR repositories exist separately, Copilot infrastructures exist separately, and so on. ( It's working good so far but at the same time I feel this is not going the rail of aws copilot

dharada1 avatar Aug 17 '22 17:08 dharada1

Hey @Fodoj and @dharada1! I think this is a great idea - even just having some documentation around pros/cons of the setups you mentioned would be nice to help people decide how to structure their accounts. Thanks for the idea and your solutions!

dannyrandall avatar Aug 22 '22 16:08 dannyrandall