3 ms·
This is good stuff right here. Separate accounts can do tons. Also helps prevent stuff like dealing with VPC collision overhead.
by colemorrison 10y ago
This is good stuff right here. Separate accounts can do tons. Also helps prevent stuff like dealing with VPC collision overhead.
- availabilly 10y agoOne 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.
- joseph 10y agoWho 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.
- schlarpc 10y agoAWS uses this isolation pattern internally for just about everything, for what it's worth.
- openasocket 10y agoNot the "per region" part, that just seems silly.
- joseph 10y agoThat'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.