Error: getaddrinfo ENOTFOUND api.internal.acme.io

What it means

Before a Lambda can connect to anything by name, it has to turn that name into an address. That lookup goes to the VPC's resolver when the function is VPC-attached, and to AWS-managed DNS when it is not. ENOTFOUND is the resolver answering definitively: no such name.

The word definitively is what makes this error more tractable than its neighbours. Something answered. The function reached a resolver, the resolver looked, and it reported the name does not exist. That eliminates a large family of connectivity problems in one step — routes, NAT gateways and security groups are all working well enough to reach DNS, so whatever is wrong is about the name rather than about the path.

For a VPC-attached function the usual culprit is scope rather than spelling. Private hosted zones answer only for the VPCs they are associated with, so an internal hostname that resolves perfectly from a bastion host, a CI runner, or another account's workload returns NXDOMAIN from a Lambda in a VPC the zone was never attached to. Nothing about the name is wrong; the function is simply asking a resolver that has never been told about it.

The other recurring case is a VPC with enableDnsSupport switched off. A default VPC has it on, and a hand-built or older Terraform-managed one often does not. The symptom is total rather than selective: every name fails, including public ones, because there is no resolver at the .2 address for the function to consult at all. That distinction — one name failing versus every name failing — is usually visible in the logs of a single invocation, and it separates a zone association problem from a VPC attribute problem before you touch anything.

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

Read the hostname in the message and ask whether it is public or private. A public name that fails to resolve points at DNS configuration in the VPC; a private name — an internal service, a Route 53 private hosted zone entry, an RDS endpoint — points at the zone not being associated with the VPC the function runs in.

Distinguish it from its neighbours. ENOTFOUND is a definitive negative answer: something answered and said the name does not exist. EAI_AGAIN is a timeout talking to the resolver, which is a different failure with a different fix. And ECONNREFUSED means the name resolved fine and the connection was refused, so DNS was never the problem.

Causes, most likely first

Fixes

bashaws ec2 describe-vpc-attribute --vpc-id vpc-0abc --attribute enableDnsSupport
aws ec2 describe-vpc-attribute --vpc-id vpc-0abc --attribute enableDnsHostnames

aws ec2 modify-vpc-attribute --vpc-id vpc-0abc --enable-dns-support
aws ec2 modify-vpc-attribute --vpc-id vpc-0abc --enable-dns-hostnames

bashaws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z0123456789ABCDEFGHIJ \
  --vpc VPCRegion=us-east-1,VPCId=vpc-0abc

jsimport { Resolver } from "node:dns/promises";

export const handler = async () => {
  const resolver = new Resolver();
  try {
    return { addresses: await resolver.resolve4(process.env.TARGET_HOST) };
  } catch (error) {
    // code is ENOTFOUND, EAI_AGAIN, ESERVFAIL — each means something different
    return { failed: error.code, host: process.env.TARGET_HOST };
  }
};

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
• Amazon VPC User Guide — DNS attributes for your VPC