Hacker News Reader

Comment by tenplusfive | Hacker News Reader

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-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.

View on HN

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.

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.

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.

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.

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 $$$.

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?

Reply on news.ycombinator.com