Error: getaddrinfo EAI_AGAIN secretsmanager.us-east-1.amazonaws.com

What it means

EAI_AGAIN is the resolver library reporting that a lookup did not complete in time. The name is short for "try again", and it exists because DNS is expected to be occasionally busy — a transient condition a retry would clear.

Inside a VPC-attached Lambda it usually means something else entirely. The function is not being told to wait its turn; it is failing to reach a resolver at all. The query goes out over UDP 53 to the VPC resolver and nothing comes back, so the library waits out its timeout and reports the only thing it can distinguish, which is that no answer arrived. A permanent routing or filtering problem and a momentarily overloaded resolver produce the identical error code.

That is why the most useful first question is not why is DNS slow but is this every lookup or some of them. A blocked NACL, a disabled enableDnsSupport, or a DHCP option set pointing at unreachable name servers all produce total failure: every invocation, every name, indefinitely. Load-related failures — the per-interface DNS packet rate ceiling, reached by a function fanning out at high concurrency — produce scattered failures that track your traffic curve. The first is a configuration fix; the second is usually solved by resolving less, which mostly means constructing SDK clients at module scope so each execution environment does one lookup rather than one per request.

Network ACLs deserve particular suspicion because of how they fail. They are stateless, unlike security groups, so allowing outbound UDP 53 does nothing on its own — the response arrives on an ephemeral port and needs its own inbound rule. A VPC configured by someone thinking in security-group terms looks completely correct and drops every DNS reply, and the resulting EAI_AGAIN gives no hint that the query itself left successfully.

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

Time it. A lookup that fails after several seconds — often five, matching the resolver timeout — is a timeout; one that fails instantly is a different error wearing a similar name. Check the elapsed time between the log line before the failure and the failure itself.

Then check whether it is intermittent or total. Genuinely transient DNS pressure produces scattered failures under load. A VPC that cannot reach its resolver produces EAI_AGAIN on every lookup, from every invocation, forever — and the word "temporary" in the error is then actively misleading, because nothing about it is temporary.

Causes, most likely first

Fixes

bash# Outbound query
aws ec2 create-network-acl-entry --network-acl-id acl-0abc \
  --rule-number 110 --protocol udp --port-range From=53,To=53 \
  --cidr-block 0.0.0.0/0 --rule-action allow --egress

# Inbound response, on the ephemeral range
aws ec2 create-network-acl-entry --network-acl-id acl-0abc \
  --rule-number 110 --protocol udp --port-range From=1024,To=65535 \
  --cidr-block 0.0.0.0/0 --rule-action allow

bashaws ec2 describe-vpcs --vpc-ids vpc-0abc \
  --query 'Vpcs[0].DhcpOptionsId' --output text | \
xargs -I{} aws ec2 describe-dhcp-options --dhcp-options-ids {}

jsimport { SecretsManagerClient } from "@aws-sdk/client-secrets-manager";

// Module scope: resolved once per execution environment, reused across invocations.
const client = new SecretsManagerClient({});

export const handler = async (event) => {
  // Not: new SecretsManagerClient({}) on every request.
  return client.send(command(event));
};

yamlSecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref Vpc
    ServiceName: !Sub "com.amazonaws.${AWS::Region}.secretsmanager"
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds: !Ref PrivateSubnets

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 — DHCP option sets