Traffic Mirroring – Load Balancing – ANS-C01 Study Guide

Traffic Mirroring

Network traffic captured in a VPC can be forwarded to a load balancer for analysis and troubleshooting. Mirroring is configured in the VPC and can send the traffic to a network load balancer listener to distribute the captured traffic to target groups associated with the NLB. Gateway load balancing is also supported, which is very useful for service providers as GLB does not modify the original source packets. The ELB web console allows you to create a mirror target in the load balancer you select and is on the Integrated Services tab. Target types can be either the network interface, network load balancer, or gateway load balancer.

VPC Endpoint Services (PrivateLink)

PrivateLink, or the endpoint service, allows outside accounts to share AWS resources with their customers. A network load balancer is created as the entry point in a VPC, and then the endpoint service is assigned to the NLB. Customers are then allowed access to your endpoint connection. PrivateLink allows the load balancer to receive traffic from the customer using the service and, with the use of target groups, routes the traffic on the backend hosts running applicators supporting the services offered. The load balancer console allows you to configure PrivateLink on the Integrated Services tab.

Web Application Firewall

The Web Application Firewall (WAF) acts as a front end to your application load balancer to protect web applications and application security breaches. Using the WAF, you set up access controls, rules, or conditions that define what is allowed and blocked before forwarding traffic to the application load balancer. This protects the services on the load balancer from heavy loads caused by attacks sent to the ALB.

It is important to note that the WAF will work with the layer 7 ALB but not with the network load balancer that has visibility only at layer 4. The WAF is integrated with the application load balancer, CloudFront, API Gateway, and AppSync at this time.

Route 53

When an ELB is created, a DNS A record is allocated to it in the format of name.region.elb.amazonaws.com.

When domain queries are performed to resolve the host domain name to the IP address of the ELB’s listening interface, Route 53 is used to direct domain traffic to the ELB load balancer.

Create an alias record in the Route 53 hosted zone that points to your load balancer. As you learned in Chapter 2, “Domain Name Services,” and Chapter 3, an alias record is a Route 53 extension to DNS. Aliases are similar to CNAME records, but they allow you to create an alias record both for the root domain, such as tipofthehat.com, and for subdomains, such as www.tipofthehat.com. CNAME records are supported only for subdomains and not the root domain.

Amazon Elastic Kubernetes Service

Kubernetes is a containerized microservice and compute service in AWS. For the Advanced Networking exam, we will focus on the networking aspects and how it integrates with AWS networking services. The application load balancer works with the Kubernetes Ingress controller at layer 7 of the OSI model.

 Elastic Kubernetes Service (EKS) has integrations with the application load balancer and the network load balancer; however, the classic load balancer services are no longer supported. An EKS cluster and the Ingress controller support ELB services, and the application load balancer controller is installed as a software add-on to the EKS service. For details on installing the controller, reference the user guide at https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html.

Your first step is to create a Kubernetes cluster and then deploy the load balancer in the cluster using at least two subnets in different availability zones. Both public and private subnets are supported. The load balancer Ingress controller then creates the application load balancer. The Kubernetes Ingress controller configures the application load balancer to route HTTP or HTTPS traffic to different pods within the cluster. The ALB can be deployed at the EC2 instance level or as Fargate IP targets.

The controller manages the ELBs for each Kubernetes cluster. When the controller is created, it will provision the ALB automatically for the Kubernetes Ingress controller. The network load balancer is created when the Kubernetes instance is LoadBalancer. Both IP and instance target types are supported.

The AWS load balancer controller is the new name for the AWS ALB Ingress controller, and you may see both terms to describe the same offering. It’s actually an open-source project available on GitHub, and you can find installation and operational instructions on the GitHub site. The GitHub site also provides examples to assist in your early deployments.