_This issue was originally opened by @willfarrell as hashicorp/terraform#16576. It was migrated here as a result of the provider split. The original body of the issue is below._
Announcement: https://aws.amazon.com/about-aws/whats-new/2017/11/amazon-api-gateway-supports-regional-api-endpoints/
In short you can now terminate a certificate at the API endpoint in it's region instead of at the edge (which requires the cert to be from us-east-1).
The feature would apply too: api_gateway_domain_name
/apigateway/home?region=us-west-2#/custom-domain-names
Would love to have this feature.
Related to #2167
Just to clarify, would this make multi availability zone apigateways possible? I tried such a setup a while ago with terraform but hit a design limitation, if I remember correctly the exact issue that hindered my setup was that the api gateway cloudfront was owned by a service account and as such I couldn't add an Alternate Name to cloudfront to enable it to accept the apigateway url and my domain. Something along that.
+1 for this feature. Need this sooner.
@nikhil-p Here's how I'm doing it
resource "aws_api_gateway_rest_api" "example" {
provider = "aws.default"
name = "example"
description = "example API"
provisioner "local-exec" {
command = "AWS_DEFAULT_PROFILE=jonathan aws apigateway update-rest-api --region ${var.region} --rest-api-id ${aws_api_gateway_rest_api.example.id} --patch-operations op=replace,path=/endpointConfiguration/types/EDGE,value=REGIONAL"
}
}
You might also need
resource "aws_api_gateway_domain_name" "example" {
provider = "aws.default"
domain_name = "example.example.com"
certificate_arn = "${data.aws_acm_certificate.example.arn}"
provisioner "local-exec" {
command = "AWS_DEFAULT_PROFILE=jonathan aws apigateway update-domain-name --region ${var.region} --domain-name ${aws_api_gateway_domain_name.example.domain_name} --patch-operations op=replace,path=/endpointConfiguration/types/EDGE,value=REGIONAL"
}
}
@jonathan-kosgei - Thanks for the reply, any templates for doing it in cloud formation? Also, how would i grab the target domain from the step above ? i would need that to create a cname.
If you would like to be able to configure between REGIONAL and EDGE then using a null resource may be a better way to achieve the functionality. This allows for updates with the use of the trigger
variable "endpoint_configuration_type" {
//REGIONAL or EDGE
default = "REGIONAL"
}
resource "null_resource" "endpoint_configuration" {
triggers {
endpoint_configuration_type = "${var.endpoint_configuration_type}"
}
provisioner "local-exec" {
command = "aws apigateway update-rest-api --rest-api-id ${aws_api_gateway_rest_api.api.id} --patch-operations op=replace,path=/endpointConfiguration/types/EDGE,value=${var.endpoint_configuration_type}"
}
}
Thought I'd share how I got this working. Thanks to the other examples posted here!
I needed the output from the custom regional domain to use as an origin for my own cloudfront distribution that I put in front of the API.
I'm not using the aws_api_gateway_domain_name + update-domain-name solution as in examples above because it tried to create a custom Edge domain first which caused conflict errors with an existing CloudFormation distribution I had.
Also, I had to make sure that awscli
was at the latest version and I'm using jq
here because terraform did not like parsing non-string values in the JSON response from the aws cli.
provider "external" { }
locals {
endpoint_configuration_type = "REGIONAL"
common_domain_options = "--region ${var.region} --profile ${var.profile} --domain-name ${var.api_domain}"
}
resource "aws_api_gateway_rest_api" "this" {
name = "${var.name}"
}
resource "null_resource" "endpoint_configuration" {
triggers {
endpoint_configuration_type = "${local.endpoint_configuration_type}"
}
provisioner "local-exec" {
command = "aws apigateway update-rest-api --region ${var.region} --profile ${var.stage} --rest-api-id ${aws_api_gateway_rest_api.this.id} --patch-operations op=replace,path=/endpointConfiguration/types/EDGE,value=${local.endpoint_configuration_type}"
}
}
data "external" "custom_regional_domain" {
program = [
"bash", "-c",
"(aws apigateway get-domain-name ${local.common_domain_options} || aws apigateway create-domain-name ${local.common_domain_options} --endpoint-configuration types=REGIONAL --regional-certificate-arn ${data.aws_acm_certificate.this.arn}) | jq '. | {domainName: .domainName, regionalDomainName: .regionalDomainName}'"
]
}
resource "aws_api_gateway_base_path_mapping" "this" {
api_id = "${aws_api_gateway_rest_api.this.id}"
stage_name = "${var.stage}"
domain_name = "${data.external.custom_regional_domain.result["domainName"]}"
}
resource "aws_cloudfront_distribution" "this" {
origin {
domain_name = "${data.external.custom_regional_domain.result["regionalDomainName"]}"
...
}
...
}
These work arounds are okay for updating API Gateways in many regions, but they do not solve the problem in cn-north-1 where only regional API Gateways are supported (presumably since there is no CloudFront in China either). The API Gateway creation fails, so it cannot be updated afterward.
Error creating API Gateway: BadRequestException: Endpoint Configuration type EDGE is not supported in this region: cn-north-1
If anyone knows a different workaround, I would love to hear it. I'll be watching this and the associated PR.
+1
+1
+1 for this feature. Need it soon.
+1
+1. Really hoping to see this as it's blocking us from migrating to Terraform for some of our config.
It will be out soon. @bflad is working on it #2866
+1
Totally forgot I created this feature request. Excited to start testing it out after PR https://github.com/terraform-providers/terraform-provider-aws/pull/2866 it gets merged, which appears to be very soon.
Support for managing regional REST APIs and domain names has been merged into master and will release with v1.20.0 of the AWS provider later this week. 🎉
This has been released in version 1.20.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.
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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!
Most helpful comment
Would love to have this feature.