AWS Systems Architect Professional

AWS Lambda Functions, Invocation, Scaling, and VPC Networking – SAP-C02 Study Guide

Learn AWS Lambda execution roles, pricing, invocation models, concurrency, VPC access, monitoring, and SAP-C02 architecture tradeoffs.

AWS Systems Architect ProfessionalAWS Systems Architect ProfessionalUpdated Sep 1, 2026
Study options
WatchComing later
ListenComing later
ReadAvailable
ReviewComing later

Study guide

Technical reference and lesson notes

Purpose of This Lesson

AWS Lambda runs application code without requiring you to provision or manage servers. A Lambda function is packaged code that executes in response to an event, such as an AWS service notification, an API request, or a direct SDK invocation.

For the AWS Certified Solutions Architect – Professional exam, Lambda questions commonly test invocation behavior, execution permissions, concurrency, runtime limits, pricing, and connectivity to resources in a VPC.

Key Concepts

Lambda Functions and Event-Driven Execution

A Lambda function contains code and its runtime configuration. Creating or uploading a function does not cause it to consume compute resources continuously. Charges are incurred when the function is invoked and executes.

A function can be triggered by:

  • AWS services and event sources
  • Applications using the AWS SDK
  • AWS APIs
  • Event-driven integrations that invoke Lambda asynchronously or through an event source mapping

The function receives an event payload and uses that input to perform an operation, such as writing to Amazon CloudWatch Logs, placing a message on a queue, or updating an Amazon DynamoDB table.

Packaging and Runtimes

Lambda supports multiple programming languages and runtimes, including:

  • Python
  • Node.js
  • Java
  • Go
  • Ruby
  • PowerShell
  • Custom runtimes and compiled languages such as C-based applications

Code can be packaged as a ZIP deployment package. Lambda also supports other packaging approaches, such as container images, when the application is better suited to that model.

Memory, CPU, and Pricing

Lambda pricing is primarily influenced by:

  • Allocated memory
  • Function execution duration
  • Number of requests

The memory setting also determines the proportional amount of CPU and other compute capacity available to the function. Increasing memory can therefore improve performance, not merely increase the function’s memory space.

A higher memory allocation may reduce execution time enough to lower total compute cost, so performance and cost should be tested rather than evaluated from memory price alone.

A Lambda invocation can run for a maximum of 15 minutes. Workloads that exceed this limit generally require a different design, such as AWS Batch, Amazon ECS, Amazon EC2, or a workflow that divides the work into multiple steps.

Execution Role and Least Privilege

A Lambda function uses an IAM execution role to obtain permissions when its code calls AWS services. The role should grant only the actions and resources required by the function.

Examples include:

  • logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents for CloudWatch Logs
  • sqs:SendMessage to publish to an Amazon SQS queue
  • DynamoDB write permissions to add or update table items
  • Permissions to read objects from an Amazon S3 bucket

The permissions of the developer or deployment pipeline are separate from the permissions granted to the running function. A developer may be allowed to deploy a function, while the function itself receives a narrowly scoped runtime role.

Monitoring and Logging

Lambda integrates with Amazon CloudWatch for operational visibility. Common monitoring data includes:

  • Invocation count
  • Errors
  • Duration
  • Throttles
  • Concurrent executions
  • Logs emitted by the function

Applications should produce structured, useful logs and should expose enough information to diagnose failures without logging sensitive data.

Synchronous and Asynchronous Invocation

The invocation type determines how the caller receives results and how failures are handled.

Invocation modelCaller behaviorTypical useImportant consideration
SynchronousCaller waits for a responseRequest/response APIs and interactive applicationsCaller receives the function result or error
AsynchronousLambda accepts and queues the event, then returns immediatelyNotifications and background processingCaller does not receive the final function result directly
Event source pollingLambda polls a source and invokes the function with batchesAmazon SQS, streams, and similar sourcesScaling, batching, retries, and checkpoint behavior depend on the source

For asynchronous invocation, Lambda manages delivery and retry behavior, but durable failure handling should be designed explicitly. A dead-letter destination or an on-failure destination may be appropriate depending on the integration.

Synchronous callers must generally implement their own retry and timeout strategy. Retrying a non-idempotent operation can create duplicate side effects.

Horizontal Scaling and Concurrency

Lambda scales horizontally by running multiple execution environments in parallel. Each concurrent invocation can use a separate execution environment, allowing a function to handle multiple requests at once.

Scaling is constrained by concurrency controls, including:

  • Regional account concurrency quotas
  • Function-level reserved concurrency
  • Optional provisioned concurrency for reducing cold-start latency
  • Downstream service limits
  • Event source scaling behavior

When available concurrency is exhausted, Lambda throttles new invocations. Throttling is not the same as an application error; it indicates that capacity or a configured limit has been reached. The appropriate response depends on the invocation model and event source. For example, an asynchronous event may be retried, while a synchronous caller may receive a throttling response.

Reserved concurrency can protect a critical function from noisy neighbors or reserve capacity for that function. It can also unintentionally prevent scaling if configured too low.

Connecting Lambda to a VPC

Lambda functions are regional and do not automatically have network access to resources inside a customer VPC. To allow access to private VPC resources, configure the function with:

  • A VPC
  • One or more subnets
  • One or more security groups

Lambda creates and manages network interfaces in the selected subnets for the function’s VPC connectivity. The security groups control traffic to and from those interfaces.

VPC attachment does not automatically provide internet access. If a function in private subnets must reach a public API or download content from the internet, the subnet route table must send outbound traffic to a NAT gateway in a public subnet. That public subnet requires a route to an internet gateway.

The resulting path is typically:

Lambda execution environment
        -> private subnet route table
        -> NAT gateway in a public subnet
        -> Internet Gateway
        -> public internet

The NAT gateway provides outbound translation; it does not make the private Lambda function directly reachable from the internet.

For AWS service access, prefer private connectivity where appropriate, such as VPC endpoints. This can reduce NAT processing, improve network isolation, and avoid unnecessary internet routing.

Exam-Relevant Takeaways

  • Lambda is event-driven and runs code only when invoked.
  • Memory allocation affects both available memory and proportional compute capacity.
  • Lambda execution duration is limited to 15 minutes.
  • The function’s IAM execution role controls access to AWS services during execution.
  • Synchronous invocation returns the function result to the caller.
  • Asynchronous invocation queues the event and returns before the function completes.
  • Lambda scales through parallel execution environments, subject to concurrency limits.
  • VPC configuration requires selecting subnets and security groups.
  • A Lambda function configured for a VPC does not automatically have internet access.
  • Private-subnet internet access generally requires a NAT gateway and appropriate route tables.
  • More concurrency can overload downstream databases, APIs, or queues even when Lambda itself can scale.
  • Idempotency is essential when retries or duplicate event delivery are possible.

Architecture Decision Guide

RequirementSuitable Lambda designMain tradeoff or risk
Short-lived event processingLambda triggered by an AWS service or event busMust fit within the execution timeout and handle retries
Synchronous API requestAPI integration invoking Lambda synchronouslyClient latency includes function startup and execution time
Background notification processingAsynchronous Lambda invocationFinal success is not returned directly to the original caller
Access to a private databaseLambda attached to private VPC subnetsRequires subnet, route, security group, and database capacity planning
Private Lambda needs public API accessPrivate subnets routed through a NAT gatewayAdds cost, dependency, and an additional network hop
High request concurrencyStandard Lambda scaling with quota reviewDownstream systems may become the bottleneck
Protection for a critical functionReserved concurrencyCan limit the function if set too low
Reduced cold-start latencyProvisioned concurrency where supportedAdditional cost and capacity planning
Work longer than 15 minutesSplit the workflow or use ECS, AWS Batch, or EC2Requires orchestration or infrastructure management

Common Exam Traps

  • Assuming VPC attachment provides internet access: A VPC-connected function in private subnets needs routes through a NAT gateway for internet-bound traffic.
  • Confusing the execution role with the deployment role: The execution role is assumed by Lambda while the function runs; it is not the IAM identity that uploads the code.
  • Treating asynchronous invocation as guaranteed success: Lambda accepts the event before processing completes. Failures, retries, and discarded events require an explicit operational design.
  • Ignoring downstream limits: Lambda can scale rapidly, but a relational database or third-party API may not tolerate the resulting concurrency.
  • Using synchronous invocation for long-running work: The caller remains blocked and may time out even if Lambda has not reached its 15-minute limit.
  • Assuming more memory only increases cost: More memory also provides more CPU. A larger allocation may reduce duration and improve total cost or latency.
  • Forgetting idempotency: Retries and duplicate delivery can repeat database writes, payments, notifications, or other side effects.
  • Using a NAT gateway when a VPC endpoint is more appropriate: Access to supported AWS services can often remain on private networking through gateway or interface endpoints.

Real-World Engineer Notes

  • Use separate IAM roles for deployment and runtime execution, and scope runtime permissions to specific resources.
  • Measure duration, error rates, throttles, and concurrency under realistic load. Do not select memory solely from the application’s idle behavior.
  • Design functions to be stateless. Store durable state in services such as Amazon S3, DynamoDB, or a database rather than relying on a particular execution environment.
  • Make handlers idempotent and record event identifiers or operation tokens when duplicate processing would be harmful.
  • Keep VPC-attached functions in subnets with sufficient IP capacity. Large bursts of execution can expose subnet address limitations.
  • Use security groups and network ACLs deliberately. A Lambda security group must permit the required traffic to the target resource, while the target’s security group must allow inbound traffic from the Lambda security group where applicable.
  • Minimize unnecessary NAT traffic. VPC endpoints for supported AWS services can reduce cost and simplify egress controls.
  • Treat CloudWatch Logs as an operational dependency and control retention to avoid indefinite storage growth.
  • For bursty workloads, place work behind a queue when the downstream service needs backpressure and controlled consumption rather than unrestricted parallelism.

Quick Reference Summary

  • Execution model: Event-driven, short-lived function execution.
  • Maximum duration: 15 minutes per invocation.
  • Pricing drivers: Requests, allocated memory, and execution duration.
  • Runtime permissions: IAM execution role.
  • Monitoring: Amazon CloudWatch metrics and logs.
  • Synchronous invocation: Caller waits for the result.
  • Asynchronous invocation: Lambda accepts and queues the event for processing.
  • Scaling: Parallel execution environments constrained by concurrency quotas and downstream capacity.
  • VPC access: Configure VPC, subnets, and security groups.
  • Private-to-internet access: Private subnet route to a NAT gateway, with the NAT gateway in a public subnet using an internet gateway.
  • Core design concerns: Idempotency, retries, least privilege, observability, and downstream throttling.

Flashcards

  1. Q: What causes a Lambda function to execute?

A: An event from an AWS service, an application or SDK invocation, or a direct AWS API invocation.

  1. Q: What two primary execution settings influence Lambda compute pricing?

A: Allocated memory and execution duration, in addition to request volume.

  1. Q: What else does increasing Lambda memory generally provide?

A: A proportional increase in CPU and other compute capacity.

  1. Q: What is the maximum execution duration of a Lambda invocation?

A: 15 minutes.

  1. Q: Which IAM role grants a running Lambda function access to AWS services?

A: The Lambda execution role.

  1. Q: How does synchronous invocation differ from asynchronous invocation?

A: Synchronous invocation waits for and returns the function result; asynchronous invocation accepts the event and returns before processing completes.

  1. Q: How does Lambda handle multiple concurrent requests?

A: It creates or uses multiple execution environments and runs invocations in parallel, subject to concurrency limits.

  1. Q: What networking configuration is needed for Lambda to access private VPC resources?

A: A selected VPC, subnets, and security groups, plus correctly configured routes and target-resource permissions.

  1. Q: Does placing Lambda in a private subnet automatically provide internet connectivity?

A: No. The private subnet needs a route to a NAT gateway, and the NAT gateway needs a route through an internet gateway.

  1. Q: Why can excessive Lambda concurrency be dangerous?

A: It can overwhelm downstream services such as databases, queues, APIs, or third-party systems.

  1. Q: What is reserved concurrency used for?

A: To reserve capacity for a function and/or limit its maximum concurrency.

  1. Q: Why should Lambda handlers be idempotent?

A: Events may be retried or delivered more than once, so repeated processing should not create unintended duplicate effects.

Practice Questions

Question 1

A company runs a Lambda function in private subnets. The function must call a public third-party API. The private subnets have no direct route to an internet gateway. Which architecture meets the requirement?

A. Attach an internet gateway directly to the private subnets.
B. Deploy a NAT gateway in a public subnet and route private-subnet internet traffic through it.
C. Add a public IP address to the Lambda execution environment.
D. Attach a VPC endpoint for the third-party API.

Correct answer: B

A NAT gateway in a public subnet, with a route to an internet gateway, provides outbound internet access for resources in private subnets. Lambda execution environments do not receive public IP addresses directly. A VPC endpoint is suitable only when the destination supports the relevant AWS private connectivity option.

Question 2

A Lambda function writes records to a DynamoDB table but receives AccessDeniedException. The function executes successfully when tested with an administrator’s credentials. What is the most likely fix?

A. Grant administrator permissions to the Lambda service.
B. Add the required DynamoDB actions and table resource to the function’s IAM execution role.
C. Add an internet gateway to the Lambda subnet.
D. Increase the function timeout.

Correct answer: B

The function uses its execution role, not the credentials of the person who deployed or tested it. The role must allow the required DynamoDB actions on the target table.

Question 3

An application invokes Lambda synchronously through an API. During traffic spikes, callers receive throttling responses. The function’s downstream database is already near its connection limit. Which solution best addresses the architectural risk?

A. Remove all Lambda concurrency limits.
B. Increase Lambda memory without testing.
C. Introduce controlled buffering or throttling and protect the database from excessive concurrency.
D. Place the function in a public subnet.

Correct answer: C

Lambda’s ability to scale does not mean the database can accept unlimited parallel work. Queueing, controlled concurrency, connection management, and appropriate reserved concurrency can protect the downstream system. Removing limits could make the overload worse.

Question 4

A workload requires a single computation that may run for 40 minutes. Which design is most appropriate?

A. Configure a Lambda timeout of 40 minutes.
B. Use Lambda with a larger memory allocation only.
C. Split the work into shorter steps or use a service designed for longer-running processing.
D. Invoke the Lambda function asynchronously and ignore the timeout.

Correct answer: C

Lambda has a maximum invocation duration of 15 minutes. The workload must either be decomposed into shorter operations or moved to a service such as Amazon ECS, AWS Batch, or Amazon EC2.

Question 5

A Lambda function processes asynchronous events that may be retried. It charges a customer’s account as a side effect. Which implementation requirement is most important?

A. Make the function idempotent using an operation identifier or deduplication record.
B. Place the function in a public subnet.
C. Disable CloudWatch Logs.
D. Use the maximum available memory.

Correct answer: A

Asynchronous processing can involve retries or duplicate delivery. An idempotent design ensures that repeated handling of the same logical operation does not create multiple charges.