Local Zones and Wavelength Zones are a relatively new service (2022 initial launch) offered by AWS to help bring your latency-sensitive workloads closer to you. If an AWS Region itself is not close enough, you may want to consider utilising Local Zones or Wavelength Zones, depending on your requirements and the availability of these services.
In this post, I want to explore Local and Wavelength Zones with you. We'll discuss how and where they can be incorporated into your existing network environment and what advantages and workloads best suit this service.
AWS Local Zones
What is an AWS Local Zone
An AWS Local Zone is a type of infrastructure deployment that can place compute, database, storage and a few other AWS services close to large populations, cities or yourself, depending on where in the world you are. By utilising these services available in a Local Zone, you can build out your infrastructure and also utilise other services where required in the parent region that the Local Zone is connected to.
Local Zones are not generally available for every region in AWS, but only for a select few where AWS has deemed necessary. On the other hand, there is another type of Local Zones called Dedicated Local Zones. These are Local Zones built by AWS for exclusive use by a customer or community, featuring the same set of benefits and the opportunity for AWS to work with you to provide the security and compliance features you need in your own Private Zone.
AWS has a handy list of all locations where Local Zones are generally available and announced.
An AWS Local Zone itself is built out by you the same way you would build out services in a Single AZ (Availability Zone), so the same considerations must be applied to Local Zone configurations when created in terms of how redundant you want your service and fallbacks. For example, you may want to build out your latency-sensitive application in the Local Zone, but if that LZ went down for whatever reason, you could have a fallback/ load-balanced configuration to pull all workloads to another AZ. This would mean slightly higher latency in the unlikely event of the Local Zone failing, but your workloads can still operate.
What types of workloads would suit a Local Zone?
The workloads best suited to a Local Zone depend heavily on the requirements.
Do you require ultra-low latency from clients to servers?
Near real-time gaming connectivity.
Live streaming to a set of users locally in a region.
AR/ VR applications where low latency is imperative for immersion and assist with resolving motion sickness.
Low latency redundancy solutions?
- Do you already have a physical data centre in the area and don't want to set up a new one to implement DR (Disaster Recovery)? AWS Local Zones can help mitigate the cost of standing up a DR facility yourself and keeping data in the same vicinity.
Have Data Residency Requirements?
- To comply with state and local data requirements, Local Zones could assist you with this again.
Let's consider a local gaming event (eSports) hosted in Atlanta (US). We want to ensure that the connectivity between the clients in the competition and the servers hosting the game remains low-latency. You don't have the time and ability to stand up a few racks with the required hardware for the backend services, and you're utilising the on-premises network infrastructure and internet connection to get out.
In this scenario, utilising AWS Local Zones would be ideal. Local Zones have a Local Internet Ingress/ Egress point helping to maintain l0w-latency between client and server. We'd set up our EC2 instances with the backend applications required, Load Balancing, Security, etc, in the Atlanta Local Zone. Then, commission a fallback AZ within the North Virginia Region (US-EAST-1 is the parent region for the Atlanta Local Zone) if the local AZ fails.
Not all Local Zones are built the same.
Generally speaking, all AWS Local Zones have a select few similar capabilities. Each Local Zone that is implemented has the following services that are ready for you to provision;
EC2 (Elastic Compute Cloud)
EBS (Elastic Block Storage)
ECS (Elastic Container Service)
EKS (Elastic Kubernetes Service)
VPC (Virtual Private Cloud)
Direct Connect
This is where the similarities stop. Some local zones have additional capabilities, such as AWS Shield, ELB (Elastic Load Balancing), RDS and more. You can find the full list of supported capabilities in each Local Zone here.
Even when considering your compute requirements, you must consider the capabilities. EC2, for example, has variations on what instance types are available in each LZ, which can be found in the above link.
Any cost implications when considering AWS Local Zones?
In short, yes. You can still apply your purchasing practices with AWS Local Zones, such as utilising On-Demand, Savings Plans and Spot Instances, with the latter reducing your overall spending. When comparing the computing price alone, we can use the AWS Pricing Calculator for a general idea.
We will look at the region North Virginia (US-EAST-1) and the Local Zone Atlanta (N.Virginia being the parent region).
You can see in the image below that the T3 Medium instance has an on-demand hourly cost of $0.0416, and T3.xlarge is $0.1664.
Below is the pricing for the Atlanta Local Zone, which resides in the same region. A T3.medium instance has an hourly cost of $0.052, and a T3.xlarge is $0.208
So, when comparing compute resources in a Local Zone, we're looking at a total price increase of 25% over resources in its parent region. It's quite the increase, but again, Local Zones are not suited for all types of workloads and are really suited to special circumstances or requirements.
AWS Wavelength Zones
AWS Wavelength Zones operate on concepts similar to Local Zones to get workloads closer to your users. In the case of Wavelength Zones, these workloads would be advantageous to 5G-based devices/ users.
Wavelength Zones are AWS' offering to optimise your applications for mobile edge computing. How it works is AWS has set up Local Zones within telecommunications providers, bringing compute and resources even closer to mobile-connected users. When communicating with a Wavelength Zone the connection need not leave the telecommunications network, reducing latency that would typically occur when traversing multiple hops across the internet to reach its destination.
Depending on your workload, you could utilise an AWS Wavelength Zone to process urgent data while handing off the rest of the data to the parent region where the rest of your infrastructure remains. Expanding your VPC to include AWS Wavelength Zones allows you to build complex infrastructures easily while processing high-priority data at the edge closest to your users.
What types of workloads would suit a Wavelength Zone?
AI, ML and Image Analytics workloads, accelerating medical diagnostics, retail and IoT/ Smart Factory settings.
Connected Vehicle Infrastructure where you want to create advanced driver assistance and autonomous driving.
Using the Connected Vehicle Infrastructure workload type is a key example of how AWS Wavelength Zones can be of benefit. Data is constantly being sent and received via their inbuilt 5G modems and requires processing. This data can be quickly processed at the edge and sent back to the connected vehicle instantly while sending non-urgent/ high-priority data back to the VPC to be processed in the Parent Region.
Types of resources we can allocate in a Wavelength Zone.
This is where the key differences come in. Only a small subset of resources can be implemented compared to an ordinary AZ/ Region. These are;
EC2
EBS
VPC (Extend the VPC into the Wavelength Zone, creating subnets, etc.)
Carrier Gateways - Enables connectivity from the subnet in the Wavelength Zone to the Communications Service Provider (CSP) network, the internet, or the region through the CSP's network.
Costing for an AWS Wavelength Zone.
Similar to AWS Local Zones, there is another slight increase in pricing.
Below is the pricing for the Local Zone, as per above.
We can see here that there is a 7.6% price increase using AWS Wavelength Zones over AWS Local Zones and a 34% increase instead of utilising resources in the parent region.
How to enable a Local Zone in AWS
In this example, we'll show you how to create a Local Zone in AWS ready for resource provision via the AWS Console.
Firstly, go to your AWS Console and head over to the EC2 dashboard (Make sure you're in an AWS Local Zone supported Region). We're using N.Virginia is an example.
On the EC2 dashboard, to the right, you'll see a link labeled "Enable Additional Zones. " Click on that.
Find a Local Zone you want to enable in your account and click the radio button next to it.
At the top right, where it says "Actions", click on it and select "Manage Zone Group". You'll be asked to confirm and opt-in to enable the Local Zone. Go ahead and select "Update".
You'll be given an informational window advising you that you cannot disable a Local Zone once it has been enabled unless you contact AWS Support. Type "Enable" into the text field and select "Enable Zone Group".
You'll be returned to the Zones Settings window in the EC2 dashboard. Find the Local Zone you wanted to enable and see if the "Opt-in" is enabled. Click the little refresh button next to Actions if it is not enabled.
Head over to your VPC Dashboard in the AWS Console.
We now want to create a subnet for use in the new Local Zone we enabled. Head to "Subnets" in your VPC dashboard.
For this example, we're using the default VPC. As such, we already have the CIDR range 172.31.0.0/16 provisioned, so we'll use that. As per below, you can see we already have a few subnets created up to 172.31.80.0/20.
We'll create a new subnet called "Local Zone Sub" with the CIDR 172.31.96.0/20.
When creating new subnet, you'll be asked to place it into an Availability Zone. This is where we'll specify the newly enabled Local Zone; US EAST Boston.
Here's what our new subnet will look.
Go ahead and click "Create Subnet".
You can now see that we have created the subnet for the newly enabled Local Zone Boston. If you scroll over to the right, you'll be able to see the Availability Zone that subnet belongs to.
Beyond this, you'd want to create your routing entries if required. As we are using the default route table, all resources can reach each other locally and connect to the internet on the IGW; this goes for the newly created subnet in the Local Zone.
Once this is done, you can create resources in your VPC, specifying the new Local Zone we enabled as a target for these resources.
Final Words
I hope this blog post has helped you understand AWS Local Zones and where to use them in future projects best.
I want to thank you for reading, and if you have a spare minute, please share the post with your communities to help us achieve our goal of making Cloud Networking more accessible to all.