Sometimes Terraform starts creating a resource, and the deployment spends several minutes showing:
module.export_api_waf.aws_wafv2_web_acl_association.api_association: Still creating... [09m40s elapsed]
module.export_api_waf.aws_wafv2_web_acl_association.api_association: Still creating... [09m50s elapsed]
module.export_api_waf.aws_wafv2_web_acl_association.api_association: Still creating... [10m00s elapsed]
module.export_api_waf.aws_wafv2_web_acl_association.api_association: Still creating... [10m10s elapsed]That does not necessarily mean something is broken, rather database creation, service updates, and cloud configuration changes can take time. The problem is we are not sure how long is long enough to wait.
For resources that support it, we can configure an operation timeout by using timeouts nested block:
timeouts {
create = "20m"
}What does a timeout actually do?
A resource timeout controls how much time the provider allows for a particular operation before giving up. Example above allows up to 20 minutes for the creation operation.
However it does not make Terraform wait for 20 minutes every time. If the operation succeeds after 40 seconds, Terraform continues immediately.
It also does not configure the timeout for the entire terraform apply. It applies to the operation only on that resource.
Timeout support is implemented by the provider. The provider decides which operations support configurable timeouts and how those values are used. HashiCorp’s Plugin Framework timeout documentation explains this from the provider developer’s perspective.
Example: attaching WAF to API Gateway
I recently added an AWS WAF Web ACL to an existing API Gateway. The configuration created the Web ACL and connected it to the API stage:
resource "aws_wafv2_web_acl_association" "api" {
resource_arn = module.api.stage_arn
web_acl_arn = aws_wafv2_web_acl.this.arn
}The Web ACL was created successfully, but the association kept retrying and eventually failed:
WAFUnavailableEntityException:
AWS WAF couldn’t retrieve the resource
that you requested. Retry your request.I have checked AWS Console and resource already existed so after generating a fresh plan and applying again, the association succeeded without any code changes. The same configuration later worked on the first attempt in another environment.
This suggested a temporary propagation delay. Resource propagation is simply the time it takes for a new or updated resource to become available across cloud that need to use it.
AWS documents that WAF changes can take seconds to minutes to become available, and a newly created Web ACL may initially be unavailable for association.
The distinction is useful: AWS can finish creating a resource before that resource is available to every operation that needs it.
Why depends_on would not solve this
The association already references the Web ACL and the API stage. Those references give Terraform the dependencies it needs. Terraform therefore waits for their creation operations to complete before starting the association. Adding another depends_on would not change the fact that AWS may still be propagating the newly created resource.
Dependencies control the order of operations meaning they do not control AWS propagation time.
Giving the existing retry mechanism more time
Terraform called the AWS AssociateWebACL API to attach the Web ACL to the API Gateway stage. AWS kept returning WAFUnavailableEntityException, so the provider retried until its 10-minute creation timeout was reached. See the highlighted line on the image below:
If this temporary failure happens repeatedly, one option is to increase the timeout on the association resource:
resource "aws_wafv2_web_acl_association" "api_association" {
resource_arn = var.api_stage_arn
web_acl_arn = aws_wafv2_web_acl.this.arn
timeouts {
create = "20m"
}
}This gives the existing retry mechanism more time. If the resource becomes available within the extended window, the association can complete during the same apply.
The override belongs on aws_wafv2_web_acl_association because that is the operation that failed. Increasing the timeout on the Web ACL resource itself would affect a different operation.
If the association is inside a reusable module, place the block on that resource inside the module. You can expose the duration as a module variable if different callers need different settings.
The timeout does not make every error retryable. An incorrect ARN or missing permissions can still cause an immediate failure. The provider’s implementation determines which errors it retries.
In my case, the next apply succeeded without changing the timeout; increasing it remains an option if the delay happens again.
