3 ms·

Nice feature and I know larger companies would love it, but I personally would like to have better grouping ability of assets within the one AWS account. For i

Nice feature and I know larger companies would love it, but I personally would like to have better grouping ability of assets within the one AWS account. For instance, we have a bunch of servers for one web app, two or three for other apps, a few apps with single servers etc. Not just EC2 here, I am talking about RDS, Elastic Beanstalk, Route 53, CloudFront, DynamoDB, the works. Would be nice if we could define 'stacks' for each web app and have the on one neat console to work with. (I know there is the concept of 'Resource Groups', but that relies on tagging assets, and I don't believe tagging extends across all the AWS assets at this stage? I would love for someone to correct me on my assumptions.)

EwanToo 10y ago
This would, i think, largely be delivered by the AWS Organisation structure this post is talking about. Create an account per stack, switch role from your user account into the stack account to do any management.
- cyberferret 10y ago
  Ah. Thinking outside the box. That is a neat way to approach it - rather than staying small, we go bigger and utilise the new multi account feature to accomplish. I'll look into this a bit more. If we can maintain the same billing details across accounts, then it could be an easy way of doing what we want. Added bonus I guess is that if one of our web apps gets acquired, it is extremely easy to detach it from our account and move it on.
  - EwanToo 10y ago
    It looks like part of the setup is to define the consolidated billing account for the whole organisation, then each new account goes onto the bill central. The existing consolidated billing works pretty well, it's just the initial per-account setup of billing and roles that's been a headache before
rbirkby 10y ago
Blast radius reduction. Especially when different agencies build systems for the same company.
okhudeira 10y ago
I think CloudFormation [https://aws.amazon.com/cloudformation/ https://aws.amazon.com/cloudformation/] might be what you're looking for, they even use the term "stack". At first blush it might seem to have a high learning curve given the verbosity of the syntax to define a stack, but with the launch YAML support, the syntax has become more succinct. Once you use it, you'll wonder how you ever lived without it. The product page doesn't do it justice, but in short, CloudFormation allows you to: - Describe the AWS resources you need in a single file (YAML or JSON), this would be your "stack". - View all the resources provisioned based on your code in a single UI grouped under the "stack" in the CloudFormation console. - Manage changes to your resources as different versions of the code file, meaning if you update a resource's properties in code, it'll know and update the already provisioned resource. - You can delete an entire "stack" and be certain that all associated resources are also destroyed. - When I used it, the coverage of types of resources you can code for was wide and they're continuously adding more. I recommend trying it out by setting up a simple S3 hosted website using this template http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-s3.html#scenario-s3-bucket-website-customdomain http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuid... If you're trying to remain cloud-agnostic, then I suggest you also checkout HashiCorp's Terraform [https://www.terraform.io/ https://www.terraform.io/]. Think of Terraform as a scripting language that compiles into AWS CloudFormation or any other cloud provider.
- cyberferret 10y ago
  Thanks for the heads up on CloudFormation. I've just poked around and realise the our Elastic Beanstalk instances all create a stack in there automatically. Seems pretty useful, and I will investigate a little more to see if we can integrate other AWS assets like S3 buckets, RDS servers etc. into each stack for better management.
  - cbsmith 10y ago
    Save yourself the pain of CloudFormation and check out Terraform.

EwanToo 10y ago

This would, i think, largely be delivered by the AWS Organisation structure this post is talking about. Create an account per stack, switch role from your user account into the stack account to do any management.

cyberferret 10y ago
Ah. Thinking outside the box. That is a neat way to approach it - rather than staying small, we go bigger and utilise the new multi account feature to accomplish. I'll look into this a bit more. If we can maintain the same billing details across accounts, then it could be an easy way of doing what we want. Added bonus I guess is that if one of our web apps gets acquired, it is extremely easy to detach it from our account and move it on.
- EwanToo 10y ago
  It looks like part of the setup is to define the consolidated billing account for the whole organisation, then each new account goes onto the bill central. The existing consolidated billing works pretty well, it's just the initial per-account setup of billing and roles that's been a headache before

rbirkby 10y ago

Blast radius reduction. Especially when different agencies build systems for the same company.

okhudeira 10y ago

I think CloudFormation [https://aws.amazon.com/cloudformation/ https://aws.amazon.com/cloudformation/] might be what you're looking for, they even use the term "stack". At first blush it might seem to have a high learning curve given the verbosity of the syntax to define a stack, but with the launch YAML support, the syntax has become more succinct. Once you use it, you'll wonder how you ever lived without it. The product page doesn't do it justice, but in short, CloudFormation allows you to: - Describe the AWS resources you need in a single file (YAML or JSON), this would be your "stack". - View all the resources provisioned based on your code in a single UI grouped under the "stack" in the CloudFormation console. - Manage changes to your resources as different versions of the code file, meaning if you update a resource's properties in code, it'll know and update the already provisioned resource. - You can delete an entire "stack" and be certain that all associated resources are also destroyed. - When I used it, the coverage of types of resources you can code for was wide and they're continuously adding more. I recommend trying it out by setting up a simple S3 hosted website using this template http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-s3.html#scenario-s3-bucket-website-customdomain http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuid... If you're trying to remain cloud-agnostic, then I suggest you also checkout HashiCorp's Terraform [https://www.terraform.io/ https://www.terraform.io/]. Think of Terraform as a scripting language that compiles into AWS CloudFormation or any other cloud provider.

cyberferret 10y ago
Thanks for the heads up on CloudFormation. I've just poked around and realise the our Elastic Beanstalk instances all create a stack in there automatically. Seems pretty useful, and I will investigate a little more to see if we can integrate other AWS assets like S3 buckets, RDS servers etc. into each stack for better management.
- cbsmith 10y ago
  Save yourself the pain of CloudFormation and check out Terraform.