How does AWS reduce the latency? - amazon-web-services

My company is in Vietnam. And the nearest AWS region is Singapore. The thing is most of our users are from Vietnam and We want the latency of the requests to our servers is as low as possible.
In paper If we use a hosting service from Vietnam the latency will be lower, due to the distance is shorter.
What are AWS's solutions to reduce the latency? Do they cooperate with local internet vendor to solve this issue?

The major option available from Vietnam to reduce latency, is to use AWS Direct Connect.
Though its not significant, while having network traffic routed through AWS Global Network Backbone, the number of hops and packet loss is less.
However, there is a significant upfront commitment in setting up AWS Direct Connect.

Related

How to find AWS EC2 with lowest latency to another server

I have a client sever located in AWS and I want to reduce latency between his machine and my EC2 instance. I rented two same servers in one availability zone and started sending requests to client`s API. It turned out that these servers have different latencies: 95-th percentiles were different for about 5 milliseconds (that is about 30% from mean latency). And my aim is to reduce latency.
I think that I can rent more servers and repeat these experiment, but it will be the next step of my investigation. The first step for me is to understand the reasons why servers in the same zone have so big difference in API response latency and which metrics can be useful to explain it?
The second way to reduce latency is to rent bare metal server instead of EC2, but it seems to be too expensive. And I am afraid that renting this server make even worse if it stand further from client server.
So, tell me please:
Do you have any advice how to reduce latency?
How can I rent closest server to my client in the same AWS zone?

Ping between aws and gcp

I have created a Site to Site VPN connection between VPC of Google cloud Platform and AWS in North Virginia region for both the VPCs. But the problem is I have been getting a very high ping and low bandwidth while communicating between the instances. Can any one tell me the reason for this?
image showing the ping data
The ping is very high considering they are in a very close region. Please help.
Multiple reason behind the cause :
1) verify gcp network performance by gcping
2) verify the tcp size and rtt for bandwidth
3) verify with iperf or tcpdump for throughput
https://cloud.google.com/community/tutorials/network-throughput
Be aware that any VPN will be traversing the internet, so even though they are relatively close to each other there will be multiple hops before the instances are connected together.
Remember that from the instance it will need to route outside of AWS networks, then to any hops on the internet to GCP and finally routed to the instance and back again to return the response
In addition there is some variation in performance as the line will not be dedicated.
If you want dedicated performance, without traversing the internet you would need to look at AWS Direct Connect. However, this might limit your project because of cost.
One of the many limits to TCP throughout is:
Throughput <= EffectiveWindowSize / RoundTripTime
If your goal is indeed higher throughput, then you can consider tweaking the TCP window size limits. The default TCP window size under Linux is ~3MB. However, there is more to EffectiveWindowSize than that. There is also the congestion window, which will depend on factors such as packet losses and congestion control heuristics being used (eg cubic vs bbr).
As far as sanity checking the ping RTTs you are seeing, you can compare with ping times you see between an instance in AWS us-east-1 and GCP us-east4 when you are not using a VPN.

Does traffic going from AWS US-East to AWS Singapore travel over a priority route? Or is it subject to normal routing rules?

Does traffic traveling from AWS US-East to AWS Singapore travel over a priority route? Or is it subject to normal internet routing?
To paint an example:
Server A is in AWS-US-East (us-east)
Server B is in AWS-Singapore(southeast-asia)
Server C is in Azure-Singapore (southeast-asia)
Assuming the same network request is made to two different availability zones:
A <-- Http Request 1 --> B
A <-- Http Request 2 --> C
Would there be a noticeable speed increase when making network requests between Http Request 1 and Http Request 2 given that Request 1 travels between two AWS availability zones?
See Behind the Scenes: Exploring the AWS Global Network (NET305) from AWS re:Invent 2018, starting around 25:00. AWS manages the transport infrastructure connecting all the regions together, except for China... so inter-region traffic is routed across high-bandwidth, uncongested links under AWS's control.
This should typically offer the best case performance across distances like these. Connections on the public Internet are not likely to be any better. They might be comparable or they might be worse, but it is impossible to definitively say what the anticipated differences between your specific scenarios might be -- or how performance on the Internet might vary over time. Over the AWS network, performance should be quite consistent over time.
If you find a significant difference, you can deploy a proxy server in EC2 in ap-southeast-1 (Singapore) and use it from us-east-1 to contact the external service, instead of contacting it directly via the Internet. This will cause you to pay cross-region as well as out-to-Internet pricing for bandwidth, but that may be worthwhile if the route is either superior in latency or more consistent in performance and stability over time.

Network Latency between GCP server and linux data centres

What are the best practices to avoid network latency between GCP server and unix server. My client application, which is on linux, is accessing GCP end point, but facing network latency. How to avoid it.
Are you suspecting that part of the latency is not due to the distance between your server and GCP? If not then obviously all you can do is (1) place your server closer to your GCP node and (2) maybe cluster/parallelize your GCP requests if you have many of them.
So I suggest that you determine the distance between the two sites and compare it to the roundtrip time for your requests. If it's significantly larger then indeed you will have to analyze the structure of your requests.
Latency is not related to the OS you are using. Network latency is a measure of the time delay required for information to travel across a network. In all the factors that may affect this time delay, the one you can manage in cloud is the distance from the source to the destination. You can find other latency factors in this previous answer.
If you are looking to optimize the latency you could use a Cloud Load Balancer. Using Google Cloud Platform HTTP(S) load balancer, the requests are always routed to the instance group that is closest to the user. With load balancer you can also use Cloud CDN. Cloud CDN reduces latency by serving assets directly at Google's network edge.

How to direct traffic to different servers per geographic location?

If I have servers placed across the globe through AWS, Rackspace, some other cloud, or even bare metal, how do I direct traffic from, say Singapore, to a server instance living in the Asia region?
Is it some kind of load balancing, or DNS type things I would have to configure?
Thanks!
Use Route 53 Latency Based Routing: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingLatencyRRSets.html
UPDATE: Route 53 now support geolocation resource record sets:
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-geo.html
As Julio pointed out Latency Based Routing on Route 53 is a good option for this. One downside if you're hoping to say users in China go to this datacenter Route 53 won't do that for you. Instead they are constantly measuring the latencies to each of the AWS datacenters and will simply send people to the best AWS option (of the ones you have configured). To be honest this is probably good enough for you.
Lots of other DNS providers have similar offerings. I believe they however mainly focus on letting you decide where each region should go. I'm not a huge fan of this approach but it does give you a bit more flexibility at a cost of effort and potentially performance (if you're worried about that).