ResourceNotFoundException
AWS ResourceNotFoundException means the target resource cannot be resolved by that service in the current account, region, partition, endpoint, lifecycle state, or caller-visible scope.
Last reviewed: May 5, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Resource Not Found Exception Mean?
The request reached AWS, but the service could not find the referenced resource in the scope used by the call. This is not automatically proof that the resource never existed. The useful boundary is resolution scope: resource ID or ARN, account, region, partition, endpoint, recently created/deleted lifecycle state, and whether the runtime config is still pointing at an old deployment output.
Common Causes
- -Resource identifier, ARN, name, or version does not match an existing resource for the target service.
- -Request is sent to the wrong account, region, partition, endpoint, or tenant-like service scope.
- -Resource was deleted, replaced, renamed, recreated with a new physical ID, or is still converging after create.
- -Application config, parameter store, secret, queue message, or IaC output contains a stale identifier.
- -Automation treats not-found as permission failure and changes IAM before proving the resource scope.
How to Fix Resource Not Found Exception
- 1Validate the exact ARN, ID, name, version, or key against service inventory in the same account and region.
- 2Confirm caller identity, partition, and endpoint region before changing code or IAM.
- 3Compare runtime config values with the latest IaC outputs or deployment artifacts.
- 4Use service-specific
Get,List, orDescribeAPIs to verify existence and readiness state. - 5Retry only when a recent create/update may still be propagating; otherwise repair the reference.
Step-by-Step Diagnosis for Resource Not Found Exception
- 1Capture request ID, service action, full resource identifier, caller account, partition, endpoint, and region from the failing call.
- 2Correlate CloudTrail create, update, delete, replace, tag, and permission events around the failure window.
- 3Compare IaC state, deployment outputs, environment variables, Parameter Store, Secrets Manager, and app runtime config for drift.
- 4Check whether the resource is pending, deleting, failed, replaced, or not yet visible to the dependent API.
- 5Verify the service uses regional, global, account-local, or parent-resource-local name resolution before retrying.
Seen in Production
- -A Lambda function reads an old table ARN from Parameter Store after Terraform replaced the table.
- -A deploy script calls a regional API in
eu-west-1while the resource exists only inus-east-1. - -A dependent workflow starts immediately after create and reads before the service reports ACTIVE or ready.
- -A queue message contains a physical resource ID from the previous blue/green environment.
Identifier Scope Validation
- -Verify ARN, ID, name, version, and parent scope against the same account, region, partition, and endpoint as the failing call.
- -Inspect runtime config sources for stale IDs after deploy, replacement, restore, or blue/green cutover.
Lifecycle and Propagation Checks
- -Audit create, delete, replace, and restore timelines with service-specific readiness states.
- -Confirm dependency ordering between provisioning, output publication, app rollout, and first use.
Decision Shortcut: Missing, Wrong Scope, or Not Ready
- -If inventory lookup fails in every expected scope, treat it as a genuinely missing or deleted resource.
- -If lookup succeeds in another region, account, partition, or parent scope, fix endpoint and config routing.
- -If the resource exists but is not ready, add readiness gates instead of changing identifiers.
Wrong Fix to Avoid
- -Do not broaden IAM permissions before verifying the resource exists in the request scope.
- -Do not hard-code a newly discovered ID into application config without fixing the output pipeline.
- -Do not retry forever when CloudTrail shows the resource was deleted or replaced.
Implementation Examples
2026-05-05T11:25:18Z service=dynamodb action=DescribeTable
configuredTableArn=arn:aws:dynamodb:us-east-1:111122223333:table/orders-blue
activeDeployment=orders-green status=400 error=ResourceNotFoundException
requestId=3f9f0b6a-1111-4444-9999-778ab9000000aws sts get-caller-identity
aws configure get region
aws dynamodb describe-table \
--table-name "$TABLE_NAME" \
--region "$AWS_REGION"aws ssm get-parameter --name /prod/orders/table-name --query 'Parameter.Value' --output text
aws cloudformation describe-stacks \
--stack-name prod-orders \
--query "Stacks[0].Outputs[?OutputKey=='OrdersTableName'].OutputValue" \
--output textIncident Timeline
11:24 UTC
Runtime loads a resource reference
Signal: Application reads an ARN, ID, name, version, or endpoint from config, queue payload, or deployment output.
Why it matters: The reference source matters as much as the AWS error response.
11:25 UTC
AWS returns ResourceNotFoundException
Signal: The service cannot resolve that reference in the active request scope.
Why it matters: Start with scope and lifecycle evidence, not permission changes.
11:31 UTC
Reference drift is isolated
Signal: Inventory and CloudTrail show wrong region, stale physical ID, replacement event, or readiness lag.
Why it matters: Repair the reference producer or readiness gate so the same drift does not recur.
11:44 UTC
Runtime and deploy outputs converge
Signal: The application resolves the current resource in the correct scope and dependent calls succeed.
Why it matters: Config propagation should be verified before traffic reaches the new deployment.
Seen in Production
Environment points to a different region/account than the resource
Frequency: common
Example: A valid ARN exists in one region, but API call is made to another region and returns ResourceNotFoundException.
Fix: Normalize endpoint/account selection and validate scope before request dispatch.
Freshly created resource is queried before service readiness is complete
Frequency: rare
Example: Immediately after create, dependent call fails until control-plane propagation completes.
Fix: Add readiness polling and bounded retries for eventual-consistency windows.
Wrong Fix vs Better Fix
IAM change vs scope validation
Wrong fix: Grant broader permissions because the resource lookup failed.
Better fix: Confirm account, region, partition, endpoint, and inventory existence first.
Why this is better: A not-found response is often stale scope or lifecycle drift, not authorization.
Manual ID patch vs output pipeline repair
Wrong fix: Patch the current resource ID in one environment variable.
Better fix: Fix the deployment output, config publication, or service discovery source.
Why this is better: Manual patches break again on the next replace, restore, or blue/green cutover.
Blind retry vs readiness gate
Wrong fix: Retry every missing resource for minutes.
Better fix: Retry only during documented convergence windows and gate on service readiness state.
Why this is better: Deleted or wrong-scope resources never become available through retry.
Debugging Tools
- -Service-specific Get/List/Describe APIs
- -CloudTrail lifecycle event correlation
- -IaC output vs runtime config diff
- -sts:GetCallerIdentity and endpoint-region validation
How to Verify the Fix
- -Re-run the same service operation and confirm ResourceNotFoundException no longer appears.
- -Validate dependent workflows complete with the corrected resource reference.
- -Confirm resource lookup error rates return to baseline.
- -Confirm runtime config and IaC outputs resolve to the same current physical resource.
How to Prevent Recurrence
- -Use dynamic discovery or deployment outputs instead of hard-coded resource IDs in application configs.
- -Add readiness/state checks between resource creation and dependent operations.
- -Continuously detect identifier drift between IaC state and runtime configuration.
- -Publish immutable deployment manifests and block rollout when app config references old resource IDs.
Pro Tip
- -emit immutable resource references from deploy pipelines and block app rollout when runtime-resolved IDs do not match those artifacts.
Decision Support
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.