4 ms·

I didn't know about the limit although you might be able to get it bumped? In my experience we haven't had any issues getting to that limit but we only ever us

I didn't know about the limit although you might be able to get it bumped? In my experience we haven't had any issues getting to that limit but we only ever use 1 level of depth (the service) and each environment has it's own AWS account so there is no path for environment. Each service has a IAM Role with an IAM Policy attached that gives it access to all of the keys under the service path. A way to fix the team prefix (what if 2 teams actually need access to that secret?) would be to not have it in the path but use roles that teams can assume to get access to those secrets.

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 ago
  VPCs 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 ago
    Not 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.

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 ago
VPCs 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 ago
  Not 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.