Development with AWS Services
Developing and Tuning AWS Lambda Functions
CoreConfigure, integrate, test, protect, and tune Lambda functions across private access, invocation lifecycle, batching, packaging, and concurrency boundaries.
Aligned to AWS Certified Developer - Associate (DVA-C02) Version 2.1, verified August 23, 2026.
Why this matters
Lambda questions combine code with runtime configuration. A correct handler can still fail because its VPC attachment, execution role, timeout, event source mapping, failure destination, batch behavior, or concurrency setting is wrong.
Must Know
- To reach private VPC resources, configure the function for the required VPC subnets and security groups and allow the execution role to manage the network interfaces Lambda needs; this is application connectivity, not VPC design.
- Environment variables hold runtime configuration; memory also affects available CPU, timeout bounds one invocation, reserved concurrency reserves and caps concurrency, and provisioned concurrency pre-initializes environments to reduce startup latency.
- Lambda layers can share compatible dependencies; extensions integrate monitoring, security, and governance tooling into the execution environment.
- Asynchronous destinations can route success and failure invocation records with request and response context. A Lambda dead-letter queue retains discarded events with less lifecycle context.
- For an SQS event source, configure failure redrive on the SQS queue rather than treating the function asynchronous-invocation DLQ as the answer.
- Event source mappings for streams invoke functions with batches. Code must iterate records, preserve idempotency, and handle the configured batch-failure behavior.
- Tune from measurements: memory changes compute allocation, initialization work can be reused outside the handler, and connection reuse can reduce repeated setup.
- Representative tests assert handler outputs and side effects for valid, invalid, duplicate, and failing events.
Compare and Distinguish
- Reserved vs provisioned concurrency: reserved concurrency isolates and caps a function; provisioned concurrency keeps environments initialized to reduce startup latency.
- Destination vs dead-letter queue: destinations can route success or failure records with invocation details; a function DLQ is a failure-only retention path with the original event and limited attributes.
- Direct asynchronous invocation vs event source mapping: Lambda manages retries for async invocations, while a poller-based event source such as SQS or Kinesis has source-specific batching and failure controls.
- ZIP vs layer vs container image: ZIP and container image are deployment package forms; a layer is shared compatible content attached to a ZIP-based function, not a third package type.
- Memory tuning vs concurrency: memory/compute changes per-invocation work; concurrency changes how many invocations run in parallel.
Scenario examples
- Scenario: A function must connect to an existing private database. Attach it to the approved VPC subnets/security groups and give its role the required network-interface permissions.
- Scenario: A function overwhelms a fixed connection pool. Set reserved concurrency to the safe parallel limit; more memory does not cap simultaneous calls.
- Scenario: Operations needs both successful and failed async outcomes with response context. Configure separate Lambda destinations.
- Scenario: Kinesis invokes a function with records requiring transformation. Process the batch deliberately and make repeated record handling safe.
Exam traps
- Lambda does not gain private resource access merely because both resources are in the same account.
- Provisioned concurrency is not a maximum-concurrency control.
- A Lambda event can contain multiple records; code that reads only the first record silently loses work.
- Increasing timeout does not fix CPU-bound code, and increasing memory does not fix a blocked dependency.
- Layers must be compatible with the runtime and architecture and do not change the configured handler automatically.
Key takeaways
- Treat code, event source, execution role, network attachment, and runtime settings as one Lambda integration.
- Select failure routing from invocation mode and the information recovery needs.
- Keep batch processing retry-safe and test representative service event shapes.
- Tune memory, duration, initialization, and concurrency from observed constraints.
How it works
- An event source invokes Lambda directly or through an event source mapping.
- Lambda initializes an execution environment from the configured runtime, handler, package, layers, extensions, memory, and environment values.
- The execution role authorizes downstream service calls and any required VPC network-interface operations.
- Invocation results follow source-specific retry, checkpoint, destination, or redrive behavior.
When to use it
- Use reserved concurrency to reserve capacity or protect a downstream system with a hard function cap.
- Use provisioned concurrency when startup latency for an interactive workload is the measured concern.
- Use asynchronous destinations when downstream processing needs invocation outcome context.
- Use event source mappings for supported poll-based queues and streams.
Security and governance implications
- Scope the execution role to required network and downstream service actions.
- Keep secrets out of plain environment values; retrieve rotating secrets under the workload role.
- Treat event payloads as untrusted input and redact sensitive fields from failure records and logs.
- Constrain failure destinations so invocation records cannot be delivered to an unintended resource.
Failure signals and diagnosis
- For a timeout, separate slow initialization, CPU work, downstream wait, batch size, and insufficient timeout before changing configuration.
- For VPC failures, inspect attachment, security groups, existing routes, DNS, role permissions, and the target endpoint without redesigning the network.
- For missing async failures, inspect retry exhaustion, destination/DLQ permissions, delivery-failure metrics, and payload limits.
- For throttling, identify account concurrency, reserved concurrency, event-source maximum concurrency, and downstream limits.
More detail
- Configuration values belong outside the handler artifact when they vary by environment; sensitive rotating values belong in a managed secret service.
- Lambda service integrations have source-specific event shapes, retry behavior, batching, and permissions.
- Near-real-time does not mean exactly-once; application code must handle the source delivery model.
- Testing must assert behavior, not merely invoke the function and inspect that it ran.
Ready for the quiz?
- Which settings let Lambda reach an existing private resource?
- How do reserved and provisioned concurrency solve different problems?
- When does a destination carry more useful recovery context than a DLQ?
- Why must stream handlers expect duplicate records and batches?
- What evidence should drive a memory change?
Related objectives
- D1.2 — Develop code for AWS Lambda
- 1.2.1 — Describe the access of private resources in VPCs from Lambda code
- 1.2.2 — Configure Lambda functions by defining environment variables and parameters (for example, memory, concurrency, timeout, runtime, handler, layers, extensions, triggers, destinations)
- 1.2.3 — Handle the event lifecycle and errors by using code (for example, Lambda Destinations, dead-letter queues)
- 1.2.4 — Write and run test code by using AWS services and tools
- 1.2.5 — Integrate Lambda functions with AWS services
- 1.2.6 — Tune Lambda functions for optimal performance
- 1.2.7 — Use Lambda functions to process and transform data in near real time