You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-functions/migration/lambda-functions-migration-assess.md
+9-9Lines changed: 9 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -66,7 +66,7 @@ The following tables compare AWS Lambda concepts, resources, and properties with
66
66
| AWS Lambda | Azure Functions |
67
67
|---|---|
68
68
| The Lambda execution role grants Lambda functions permissions to interact with other AWS services. Each Lambda function has an associated identity and access management (IAM) role that determines its permissions while it runs. | Managed identities provide an identity for your function app that allows it to authenticate with other Azure services without storing credentials in the code. Role-based access control assigns appropriate roles to the managed identity in Microsoft Entra ID to grant access to the resources it requires. |
69
-
| Resource-based policy statements: <br> - AWSLambda_FullAccess gives full access to all Lambda operations, including creating, updating, and deleting functions. <br> - AWSLambda_ReadOnlyAccess fgives read-only access to view Lambda functions and their configurations <br> - Custom IAM policies | Resource-based built-in roles: <br> - The Owner role gives full access, including access permissions management. <br> - The Contributor role can create and delete function apps, configure settings, and deploy code. It can't manage access. <br> - The Monitoring Reader role can grant read-only access to monitoring data and settings. It can also allocate custom roles. |
69
+
| Resource-based policy statements: <br> - AWSLambda_FullAccess gives full access to all Lambda operations, including creating, updating, and deleting functions. <br> - AWSLambda_ReadOnlyAccess gives read-only access to view Lambda functions and their configurations <br> - Custom IAM policies | Resource-based built-in roles: <br> - The Owner role gives full access, including access permissions management. <br> - The Contributor role can create and delete function apps, configure settings, and deploy code. It can't manage access. <br> - The Monitoring Reader role can grant read-only access to monitoring data and settings. It can also allocate custom roles. |
70
70
71
71
### Function URL
72
72
@@ -99,26 +99,26 @@ The following tables compare AWS Lambda concepts, resources, and properties with
99
99
100
100
| AWS Lambda | Azure Functions |
101
101
|---|---|
102
-
| Provisioned concurrency reduces latency and ensures predictable function performance by pre-initializing a requested number of function instances. Provisioned concurrency suits latency-sensitive applications and is priced separately from standard concurrency. | Function apps allow you to configure concurrency for each instance, which drives its scale. Multiple jobs can run in parallel in the same instance of the app, and subsequent jobs in the instance don't incur the initial cold start. Function apps also have *always ready* instances. Customers can specify a number of pre-warmed instances to eliminate cold-start latency and ensure consistent performance. Function apps also scale out to additional instances based on demand, while maintaining the always ready instances. |
102
+
| Provisioned concurrency reduces latency and ensures predictable function performance by pre-initializing a requested number of function instances. Provisioned concurrency suits latency-sensitive applications and is priced separately from standard concurrency. | Function apps allow you to configure concurrency for each instance, which drives its scale. Multiple jobs can run in parallel in the same instance of the app, and subsequent jobs in the instance don't incur the initial cold start. Function apps also have *always ready* instances. Customers can specify a number of prewarmed instances to eliminate cold-start latency and ensure consistent performance. Function apps also scale out to more instances based on demand, while maintaining the always ready instances. |
103
103
| Reserved concurrency specifies the maximum number of concurrent instances a function can have. This limit ensures that a portion of your account's concurrency quota is set aside exclusively for that function. AWS Lambda dynamically scales out to handle incoming requests even when reserved concurrency is set, as long as the requests don't exceed the specified reserved concurrency limit. The lower limit for reserved concurrency in AWS Lambda is 1. The upper limit for reserved concurrency in AWS Lambda is determined by the account's regional concurrency quota. By default, this limit is 1,000 concurrent executions for each region. | Azure Functions doesn't have an equivalent feature to reserved concurrency. To achieve similar functionality, isolate specific functions into separate function apps and set the maximum scale-out limit for each app. Azure Functions dynamically scales out, or adds more instances, and scales in, or removes instances, within the scale-out limit set. By default, apps that run in a Flex Consumption plan start with a configurable limit of 100 overall instances. The lowest maximum instance count value is 40, and the highest supported maximum instance count value is 1,000. [Regional subscription memory quotas](/azure/azure-functions/flex-consumption-plan#regional-subscription-memory-quotas) can also limit how much function apps can scale out, but you can increase this quota by calling support. |
104
104
105
105
### Pricing
106
106
107
107
| AWS Lambda | Azure Functions |
108
108
|---|---|
109
-
| - Pay per use for the total execution count and for the GB/s for each instance (with a fixed concurrency of 1) <br> - 1 ms increments <br> - 400K Gb/s free tier | - Pay per use for the total execution count and for the GB/s of each instance (with configurable concurrent executions) <br> - 100 ms increments <br> - 100K Gb/s free tier <br> - [Consumption-based costs](/azure/azure-functions/functions-consumption-costs#consumption-based-costs) |
109
+
| - Pay per use for the total execution count and for the GB/s for each instance (with a fixed concurrency of 1) <br> - 1 ms increments <br> - 400,000 Gb/s free tier | - Pay per use for the total execution count and for the GB/s of each instance (with configurable concurrent executions) <br> - 100 ms increments <br> - 100,000 Gb/s free tier <br> - [Consumption-based costs](/azure/azure-functions/functions-consumption-costs#consumption-based-costs) |
110
110
111
111
### Source code storage
112
112
113
113
| AWS Lambda | Azure Functions |
114
114
|---|---|
115
-
| AWS Lambda manages the storage of your function code in its own managed storage system. You don't need to supply additional storage. | Functions requires a customer-supplied Blob Storage container to maintain the deployment package that contains your app's code. You can configure the settings to use the same or a different storage account for deployments and manage authentication methods for accessing the container. |
115
+
| AWS Lambda manages the storage of your function code in its own managed storage system. You don't need to supply more storage. | Functions requires a customer-supplied Blob Storage container to maintain the deployment package that contains your app's code. You can configure the settings to use the same or a different storage account for deployments and manage authentication methods for accessing the container. |
116
116
117
117
### Local development
118
118
119
119
| AWS Lambda feature | Azure Functions feature |
120
120
|---|---|
121
-
| - SAM CLI <br> - [LocalStack](https://github.com/localstack/localstack) | Azure Functions core tools <br> - Visual Studio Code <br> - Visual Studio <br> - GitHub Codespaces <br> - VSCode.dev <br> - Maven <br> - [Code and test Azure Functions locally](/azure/azure-functions/functions-develop-local) |
121
+
| - SAM CLI <br> - [LocalStack](https://github.com/localstack/localstack) | - Azure Functions core tools <br> - Visual Studio Code <br> - Visual Studio <br> - GitHub Codespaces <br> - VSCode.dev <br> - Maven <br> - [Code and test Azure Functions locally](/azure/azure-functions/functions-develop-local) |
122
122
123
123
### Deployment
124
124
@@ -136,8 +136,8 @@ The following tables compare AWS Lambda concepts, resources, and properties with
| Execution timeout | 900 seconds (15 minutes) | The default time-out is 30 minutes. The maximum time-out is unbounded. However, the grace period given to a function execution is 60 minutes during scale-in and 10 minutes during platform updates. For more information, see [Function app time-out duration](/azure/azure-functions/functions-scale#timeout). |
140
-
| Configurable memory | 128 MB to 10,240 MB, in 64 MB increments | Functions supports [2 GB and 4 GB](/azure/azure-functions/functions-scale#service-limits) instance sizes. Each region in a given subscription has a memory limit of 512,000 MB for all instances of apps, which you can increase by calling support. The total memory usage of all instances across all function apps in a region must stay within this quota. Although 2 GB and 4 GB are the options for instance sizes right now, it's important to note that the concurrency for each instance can be higher than 1. Therefore, a single instance can handle multiple concurrent executions, depending on the configuration. Configuring concurrency appropriately can help optimize resource utilization and manage performance. By balancing memory allocation and concurrency settings, you can effectively manage the resources allocated to your function apps and ensure efficient performance and cost control. For more information, see [Regional subscription memory quotas](/azure/azure-functions/flex-consumption-plan#regional-subscription-memory-quotas). |
139
+
| Execution time-out | 900 seconds (15 minutes) | The default time-out is 30 minutes. The maximum time-out is unbounded. However, the grace period given to a function execution is 60 minutes during scale-in and 10 minutes during platform updates. For more information, see [Function app time-out duration](/azure/azure-functions/functions-scale#timeout). |
140
+
| Configurable memory | 128 MB to 10,240 MB, in 64-MB increments | Functions supports [2-GB and 4-GB](/azure/azure-functions/functions-scale#service-limits) instance sizes. Each region in a given subscription has a memory limit of 512,000 MB for all instances of apps, which you can increase by calling support. The total memory usage of all instances across all function apps in a region must stay within this quota. Although 2 GB and 4 GB are the instance size options right now, it's important to note that the concurrency for each instance can be higher than 1. Therefore, a single instance can handle multiple concurrent executions, depending on the configuration. Configuring concurrency appropriately can help optimize resource utilization and manage performance. By balancing memory allocation and concurrency settings, you can effectively manage the resources allocated to your function apps and ensure efficient performance and cost control. For more information, see [Regional subscription memory quotas](/azure/azure-functions/flex-consumption-plan#regional-subscription-memory-quotas). |
141
141
142
142
### Secret management
143
143
@@ -170,7 +170,7 @@ The following tables compare AWS Lambda concepts, resources, and properties with
170
170
171
171
- Select key workloads for a proof of concept.
172
172
173
-
Start by selecting one to two medium-sized, non-critical workloads from your total inventory. These workloads serve as the foundation for your proof-of-concept migration. You can test the process and identify potential challenges without risking major disruption to your operations.
173
+
Start by selecting one to two medium-sized, noncritical workloads from your total inventory. These workloads serve as the foundation for your proof-of-concept migration. You can test the process and identify potential challenges without risking major disruption to your operations.
174
174
175
175
- Test iteratively and gather feedback.
176
176
@@ -181,4 +181,4 @@ By the end of this stage, you have mapped AWS Lambda features and services to th
Copy file name to clipboardExpand all lines: articles/azure-functions/migration/lambda-functions-migration-discover.md
+31-5Lines changed: 31 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,5 @@
1
1
---
2
-
title: Discover workloads to migrate from AWS Lambda to Azure Functions
2
+
title: Discover Workloads to Migrate from AWS Lambda to Azure Functions
3
3
description: Learn how to conduct a detailed discovery process to inventory current AWS Lambda workloads, including their configuration, dependencies, and usage patterns.
4
4
author: MadhuraBharadwaj-MSFT
5
5
ms.author: mabhar
@@ -18,34 +18,60 @@ In this stage, you conduct a detailed discovery process to evaluate existing AWS
18
18
Compile a comprehensive inventory of your AWS Lambda functions by using familiar AWS tooling like service-specific SDKs, APIs, and CloudTrail to assess the workloads on AWS. You should understand the following key aspects of your inventory:
19
19
20
20
- Use cases
21
+
21
22
- Identify the primary business or technical purposes that each Lambda function serves.
23
+
22
24
- Categorize functions based on their use cases, such as event-driven workflows, data processing, real-time analytics, or API back ends.
23
25
24
26
- Configuration
27
+
25
28
- Document configuration settings for each function, including memory allocation, time-out settings, and environment variables.
29
+
26
30
- Note versioning details, aliases, and any deployment-specific configurations, such as language runtime and architectures like x86 or ARM.
27
31
28
32
- Security and networking setup
33
+
29
34
- Assess the identity and access management roles and policies associated with each function to ensure proper access control.
35
+
30
36
- Identify virtual private cloud configurations, including subnets, security groups, and NAT gateway dependencies, if applicable.
31
37
32
38
- Tooling
39
+
33
40
- List the continuous integration and continuous delivery tools and deployment frameworks that each function uses, such as AWS SAM, Serverless Framework, or custom pipelines.
41
+
34
42
- Document build and packaging tools, including testing frameworks and staging workflows.
35
43
36
44
- Monitoring, logging, and observability mechanisms
45
+
37
46
- Evaluate the current monitoring and logging mechanisms, such as Amazon CloudWatch, AWS X-Ray, or partner tools.
47
+
38
48
- Identify log retention policies and patterns for troubleshooting.
49
+
39
50
- Document tracked metrics and alerts, such as error rates, invocation counts, and duration trends.
40
51
41
52
- Dependencies
42
-
- Determine which AWS services, like DynamoDB, S3, or API Gateway, and partner tools that your Lambda functions rely on. Document their configurations, interactions, and data flows.
43
-
- Map interdependencies, such as shared resources or invocation chains, between Lambda functions and evaluate potential bottlenecks or latency problems.
53
+
54
+
- Determine which AWS services, like DynamoDB, S3, or API Gateway, and partner tools that your Lambda functions rely on. Document their configurations, interactions, and dataflows.
55
+
56
+
- Map interdependencies, such as shared resources or invocation chains, between Lambda functions, and evaluate potential bottlenecks or latency problems.
57
+
44
58
- Assess service limits, operational considerations, and monitoring tools like CloudWatch and X-Ray. Ensure that you understand how these dependencies affect the workload.
45
59
46
-
By the end of this stage, you should have a comprehensive inventory of your AWS Lambda functions, including their use cases, configurations, security and networking setups, tooling, monitoring, logging, and observability mechanisms, and dependencies. This detailed inventory is the foundation for the next stage, where you assess the readiness and suitability of these functions for migration to Azure Functions.
60
+
By the end of this stage, you should have a comprehensive inventory of your AWS Lambda functions, including their:
61
+
62
+
- Use cases.
63
+
64
+
- Configurations.
65
+
66
+
- Security and networking setups.
67
+
68
+
- Tooling, monitoring, logging, and observability mechanisms.
69
+
70
+
- Dependencies.
71
+
72
+
This detailed inventory is the foundation for the next stage, where you assess the readiness and suitability of these functions for migration to Azure Functions.
0 commit comments