0

I am receiving "Could not connect to the endpoint URL: "https://s3.amazonaws.com/" from inside EC2 instance running in private subnet

Here is a configuration:

  1. Created one VPC with 2 private subnets (yes.. no public) that is connected to our datacenter using VPN connection. This VPC does not have any IG or NAT.

  2. Created EC2 instance(Amazon Linux AMI) inside one of the private subnet.

  3. Connected to EC2 using Putty- successfully.

  4. Now created an endpoint - S3 that is connected to the VPC (in step1) and policy is as follows (as presented by aws management console):

    {
    "Statement": [
        {
            "Action": "*",
            "Effect": "Allow",
            "Resource": "*",
            "Principal": "*"
        }
    ]
}
  5. Routing is automatically added to the VPC routing where destination is pl-xxxxxxxx(com.amazonaws.us-east-1.s3) and target is the endpoint created in step4, status Active, Propogated - No
  6. Added 2 outbound rules in Security Group for the VPC: (HTTP:80, HTTP:443) to destination prefix s3 endpoint starting with pl-xxxxxxxx (same as step 5).
  7. Created a bucket in S3 using amazon management console

  8. Edited bucket policy as follows

        {
    "Version": "2012-10-17",
    "Id": "Policy1459706251964",
    "Statement": [
        {
            "Sid": "Stmt1459706246215",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::mybucket/*",
                "arn:aws:s3:::mybucket"
            ]
        }
    ]
}

  9. Now entered following command in putty session 

     aws s3 ls --debug --endpoint-url https://s3.amazonaws.com/mybucket

  10. I got "EndpointConnectionError: Could not connect to the endpoint URL in #9

I know I am missing something..Any help will be greatly appreciated..

user2939101
  • 5
  • 2
  • 6
  • 1
    I'm not sure where you got `us-east1.s3.amazonaws.com`, but that's almost certainly invalid. In the us-east-1 region, the correct endpoints for S3 are `s3.amazonaws.com` or `s3-external-1.amazonaws.com`. – Michael - sqlbot Apr 03 '16 at 20:28
  • @Michael-sqlbot - You are right. In the AWS documentation, for east coast - it is s3.amazon.com. I tried it and it did not work. Then I googled and saw somebody had similar problem and he was referring to {us-east1.s3.amazonaws.com}. Now I re-corrected back and same error. – user2939101 Apr 03 '16 at 20:40
  • *Routing is automatically added to the VPC routing* ... automatically added? That doesn't sound right, but I'm going from memory -- verify that *all* of the appropriate routing tables, particularly the one for the subnet of this instance do indeed have that pl-xxxxxxxx entry. Then, I would relax the outbound security group to allow all traffic and see if you have a connection, then, or not. You don't want to have to troubleshoot more than one thing at a time. – Michael - sqlbot Apr 03 '16 at 20:49
  • @Michael-sqlbot - Followed your instructions: – user2939101 Apr 03 '16 at 20:58
  • I also checked that is defined in subnet. Then I checked routing against the VPC. It is defined properly and it has `3 routes defined- 1) as Destination, "local" as Target, "Active" as Status and "No" as "Propogated" 2) as Destination, "" as Target, "Active" as Status and "No" as "Propogated" 3) 0.0.0.0/0 as Destination, "" as Target, "Active" as Status and "Yes" as Propogated` Then I relaxed the outbound rules on Security Groups associated with this VPC and allowed all traffic. – user2939101 Apr 03 '16 at 21:07
  • And then what happened? If it's still not working, I'd be curious to see the result of a simple `telnet s3.amazonaws.com 443` since the error message "Could not connect" is fairly meaningless. – Michael - sqlbot Apr 03 '16 at 21:09
  • Can you open all outbound and see the CLI command succeeds? This will narrow down the debug route. – helloV Apr 03 '16 at 21:20
  • @Michael-sqlbot - The steps you originally asked me to verify -- did not work. However I am trying to do "telnet s3.amazonaws.com 443".. alas-- telnet not found on this ami. So I am struggling on that piece.. once i have that, I will post it here. – user2939101 Apr 03 '16 at 22:02
  • @helloV- Do you mean by open outbound rules for ALL Traffic. I did.. and CLI command did not succeed. – user2939101 Apr 03 '16 at 22:03
  • @Michael-sqlbot The problem is solved. The actual problem was inside our company firewall. The DHCP was not properly set to allow the traffic outside VPC and hence EC2 instance or accessing to any CLI commands. – user2939101 Apr 04 '16 at 23:10
  • @helloV - It was definitely related to permissions and as I mentioned to Michael - our IT Security Operations has not set these properly. – user2939101 Apr 04 '16 at 23:11

1 Answers1

0

If anybody has similar problem- please also check with your corporate IT about DNS resolution properly set. The workaround is - While I waited for our internal IT to do this work, I used Amazon DNS.

user2939101
  • 5
  • 2
  • 6
  • Yes, that could do it. There are several compelling reasons to stick with the VPC resolvers rather than using your corporate DNS servers. You can associate "private" Route 53 hosted zones with your VPC as one way to resolve "internal" hostnames, if that's a concern. Using external DNS that depends on the VPN connection will of course mean higher latencies and creates a dependency on the availability of the VPN connection for proper functioning of what you've deployed in AWS. – Michael - sqlbot Apr 05 '16 at 02:58