For many years, placement of cloud infrastructure on the AWS cloud was limited to Regions and the associated Availability Zones. This has changed in recent years with the announcement of new products like Outposts, Wavelength, the Snow Family and, more recently, Local Zones, which now form part of the AWS Global Infrastructure. This is great news for those looking to achieve low-latency cloud performance.
First announced in 2019, Local Zones are a new type of AWS infrastructure deployment that delivers a subset of AWS services from locations that are closer to large population and industry centres and with the recent opening of the Perth Local Zone (the first of three announced Local Zones in Australia and New Zealand), it’s important to know how Local Zones work, when they might be useful and understand key considerations.
What are Local Zones and why did AWS create them?
AWS defines Local Zones as “a type of infrastructure deployment that places compute, storage, database, and other select AWS services close to large population and industry centres”. In essence, each Local Zone is an extension to an existing AWS Region (called the Parent Region) that allows for the provision of cloud services in a specific geographic area with the goal of reducing the network latency between these services and the end-users or systems interacting with them.
AWS launched Local Zones to help organisations achieve three specific goals, namely:
- Deploy low latency applications (e.g. gaming, social media)
- Deliver hybrid cloud architectures and migrations
- Meet data residency requirements (e.g. public sector or financial services industry)
Where are the Local Zones?
Local Zones first launched in the US where (at the time of writing) there are now 17 Local Zones and another 15 outside the US. Further, AWS has announced an additional 23 Local Zones across the globe, with the majority announced for release by 2024. AWS continues to launch new locations, so use the official list of AWS Local Zones locations to view current information.
Closer to home in Australia and New Zealand (A/NZ), the first Local Zone in our part of the world launched in Perth in January 2023 and Local Zones have been announced for Brisbane and Auckland.
All three Local Zones in A/NZ will have the Sydney Region as the Parent Region. Originally the Parent Region for the Perth Local Zone was going to be the new Melbourne AWS Region, however, this has since been revised. I expect that this is because adoption of the Perth Local Zone would have then been dependent on the launch and uptake of the Melbourne AWS Region, whereas using Sydney as the Parent Region allows AWS customers to easily take advantage of the A/NZ Local Zones.
These Local Zones provide opportunities to improve the delivery of cloud-based applications in Australia and New Zealand. For New Zealand AWS customers operating from the Sydney AWS Region, network traffic previously had to travel some 2,200 kilometres. And for Perth (one of the most remote cities in the world), the situation was even worse, with a distance to Sydney of approximately 3,300 kilometres. Some casual testing shows that ping times between a Perth-based NBN connection and instances in the Perth Local Zone average 15ms, whereas pinging instances in the Sydney AWS Region average 58ms.
By using Local Zones, services can be delivered within the local metropolitan area and achieve low single-digit millisecond latency, enabling new architectural possibilities.
How to make use of Local Zones
Before you can start deploying resources to a Local Zone, you first need to enable the Local Zone from within your AWS account and then extend a VPC in the Parent Region by adding a subnet in the Local Zone. This process is described in the user guide.
Once you have enabled the Local Zone, you can run applications using your choice of Amazon EC2, ECS or EKS.
Some example use-cases that come to mind are:
- If running latency-sensitive applications in an AWS Region is not performant enough, consider migrating these applications from the current data centre to a Local Zone
- Migrate corporate services like Active Directory Domain Controllers and File Servers from an office premises communications room to a secure AWS facility, without compromising on performance
- AWS FSx administrators could configure FSx File Gateway in the Local Zone (closer to users) and reduce the latency for file operations
- Use compute resources in the Local Zone for virtual desktops for video production, animation and rendering workloads
- Train ML models using GPU-accelerated compute in the Local Zone, backed by on-prem data stores
Considerations prior to using Local Zones
Before you jump right in, it is important to confirm a few things:
- What are your requirements for high availability?
It is critical to note that a Local Zone is not comprised of multiple Availability Zones, so typical patterns to achieve high availability by deploying resources to multiple Availability Zones in a single Region cannot be leveraged in the context of a single Local Zone. Patterns that leverage Local Zones with failover to the Region can be used to achieve highly resilient applications and I recommend reviewing the blog written by Rachel Rui Lui to gain a deeper understanding. - Are the features that you require available?
Similar to AWS Regions, there are differences in the availability of AWS services at different Local Zones. For example, the Los Angeles Local Zone was the first to launch and is the only Local Zone to offer FSx, RDS and ElastiCache. At the time of writing, many of the Local Zones do not have Amazon ELB or Direct Connect either. Use the published Local Zone services page to ensure that the services you require are available. - Which connectivity option(s) will you use?
Internet traffic originating from the Local Zone can break out directly by using an Internet Gateway. If you require NAT in the Local Zone, then unfortunately, you need to use NAT instances to achieve this requirement (because NAT Gateway is a service that operates from the Region).
To establish secure connectivity to a Local Zone, you have the option of using Direct Connect (if available in the Local Zone you are using) or a self-hosted VPN. Amazon Site-to-Site VPN is not currently available. The Direct Connect with Local Zones reference architecture is helpful in understanding how this works.If you are hoping to connect your data centre to a Local Zone, then you should understand that using Transit Gateway to do so is an anti-pattern, because this requires your data to hairpin via the Region first, which increases the latency and erodes the value of using Local Zones in the first place.
Are the EC2 instance types and EBS volume types that you require available?
The range of EC2 instance types available in Local Zones is much more limited than that of AWS Regions, and many of the newer instance types are not available (such as Graviton-powered instance types). You can determine which instance types are available in a Local Zone by using the Instance Types section of the EC2 Console, the DescribeInstanceTypeOfferings API, or checking the Local Zone services page.Outside of LA, the only EBS volume type available is gp2, so you will not be able to create gp3, Provisioned IOPS or HDD-backed volumes.
Where next for Local Zones?
Because AWS launches services and then uses customer feedback to improve them over time, I am sure that AWS will continue to build out the available features in Local Zones. There are several areas that I would like to see improved to increase the usefulness of Local Zone adoption:
- Provide Direct Connect at all locations and add support for Site-to-Site VPN (perhaps via Cloud WAN).
- Provide the ability to run latency-sensitive End User Compute workloads so that the Local Zone becomes a more viable replacement for desktops (AWS WorkSpaces and AppStream).
- Provide the ability to run latency-sensitive services that are commonly used on-premises to provide a pathway for migrating these workloads to the cloud (e.g. replacing file shares with AWS FSx).
The addition of Local Zones to the AWS Global Infrastructure creates new opportunities to improve resilience and performance of applications, and I’m excited that my hometown now has one. If you would like to take advantage of the Perth Local Zone (or Brisbane or Auckland when they launch), then please get in touch!
