Install & Compatibility
Where this runs
tested against v1.1.5 · pip install
no network on importno background threads
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
muslpy 3.10–3.920 runs
installs and imports cleanly · install 0.0s · import 0.229s · 18.7MB
glibcpy 3.10–3.920 runs
installs and imports cleanly · install 1.7s · import 0.212s · 19MB
17MB installed
● package 17MB
Code
Verified usage
Verified import paths — ran on the pinned version, not inferred.
send, SUCCESS, FAILED
✓ from cfnresponse import send, SUCCESS, FAILED
✗ import cfnresponse
While 'import cfnresponse' is valid, directly importing `send`, `SUCCESS`, and `FAILED` is the idiomatic and common pattern for brevity.
This quickstart demonstrates a typical AWS Lambda handler function for a CloudFormation custom resource using cfnresponse. It handles 'Create', 'Update', and 'Delete' request types, sends a success or failure response back to CloudFormation, and includes basic error handling. The `physical_resource_id` is crucial for tracking the resource lifecycle.
import json
import cfnresponse
def handler(event, context):
print("Received event: " + json.dumps(event))
# Default to SUCCESS
status = cfnresponse.SUCCESS
reason = None
physical_resource_id = event.get('PhysicalResourceId', context.log_stream_name)
response_data = {}
try:
if event['RequestType'] == 'Create':
# Implement creation logic here
response_data['Message'] = 'Resource created successfully!'
# Often a unique ID for the resource is set as PhysicalResourceId
physical_resource_id = 'my-unique-resource-id'
elif event['RequestType'] == 'Update':
# Implement update logic here
response_data['Message'] = 'Resource updated successfully!'
elif event['RequestType'] == 'Delete':
# Implement deletion logic here
response_data['Message'] = 'Resource deleted successfully!'
except Exception as e:
status = cfnresponse.FAILED
reason = f'Lambda function failed: {str(e)}'
response_data['Error'] = str(e)
print(f"Error: {e}")
finally:
cfnresponse.send(event, context, status, response_data, physical_resource_id, reason=reason)
# Note: Any code after cfnresponse.send is generally not executed as the Lambda terminates.
Debug
Known issues
breakingThe underlying HTTP client for cfnresponse changed from `botocore.vendored.requests` to `urllib3` around April 2020. AWS Lambda environments stopped supporting the vendored `requests` by December 2021. Older Lambda functions using `cfnresponse` might fail if not updated.fixEnsure your Lambda function uses `cfnresponse` version 1.1.4 or higher. If deploying inline via `ZipFile`, CloudFormation automatically provides the updated module for current runtimes. For S3-deployed code, ensure you've bundled a recent `cfnresponse`.
affects: < 1.1.4 (cfnresponse), older Lambda runtimes
gotchaFailure to call `cfnresponse.send()` for any request type (Create, Update, Delete) will cause your CloudFormation stack operation to hang and eventually time out after a long delay (typically 1 hour).fixAlways ensure `cfnresponse.send()` is called exactly once in your Lambda handler, preferably within a `finally` block to guarantee execution even after errors. Include explicit handling for `RequestType == 'Delete'`.
affects: All versions
gotchaAny Python code placed after the `cfnresponse.send()` call will not be executed. The Lambda function terminates immediately after sending the response to CloudFormation.fixPlace all necessary logic before the `cfnresponse.send()` call. If cleanup or logging is required post-response, consider asynchronous methods or ensure it's handled before the final `send`.
affects: All versions
gotchaChanging the `PhysicalResourceId` between an `Update` request can cause CloudFormation to treat it as a resource replacement (deletion of old, creation of new) rather than an in-place modification, leading to unexpected behavior or data loss.fixThe `PhysicalResourceId` should be stable across updates for the same logical resource. For `Update` requests, reuse `event['PhysicalResourceId']`. Only generate a new `PhysicalResourceId` for `Create` requests.
affects: All versions
Errors
Common errors & fixes
Runtime.ImportModuleError: Unable to import module 'index': No module named 'cfnresponse'
The cfnresponse module is not found in the Lambda execution environment. This often happens if the Lambda function code is deployed from an S3 bucket without bundling `cfnresponse`, or if the Lambda runtime doesn't automatically include it (e.g., in newer Python versions if not deployed via inline ZipFile).
fixIf using a `ZipFile` property in CloudFormation, ensure your CloudFormation template explicitly sets the Lambda `Runtime` property to a supported Python version. If deploying from S3, you must package `cfnresponse` with your Lambda code or use a Lambda Layer. Verify the handler path (e.g., `index.handler`).
/var/task/botocore/vendored/requests/api.py:67: DeprecationWarning: You are using the put() function from 'botocore.vendored.requests'.
This warning indicates your Lambda function is using an older version of `cfnresponse` that relied on a deprecated vendored `requests` library within `botocore`. This dependency was removed, and newer AWS Lambda runtimes no longer support it.
fixUpdate your `cfnresponse` library to version 1.1.4 or newer. If deploying via `ZipFile` in CloudFormation, ensure your template's `Runtime` property is set to a recent Python version (e.g., `python3.9` or higher) to automatically pick up the latest `cfnresponse` version provided by AWS. If bundling manually, include the latest `cfnresponse`.
Upgrade
Version history
1.1.5latest on PyPI · released Aug 3, 2024
Audit
Dependencies
No dependency data recorded yet.