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

VPC endpoint service complications with availability zone restrictions #462

Closed
acdha opened this issue Jun 26, 2020 · 5 comments · Fixed by #635
Closed

VPC endpoint service complications with availability zone restrictions #462

acdha opened this issue Jun 26, 2020 · 5 comments · Fixed by #635

Comments

@acdha
Copy link
Contributor

acdha commented Jun 26, 2020

I ran into a problem attempting to provision an SES endpoint: the default is to use all private subnets but some are for unspecified reasons unsupported — in my case us-east-1a,e,f are listed as “Service not supported in this Availability Zone” in the console and so an apply fails:

Error: Error creating VPC Endpoint: InvalidParameter: The VPC endpoint service com.amazonaws.us-east-1.email-smtp does not support the availability zone of the subnet: subnet-0de46d7dcc06da2a7.
@acdha
Copy link
Contributor Author

acdha commented Jun 29, 2020

For anyone else who, like me, needed to be reminded that Terraform's dependency graph crosses module boundaries, the fix is relatively easy. It might be easiest to start with a documentation update for this situation since it would be a bit of work to update the endpoint service code to do this automatically:

module "vpc" {
  source                 = "terraform-aws-modules/vpc/aws"
  version                = "~> 2.44"enable_ses_endpoint              = true
  ses_endpoint_private_dns_enabled = true
  ses_endpoint_security_group_ids  = [aws_security_group.vpc_endpoints.id]
  ses_endpoint_subnet_ids          = data.aws_subnet_ids.private_subnets.ids
}

# Not all VPC endpoint services are supported in all availability zones. This
# caused a problem when 1 of the 4 VPCs used for our project didn't support
# SES. Fortunately we can make a separate query for that service information and
# use the results to filter the subnet list.

data "aws_vpc_endpoint_service" "ses" {
  service = "email-smtp"
}

data "aws_subnet_ids" "private_subnets" {
  vpc_id = module.vpc.vpc_id

  filter {
    name   = "subnet-id"
    values = module.vpc.private_subnets
  }

  filter {
    name   = "availability-zone"
    values = data.aws_vpc_endpoint_service.ses.availability_zones
  }
}

@acdha acdha changed the title Endpoint subnet IDs with AZ restrictions VPC endpoint service complications with availability zone restrictions Jun 29, 2020
@coofercat
Copy link

Just to add that I banged my head against the desk for some time on this, until I realised that what looks like a circular dependency works. Can't post the real code, but something like this:

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> v2.10.0"
...
  ssm_endpoint_subnet_ids = module.vpc.private_subnets
...
}

This is new in TF12, and somewhat hard to predict working. The example above is more complex, but if you follow it through, does much the same thing.

@DrFaust92
Copy link
Contributor

@coofercat, not sure that you solution address the issue at hand? if the subnets are created in AZ that dont support a give VPC endpoint it will still fail. you are just explicitly specifying subnets that are passed to the vpc endpoints as is.

@acdha can you open a PR to add some docs on the subject with the given example? i think its the best way to go around this issue.

@fahadshaikh09
Copy link

+1

@github-actions
Copy link

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 Oct 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
4 participants