AWS Builder Center

Builder Center

Set Up AWS Lambda Managed Instances Through the AWS Console

Set Up AWS Lambda Managed Instances Through the AWS Console

Series: Financial Service (19 articles)

  1. 1
    AWS Lambda MicroVMs and the End of Repeated Application Cold Initialization
  2. …
  3. 4
    Set Up AWS Lambda Managed Instances Through the AWS Console This article
  4. 5
    Lambda Durable Functions for a Governed Three-Level Order-Book Workflow

Martin

Dev @ Vertex Macro

Set Up AWS Lambda Managed Instances Through the AWS Console

Purpose

This guide explains how to create an AWS Lambda Managed Instances environment through the AWS Management Console, attach a Lambda function to it, publish and test the function, configure scaling and monitoring, and safely deactivate or remove the infrastructure.
Lambda Managed Instances, also called LMI, runs Lambda functions on Amazon EC2 instances in your AWS account while AWS manages instance provisioning, operating-system and runtime patching, request routing, load balancing, and scaling. Unlike the default Lambda compute type, LMI supports multiple concurrent invocations in one execution environment. A capacity provider is the infrastructure and security boundary that connects the function to the VPC, EC2 instance requirements, IAM operator role, and scaling configuration.
Console labels can change slightly as AWS updates the service. Use the AWS Region in which Lambda Managed Instances and your required EC2 instance types are available.

Architecture Created by This Procedure

The completed environment contains the following components:
  • A VPC with private subnets in multiple Availability Zones
  • Route tables and approved outbound connectivity
  • A security group for the managed EC2 capacity
  • A Lambda function execution role
  • A Lambda Managed Instances capacity-provider operator role
  • A Lambda capacity provider
  • A Lambda function using the Lambda Managed Instances compute type
  • A published function version
  • CloudWatch logs, metrics, alarms, and a dashboard
  • Optional SQS asynchronous invocation and failure handling
For production financial-services workloads, keep the calculation plane separate from systems that submit external transactions. The LMI function should calculate, validate, enrich, or prepare an action. A separately controlled execution service should perform the final transaction only after entitlement, limit, approval, idempotency, and reconciliation controls succeed.

Important Behavior to Understand

LMI is intended primarily for sustained, predictable, high-volume workloads that benefit from EC2 hardware choices, VPC placement, and EC2 purchasing options. It is not equivalent to default Lambda scale-to-zero behavior.
A default Lambda execution environment handles one invocation at a time. An LMI execution environment can handle multiple invocations simultaneously. Application code must therefore be safe under concurrent execution. Do not store request-specific data in unprotected global variables, reuse non-unique temporary filenames, or allow logging context to leak between requests.
When a function version is published on a capacity provider, Lambda normally launches three managed instances and three execution environments for Availability Zone resilience before marking the version active. Scaling is asynchronous and responds to CPU utilization and execution-environment concurrency saturation. A traffic increase greater than approximately two times within five minutes can experience throttling while capacity is added.
The smallest LMI function configuration is 2 GB of memory and 1 vCPU. Functions can run for up to 90 minutes, or 5,400 seconds, only for asynchronous invocations and eligible event-source mapping invocations. Synchronous invocations, initialization, Amazon MQ event-source mappings, and Amazon DocumentDB event-source mappings remain limited to 15 minutes.

Prerequisites

Before opening the console, identify the following values:
  • AWS account and target Region
  • Environment name, such as dev, test, or prod
  • VPC CIDR range
  • At least two private subnets in different Availability Zones, with three preferred for production resilience
  • Required outbound destinations and VPC endpoints
  • Processor architecture, either x86_64 or an available Arm64 option
  • Maximum vCPU limit for the capacity provider
  • Function runtime, memory, vCPU ratio, timeout, and expected concurrency
  • Expected sustained and peak request rates
  • Data classification and trust level
  • Required downstream AWS services and IAM permissions
  • A cost limit and an infrastructure-removal plan
The console operator needs permission to manage Lambda functions and capacity providers, create or select IAM roles, pass the required roles, select VPC resources, and configure CloudWatch. The first capacity-provider creation in an account can also require iam:CreateServiceLinkedRole.

Step 1: Select the AWS Region

  1. Sign in to the AWS Management Console.
  2. Use the Region selector in the upper-right corner.
  3. Select the Region in which the VPC, data, downstream services, and LMI capacity will run.
  4. Confirm that Lambda Managed Instances and the desired instance families are supported in that Region.
  5. Keep all resources in the same Region unless the architecture explicitly requires cross-Region access.
For regulated workloads, record why the Region was selected and verify data-residency, latency, recovery, and service-availability requirements.

Step 2: Create or Prepare the VPC

LMI runs managed EC2 instances in subnets that you specify. The network must provide the connectivity required by the function and by Lambda telemetry.
  1. Open VPC in the AWS Management Console.
  2. Choose Your VPCs.
  3. To create a VPC, choose Create VPC.
  4. Select VPC only or the guided VPC workflow according to enterprise standards.
  5. Enter a descriptive name, such as prod-lmi-trading-vpc.
  6. Enter an approved IPv4 CIDR block, such as 10.40.0.0/16.
  7. Configure IPv6 only when required and approved.
  8. Choose Create VPC.
  9. Open the new VPC and confirm that DNS resolution and DNS hostnames are enabled when required by the application.
Do not use an overlapping CIDR range if the VPC connects to an enterprise network, another VPC, or a transit gateway.

Step 3: Create Private Subnets Across Availability Zones

  1. In the VPC console, choose Subnets.
  2. Choose Create subnet.
  3. Select the LMI VPC.
  4. Create a private subnet in the first Availability Zone, for example prod-lmi-private-a with 10.40.10.0/24.
  5. Create a second private subnet in another Availability Zone, for example prod-lmi-private-b with 10.40.20.0/24.
  6. For stronger production resilience, create a third private subnet in a third Availability Zone, for example prod-lmi-private-c with 10.40.30.0/24.
  7. Confirm that automatic public IPv4 assignment is disabled for the private subnets.
  8. Ensure the subnet CIDR ranges have enough free IP addresses for the planned capacity and growth.
Using fewer than three Availability Zones can reduce the default resiliency of the LMI deployment.

Step 4: Configure Routes and Outbound Connectivity

Choose the least-permissive connectivity model that supports the workload.
For access to supported AWS services, prefer interface or gateway VPC endpoints. Examples include endpoints for Amazon S3, Amazon DynamoDB, AWS Secrets Manager, AWS Key Management Service, and other services required by the workload.
If the function must reach public AWS endpoints or approved external services from private subnets:
  1. Create or select a NAT gateway in an approved public subnet, or use the enterprise egress architecture.
  2. Open Route tables in the VPC console.
  3. Select the route table associated with each LMI private subnet.
  4. Add the approved default or destination-specific route through the NAT gateway, firewall, or transit architecture.
  5. Confirm that network ACLs permit required traffic.
  6. Confirm that DNS resolution works from the VPC.
  7. Ensure external destinations are allow-listed through enterprise egress controls.
Long-running functions must account for connection idle timeouts. A path through a NAT gateway can drop an idle connection after 350 seconds, so use application keep-alives or reconnect safely. Respect DNS TTL values and refresh temporary credentials that could expire during a long invocation.

Step 5: Create the Capacity Provider Security Group

  1. In the VPC console, choose Security groups.
  2. Choose Create security group.
  3. Enter a name such as prod-lmi-capacity-provider-sg.
  4. Select the LMI VPC.
  5. Do not add inbound rules unless an approved component explicitly requires them.
  6. Restrict outbound rules to the destinations and ports required by the function, telemetry, package access, data services, and enterprise egress path.
  7. Choose Create security group.
Do not use unrestricted outbound access in a production environment without a documented reason and compensating controls.

Step 6: Create the Lambda Function Execution Role

The execution role is assumed by the function code. It is separate from the operator role used by Lambda to manage EC2 capacity.
  1. Open IAM in the AWS Management Console.
  2. Choose Roles.
  3. Choose Create role.
  4. For trusted entity type, select AWS service.
  5. For use case, choose Lambda.
  6. Attach AWSLambdaBasicExecutionRole to permit CloudWatch Logs delivery.
  7. Add only the application permissions required by the function. Examples can include tightly scoped access to a specific SQS queue, S3 bucket prefix, DynamoDB table, KMS key, or Secrets Manager secret.
  8. Enter a role name such as prod-lmi-function-execution-role.
  9. Add enterprise tags.
  10. Choose Create role.
  11. Open the role and review the trust policy. The service principal should be lambda.amazonaws.com.
  12. Review every attached permission and remove broad permissions not needed by the function.
Avoid using AdministratorAccess, wildcard resource permissions, or a shared execution role across unrelated trust domains.

Step 7: Create the Capacity Provider Operator Role

The capacity-provider operator role allows Lambda to launch, terminate, and monitor the managed EC2 instances.
  1. In IAM, choose Roles.
  2. Choose Create role.
  3. Select Custom trust policy if the guided use case is not available.
  4. Use a trust relationship that allows lambda.amazonaws.com to call sts:AssumeRole.
  5. Attach the AWS managed policy AWSLambdaManagedEC2ResourceOperator.
  6. Enter a name such as prod-lmi-capacity-provider-operator-role.
  7. Add enterprise tags.
  8. Choose Create role.
  9. Record the role ARN for the capacity-provider setup.
The administrator creating the capacity provider must be allowed to pass this operator role. Limit iam:PassRole permission to the specific role ARN rather than all roles.

Step 8: Create the Lambda Managed Instances Capacity Provider

  1. Open AWS Lambda in the AWS Management Console.
  2. In the left navigation pane, choose Capacity providers.
  3. Choose Create capacity provider.
  4. Under Capacity provider settings, enter a descriptive name such as prod-trading-analysis-trusted.
  5. Select the prepared VPC.
  6. Select the private subnets across multiple Availability Zones.
  7. Select prod-lmi-capacity-provider-sg or the approved security group.
  8. Select the capacity-provider operator role created earlier.
  9. Expand Advanced settings.
  10. Under Instance requirements, choose the processor architecture.
  11. Allow Lambda to choose compatible instance types unless testing proves that specific hardware is required.
  12. If specific requirements exist, configure an allowed set rather than one instance type whenever possible. A narrow selection can reduce capacity availability.
  13. Under Auto scaling, set the maximum EC2 vCPU count for the provider. This is a critical cost and capacity guardrail.
  14. Keep automatic scaling for the normal production case. Select Manual instance scaling mode only when precise capacity control is required and an operator owns the lifecycle.
  15. Review all settings.
  16. Choose Create capacity provider.
  17. Wait until the capacity provider is ready before creating the function.
Create separate capacity providers for workloads with different trust levels. All functions attached to one capacity provider must be mutually trusted because the capacity provider is the LMI security boundary.

Step 9: Create the LMI Function

  1. In the Lambda console, choose Functions.
  2. Choose Create function.
  3. Select Author from scratch.
  4. Enter a function name such as prod-portfolio-analysis-lmi.
  5. Select a runtime supported by LMI in the target Region.
  6. Select the same architecture used by the capacity provider.
  7. Under Permissions, select Use an existing role.
  8. Choose prod-lmi-function-execution-role.
  9. Expand Additional configurations.
  10. For Compute type, select Lambda Managed Instances.
  11. Select the capacity provider ARN. The provider created in the previous step can be preselected.
  12. Choose the function memory size. The minimum is 2 GB.
  13. Choose the execution-environment memory-per-vCPU ratio.
  14. Choose Create function.
  15. Allow several minutes for function creation and initial capacity provisioning.
For Python, begin with a higher memory-to-vCPU ratio, such as 4:1 or 8:1, then validate with representative load. For CPU-intensive code or code that performs little I/O, use more than one vCPU and test a lower concurrency setting. For I/O-heavy work, controlled multi-concurrency generally provides greater utilization.

Step 10: Add or Deploy Function Code

For a simple console validation, replace the generated code with the following Python handler if the selected runtime is Python:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
import json
import os
import time


def lambda_handler(event, context):
request_id = context.aws_request_id
started_at = time.time()

result = {
"status": "ok",
"request_id": request_id,
"function_name": context.function_name,
"function_version": context.function_version,
"remaining_time_ms": context.get_remaining_time_in_millis(),
"process_id": os.getpid(),
"received_event": event,
"elapsed_ms": int((time.time() - started_at) * 1000),
}

print(json.dumps(result))
return result
  1. Paste the code into the console editor.
  2. Choose Deploy.
  3. For enterprise applications, deploy signed artifacts through a controlled CI/CD pipeline instead of editing production code in the console.
  4. Store secrets in AWS Secrets Manager or another approved secret store rather than in the source code.
  5. Use environment variables only for non-secret configuration or references to protected values.
Request-specific values must remain local to the invocation. Do not place customer identifiers or mutable request state in global variables because multiple invocations can run in the same execution environment.

Step 11: Configure General Function Settings

  1. On the function page, choose Configuration.
  2. Choose General configuration.
  3. Choose Edit.
  4. Set Memory and any LMI-specific vCPU ratio based on test evidence.
  5. Set Timeout.
  6. Use no more than 900 seconds for synchronous requests.
  7. Use up to 5,400 seconds only for asynchronous invocations or eligible event-source mappings.
  8. Add a clear function description.
  9. Choose Save.
A long-running function should checkpoint progress before its deadline. If a single task cannot complete safely within 90 minutes, split the work or select a service designed for longer execution.

Step 12: Configure Function Scaling and Concurrency

Open the function configuration area for Managed Instances scaling. Depending on the current console layout, these controls can appear under Configuration, Concurrency, or the Managed Instances compute settings.
Configure the following values:
  1. Set the minimum execution environments to support baseline load. The default is normally three.
  2. Avoid setting the minimum below three in production unless reduced Availability Zone resilience is understood and accepted.
  3. Set the maximum execution environments to create a cost boundary and protect other functions sharing the provider.
  4. Set or review maximum concurrency per execution environment.
  5. Begin conservatively and increase concurrency after sustained-load testing.
  6. For low-CPU, I/O-heavy invocations, concurrency can be increased substantially, with an LMI limit of up to 64 concurrent invocations per vCPU where appropriate.
  7. For CPU-bound or memory-heavy work, reduce concurrency and increase function resources.
  8. Save the configuration.
Monitor ConcurrencyThrottles, CPUThrottles, MemoryThrottles, and DiskThrottles to determine the actual constraint. Very low execution-environment concurrency can also cause scaling difficulty and throttling.

Step 13: Configure Asynchronous Processing with Amazon SQS

For jobs that can take more than a few seconds, and especially jobs that can approach 90 minutes, place work behind an asynchronous queue instead of holding a synchronous client connection.
  1. Open Amazon SQS.
  2. Choose Create queue.
  3. Select Standard unless the workload requires FIFO ordering and deduplication semantics.
  4. Enter a name such as prod-portfolio-analysis-jobs.
  5. Set encryption according to enterprise policy.
  6. If the function timeout is 5,400 seconds, set queue visibility timeout according to the Lambda requirement of at least six times the function timeout. Confirm the current SQS maximum and Lambda event-source requirements before finalizing a 90-minute design.
  7. Configure a dead-letter queue and a bounded receive count.
  8. Choose Create queue.
  9. Add the minimum SQS consume permissions to the function execution role.
  10. Return to the Lambda function.
  11. Choose Add trigger.
  12. Select SQS.
  13. Select the queue.
  14. Configure batch size, batching window, and concurrency based on load tests.
  15. Enable partial batch failure reporting where supported by the runtime implementation.
  16. Choose Add.
Every job must have an idempotency key. Lambda and SQS processing are at least once, so duplicate delivery must not cause a duplicate financial action or duplicate database write.

Step 14: Create a Test Event

  1. Open the function Code tab.
  2. Choose Test.
  3. Choose Create new event.
  4. Enter an event name such as basic-lmi-test.
  5. Use a payload such as:
1
2
3
4
5
6
{
"job_id": "LMI-TEST-001",
"portfolio_id": "DEMO-PORTFOLIO",
"operation": "validate-connectivity",
"idempotency_key": "LMI-TEST-001-v1"
}
  1. Save the event.
  2. Choose Test.
  3. Review the response, execution duration, request ID, and log link.
  4. Open the corresponding CloudWatch log stream and verify the structured output.
A console test is a functional check, not a concurrency or performance test.

Step 15: Publish a Function Version

Publishing is important because function versions become active on capacity-provider instances.
  1. On the function page, choose Actions.
  2. Choose Publish new version.
  3. Enter a description containing the release identifier and artifact version.
  4. Choose Publish.
  5. Wait for the published version to become active.
  6. Confirm that the capacity provider is healthy and that expected execution environments are available.
  7. Create or update an alias, such as prod, only after validation.
  8. Point invoking systems to the controlled alias rather than an unqualified development version.
Record the published version, code hash, role ARN, capacity provider ARN, configuration, approver, and release time for audit purposes.

Step 16: Configure CloudWatch Monitoring

  1. Open CloudWatch.
  2. Choose Metrics.
  3. Locate Lambda and Lambda Managed Instances metrics.
  4. Create a dashboard for the capacity provider and function.
  5. Add capacity-provider metrics such as CPU utilization, memory utilization, available vCPUs, and available memory.
  6. Add execution-environment concurrency and concurrency-limit metrics.
  7. Add invocation count, errors, duration, throttles, queue depth, oldest-message age, dead-letter activity, and business-outcome metrics.
  8. Create alarms for high CPU or memory use.
  9. Create alarms for low available capacity.
  10. Create alarms for approaching concurrency limits and each throttle reason.
  11. Create alarms for elevated errors, stale queue messages, and unusual cost.
  12. Route alarms to the approved incident-management destination.
Also use CloudTrail to monitor capacity-provider assignments, policy changes, role changes, scaling changes, and deletion activity.

Step 17: Perform Load and Concurrency Testing

Do not approve production solely from a successful console test.
Run representative tests that include:
  • Expected sustained request volume
  • A controlled increase to at least the planned peak
  • More than 100 simultaneous users when that reflects the business case
  • Representative payload size and data distribution
  • Realistic downstream latency and quota behavior
  • Retry and duplicate-delivery scenarios
  • Network and downstream-service failures
  • CPU, memory, disk, and connection-pool saturation
  • State-isolation and temporary-file collision tests
  • Idempotency and reconciliation tests
  • Scale-out and scale-in behavior
  • Deactivation and recovery procedures
Measure completion rate, p50 and p99 duration, queue age, throttles by reason, CPU, memory, network use, failure rate, duplicate suppression, downstream rejection, and cost per completed business operation.

Step 18: Production Readiness Controls

Before opening production traffic, verify the following conditions:
  • Functions sharing a capacity provider are mutually trusted.
  • Private subnets span multiple Availability Zones.
  • The operator and execution roles use least privilege.
  • Network egress is restricted and observable.
  • Secrets are not embedded in code.
  • Request-specific state is isolated under multi-concurrency.
  • All financially meaningful operations are idempotent.
  • Calculation and transaction-execution planes are separated.
  • Maximum vCPU, execution-environment, and concurrency limits are set.
  • CloudWatch and CloudTrail monitoring are active.
  • Failure destinations and dead-letter handling are tested.
  • Runbooks include throttling, stale data, downstream failure, and duplicate delivery.
  • A tested kill switch can stop intake, dispatch, or final execution independently.
  • Cost alarms and an end-of-project shutdown owner are assigned.

Step 19: Safely Deactivate the Function

Use deactivation when the project finishes but the configuration must remain available temporarily.
  1. Stop new application intake.
  2. Allow safe in-flight jobs to complete or reach checkpoints.
  3. Drain SQS queues or move remaining jobs to a controlled holding queue.
  4. Reconcile external actions and uncertain responses.
  5. Archive required inputs, outputs, logs, and evidence.
  6. Open the LMI function scaling configuration.
  7. Set both minimum and maximum execution environments to 0.
  8. Save the configuration.
  9. Verify that no active execution environments remain.
  10. Continue monitoring billing and inventory until the underlying managed instances terminate.
LMI instance charges continue until termination completes, which can take several minutes.

Step 20: Delete the LMI Infrastructure

Managed instances cannot be terminated as ordinary EC2 instances. Remove them through the LMI capacity-provider lifecycle.
  1. Confirm that no required function version still uses the capacity provider.
  2. Remove event-source mappings and triggers that can create new work.
  3. Delete or retire controlled aliases and function versions according to retention policy.
  4. Delete the Lambda function when it is no longer required.
  5. In the Lambda console, choose Capacity providers.
  6. Select the capacity provider.
  7. Choose Delete.
  8. Confirm deletion.
  9. Verify that Lambda terminates the associated managed EC2 instances.
  10. Remove unused IAM roles, policies, security groups, VPC endpoints, NAT capacity, queues, and VPC resources only after dependency and retention checks.
  11. Review CloudTrail, AWS Config, inventory, and billing data to prove closure.

Troubleshooting

The Capacity Provider Option Is Missing

Confirm that the selected Region supports LMI, your identity has the required Lambda and IAM permissions, and the account is permitted to create the service-linked role.

Capacity Provider Creation Fails

Review the operator-role trust policy, attachment of AWSLambdaManagedEC2ResourceOperator, iam:PassRole permission, VPC and subnet selections, security-group validity, service quotas, and available subnet IP addresses.

Function Creation Remains in Progress

Initial provisioning can take several minutes. Review Lambda status messages, capacity-provider state, CloudTrail events, service quotas, subnet capacity, and restrictions on the selected instance types.

The Function Cannot Reach CloudWatch or AWS Services

Check route tables, VPC endpoints, NAT or egress routing, security-group outbound rules, network ACLs, DNS settings, endpoint policies, and IAM permissions.

Invocations Are Throttled

Review concurrency, CPU, memory, and disk throttle metrics. Check execution-environment concurrency, maximum environment limits, capacity-provider vCPU limits, resource-utilization targets, traffic growth rate, and downstream backpressure. Queue bursty work and add capacity before a predictable event.

Requests Interfere with Each Other

Audit global variables, shared mutable objects, temporary filenames, logging context, singleton clients, transaction state, and connection-pool behavior. Add request IDs to all temporary resources and logs, then run concurrent isolation tests.

Costs Continue After Traffic Stops

Traffic stopping does not necessarily remove baseline environments. Set both minimum and maximum execution environments to zero or delete the capacity provider when appropriate. Verify that managed-instance termination has completed.

Recommended Naming Pattern

Use names that expose environment, application, component, and trust level:
1
2
3
4
5
6
7
8
prod-lmi-trading-vpc
prod-lmi-private-a
prod-lmi-capacity-provider-sg
prod-lmi-function-execution-role
prod-lmi-capacity-provider-operator-role
prod-trading-analysis-trusted
prod-portfolio-analysis-lmi
prod-portfolio-analysis-jobs

Final Validation Record

Record the following before declaring the environment ready:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
AWS account:
AWS Region:
VPC ID:
Subnet IDs and Availability Zones:
Security group ID:
Execution role ARN:
Operator role ARN:
Capacity provider ARN:
Maximum capacity-provider vCPUs:
Function ARN:
Published function version:
Runtime and architecture:
Memory and vCPU ratio:
Timeout:
Maximum concurrency per environment:
Minimum and maximum execution environments:
SQS queue ARN, if used:
CloudWatch dashboard:
Alarm destination:
Load-test report:
Security approval:
Business owner:
Technical owner:
Shutdown owner:
Planned deactivation date:
Planned deletion date:

Official AWS References

  • AWS Lambda Managed Instances overview: https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances.html
  • Getting started with Lambda Managed Instances: https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-getting-started.html
  • Lambda Managed Instances best practices: https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-best-practices.html
  • Scaling Lambda Managed Instances: https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-scaling.html
  • Lambda Managed Instances networking: https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-networking.html
  • Lambda Managed Instances supported runtimes: https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-runtimes.html
  • Lambda Managed Instances quotas: https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-quotas.html
  • Lambda Managed Instances troubleshooting: https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances-troubleshooting.html

Series: Financial Service (19 articles)

  1. 1
    AWS Lambda MicroVMs and the End of Repeated Application Cold Initialization
  2. …
  3. 4
    Set Up AWS Lambda Managed Instances Through the AWS Console This article
  4. 5
    Lambda Durable Functions for a Governed Three-Level Order-Book Workflow
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article