Fix AWS CLI Error: Could Not Connect to Endpoint URL (DNS & Region)

If the AWS CLI is throwing Could not connect to the endpoint URL, the cause is almost always one of three things: the region your command is pointed at doesn't have the service you're calling, your machine can't resolve the AWS hostname through DNS, or something between you and the internet — a proxy, a VPN, a firewall — is silently eating the request. The counterintuitive part: most people's first move is to check their internet connection, and their internet is usually fine. The CLI can complete a Google search, open Netflix, and still fail this exact call, because the problem isn't "the internet" — it's one specific hostname, on one specific port, that nothing else you use all day happens to touch.

What "could not connect to the endpoint URL" actually means

Every AWS CLI command builds a web address before it does anything else. Type aws s3 ls and, behind the scenes, the CLI assembles something like https://s3.us-east-1.amazonaws.com/ and tries to open a connection to it — the same way your browser opens a connection when you type a web address into the bar at the top. An endpoint is just that address: the specific door on AWS's side that a particular service listens on, in a particular region, the way a building has one door for deliveries and a different door for visitors even though it's the same building. 

Also Read: AWS CLI: ExpiredToken - session credentials explained

"Could not connect to the endpoint URL" is not an AWS error. AWS never got your request. This message comes from the CLI itself, reporting that it tried to knock on that door and nothing answered — no DNS record pointing at an IP address, no TCP handshake, no response at all. That distinction matters more than it sounds like it should, because it rules out an entire category of things people check first: your access key, your secret key, your IAM permissions. None of those are even read yet when this error fires. The CLI never got far enough to present them, the same way a letter that never left your mailbox can't be rejected by the person it was addressed to.

Here's the piece that trips people up the most, and it's the one true surprise worth sitting with before you go any further: the hostname in the error message changes depending on the command you run. aws s3 ls talks to an S3 endpoint. aws ec2 describe-instances talks to an EC2 endpoint. aws health describe-events talks to a Health endpoint that, as of this writing, only exists in two US regions no matter where you are in the world. That's why the exact same laptop, the exact same network, the exact same AWS account can run one command fine and fail the next one with this identical error message — because it isn't one endpoint failing, it's a different endpoint every time, and each one has its own separate reasons to be unreachable. Fixing one command's connection problem doesn't guarantee the next command will work, and that's exactly the pattern that makes this error feel random when it isn't.

Start here: let the CLI tell you which endpoint it tried

Before you touch region settings, DNS, or a proxy config, run the failing command again with one extra flag. This single step saves more time than every other fix in this article combined, because it tells you exactly which cause you're dealing with instead of leaving you to guess your way through six sections in order.

1. Re-run the exact command that failed, adding --debug to the end of it. For example: aws s3 ls --debug.
2. The output will be long — dozens or hundreds of lines. Don't read it top to bottom. Scroll to near the bottom, where the actual error appears, right above where the traceback ends.
3. Look for a line mentioning the endpoint or the hostname it tried — it will look like a normal web address ending in .amazonaws.com.
4. Copy that exact hostname. You'll use it in the DNS test in the next section, whether or not region turns out to be the problem.
5. If you'd rather skip the wall of text, save it to a file instead: aws s3 ls --debug > debug-log.txt 2>&1, then open the file and search it for the word "endpoint."

On Windows, there's a second quick tool worth knowing before you even open a --debug log: Test-NetConnection in PowerShell. Running Test-NetConnection s3.amazonaws.com -Port 443 checks both whether the name resolves and whether port 443 is reachable, in one command, and it prints a clean true/false result instead of a wall of log lines — useful when you just want a yes-or-no answer fast, and you can save the deeper --debug read for when the quick check comes back negative.

Ethan's take: "People treat --debug like a last resort, something you reach for after you've already tried everything else. Flip that. It's the fastest diagnostic step in the whole list, and it's the one that tells you which of the next several sections actually applies to you — skip it and you're just guessing in order, checking causes one by one that might have nothing to do with what's actually happening on your machine."

Cause 1: the wrong region, or no region at all

This is the single most common cause of this error, and it's the one most how-to pages stop at, treating it as the whole answer instead of the first of several. The AWS Region you're pointed at is baked directly into the endpoint hostname — s3.us-east-1.amazonaws.com versus s3.eu-west-1.amazonaws.com are two completely different addresses, not two versions of the same one. Get the region wrong, misspell it, or leave it unset in some environments, and the CLI tries to open a connection to an address that either doesn't exist or doesn't route the way it should.

The region the CLI actually uses is decided by checking several places, in a fixed order, and stopping at the first one it finds. Get this order backwards in your head and you'll spend twenty minutes "fixing" a setting that was never being read in the first place, because something with higher precedence was quietly overriding it the whole time.

Because command-line and environment settings sit above the config file, a region you carefully set with aws configure can be silently overridden by a leftover AWS_DEFAULT_REGION environment variable you forgot you exported six months ago in a shell profile file you haven't opened since. That's a genuinely common trap, and it's invisible unless you know to check for it — the config file will say one thing, the CLI will do another, and there's no error message pointing at the mismatch.

Check what's actually being used, not what you think you set

Two commands answer this without guessing:

1. aws configure get region — returns the effective region for your active profile. If this comes back empty, no region is configured anywhere for that profile, and the CLI is likely falling back to a default that may not match the service you're calling.
2. aws configure list — shows every setting (region, credentials, output format) alongside where each one came from: the config file, an environment variable, or a command-line override. This is the one to run when a region you're sure you set doesn't seem to be taking effect, since it shows you the source column, not just the value.

To fix a wrong or missing region permanently for a profile, rather than typing --region on every single command for the rest of the week: aws configure set region us-east-1 — or, for a named profile other than default: aws configure set region us-east-1 --profile work.

The trap "just set us-east-1" doesn't cover

A lot of quick-fix guides tell you to set the region to us-east-1 and move on, and often that does work — but it works because us-east-1 happens to be the region most services are available in, not because it's universally correct for your account. Two situations where "just set a valid region" isn't the whole story:

Your resources genuinely live somewhere else. If your S3 bucket, EC2 instances, or database sit in ap-south-1, pointing the CLI at us-east-1 will connect just fine — and then return an empty list or a "not found," because you're now correctly and successfully talking to the wrong region. That's a different error message, but it starts the same way, with a region mismatch nobody noticed.

The service you're calling doesn't exist in every region. This is the one almost nobody mentions, and it's the exact cause behind several of the real support threads this problem generates. A handful of AWS services — AWS Health among them — only run their API in one or two specific regions worldwide, regardless of where your account's resources are. Point a Health command at your usual region and you'll get exactly this error, forever, because there's genuinely nothing listening there. The fix is to add --region us-east-1 (or whichever region that specific service documents) only for calls to that service, while leaving your default region alone for everything else you do.

A quieter version of this same mistake: typing a region that looks valid but isn't one. Availability zones (us-east-1a, us-east-1b) are not regions — they're subdivisions within a region — and typing one where the CLI expects a region produces this same connection failure, because there's no endpoint hostname built around an availability zone. If your region setting has a trailing letter on it, that's worth a second look before anything else.

Cause 2: DNS can't resolve the endpoint

Assuming region is correct — or you've confirmed it with aws configure list and it's not the issue — the next suspect is DNS. Every request the CLI makes starts with turning that hostname (s3.us-east-1.amazonaws.com) into an actual IP address, the way a phone book turns a name into a number before a call can go through. That translation step is called DNS resolution, and it happens on your machine, using whatever DNS server your network is configured to use — entirely separately from whether your general internet connection works.

This is why "but my Wi-Fi is fine, I'm watching YouTube right now" doesn't rule out DNS as the cause. YouTube's hostname resolved fine through your DNS server. The AWS hostname might not — because a company DNS server blocks it on purpose as a security policy, a home router's cached DNS entry is stale, or a VPN is quietly routing DNS queries somewhere that has no idea what an AWS endpoint even is.

Test DNS directly, in under a minute

Use the exact hostname you pulled from the --debug output earlier, or the generic S3 endpoint if you haven't run that yet. Windows: open Command Prompt and run nslookup s3.amazonaws.com. Mac/Linux: nslookup s3.amazonaws.com or dig s3.amazonaws.com both work; dig tends to give more detail if it's installed on your system already.

A working result returns one or more IP addresses under an "Answer" or "Address" section within a second or two. If instead you get "can't find," "server can't find," a timeout, or the tool just hangs with no response, DNS genuinely can't reach that hostname from your machine right now — and that's your answer, confirmed by a test, not guessed from a hunch.

Fixing DNS once you've confirmed it's the problem

A few things genuinely fix a DNS resolution failure for AWS endpoints, roughly cheapest and least invasive first. Switch off a VPN temporarily and retest — corporate and personal VPNs frequently push their own DNS server to your machine while connected, and that server may have no route to AWS's public DNS records, or may deliberately block cloud-provider domains as a matter of policy. If nslookup suddenly works the moment the VPN disconnects, that's confirmed, not coincidental.

Flush your local DNS cache. Windows: ipconfig /flushdns. Mac: sudo dscacheutil -flushcache followed by sudo killall -HUP mDNSResponder. This clears out a stale, previously-failed lookup your machine may be stubbornly reusing instead of trying again fresh.

Try a different DNS server temporarily — Google's 8.8.8.8 or Cloudflare's 1.1.1.1 — to isolate whether the problem is your network's usual DNS server specifically, rather than something wrong with DNS everywhere. If the AWS hostname resolves through a public DNS server but not your usual one, that points squarely at your network or router configuration, and it's worth raising with whoever manages it, whether that's IT or your own router settings on a home network.

Also worth checking on a company network: split-horizon DNS, where internal and external lookups for the same domain are deliberately answered differently depending on which network you're on. If a colleague on a different office connects fine and you don't, ask whether your two machines are pointed at different internal DNS servers — that's a configuration difference between two setups, not a fault in either one.

On a locked-down corporate network, DNS may not be something you can fix yourself at all. If a company firewall or DNS policy is intentionally blocking *.amazonaws.com, no client-side setting changes that. This is the honest limit worth naming early: if IT has to allowlist the domain, that's the actual fix, and no amount of flushing your cache substitutes for it.

Cause 3: a proxy or corporate firewall is silently eating the request

If you're on a work laptop or any network with a corporate proxy, this is genuinely the most likely cause — more likely than region, more likely than plain DNS — and it's the one people check last because it's the least obvious one to think of first. Your browser might already be configured, often automatically by IT without you doing anything yourself, to route through a proxy. The AWS CLI has no idea that configuration exists unless you tell it separately, because it doesn't read your browser's settings at all.

Jake's shop runs three PCs behind a single office router with a basic content filter. Two of them browse the web fine and still can't run a single AWS CLI command, because the filter treats amazonaws.com like an unrecognized destination and drops it rather than forwarding it — invisible in a browser, because nothing in his day-to-day browsing needs that particular hostname to load a page.

Setting the proxy the AWS CLI actually reads

The CLI reads two environment variables for this — not a setting inside aws configure, and not whatever your browser has configured, which the CLI never sees at all. Mac/Linux (current terminal session): export HTTP_PROXY=http://proxy.example.com:8080, export HTTPS_PROXY=http://proxy.example.com:8080. Windows Command Prompt (current session only): set HTTP_PROXY=http://proxy.example.com:8080, set HTTPS_PROXY=http://proxy.example.com:8080.

If your proxy requires a username and password, put them directly in the URL: http://username:password@proxy.example.com:8080. One detail worth knowing before it costs you an hour: if you accidentally set the variable in both uppercase and lowercase (HTTPS_PROXY and https_proxy) with different values, the lowercase version wins — quietly, with no warning printed anywhere. Set each one exactly once, in one case, to avoid chasing a phantom mismatch between two variables you thought were the same thing.

Some corporate networks don't hand out a fixed proxy address at all — they use a PAC file (a small script your browser downloads that decides which proxy to use based on the destination), and Windows itself can be configured to follow that same PAC file system-wide through netsh winhttp show proxy. If that command shows a PAC-based configuration but you've only ever set HTTP_PROXY and HTTPS_PROXY manually, the two systems aren't necessarily talking to each other — the CLI's environment variables and Windows' own WinHTTP proxy settings are separate configurations, and a mismatch between them is a real, if less common, source of this exact error on a managed Windows laptop.

The certificate error that looks like this one but isn't

Once a proxy is in the mix, you'll sometimes trade "Could not connect to the endpoint URL" for a different error: SSL: CERTIFICATE_VERIFY_FAILED. That's actually progress, not a new failure — it means the connection is reaching the proxy now, and the proxy is intercepting and re-signing HTTPS traffic with its own certificate, common on corporate networks for security inspection, which the CLI doesn't trust by default because it isn't a certificate AWS itself issued.

The fix is to point the CLI at your company's root certificate file, not to bypass certificate checking as a permanent habit going forward: aws configure set ca_bundle /path/to/company-cert.pem — or the --ca-bundle flag on a single command, or the AWS_CA_BUNDLE environment variable for a whole session. There's also a --no-verify-ssl flag that skips certificate checking entirely; it will make the error disappear, but it does so by turning off a real security check, and it should be a temporary diagnostic step used to confirm the cause, not the fix you leave in place afterward.

Cause 4: a VPN is routing your traffic somewhere it shouldn't

A personal or corporate VPN can cause this error two different ways, and they need two different fixes, so it's worth telling them apart before you touch anything on your machine.

Way one: the VPN hijacks DNS. Covered above — the VPN pushes its own DNS server, and that server has no idea what s3.amazonaws.com is. Confirmed by the same nslookup test, run once with the VPN connected and once with it disconnected, comparing the two results directly.

Way two: the VPN's routing table sends AWS traffic down a tunnel that doesn't actually lead anywhere useful. Some corporate VPNs route all traffic through the company network by design — including traffic to AWS, even when your AWS account has nothing to do with that company at all. If the company's own firewall then blocks outbound AWS traffic, a genuinely common and intentional security policy, your request vanishes into a tunnel that was never going to deliver it, and the CLI reports exactly the same "could not connect" message it would give for a plain DNS failure, with no way to tell the two apart from the error text alone.

The practical test is the same either way: disconnect the VPN, retry the exact command, and see if it succeeds. If it does, you now know the VPN is involved — whether the actual fix is not using the VPN for this particular task, asking IT to allowlist AWS endpoints on the VPN, or switching to a split-tunnel VPN configuration that only routes company traffic through the tunnel and leaves everything else on your normal connection, depends entirely on why your organization has that VPN in the first place. That's a conversation with whoever manages it, not a setting you can change on your own laptop.

Cause 5: running from inside AWS itself — EC2, VPC endpoints, and NAT gateways

Everything above assumes you're running the CLI from a laptop or desktop reaching out over the open internet. If instead you're running it from inside an EC2 instance, the causes shift, because the network path is entirely different — and this is the situation people find most confusing, because "my internet is fine" doesn't even apply here; the instance might have no direct internet path by design, and that's normal, not broken.

If the instance is in a public subnet

Check that the subnet's route table sends traffic bound for the internet (0.0.0.0/0) to an internet gateway, and that the instance's security group and the subnet's network ACL both allow outbound traffic on port 443 — the port all AWS API and S3 traffic uses for encrypted requests.

If the instance is in a private subnet

A private subnet has no direct internet gateway by design — that's precisely what makes it private. Two things need to be true:

1. The subnet's route table needs a route to a NAT gateway, so outbound requests can reach the internet even though nothing can initiate a connection back in from outside.
2. If you're using a VPC endpoint instead of a NAT gateway, common for keeping S3 traffic off the public internet entirely, that endpoint is tied to one specific region. Run aws s3 sync with --region us-west-1 while the VPC endpoint only exists in us-east-1, and you'll get this exact error — because the region flag and the VPC endpoint are now pointed at two different places, and neither setting is wrong on its own; they just don't agree with each other.

For anyone troubleshooting a VPC endpoint mismatch in more depth than a route table alone can show, AWS's Reachability Analyzer traces the actual path between an instance and an endpoint and flags exactly which security group, network ACL, or route table entry is blocking it — worth reaching for once you've confirmed the region and the endpoint genuinely should be able to talk to each other and still aren't.

One more EC2-specific trap: if the instance uses an attached IAM role and also sits behind a proxy you've configured, make sure 169.254.169.254 — the address of the instance metadata service the role's credentials come from — is excluded from that proxy via a NO_PROXY setting. Routing metadata requests through an external proxy breaks credential retrieval in a way that can look, at a glance, like the same connection failure this whole article is about, even though the actual cause is one address that should never have left the instance in the first place.

Cause 6: the service just isn't available in that region

This one deserves its own section because it's genuinely counterintuitive: your region setting can be entirely correct for 95 percent of what you do, and still be wrong for one specific service, because not every AWS service runs its API in every region. It's not a bug in your setup — it's how those particular services are architected on AWS's side.

AWS Health is the clearest real-world example. Its API deliberately runs in only a couple of US regions as an active/passive pair, regardless of which region your account's actual resources live in. Someone whose default region is set to Tokyo, running aws health describe-events, will get "could not connect to the endpoint URL" every single time — not because anything is broken, but because there genuinely is no Health endpoint in that region for the request to reach.

The fix, once you know this is the cause, is narrow and specific: add --region us-east-1, or whichever region that particular service's documentation names, to calls for that one service only, without changing your profile's default region for everything else you do day to day. If a command that used to work suddenly stops, and nothing on your end has changed, it's also worth checking whether AWS added, moved, or deprecated an endpoint for that service — new AWS services frequently launch in a handful of regions first before expanding out over following months.

Running this inside Docker, WSL, or a CI/CD pipeline

A version of this error shows up constantly in setups where the AWS CLI isn't running directly on your everyday operating system at all — inside a Docker container, inside Windows Subsystem for Linux, or on a build agent in a CI/CD pipeline — and it's worth its own section because the network layer underneath is genuinely different from a normal laptop, even though the error message on screen looks identical.

A Docker container gets its own network namespace by default. It doesn't automatically inherit your host machine's proxy settings, its DNS configuration, or its VPN routes — each of those has to be passed into the container explicitly, usually as environment variables on the docker run command (-e HTTPS_PROXY=... -e HTTP_PROXY=...) or baked into the image itself. A command that works perfectly on the host and fails identically inside a container built from that same host is one of the clearest signals that the container is simply missing proxy or DNS settings the host has and it doesn't.

WSL2 runs Linux inside a lightweight virtual machine with its own network adapter, separate from Windows' own network stack. A corporate VPN connected on the Windows side doesn't always route WSL2's traffic the same way it routes Windows' traffic — this is a known friction point, not a misconfiguration on your part — and DNS inside WSL2 sometimes points at a different resolver than the one Windows itself is using at that moment. Testing nslookup from inside WSL2 separately from testing it in a normal Windows Command Prompt is the fastest way to tell whether the two environments actually agree with each other.

On a CI/CD runner — GitHub Actions, GitLab CI, Jenkins, and similar — the machine running your pipeline may sit behind its own egress proxy or a restrictive outbound firewall that has nothing to do with the network you develop on personally. A step that runs an AWS CLI command and fails only in the pipeline, never locally, points at the runner's network configuration specifically: check whether the CI provider documents required proxy environment variables for that runner type, and confirm the pipeline's IAM role or credentials have actually been passed into the step correctly, since a credentials problem and a connectivity problem can look surprisingly similar in a compressed CI log.

Before you paste your debug output anywhere

Running a command with --debug produces a genuinely useful log — and also one that's worth a second look before you paste the whole thing into a public forum post, a GitHub issue, or a support ticket outside your own organization. That output regularly includes your AWS account ID, the exact ARNs of any IAM roles or users involved, internal hostnames if you're using a VPC endpoint, and occasionally fragments of a session token. None of that is as sensitive as a full secret access key — the CLI redacts the most obviously dangerous fields by default — but account IDs and role names are still information you generally don't want sitting in a public issue tracker indefinitely, searchable by anyone who comes across it later.

Before sharing a debug log with someone outside your team, skim it once for your account ID and any role or resource names specific to your organization, and replace them with a placeholder if the person helping you doesn't actually need the real values to diagnose a connection problem — in most cases, the hostname, the error text, and the region are the only parts that matter for troubleshooting this particular error, and everything else in the log is context you can safely trim before you hit send.

Match your symptom to the cause

Run through this in order — each row's test takes under a minute, and together they'll usually land you on the right section above before you've read this whole article top to bottom.

Popular advice that doesn't actually fix this

A few fixes get repeated constantly across forum threads on this exact error, and they're worth naming plainly, because they solve a symptom for some people some of the time, not the underlying cause for everyone.

"Reinstall the AWS CLI." This helps in exactly one scenario: a corrupted install, or an old version missing a newer service's endpoint definitions entirely. It does nothing for a region mismatch, a DNS failure, or a proxy problem, and reinstalling is a ten-minute detour when the actual fix might be a one-line environment variable you haven't set yet.

"Restart your computer." Occasionally fixes VPN or DNS-cache issues by resetting network state, purely by accident rather than by design — worth trying if you're genuinely stuck with no other leads, but it's not a diagnosis of anything, and if the underlying cause is a firewall rule or a wrong region, the exact same error returns identically the moment you try the command again after rebooting.

"Just use --no-verify-ssl." This is specifically for certificate errors, not connection errors, and turning off certificate verification as a permanent habit trades a real security check for a quieter terminal window. Use --ca-bundle instead once you've confirmed a proxy certificate is genuinely the issue, and treat --no-verify-ssl as a diagnostic flag you remove again afterward.

"Switch to AWS CLI version 1." Version 1 is in maintenance mode, and while its error messages and defaults differ slightly from version 2's, switching versions doesn't change whether your network can reach an AWS endpoint. If anything, an older version is more likely to be missing endpoint definitions for newer services and regions, which can introduce a second, unrelated version of this same error.

"Set the region to us-east-1 and move on." Often works, for the reason covered earlier — but if your resources live elsewhere, or the specific service you're calling isn't in that region either, you've just swapped one wrong region for another, and the same error, or a new, quieter one, follows you straight into the next command you try.

When you've tried everything and it still fails

If region, DNS, proxy, VPN, and subnet routing have all checked out clean and the error still shows up, a few less common possibilities are worth ruling out before you assume something exotic and unfixable is wrong.

Your system clock is wrong. AWS cryptographically signs every request with a timestamp, and rejects requests where the client's clock has drifted too far from AWS's own reference time. This usually surfaces as a different, more specific error about the request signature — but a badly wrong clock can produce connection-level oddities too on some systems, particularly around certificate validation, which checks dates as part of confirming a certificate hasn't expired. Confirm your date and time are correct and set to sync automatically rather than manually.

A genuinely bad AWS CLI install — a broken or partial installation, especially one left over after an interrupted update that didn't finish cleanly. Uninstall it completely and reinstall the latest version from AWS's own installer rather than trying to patch over whatever's already there.

You're on an outdated CLI version that simply doesn't know about a newer service or region yet. AWS ships CLI updates frequently, and a service or region added after your version was installed won't be in its list of known endpoints at all, no matter how correctly everything else is configured. aws --version tells you exactly what you're running; compare it against the latest release AWS publishes.

Name what you genuinely can't fix from the CLI side, because this is the honest ceiling worth stating plainly rather than implying with silence. If IT has a firewall policy that blocks *.amazonaws.com by design, or a VPN configured to route all traffic through an inspection point that then drops AWS traffic on purpose, no combination of settings on your own machine gets around that. That's not a personal troubleshooting failure on your part — it's a network policy decision made above your account, and the honest next step is a ticket to whoever owns that policy, not another hour of retrying the same command hoping something changes on its own.

Frequently asked questions

What does "Could not connect to the endpoint URL" actually mean?

It means the AWS CLI tried to open a network connection to a specific AWS service address and got no response at all — no DNS resolution, no TCP handshake, nothing. It's a network-layer failure that happens before your credentials or permissions are even checked, which is why fixing your access keys never resolves it on its own.

Why does this happen only with some AWS CLI commands and not others?

Each AWS service has its own endpoint address, built from the service name and your region. A working aws s3 ls alongside a failing aws health describe-events usually means one specific service's endpoint isn't reachable — often because that service doesn't run in your default region at all — rather than a general network outage affecting everything equally.

How do I check which region my AWS CLI is currently using?

Run aws configure get region for a quick answer, or aws configure list for a fuller picture that also shows whether the region is coming from an environment variable, the config file, or a command-line override, so you can see exactly why it's set to what it's set to.

Does the --region flag always fix this error?

It fixes it when the cause is a wrong or missing region, which is common but not universal. If DNS, a proxy, or a firewall is blocking the connection instead, setting the region correctly won't change anything, because the request still can't leave your machine in the first place.

Can a typo in my endpoint URL really cause this?

Yes, and it's an easy one to miss. If you're using a custom --endpoint-url flag, one extra or misplaced character points the CLI at an address that doesn't exist. Run the command with --debug and read the exact hostname it tried — a typo usually jumps out immediately once you see it spelled out in full rather than half-remembered.

How do I test whether DNS is the problem?

Run nslookup, or dig on Mac/Linux, against the exact hostname from your --debug output, for example nslookup s3.amazonaws.com. If it returns an IP address quickly, DNS is working for that hostname. If it times out or says it can't find the host, DNS is your cause.

What do I do if nslookup or ping can't resolve the AWS hostname?

Try disconnecting any VPN and testing again, since VPNs commonly push their own DNS server. If that doesn't help, try a public DNS server like 8.8.8.8 to see if the problem is specific to your network's usual DNS. If it only resolves through the public server, the fix likely needs to happen on your router or with your network administrator rather than on your own laptop.

How do I know if a corporate proxy is blocking the AWS CLI?

If your browser needs a proxy to reach the internet at all, but you haven't set HTTP_PROXY or HTTPS_PROXY for your terminal session, that's the most likely explanation — the CLI has no visibility into your browser's proxy settings and needs its own, set separately.

I set HTTPS_PROXY and it still fails — what's wrong?

Check for a case mismatch — if both HTTPS_PROXY and https_proxy are set to different values, the lowercase one wins silently. Also confirm the port and any username or password in the proxy URL are correct, and check whether you're now getting a different error, an SSL certificate error, which would mean the proxy is being reached but its certificate isn't trusted yet.

Does a VPN cause this error, and should I turn it off?

A VPN can cause it two ways — by hijacking DNS resolution, or by routing traffic through a network that blocks AWS. Turning it off is a good diagnostic test, but whether you can leave it off depends on why your organization requires it in the first place, which is a policy question for whoever manages the VPN, not just a CLI setting you flip yourself.

Why does this happen on an EC2 instance but works fine from my laptop?

An EC2 instance in a private subnet has no direct internet access by design. It needs a NAT gateway configured on its route table to reach AWS endpoints, or a VPC endpoint for services like S3. Missing either one produces exactly this error, even though your laptop on a completely different network connects without any issue at all.

Why does this happen inside Docker or WSL but not directly on Windows?

Containers and WSL2 each get their own network environment, separate from your host machine's. Proxy settings, DNS configuration, and VPN routing that work on your host don't automatically carry over — they usually need to be passed in explicitly as environment variables or configured separately inside that environment.

Is "Could not connect to the endpoint URL" the same as an SSL certificate error?

No, but they're closely related and often appear back-to-back while troubleshooting a proxy. "Could not connect" means the connection never opened at all. A certificate error means the connection opened but the CLI didn't trust the certificate presented, commonly because a proxy is re-signing HTTPS traffic with its own certificate. Getting the certificate error after fixing the connection error is a sign of progress, not a new problem to solve from scratch.

Is it safe to paste my --debug output into a support ticket or forum post?

Skim it first. Debug output commonly includes your AWS account ID, IAM role or user ARNs, and sometimes internal hostnames — none of it as sensitive as a full secret key, but still worth trimming or replacing with placeholders before sharing outside your own organization, since usually only the hostname, the error text, and the region actually matter for diagnosing this error.

What's the fastest way to figure out exactly which of these causes I have?

Run the failing command with --debug and note the exact hostname it tried. Then test that hostname with nslookup. Between what --debug reveals about the region being used and what the DNS test reveals about resolution, most people land on the right cause within two or three minutes, without working through every section in this article in order.

Can I automate this diagnosis instead of running each check manually?

Yes — a short shell script that runs aws configure list, then nslookup against the relevant hostname, then a port check on 443, and prints the results together covers the first three causes in this article in one pass, and is worth keeping handy if you troubleshoot AWS CLI connectivity issues more than occasionally across different machines or environments.

Also Read👇

🪣 S3 Fixes

• ⚠️ NoSuchBucket, But the Bucket Exists — every cause behind this confusing error.
• 🔒 AccessDenied on GetObject — every permission layer that can produce this.
• 🚫 "Bucket Does Not Allow ACLs" — the Object Ownership setting that broke ACL-based uploads.
• 🔤 "Bucket Name Already Exists" — why bucket names are global, and how to pick a free one.
• 🚧 S3 Access Denied / 403 Errors — a general walkthrough, from bucket policy to VPC endpoint.

💻 EC2 & SSH Fixes

• 🔑 SSH: Permission Denied (publickey) — the key-pair mismatches behind this classic error.
• 🔐 PuTTY: "Server Refused Our Key" — the PPK-format version of the same problem.
• 🚦 EC2 Status Check Failed — system versus instance checks, and what each means.
• ⏳ Connection Timed Out / Refused / Denied — three failures, three different fixes.
• 🌐 Private Subnet Has No Internet — the NAT fix.

⚡ Lambda Fixes

• 📦 "Unable to Import Module" — the packaging mistakes that break a working function.
• ⏱️ "Task Timed Out After 3.00 Seconds" — the default timeout everyone hits once.
• 👁️ Lambda Not Logging to CloudWatch — the permission it needs first.
• 💥 Malformed Lambda Proxy Response (502) — the exact response shape API Gateway expects back.

Revision note. Written September 2026. Region precedence, proxy handling, and service-specific endpoint availability are the kind of detail AWS updates without much fanfare, so if a step here doesn't match what you're seeing, it's worth a quick check against AWS's own CLI documentation before assuming you've done something wrong. If you've been stuck on this one for a while, you're not missing something obvious — this error genuinely hides its real cause on purpose, and it's worth the two minutes it takes to run it with --debug before you try anything else.. Happy Learning!