Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address Subnets by availability_zone_id #350

Closed
syquus opened this issue Oct 30, 2019 · 5 comments
Closed

Address Subnets by availability_zone_id #350

syquus opened this issue Oct 30, 2019 · 5 comments

Comments

@syquus
Copy link

syquus commented Oct 30, 2019

Hello,
I've been some days working with this module.

I've found a dead-end regarding AZ IDs. It's a common necessity to relate the same DataCenters from one account to another. Using subnets ONLY by its name, limits strongly how flexible AWS is.

Is there any plan or workaround to make the module work being aware of Subnet availability_zone_id attribute?
It's documented in AWS Provider doc

Regards

@Japeth
Copy link

Japeth commented Jan 3, 2020

I second this. I need to deploy subnets in certain availability zones. For whatever reason, AWS naming conventions of us-east-1c is not the same between accounts...but use1-az2 zone ID is always the same. I need the ability to make sure when I deploy these subnets, the are in the zones I specify.

@bryantbiggs
Copy link
Member

hello all - thanks for submitting this. Amazon abstracts the AZ ID for a reason - this allows them to distribute resource utilization appropriately across a region. if everyone relied on us-east-1a, us-east-1b, us-east-1c as being the same physical AZ, then those AZs would be heavily overloaded compared to the remaining three in us-east-1 (us-east-1d, us-east-1e, us-east-1f). if you need low latency, I would suggest using clustered placement groups - this is going to be per account though. this would go against the flexibility and resource balancing that AWS is trying to provide. if your infrastructure is this closely tied to physical AZs, I would question if you have approached your architecture in an appropriate manner - open to hearing use cases though

@Japeth
Copy link

Japeth commented Jan 13, 2020

Well,

I would love it if Amazon was actually flexible with the Availability zones and you could throw whatever resources in whatever AZs you wanted. However, when deploying WORKSPACES, you can only deploy into certain availability zone IDs. Now this becomes a nightmare because unless you know the AZ IDs up front, you could easily deploy the pre-requisite resources (such as AWS Active Directory) in the "wrong" availability zones. Then when you try to deploy workspaces into the subnet, you get an error back stating you're using the wrong availability zones. There are literally dozens of public support topics with other engineers asking how to find the correct availability zones to use. What's worse, is because AWS abstracts the zone names from the IDs, no one's solution is the correct solution for anyone else. This has lead to individuals attempting trial and error to find the correct Availability zones that support workspaces. Thankfully, AWS has improved the error message when this occurs, and you at least get the correct availability zone ids back. This doesn't help when attempting to use this module however, as az ids is not a parameter on it. This is why I am asking for availability zone IDs as a parameter.

@antonbabenko
Copy link
Member

I have just released v2.25.0 (after #370 has been merged) and you can now specify AZ IDs or AZ names in azs argument, like this (pick one):

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"

  # Option 1 - Using AZ names
  azs = ["eu-west-1a", "eu-west-1b"]

  # Option 2 - Using AZ ids
  azs = ["euw1-az1", "euw1-az2"]

  # Option 3 - Using mixed values (names and ids)
  azs = ["eu-west-1a", "euw1-az2"]
}

Closing this issue.

@github-actions
Copy link

github-actions bot commented Nov 3, 2022

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants