Introduction

Calling a REST API from AWS Lambda with Node.js is straightforward because a Lambda function is just Node.js code running inside a managed runtime. The important parts are choosing a simple HTTP client, setting timeouts, handling retries carefully, and understanding that network access depends on whether the function runs in a VPC.

Use the Built-In fetch in Modern Lambda Runtimes

In current Node.js Lambda runtimes, the easiest option is the built-in fetch API. That avoids an extra dependency such as axios for many use cases.

A minimal handler that calls a JSON API looks like this:

1export const handler = async () => {
2  const response = await fetch("https://api.example.com/orders/42", {
3    method: "GET",
4    headers: {
5      Accept: "application/json"
6    }
7  });
8
9  if (!response.ok) {
10    throw new Error(`Upstream API returned ${response.status}`);
11  }
12
13  const data = await response.json();
14  return {
15    statusCode: 200,
16    body: JSON.stringify(data)
17  };
18};

That is enough for public APIs or internal APIs reachable from the Lambda runtime.

Add Timeouts and Clear Error Handling

The default failure mode for remote calls is often too vague. A production Lambda should fail with enough context to debug the upstream problem.

1export const handler = async () => {
2  const controller = new AbortController();
3  const timeout = setTimeout(() => controller.abort(), 3000);
4
5  try {
6    const response = await fetch("https://api.example.com/health", {
7      signal: controller.signal,
8      headers: { Accept: "application/json" }
9    });
10
11    if (!response.ok) {
12      const body = await response.text();
13      throw new Error(`HTTP ${response.status}: ${body}`);
14    }
15
16    const payload = await response.json();
17    return {
18      statusCode: 200,
19      body: JSON.stringify(payload)
20    };
21  } finally {
22    clearTimeout(timeout);
23  }
24};

This gives you a defined upper bound on the outbound request instead of waiting until the whole Lambda invocation times out.

POST JSON to an API

Sending data is just as simple. Serialize the body and set the content type explicitly.

1export const handler = async () => {
2  const order = {
3    id: 42,
4    status: "queued"
5  };
6
7  const response = await fetch("https://api.example.com/orders", {
8    method: "POST",
9    headers: {
10      "Content-Type": "application/json",
11      Accept: "application/json"
12    },
13    body: JSON.stringify(order)
14  });
15
16  const result = await response.json();
17
18  return {
19    statusCode: response.status,
20    body: JSON.stringify(result)
21  };
22};

This pattern is common when Lambda is acting as a small integration layer between AWS services and an external system.

VPC Networking Changes the Failure Mode

A Lambda function without VPC attachment can reach the public internet by default. Once you attach it to private subnets in a VPC, outbound internet access requires the right route through a NAT gateway or equivalent egress path.

So if your code works locally but times out in Lambda, check networking before rewriting the handler.

Typical signs of a network problem:

• long timeouts instead of fast HTTP errors
• DNS resolution errors
• connection refused from a private target that is not reachable from the selected subnets

This operational detail matters more than the choice between fetch and axios.

Keep Secrets Out of the Source Code

API keys and bearer tokens should come from environment variables or AWS Secrets Manager, not hard-coded strings.

1export const handler = async () => {
2  const token = process.env.API_TOKEN;
3  if (!token) {
4    throw new Error("Missing API_TOKEN environment variable");
5  }
6
7  const response = await fetch("https://api.example.com/private", {
8    headers: {
9      Authorization: `Bearer ${token}`,
10      Accept: "application/json"
11    }
12  });
13
14  return {
15    statusCode: response.status,
16    body: await response.text()
17  };
18};

If the secret changes frequently or is shared across multiple functions, Secrets Manager is usually a better operational choice than plain environment variables.

Reuse Connections Across Invocations

A Lambda execution environment can be reused for multiple invocations. Put reusable clients outside the handler when you can. For simple fetch calls this matters less, but for database or SDK clients it helps reduce cold-start and per-request overhead.

You should also avoid blind retries inside the handler. If the event source already retries, doubling the retry logic can make failures noisier and more expensive.

Example With axios

If your team already uses axios, it works fine too.

1import axios from "axios";
2
3export const handler = async () => {
4  const response = await axios.get("https://api.example.com/items", {
5    timeout: 3000,
6    headers: { Accept: "application/json" }
7  });
8
9  return {
10    statusCode: 200,
11    body: JSON.stringify(response.data)
12  };
13};

The built-in fetch is usually enough, but axios still provides a familiar API for teams already standardized on it.

Common Pitfalls

Assuming the code has internet access after placing Lambda in private subnets. VPC routing often causes the real failure.

Leaving the outbound request without a timeout. Then the Lambda timeout becomes your only protection.

Hard-coding API keys in the source code. Use environment variables or Secrets Manager.

Retrying too aggressively inside the handler. Coordinate retries with the event source.

Ignoring non-200 responses and trying to parse everything as success JSON.

Summary

• A Lambda function can call REST APIs with the built-in fetch in modern Node.js runtimes.
• Add explicit timeouts and clear error messages.
• Use environment variables or Secrets Manager for credentials.
• Check VPC egress if requests time out in AWS but work locally.
• Keep the handler small and let the network and retry design stay deliberate.