tmccombs commented 1 year ago

Description

When working with multiple regions, currently in most cases you have to use a separate aws provider alias for each region. While this is workable in many cases, there are other cases where it is not very workable. In the best case it means you have to duplicate your provider configuration, varying only in the region. In other cases it can seriously constrain the design of the terraform code. If resources allowed you to specify the region to use for them, through an attribute that override the default region of the provider, than it would simplify working with multiple regions without having to wait for support for more dynamic provider configuration from the terraform engine.

Example Use Cases

Here are some specific use cases where being able to create resources in multiple regions with the same provider would be beneficial:

A module which creates a primary s3 bucket, with replicas in a number of regions, and sets up replication to those other buckets. Currently due to needing a separate provider for each region the number of regions supported would have to be a fixed number, and the resources for each bucket would need to be copied a number of times equal to the number of regions (foreach and count can't be used). (This would be possible if you had both a way to pass in a dynamic set of aliases to a module, and a way to do a for_each over such a dynamic set of providers).
Similar to the above but for kms replica keys (and actually the above module might potentially want to create kms replicas in each region where there is a bucket).
A module which creates a cloudfront distribution along with an ACM certificate to use with it. Since the certificate has to be in the us-east-1 region, currently you would need the caller of the module to pass in a separate provider alias for the us-east-1 region. And the module can't be sure that the caller passed in the right region.
A module which optionally (using count) creates some resources in one or more other regions. Possibly because those resources are for backups that aren't needed in non-production cases. It's possible to do this currently, but the caller needs to pass in something for the provider for the optional region, even if it isn't used.

Affected Resource(s) and/or Data Source(s)

Many. Some of the most important ones are possibly:

aws_s3_bucket and related
aws_acm_certificate (in particular, you need to create certificates in the us-east-1 region to use with cloudfront)
aws_kms_key and aws_kms_replica_key

Potential Terraform Configuration

The example from https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/kms_replica_key

could be rewritten to something like:

resource "aws_kms_key" "primary" {
  description             = "Multi-Region primary key"
  deletion_window_in_days = 30
  multi_region            = true
  region                  = "us-east-1"
}

resource "aws_kms_replica_key" "replica" {
  description             = "Multi-Region replica key"
  deletion_window_in_days = 7
  primary_key_arn         = aws_kms_key.primary.arn
  region                  = "us-west-2"
}

Or if used in a module that accepts multiple regions something like:

resource "aws_kms_key" "primary" {
  description             = "Multi-Region primary key"
  deletion_window_in_days = 30
  multi_region            = true
  region                  = var.primary_region
}

resource "aws_kms_replica_key" "replica" {
  for_each = var.replica_regions

  description             = "Multi-Region replica key for ${each.key}"
  deletion_window_in_days = 7
  primary_key_arn         = aws_kms_key.primary.arn
  region                  = each.key
}

References

Some more specific issues:

Would you like to implement a fix?

No response

github-actions[bot] commented 1 year ago

Community Note

Voting for Prioritization

Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
Please see our prioritization guide for information on how we prioritize.
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.

Volunteering to Work on This Issue

If you are interested in working on this issue, please leave a comment.
If this would be your first contribution, please review the contribution guide.

sblask commented 1 year ago

I am looking into Guardduty and need to generate 23 providers, one for each supported region to enable Guardduty, it would be much simpler to just have a for_each over the regions. Unfortunately Terraform does not allow dynamic providers...

There is also a problem with having the region on provider level, if you create resources in the wrong region and then change the region on the provider, Terraform only wants to create the resource in the new region, but doesn't want to destroy the resource in the wrong region.

tmccombs commented 1 year ago

If I were to create pull requests to add support for this for at least some resources, would that be likely to be accepted? (contingent on it being high enough quality of course)

breathingdust commented 1 year ago

Hi @tmccombs 👋 We have been chatting with @brittandeyoung about this (he has put a compelling PoC together in #31517) and we are all positive about the approach. There is some internal due diligence we need to get through in introducing what is a bit of a paradigm change in how the provider is used. We have that scheduled for next quarter after which we will update to community on how we propose to implement and introduce it to the provider, would love feedback at that point.

Appreciate your patience and input!