Hidden Resources to Consider When Removing an AWS Lambda Function

Martin D — Thu, 03 Sep 2026 17:52:30 +0000

Deleting an AWS Lambda function may look like a simple task, but the function itself can be connected to several AWS resources that remain in your account after the function is removed.

These leftover resources can create unnecessary costs, security concerns, operational confusion, and maintenance overhead.

As an AWS Cloud Developer or AWS Account Administrator, it is important to understand which resources should be reviewed before and after deleting a Lambda function.

1. IAM Roles and Policies

Many Lambda functions use a dedicated IAM role created specifically for their execution.

Deleting the Lambda function does not automatically delete its IAM role or associated policies. Over time, these unused roles can remain in the AWS account without anyone realizing they are no longer required.

Before removing the function, review:

Lambda execution IAM roles
Custom IAM policies attached to the role
Inline IAM policies
Permissions created specifically for the Lambda function

Unused IAM roles and policies should be reviewed carefully before deletion to avoid unnecessary security exposure and account clutter.

2. Amazon CloudWatch Log Groups

AWS Lambda automatically creates a CloudWatch Log Group using the following naming convention:

/aws/lambda/<function-name>

Deleting the Lambda function does not necessarily remove its CloudWatch Log Group.

As a result, logs may remain stored in Amazon CloudWatch for a long time and continue consuming storage.

Before completing the cleanup, check:

CloudWatch Log Groups
Log retention settings
Old log streams
Log storage costs

If the logs are no longer required for auditing, troubleshooting, or compliance purposes, consider deleting the log group or configuring an appropriate retention policy.

3. Elastic Network Interfaces (ENIs)

If your Lambda function is configured to access resources inside an Amazon VPC, AWS manages network interfaces associated with Lambda connectivity.

These resources may not disappear immediately after the Lambda function is deleted.

Depending on the configuration and AWS resource lifecycle, cleanup can take some time.

When removing a VPC-enabled Lambda function, review:

VPC configuration
Subnets
Security groups
Elastic Network Interfaces associated with Lambda

Do not immediately assume that an ENI is orphaned and delete it manually. Always verify whether it is still being used by another AWS-managed service or Lambda function.

4. Resource-Based Policies and Permissions

Lambda functions can have resource-based permissions that allow other AWS services or accounts to invoke them.

Examples include permissions for:

Amazon API Gateway
Amazon EventBridge
Amazon S3
Amazon SNS
Other AWS accounts

Before deleting a Lambda function, review the integrations and permissions associated with it.

Other AWS services may still contain references to the deleted Lambda ARN, which can result in failed events, broken integrations, or unnecessary troubleshooting later.

5. Event Sources and Triggers

One of the most important areas to review is the Lambda function's triggers.

A Lambda function may be invoked by:

Amazon API Gateway
Amazon EventBridge
Amazon S3
Amazon SNS
Amazon SQS
Amazon DynamoDB Streams
Amazon Kinesis
AWS Step Functions
Amazon CloudWatch scheduled rules

Before deletion, identify whether these services are still configured to invoke the Lambda function.

Removing the function without cleaning up the integration can leave behind failed invocations or unused configurations.

6. Lambda@Edge Replicas

If the Lambda function is associated with Amazon CloudFront as a Lambda@Edge function, additional considerations are required.

Lambda@Edge functions are replicated to AWS Regions as part of the CloudFront deployment process.

Before removing such a function, ensure that:

The function is no longer associated with any CloudFront distribution
CloudFront changes have been fully deployed
Lambda@Edge replicas have completed their lifecycle

These resources may require additional time to be fully removed.

7. Infrastructure as Code Resources

If the Lambda function was created using infrastructure-as-code tools such as:

AWS CloudFormation
AWS CDK
Terraform
Serverless Framework

Avoid manually deleting the Lambda function without first checking how it is managed.

Manual deletion can cause configuration drift between your AWS account and the infrastructure code.

Instead, where possible, remove the resource through the same infrastructure-as-code process that created it.

8. Monitoring, Alarms, and Dashboards

Lambda functions may have associated monitoring resources such as:

Amazon CloudWatch Alarms
CloudWatch Dashboards
AWS X-Ray tracing configuration
SNS notifications for alarms

After deleting the Lambda function, these monitoring resources may remain in the account.

Review and remove any alarms or dashboards that are no longer useful.

AWS Account Permissions Matter

Finally, it is important to understand that an AWS Cloud Developer or Cloud DevOps Engineer may not always have sufficient permissions to perform all cleanup activities.

For example, a developer may be able to delete a Lambda function but may not have permission to:

Delete IAM roles
Remove IAM policies
Delete VPC network interfaces
Modify CloudFront distributions
Delete CloudWatch Log Groups
Review account-wide resource dependencies

These activities may require additional IAM permissions or involvement from an AWS Account Administrator or Cloud Account Management team.

Therefore, managing AWS resources effectively is not only about having development or DevOps knowledge. It also requires:

Proper IAM access
Clear ownership of resources
Understanding of account-level dependencies
Defined cleanup procedures
Coordination between development, DevOps, security, and cloud administration teams

Why Documentation Is Important

Maintaining proper documentation for AWS resources is essential for effective account maintenance.

For every important application or Lambda function, documentation should ideally include:

Lambda function name and purpose
IAM role used
VPC and security group configuration
Event sources and triggers
CloudWatch Log Group details
Monitoring and alarms
Infrastructure-as-code repository or stack
Resource owner
Dependencies on other AWS services

This documentation makes future maintenance and cleanup activities much easier.

Final Thoughts

Deleting an AWS Lambda function should not be treated as simply clicking the Delete button.

A Lambda function can be connected to IAM roles, CloudWatch logs, VPC networking, event sources, monitoring resources, CloudFront distributions, and infrastructure-as-code deployments.

A proper cleanup process should therefore include a dependency review before deletion and a resource verification after deletion.

Maintaining an AWS resource inventory and clear documentation helps organizations control unnecessary costs, reduce security risks, avoid orphaned resources, and keep AWS account maintenance under control.

In AWS, deleting the main resource does not always mean the entire environment associated with that resource has been cleaned up.

When AWS Lambda Versioning Was Not Enough

Martin D — Sun, 08 Feb 2026 00:53:07 +0000

Postmortem: When AWS Lambda Versioning Was Not Enough

Summary

During a recent release, we ran into deployment and rollback challenges while relying on AWS Lambda versioning. While versioning worked well for changes limited to business logic, it broke down when changes involved Lambda layers and underlying architecture.

This postmortem documents what went wrong, why it happened, and how we fixed it.

Impact

Increased deployment risk during releases involving dependency changes
Inability to safely reuse existing Lambda versions
Rollbacks became unreliable due to layer incompatibility
Slower release cycles for architectural changes

No customer-facing outage occurred, but the risk of runtime failures increased.

What Changed

The release included changes to:

Lambda layers containing shared libraries
Dependency versions used across multiple functions
Runtime behavior dependent on updated layer code

Although the function interface remained unchanged, the underlying execution environment did not.

Expected Behavior

We expected AWS Lambda versioning to:

Support safe deployments
Allow rollbacks using Lambda aliases
Work for both code and dependency updates

This assumption proved incorrect.

Actual Behavior

AWS Lambda versioning creates immutable snapshots:

Each published version is permanently bound to specific layer versions
Published versions cannot be updated to reference new layer versions
Lambda aliases cannot compensate for architectural incompatibilities

As a result:

Updating layers required publishing new Lambda versions
Rollbacks could fail due to dependency mismatches
Versioning alone was insufficient for architecture-level changes

Root Cause

We treated AWS Lambda versioning as a full deployment lifecycle solution.

In reality, Lambda versioning is a code versioning mechanism, not an architecture versioning mechanism. The tight coupling between Lambda versions and Lambda layer versions was the core issue.

Resolution

We introduced a separate Lambda function to represent the new architecture:

New function name
New layer references
Independent deployment and testing
Gradual traffic migration via upstream services (API Gateway, EventBridge, SQS)

This approach restored deployment safety and rollback confidence.

Lessons Learned

Lambda versioning works best for business logic changes
Lambda layers introduce hidden coupling across versions
Architectural changes require architectural isolation
Rollbacks must consider dependency compatibility, not just code

Preventive Actions

Use Lambda versions only for logic-level changes
Create new Lambda functions for dependency or architecture changes
Limit shared logic in Lambda layers where possible
Add dependency impact analysis to release reviews
Document decision criteria: version vs new function

Final Takeaway

Serverless does not remove architectural responsibility. Knowing when to version and when to isolate is critical for building reliable, production-grade Lambda systems.

If this post helped you, feel free to share or discuss your own Lambda versioning experiences below.

DEV Community: Martin D