Serverless Computing and Ephemeral IPs: The Servers That Don't Exist

Code That Has No Fixed Address

The traditional model of running code on the internet assumed a stable, long-lived server: rent a machine, assign it an IP address, keep it running. Whether that machine was a physical server in a colocation facility or a virtual machine in AWS EC2, it had a consistent identity. You could whitelist its IP, monitor its uptime, and SSH into it when something broke.

Serverless computing discards that model entirely. In platforms like AWS Lambda, Google Cloud Run, Azure Functions, or Cloudflare Workers, your code is packaged as a deployment artifact and stored in the cloud provider's infrastructure. Nothing runs until a request triggers it. When a trigger fires — an HTTP request, a message in a queue, a scheduled timer — the provider allocates a small execution environment, loads your code, runs it, and discards the environment when the function completes or times out. The entire lifecycle can be measured in milliseconds for simple functions.

During that execution window, the function has an IP address. It is an address assigned from the cloud provider's internal pool, allocated at startup, and returned to the pool at shutdown. The same function invoked again one second later may receive a completely different address. These are ephemeral IPs — addresses that exist only as long as the process that holds them.

How Ephemeral IP Assignment Works in AWS Lambda

When a Lambda function is triggered, the AWS control plane selects a worker host from the available fleet and starts a microVM using the Firecracker hypervisor. The microVM receives a private IP address from the VPC network connecting it to the Lambda data plane. This address is internal to AWS's infrastructure — it is not directly reachable from the public internet.

If the Lambda function makes outbound network calls — querying an external API, connecting to a database — those calls are sourced from one of the IP addresses in the NAT gateway or VPC endpoint associated with the Lambda's VPC configuration. Without explicit VPC attachment, Lambda functions run in an AWS-managed VPC and their outbound traffic is NATed through a pool of IP addresses that AWS manages and rotates across all customers using the same regional Lambda environment.

The practical implication: a Lambda function you wrote may exit one of dozens or hundreds of IP addresses on a given day. You cannot tell an external third-party API to whitelist your Lambda function’s egress IP and expect that whitelist to remain valid the next day.

Architecture: Solving the Ephemeral IP Problem

There are three standard architectural patterns for situations where serverless functions need a stable network identity:

Pattern 1: API Gateway as the Public Face

An API Gateway (AWS API Gateway, Kong, Cloudflare) sits in front of all Lambda functions and serves as the public-facing IP identity. External clients talk to the API Gateway's stable domain name or IP address. The Gateway routes requests to whichever Lambda execution environment is currently handling the function. Third parties whitelist the API Gateway's IP, not the Lambda's. This is the standard architecture for public-facing serverless APIs.

Pattern 2: NAT Gateway with Elastic IP

For serverless functions that need to call external APIs that require IP whitelisting, deploy the Lambda in a VPC and route all outbound traffic through a NAT Gateway with an Elastic IP attached. An Elastic IP is a static public IP that AWS assigns to your account and which persists until you release it. All Lambda invocations in that VPC will exit through the same Elastic IP, making whitelisting possible. The trade-off is additional cost (NAT Gateway charges per GB of data processed) and increased cold-start latency from VPC attachment overhead.

Pattern 3: VPC Endpoints for AWS-Internal Services

When Lambda functions only need to communicate with other AWS services (S3, DynamoDB, SQS), VPC endpoints allow traffic to route within the AWS backbone without traversing the public internet at all. No public IP is used or needed, and the traffic never leaves AWS's network infrastructure.

Real-World Use Cases

E-commerce checkout processing: A Lambda function processes payment gateway webhooks. The payment provider requires the webhook consumer to have a whitelisted IP. The team attaches a NAT Gateway with an Elastic IP to the Lambda's VPC. The payment provider whitelists that single Elastic IP. All webhook processing functions share the same outbound address regardless of how many parallel invocations are running.

Rate-limited third-party API calls: A Lambda function fetches data from a weather API that enforces per-IP rate limits. With ephemeral IPs, each cold start may appear to the weather API as a different client, accidentally distributing requests across IPs and complicating rate limit enforcement. Routing through a NAT Gateway with a static IP ensures consistent rate limit tracking.

Log aggregation pipeline: A serverless pipeline processes millions of log events per day using many concurrent Lambda invocations. Because the functions write to DynamoDB via VPC endpoints rather than public internet, no outbound public IP is involved at all. The architecture is simpler and does not require managing static IPs.

Comparison: Serverless vs. Traditional Server IP Behavior

Security Considerations for Ephemeral Networking

The absence of a persistent IP address is not inherently a security weakness — in many ways, it reduces the attack surface. A server that does not exist for most of the day cannot be port-scanned, probed, or attacked during those hours. There is no persistent process to exploit with a memory corruption vulnerability because the execution environment is freshly allocated for each invocation.

However, ephemeral networking introduces different security considerations:

• IAM roles replace network-based trust: Because you cannot control which IP a Lambda function will use, access controls for downstream services (databases, S3 buckets, other APIs) must be implemented through identity-based policies (IAM roles in AWS) rather than IP-based network rules. This is generally a more robust model but requires careful role design.
• Shared network infrastructure risks: Without VPC attachment, Lambda functions share network infrastructure with other AWS customers. This is a multi-tenant environment, and the security model depends entirely on AWS's hypervisor-level isolation.
• Injection attacks via event data: A Lambda function's primary attack surface is its input data — the event payload. SQL injection, command injection, and path traversal vulnerabilities in function code are the dominant threat, not network-layer attacks.

Common Misconceptions

Misconception 1: 'Serverless functions have no IP address'

Serverless functions absolutely have IP addresses during their execution window. What they lack is a persistent IP address. At the moment a Lambda function runs, it has a network interface with an assigned IP. The confusion arises because developers never need to configure or manage that IP — the platform handles it transparently.

Misconception 2: 'You can never whitelist a serverless function's IP'

You can, but you need to architect for it. By attaching a Lambda function to a VPC and routing outbound traffic through a NAT Gateway with an Elastic IP, the function's external-facing IP becomes stable and whitelistable. This is a standard, well-documented architecture pattern.

Misconception 3: 'Serverless is less secure because you don't control the infrastructure'

The opposite case can be made. The cloud provider manages OS patching, hypervisor security, network isolation, and physical data center security. The developer's security scope is reduced to the function code and its IAM permissions. Smaller scope means fewer places where mistakes can occur, assuming the developer correctly designs IAM policies and validates all input data.

Misconception 4: 'Cold starts are purely a performance problem'

Cold starts also have security relevance. During a cold start, the execution environment is freshly initialized, which means any in-memory state from previous invocations is absent. This is actually a security benefit — secrets or session data cannot accidentally persist between unrelated invocations from different users. But it also means cached security tokens or database connections must be re-established, which developers sometimes handle insecurely by storing credentials in environment variables without proper secrets management.

Pro Tips

• Use AWS Secrets Manager or Parameter Store rather than Lambda environment variables for credentials. Environment variables are decrypted and visible to anyone with IAM access to the Lambda configuration.
• Attach an Elastic IP via NAT Gateway only when you genuinely need IP whitelisting. VPC attachment adds cold-start latency (historically 1–3 seconds for ENI attachment, improved with Hyperplane ENIs but still measurable) and costs money for NAT data processing.
• Use VPC endpoints for all AWS service calls in production workloads. This keeps traffic off the public internet, eliminates the need for outbound internet gateways for AWS service calls, and often reduces latency.
• Set concurrency limits on Lambda functions that call rate-limited external APIs. Without limits, a traffic spike can spawn hundreds of parallel invocations that all hit the same external API simultaneously, exhausting rate limits and potentially causing errors.
• Monitor for unexpected IP ranges in outbound connections using VPC Flow Logs. If a Lambda function suddenly starts making connections to unexpected CIDR ranges, that may indicate a server-side request forgery (SSRF) vulnerability being exploited.
• Test your API Gateway authentication independently of your Lambda function logic. The Gateway's authorization layer is your network-level perimeter — if it can be bypassed to invoke Lambda functions directly, your network security model is incomplete.

Check how your cloud infrastructure's IPs appear to the internet