Introduction

Duplicating an AWS Lambda function usually means creating a new function that uses the same code package and nearly the same configuration as an existing one. Teams do this when they need a staging copy, a regional variant, a backup, or a new function that starts from an existing implementation.

There is no magical "clone everything" button at the platform level, so the process is usually: inspect the source function, copy the code package, and recreate the important configuration on the destination function.

What Needs To Be Copied

A Lambda function is more than just source code. A practical duplicate often needs:

• the deployment package or image reference
• runtime settings such as memory and timeout
• environment variables
• execution role
• VPC settings if used
• layers and architecture settings

The safest mindset is that you are reproducing a function definition, not just copying files.

CLI-Based Workflow

A straightforward AWS CLI workflow starts by retrieving the configuration:

aws lambda get-function-configuration --function-name source-function

If the function uses a ZIP deployment package, you can also get information about the code location:

aws lambda get-function --function-name source-function

Then create the new function with the relevant configuration values:

1aws lambda create-function \
2  --function-name copied-function \
3  --runtime python3.12 \
4  --role arn:aws:iam::123456789012:role/lambda-exec-role \
5  --handler app.handler \
6  --zip-file fileb://function.zip

If the source function already exists in your local project or deployment pipeline, it is usually easier to redeploy from source than to download and re-upload the packaged artifact manually.

Copying Configuration Carefully

Not every setting should be copied blindly. For example, a staging copy may need different environment variables, a different IAM role, or different event sources.

That means the practical duplication flow is often:

1. copy the code package
2. copy the safe baseline settings
3. intentionally change environment-specific values
4. reattach triggers only if the new function should process real traffic

This prevents the duplicate from accidentally consuming production events or using the wrong secrets. It also keeps the duplicate from inheriting alarms, destinations, or schedules that were meant only for the original function.

Infrastructure As Code Is Better For Repeatability

If function duplication is a recurring task, the better long-term answer is usually infrastructure as code through CloudFormation, SAM, Terraform, or CDK. With IaC, you do not really duplicate the function manually. You parameterize the definition and deploy another instance of it.

That is cleaner, safer, and easier to version-control than repeating console steps by hand.

Common Pitfalls

The biggest mistake is copying code without copying the execution context that makes the function work. Missing environment variables, missing layers, or the wrong IAM role can make the duplicate fail immediately.

Another pitfall is duplicating event triggers unintentionally. If the new function is connected to the same queue, stream, or API route as the original, you may create double-processing or unexpected production traffic.

A third issue is assuming the duplicate should be identical forever. In many cases you want a near-copy as a starting point, not a permanent configuration mirror.

Summary

• Duplicating a Lambda function means copying both code and the important runtime configuration.
• AWS CLI can inspect the source function and create a new function from the copied settings.
• Be deliberate about environment variables, IAM roles, and triggers.
• Avoid reconnecting event sources automatically unless the new function should handle real traffic.
• For repeated duplication, infrastructure as code is usually the better long-term approach.