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.
Top comments (0)