Hi there 👋
How can I help you today?
AWS Outposts are physical racks that are connected to the AWS global network that provide AWS infrastructure and services to almost any type of datacenter, co-location space, or on-premises facility. You have access to all of the AWS services that are available in your region, including Application Load Balancer (ALB), and they are all run locally on the Outpost. Nevertheless, setting up an Application Load Balancer for Outposts differs slightly from doing so for an AWS Region. An overview of configuring ALB for Outposts to scale and balance resources is given in this post.
Customers with very low latency use cases are particularly interested in outposts, and as a result, load balancing capability must be brought on-premises. The requirement for low latency connectivity to web application servers is one typical use case. These services can be offered on-site by outposts. With the ALB, you can load balance HTTP and HTTPS streams from an on-premises, scalable, and resilient infrastructure with minimal latency.
We assume that you are familiar with Outposts, local gateway (LGW), customer-owned IP (CoIP) and since internet facing public ALB on Outpost only support CoIP mode and it is used to load balance services like ECS, EC2, EKS on Outpost.
A game monetization model refers to the strategy that game developers use to gain revenue from their games. These models are designed in such a way that developers earn money from their games while providing players with enjoyable and engaging experiences. Gamers today expect more than just a one-time purchase. They seek ongoing updates, new features, and a continuous stream of engaging content. Effective monetization models enable developers to meet these expectations, fostering player satisfaction and loyalty. Revenue generated through game monetization encourages the innovation in the industry also it motivates developers to invest in research and development, ultimately driving the evolution of gaming as an art form.
When deploying an ALB, there are a few important distinctions within AWS Outposts that need to be taken into account. These can be divided into six categories:
Resources: In Outpost ALB need to use compute resources (EC2) and it requires atleast two instances for resilience and can be deployed on following instance type c5,m5,r5 etc. In the intials it only consumes two IP address from the Outpost subnet and it requires two Elastic IP address from the CoIP range.
Scaling: To scale, the ALB needs two more instances of the next larger size than its present resources. These have to be made available in addition to the current instances. Two more Co-IP addresses from the Elastic IP address pool are also required by the ALB. All are used for a while after scaling is finished and the original resources are released.
For instance, in order for the ALB to scale itself up, c5.xlarge instances are required if it originally deploys on c5.large instances. This scaling keeps up until c5.4xlarge, after which it can't scale up any more and instead scales out. It's crucial to remember that when it scales, it will always use the instance type family that was initially used. Resources are always selected by ALB in a particular order. In the event that no c5 instances are available, other supported instance families are used after c5 instances. If you have c5 instances available, you cannot force the ALB to use m5. While sizing the Outpost, keep this in mind.
Failure: The ALB fails if it attempts to execute a scaling event and there are insufficient resources available inside the Outpost. Using the Personal Health Dashboard, the ALB states that it is unable to scale and continues load balancing with its available resources.
Target: ALB forwards traffic to IP address of On-premises resources and also the the Outpost resources using instance names.
DNS resolution: When we use public facing external ALB for Outpost, DNS resolution provided the assigned CoIP address for the ALB which may change during the scaling or failure, so it is important to use the ALB name rather than specific IP address.
When determining the size of a CoIP pool, ALB must also be taken into account. These pools can have any CIDR range (around 60–65,000 useable addresses) between /26 and /16. In the event that ALB usage would be significant, each deployed ALB must have access to a minimum of four Co-IP addresses.
It is important to map the target group with instance of subnet deployed in Outpost.
Configure an application load balancer after the target group has been created. The method for doing this is the same as how the configuration in Region is done. The ALB has to be of the "internet-facing" type in order to be accessed from on-premises. You can then choose from an IP pool that belongs to the customer. Only subnets inside the AWS Outposts connected to the local gateway (LGW) can have the ALB deployed after a Co-IP pool has been assigned.
It should be noted that while the type of ALB selected is ‘internet-facing’, it doesn’t actually have any external public connection. This is just a way of being able to select the pool of Elastic IP addresses to use. In the case of AWS Outposts, this is the Co-IP pool, which is most likely a private range.
From an on-premises Linux server, We can now check to see what addresses it get resolved for the ALB. We send the request using the DNS name from the ALB configuration, and we get the results.
If weI try to access the web server from that address, we get a response from one of the backend NGINX hosted behind the instances.
As we can see, ALB on AWS Outposts follows the same design and performs the same functions as ALB in Region, and as new features are added to ALB on AWS Outposts, they are automatically made available. The ALB's primary goal is to provide a durable, scalable, and low-latency link between on-premises devices and AWS Outposts, as well as to eliminate the requirement for load balancing outside of the AWS environment. As a result, target groups can be more tightly integrated while meeting throughput and performance requirements.
