Running AWS Transform from GitHub Copilot through MCP
AWS has documented how to connect its AWS Transform MCP server to GitHub Copilot agent mode, so migrations can be driven from the chat box in Visual Studio or VS Code. The walkthrough ports an Azure Functions .NET app to AWS Lambda using the Lambda Annotations Framework. It is worth a read if your team is weighing an Azure-to-AWS move or wants a repeatable agent-driven migration workflow.
Key points
- Install the awslabs.aws-transform-mcp-server Python package and confirm it starts before enabling it in Copilot.
- Register the server under servers in mcp.json (VS Code) or .mcp.json (Visual Studio) and set AWS_REGION.
- Switch Copilot Chat to Agent mode and enable the atx-server tools from the Tools menu.
- Name the ATX Custom orchestration agent explicitly to avoid the .NET Modernization track.
- Confirm each create_job and CLI step; changes reach the local repo only after you approve the summary.
- Transformed handlers use [LambdaFunction] with [HttpApi(...)] for HTTP, and SQSEvent or S3Event for queue and blob triggers.
AWS has published a guide for connecting the AWS Transform MCP server to GitHub Copilot in agent mode, so migrations can start from the chat box in Visual Studio or VS Code. The worked example converts an Azure Functions app with HTTP, Queue and Blob triggers into AWS Lambda functions built with the Lambda Annotations Framework, targeting net8.0 on the provided.al2023 runtime.
The server is installed as a Python package and registered in an mcp.json or .mcp.json file, with access handled by IAM Identity Center SSO or existing AWS CLI credentials. The author advises naming the ATX Custom orchestration agent in the prompt, since Copilot may otherwise pick the .NET Modernization track, which expects infrastructure inventories rather than C# source. Each action waits for your confirmation, and changes reach your local repo only after you approve the summary.
Real-world use
- Moving an isolated worker Azure Functions app with HTTP, queue and blob triggers to AWS Lambda.
- Defining a team-specific AWS Transform custom transformation for another source-to-target migration and reusing it.
- Running a dependency analysis of a .NET solution before committing to a migration plan.
Why it matters
Teams running workloads on both Azure and AWS can plan and run a Functions-to-Lambda port from the same Copilot session they use for coding, reviewing each step before code changes land.