I am attempting to run basic commands like aws s3 ls and aws ec2 describe-instances, but I keep getting a "Could not connect to the endpoint URL" error. I have already verified my internet connection and updated my access keys. Is this usually a result of an incorrect region setting in my ~/.aws/config file, or could it be a firewall/proxy blocking the outbound request to the AWS service endpoints? How can I identify the specific URL the CLI is trying to reach?
3 answers
The "Could not connect to the endpoint URL" error essentially means the CLI cannot reach the AWS server for the service you're calling. The most frequent culprit is an invalid Region name. For example, if you mistakenly set your region to us-east-1a (which is an Availability Zone) instead of us-east-1 (the Region), the generated endpoint URL will be invalid. Another common cause is being behind a corporate proxy or firewall that blocks port 443. To diagnose this, run your command with the --debug flag. This will output the exact URL the CLI is attempting to hit and the low-level connection logs. If the URL looks correct (e.g., https://s3.us-east-1.amazonaws.com), then it is likely a local network or DNS resolution issue.
Sometimes this happens because the system clock is out of sync. If your local time differs by more than 5 minutes from the AWS server time, the connection might be dropped during the handshake.
I noticed Sarah mentioned the --debug flag, which is great for finding the URL. If I find that the URL is correct but I'm still getting the error while working inside a private VPC, could the issue be related to a missing VPC Endpoint for S3 or EC2, or would that usually throw a different timeout error instead?
Michael, you're on the right track. If your instance is in a private subnet with no NAT Gateway or Internet Gateway, it will fail with this exact "could not connect" error because it has no path to the public internet. In that case, you must create an Interface or Gateway VPC Endpoint for that specific service. Once the endpoint is created, the CLI will automatically route traffic through the internal AWS network, provided your private DNS settings are enabled for the VPC.
I agree with Emily. While the "RequestTimeTooSkewed" is the typical error for clock issues, I've seen some versions of the CLI fail to establish the initial secure socket layer (SSL) connection entirely if the certificates aren't validated against the correct system time.