0

In our team, we are using AWS as our main cloud provider and currently, we have 3 projects hosted on their platform.

We are about to have 2 more projects in the next weeks, but first, we want to organize our projects, because our current organization is a little bit disordered.

We want our projects to be organized following these rules:

  • Each project must have a staging and production environment.
  • Each project is independent of each other so that it is not possible to see the resources of a project from within another project, i.e., VPC and S3 Buckets.
  • The client is responsible for paying the bills of the project (staging and production environment).
  • Even though the client is responsible for paying the bills, we must have access to the environments to deploy our code and to do other tasks related to development, testing, and operations.
  • We can assign a team of developers to each project. It should be possible for a developer to be in one or more projects at the same time. Plus, it should be possible to move our developers between projects and to remove their access from a project.

So, is it possible to organize projects in AWS under the rules previously mentioned?

Improve this question
2

1 Answer 1

Reset to default
1

Your primary options for logical organization are:

  • Everything one one account / one VPC with separation by tagging or subnets (not ideal)
  • One account / one VPC per application per environment (better)
  • One account for each application per environment (IMHO best for larger organizations, but has some overhead for smaller organizations)

The primary considerations are:

  • Ease of enabling or preventing access, particularly if your accounts are federated with AD. It's handy to just add someone to an AD group to give them access, and remove them to revoke it, they just assume a role with the policy you want them to have
  • Isolation between workloads
  • Reducing blast radius
  • Avoiding AWS API limits, which are per-account
  • Cost allocation, which is ok with tags but easier with accounts (other than bandwidth if you use a central communications account or backhaul to on-premise)
  • Monitoring
  • Complexity - more accounts can be more difficult to manage, but the application isolation also helps reduce complexity
  • Compliance - PCI compliance may be easier with separate accounts as you can more easily demonstrate isolation

AWS Control Tower is AWS best practice in this area as of 2022, you should read up on it. It uses AWS Organizations, which are really useful to do consolidated billing and to use service control policies. Transit Gateway is useful if you need to set up communications between the accounts. You can't just run turn on Control Tower and call that good enough, you still need to work on your networking, security, and user management, but it's a good start.

Legacy AWS Landing Zone which this answer recommended in 2019 is now legacy and is marked "will not get updates".

I've spent a lot of time considering this, this is just a brief answer. If you need more information please comment and I'll do my best to expand my answer.

Improve this answer
2
  • Please, I would like to know more.
    – GianMS
    May 31, 2019 at 13:33
  • I've spent a lot of time working on just account structures for enterprises, plus more on compliance, networking, security, etc. There is more to know than what I've written but this is a good start.. Firstly though you'll need to be more specific about what you want to know, and secondly you need to do some reading on multi account architectures yourself so you know what questions to ask. There are some useful articles you can find on Google.
    – Tim
    May 31, 2019 at 19:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .