High latency issues in application/service delivery have adverse effects on both financial outcomes and customer satisfaction. While the reasons behind such issues may vary, the physical distance between the client and the server consistently remains one of the primary factors to consider.
AWS offers a purpose-built solution to address such challenges: Local Zones. This blog post will explore AWS Local Zones and outline some considerations before using them.
AWS Local Zones are extensions of AWS Regions, strategically located to offer computing, database, storage, and various other AWS resources in close proximity to specific geographic locations, like major urban hubs and industrial centres. The primary objective is to provide users in these areas with low-latency access to these resources.
Currently, there are 33 Local Zones distributed globally. This number can change over time as new zones are continually being introduced. You can access the complete list of these Local Zones here.
Local Zones can be utilised for various use cases like;
Establish hybrid environments by migrating your on-premises workloads to Local Zones, achieving low latency while preserving a hybrid setup.
Adhering to strict data location regulations to meet state and local data residency requirements in sectors like healthcare, financial services, and government.
- AWS has recently announced Dedicated Local Zones, providing an advanced solution for clients seeking greater privacy and control over resource placement. This allows clients to choose and place their resources within physically separate data centres exclusively for their use. AWS collaborates with customers to configure Dedicated Local Zones, ensuring compliance with their regulatory requirements.
Each Local Zone is linked to a parent AWS Region. Although Local Zones are distinct physical data centres, they maintain a logical connection to the parent Region, facilitating seamless integration with the wider AWS ecosystem.
Although Local Zones share some networking characteristics with Regions and can be managed using route tables, subnets, security groups, and ACLs, there are several differences to consider before starting to work with them;
Routing:
- Local Zones can be accessed through various public and private connection options, including Direct Connect Gateways, Transit Gateways, NAT gateways, Internet Gateways, and VPNs. Before we discuss the considerations with these connection types, let's quickly recap what they are.
- Direct Connect Gateway: allows you to connect your on-premises to AWS through a dedicated network connection.
- Transit Gateway: a central hub enhances connectivity between multiple VPCs and on-premises.
- Internet Gateway: enables communication between AWS and the internet.
- NAT Gateway: enables your resources in a private subnet to initiate outbound traffic to the internet.
- VPN: a secure connection method that allows you to establish a private and encrypted connection over the internet.
- Traffic to/from the internet is routed via the Local Zone directly without any hop in between when using Internet Gateway.
- A NAT Gateway can also serve in a private subnet scenario with the same operational characteristics.
Same as the traffic to/from an on-prem data centre when using Direct Connect.
This direct traffic flow provides low latency, often reaching single-digit latency figures, thereby enhancing your application's response performance.
Creating a transit gateway attachment for subnets in Local Zones is not possible. Therefore, an additional step will be introduced when accessing the Local Zone through a Transit Gateway, as direct connection is not possible. Before reaching the Local Zone, traffic now follows a route through the parent region.
Choosing this approach with a Transit Gateway is not advisable due to the potential latency increase it may cause.
As expected, the same issue arises when you want to connect Local Zones on different VPCs within a region. The traffic again traverses the parent zone before reaching the Local Zone.
Availability:
Numerous AWS services are available to be utilised with Local Zones, but it's important to note that not all services will be accessible to you.
As can be seen from the list referenced below, at the time of this post,
- Only certain EC2 instance types are available
- RDS is the only available database solution
- AWS Shield Standard is the only available option for security
- You can use ALB in some local zones for load balancing, but NLB is not available If needed, etc..
Depending on your location, the current list of available services can be found here.
Cost:
Local Zones can be enabled at no additional cost, but using some AWS services in Local Zones costs slightly more than running them in AWS Regions.
By choosing the location type filter, you can estimate and compare prices using the AWS Pricing Calculator.
In summary, AWS Local Zones offer low-latency access to a range of AWS resources for specific locations, but they come with few routing and service availability considerations. While Local Zones have no additional costs, some services may have slightly higher pricing. As AWS continues to expand, Local Zones remain a valuable choice for improved performance and compliance within your AWS infrastructure.
To follow the updates with Local Zones, please visit What’s new with AWS?