Zero Trust for AWS NLBs: Why It Matters and How to Do It

Introduction to AWS Network Load Balancer

AWS has several critical services that drive the internet. If you have ever built any application on top of AWS and need a high throughput or volume of traffic, the chances are that you’ve leaned on an AWS Network Load Balancer at some point in the discussion. AWS NLB is nothing but a Layer 4 load balancer, and consistency helps with low-latency forwarding of massive amounts of TCP, UDP, and even TLS traffic. NLBs, being operational at Layer 4 of the OSI model, support a host of features. You get features like static IPs, support for long-lived connections out of the box, and can be configured to our requirements. 

In my projects, I’ve used NLBs for use cases ranging from being the front end for low-latency database requests to hosting an entire backend of an application. NLB helps in all these use cases by giving us a consistent latency, and it holds up its end every time. There are alternatives for NLBs like the AWS Application Load Balancers, but they operate at a higher level of the OSI model and are not always the choice for developers looking for a high-throughput, no-nonsense load balancer.

Introduction to Zero Trust Architecture (ZTA)

Zero trust is a concept that has been around for a while, and the original term was coined back in 2010. Given the growth in conversations about moving applications to the cloud, zero trust has been thrust into the forefront of conversations. In a traditional sense, there is an assumption that when a device or user is inside your network, it is considered safe. But, in a cloud-based network, this doesn’t really hold up anymore.

Zero trust comes with a concept that you cannot trust anything, and you need to verify everything. Whether it’s a person, device, or another service, it has to prove that it belongs. It extends the concept of least privilege, stressing the need to validate identity at every step and never let your guard down.

Why Zero Trust Architecture Matters for AWS Network Load Balancers

In an AWS architecture, NLBs are usually the first line of interaction with the user, sitting right at the edge. It can take traffic from the internet, other services, or both. This is the reason NLBs are a prime spot for security enforcement. Let’s consider why NLBs and zero trust make sense:

• They’re the gatekeepers: Taking an analogy from your personal home, NLBs act as a front door. If your door is unlocked, you have the possibility of letting strangers wander into your home.
• Layer 4 simplicity: Unlike an ALB, NLB doesn’t have visibility into HTTP headers or cookies. This simplicity is why NLBs are fast, but also need extra effort to lock in security. Zero trust helps you lock things down with TLS, identity-aware proxies, and traffic filtering.
• They serve the heavy hitters: NLBs are often used by organizations and applications to front latency-sensitive apps like financial APIs, gaming, or streaming services.  This calls for the need to have security at NLB without sacrificing performance. Zero trust gives you a blueprint for that.
• The perimeter is blurry: More often than not, NLBs aren’t directly public-facing; rather, they are the backend for stuff like PrivateLink and multi-account setups. Traffic in these cases could be coming from anywhere, and we cannot classify these applications as internal just because they are coming in from internal AWS services. ZTA asks you to treat every such connection with suspicion.

Core Zero Trust Principles Applied to NLBs

Now that we know what zero trust is and what the AWS NLB use case is, let’s actually put zero trust into action with the NLBs. This is what it looks like in practice:

Never Trust, Always Verify

NLBs don’t have the capabilities to look deep into packets, but rather just the headers. However, NLBs can still enforce TLS with a valid certificate. If you need further security, we can even insert a service like OAuth that can help authenticate users and services. More often than not, we will need every TCP connection to prove its identity before anything moves forward.

Least Privilege Access

A common issue we all have during building up network is opening things up to a big CIDR block as it’s very convenient. Although convenient, it goes against the concept of zero trust. It’s better to have control over this and lock it down better. Some of the ways we can achieve this are by using tightly scoped security groups, IAM policies, and target access controls. This way, we can only let traffic that truly needs access get through.

Micro-Segmentation

A big monolithic NLB is always a problem in terms of security. It’s good to split services across different NLBs and VPCs. This helps mitigate compromise in a single entity. A single NLB being compromised doesn’t necessarily mean your entire network path is compromised. This way, we can ensure the blast radius is small.

Continuous Monitoring

An important use case for NLB is monitoring. AWS supports VPC flow logs extensively, and it also incorporates traffic involving NLBs. In addition to VPC flow logs, NLB access logs are an important auditing tool as well. AWS CloudWatch is by far one of the best log visualization services out there, and we can use that to monitor some of the publicly available monitors that NLB vends out and add monitoring to those accordingly.

Public vs. Private NLBs: Same Principles, Different Playbooks

Whether your NLB is public-facing or internal-only, zero trust applies to both. It’s just that you will implement them a bit differently.

• Public NLBs: These provide public endpoints, and anyone can access them. A common way to lock public NLBs is to use TLS. We can also add CloudFront or a third-party edge provider, all while keeping IP filtering and aggressive throttling to avoid DDOS attacks.
• Private NLBs: These don’t have a public-facing endpoint and are often used along with other AWS networking. For this kind of NLB, it’s preferable to use PrivateLink in the network infrastructure. We need to make sure the IAM permissions are restrictive and use CloudWatch and logs to monitor everything. We have to treat even internal traffic like it might be hostile, because sometimes, it is.

Implementation Steps for Zero Trust With AWS NLB

Here’s a playbook to bring zero trust to life around your NLBs:

• Start with private subnets: Make sure the NLBs are moving into private subnets where possible. Use security groups for further restrictions on who can even see them.
• TLS termination: A secure communication line is vital in a zero-trust environment. Consider using TLS for an NLB and terminating it at the NLB using AWS Certificate Manager.
• Layer in auth: In many use cases, the traffic will be from another AWS Service. For such service-to-service calls, always use IAM. For user-facing use cases, put something like Cognito, OAuth, or an API Gateway in front.
• Monitor everything: AWS prides itself on its monitoring capability. Use NLB access logs, VPC flow logs, CloudWatch metrics, and make sure these logs and metrics land in a place where owners can validate. Whether it’s AWS Security Hub or 3rd party services from Splunk, Datadog, the key is to have centralized visibility.
• Use PrivateLink: From a security standpoint, if the communications are between AWS services or VPCs, PrivateLink helps keep the traffic off the public internet, and this will let you enforce strict access controls.

Advanced NLB Security Configurations

If you want more advanced protection on your NLBs, there are other considerations to look at:

• Client IP preservation: NLBs can keep the original source IP if needed. When it comes to monitoring, it is an added benefit as you can get more details from the client IP, including geolocation, and enforce IP-based access control.
• DDoS protection: AWS Shield Standard is available for you, but NLBs are handling critical workloads; look into Shield Advanced. If your use case needs application-layer protections, add CloudFront + WAF in front of the NLB.
• Cross-zone consistency: AWS allows you to have cross-zone NLBs, and if you are using cross-zone enabled NLBs, make sure your security settings, including groups, logs, and IAM roles, are consistent in all the available zones.
• PrivateLink endpoint controls: When exposing services through PrivateLink, unless the use case doesn’t let you do it, have manual connection approvals.
• Cryptographic hygiene: Enforce newer TLS ciphers and use ECDSA certs where you can. It’s faster and more secure.

Final Thoughts

Here’s the final parting thought: Zero trust isn’t just a feature you toggle on, but rather it’s a way of thinking or a mindset. When you apply this mindset to an AWS NLB setup, you can go from routing packets to actually securing it in a real-world use case and meaningful ways.

AWS gives you the building blocks for zero trust, like static IPs, TLS, PrivateLink, IAM, and logs. It’s up to you to stitch them together. By ensuring zero trust practices are followed for an NLB, you make it not just fast, scalable, and reliable, but also smart and secure. And in today’s threat landscape, that’s what matters most.