guidance for self healing code on aws
1.0.0
Any customer that creates software inevitably has bugs, but at the same time, often must compete with product and feature development pressure, which often pushes them to de-prioritize addressing bugs. These bugs can distract developers' focus, degrade user experience and cause misleading metrics about the user experience. Even if customers prioritize fixing bugs, this often requires business investment in the form of experience/skilled engineers to dedicate a large amount of time and focus in understanding and fixing bugs.
This repo contains an end to end system which combines Amazon CloudWatch, AWS Lambda, and Amazon Bedrock to create an end-to-end system which automatically detects and fixes bugs to enhance application reliability and the overall customer experience. The Log Driven Bug Fixer hooks into an application's Amazon CloudWatch Logs log group via an AWS Lambda subscription. Any logs containing application errors are sent for processing; where a Lambda function creates a prompt, including the stack trace and relevant code files, and then sends it to Amazon Bedrock (Claude v1) to generate code fixes. The modified code is then pushed into source control (git) and creates a pull request for review and deployment.
The following table provides a sample cost breakdown for deploying this Guidance with the default parameters in the US East (N. Virginia) Region for one month.
| AWS service | Dimensions | Monthly cost [USD] |
|---|---|---|
| Amazon DynamoDB | Average item size 0.5kb, 0.5 RCU and 1 WCU per message | $ 17.08 |
| Amazon CloudWatch | 33kb of logs written and stored per message | $ 8.77 |
| AWS Lambda | 45 seconds execution time per unique error message | $ 2.43 |
| Amazon SQS | 3 requests per message, 1k message size | $ 0.01 |
| Amazon Bedrock | 1,000 input tokens, 1,000 output tokens | $ 32.00 |
| Total | $ 60.29 |
This solution supports build environments in Mac or Linux.
This deployment requires that you have access to the following AWS services:
These deployment instructions are optimized to best work on Mac or Amazon Linux 2023. Deployment in another OS may require additional steps.
Gather following information about your existing application as these are inputs needed to configure the solution
Clone the repo using command git clone https://github.com/aws-solutions-library-samples/guidance-for-self-healing-code-on-aws.git
cd to the repo folder cd guidance-for-self-healing-code-on-aws
Install packages in requirements using command pip install -r requirement.txt
Export the required environment variables:
# CloudFormation stack name.
export STACK_NAME=self-healing-code
# S3 bucket to store zipped Lambda function code for deployments.
# Note: the S3 bucket must be in the same region as the CloudFormation stack deployment region.
export DEPLOYMENT_S3_BUCKET=<NAME OF YOUR S3 BUCKET>
# All variables and secrets for this project will be stored under this prefix.
# You can define a different value if it's already in use.
export PARAMETER_STORE_PREFIX=/${STACK_NAME}/
pip3 install -r requirements.txt
# Follow the resulting series of prompts to store configuration details in SSM Parameter Store. This steps will use information gathered during Step 1
python3 bin/configure.py
Re-run the above script if you need to make any changes. Alternatively, you can directly modify the SSM Parameter Store values which are stored under the ${PARAMETER_STORE_PREFIX} prefix.
# Create a deployment package (Lambda function source code)
cloudformation/package.sh
# Deploy the CloudFormation template
cloudformation/deploy.sh
Open CloudFormation console and verify the status of the template with the name of the stack specified in step 4 of the deployment steps.
Upon receiving a Python stack trace in your application's Amazon CloudWatch log group configured in Step 6, a pull request will be created in the source control system. Note that processing can take several minutes to complete. If you want a quick validation of the solution, you can inject an error into your existing application which can result in a python stack trace in your application's logs
Example output pull request in Github:
This guidance is a sample project which targets Python 3.9+ code bases. There are further opportunities to extend and enhance this system. Some suggested next steps:
src/handlers/providers to refine responses from LLM'ssrc/handlers/source_code.py)src/providers/source_code.py)aws cloudformation delete-stack --stack-name ${STACK_NAME}
aws ssm delete-parameters-by-path --path ${PARAMETER_STORE_PREFIX}
Customers are responsible for making their own independent assessment of the information in this Guidance. This Guidance: (a) is for informational purposes only, (b) represents AWS current product offerings and practices, which are subject to change without notice, and (c) does not create any commitments or assurances from AWS and its affiliates, suppliers or licensors. AWS products or services are provided “as is” without warranties, representations, or conditions of any kind, whether express or implied. AWS responsibilities and liabilities to its customers are controlled by AWS agreements, and this Guidance is not part of, nor does it modify, any agreement between AWS and its customers.
