Feature request: support multiple regions and accounts CloudFormation StackSets

[hiroqn]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

CloudFormation StackSets has options to specify multiple region and accounts.
But, aws_cloudformation_stack_set_instance only accept 1 account and 1 region.
aws_cloudformation_stack_set_instance may accept multiple region or accounts.

example from docs , cli accept multiple.

aws cloudformation create-stack-instances \
  --stack-set-name my-awsconfig-stackset \
  --accounts '["account_ID_1","account_ID_2"]' \
  --regions '["region_1","region_2"]' \
  --operation-preferences FailureToleranceCount=0,MaxConcurrentCount=1

This is reference source code

• terraform-provider-aws/internal/service/cloudformation/stack_set_instance.go

  Line 163 in 3cdebe9

  Regions: aws.StringSlice([]string{region}),

• https://github.com/aws/aws-sdk-go/blob/ec3763d8d5abacbf47c0b4296fb5d27821297508/service/cloudformation/api.go#L8732

New or Affected Resource(s)

• aws_cloudformation_stack_set_instance

Potential Terraform Configuration

I have 3 ideas.

• add regions which accept list of regions

  • resource "aws_cloudformation_stack_set_instance" "example" {
      deployment_targets {
      organizational_unit_ids = [aws_organizations_organization.example.roots[0].id]
    }
      regions         = ["us-east-1", "ap-northeast-1"]
      stack_set_name = aws_cloudformation_stack_set.example.name
    }

• region accept list of regions

  • resource "aws_cloudformation_stack_set_instance" "example" {
      deployment_targets {
      organizational_unit_ids = [aws_organizations_organization.example.roots[0].id]
    }
      region         = ["us-east-1", "ap-northeast-1"]
      stack_set_name = aws_cloudformation_stack_set.example.name
    }

• region accept comma delimited region

  • resource "aws_cloudformation_stack_set_instance" "example" {
      deployment_targets {
      organizational_unit_ids = [aws_organizations_organization.example.roots[0].id]
    }
      region         = "us-east-1,ap-northeast-1"
      stack_set_name = aws_cloudformation_stack_set.example.name
    }

References

[jgrumboe]

@justinretzolk I've got a question since you remove the needs-triage label: what's the decision here?
Hacktoberfest is around the corner and I would like to try my luck with this one.
The OP suggested 3 ideas, out of which I would probably go for number 1 (for backward compatibility, maybe deprecating region in favor of regions).

[justinretzolk]

Hey @jgrumboe 👋 I appreciate your interest in this one! In this case, my removal of the needs-triage label means that I've reviewed it and that we don't need any additional information at the moment. It's still in the backlog to be prioritized by the team. Once the team is able to prioritize this request, they'll be able to speak to the path they'd like to take (I'm the community manager for the provider, so that particular decision isn't up to me).

[ArgyrisKefalas2022]

Is there any update about this?

[ashoksankarh]

Is there any update on this? One of the advantages to using stack sets and instances is so that we can parallelize the resource creation across regions.
Without this, resources (that require creation in multiple regions) need to specified one by one sequentially (with "depends" clause) as each stackset instance creation will be one operation and stacksets only support one operation at a time.

[anothercopy]

Any news on this ? It's a bit problematic for us and we have a few updates upcoming to out stacksets

[sahaqaa]

is there any updates on this?

[alvaro-fdez]

any news on this? we are using a workarround that consist of deploying stacksets on multiple (aws-cli) regions and then import it with the aws_cloudformation_stack_set_instance resource. It does the trick and the stacksets instances are deployed on every region selected but is very annoying...

[michalz-rely]

Is there any update on this?

[popsicleslayer]

Is there any news on supporting this? It would be awesome if this got implemented 😄

[rads18]

I see this is listed as an enhancement however, per documentation below it says for resource aws_cloudformation_stack_set_instance there is operational_preference parameter that allows PARALLEL execution, what is that for ?.. if only one region is allowed.

region_concurrency_type - (Optional) The concurrency type of deploying StackSets operations in Regions, could be in parallel or one Region at a time. Valid values are SEQUENTIAL and PARALLEL.

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudformation_stack_set_instance

[jgrumboe]

I still would like to implement this.
I just need a hint, which of the three ideas in the OP is the preferred way (mine would still be the first one)?

[rads18]

I still would like to implement this. I just need a hint, which of the three ideas in the OP is the preferred way (mine would still be the first one)?

I agree the first option makes most sense to me as well.

@jgrumboe how long can this feature take build to be GA?

[jgrumboe]

@rads18 I can try to build a PR within the following days. I cannot tell if and when it will get merged.

[rads18]

@rads18 I can try to build a PR within the following days. I cannot tell if and when it will get merged.
@jgrumboe sure . Our use case multi accounts and multi region infras to rollout and we foresee Terraform greatly can reduce our overall cycle time without much code changes if we have multi region support. thanks !

[jgrumboe]

I just started this evening with some tests and recognized that this would be tricky.
The current implementation/limitation to only support one account and one region simplifies the implementation because it results in a 1:1 relation between terraform resource and stack set instance.
Extending to multiple regions results in a 1:n relation and makes things more complex.
Currently, a region change "just" forces a recreation of the whole stack set instances. This is not feasible with multiple regions, as a user may wants to add and remove regions without recreating stack set instances in untouched regions. And so on.

This definitely requires a lot more thinking than I thought. This is probably a kind of refactoring, which should also take multiple account ids into consideration, as I believe the problem is the same there.

[ericofusco]

The current implementation/limitation to only support one account and one region.

That's not really the case, multiple accounts are supported with the deployment_targets parameter, the parameter is outdated with the current API too: https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStackInstances.html

Although it deploys to multiple accounts and/or regions, it's still a single API call/resource and response.

Related FR: #33914

[rads18]

@ericofusco i recall seeing that as well however, just to clarify the deployment_targets is capable deploying to multiple accounts but to the same region right?, i ask because I only a single region allowed for the aws_cloudformation_stack_set_instance resource

Generally speaking i am a bit lost on the release config for stacksets in Terraform, if its a single region one might as well use a stack

[jgrumboe]

That's not really the case, multiple accounts are supported with the deployment_targets parameter, the parameter is outdated with the current API too: https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStackInstances.html

You're right.
I also had a look at the deployment_targets implementation and saw it's a single API call. I will test a little bit with that, and maybe the usage of the summary in the API response is something that could be used in general to also support multiple regions/accounts.

But how do you see it's an outdated parameter? Following the link, I still read that DeploymentTargets is a valid request parameter.

Although it deploys to multiple accounts and/or regions, it's still a single API call/resource and response.

Related FR: #33914

Yes, I saw that FR also.
Thinking more about it, could it be that supporting multiple regions and the FR for deployment_targets could be the overall solution?
I mean, one could then define the root-OU, AccountFilterType INTERSECTION and the account ids together with multiple regions.

Or do I miss something?

[rads18]

Based on the endpoint you can have multiple Accounts with multiple regions however, the regions selected will apply to all accounts part of the that resource and that makes sense and is in line with how it works in UI as well.

If a user need different regions for an account that will be an additional aws_cloudformation_stack_set_instance resource for that account(s).

[ericofusco]

Thinking more about it, could it be that supporting multiple regions and the FR for deployment_targets could be the overall solution?

Agree, what needs to be done is update the region parameter from string to an array of strings and update the deployment_targets block with the current API schema: https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_DeploymentTargets.html

[rads18]

@jgrumboe is there any update or progress with this?

[jgrumboe]

@rads18 Sorry, not yet. I had to focus on other topics. I need some time to think about this here again. I fear there will be some hidden problem with the resource ids, which have the region as part of it. I'd like to avoid changes in the resource id.
But as said, currently, no free time from my side here unfortunately.

[rads18]

Thats unfortunate there is no one take this on. I am not sure how the community agreed to release Cloudformation stacksets to begin with, without it being able to expand to multiple regions. It totally defeats the main purpose for it.

[0xVak]

Would also like to see this. Having to set 17 different instance resources for all the different regions is functional, yet an annoyance.

[grosschmid]

Just pinging if this could be picked up again..

[ewbankkit]

@hiroqn et al. Is creating multiple resources, one per (account_id, region) pair, probably using the for_each construct, not sufficient?

[ashoksankarh]

@ewbankkit that works but doesn't scale for deployments in a big org, especially creating resources for region specific services like EventBridge - imagine creating EB rules in each and every region for an organization with 1000s of accounts
With draios/terraform-aws-secure-for-cloud#65, it isn't as bad as before but it is limited by the parallelism in large orgs. Would be great if terraform can support regions (for stackset instances) like aws cli/API do
#36794 any major issues with the PR?

[ewbankkit]

To avoid any backwards compatibility issues with the current aws_cloudformation_stack_set_instance resource, I'm thinking that we should create a new resource aws_cloudformation_stack_set_instances that takes multiple accounts and Regions (i.e. matches closely to the underlying API) and eventually deprecate aws_cloudformation_stack_set_instance.

We would add state move functionality to allow simple migration to the new resource.

[ericofusco]

@ewbankkit I agree with moving away from aws_cloudformation_stack_set_instance. I believe what happened during the development of the resource is that initially was meant to manage a single stack instance (account_id and region) but the main point of stacksets is to deploy stacks across multiple accounts and regions with a single resource and configuration.

[YakDriver]

@hiroqn I'm working on PR #36794 to do the items listed in the op. Let me know if you have concerns.

[hiroqn]

Thank you for great PR! I have no concerns.

[github-actions]

Warning

This issue has been closed, meaning that any additional comments are hard for our team to see. Please assume that the maintainers will not see them.

Ongoing conversations amongst community members are welcome, however, the issue will be locked after 30 days. Moving conversations to another venue, such as the AWS Provider forum, is recommended. If you have additional concerns, please open a new issue, referencing this one where needed.

[github-actions]

This functionality has been released in v5.67.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.