Get Started Deploying Low Latency Applications with AWS Local Zones
AWS Local Zones are a type of infrastructure deployment that places compute, storage, database, and other select AWS services close to large population and industry centers, enabling you to deliver applications that require single-digit millisecond latency to end users.
What you will accomplish
In this guide, you will learn how to:
- Choose the right AWS infrastructure to deploy your latency-sensitive workloads in AWS
- Opt in to a Local Zone from the AWS Management Console
- Extend your Amazon VPC from a Region to your chosen Local Zone
- Launch an EC2 T3 instance within your Local Zone
- Clean up your resources
You will need an AWS account to complete this tutorial. If you do not have an AWS account, create a new AWS account to get started.
Time to complete
Cost to complete
This tutorial provisions EC2 t3.medium instances on AWS Local Zones. The cost to the trainee will depend on the volume and time for which the t3.medium instance is provisioned and the Local Zone selected.
- AWS account
- Recommended browser: The latest version of Chrome or Firefox
[**]Accounts created within the past 24 hours might not yet have access to the services required for this tutorial.
Speed test hosted on GitHub
November 3, 2022
Identify the AWS site with the lowest latency to your site
To identify the site in the global AWS infrastructure with the lowest latency, you can use this test portal, which provides a latency response from your location to the AWS Regions and Local Zones, highlighting the AWS infrastructure that returns the lowest latency to your location. The portal runs 120 seconds of performance tests against endpoints located across AWS Regions and Local Zones and measures latency readings in milliseconds. To get the most accurate measurement, wait for the tests to finish. The portal will highlight in green the best AWS site to deploy your latency-sensitive workloads based on your location. If you need to compare the results with the availability of services in every location, see the AWS services availability table on the AWS Local Zones features page or the AWS Regional Services page for service availability by Region.
Note: To complete this tutorial, identify the Local Zone with the shortest latency to you (be sure to select a Local Zone, and not a Region). You should capture the Local Zone ID and its Parent Region from this tool, because both will be required to complete this guide.
Step 1: Opt in to an AWS Local Zone
1.1 — Sign in to the AWS Management Console, then choose the correct Region from the top-right corner.
Step 2: Extend your Amazon VPC to the Local Zone
2.1a — Navigate to Amazon VPC in the AWS Management Console and confirm that you have a default VPC. In the Default VPC column, look for a value of Yes.
If you do not have a default VPC, jump to Step 2.1b; otherwise, jump to Step 2.2a.
2.1b (only if required) — If you do not have a default VPC in your account/Region, follow the steps for creating a default VPC in the Amazon VPC User Guide.
Continue to Step 2.2a.
2.2a — Confirm that there is an internet gateway (IGW) attached to the default VPC. Go to Filter by VPC, choose your default VPC ID, select Internet gateways, and then confirm that an IGW is attached to the VPC.
If there isn’t an IGW attached to your default VPC, continue to Step 2.2b; otherwise, jump to Step 2.3a.
2.2b (only if required) — If you don’t already have an internet gateway attached to your default VPC, create one and attach it to your VPC. From the Virtual private cloud dropdown menu, select Internet gateways. Next, in the upper right corner, choose the Create Internet gateway button and then select Attach to VPC.
Continue to Step 2.3a.
2.3a — Verify that your default route table (RTB) has a default route to the internet gateway. With the filter applied under Filter by VPC in the previous step, from the Virtual private cloud dropdown menu, select Route tables. In the Main column, you should see Yes as the value listed.
If there isn’t a default route table (0.0.0.0/0) with IGW as the Target, continue to Step 2.3b; otherwise jump to Step 2.4.
2.3b (only if required) — Create a default route (0.0.0.0/0) in the main route table attached to the default VPC. With the filter you applied in previous steps in Filter by VPC, select Route tables and check the main route table. Choose the Routes tab and then choose the Edit routes button to open a new window.
In the Edit routes window, add the default route to your default VPC. Then, choose the Save changes button.
Continue to Step 2.4.
2.4 — Create a subnet as part of your default VPC mapped to the Local Zone that you enabled in Step 1.3. At this stage, your default VPC has a subnet both in the Region (the default subnet) and in the Local Zone. The internet gateway will be available for the VPC and all its subnets.
Go to your VPC dashboard. From the Virtual private cloud dropdown menu on the left, select Subnets. Next, choose the Create subnet button. Then, choose your default VPC and enter a name in the Subnet name field. In the Availability Zone section, choose your Local Zone. In the Subnet settings window, under IPv4 CIDR block, define the subnet CIDR, then choose the Create subnet button.
Note: There is a separate block of external IP address space dedicated to each Local Zone. Local Zones do not support “bring your own IP addresses (BYOIP).”
Continue to Step 3.
Step 3: Launch a t3.medium instance in a public subnet in Region and in the Local Zone
3.1 — Navigate to the Amazon EC2 console and choose the Launch instance button. For more information on how to launch an instance using the instance wizard, visit Launch an instance using the new launch instance wizard.
(This tutorial uses EC2 T3 instance as an example. Availability of EC2 instance types can vary by Local Zone. Please see our features page for the full list of instance types available by Local Zones. If T3 instance is not available in the Local Zone closest to you, please select another available instance type and proceed with the steps in this tutorial.)
3.3 — In the Instance type section, select t3.medium. Then, choose Next: Configure Instance Details.
3.6 — Create a security group to allow access to specific ports.
- You will need to connect to your instance to install the speed test, so port 22 TCP (SSH) must be added in the security group.
- The speed test uses port 80 (HTTP), so port 80 TCP (HTTP) must be added in the security group.
In the next section of Network settings, create a security group with these two rules:
Step 4: Install speed test and test your latency
We will now test our latency using a lightweight speed test hosted in this Github repository.
You can now connect to your instance using an SSH client from a Unix shell. If you need to access the instance from a Windows machine, follow these instructions: Connect to your Linux instance from Windows using PuTTY. To simplify the process of connecting to the instance, you can select the check box next to the instance name and choose Connect.
chmod 400 <key-pair-name>.pem ssh -i /path/key-pair-name.pem instance-user-name@instance-public-dns-name Example: ssh -i "speedtest2.pem" ec2-user@ec2-AA-BB-CC-DD.compute-1.amazonaws.com Last login: Mon Oct 31 19:12:07 2022 from <your-public-ip> __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ -bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory [ec2-user@ip-10-0-3-68 ~]$
Next, install Docker following this guide, under the section Installing Docker on Amazon Linux 2. You will need to do this to run the speed test application.
First, verify that Docker is properly installed by running:
sudo docker info
sudo docker run --name speedtest -d -p 80:80 e7db/speedtest
First, in the EC2 console on the Instances page, find your public IP address.
Connect to the URL: http://<insert public IP of your EC2 here>. You will see the following interface:
Using these speed test results, you will be able to confirm how close the latency measurements are in comparison with the results you obtained from the test portal for your Local Zone. If you compare these results with those in the Region, you will notice that you typically get lower values from Local Zones because the traffic goes directly to its Network Border Group without traversing its parent Region. This example has helped identify the AWS infrastructure type and location that provides you with the lowest latency from your location, which is directly related to the physical distance between you and the AWS infrastructure.
Step 5: Clean up resources
Now that you have finished the tutorial, you need to clean up the resources you created.
5.1 — Delete your EC2 instance.
You should complete this step to ensure you do not continue to incur EC2 charges after completing this tutorial. In the EC2 console, go to the Instances page. From the Instance state dropdown menu, select Terminate instance to terminate the WebApp-LatencyTest instance.
5.2 — Delete the extended VPC subnet in your AWS Local Zone.
In the Amazon VPC console, go to the Subnets page and select the subnet you deployed in your Local Zone.
Congratulations! You have finished the Get Started Deploying Low Latency Applications with AWS Local Zones guide. You can now provision EC2 instances in Local Zones for workloads that require low latency as well as those that are not in an AWS Region close enough to meet your latency requirements. Please note, not all EC2 families and sizes are supported in Local Zones. Please see the EC2 pricing page for EC2 family and size availability in the selected Local Zone.
One more thing! Please make sure you clean up using the steps in the Clean up resources section before continuing your AWS journey in the Next steps section below.