Functions that fail to start when the subnet runs out of addresses
The market-open failures stopped, and database connection counts during bursts fell dramatically once connections were reused rather than created per invocation.
Overview
VPC-attached Lambda functions need network interfaces and subnet IP addresses to scale. When a small subnet is shared with other workloads, a burst of concurrent invocations can exhaust available addresses, and the function fails before your code ever runs — which is why the application logs show nothing.
Challenge
During market-open bursts, a share of invocations failed with networking errors and no application log output. The functions were attached to two small subnets shared with other services. Every invocation also opened a fresh database connection at handler scope rather than reusing one, so a burst simultaneously exhausted subnet addresses and the database's connection limit.
Environment
VPC-attached AWS Lambda functions reaching private databases and internal services, with sharp intraday traffic bursts. AceMQ works on the customer's function configuration, networking design, and connection handling — the AWS platform itself is Amazon's.
Approach
AceMQ correlated failed invocations against subnet address utilization and concurrency to confirm exhaustion as the cause rather than an application fault. We then addressed both sides: enough address space and interface capacity to absorb the burst, and connection reuse so the database is not attacked by the same burst.
Solution
- 1Correlated invocation failures with subnet IP utilization and concurrency to confirm exhaustion
- 2Moved functions to dedicated, appropriately sized subnets across additional availability zones
- 3Moved database connection setup outside the handler so warm invocations reuse connections
- 4Introduced a connection proxy layer so burst concurrency does not translate into raw database connections
- 5Set reserved and provisioned concurrency where burst shape justified it
- 6Added alerting on subnet address utilization and function-level throttle and error metrics
Outcome
The market-open failures stopped, and database connection counts during bursts fell dramatically once connections were reused rather than created per invocation.
Technologies
Related Use Cases
AWS Lambda SQS Redrive Loop Remediation
Breaking a redrive loop where SQS messages were reprocessed indefinitely because the queue visibility timeout was shorter than the Lambda function timeout.
AWS Lambda Event-Source Architecture Consulting
Designing event-source mapping, batching, ordering, and failure handling for a Lambda estate that had grown without a consistent event architecture.
Need Expert AWS Lambda Support?
AceMQ's senior AWS Lambda engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.