Migrating Azure Functions to AWS Lambda: A Guide for 2025
AWS partner dedicated to startups
- 2000+ Clients
- 5+ Years of Experience
- $10M+ saved on AWS
Migrating serverless workloads from Microsoft Azure to Amazon Web Services (AWS) is more than a code rewrite: it’s a strategic decision that can lower costs, boost performance and open up a wider ecosystem of services. This guide, written from the perspective of a veteran cloud architect, shows how to migrate Azure Function to AWS Lambda. You’ll learn why companies make the move, how to plan for it, and the practical steps required to run your functions on AWS without disruption.
Table of Contents
Why migrate Azure Functions to AWS Lambda?
Cost savings and pricing flexibility
One of the biggest drivers for moving serverless functions from Azure to AWS is cost. Cloudvisor notes that AWS’s pricing options: Savings Plans, Spot Instances and deeper discounts on reserved instances: can deliver better long‑term savings than Azure’s reservations. A study by Accenture indicates that moving workloads to public cloud can reduce total cost of ownership by up to 40%. AWS Lambda operates on a pay‑as‑you‑go model where you pay only for the compute time your function uses, billed in 100‑millisecond increments. There are no charges when your code isn’t running, and a generous free tier offers one million invocations per month. This pricing structure makes Lambda ideal for workloads with variable or unpredictable traffic because you avoid paying for idle resources.
Breadth of services and global footprint
AWS offers more than 200 fully featured services across compute, storage, database, machine learning and analytics. Whether you need a managed relational database, a message queue, a data lake or a machine‑learning inference engine, AWS likely has a service that meets your requirements. This breadth reduces the need for third‑party add‑ons and lets you build integrated solutions within a single ecosystem. AWS also operates in more regions and availability zones than any other cloud provider, giving you the ability to deploy functions close to your users to reduce latency.
Scalability and performance
Both Azure Functions and AWS Lambda scale automatically, but AWS’s focus on extreme elasticity sets it apart. Services like S3 offer virtually unlimited storage and EC2 instances can scale in or out on demand. Lambda handles thousands of concurrent executions transparently and replicates functions across multiple availability zones for fault tolerance. This resilience protects against zone‑level failures and ensures high availability.
Security and compliance
AWS is a leader in cloud security, with more than 143 compliance certifications including PCI‑DSS, HIPAA and FedRAMP. Features like IAM Access Analyzer, GuardDuty and Security Hub help you monitor and enforce least‑privileged access across your environment. While Azure also offers robust security controls, AWS’s longer track record and broader compliance portfolio are attractive to regulated industries.
Innovation ecosystem
By migrating serverless workloads to AWS you gain access to a growing ecosystem of services such as Amazon EventBridge for event routing, AWS Step Functions for orchestration, and DynamoDB or Aurora Serverless for stateful data. Many of these services have matured earlier or faster on AWS; for instance, AWS pioneered serverless computing in 2014 with Lambda and continues to add new features like provisioned concurrency and custom runtime support. This environment allows you to build complex, event‑driven architectures that might not be feasible or cost‑effective on Azure.
Planning your migration
Assessing your current environment
A successful migration starts with a thorough assessment. Inventory all Azure Functions, their triggers, dependencies and related services. Identify which functions respond to HTTP requests, queue messages, timers or blob storage events. Evaluate whether they interact with Azure services such as Service Bus, Blob Storage or Azure SQL. Cloudvisor recommends creating an assessment checklist that maps each workload and its dependencies. This step reveals potential blockers, such as functions relying on Azure‑only services, and helps determine the migration strategy for each component.
Defining goals and strategies
Next, clarify why you’re migrating. Are you aiming to reduce costs, improve performance, increase reliability or adopt new features? Your goals will influence your approach. Cloudvisor outlines several migration strategies, commonly referred to as the 6 R’s:
- Rehost (“lift and shift”): Port the code as is to AWS without major changes. You’ll likely still use Lambda but might rely on similar patterns (e.g., HTTP functions through API Gateway). This is fast but may not yield the full benefits of AWS.
- Replatform: Make small changes to take advantage of AWS services (for example, replace Azure Blob Storage with Amazon S3 or Azure SQL with Amazon RDS). When migrating functions, this often means adapting your triggers and packaging format to meet Lambda’s requirements.
- Refactor (re‑architect): Redesign functions to use AWS‑native services like DynamoDB, Step Functions or EventBridge. This approach takes more time but can provide the greatest long‑term benefits.
- Repurchase, retain or retire: Determine if some functions should be replaced with SaaS, remain on Azure temporarily or be decommissioned altogether.
Decide which strategy is appropriate for each function. For example, a simple HTTP function may be a candidate for rehosting, while a complex workflow built with Azure Durable Functions might benefit from refactoring into a Step Functions state machine.
Preparing your team
Ensure your development and operations teams are familiar with AWS fundamentals. Training should cover IAM concepts, Virtual Private Cloud (VPC) networking, CloudWatch monitoring and logging, as well as Lambda’s runtime model. Cloudvisor highlights the importance of upskilling your staff or partnering with an experienced AWS consultancy to bridge knowledge gaps. Investing in training upfront prevents costly mistakes and accelerates adoption of best practices.
Mapping Azure services to AWS
Create a mapping document to match each Azure service with its AWS equivalent, as Cloudvisor suggests. For example:
- Azure Blob Storage → Amazon S3: S3 provides object storage with event notifications. You can configure S3 to trigger Lambda functions when new objects are created.
- Azure Service Bus → Amazon SQS/SNS: Use SQS for message queues or SNS for pub/sub patterns. Both can trigger Lambda.
- Azure Event Grid → Amazon EventBridge: EventBridge provides a unified event bus for routing events from AWS services or custom applications.
- Azure SQL/Cosmos DB → Amazon RDS/DynamoDB: RDS offers managed relational databases, while DynamoDB provides a serverless NoSQL option.
- Azure Durable Functions → AWS Step Functions: Step Functions orchestrate workflows with built‑in error handling and visual diagrams.
Mapping ensures you design an AWS architecture that preserves functionality while taking advantage of native services.
Step‑by‑step migration process
The following guide outlines how to convert and deploy your functions on AWS Lambda. Tailor each step to your environment and chosen migration strategy.
1. Create or configure your AWS environment
Begin by setting up an AWS account (or using an existing one) and configuring IAM roles. Define a landing zone, a structured environment with VPCs, subnets and security groups appropriate for serverless workloads. Because Lambda functions can run inside a VPC to access private resources, ensure your subnets have adequate connectivity to databases or internal services. Enable monitoring tools such as CloudWatch Logs and AWS X‑Ray. These services provide insights into function performance and help trace execution flows.
2. Adapt and package your code
Azure Functions and AWS Lambda share the concept of small, event‑driven pieces of code, but their packaging and handler conventions differ. To port a .NET Azure Function, remove the Microsoft.NET.Sdk.Functions package and add AWS Lambda packages instead. Target .NET Core versions supported by Lambda currently .NET 8 for native runtime or .NET 6 via container images. Replace Azure‑specific libraries with AWS equivalents, and adjust environment variables and configuration settings. Store sensitive configuration values in AWS Secrets Manager or Parameter Store.
For other languages like Python or Node.js, the code changes are minimal. Ensure your handler signature matches Lambda’s requirements and update any SDK calls to use AWS services. Organize dependencies in a requirements.txt or package.json, then package your code with the AWS Serverless Application Model (SAM) CLI or the Serverless Framework. SAM templates describe functions, API Gateway integrations, and permission policies in a declarative way, making deployments repeatable.
3. Recreate triggers and integrations
Azure Functions are invoked by triggers such as HTTP requests, timers or storage events. In AWS, triggers are configured at the platform level rather than in code. Map each Azure trigger to an AWS equivalent:
- HTTP requests: Use Amazon API Gateway to create REST or HTTP endpoints. API Gateway manages authentication, routing and throttling, and invokes your Lambda functions when requests arrive. Alternatively, use Lambda function URLs for simple use cases where full API Gateway features aren’t required.
- Timers: Scheduled functions in Azure can be replaced with Amazon EventBridge or CloudWatch Events rules. These services allow you to schedule cron expressions or rate triggers, and they deliver events to Lambda.
- Queue and message triggers: If your function reads from Azure Service Bus or Storage Queues, migrate to Amazon SQS (simple queue service) or SNS. Configure SQS to trigger Lambda directly on message arrival. For pub/sub patterns, use SNS or EventBridge.
- Blob triggers: Functions responding to new or updated blobs can be rewritten to use Amazon S3 event notifications. When an object is created or deleted, S3 sends a notification to Lambda.
After mapping triggers, configure IAM roles granting your functions the minimum permissions they need. For example, a function reading messages from SQS should have sqs:ReceiveMessage permission on the target queue. A function writing to DynamoDB needs appropriate dynamodb:PutItem permissions.
4. Deploy functions and configure concurrency
With code packaged and triggers defined, deploy your functions. SAM’s sam deploy command uploads your package to AWS, creates the Lambda function and attaches the necessary permissions. At deployment time, specify the memory allocation and timeout for each function. AWS Lambda lets you allocate between 128 MB and 10.24 GB of memory; CPU and network resources scale proportionally. Choose a timeout that reflects how long your function should run. AWS imposes a maximum execution time of 15 minutes per invocation, so break long‑running tasks into smaller units or offload heavy processing to AWS Fargate or ECS.
To mitigate cold starts a delay experienced when a new function container is initialized, consider using provisioned concurrency. This feature keeps a specified number of instances warm and ready to handle requests, reducing latency for latency‑sensitive applications. Monitor concurrency settings in CloudWatch to balance performance against costs.
5. Test, monitor and cut over
Before switching production traffic, thoroughly test your migrated functions. Use the AWS console or SAM CLI to invoke functions with sample events and verify responses. Inspect logs in CloudWatch and traces in X‑Ray for errors or performance bottlenecks. Compare key metrics, latency, memory usage and error rates between Azure and AWS versions. Once satisfied, update DNS or API endpoints to point to the new API Gateway endpoints. Continue monitoring for anomalies such as elevated error rates or unexpected cost spikes. When the new system stabilizes, decommission the Azure Functions and associated resources to avoid double billing.
Common challenges and solutions
Migrating serverless workloads involves more than simply copying code. Here are some challenges you may encounter and ways to address them:
Language and runtime differences
Azure Functions support languages like C#, F#, PowerShell, Python, JavaScript and Java. AWS Lambda supports many of the same, including Python, Node.js, Java, C# and Go, but runtime versions may differ. For example, Azure might support .NET 6 while Lambda uses .NET 8. Plan for minor code adjustments or choose container‑based Lambda functions, which allow you to run any Linux‑compatible runtime in a container image.
State management
Azure Durable Functions provide built‑in orchestration and stateful patterns. In AWS, orchestrate workflows using AWS Step Functions, which provide a visual interface and built‑in retries. For persistent data, use DynamoDB or Aurora Serverless, both of which scale automatically. Because Lambda functions are stateless, any state must be externalized to a data store. Use Amazon S3 or DynamoDB streams with Lambda to build event‑driven pipelines.
Execution time limits
Azure’s Premium Plan allows functions to run indefinitely, whereas AWS imposes a 15‑minute maximum execution time. Long‑running tasks should be broken into smaller functions orchestrated by Step Functions or executed in AWS Fargate containers. This pattern not only avoids timeouts but also improves resilience by isolating failure scopes.
Cold starts
Cold starts occur when a function is invoked after being idle, requiring the platform to spin up a new container. Both Azure and AWS mitigate cold starts differently. On AWS, provisioned concurrency ensures your functions are warm and ready. For workloads with unpredictable traffic, adjust memory allocation and concurrency settings to reduce startup latency. Consider using languages with faster cold start times (e.g., Node.js or Go) or using AWS Lambda SnapStart for Java functions (currently in preview) to speed up initialization.
Monitoring and debugging
Azure’s monitoring tools differ from AWS. When you migrate, set up CloudWatch Logs, CloudWatch Metrics, AWS X‑Ray and CloudTrail to gain visibility into function execution and security events. Use structured logging so you can search logs easily. Implement distributed tracing with X‑Ray to track requests across services and identify latency sources. AWS also offers native alarms and dashboards; configure alerts for high error rates, throttling or cost anomalies.
Post‑migration: Unlocking AWS innovations
Once your Azure functions run successfully in AWS, take time to explore the capabilities the platform provides beyond simple function execution. Here are several areas to investigate:
EventBridge for decoupled architectures
AWS EventBridge is an event bus that routes events from AWS services, SaaS partners or custom applications to targets like Lambda, Step Functions or Kinesis. It enables complex routing rules and supports schema discovery, allowing you to build loosely coupled microservices. Compared with Azure Event Grid, EventBridge integrates deeply with AWS services and supports fine‑grained filtering.
Step Functions for orchestration
If your Azure Functions workflow relies on Durable Functions, consider migrating orchestration logic into AWS Step Functions. Step Functions provide visual state machines, built‑in error handling and retry strategies. You can chain Lambda functions, wait for human approval (via Amazon SNS or Amazon SQS) and coordinate long‑running tasks elegantly. Step Functions integrate with over 200 AWS services, enabling complex workflows without maintaining custom orchestration code.
Fine‑tuning performance and cost
Lambda allows you to allocate memory from 128 MB to 10.24 GB in 64‑MB increments. Increasing memory also increases CPU allocation and network bandwidth, so adjust memory settings to see how performance scales. For high‑throughput or low‑latency workloads, enable provisioned concurrency to eliminate cold starts. Use Cost Explorer and Compute Optimizer to monitor spending and identify opportunities to reduce costs by right‑sizing functions or consolidating workloads.
Custom runtimes and container support
If your application uses a programming language or environment not natively supported by Lambda, you can create a custom runtime or deploy your function as a container image. Custom runtimes let you bring your own interpreter or runtime (e.g., Rust, PHP), while container‑based Lambda functions support OCI‑compliant images up to 10 GB. This flexibility means you can package dependencies and frameworks exactly as you need, making it easier to migrate complex or unusual workloads.
Integrating with the AWS ecosystem
Finally, take advantage of the broader AWS ecosystem. Pair Lambda with Amazon S3 for serverless storage, DynamoDB for low‑latency data, Aurora Serverless for relational workloads, Amazon SNS for fan‑out messaging and Amazon SQS for durable queues. Use AWS AppConfig to manage configuration updates without redeploying functions. For analytics, pipe function data into Amazon Kinesis Data Firehose or AWS Glue. The possibilities are vast because AWS services are designed to integrate seamlessly.
Real‑world experience: Repsense migration
Although there isn’t a public case study of converting Azure Functions to Lambda, Cloudvisor’s client Repsense offers valuable insight into the broader Azure‑to‑AWS journey. Repsense, an AI‑driven data company, migrated from Azure to AWS to gain greater flexibility, improved security and better performance. The move allowed them to tap into AWS’s extensive services and global infrastructure, meeting ambitious scaling goals and unlocking features unavailable on Azure. While Repsense’s migration involved more than serverless functions, it demonstrates how shifting to AWS can empower organizations to deliver new capabilities and meet business objectives.
Conclusion: Take the next step with Cloudvisor
Migrating Azure Functions to AWS Lambda can unlock substantial business value. By embracing AWS’s pay‑per‑use pricing, you avoid paying for idle capacity and can cut total cost of ownership by up to 40%. You gain access to a far broader set of services and a global network of regions, enabling you to build innovative applications that reach users around the world. When you follow a structured migration plan, starting with a thorough assessment, choosing the right strategy, adapting your code and triggers, deploying with care and embracing AWS’s advanced features, you set yourself up for long‑term success.
If you’re ready to explore this journey, Cloudvisor can help. We’ve helped startups and enterprises migrate to AWS for years, including clients like Repsense. Our experts will guide you through planning, implementation and optimization, ensuring your serverless workloads run efficiently and securely. Book a free consultation today to discover how moving to AWS can accelerate your growth.
