Define an Amazon Bedrock managed prompt and a published version in AWS CloudFormation and invoke it from AWS Lambda through Converse.
Teams building on Amazon Bedrock often hardcode prompt text inside their application code. Changing a prompt then means a code change and a redeploy, and there is no built-in versioning or rollback. Amazon Bedrock Prompt Management solves this by storing prompts as managed, versioned resources, and this pattern shows how to define and invoke them entirely as infrastructure as code.
The pattern defines two native AWS CloudFormation resources: an AWS::Bedrock::Prompt (the prompt template, its input variables, the target model, and inference settings) and an AWS::Bedrock::PromptVersion (an immutable published version of that prompt). Because the prompt lives in Amazon Bedrock rather than in the function, prompt authors can iterate on wording independently of the application code.
At runtime, an AWS Lambda function calls the Amazon Bedrock Converse API and passes the prompt version ARN as the modelId, along with promptVariables for the template placeholders. Converse recognizes the ARN, renders the managed prompt with those values, and runs it against the model configured on the prompt variant, returning the result. The function contains no prompt text at all, only the version ARN it was given.
To change the prompt, you publish a new version in Amazon Bedrock and repoint the function to that version ARN (a configuration value, not code). Rolling back is just pointing at an older version. Invoking a pinned, immutable version keeps production behavior deterministic while still allowing safe iteration, the same idea as feature flags applied to generative AI prompts.
IAM permissions follow least privilege: the function may call bedrock:RenderPrompt, the action Converse checks for a prompt resource, only on this prompt and its versions, plus bedrock:InvokeModel on the model the prompt variant targets. The target model is a template parameter, so the same pattern works with any Converse-compatible Amazon Bedrock model or cross-Region inference profile. Good use cases include support and FAQ assistants, summarization and classification, and any workload where prompts must be iterated, versioned, or rolled back without redeploying application code.
< Back to all patterns
Clone repo
git clone https://github.com/aws-samples/serverless-patterns/cd serverless-patterns/bedrock-prompt-management-lambda/python/samDeploy
sam buildsam deploy --guidedTesting
Invoke the AWS Lambda function to run the managed prompt with
aws lambda invoke --region REGION --function-name FUNCTION_NAME --cli-binary-format raw-in-base64-out --payload file://event.json out.json, then edit the prompt, publish a new version, and repoint the function to see the output change with no code change. Pass --region on every command so that the Region matches the one you deployed to. See the README for detailed instructions.Cleanup
1. Delete the stack with AWS SAM, which also deletes the prompt and every version published from it, including the versions published during testing:
sam delete --stack-name STACK_NAME --region REGION. Enter y at each confirmation prompt.2. Confirm the stack has been deleted:
aws cloudformation list-stacks --region REGION --query "StackSummaries[?contains(StackName,'STACK_NAME')].StackStatus".3. Delete the local files created during testing:
rm -f event.json out.json out2.json out3.json. The Amazon S3 bucket the AWS SAM CLI manages for deployment artifacts is shared by every AWS SAM deployment in that account and Region, so it is not removed.Additional resources
Created by:
