The ResourceDependencyException error occurs when Terraform tries to delete AWS Image Builder Components or Recipes that have dependent resources (like Image Pipelines) still referencing them. Terraform attempts to delete resources in the wrong order, causing AWS to reject the deletion. You must manually manage the deletion order or use workarounds.
The "ResourceDependencyException: Resource dependency error: The resource ARN has other resources depended on it" error in Terraform occurs when you attempt to delete or update AWS Image Builder resources that have dependencies on them. AWS Image Builder resources form a dependency chain: Image Pipelines depend on Image Recipes, which depend on Image Components. When you modify or delete any resource in this chain, AWS and Terraform must respect these dependencies. The root cause is that Terraform's AWS provider doesn't always manage the deletion order correctly. Starting from AWS provider version 5.74.0, Image Pipelines can now be updated in place rather than being destroyed and recreated. This means the pipeline continues to depend on the recipe while Terraform tries to replace or delete it, causing AWS to reject the operation with a ResourceDependencyException. In earlier provider versions, the entire dependency chain would be destroyed and recreated, automatically handling the ordering. Now with in-place updates, the dependency chain remains active during modifications, triggering this error.
First, verify which Image Builder resources depend on each other in your Terraform configuration:
# This structure creates a dependency chain:
# Pipeline -> Recipe -> Component
resource "aws_imagebuilder_component" "example" {
name = "my-component"
version = "1.0.0"
# ...
}
resource "aws_imagebuilder_image_recipe" "example" {
name = "my-recipe"
parent_image = "arn:aws:imagebuilder:..."
version = "1.0.0"
component_configuration {
component_arn = aws_imagebuilder_component.example.arn # Depends on component
}
}
resource "aws_imagebuilder_image_pipeline" "example" {
name = "my-pipeline"
image_recipe_arn = aws_imagebuilder_image_recipe.example.arn # Depends on recipe
# ...
}Check your state file to see all existing resources:
terraform state list | grep imagebuilder
terraform state show aws_imagebuilder_image_pipeline.exampleWhen you encounter ResourceDependencyException, manually taint the dependent resources in reverse order (Pipeline first, then Recipe, then Component):
# Taint the Pipeline first (so it gets recreated)
terraform taint aws_imagebuilder_image_pipeline.example
# Then apply - the Pipeline will be destroyed and recreated
terraform apply
# After the Pipeline is recreated successfully, then taint the Recipe
terraform taint aws_imagebuilder_image_recipe.example
# Apply again
terraform apply
# Only after Recipe succeeds, taint the Component if needed
terraform taint aws_imagebuilder_component.example
# Final apply
terraform applyThis forces Terraform to delete dependencies before their dependents, respecting AWS's requirements.
AWS Image Builder uses versioning instead of replacement. When you need to update a Component or Recipe, increment the version instead of letting Terraform replace it:
# Instead of changing a property that forces replacement:
# OLD (causes replacement)
resource "aws_imagebuilder_component" "example" {
name = "my-component"
version = "1.0.0" # Don't change this
data = "..." # Changing this forces replacement
}
# NEW (creates a new version)
resource "aws_imagebuilder_component" "example" {
name = "my-component"
version = "1.0.1" # Increment version instead
data = "..." # Updated content
}
# Then update the Recipe to reference the new Component version:
resource "aws_imagebuilder_image_recipe" "example" {
name = "my-recipe"
version = "1.0.1" # Increment recipe version too
component_configuration {
component_arn = aws_imagebuilder_component.example.arn
}
}
# Finally, let the Pipeline update in-place
resource "aws_imagebuilder_image_pipeline" "example" {
# The Pipeline can stay the same - it just points to the new Recipe version
image_recipe_arn = aws_imagebuilder_image_recipe.example.arn
}By incrementing versions, you avoid forcing resource replacement, which sidesteps the dependency issue entirely.
As a temporary workaround, use ignore_changes to prevent Terraform from trying to update the Recipe when the Component changes:
resource "aws_imagebuilder_image_recipe" "example" {
name = "my-recipe"
parent_image = "arn:aws:imagebuilder:..."
version = "1.0.0"
component_configuration {
component_arn = aws_imagebuilder_component.example.arn
}
# Prevent automatic updates that trigger dependency errors
lifecycle {
ignore_changes = [component_configuration]
}
}Warning: This is a workaround, not a permanent solution. You'll need to manually manage Recipe versions when Components change.
If you must delete Image Builder resources, do so in reverse dependency order:
# Order: Pipeline -> Recipe -> Component
# Step 1: Delete all Pipelines first
terraform destroy -target=aws_imagebuilder_image_pipeline.example
# Step 2: After Pipeline is deleted, delete Recipes
terraform destroy -target=aws_imagebuilder_image_recipe.example
# Step 3: Finally, delete Components
terraform destroy -target=aws_imagebuilder_component.example
# Or destroy everything (should now work in correct order)
terraform destroyDestroying in this order allows AWS to cleanly remove the resources without dependency conflicts.
Add skip_destroy = true to Image Builder Components to prevent Terraform from trying to delete them:
resource "aws_imagebuilder_component" "example" {
name = "my-component"
version = "1.0.0"
data = "..."
# Skip deletion during terraform destroy
lifecycle {
create_before_destroy = true
}
}This prevents Terraform from attempting to delete the component, which avoids triggering the ResourceDependencyException. However, manually clean up components in the AWS console afterward.
Ensure you're using the latest version of the AWS Terraform provider, as bug fixes may have been applied:
# In terraform.tf or versions.tf
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.76" # Use latest stable version
}
}
}Then update your local provider:
terraform init -upgrade
# Verify the new version
terraform versionCheck the [AWS provider changelog](https://github.com/hashicorp/terraform-provider-aws/releases) for fixes related to Image Builder resource ordering.
### AWS Image Builder Resource Dependency Chain
AWS Image Builder resources form a strict dependency hierarchy:
Image Component (lowest dependency)
↓
Image Recipe (depends on Components)
↓
Image Pipeline (depends on Recipes)
↓
Image (output of Pipeline)When modifying this chain:
1. Changes to Components require Recipe version bump
2. Changes to Recipes require Pipeline update or recreation
3. Pipeline changes trigger Image builds
### Why Versioning Matters
AWS Image Builder uses immutable versioning to prevent conflicts:
ComponentA:1.0.0 → ComponentA:1.0.1 (new version, old version still exists)
RecipeA:1.0.0 → RecipeA:1.0.1 (new version, old version still exists)This allows multiple resources to depend on different versions simultaneously, preventing dependency conflicts.
### Terraform State and Image Builder
Image Builder resources in your Terraform state may not reflect all versions in AWS:
# Check what Terraform knows about
terraform state show aws_imagebuilder_component.example
# What actually exists in AWS (may have more versions)
aws imagebuilder list-components --owner=SELF
# Reconcile by refreshing state
terraform refresh### Provider Version Impact
The ResourceDependencyException became more common starting with AWS provider 5.74.0 because:
- Before 5.74.0: Pipelines were force-replaced when Recipes changed (brute force, but reliable)
- After 5.74.0: Pipelines are updated in-place (more efficient, but triggers dependency errors)
If upgrading isn't an option, consider pinning an older provider version:
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.73" # Pin to earlier version if needed
}
}
}### GitHub Issues and Tracking
This is a known issue with multiple open tickets:
- [Issue #22127](https://github.com/hashicorp/terraform-provider-aws/issues/22127) - Original report
- [Issue #39985](https://github.com/hashicorp/terraform-provider-aws/issues/39985) - Regression in 5.74.0
- [Issue #40128](https://github.com/hashicorp/terraform-provider-aws/issues/40128) - Recent reports
Check these issues for updates and workarounds from the Terraform community.
### Monitoring Image Builder Resources
Create a simple script to monitor your Image Builder state:
#!/bin/bash
# Monitor Image Builder resources
PROFILE=${1:-default}
echo "=== Components ==="
aws imagebuilder list-components --owner=SELF --profile=$PROFILE \
--query 'componentVersionList[*].[name,version,state.status]' \
--output table
echo "\n=== Recipes ==="
aws imagebuilder list-image-recipes --owner=SELF --profile=$PROFILE \
--query 'imageRecipeSummaryList[*].[name,version,state.status]' \
--output table
echo "\n=== Pipelines ==="
aws imagebuilder list-image-pipelines --profile=$PROFILE \
--query 'imagePipelineList[*].[name,infrastructureConfigurationArn]' \
--output tableError: Error installing helm release: cannot re-use a name that is still in use
How to fix "release name in use" error in Terraform with Helm
Error: Error creating GKE Cluster: BadRequest
BadRequest error creating GKE cluster in Terraform
Error: External program failed to produce valid JSON
External program failed to produce valid JSON
Error: Unsupported argument in child module call
How to fix "Unsupported argument in child module call" in Terraform
Error: network is unreachable
How to fix "network is unreachable" in Terraform