Delays in application delivery not only hurt the bottom line, they provide a negative customer experience.
Placement within the AWS global infrastructure affects how well an application performs. Still, it is an oversimplification to say that the distance between the client and the server is the cause of network latency.
Data travels through fiber optic cables at the speed of light. Unfortunately, the TCP/IP protocol does not employ direct, uninterrupted connections. Instead, requests hop from router to router, with data packets read and rerouted at each stop.
For example, an HTTP request from Toronto to the TechTarget server in Boston required seven hops to complete. These hops create latency.
Amazon offers IT teams the following ways to design high-performance, low-latency architectures:
- AWS Regions. Provide a full suite of compute, data storage and serverless capabilities.
- AWS Local Zones. Provide compute power near high-density populations.
- AWS edge locations. Quicken the delivery of cacheable resources to customers around the world.
- AWS Outposts. Allows companies to install AWS hardware inside their own data center.
With an understanding of the global distribution of your customer base, your application's latency requirements and your project's budget, these options can be optimally combined to build an architecture that best suits your cloud computing needs.
But how do you know if AWS Local Zones is the right choice for your low-latency app? Learn more about Local Zones and its uses, as well as how it compares with other options.
AWS Local Zone benefits and use cases
Amazon builds AWS Local Zones near densely populated city centers to reduce the round-trip distance data must travel to fulfill nearby users' web-based requests. For example, a Dallas user in the AWS Local Zone in Dallas cuts more than 2,000 miles from the roundtrip distance packets must travel versus the parent region's data center in Northern Virginia. Since these zones are placed in close proximity to the clients who use them, low-latency applications can meet rigorous service-level agreements requirements.
The response time of a web-based request is a combination of the following two factors:
- Origin time. How long it takes the server to process the request.
- Round-trip time. How long a request takes to travel back and forth across the network.
A well-designed AWS architecture, built upon technologies like Amazon EC2, Amazon EKS and serverless functions, can bring the origin time down to less than 10 milliseconds. At these service levels, total response time becomes entirely dependent upon how long it takes data to travel across the network.
AWS Local Zones reduce the number of network hops required to route a request and provide high-speed, private access to the Amazon network backbone.
A Local Zone also reduces the number of hops between the Local Zone, the closest Availability Zone (AZ) and systems that run in other AWS Regions around the globe.
With per-usage rates that are only marginally higher than the AZ hosted equivalent, AWS Local Zones are an effective, budget-conscious way to reduce response times for latency-sensitive applications. For applications that require extremely low latency but must also access block storage or microservices hosted in remote AWS regions, the use of an AWS Local Zone makes sense.
High-frequency trading is a compelling use-case for AWS Local Zones. For every city in the Western world that has a high-volume stock exchange, Amazon has either announced or implemented a fully functional nearby AWS Local Zone. The majority of AWS Local Zones provide support for AWS compute-related services such as EC2, EBS, EKS and more.
Other examples of applications that benefit from reduced latency and the local compute capacity an AWS Local Zone provides include:
- Medical automation.
- Military and policing.
- Real-time gambling.
- Online auctions.
- Virtual reality gaming.
- Cloud-based IDEs and editors.
Persistence services such as block storage, relational systems and NoSQL databases are generally not available in Local Zones. To access any AWS Service other than the limited set offered through the Local Zone, enterprises will need a more remote AZ.
Most applications require access to persistent storage services such as Amazon S3 and Amazon Relational Databases (RDS). Most applications require access to persistent storage services, such as S3 or RDS, so hosting any application in a Local Zone that requires constant access to data stored in a remote AZ would defeat the purpose. After all, why not host everything in the more remote AZ if every request fetches S3 or RDS data stored there?
This is where network latency and the way the AWS backbone connects Local Zones to their parent region come into play.
Compare Local Zones with other AWS options
AWS has several options to place resources close to densely populated areas, which are comparable to Local Zones.
Content delivery networks (CDNs) such as Cloudflare, Akamai and Amazon CloudFront also place resources closer to those who access them. A CDN caches static content at more than 150 edge locations. AWS CloudFront routes HTTP traffic to the edge location closest to the client making the request. CloudFront greatly reduces download times for shared files that rarely change, such as images, videos, CSS files and HTML pages.
While CloudFront and Local Zones solve the latency problem through servers, the specific use case each service addresses is quite different.
There's a key difference between CloudFront edge locations and AWS Local Zones. CloudFront will serve shared, static, cached content from any one of more than 150 edge locations around the world, while a Local Zone is a single, redundantly designed data center located close to large, urban populations with the ability to provide AWS compute services.
Unlike an AWS Local Zone, edge locations do not allow users to host applications, manage Kubernetes clusters or run serverless Lambda functions. In contrast, AWS Local Zones support services like ECS and EC2.
Webpage metrics like time-to-first load or time-to-first byte are improved using edge locations. CloudFront cannot improve response times for applications that require compute power.
If the need is to improve response times for low latency, data processing applications that require application logic, only AWS Local Zones meet the requirements.
An AWS Local Zone provides more services than an edge location, but far fewer than an AWS Region's AZ. Local Zones are only guaranteed to host compute offerings such as EC2, ECS and EKS services. When accessed through a Local Zone, compute services come with a slightly higher cost than equivalent ones hosted in the Region's AZ.
For example, a Windows-based, t3.xlarge system with 16 gibibytes (GiB) of memory would cost $0.24 per hour if hosted in an Oregon Availability Zone; in the Denver Local Zone, the hosted price rises to $0.28 per hour.
Local Zones are limited in the types of server configurations that are available for deployment. For example, the Denver Local Zone does not have t3.large EC2 instances available for deployment, while all AZs do.
For extremely low-latency applications where a double-digit response time is unacceptable or where AWS Local Zones are unavailable, AWS customers have the option to purchase an AWS Outpost.
An AWS Outpost is a physical server costing an estimated $150,000 to $750,000 depending on the type of unit. It comes preconfigured with various AWS services such as RDS, S3, EKS and EC2. Since an AWS Outpost is a physical piece of hardware that sits inside a company's data center, the network latency for direct connections is negligible. Low, single-digit response times are possible.
One of the primary use cases for AWS Outposts configured with RDS and S3 support is data sovereignty law compliance. When companies want to use Amazon services, but compliance regulations forbid offsite storage in the cloud, Outposts brings the AWS cloud into the client's on-premises data center.
Configured with a high-speed, AWS Direct Connect linkage to a Local Zone or AZ, AWS Outposts are the lowest latency option. However, AWS Outposts does not support the same number of services as an AZ in an AWS Region.