Is it best practise to create seperate cloud account for different systems on AWS?

Hello.

Are there any cost differences between seperating cloud accounts of different applications and combing cloud accounts of different applications?

Basically, when you use AWS, you only pay for what you use.
So I don't think the total amount will change whether the AWS accounts are separated or not.
If you are purchasing Savings Plans and want to apply discounts to a specific AWS account preferentially, it may be a good idea to use the same AWS account.
https://repost.aws/knowledge-center/savings-plans-consolidated-billing

Separating AWS accounts may be better than using the same account in terms of permission management, etc.
Separating AWS accounts limits the scope of operations.
This makes it possible to narrow the range of influence even if an incorrect operation is performed.
https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/aws-account-management-and-separation.html

Hi,

Separating concerns with different accounts is a very big trend for large customers. At the same time, you want to keep things coherent and under controls. That's what is AWS Organizations is here for: have multiple accounts to better isolate applications but keep things efficient via proper mechanisms.

To get all this, I recommend (strongly) reading this whitepaper end-to-end: https://docs.aws.amazon.com/pdfs/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.pdf

On the cost efficiency, Riku's answer points to interesting docs to save while having multiple accounts.

Best,

Didier

I agree with the above answers. For large organizations that have many different projects that are owned by separate teams, then AWS Organizations with Control Tower is a smart choice. You can get that fine level of control needed for such use cases. For example, creating sandbox account for team A and a locked down secure account for production in team B https://aws.amazon.com/controltower/

That being said, I have seen a couple of issues with the above for smaller teams & orgs

1. It can be cumbersome to manage.
2. It can increase costs for reused services

MANY APPS MANAGED BY 1 TEAM.

[1 orgunit appdev & then dev, test, prod environment accounts + content account for repos, domains & container images]

I've seen orgs set up an sandbox, dev, staging, prod account for each application that they own when the applications are interconnected. If the majority of the applications are owned by the same group & connected, then you may just want an "appdev" org with the desired sandbox,staging,prod accounts. This way, you can reuse some managed services (like RDS & cache) without getting double charged for services. It also helps simplify networking.

**STARTUPS & PROOF of CONCEPTS **

[dev, stage, prod in same account]

Caveat: If working with private data like health or finance, then not recommended. Sometimes, it is smart for a startup to use the same account for dev, test, prod to help increase speed & reduce cost burden. I would recommend keeping clear separations of concerns in this case. For example, separate S3 buckets for the different environments so that you can move to a more robust org strategy.

SENSITIVE ORG OR PERSONAL DATA

[appdev accounts + separate data (s3, logging, etc) accounts]

It is generally recommended to keep private & sensitive data in separate accounts than the application content. For example, customer S3 data can be stored in separate aws accounts.

As you can see, there isn't a single universal account strategy. It can be easy to go down the trail of each "thing" needs to be its own organization with separate accounts, but this can lead to unneeded complexity and cost. Really, think of the organizations of who needs to manage & accounts as what needs to be done. This will make simplifying account strategy easier.