Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- The GA mappings are Azure Functions to AWS Lambda, Azure Blob Storage to Amazon S3, and Azure Queue Storage to Amazon SQS.
- Azure Cosmos DB to Amazon DynamoDB remains in preview.
- The feature converts application code for eligible modern .NET apps; it does not migrate cloud infrastructure.
- Review and adjust service mappings in the assessment report and modernization plan before running the transformation, then validate the result yourself.
It rewrites Azure SDK calls, not your whole cloud environment
On October 16, 2026, AWS announced general availability of Azure SDK-to-AWS SDK application-code conversion in AWS Transform. The feature is aimed at eligible modern .NET applications that need to use equivalent AWS service code.
After you submit code, AWS Transform identifies Azure SDK usage and presents conversion options in the assessment report and modernization plan. You can accept those options or adjust them before starting modernization.
AWS documents this as application-code conversion only; it does not migrate cloud infrastructure. A completed code change therefore does not mean Azure resources, networking, identity configuration, or data have also moved to AWS.
Three service mappings are GA; Cosmos DB is still preview
The generally available mappings are Azure Functions to AWS Lambda, Azure Blob Storage to Amazon S3, and Azure Queue Storage to Amazon SQS. The corresponding Azure functions or SDK calls are rewritten as AWS-side code.
Azure Cosmos DB to Amazon DynamoDB is still labeled a preview feature. Do not plan a production migration on the assumption that this mapping is generally available.
The list is specific: other Azure services do not gain automatic equivalents through this announcement. AWS says code it cannot convert may be left as TODO comments, stubs, or items in a generated Next Steps file.
Check the plan against the services your app actually uses
Before starting, confirm that your project is an eligible modern .NET application and that its Azure services appear in the supported mapping list. If the project depends on unlisted services, plan that work as a separate migration task.
For example, suppose a .NET app uses the Azure Blob Storage SDK. If the assessment plan proposes Amazon S3, the team should first check that the target storage, configuration, and call sites match its needs before accepting the conversion. This is a hypothetical illustration, not a test run.
You can adjust mappings in the modernization plan or agent chat, and you can opt out of some or all cloud-service code conversions. Review the plan before starting so a default suggestion is not mistaken for a fixed migration design.
Build, test, and review the output locally
AWS Transform checks that converted calls are incorporated into the generated code, but that is not the same as confirming your application works on AWS. Inspect the diff, TODOs, stubs, and Next Steps, then run the project’s own build and test process.
Validate runtime behavior, identity and permissions, data access, and environment settings separately. AWS’s .NET guidance recommends a validation plan, review of the modernization plan, and validation after transformation; generated code is not a production-readiness certificate.
Check Region and billing details before estimating a project
AWS lists eight supported Regions: US East (N. Virginia), Asia Pacific (Mumbai, Tokyo, Seoul, Sydney), Canada (Central), and Europe (Frankfurt, London). If your team or code environment requires another Region, check the current availability information first.
The launch announcement does not state a separate price for this conversion. AWS’s current pricing page separately lists up to 50,000 included agent minutes per month for AWS-managed .NET transformations; the launch note does not specify how Azure-to-AWS code conversion draws on that allowance. Confirm the applicable pricing and usage shown for your account before budgeting.
Sources
Frequently Asked Questions
Does AWS Transform migrate Azure infrastructure to AWS too?
No. This feature converts application code only; AWS explicitly says it does not handle cloud-infrastructure migration. Plan resource, network, and data migration separately.
Is the Cosmos DB to DynamoDB conversion generally available?
Not yet. AWS labels Azure Cosmos DB to Amazon DynamoDB as a preview. The three GA mappings are Functions to Lambda, Blob Storage to S3, and Queue Storage to SQS.
Does it convert every Azure SDK?
No. The documentation lists specific supported service mappings. Code that cannot be converted may remain as TODOs, stubs, or Next Steps for you to resolve.
Can I deploy the result as soon as AWS Transform finishes?
Do not assume that. Review the generated changes and run your own local build, tests, and runtime checks. Code conversion does not mean your infrastructure, permissions, or data have been migrated and accepted.
Does this new conversion count toward the 50,000 included agent minutes?
AWS’s pricing page lists up to 50,000 included agent minutes per month for AWS-managed .NET transformations, but the October 16 launch announcement does not say whether this Azure-to-AWS mapping uses that allowance. Check the applicable pricing and usage for your account.