Skip to content

The aws_region parameter is unevenly applied #5209

Description

@grahamc

Hi,

I'm looking at deploying this stack to a variety of regions. I was going to implement this by setting the "aws_region" parameter to an alternate region and go from there. I pretty quickly found a lot of resources aren't provided that option, and thusly get provisioned in the default region for the aws provider.

I looked (briefly) at fixing this by uniformly adding the region to each resource and PRing it. However, I realized it is probably somewhat futile without an automated test, like tflint, asserting that region is always specified except for resources which don't accept the region option.

I briefly looked at creating a tflint rule for this to make it future-proof, but figured I should stop and check in.

I think my main question is:

  1. What is the aws_region parameter for? In case I've misunderstood the purpose.
  2. Is this worth solving? Or removing the aws_region parameter?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions