Improving latency times for EC2 from different geographic areas - amazon-web-services

We have an EC2 instance in US East, and our latency for users in the UK + AU is about 1-2 seconds higher. We are only dealing with text data and an RDS server in the same zone. Provided we want to go the route of creating another image instance of the primary EC2. How does the process work in lowering latency? Per our understanding:
Create a replica from the image in AU/UK zones
Add the external IP's of these two servers to the domain nameserver which will automatically generally help route the user to the closest server?
Or does it involve creating some sort of load balancer with a geographic rule, and the load balancer IP is what our NS will be?
TLDR: How do we route UK users to the UK EC2 server, what does the setup look like?

I recommend that you use Latency-based routing - Amazon Route 53:
If your application is hosted in multiple AWS Regions, you can improve performance for your users by serving their requests from the AWS Region that provides the lowest latency.
You would configure one DNS Name to route to multiple IP addresses. Route 53 will examine the location of the incoming request and route the traffic to the destination with the lowest latency.
This is not quite the same as geographic routing because some countries have better Internet connectivity and traffic will be routed according to latency rather than distance.
Alternatively, you can use AWS Global Accelerator, which routes traffic across the AWS global network. It uses a single IP address that exists in multiple locations (known as anycast) to redirect traffic to the closest (fewest-hop) endpoint of the AWS global network, then sends traffic over that network to the closest AWS location where you have provisioned services. This can achieve lower latency than routing across the Internet, but incurs a per GB cost for traffic.

Related

Will route53 choose the closest region to serve the request?

I am planning to deploy my api gateway to multiple regions in AWS. I implement a health endpoint in the gateway in each region and configure them in route53 healthy check. So route53 will forward the request to the healthy regions if one region fails on healthy check.
My question is in case of all regions are healthy, will route53 route traffic to the closest region? For example, if there are 2 regions configured in route53, ap-southeast-1 and ap-southeast-2, can route53 route the traffic to ap-southeast-2 if the request is from Sydney since it is closer? If yes, how does route53 decide which one is closer?
Yes, you can do that using Route 53 Geolocation routing policy, which can be used when you want to serve your site based on the location of the client or user.
There are three routing policies in R53 that you may consider:
Geolocation routing policy – Use when you want to route traffic based on the location of your users.
Geoproximity routing policy – Use when you want to route traffic based on the location of your resources and, optionally, shift traffic from resources in one location to resources in another.
Latency routing policy – Use when you have resources in multiple AWS Regions and you want to route traffic to the region that provides the best latency.
how does route53 decide which one is closer?
Geolocation is based the location that DNS queries originate from.
Geoproximity routing lets Amazon Route 53 route traffic to your resources based on the geographic location of your users and your resources.
Latency-based routing is based on latency measurements performed over a period of time.
For all these, AWS can also use EDNS0 edns-client-subnet extension.

Is it possible to map different domain names to one IP address in AWS?

I'm not sure if this is the right place to ask this. If it's not, kindly refer me to the most appropriate place.
I need to have customized domain names for my clients but only one instance of the web app. Is this possible? How do you I go about this?
The answer may simply be yes. But it's not up to AWS, but rather the DNS for the domains you plan to use. All the application running on the AWS IP address has to do is not reject the domain names given to the web server stack in its configuration.
You can create as many domain names as you like to point to a single IP address using AWS route 53 hosted zones. You can create multiple A record in route 53 or you can utilise alias records.
Amazon Route 53 is a highly available and scalable cloud Domain Name
System (DNS) web service. It is designed to give developers and
businesses an extremely reliable and cost effective way to route end
users to Internet applications by translating names like
www.example.com into the numeric IP addresses like 192.0.2.1 that
computers use to connect to each other. Amazon Route 53 is fully
compliant with IPv6 as well.
Amazon Route 53 effectively connects user requests to infrastructure
running in AWS – such as Amazon EC2 instances, Elastic Load Balancing
load balancers, or Amazon S3 buckets – and can also be used to route
users to infrastructure outside of AWS. You can use Amazon Route 53 to
configure DNS health checks to route traffic to healthy endpoints or
to independently monitor the health of your application and its
endpoints. Amazon Route 53 Traffic Flow makes it easy for you to
manage traffic globally through a variety of routing types, including
Latency Based Routing, Geo DNS, Geoproximity, and Weighted Round
Robin—all of which can be combined with DNS Failover in order to
enable a variety of low-latency, fault-tolerant architectures. Using
Amazon Route 53 Traffic Flow’s simple visual editor, you can easily
manage how your end-users are routed to your application’s
endpoints—whether in a single AWS region or distributed around the
globe. Amazon Route 53 also offers Domain Name Registration – you can
purchase and manage domain names such as example.com and Amazon Route
53 will automatically configure DNS settings for your domains.

Google cloud load balancer unevenly distributes traffic

I have created instance groups with 3 instances and GCP load balancer of type HTTP/2.
When I hit the load balancer's IP, the requests get randomly distributed say I hit 12 requests since there are 3 instances the load distribution should have been 4 per VM but it doesn't happen in a round robin away. Is there any possibility that I can achieve this in GCP?
The algorithm used by the GCP load Balancing is intended to distribute load according to the geographic location of the clients. If more than one zone is configured with backends in a region, the traffic is distributed across the instance groups in each zone according to each group's capacity.
The Round-robin algorithm is present only when you create a backend made of instances within the same zone; in that case the requests are spread evenly over the instances.

AWS alternative to DNS failover?

I recently started reading about and playing around with AWS. I have particular interest in the different high availability architectures that can be acheived using the platform. Specifically, I am looking for a reliable poor man's solution that can be implemented using the least amount of servers.
So far, I am satisfied with solutions for the main HA concerns: load balancing, redundancy, auto recovery, scalability ...
The only sticking point I have is with failover solutions.
Using an ELB might seem great, however ELB actually uses DNS balancing under the hood. See Is AWS's Elastic Load Balancer a single point of failure?. Also from a Netflix blog post: Lessons Netflix Learned from the AWS Outage
This is because the ELB is a two tier load balancing scheme. The first tier consists of basic DNS based round robin load balancing. This gets a client to an ELB endpoint in the cloud that is in one of the zones that your ELB is configured to use.
Now, I have learned DNS failover is not an ideal solution, as others have pointed out, mainly because of unpredictable DNS caching. See for example: Why is DNS failover not recommended?.
Other than ELBs, it seems to me that most AWS HA architectures rely on DNS failover using route 53.
Finally, the floating IP/Elastic IP (EIP) strategy has popped up in a very small number of articles, such as Leveraging Multiple IP Addresses for Virtual IP Address Fail-over and I'm having a hard time figuring out if this is a viable solution for production systems. Also, all examples I came across implemented this using a set of active-passive instances. It seems like a waste to have a passive for every active to achieve this.
In light of this, I would like to ask you what is a faster and more reliable way to perform failover?
More specifically, please discuss how to perform failover without using DNS for the following 2 setups:
2 active-active EC2 instances in seperate AZs. Active-active, because this is a budget setup, were we can't afford to have an instance sitting around.
1 ELB with 2 EC2 instances in region A, 1 ELB with 2 EC2 instances in region B. Again, both regions are active and serving traffic. How do you handle the failover from 1 ELB to the other?
You'll understand ELB better by playing with it, if you are the inquisitive type, as I am.
"1" ELB provisioned in 2 availability zones is billed as 1 but deployed as 2. There are 2 IP addresses assigned, one to each balancer, and 2 A records auto-created, one for each, with very short TTLs.
Each of these 2 balancers will forward traffic to the instance in its same AZ, or you can enable cross-AZ load balancing (and you should, if you only have 1 server instance in each AZ).
These IP addresses do not change often and though it stands to reason that ELBs fail like anything else, I have maybe 30 of them and have never knowingly had a dead one on my hands, presumably because the ELB infrastructure will replace a dead instance and change the DNS without your intervention.
For 2 regions, you have little choice other than using DNS at some level. Latency-based routing from Route 53 can send people to the closest site in normal operations and route all traffic to the other site in the event of an outage of an entire region (as detected by Route 53 health checks), but with this is somewhat more likely to encounter issues with DNS caching when the entire region is unavailable.
Of course, part of the active/passive dilemma in a single region using Elastic IP is easily remedied with HAProxy on both app servers. It's an http request router and load balancer like ELB, but with a broader set of features. The code is so tight that you can likely run it on your app servers with negligible CPU consumption. The instance with the EIP would then balance traffic between its local app server and the peer. Across regions, HAProxy behind ELB could forward traffic to a mate in a remote region, if the local region is up but for whatever reason the application can't serve requests from the local region. (I have used such a setup to increase availability of external services, by bouncing the request to a remote AWS region when the direct Internet path from the local region is not working.)

Amazon availability zones

I'm fairly new to Amazon services and wondering what some of the best practices are for clustering/load balancing?
I have a load balancer in my colo (NJ) which may potentially be upgraded to Netscaler.
The application we're hosting on Amazon is nothing crazy and don't expect too much traffic. We're looking at 2 linux instances that would run a Node JS application with a MongoDB replica set. From what I understand, Amazon will evenly divide the traffic amongst the zones. The end-users location has no effect on where they'll be distributed (ie if I have a server in the west coast and one in the east coast, the user in the east coast could be directed to either east or west).
If I wanted to direct users traffic based on location, a global DNS solution would make more sense?
One server would be the master db and the other would be slave with data replicating to each other.
Anybody have any experience with this and how is the network performance?
A question about EC2/S3
EC2 Instances and S3 buckets can only communicate if they are in the same region, correct?
The load balancer only works within one region. If you want to balance traffic between different regions you will need to look at latency based routing in Route 53. Keep in mind that availability zone and region have different meanings within EC2
MongoDB replica set is a flexible master/slave configuration. If the primary instance fails, a secondary, based on configured priority can automatically become primary. Network within a region is fast, you will have some latency if you use multiple regions.
EC2 instance can access an s3 bucket in any region, you wont pay for outgoing bandwidth if both are in the same region.