AWS Elastic Load Balancing Security

One of the overwhelming benefits of hosting your applications in the cloud is the ability to scale exponentially as the demands on your services increase. Amazon Web Service’s Elastic Load Balancing (ELB) service is integral to a scalable architecture. This article will cover the basics of ELBs, including the different types and advantages.

We’ll also dive deep into securing your ELB resources properly and protecting the applications, services, and other resources behind them. In addition, we’ll talk about the type of threats an ELB might face and some best practices and strategies you can use to protect your ELBs.

ELBs and How They Work

Before we get into how ELBs work, you should be familiar with two terms: listeners and target groups. A listener is a process that listens for connect requests to your load balancer. You configure a listener with a protocol and a port. ELB supports the TCP, TLS, UDP, or TCP_UTP protocols. Ports can be between 1 and 65, 535 (such as port 80 for web traffic and port 443 for encrypted traffic).

A target group is a destination for traffic that comes through the ELB. ELBs provide a single entry point for traffic coming into your AWS account. The ELB routes that traffic across multiple destinations. The destination might be a cluster of EC2 instances in an Autoscaling Group (ASG), and some also support routing to AWS Lambda functions and containerized applications. ELBs maintain a list of healthy targets by performing health checks, adding new resources, and removing expired resources as needed. ELBs can manage target groups in multiple Availability Zones (AZs), which means that if resources in an AZ are unavailable, the ELB automatically routes requests to available resources in another AZ.

Different types of ELBs can route traffic based on various elements within the HTTP stack. Next, we’ll discuss the different kinds of ELBs, including their performance and dynamic routing advantages. The ELB service can be configured with an SSL certificate using the AWS Certificate Manager (ACM) to accept and validate HTTPS requests from your clients.

Different ELB Types and Their Advantages

AWS released its Classic Load Balancer as one of the early services available on its cloud platform. While the Classic ELB covers most use cases, they have since released more specialized load balancer types that offer distinct routing options and levels of performance. The routing options in these ELBs work with different layers in the Open Systems Interconnection model, or OSI.

We have listed each type of load balancer below, along with a brief description of the benefits and advantages of each one. If you need more information about a specific kind or would like to learn more about their capabilities, AWS has documented the full feature set in a product comparison table.

Classic Load Balancers (ELB)

The Classic Load Balancer is the simplest version of ELB available in AWS. It provides clients with a single entry point and balances the incoming requests across EC2 instances. The ELB performs regular health checks on each of the instances in the target group and ensures that it only routes requests to healthy and responsive instances.

The Classic ELB supports TCP and SSL requests, and it also supports sticky session, which uses an application-generated cookie to route requests from the same client to the same target instance. This ELB is simple, battle-tested, and reliable. Unfortunately, it is limited in the scope of the types of routing and only supports routing the EC2 instances.

Application Load Balancers (ALB)

Application Load Balancers, or ALBs, are especially useful in cases where you want to route requests based on the contents in layer 7 of the OSI, or the application layer. You do this by adding listeners to the ALB with a rule or set of rules. When a request matches these rules, the listener routes the request to the associated target group.

An ALB allows you to route requests based on the following:

• Parameters in the path of the URL of the request
• HTTP Headers such as:
  • The host
  • Query parameters
  • Source IP address

ALBs provide support for routing to Lambda functions as targets and containerized applications running within the Amazon Elastic Container Service, or Amazon ECS. The ALB manages the health checks for each target group independently, providing improved resiliency. You will also have access to more detailed logs than are available with the original Classic ELB.

An additional advantage to using an ALB is that you can configure the listeners to authenticate users with an OpenID Connect (OIDC) Identity Provider (IdP), such as Amazon Cognito. This approach improves security at the load balancer and offloads the burden of authentication from the application.

Network Load Balancer (NLB)

If your application needs a highly performant load balancer that can handle millions of requests per second, you should consider the Network Load Balancer (NLB). NLBs operate at layer 4 of the OSI, or the transport layer.

The speed and scalability of the NLB are the primary reasons to select it; however, some of the features that are available in other ELB types (such as SSL termination and parameter-based routing) aren’t available as part of the NLB configuration.

Gateway Load Balancer

The final type of ELB available from AWS (at least for now) is the Gateway Load Balancer. This load balancer operates at layer 3 of the OSI, or the network layer. The Gateway Load Balancer is also an excellent choice if you need to support secure communication across VPC boundaries and can manage virtual network appliances.

The Gateway Load Balancer supports use cases like adding additional network appliances to your load balancing resources, such as firewalls, deep packet inspection, and intrusion detection and prevention. You can add these virtual appliances as target groups to the load balancer, and you configure them with a route table entry in the load balancer.

Understanding the Shared Responsibility Model

Regarding security, AWS (like most cloud platforms) operates on a shared responsibility model. The best way to describe this is that AWS is responsible for the protection of the cloud, and the customer is responsible for security in the cloud. This model means that AWS will protect the cloud infrastructure, including the hardware, software, networking, and facilities that house the infrastructure.

AWS offers its users a vast array of capabilities and configuration options. Users of the different AWS services are responsible for ensuring that they configure those services correctly and set up appropriate security measures to protect those resources and the data they transfer, process, and store.

ELBs, like any other cloud service, have unique security challenges, and AWS provides the tools and configurations to mitigate these risks. Let’s explore what risks an ELB might face, and with that understanding, we can address how best to manage them.

ELB Security Risks

When we discuss application security, our primary concern is the attack surface. The attack surface is the part of your application that is exposed to the internet – and the part that a malicious actor can access. If a hacker can successfully compromise this entry point, they can gain unauthorized access to your application and your data. Using an ELB allows you to secure and protect the resources hosting your application behind it. This means that the primary attack surface for your application is the ELB.

Best Practices for ELB Security

Before we discuss ELB security directly, ensuring that your AWS account is properly secured is essential. AWS Identity and Access Management (IAM) is central to the security of your account. It doesn’t matter how much security you apply to the resources in your account. If someone can gain access to IAM, all of that is for naught. Ensure that you have tightly managed access controls to your account, including implementing the principle of least privilege and requiring MFA authentication on every account.

When you add listeners to a load balancer, ensure that they support and require encrypted communication between your clients and the load balancer. Depending on the type of load balancer you choose, it’s best to use either a TLS or an HTTPS listener to enforce this.

Within your Virtual Private Cloud (VPC), you can create internal and external ELBs. You should only configure a public IP address on those ELBs required to accept incoming requests from outside the VPC. Suppose you are using an ALB to allow ingress from outside the VPC. In that case, you can enable authentication on the listeners to validate all incoming requests and offload the authentication burden from the targeted application.

As an additional layer of protection, you might consider setting up a Web Application Firewall, such as AWS WAF, to restrict incoming requests from a defined range of IP addresses, geo-specific locations, and other criteria. You can also create a network Access Control List (ACL) that further defines who and what can access your VPC.

Using Security Groups to Secure Your ELB and Applications

Within your VPC, you can create security groups to define access to AWS resources. As an additional layer of security, AWS denies all access to resources unless explicitly allowed by an access rule in the security group. Security group rules require a combination of protocol and port number(s) and apply to either inbound or outbound traffic from the resources to which it is attached. As the responsible party for configuring a security group, you can configure the rules as broad or as narrow as you would like. A best practice is to limit the port and IP address ranges as much as possible.

The target groups of your ELB should have a security group applied that limits incoming requests to the ELB, ensuring that all incoming requests come through the load balancer. Additionally, you can add a security group to the load balancer to limit which clients can send requests.

Next Steps

AWS Elastic Load Balancers are a critical architectural component that allows your applications to scale seamlessly and as securely as possible. Your use case will determine which load balancer type best meets your requirements, and you are responsible for configuring the security and access rules to maintain a secure and performant environment. The Amazon documentation on the different load balancing solutions is kept current with the latest user guides and recommendations. As you consider the various options, pay close attention to the benefits of each, and design a scalable solution that meets the needs of your consumers while simultaneously maintaining the security of your applications.