Conducting assessments on application portfolios that need to be migrated to the cloud can be a lengthy endeavor. Despite the existence of AWS Application Discovery Service or the presence of some form of configuration management database (CMDB), customers still face many challenges. These include time taken for follow-up discussions with application teams to review outputs and understand dependencies (approximately 2 hours per application), cycles needed to generate a cloud architecture design that meets security and compliance requirements, and the effort needed to provide cost estimates by selecting the right AWS services and configurations for optimal application performance in the cloud. Typically, it takes 6–8 weeks to carry out these tasks before actual application migrations begin.
In this blog post, we will harness the power of generative AI and Amazon Bedrock to help organizations simplify, accelerate, and scale migration assessments. Amazon Bedrock is a fully managed service that offers a choice of high-performing foundation models (FMs) from leading AI companies like AI21 Labs, Anthropic, Cohere, Meta, Stability AI, and Amazon through a single API, along with a broad set of capabilities you need to build generative AI applications with security, privacy, and responsible AI. By using Amazon Bedrock Agents, action groups, and Amazon Bedrock Knowledge Bases, we demonstrate how to build a migration assistant application that rapidly generates migration plans, R-dispositions, and cost estimates for applications migrating to AWS. This approach enables you to scale your application portfolio discovery and significantly accelerate your planning phase.
General requirements for a migration assistant
The following are some key requirements that you should consider when building a migration assistant.
Accuracy and consistency
Is your migration assistant application able to render accurate and consistent responses?
Guidance: To ensure accurate and consistent responses from your migration assistant, implement Amazon Bedrock Knowledge Bases. The knowledge base should contain contextual information based on your company’s private data sources. This enables the migration assistant to use Retrieval-Augmented Generation (RAG), which enhances the accuracy and consistency of responses. Your knowledge base should comprise multiple data sources, including:
Responses for an application discovery questionnaire (See example)
Output from the configuration management database (CMDB) or AWS Application Discovery Agent data (See example)
Best practices and white-papers on migration to AWS (for example, Migration Lens – AWS Well-Architected Framework and Container Migration Methodology)
Any organization-specific guidelines, migration patterns, or application patterns
Handle hallucinations
How are you reducing the hallucinations from the large language model (LLM) for your migration assistant application?
Guidance: Reducing hallucinations in LLMs involves implementation of several key strategies. Implement customized prompts based on your requirements and incorporate advanced prompting techniques to guide the model’s reasoning and provide examples for more accurate responses. These techniques include chain-of-thought prompting, zero-shot prompting, multishot prompting, few-shot prompting, and model-specific prompt engineering guidelines (see Anthropic Claude on Amazon Bedrock prompt engineering guidelines). RAG combines information retrieval with generative capabilities to enhance contextual relevance and reduce hallucinations. Finally, a feedback loop or human-in-the-loop when fine-tuning LLMs on specific datasets will help align the responses with accurate and relevant information, mitigating errors and outdated content.
Modular design
Is the design of your migration assistant modular?
Guidance:Â Building a migration assistant application using Amazon Bedrock action groups, which have a modular design, offers three key benefits.
Customization and adaptability: Action groups allow users to customize migration workflows to suit specific AWS environments and requirements. For instance, if a user is migrating a web application to AWS, they can customize the migration workflow to include specific actions tailored to web server setup, database migration, and network configuration. This customization ensures that the migration process aligns with the unique needs of the application being migrated.
Maintenance and troubleshooting: Simplifies maintenance and troubleshooting tasks by isolating issues to individual components. For example, if there’s an issue with the database migration action within the migration workflow, it can be addressed independently without affecting other components. This isolation streamlines the troubleshooting process and minimizes the impact on the overall migration operation, ensuring a smoother migration and faster resolution of issues.
Scalability and reusability: Promote scalability and reusability across different AWS migration projects. For instance, if a user successfully migrates an application to AWS using a set of modular action groups, they can reuse those same action groups to migrate other applications with similar requirements. This reusability saves time and effort when developing new migration workflows and ensures consistency across multiple migration projects. Additionally, modular design facilitates scalability by allowing users to scale the migration operation up or down based on workload demands. For example, if they need to migrate a larger application with higher resource requirements, they can easily scale up the migration workflow by adding more instances of relevant action groups, without needing to redesign the entire workflow from scratch.
Overview of solution
Before we dive deep into the deployment, let’s walk through the key steps of the architecture that will be established, as shown in Figure 1.
Users interact with the migration assistant through the Amazon Bedrock chat console to input their requests. For example, a user might request to Generate R-disposition with cost estimates or Generate Migration plan for specific application IDs (for example, A1-CRM or A2-CMDB).
The migration assistant, which uses Amazon Bedrock agents, is configured with instructions, action groups, and knowledge bases. When processing the user’s request, the migration assistant invokes relevant action groups such as R Dispositions and Migration Plan, which in turn invoke specific AWS Lambda
The Lambda functions process the request using RAG to produce the required output.
The resulting output documents (R-Dispositions with cost estimates and Migration Plan) are then uploaded to a designated Amazon Simple Storage Service (Amazon S3)
The following image is a screenshot of a sample user interaction with the migration assistant.
Prerequisites
You should have the following:
Understanding of Amazon Bedrock Agents, prompt engineering, Amazon Bedrock Knowledge Bases, Lambda functions, and AWS Identity and Access Management (IAM).
Familiarity with basic cloud migration concepts, including application discovery and migration strategies.
An AWS account with the appropriate IAM permissions to create Amazon Bedrock agents and knowledge bases, Lambda functions, and IAM roles.
Access to Amazon Bedrock models. For more information, refer to Model access.
Access to create and configure Amazon Simple Storage Service (S3) buckets, which will be used for storing generated migration plans and other outputs.
Create a service role for Amazon Bedrock Agents.
Deployment steps
Configure a knowledge base:
Open the AWS Management Console for Amazon Bedrock and navigate to Amazon Bedrock Knowledge Bases.
Choose Create knowledge base and enter a name and optional description.
Select the vector database (for example, Amazon OpenSearch Serverless).
Select the embedding model (for example, Amazon Titan Embedding G1 – Text).
Add data sources:
For Amazon S3: Specify the S3 bucket and prefix, file types, and chunking configuration.
For custom data: Use the API to ingest data programmatically.
Review and create the knowledge base.
Set up Amazon Bedrock Agents:
In the Amazon Bedrock console, go to the Agents section and chose Create agent.
Enter a name and optional description for the agent.
Select the foundation model (for example, Anthropic Claude V3).
Configure the agent’s AWS Identity and Access Management (IAM) role to grant necessary permissions.
Add instructions to guide the agent’s behavior.
Optionally, add the previously created Amazon Bedrock Knowledge Base to enhance the agent’s responses.
Configure additional settings such as maximum tokens and temperature.
Review and create the agent.
Configure actions groups for the agent:
On the agent’s configuration page, navigate to the Action groups
Choose Add action group for each required group (for example, Create R-disposition Assessment and Create Migration Plan).
For each action group:
Enter a name and description.
Define the API schema using OpenAPI 3.0 specification, detailing the endpoints and expected request and response formats.
Create and associate a Lambda function to handle the action’s logic. See the sample Lambda logic for Create R-disposition Assessment and Create Migration Plan action groups.
Configure the Lambda function with the appropriate permissions and environment variables.
Test the action group using the provided test console to ensure proper functionality.
After adding all action groups, review the entire agent configuration and deploy the agent.
Clean up
To avoid unnecessary charges, delete the resources created during testing. Use the following steps to clean up the resources:
Delete the Amazon Bedrock knowledge base: Open the Amazon Bedrock console.
Delete the knowledge base from any agents that it’s associated with.
From the left navigation pane, choose Agents.
Select the Name of the agent that you want to delete the knowledge base from.
A red banner appears to warn you to delete the reference to the knowledge base, which no longer exists, from the agent.
Select the radio button next to the knowledge base that you want to remove. Choose More and then choose Delete.
From the left navigation pane, choose Knowledge base.
To delete a source, either choose the radio button next to the source and select Delete or select the Name of the source and then choose Delete in the top right corner of the details page.
Review the warnings for deleting a knowledge base. If you accept these conditions, enter delete in the input box and choose Delete to confirm.
Delete the Agent
In the Amazon Bedrock console, choose Agents from the left navigation pane.
Select the radio button next to the agent to delete.
A modal appears warning you about the consequences of deletion. Enter delete in the input box and choose Delete to confirm.
A blue banner appears to inform you that the agent is being deleted. When deletion is complete, a green success banner appears.
Delete all the other resources including the Lambda functions and any AWS services used for account customization.
Conclusion
Conducting assessments on application portfolios for AWS cloud migration can be a time-consuming process, involving analyzing data from various sources, discovery and design discussions to develop an AWS Cloud architecture design, and cost estimates.
In this blog post, we demonstrated how you can simplify, accelerate, and scale migration assessments by using generative AI and Amazon Bedrock. We showcased using Amazon Bedrock Agents, action groups, and Amazon Bedrock Knowledge Bases for a migration assistant application that renders migration plans, R-dispositions, and cost estimates. This approach significantly reduces the time and effort required for portfolio assessments, helping organizations to scale and expedite their journey to the AWS Cloud.
Ready to improve your cloud migration process with generative AI in Amazon Bedrock? Begin by exploring the Amazon Bedrock User Guide to understand how it can streamline your organization’s cloud journey. For further assistance and expertise, consider using AWS Professional Services (contact sales) to help you streamline your cloud migration journey and maximize the benefits of Amazon Bedrock.
About the Authors
Ebbey Thomas is a Senior Cloud Architect at AWS, with a strong focus on leveraging generative AI to enhance cloud infrastructure automation and accelerate migrations. In his role at AWS Professional Services, Ebbey designs and implements solutions that improve cloud adoption speed and efficiency while ensuring secure and scalable operations for AWS users. He is known for solving complex cloud challenges and driving tangible results for clients. Ebbey holds a BS in Computer Engineering and an MS in Information Systems from Syracuse University.
Shiva Vaidyanathan is a Principal Cloud Architect at AWS. He provides technical guidance, design and lead implementation projects to customers ensuring their success on AWS. He works towards making cloud networking simpler for everyone. Prior to joining AWS, he has worked on several NSF funded research initiatives on performing secure computing in public cloud infrastructures. He holds a MS in Computer Science from Rutgers University and a MS in Electrical Engineering from New York University.
Source: Read MoreÂ
