Hacker News Reader

Comment by colemorrison | Hacker News Reader

This is good stuff right here. Separate accounts can do tons. Also helps prevent stuff like dealing with VPC collision overhead.

View on HN

One account per service per region per deployment stage (e.g. dev, test, production) is the best practice. How you define "service" is up to you, but I usually divide them by trust/dependency footprints.

This significantly reduces the risk that an account-level problem or throttle will disrupt your entire business.

Fortunately, AWS finally seems to be getting serious about building management tools for multiple accounts. AWS Organizations is way better than the old consolidated billing stuff.

Who calls that a best practice? If you're a very small company, that might be fine. With thousands of employees and tens or hundreds of applications, you'll run into serious problems if you want to use e.g. VPC peering for shared services. You'll also run into major cost issues if for example you have per-VPC or per-account commercial appliances.

AWS uses this isolation pattern internally for just about everything, for what it's worth.

Not the "per region" part, that just seems silly.

That's interesting, because their consultants discourage it for their customers. For companies that want to keep most of their traffic internal, I don't think it's a working model. I suppose Amazon's internally used services are the same ones they expose to customers, so it probably works fine.

Reply on news.ycombinator.com