3 ms·
Yeah, I personally find using separate AWS accounts for dev/test/stage to be a bit of a PITA overall, prefer to isolate those resources via VPCs & IAM policies
by sudosteph 8y ago
Yeah, I personally find using separate AWS accounts for dev/test/stage to be a bit of a PITA overall, prefer to isolate those resources via VPCs & IAM policies in an umbrella non-prod account, but definitely see how that would simplify other aspects of setup.
The path limit isn't a huge issue, just something you have to design around up front. As you mentioned in another comment, no reason you can't store a JSON or something in the string if you need deeper nesting.
For secrets needing to be shared between teams I'd just create a different prefix in the place of team, like /shared/, and grant access appropriately. Or just use no team prefix at all and make it accessible if it's for everyone.
But it's quite nice that the service is flexible enough to be useful for a variety of use cases / infrastructure setups.
- scarface74 8y agoVPCs are not a substitute for accounts. Most AWS resources must have unique names across the account like lambdas, SQS queues, sns topics etc. When you have one account you end up prefixing/suffixing resource names for different environments. It gets to be really ugly.
- sudosteph 8y agoNot a problem. Just deploy with CloudFormation and it will give you unique names for your resources automatically. You can use the same template for everything and filter by the stack tags it auto adds. Still way easier than dealing with creds, billing, and monitoring for 3 different non-prod accounts. Though I admit that the new aws organizations feature has made the billing setup stuff a little easier.