3 ms·

Having one account per database/backend/frontend is not only overkill, but actually a bad practice. You're going to have to expose your DB to the internet inste

Having one account per database/backend/frontend is not only overkill, but actually a bad practice. You're going to have to expose your DB to the internet instead of having everything inside a single VPC. What you should do instead is have one account per environment (as you said).

kroolik 2y ago
You can peer-connect vpcs cross-account
- dilyevsky 2y ago
  Up to 125 peers before you have to setup a transit vpc which is a lot more complex
  - Hikikomori 2y ago
    Transit gateway can have 5000 VPCs connected in a region, and you have multiple TGWs. And rather than have a VPC per account you can use Shared VPCs instead.
tenplusfive 2y ago
I've recently stumbled upon the possibility to share a VPC and use one VPC with multiple accounts: https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/amazon-vpc-sharing.html https://docs.aws.amazon.com/whitepapers/latest/building-scal... I'm honestly not sure if thats a great idea, but this might be a possible way to do one account per DB/backend/frontend in a somewhat sane way.
- LilBytes 2y ago
  It's fine, but you're going to attract a lot of network costs bridging data between AWS accounts. Generally I'd stick to accounts per environment, you'll be worrying about a lot more when you get to FAANG scale.
  - visualphoenix 2y ago
    Sharing a VPC between accounts with AWS RAM incurs no network costs between the accounts and greatly simplifies AWS networking. Additionally you can share and re-use security groups from the shared vpc across account boundaries.
    - LilBytes 2y ago
      Hey thank you! I didn't know that, I was still stuck in the thoughts of using Transit Gateways between accounts which of course attracts $$$.
- lijok 2y ago
  It's a great idea if you know how manage it. This is current recommended practice for corporate. Single Network account that interconnects everything and dishes out subnets to other accounts for use exclusively by them.
- shakiXBT 2y ago
  oh, that's cool, I didn't know that was possible. That said, I still think it's overkill and doesn't bring any real benefit? Sure you're reducing the blast radius of a security breach, but are the overcomplications worth it? Also, you now have to manage multiple accounts with multiple policies and users / roles, won't that extra complexity actually increase the attack surface?
- thedougd 2y ago
  I do this. Technically you share the subnets. It's a fantastic pattern and enables greater autonomy for application teams. They're given an AWS account per app environment (e.g. WidgetApp Test, WidgetApp Prod, etc) and are able to build their stuff and attach it to existing subnets without a care about 'how' it communicates with the Internet or the greater organization.
Hikikomori 2y ago
You'll find that a plan like this is not overkill once you outgrow single accounts. Though I would do one account per system with Shared VPCs instead.
chippiewill 2y ago
We use peered VPCs at work. We have a central account per environment that has the VPC that's shared to all the other accounts in that environment for databases etc. To be honest, I'd probably prefer a single account per environment. But managing the IAM for that would be much more work.
cyberax 2y ago
> Having one account per database/backend/frontend is not only overkill, but actually a bad practice. That's how AWS works internally. A team can easily have several hundred accounts: one for each region, and for each env. You absolutely need tools to manage them, and AWS is not great in this regard. IAM Identity Center is a good first step, but its usability sucks compared to the AWS internal tool (called "Isengard"). > You're going to have to expose your DB to the internet instead of having everything inside a single VPC. There are several ways to NOT do this. The easiest one is to use IPv6 with your own block (you can get it from ARIN for around $100). Then split it into "public" and "private" subnets, and install a network ACL prohibiting external connections into the private subnet.

kroolik 2y ago

You can peer-connect vpcs cross-account

dilyevsky 2y ago
Up to 125 peers before you have to setup a transit vpc which is a lot more complex
- Hikikomori 2y ago
  Transit gateway can have 5000 VPCs connected in a region, and you have multiple TGWs. And rather than have a VPC per account you can use Shared VPCs instead.

tenplusfive 2y ago

I've recently stumbled upon the possibility to share a VPC and use one VPC with multiple accounts: https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/amazon-vpc-sharing.html https://docs.aws.amazon.com/whitepapers/latest/building-scal... I'm honestly not sure if thats a great idea, but this might be a possible way to do one account per DB/backend/frontend in a somewhat sane way.

LilBytes 2y ago
It's fine, but you're going to attract a lot of network costs bridging data between AWS accounts. Generally I'd stick to accounts per environment, you'll be worrying about a lot more when you get to FAANG scale.
- visualphoenix 2y ago
  Sharing a VPC between accounts with AWS RAM incurs no network costs between the accounts and greatly simplifies AWS networking. Additionally you can share and re-use security groups from the shared vpc across account boundaries.
  - LilBytes 2y ago
    Hey thank you! I didn't know that, I was still stuck in the thoughts of using Transit Gateways between accounts which of course attracts $$$.
lijok 2y ago
It's a great idea if you know how manage it. This is current recommended practice for corporate. Single Network account that interconnects everything and dishes out subnets to other accounts for use exclusively by them.
shakiXBT 2y ago
oh, that's cool, I didn't know that was possible. That said, I still think it's overkill and doesn't bring any real benefit? Sure you're reducing the blast radius of a security breach, but are the overcomplications worth it? Also, you now have to manage multiple accounts with multiple policies and users / roles, won't that extra complexity actually increase the attack surface?
thedougd 2y ago
I do this. Technically you share the subnets. It's a fantastic pattern and enables greater autonomy for application teams. They're given an AWS account per app environment (e.g. WidgetApp Test, WidgetApp Prod, etc) and are able to build their stuff and attach it to existing subnets without a care about 'how' it communicates with the Internet or the greater organization.

Hikikomori 2y ago

You'll find that a plan like this is not overkill once you outgrow single accounts. Though I would do one account per system with Shared VPCs instead.

chippiewill 2y ago

We use peered VPCs at work. We have a central account per environment that has the VPC that's shared to all the other accounts in that environment for databases etc. To be honest, I'd probably prefer a single account per environment. But managing the IAM for that would be much more work.

cyberax 2y ago

> Having one account per database/backend/frontend is not only overkill, but actually a bad practice. That's how AWS works internally. A team can easily have several hundred accounts: one for each region, and for each env. You absolutely need tools to manage them, and AWS is not great in this regard. IAM Identity Center is a good first step, but its usability sucks compared to the AWS internal tool (called "Isengard"). > You're going to have to expose your DB to the internet instead of having everything inside a single VPC. There are several ways to NOT do this. The easiest one is to use IPv6 with your own block (you can get it from ARIN for around $100). Then split it into "public" and "private" subnets, and install a network ACL prohibiting external connections into the private subnet.