Caching cannot be enabled in the default deployment for API Gateway

[betabandido]

As the AWS SDK for Go documentation shows, it is possible to specify whether the cache cluster for the default deployment is enabled (and its size). By default deployment I refer to the one created with aws_api_gateway_deployment as opposed to aws_api_gateway_stage.

However, as the current Terraform code shows, the fields to specify the cache cluster settings are not used:

deployment, err := conn.CreateDeployment(&apigateway.CreateDeploymentInput{
	RestApiId:        aws.String(d.Get("rest_api_id").(string)),
	StageName:        aws.String(d.Get("stage_name").(string)),
	Description:      aws.String(d.Get("description").(string)),
	StageDescription: aws.String(d.Get("stage_description").(string)),
	Variables:        aws.StringMap(variables),
})

This forces us to create two stages whenever we need caching. The one created with aws_api_gateway_deployment will not have caching enabled, while the one created with aws_api_gateway_stage will have caching enabled (as that resource allows for the configuration of the cache cluster).

Given that CreateDeploymentInput actually has fields to configure the cache cluster, it would be nice to let users configure the cache cluster in the default deployment.

[momania]

Probably better to have aws_api_gateway_deployment not required a stage name so no default stage is created.
A stage should point to a deployment anyway, not vice versa.

I'm running into the sample problem now here, with added bonus that the creation of a seconds stage, pointing to my earlier deployment fails with: BadRequestException: Deployment id does not exist

So I have no way to enable caching on my api as I can't control the stage settings.

[betabandido]

Based on the API reference it might not be possible to create a deployment without a stage.

[dudemcbacon]

I was able to enable cache settings with a local provisioner like this:

resource "aws_api_gateway_deployment" "test" {
  depends_on = [
    "aws_api_gateway_integration.test",
    "aws_api_gateway_method.test",
  ]

  rest_api_id = "${aws_api_gateway_rest_api.test.id}"
  stage_name  = "api"

  # FIXME: https://github.com/hashicorp/terraform/issues/6613
  # Terraform has issues deploying API Gateways
  stage_description = <<EOF
${md5(file("terraform/api-gateway.tf"))},
EOF

  # FIXME: https://github.com/terraform-providers/terraform-provider-aws/issues/1607
  # terraform does currently support setting cache settings via the
  # aws_api_gateway_deployment resource so use a local provisioner instead
  provisioner "local-exec" {
    command = "aws apigateway update-stage --region ${var.region} --rest-api-id ${aws_api_gateway_rest_api.test.id} --patch-operations op=replace,path=/cacheClusterEnabled,value=true op=replace,path=/cacheClusterSize,value=0.5 --stage-name ${aws_api_gateway_deployment.authpoc.stage_name}"
  }
}

[alexclifford]

dudemcbacon's workaround is fine if you're happy not specifying a stage variable. The problem I have though is I really want to use a aws_api_gateway_stage resource because I want to customise the other cache and logging settings.

Then when you want to use a aws_api_gateway_method_settings resource it also wants stage_name, which then just leads to hardcoded stage names across your config because the deployment resource doesn't have an output for the name you give it!

The AWS API dependencies between deploy and stage resources is very weird and not fun to manage.

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[ghost]

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!