AWS Wavelength Zones

Advances in radio technology have enabled 5G networks to provide high-density radio (air) interfaces with extremely high bandwidth and reliability. However, improvements in the radio network alone might not be enough to meet the low latency requirements set by the 5G standards. Today, most consumer and enterprise applications that are accessed on mobile devices and other mobile endpoints are hosted on application servers outside of the communications service provider’s network.

Enabling applications to be run in edge computing infrastructure, close to end users, is essential to improving application latency. By running an application closer to its end point, the latency that comes from the number of hops needed for an application to reach the compute, storage, and cloud services it requires can be reduced. Accessing these resources in the cloud using traditional mobile architectures requires several hops on the network (from a device, to a cell tower, to metro aggregation sites, to regional aggregation sites, to the internet, to the cloud—and then back through those stops before getting back to the device). This creates tens to hundreds of milliseconds of latency.

The 5G network is up to ten times faster than 4G, but to take full advantage of the latency improvements that 5G offers, the number of network hops needs to be reduced.

AWS Wavelength for URRL and edge workloads

Reference architecture on AWS Wavelength Zones

AWS Local Zones are an extension of an AWS Region, and provide the ability to place resources closer to the end users. In comparison, AWS Wavelength Zones allow developers to build applications that deliver ultra-low latencies to 5G devices and end users. Wavelength deploys standard AWS compute and storage services to the edge of telecommunication carriers' 5G networks. From the technical architectural perspective, the approach is similar to AWS Local Zones. The Amazon VPC can be extended to one or more Wavelength Zones and then use AWS resources like Amazon EC2 instances to run applications that require ultra-low latency and a connection to AWS services in the Region.

A Wavelength Zone is an isolated zone in the carrier location where the Wavelength infrastructure is deployed; they’re tied to an AWS Region. A Wavelength Zone is a logical extension of a Region, and is managed by the control plane in the Region. A Wavelength Zone is represented by a region code followed by an identifier that indicates the Wavelength Zone (for example, us-east-1-wl1-bos-wlz-1).

To use a Wavelength Zone, you must opt in to the zone. After you opt in, create an Amazon VPC and subnet in the Wavelength Zone. Because deploying an OpenShift worker node on AWS Wavelength Zones is similar to doing the same in AWS Local Zones, only the steps specific to this setup are included.

Create a subnet in VPC for AWS Wavelength Zones

From the VPC where the OpenShift cluster is running, create a subnet for AWS Wavelength by providing the VPC ID, subnet name, Availability Zone (select Wavelength Zone) and CIDR. After the subnet for AWS Wavelength is created, create a Carrier gateway.

Opt in to the Wavelength Zone

Create a MachineSet for Wavelength Zones

Identically with how you create a MachineSet for Local Zones, create a MachineSet for Wavelength Zones. Replace the local zone and subnet ID with wavelength ID, and the subnet ID for it. Then apply the wavelength MachineSet to provision OpenShift worker nodes on the AWS Wavelength Zones.