Why traceroute of AWS public IP goes to the US? - amazon-web-services

I've used the traceroute command to see which network path packets are taking when reaching out to an EC2 instance with a public IP address.
I don't understand why at step 8 of the traceroute, packets are going to the USA (Seattle)
My EC2 is located in the AWS Paris region (eu-west-3) and my laptop making the request is located in Paris too.
Any idea why ?

IP addresses are not actually associated with geographic locations. However, various services over time have attempted to map each IP address with a location.
See: How does IP geolocation service providers collect data or how does IP geolocation databases are filled? - Quora
These activities are not always accurate and nobody is responsible for updating the information whenever devices are moved or addresses are reallocated.

Related

Can a client find out which region an AWS-hosted webapp is in?

As indicated in the title, I want to know if it is possible to know the region of a given AWS service, for examlple using ip address or traceroute tool.
Thank in advance.
Yes indeed once the IP address is known it can be matched against the publically available IP Address table from AWS.
The IP Address range is always found here https://ip-ranges.amazonaws.com/ip-ranges.json

If Anycast means I see only 1 IP address for a domain name distributed over many geographic regions

I am wondering about Anycast. From the diagram it looks like you can map a single IP address to multiple IP addresses. This means you can have an interface of 1 IP address, but then under the hood redirect it to region a or region b, geographically distributed.
Not knowing much about IP addresses, I try this:
$ ping google.com
PING google.com (216.58.194.206) ....
....
To me that says that google.com is at 216.58.194.206 IP address. I have a few questions about this:
If that IP address will ever change.
If this is a region-specific IP address.
Or if this is probably (under the hood) redirecting to a region-specific IP address, if that's a thing.
I would like to do something like this:
mywebsite.com -> 123.123.123.123 -> 200.200.200.200 (region 1)
-> 200.200.200.201 (region 2)
-> 200.200.200.202 (region 3)
...
-> 200.... (region n)
Where only 123.123.123.123 can connect to the region specific IP addresses, and when you do ping mywebsite.com you always see 123.123.123.123 no matter where you are in the world.
Wondering if that's how it works with Anycast, or if not then how it does work. I am trying to architect a system where there are many regions for reliability and latency optimization (closeness to request source), while at the same time having it so there is only 1 domain for all regions. That is, there is not zh.mywebsite.com for china, uk.mywebsite.com for UK, etc, it is all just mywebsite.com and under the hood it redirects to the appropriate region. Also, the reason for having the intermediate 123.123.123.123 IP is so that there is a constant interface to the regions, so when you do ping mywebsite.com you will always see 123.123.123.123, not 200.200.200.200 for region 1, etc. Or perhaps there is no way around this, which would be good to know: that the IP will always resolve to the region IP.
Actually now that I try ping google.com again I get a different IP address, so there's at least 2 for some reason.
Suggestion: Ask a single question and not a broad question that covers the design of the global Internet. Ask about one cloud provider and not several. In my answer below I am limiting the amount of details that I am providing otherwise my answer would be the size of a book.
I am wondering about Anycast. From the diagram it looks like you can
map a single IP address to multiple IP addresses. This means you can
have an interface of 1 IP address, but then under the hood redirect it
to region a or region b, geographically distributed.
In Google Cloud, a global IP address is used to route the customer to the closest Google Edge location, where the traffic is then sent via the Google internal network to the final destination. The final destination depends on the type of resource. Let's assume Google Compute Engine or AWS EC2.
AWS offers AWS Global Accelerator for Anycast IP addresses which provides similar technologies.
Not knowing much about IP addresses, I try this: ping google.com
For enterprise systems, it is common practice to have many compute servers provide services for a single DNS endpoint (google.com). The servers can be load balanced by the DNS server using multiple A records. The load balancing strategy can be round robin, least busy, geo-location based, etc. I do not know Google's internet design for the DNS name google.com, but the design possibilities are large. The domain can also be served by a load balancer that hides the backend implementation. Using a load balancer is a typical design but older legacy designs use DNS servers.
If that IP address will ever change.
The answer is Yes, No and Maybe. The answer depends on the internal design of the systems. Fault tolerant, elastic designs do not require a fixed static IP address. The goal of the DNS server to translate a DNS name (google.com) into an IP address (216.58.194.206) at that point in time that the translation is required.
If this is a region-specific IP address.
Or if this is probably (under the hood) redirecting to a region-specific IP address, if that's a thing.
It depends on how Google designed its systems internally. Google offers both global and region IP addresses.
Where only 123.123.123.123 can connect to the region specific IP
addresses, and when you do ping mywebsite.com you always see
123.123.123.123 no matter where you are in the world.
You are imposing a design criteria that is not necessary. The DNS server can provide the IP address translation for the domain name. Your question indicates an lack of understanding how public and private IP addressing is managed, how addresses are translated and routed and the interplay with DNS servers, load balancers and auto-scaling. Hopefully my answers will help you know what to learn about.
I am trying to architect a system where there are many regions for
reliability and latency optimization (closeness to request source),
while at the same time having it so there is only 1 domain for all
regions.
Having one domain name (example.com) with servers located in Europe, US, South America and Asia is very easy to achieve with any cloud provider. Anycast is not required. You just need either a global load balancer (Google) or regional load balancers (AWS), and a modern DNS server, which both Google and AWS provide.
You have created a question covering both AWS and Google Cloud. The two providers are very similar at a high level but very different in implementation details. Pick one, learn how DNS, Load Balancers, and Auto-scaling works for either AWS or Google. Note: you can achieve your design goal mixing both AWS and Google Cloud, but why add that layer of complexity. The more complex your design, the more fragile it becomes. This means more management layers by humans or machines for logging, monitoring, metrics and alerting.

Google Cloud Platform external IP point to an instance in Singapore but shown in US

I purchased a GCP VM instance in asia-southeast1 and reserved an external IP in the same region for this.
The instance and IP information that is shown in GCP console seems to be okay but when I deploy my website into it, the response is really slow.
My static IP
VM instance
So I lookup my IP and the tool show my IP is from US
IP lookup result
I am not sure what wrong with my IP or instance, I am new in GCP please help. Thank you.
If I search the whois data for external IP address of a Virtual Machines in GCP zone asia-southeast1 I can see that the address points to Google's headquarters in Mountain View, CA. The whois data has no indication of where in the world the actual hardware is located...
Many external Geo IP services depend on a SWIP database. Most of Google IP's are SWIP'ed to be Mountain View, CA. That means a VM living in a datacenter outside of the U.S. might show a linked U.S. IP address, as in your case. I suspect that most of Google's addresses will be originally US allocated.
The external IPs that are assigned to Google Cloud customer's projects are from an address block(s) that belongs to Google and is Geolocated there:
# The following results may also be obtained via:
# https://whois.arin.net/rest/nets;q=35.193.232.48?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#
NetRange: 35.192.0.0 - 35.207.255.255
CIDR: 35.192.0.0/12
NetName: GOOGLE-CLOUD
NetHandle: NET-35-192-0-0-1
Parent: NET35 (NET-35-0-0-0-0)
NetType: Direct Allocation
OriginAS:
Organization: Google LLC (GOOGL-2)
RegDate: 2017-03-21
Updated: 2018-01-24
Comment: *** The IP addresses under this Org-ID are in use by Google Cloud customers ***
Comment:
Comment: Direct all copyright and legal complaints to
Comment: https://support.google.com/legal/go/report
Comment:
Comment: Direct all spam and abuse complaints to
Comment: https://support.google.com/code/go/gce_abuse_report
Comment:
Comment: For fastest response, use the relevant forms above.
Comment:
Comment: Complaints can also be sent to the GC Abuse desk
Comment: (google-cloud-compliance#google.com)
Comment: but may have longer turnaround times.
Ref: https://whois.arin.net/rest/net/NET-35-192-0-0-1
OrgName: Google LLC
OrgId: GOOGL-2
Address: 1600 Amphitheatre Parkway
City: Mountain View
StateProv: CA
PostalCode: 94043
Country: US
RegDate: 2006-09-29
Updated: 2017-12-21
(...)
That does not mean that your VM's address is responding from Mountain View, if your instance is in Asia. In your case, your instance in asia-southeast1 and is physically located in Singapore.
You can also choose the region for your static external IP, just go to VPC Network -> External IP addresses -> Reserve static address and you can choose the region where the external IP will be located. It will still be displayed as from the US by the whois databases, because it belongs to the Google bloc, but the entry point will be routed in Singapore, that should improve your latency.
Thank guys for clarification about the IP, it is not related to my issue. I got confused with GeoIP at first.
After all, I found out that the slow response is caused by 2 things below:
Database region: My Google Cloud Sql (mysql) region is in Australia because GCP Cloud Database has no server in SEA. I tried to change database region to asia-east (exactly is in Taiwan) and got doubly faster response.
Connection method: GCP provide 2 ways to connect to its cloud sql: Database External IP (with IP whitelist config) and via Cloud SQL Proxy that both have network latency. I think GCP should support database communication inside a VPC. I am not sure why GCP does not support this way currently.
The response of my website is now better but much slower as compared with the same one I deployed into AWS. In AWS the communication between my App and database is done inside a VPC, no public IP exposed and no network latency. Moreover, AWS database have server in SEA that why AWS is much faster in my case
Response time: GCP vs AWS

About region / zone of Google Compute Engine's VM

I have an instance which was created in Australia region, the zone is australia-southeast1-a. However, I find that the External IP is still in US:
Had tried creating another instance in another region (asia), and logined using ssh, haven't noticed any significant difference in latency, the responses are both not very fast.
My question is, have I correctly setup the region to Australia? Or is there any configuration that I have missed?
Your setup on the VM and its configuration are perfectly fine. You have your hardware physically located in the Australian region. Your concern over IP’s location is just a mere confusion. This had happened to most of the customers.
Most of the external Geo IP services are depending upon the SWIP database. And for this reason, most of the Google’s IPs are SWIP’ed to the Mountain View, CA. Because of this, even for a VM which is created outside (in your case Australian Region) the US shows its IP location as in the US.
Furthermore, you can also go through this Google discussion thread which will give you more comments on this matter.

How to reference another EC2 instance, which may be restarted or even have another instance started?

Consider an server ec2-50-1-2-3.compute-1.amazonaws.com, which is not publicly available and which does not have an elastic IP address. I cannot assign it an Elastic IP address as I don't have any more addresses to assign (used all 5 already on publicly-available servers).
The publicly-available servers need to access a service on ec2-50-1-2-3.compute-1.amazonaws.com. However, if I restart that server then it may receive a different address and I'll have to update 20 websites across 5 webservers with the new address. Is there any way to refer to the ec2-50-1-2-3.compute-1.amazonaws.com server which will persist even if I restart that server, considering that I have no more Elastic IP addresses to assign to it?
Is there any way to refer to
Key word "refer to" -- indeed, there is... a DNS CNAME.
Whether your DNS is in Route 53 or elsewhere, a CNAME record refers a system asking for a particular host by name, to a different host -- also by name.
Let's say, for example, that the service this system provides is the generation of reports. In the "example.com" domain...
reports IN CNAME ec2-50-1-2-3.compute-1.amazonaws.com.
Any machine looking up "reports.example.com" from the DNS will be referred to the hostname ec2-50-1-2-3.compute-1.amazonaws.com which will of course resolve to the machine's IP address.
If the machine's IP address (and therefore, in AWS, its hostname) changes because the instance was terminated or failed or replaced, you only have to update the information in one place -- the DNS. The systems that need to access this system would be configured with "reports.example.com" instead of the other hostname, so they wouldn't have to be maintained individually.
If you are using Route 53, it's also possible to configure Route 53 to actually give out a different answer using failover routing with health checks and divert requests elsewhere when the instance isn't working properly.
Amazon will not give you any difficulty at all if you simply request more Elastic IPs. It's right here: Request to Increase Elastic IP Address Limit
It turns out the the best way to refer to other instances in AWS is to use Amazon Virtual Private Cloud (VPC). In VPC each machine gets a static internal IP address, which persists for the lifetime of the instance. In fact in VPC one can configure full networking!