Subnet Configuration and Optimization

When deploying elastic and scalable solutions in the AWS cloud, you need to ensure that your VPC networks are properly configured to allow for that behavior. AWS services such as EC2 and Elastic Load Balancing (ELB) enable solutions to automatically horizontally scale dynamically based on capacity needs. This short section will detail some considerations that should be made when deploying subnets to support ELB and EC2 Auto Scaling.

Note

There will be a later chapter that dives deeper into Elastic Load Balancing and the details that come with ELB configuration.

Subnet Considerations for ELB

When deploying various types of elastic load balancers in AWS, the ELB will need to be mapped to specific subnets within the VPC that it belongs to. When this mapping is done, the ELB will have an ENI deployed into each of those subnets. These ENIs are fully managed by the ELB and cannot be moved to other resources such as an EC2 instance. However, it is important to consider that these ENIs will need to consume IP addresses out of each of the subnets as well.

This sort of mapping is common when using an ELB as the frontend connection of a website. The ELB becomes the internet-facing website DNS entry that customers connect to, and when the connections come into the ELB, the routing rules of the load balancer determine into which subnet the traffic is delivered. Delivering traffic to these subnets requires the ENI deployment.

This may seem like a small thing to consider when you need to only account for one IP address in each subnet for the ELB. While only a single IP address, it is important to consider this when deploying your subnets within a VPC, especially if multiple ELBs may reside there. If you are using something small such as /28 for your subnets, there are only 11 usable addresses (14 minus the 3 AWS addresses) to assign to resources. The addresses must be used sparingly.

Refer to Figure 1.11 for a simplistic view of multiple application load balancers mapped to the same subnets and consuming multiple addresses:

Figure 1.11: ALB with ENIs

ALBs are usually deployed in such a fashion for resiliency and redundancy in case an AZ is impacted by a failure.

Subnet Considerations for Auto-Scaling

When configuring EC2 Auto Scaling, you need to make similar considerations for the number of IP addresses that will be consumed out of your VPC subnets. Since EC2 Auto Scaling allows you to set minimum and maximum desired capacity units for EC2 instances, you will need to ensure your subnets have adequate IP addresses, not just for normal operation, but also to account for failure.

Take the following example. Trailcats has an Auto Scaling group (ASG) spread across three AZs within a VPC. During peak times, the maximum capacity on the ASG is configured for nine instances, so they are spread evenly across the AZs. If there is an AZ failure, then those instances will need to be redeployed in other subnets. In this scenario, all VPC subnets need to have enough IP addresses to account for all the EC2 instances that the ASG could deploy into the subnet during an AZ failure. Refer to Figure 1.12 to see an example of how the ASG could react to an AZ failure:

Figure 1.12: Subnets with auto-scaling configuration

Auto-scaling is both based on demand and resiliency; in the preceding figure, auto-scaling is being used for resiliency to ensure adequate resources are available.