Error: connect ECONNREFUSED 10.0.4.22:5432

What it means

Of the four ways a network call can fail on Lambda, this is the one that tells you the most. ECONNREFUSED is a TCP reset: the SYN packet arrived at a live machine, the kernel there found nothing bound to that port, and it sent back a refusal. Every layer below the service — DNS, routing, NAT, security groups, network ACLs — did its job.

That eliminates most of the VPC problem space in one reading. If security groups were blocking the traffic you would get ETIMEDOUT, because a dropped packet produces silence rather than a refusal. If the name were wrong you would get ENOTFOUND. Getting a reset means the address is right, the path is open, and the only thing missing is a listener.

The single most common instance on Lambda is 127.0.0.1. A Lambda execution environment contains your function and the runtime — no database, no cache, no sidecar. Code that ran under Docker Compose, or on a server where Postgres happened to be local, carries a connection string that was perfectly correct in its original home and refers to nothing here. The error is immediate and the address in the message names the mistake outright.

The other case worth recognising is failover. During an RDS or ElastiCache failover the old host stays up while the service stops accepting connections, and DNS takes a moment to move. In that window every function gets a refusal, all at once, and then the problem disappears on its own. A burst of ECONNREFUSED across every concurrent execution followed by clean recovery is that pattern — and it is a case for a short bounded retry rather than for changing any configuration.

What it looks like in CloudWatch

This is the shape the failure arrives in: the lines of one invocation scattered among everything else the log group received at the same moment.

The panel on the right is generated by running the excerpt on the left through the same parser that powers the free web stitcher — it is what the tool actually produces for this input, not an illustration of it.

How to confirm it from the logs

The address and port in the message are the whole diagnosis. 127.0.0.1 or localhost means the code is trying to reach something in its own container — there is nothing else there, and this is almost always code carried over from a Docker or local development setup. A private address means the host is reachable and the service is not listening, or is listening on a different port.

Contrast it with the alternatives, because the distinction is precise and useful. ECONNREFUSED is immediate — the reset comes back in milliseconds. ETIMEDOUT takes seconds and means nothing answered at all, which points at routing or security groups. ENOTFOUND means the name never resolved. Getting a refusal means you are further along than either of the others.

Causes, most likely first

Fixes

js// Carried over from docker-compose — nothing listens here in Lambda.
// const redis = createClient({ url: "redis://localhost:6379" });

const redis = createClient({ url: process.env.REDIS_URL });

bashaws rds describe-db-instances --db-instance-identifier orders-prod \
  --query 'DBInstances[0].Endpoint'

jsasync function connectWithRetry(attempts = 3) {
  for (let attempt = 1; attempt <= attempts; attempt += 1) {
    try {
      return await pool.connect();
    } catch (error) {
      if (error.code !== "ECONNREFUSED" || attempt === attempts) throw error;
      await new Promise((r) => setTimeout(r, 2 ** attempt * 100));
    }
  }
}

Also seen as

The same underlying failure, worded differently by a different runtime, SDK version, or logging layer. All of these land here — there is no separate page for each phrasing.

Related errors

Errors that show up alongside this one, or that people mistake for it.

References

• AWS Lambda Developer Guide — Troubleshoot networking issues
• AWS Lambda Developer Guide — Using Amazon RDS Proxy with Lambda