Introduction

When API Gateway invokes a Lambda function, the caller’s public IP address is already included in the event payload. The exact path depends on whether you are using API Gateway REST API payloads or HTTP API v2 payloads, so the main job is reading the right field rather than making an extra network call.

Read the IP from the Event Object

For API Gateway REST APIs, the source IP is commonly available at event.requestContext.identity.sourceIp.

For HTTP API v2 payloads, it is commonly at event.requestContext.http.sourceIp.

A defensive Node.js handler can check both.

1exports.handler = async (event) => {
2  const sourceIp =
3    event?.requestContext?.http?.sourceIp ||
4    event?.requestContext?.identity?.sourceIp ||
5    null;
6
7  return {
8    statusCode: 200,
9    body: JSON.stringify({ sourceIp }),
10  };
11};

That is usually all you need.

Understand Why the Value Is There

API Gateway sits in front of the Lambda function, so Lambda does not see a raw client socket directly. Instead, API Gateway extracts request metadata and places it into the event object.

That is why trying to inspect the Lambda runtime machine or asking an external “what is my IP” service is the wrong approach for this problem. Those would tell you about AWS infrastructure, not the original caller.

Headers Can Help, but the Event Field Is Better

You may also see client IP information in forwarded headers such as X-Forwarded-For. That can be useful for debugging, but the structured request-context field is usually the cleaner source in Lambda code.

const forwardedFor = event?.headers?.['x-forwarded-for'] || event?.headers?.['X-Forwarded-For'];
console.log(forwardedFor);

If you inspect headers, remember that X-Forwarded-For may contain multiple comma-separated IP addresses due to proxy hops. The request-context source IP is often easier to reason about.

Check Your Payload Version

This question often turns into a bug simply because the Lambda function expects one event shape and receives another. API Gateway REST APIs and HTTP APIs do not serialize request context identically.

If sourceIp appears missing, log a sanitized sample event structure and confirm which gateway type and payload version the function is actually receiving. The data is often present, just under a different path than the code expects.

Log the Value Early When Debugging

When you are verifying this in a new Lambda integration, log the parsed IP and the request-context shape early in development.

1console.log(JSON.stringify({
2  sourceIp,
3  requestContext: event?.requestContext,
4}));

That makes it much easier to spot whether the issue is a wrong property path, a payload-version mismatch, or an upstream proxy assumption.

Be Careful About What “User IP” Means

The value you receive is generally the public source IP that API Gateway observed. Depending on the network path, that may represent:

• the end user’s public IP
• a corporate proxy or NAT gateway
• another upstream proxy layer

So the field is useful, but it is not proof of a unique physical device or human identity.

Common Pitfalls

• Trying to call an external IP-check service from Lambda instead of reading the API Gateway event.
• Reading the wrong request-context field for the API Gateway payload version in use.
• Treating X-Forwarded-For as a single IP when it may contain a chain of addresses.
• Assuming the observed public IP uniquely identifies one user or device.
• Logging request metadata incompletely and then losing the ability to debug proxy-related behavior.

Summary

• The caller IP is usually already present in the API Gateway event sent to Lambda.
• For REST API payloads, check requestContext.identity.sourceIp.
• For HTTP API v2 payloads, check requestContext.http.sourceIp.
• Confirm the event shape before assuming the field is missing.
• Treat the value as network-origin information, not as a guaranteed unique user identity.