ResourceConflictException
AWS ResourceConflictException is a deployment-time error that occurs when a Lambda function is already undergoing an update, deployment, or state transition. AWS serializes configuration changes, meaning a second update will be rejected if the first is still in progress.
Last reviewed: March 16, 2026|Editorial standard: source-backed technical guidance
What Does Resource Conflict Mean?
This exception indicates a state conflict. Lambda requires functions to be in a terminal state (Active/Successful) before accepting new configuration or code changes. If you trigger multiple updates in parallel (e.g., updating Environment Variables and Code at the same time), the second request will be rejected with a 409-style conflict because the function's "LastUpdateStatus" is still "InProgress".
Common Causes
- -Concurrent Pipeline Runs: Two developers merge PRs simultaneously, triggering two GitHub Actions or GitLab jobs that try to update the same Lambda ARN at once.
- -Parallel API Calls: A deployment script using
Promise.all()to callUpdateFunctionCodeandUpdateFunctionConfigurationsimultaneously. - -Pending State After Creation: Attempting to update or publish a version of a Lambda immediately after its creation before it has transitioned from
PendingtoActive. - -Slow Propagation: Large Lambda layers or complex VPC configurations taking longer to "settle," blocking subsequent updates.
How to Fix Resource Conflict
- 1Check Status Before Update: Always query
GetFunctionConfigurationand proceed only ifLastUpdateStatusisSuccessful. - 2Sequence Your Updates: If you need to change both code and config, update the code first, wait for completion, then update the config.
- 3Implement Pipeline Serialization: Configure your CI/CD tool (GitHub concurrency groups, Jenkins locks) to ensure only one deployment job runs per function.
- 4Use AWS SDK Waiters: Leverage built-in helpers like
wait_until_function_activeorwait_until_function_updatedto handle polling automatically.
Step-by-Step Diagnosis for Resource Conflict
- 1Run
aws lambda get-function-configurationand check theLastUpdateStatus. If it saysInProgress, you are in a conflict state. - 2Inspect CloudTrail logs for overlapping
UpdateFunctionAPI calls within a 60-second window. - 3Audit your CI/CD logs for parallel job executions targeting the same environment.
- 4Check the
LastUpdateStatusReasonto see if a specific infrastructure change (like VPC attaching) is causing an extended "InProgress" state.
Lambda State Machine Audit
- -Pending: Function is being created or initialized. Updates are NOT allowed.
- -Active: Function is ready. Updates ARE allowed.
- -InProgress: An update is currently propagating. New updates ARE rejected.
- -Failed: The last update failed. Manual intervention or a fresh update is required.
CI/CD Concurrency Control
- -GitHub Actions: Use
concurrency: group-nameto cancel or queue overlapping runs. - -Terraform: Use
depends_onor manual locks if using multiple modules that update the same resource.
Implementation Examples
import { LambdaClient, waitUntilFunctionUpdated, UpdateFunctionCodeCommand } from "@aws-sdk/client-lambda";
const client = new LambdaClient({ region: "us-east-1" });
async function safeDeploy(functionName, zipFile) {
// 1. Trigger update
await client.send(new UpdateFunctionCodeCommand({ FunctionName: functionName, ZipFile: zipFile }));
// 2. Use the built-in waiter to prevent ResourceConflictException for the next step
console.log("Waiting for update to propagate...");
await waitUntilFunctionUpdated({ client, maxWaitTime: 60 }, { FunctionName: functionName });
console.log("Deployment Successful. Ready for next update.");
}STATUS=$(aws lambda get-function-configuration --function-name my-func --query 'LastUpdateStatus' --output text)
if [ "$STATUS" == "InProgress" ]; then
echo "Conflict detected! Waiting for previous update..."
aws lambda wait function-updated --function-name my-func
fi
# Now it's safe to update
aws lambda update-function-code --function-name my-func ...How to Verify the Fix
- -Trigger two simultaneous updates and confirm the second one now waits for the first to reach "Successful" status.
- -Verify that
LastUpdateStatusreaches "Successful" in CloudWatch/CloudTrail after every deployment. - -Confirm the Lambda function code and configuration match the latest intended version in the AWS Console.
How to Prevent Recurrence
- -Always use Waiters: Never write a deployment script that "assumes" a function is ready. Always poll or wait.
- -Versioned Deployments: Use Lambda Aliases and Versions. This reduces the need to update the same "Live" ARN repeatedly in a way that causes conflicts.
- -Infrastructure as Code (IaC): Use CDK or SAM, which have built-in state management and retry logic for ResourceConflictExceptions.
- -Pro-tip: The "wait_until_active" waiter is your best friend when creating functions via script-it eliminates the 409 error that happens when you try to use a function 0.5 seconds after creation.
Decision Support
Compare Guide
409 Conflict vs 412 Precondition Failed: When to Use Each
Choose 412 when If-Match or If-Unmodified-Since checks fail; choose 409 for state conflicts without failed precondition headers during concurrent updates.
Playbook
Conflict and Concurrency Playbook (409 / 412 / OptimisticLock)
Use this playbook to separate true write conflicts from stale precondition failures, then apply safe re-fetch, optimistic-lock, and retry choices.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.