search

aws-solutions / aws-control-tower-customizations

The Customizations for AWS Control Tower solution combines AWS Control Tower and other highly-available, trusted AWS services to help customers more quickly set up a secure, multi-account AWS environment using AWS best practices.
https://docs.aws.amazon.com/controltower/latest/userguide/cfct-overview.html
Apache License 2.0
356 stars 205 forks source link

Feature Request: Optional key used to derive the StackSet name #95

Open cacack opened 2 years ago

cacack commented 2 years ago

Is your feature request related to a problem? Please describe. Currently, the name key of each block in the resource section of the manifest file is used to derive the name of the CloudFormation StackSet. Changing the name key will result in deleting the current StackSet and creating a new one. This blocks our ability to refactor our manifest file, particularly for the blocks which builds critical infrastructure resources like our TransitGateway.

Describe the feature you'd like I'd like to be able to directly specify or override the name used in deriving the resulting CloudFormation StackSet. A possible solution would be to offer the use of an optional key, say stackset_name, which would then be used for naming the CloudFormation StackSet. This would allow us refactor our manifest file, ensuring the StackSet remains undisturbed, by:

  1. copying existing blocks
  2. provide a new name key
  3. use the stackset_name key to keep the previous value of name

Additional context This could be viewed as a "lightweight" way to address some of what I raised in #88. Refactoring a given block into two blocks would allow us to clone the underlying templates, and adjust the mix of OUs/accounts the block applies to, thereby providing us a way to roll out changes to incremental portions of our environment.

Note I do not view this as a "proper" solution to #88 as the feature being requested ere would essentially amount to humans cut-n-copying code/changes as a means of "promotion", which is not a proper SDLC.

balltrev commented 2 years ago

Hey @cacack, thanks for detailing your use case for me. If I understand correctly, the feature as described is to have CfCT implement a SDLC within its deployment process. Is that correct, or have I missed the goal of what you're trying to accomplish?

CfCT was designed as a deployment tool for customizations in CT managed accounts, but isn't opinionated about the development/test/release process prior to that deployment, and that's by design because customers' release workflows differ so greatly. For example, one configuration to accomplish is to have a development, staging, and prod deployment of CfCT in separate accounts to promote tested infrastructure/code accordingly while keeping each environment suited to the relevant release stage. We recommend a route similar to that because it avoids a stateful nature for the CfCT deployment and keeps things clean and separated.

Let me know if that setup works for you, and please correct me if I've misunderstood the use case you have in mind.

gabrielbac commented 1 year ago

Hi @cacack you should try to use this:

https://pypi.org/project/aws-control-tower-manifest-builder/

it builds your manifest file based on the data you have in the metadata of your template. it derives the name from the template file name.

cacack commented 1 year ago

Thanks @gabrielbac ! I will definitely take a look at that. We did end up pivoting away from CfCT and back to our roots with Terraform (homegrown but borrowing from Account Factory for Terraform).