Living on the AWS Edge - Local Zones

AWS has an array of computing solutions to bring your applications to the edge.  In this installment of Living on the AWS Edge we are looking at Local Zones.  In our last installment we covered Outposts, and in the future, we will review additional AWS edge offers; right now let's dig in on Local Zones.

What are Local Zones?

In working with my peers at AWS we have had conversations on what a local zone consists of, how many and why you would need to work with F5 to address your application delivery and secuirty needs.   This is the feed back from AWS:

AWS introduced Local Zones in 2019 starting with Los Angeles and currently has grown to 34 worldwide with more to be launched (AWS Local Zones locations). AWS Local Zones is a type of AWS infrastructure deployment that place AWS compute, storage, database, and other select services closer to large population, industry, and IT centers. Local Zones enable organizations to run latency-sensitive applications close to end-users and resources in a specific geography, delivering single-digit millisecond latency for use cases such as media & entertainment content creation, real-time gaming, reservoir simulations, electronic design automation, and machine learning.

 When organizations adopt Local Zone they must recognize that it is an highly secure AWS infrastructure with key services (EC2, EBS, ECS, EKS, VPC, DX and ALB*) and not all AWS services, traffic management and tools are present compared to an AWS region.  Some Local Zones may not have a native load balancer (ALB), web application firewall or network firewall service.  This means that if you are running an application that requires traffic management bundled with security, you need the support of an ISV such as F5.  

At present, customers using Local Zones also need to address Web Application security and Network security challenges such as WAF, L7 DoS, Behavioral security, bot protection, deep packet inspection, IPS or authentication at the app layer, additinoally you may need to do this in Local Zones that have different services. With BIG-IP you can address all these challenges and requirements in all Local Zones globally.

Setting the Stage – a primer on F5 Software and Services

If you are reading this, it is evident you know that F5 Local Traffic Manager is what provides the traffic management in our Local Zone deployment; many of you are aware that F5 Advanced Web Application Firewall will provide the application security; in my journeys I have found that people are pleasantly surprised about the network firewall and Intrusion Prevention Services that F5 Advanced Firewall Manager provides.  When we combine these services onto the same platform, we also decrease the impact of them on the network; after all the choice of Local Zone is driven by latency and getting closer to the customer and the risk of deploying without security services is too great. 

 Evaluating a Deployment

 When deploying into a Local Zone the workflow is not that different deployments in a region.  Local Zones require a user to opt in (or register) for usage and present themselves as a single AZ extension of a region.

 

You configure subnets and use internet gateways just like you would in a region with one difference: the creation of an elastic IP requires you to select the AWS Network Border group that is assigned to the Local Zone.  A network border group is an IP range that is routed in/out of the local zone ensuring creating the "short" path to the users you are trying to connect the application to over the internet.

 

The instances in your VPC will all have the same IGW, with the IP range selected for the EIP controlling the ingress/egress point.  The subnets you deploy will also be associated with the Local Zone AZ and the network border group.

If you look at the route table for my public, Local Zone exposed applications it does not look any different than a public route table in a region, we use an Internet Gateway.

BIG-IP in the local zone can be deployed using Active/Standby or Active/Active configurations.  Active/Active deployments are an array of instances that can be deployed without API integrations into AWS. We will look at Active/Standby configuration and will present an application via an EIP from the Hamburg network border group for our validation.  If you read the blog on using Outpost the topology will look familiar to you.  

By using the standard and well documented CFE configuration you can easily integrate BIG-IP into your Local Zone deployments manipulating the mapping of Elastic IPs, Secondary IPs, and routes. 

Now that we have validated that CFE can integrate with our Local Zone deployment we consider other scenarios. What about deployments that need (or want) to have more than one active BIG-IP deployment? What about elasticity? One option is to repeat the pattern above with multiple active/standby instances above but that may not be the most optimal use of resources.  In scenarios where we are scaling horizontally, we can look at deploying N Active instances in the Local Zone. 

To accomplish this, we need to introduce upstream disaggregation.  This disaggregation of traffic happens at the name resolution event using Global Server Load Balancing.  The specific GSLB service could be provided by F5 DNS or could be AWS Route 53.   No matter what disaggregation you use it is time well spent to learn the F5 declarative APIs such as AS3 and DO. 

Can the app run on….? 

Yes.  At F5 we are impartial of the compute services that support the application.  EC2, EKS, ECS no problem.  Service discovery? Sure thing. We can find the applications by DNS, ENI tag, or instance TAG.  For example, if you are using ECS and cloud map we can query the records that are placed in Route53 by Cloud Map? If you customer cannot use Cloud Map tag the ECS task running in AWS VPC mode, and we will find the ENI associated with the service. AWS Auto Scale? Tag the instances or provide the Auto Scale group kev:value pair to BIG-IP and we will find the services.  If you are using EKS we can integrate BIG-IP directly with F5 Container Ingress Services (CIS) or with CIS + NGINX Ingress link for customers that either want to use NGINX for Kubernetes Ingress or want more separation between the edge network services and the EKS based application. Using BIG-IP combined with Local Zone supports that elastic environment where the environment configures itself scaling in and out supporting any surge in traffic.

 Conclusion 

If you are deploying your applications in a Local Zone be they on EC2, EKS or ECS - and you need provide the traffic visibility control and security F5 has you covered for your application by delivering best in class traffic management, network and application security solutions in your Local Zone deployment supporting low latency and elastic deployments.