REST API Policy 'Resource' field value doesn't seem to take effect after an apply

Terraform Providers AWS
1

My problem involves what seems like a fairly trivial deploy of an API Gateway REST API. Everything about my deploy is very basic. The interesting bit, and where the problem seems to come in, involves the policy document I’ve attached.

resource "aws_api_gateway_rest_api_policy" "proxy" {
  rest_api_id = aws_api_gateway_rest_api.proxy.id
  policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
	{
        ....
        "Resource": "${aws_api_gateway_rest_api.proxy.execution_arn}/*/*"
	},
	{
        ....
        "Resource": "${aws_api_gateway_rest_api.proxy.execution_arn}/*/*",
	}
  ]
}
EOF
}

When I deploy my API and then try to access it, I get a “Forbidden” response. I’ve tried lots of different options as to just what I put in this policy, but nothing helps.

Here’s the interesting thing. When I look in the AWS Console, the policy looks right, but the API isn’t working. Then, I FORCE A REDEPLOY in the AWS Console, and the API starts working!

I’ve seen discussions of what I think is the same issue that I’m experiencing, like this:

terraform plan wants to modify api_gateway resource policy unnecessarily · Issue #15602 · hashicorp/terraform-provider-aws · GitHub

From reading the stuff on the net, I think I understand what is happening. The policy associated with an API is stored IN the API resource rather than being created separately and referred to by the API resource. So what is happening is that the policy in the current API object is first updated, and then that API resource is replaced with a new one that doesn’t contain the policy.

Attempts to access the endpoint fail because of this. Doing a manual deploy in the AWS API must update the policy in the API resource. Another side effect of this is that if you do an “apply” due to changes you’ve made, and then immediately do a second “apply”, Terraform always wants to make one small additional change in the second deploy. Unfortunately, that second deploy doesn’t fix the problem.

A suggestion of setting "Resource": "*" doesn’t help me although it seemed to help others.

It’s strange that all of the activity around this issue seems to have been about a year ago or earlier, as though the problem has been fixed. And yet, I’m using v1.3.2.

Any ideas?

2

I figured this out myself…sorta. Since nobody else seemed to be having this problem, I decided to ‘destroy’ my deployed resources and redeploy, thinking there was a chance that this was a fluke…a glitch in the matrix. That fixed the problem! When I first saw that, I was worried that the problem might return upon making updates to my infrastructure, but I’ve made all the same sorts of changes that I’d been making before, and so far (knock on wood), everything is working great. So the old adage applies here…when in doubt…REBOOT!