Support for the Region Argument in all resources

[carlcauchi]

Is your request related to a new offering from AWS? ✅

Yes — AWS has recently introduced support for the region argument for RDS resources, enabling cross-region database provisioning and configuration directly within a single Terraform workspace.

This functionality is available in the AWS Provider v6.0+.

Describe the solution you'd like

Please add support for the new region argument in the RDS module so that users can explicitly set the AWS region for RDS instances, clusters, and related resources.

This aligns with the updated AWS provider behavior for RDS resources documented here:
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/db_instance#region-1

Allowing this parameter to pass through the module will enable multi-region deployments without relying solely on provider aliases, improving clarity and reducing config complexity.

Describe alternatives you've considered

Using multiple provider aliases — works, but becomes complex when scaling multi-region infrastructure patterns.

Additional context

Native support for the region argument in the module will streamline cross-region deployments and align this module with the latest AWS provider capabilities.

Thanks for considering this improvement! 🙏

[bryantbiggs]

I'm curious, what is the motivation behind wanting to setup cross region replication with the region argument?

[carlcauchi]

I'm curious, what is the motivation behind wanting to setup cross region replication with the region argument?

Thanks for the question!
To clarify — this request isn’t for cross-region replication.

The motivation is to avoid having to declare and pass multiple aliased providers when deploying the module across multiple regions. With the AWS provider v6+ support for the region argument, we can simply iterate over regions (e.g., for_each on a region map) and let the resource handle its own region setting.

This enables cleaner, more scalable multi-region patterns without maintaining separate provider blocks such as:

provider "aws" {
  alias  = "us-east-1"
  region = "us-east-1"
}

provider "aws" {
  alias  = "eu-central-1"
  region = "eu-central-1"
}

Instead, we could do:

for_each = var.regions

region = each.value

This keeps code DRY, improves maintainability, and aligns the module with the new Terraform AWS provider capabilities.

[bryantbiggs]

apologies, should have been what is the motivation behind wanting to setup cross region *configuration with the region argument?

so back to that question - lets ignore anything code related for the moment. What is your motivation for wanting to create resources in multiple regions - such as RDS database resources

[carlcauchi]

apologies, should have been what is the motivation behind wanting to setup cross region *configuration with the region argument?

so back to that question - lets ignore anything code related for the moment. What is your motivation for wanting to create resources in multiple regions - such as RDS database resources

Thanks for the clarification!

The motivation isn’t cross-region configuration of a single database — we are not trying to replicate or fail-over an RDS instance across regions.

We run a multi-region platform where different workloads operate in different AWS regions for latency, compliance, and redundancy reasons. As part of that, we need to deploy independent RDS instances in multiple AWS regions, with no replication between them.

Right now, the module requires separate aliased providers for each region, which becomes cumbersome as the number of managed regions grows. With the new AWS provider support for region at the resource level, we could deploy identical stacks across multiple regions in a scalable way — without needing manual provider alias management.

In short:

• Multiple regions-
• Independent RDS instances (not replicated)-
• Cleaner, scalable infra using the new AWS provider capability

This is why region passthrough support would be extremely useful.

Happy to provide more detail if needed — thank you again for discussing!

[bryantbiggs]

and redundancy reasons.

thats a bit confusing if you are saying they are independent and not replicated

but ok, thank you for the information. last question 😬

you have very clearly taken deliberate steps to isolate your database resources, for various reasons. why don't you treat the code that defines and manages those the same way? meaning - you have independent resources spread about the globe, all separate and isolated, but your code is all in a single point of failure. given the recent AWS outage in us-east-1 - how do you reason about trying to make changes to your infrastructure if all of your regions are defined in a single Terraform project (i.e. - statefile)?

we will add the region argument, we have been rolling that out with various other upgrades, but I don't really follow the group of folks who are shooting themselves in the foot with this new argument and claiming this "DRY" nonsense. (fun fact - your IaC should not be "DRY" in my opinion. That is a software term that has a different meaning, this is configuration. Named workspaces were created by Mitchel to allow for developer like setups - think PR preview sites.) Prod will never look like dev - thats just a fact of life for 95% of scenarios.

[carlcauchi]

On DRY — totally agree that infra code isn't meant to follow the same DRY philosophy as application code. We’re not trying to abstract environments into a single “one-size-fits-all” module stack or build meta-modules that hide everything (seen too many of these 🥲 ). The goal is simply to avoid repetitive provider alias plumbing and reduce accidental complexity, not to over-engineer or force uniformity where it doesn’t belong.

Think more in terms of maintaining consistency and clarity, not “make everything identical” or “abstract until unreadable.” We still keep regional differences explicit — we just prefer not to repeat boilerplate wiring everywhere when the provider now gives us a clean native mechanism.