search

aws-ia / terraform-aws-control_tower_account_factory

AWS Control Tower Account Factory
Apache License 2.0
604 stars 386 forks source link

Add flag that disables "auto-approve" on customization invocations after initial customization apply #415

Open robbycuenot opened 5 months ago

robbycuenot commented 5 months ago

Feature request: A flag that can be set to turn off auto-apply for customization flows that are manually applied

To the best of my knowledge, there is no supported way to turn off auto-applies for customizations when you re-invoke them through the step function. This means that updates to a particular customization apply to accounts without the chance to review them first. Being able to see what will change on prod accounts, particularly when customizations on multiple accounts may be on different versions, is crucial. I'm not sure where this flag would be set; maybe at the account level as a flag in the request?

robbycuenot commented 5 months ago

Discussion started in this reddit thread: https://www.reddit.com/r/Terraform/comments/191vcqh/comment/kgz4w0p/?utm_source=share&utm_medium=web2x&context=3

Sanjan611 commented 5 months ago

Thanks @robbycuenot , I've noted the feature request in our backlog.

Out of curiosity, is having multiple versions of the a customization (ie different versions for different accounts) a requirement for your use case?

robbycuenot commented 5 months ago

Thanks @robbycuenot , I've noted the feature request in our backlog.

Out of curiosity, is having multiple versions of the a customization (ie different versions for different accounts) a requirement for your use case?

Hey @Sanjan611, having multiple versions isn't a requirement, but rather a byproduct of a customization getting updates without re-applying to every account every update.

For instance, account1 is created with v1.0. To support a new project, the customization is updated to v1.1. account2 and account3 are created with this v1.1 customization. The same occurs with account4 and account5 on customization v1.2.

At this point, if no manual invocations have executed, you end up with this: account customization version
account1 v1.0
account2 v1.1
account3 v1.1
account4 v1.2
account5 v1.2

In this scenario, I'd like to bring all accounts up to speed with v1.2. However, in a real world scenario this could involve a more complex matrix (say, 20 accounts on 5 different versions). I could invoke the customizations on all, but without being able to plan them first it becomes a very risky operation.