LBs

• Network Load Balancer automatically provides a static IP per Availability Zone (subnet) that can be used by applications as the front-end IP of the load balancer.
• Network Load Balancer also allows you the option to assign an Elastic IP per Availability Zone (subnet) thereby providing your own fixed IP.

  An Elastic IP address is a static IPv4 address
• Network Load Balancer (v2)

  Network load balancers (Layer 4) allow to:

  • Forward TCP & UDP traffic to your instances.

  • • Handle millions of request per seconds.

  • • Less latency ~100 ms (vs 400 ms for ALB).

  • NLB has one static IP per AZ, and supports assigning Elastic IP (helpful for whitelisting specific IP).

  • NLB are used for extreme performance,TCP or UDP traffic.

  • Not included in the AWS free tier.

  
• Network Load Balancer – Target Groups

  • EC2 instances.

  • IP Addresses – must be private IPs.

  • Application Load Balancer.

  • Health Checks support the TCP, HTTP and HTTPS Protocols.

  
• A valid combination is to have an NLB in front of an ALB. Why?

  NLB: get fixed IP addresses. ALB: can get all the rules around handling HTTP(S) traffic.
• NLB – Client IP Preservation.

  
  

  • Client IP addresses are forwarded to NLB targets.

  • When disabled, the private IP address of the NLB becomes the client IP address for all incoming traffic.

  
  

  Default Settings:

  
  

  • Targets by instance ID / ECS Tasks: Enabled.

  • Targets by IP address TCP & TLS: Disabled (default).

  • Targets by IP address UDP & TCP_UDP: Enabled (default).

  
  

  Note: Can’t be disabled for both targets by instance ID and by IP address (UDP & TCP_UDP)

  
• Network Load Balancer – Security Groups

  
  

  • Network Load Balancers can have associated Security Groups.

  • Target’s Security Groups can have an inbound security group rule that allows traffic from the NLB to flow securely.

  
• Network Load Balancer – Network ACL

  INBOUND

  Row1: Client and Internet traffic - we have the client's IP as a source on the listener ports.

  Row2: Health Check traffic - anything on the VPC CIDR on ephemeral port, so a wide port range should be allowed.

  OUTBOUND - to allow responses to the client and the internet.

  Row3: the client IP as a listener.

  Row4: to allow a health check traffic - health check port.

  Row5: to allow a health check traffic - a random port.

  -----------

  Ephemeral = short lived (temporary port).

  ACL = Access Control List.

  NACL = Network ACL.

  
• Network Load Balancer – Network ACL

  Good to specify that network ACLs also must be properly updated to take into account the client IP preservation.

  
• Network Load Balancer – Network ACL

  
  

  Target Subnet NACL

  
  

  INBOUND

  
  

  Row1: Client traffic - allowing client IP traffic from the internet*.

  Row2: Health Check traffic - allowing the health check protocol.

  
  

  OUTBOUND - on the way back, again:

  
  

  Row3: the client IP as a listener - you want to allow responses back to the client. The target traffic is gonna go to the source IP that you received from the client IP preservation.

  
  

  * If you have client IP preservation, you do need to allow the client IP.

  
• Network Load Balancer –Troubleshooting

  
  

  RegisteredTarget is NOT In Service

  
  

  • Health check can be failing

  • Target’s Security Group does not allow traffic on health check port/protocol from the NLB’s Security Group

  • Target’s Subnet NACL does not allow traffic from the NLB
• Network Load Balancer –Troubleshooting

  
  

  Requests are NOT Routed To Targets

  
  

  • Target’s SG does not allow traffic from the NLB’s SG.

  • Target’s Subnet NACL does not allow traffic (see before).

  • Targets are in an AZ that is not enabled.

  • EC2 instances is in a peered VPC*.

  • • Then you must register EC2 instances by IP addresses, not by Instance ID.

  
  

  *A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IP addresses. Instances in either VPC can communicate with each other as if they are within the same network.
• Sticky Sessions (Session Affinity)

  
  

  This works for*:

  
  

  1. Classic LB

  2. ALB

  3. NLB

  
  

  • The same client is always redirected to the same instance behind a load balancer.

  • For both CLB & ALB, the “cookie” used for stickiness has an expiration date you control.

  • NLB works without Cookies.

  • Use case: make sure the user doesn’t lose his session data.

  • Enabling stickiness may bring imbalance to the load over the backend EC2 instances.

  
  

  *Important to remember.

  
• Sticky Sessions – Cookie Names

  
  

  Application-based Cookies

  
  

  • Custom cookie

  • • Generated by the target (the application itself).

  • • Can include any custom attributes required by the application

  • • Cookie name must be specified individually for each target group

  • • Don’t use AWS(ALB), AWS(ALB)APP, or AWS(ALB)TG* - reserved for use by the ELB.

  
  

  • Application cookie

  • • Generated by the LB

  • • Cookie name is AWS(ALB)APP

  
  

  Duration-based Cookies

  • Cookie generated by the LB

  • Cookie name is AWS(ALB) for ALB, AWS(ELB) for CLB

  
  

  *Target Group
• SSL/TLS - Basics

  
  

  • An SSL Cert allows traffic between your clients and your LB to be encrypted in transit (in-flight encryption).

  • SSL = Secure Socket Layer, used to encrypt connections.

  • TLS = Transport Layer Security (newer version).

  • Nowadays, TLS certificates are mainly used, but people still refer as SSL.

  • Public SSL certs are issued by Certificate Authorities (CA) - Symantec, GoDaddy, GlobalSign, etc.

  • SSL certss have an expiration date (you set) and must be renewed.

  
  

  Using this public SSL cert attached to our LB, we're able to encrypt the connection between the clients and the LB.
• Elastic LB – SSL Certificates

  
  

  • The LB uses an X.509 cert (SSL/TLS server cert).

  • You can manage certs using ACM (AWS Certificate Manager).

  • You can create upload your own certs alternatively.

  • HTTPS listener.

  
  

  * Internally, your LB does something called SSL certificate termination. And in the BE, it can talk to your EC2 instance using HTTP, so not encrypted, but the traffic goes over your VPC, which is private traffic network. And that is somewhat secure.

  
• Elastic LB – SSL Certificates

  
  

  HTTPS listener:

  
  

  • You must specify a default cert.

  • You can add an optional list of certs to support multiple domains.

  • Clients can use SNI (Server Name Indication) to specify the hostname they reach .

  • Ability to specify a Security Policy (for compliance, features, compatibility or security) to support older versions of SSL / TLS (legacy clients).
• SSL – Server Name Indication (SNI)

  
  

  • SNI solves the problem of loading multiple SSL certificates onto one web server (to serve multiple websites).

  • It’s a “newer” protocol, and requires the client to indicate the hostname of the target hostname in the initial SSL handshake.

  • The server will then find the correct certificate, or return the default one.

  
  

  • Only works for ALB & NLB.

  
• Elastic Load Balancers – SSL Certificates

  
  

  Classic Load Balancer (v1)

  • Supports only one SSL certificate

  • Must use multiple CLB for multiple hostnames with multiple SSL certificates

  
  

  Application Load Balancer (v2)

  • Supports multiple listeners with multiple SSL certificates

  • Uses Server Name Indication (SNI) to make it work

  
  

  Network Load Balancer (v2)

  • Same as ALB
• What are the three different SSL certificates for 'Elastic' LBs?

  Classic Load Balancer, Application Load Balancer , Network Load Balancer
• HTTPS/SSL Listener – Security Policy.

  
  

  Setting up a security policy for your HTTPS or your SSL listener.

  The Security Policy is:

  
  

  • A combination of SSL protocols, SSL ciphers, and Server Order Preference option supported during SSL negotiations.

  • Predefined Security Policies (e.g., ELBSecurityPolicy-2016-08).

  • For ALB and NLB (FE: can use following, BE: always above).

  
  

  a) Use ELBSecurityPolicy-TLS policies.

  b) Use ELBSecurityPolicy-FS policies, if you require Forward Secrecy.
• Predefined Security Policies for ELB HTTPS/SSL Listeners

  For ALB and NLB

  
  

  • FE connections, you can use a predefined Security Policy

  • BE connections, ELBSecurityPolicy-2016-08 Security Policy is always used.

  
  

  
  

  Use ELBSecurityPolicy-TLS policies

  
  

  • To meet compliance and security standards that require certain TLS protocol version.

  • To support older versions of SSL/TLS (legacy clients)

  
  

  
  

  Use ELBSecurityPolicy-FS policies, if you require Forward Secrecy

  
  

  • Provides additional safeguards against the eavesdropping of encrypted data

  • Using a unique random session key
• NLB – SSL/TLS & HTTPS

  
  

  If a certificate has been attached to NLB, TLS termination enabled.

  
  

  • NLB uses a Server Cert to terminate and decrypt the FE connections before sending them to the targets.

  • To create a TLS listener, you must attach at least one Server Cert from ACM on NLB.

  • If Client IP Preservation Enabled: both source IP and port is presented to your BE servers, even when TLS is terminated at the NLB.

  • NLBs do not support TLS re- negotiation or mutual TLS authentication (mTLS)*

  
  

  * it has to be done directly by the client with the EC2 instances and not by the NLB.