Introduction

SAM stacks are CloudFormation stacks. That means the template is supposed to be the source of truth for your Lambda function and its related resources. If you manually delete the function in the Lambda console, you create drift between the real AWS state and the state CloudFormation still believes it manages.

Why the Error Appears

CloudFormation tracks resources by logical IDs from the template and physical resources in AWS. Manual deletion removes the physical Lambda function, but the stack still has a record that it should exist.

From that point on:

• stack updates may try to modify a function that no longer exists
• rollback may try to restore previous configuration against a missing resource
• delete operations may fail because dependent resources still reference the missing function

That is why "function not found" often appears only on the next deploy or rollback, not at the moment you delete the function manually.

First Recovery Step: Try a Normal SAM Redeploy

If the stack is still in a normal updatable state and the function is still present in template.yaml, the cleanest recovery is often to redeploy the application. CloudFormation will attempt to bring reality back in line with the template.

cd /path/to/sam-app
sam build
sam deploy --stack-name my-sam-stack

This usually works best when the function name is predictable and the stack is not already stuck in a rollback failure.

When Redeploy Is Not Enough

Sometimes the stack is already in a failed state such as UPDATE_ROLLBACK_FAILED. In that situation, a simple sam deploy may not proceed because CloudFormation cannot finish reconciling the broken resource graph.

AWS's CloudFormation recovery guidance is important here: if a resource was manually deleted and rollback expects it to exist, you may need to recreate that resource manually with the same properties so rollback has something to work against.

For a Lambda function, that can mean restoring:

• the same function name
• the same runtime and handler
• the same execution role
• any permissions or event source mappings the stack expects

The goal is not to keep the manual resource forever. The goal is to give CloudFormation a consistent target again so it can finish the stack operation.

Inspect the Stack Events

Do not guess at the failure. Inspect the CloudFormation stack events first:

aws cloudformation describe-stack-events \
  --stack-name my-sam-stack

Look for:

• the logical ID of the missing Lambda resource
• related AWS::Lambda::Permission failures
• API Gateway, EventBridge, or SQS mappings that still reference the deleted function
• whether the stack is in update failure, rollback failure, or delete failure

That event history tells you whether a redeploy is enough or whether you need manual repair first.

Continuing a Failed Rollback

After restoring the missing resource or fixing the root issue, you can continue the rollback:

aws cloudformation continue-update-rollback \
  --stack-name my-sam-stack

CloudFormation also allows ResourcesToSkip during rollback recovery, but that should be a last resort. Skipping resources can leave the stack and the actual infrastructure out of sync, which you still have to clean up afterward.

Preventing the Problem

The durable fix is operational discipline:

• manage Lambda resources through sam deploy or CloudFormation updates
• avoid deleting stack-managed functions directly in the console
• run drift detection when the stack behavior looks inconsistent
• remove resources by editing the SAM template and deploying the change

If you want a function gone, delete it from the template and let CloudFormation own the deletion process.

Common Pitfalls

The biggest mistake is manual deletion followed by repeated redeploy attempts without checking stack state. If the stack is already in UPDATE_ROLLBACK_FAILED, blindly redeploying usually wastes time.

Another mistake is recreating the function with the wrong name or incomplete configuration. CloudFormation may still fail if the physical resource does not match what the stack expects.

People also forget dependent resources. A missing Lambda permission or event source mapping can keep the stack broken even after the function itself has been recreated.

Finally, do not use rollback skipping casually. It is a recovery tool, not a normal repair strategy.

Summary

• Manually deleting a Lambda function from a SAM stack creates CloudFormation drift.
• If the stack is still healthy enough, sam build and sam deploy may recreate the function.
• If rollback is already broken, you may need to restore the missing function and then continue rollback.
• Always inspect CloudFormation stack events before choosing a recovery path.
• The long-term fix is to manage stack resources only through SAM or CloudFormation.