AWS Network Load Balancer – NLB

AWS Network Load Balancer – NLB

  • Network Load Balancer operates at the connection level (Layer 4), routing connections to targets – EC2 instances, containers and IP addresses based on IP protocol data.
  • Network Load Balancer is suited for load balancing of TCP traffic
  • Network Load Balancer is capable of handling millions of requests per second while maintaining ultra-low latencies.
  • Network Load Balancer is optimized to handle sudden and volatile traffic patterns while using a single static IP address per Availability Zone.
  • Network Load Balancer also supports TLS termination, preserves the source IP of the clients, and provides stable IP support and Zonal isolation.
  • NLB supports long-running connections that are very useful for WebSocket type applications.
  • NLB is integrated with other AWS services such as Auto Scaling, EC2 Container Service (ECS), and CloudFormation.
  • NLB support connections from clients over VPC peering, AWS managed VPN, and third-party VPN solutions.
  • For TCP traffic,
    • the load balancer selects a target using a flow hash algorithm based on the protocol, source IP address, source port, destination IP address, destination port, and TCP sequence number.
    • TCP connections from a client have different source ports and sequence numbers, and can be routed to different targets.
    • Each individual TCP connection is routed to a single target for the life of the connection.
  • For UDP traffic,
    • the load balancer selects a target using a flow hash algorithm based on the protocol, source IP address, source port, destination IP address, and destination port.
    • A UDP flow has the same source and destination, so it is consistently routed to a single target throughout its lifetime.
    • Different UDP flows have different source IP addresses and ports, so they can be routed to different targets.
  • back-end server authentication is not supported
  • session stickiness is not support

Refer Blog Post @ Classic Load Balancer vs Application Load Balancer vs Network Load Balancer

Network Load Balancer Features

Connection-based Load Balancing

  • Allows load balancing of  TCP traffic, routing connections to targets – EC2 instances, microservices and containers, and IP addresses.

High Availability

  • is highly available.
  • accepts incoming traffic from clients and distributes this traffic across the targets within the same Availability Zone.
  • monitors the health of its registered targets and routes the traffic only to healthy targets
  • if a health check fails and an unhealthy target is detected, it stops routing traffic to that target and reroutes traffic to remaining healthy targets.
  • if configured with multiple AZs and if all the targets in a single AZ fail, it routes traffic to healthy targets in the other AZs

High Throughput

  • is designed to handle traffic as it grows and can load balance millions of requests/sec.
  • can also handle sudden volatile traffic patterns.

Low Latency

  • offers extremely low latencies for latency-sensitive applications.

Cross Zone Load Balancing

  • enable cross-zone loading balancing only after creating the NLB
  • is disabled, by default, and charges apply for inter-az traffic.

Load Balancing using IP addresses as Targets

  • allows load balancing of any application hosted in AWS or on-premises using IP addresses of the application backends as targets.
  • allows load balancing to an application backend hosted on any IP address and any interface on an instance.
  • ability to load balance across AWS and on-premises resources helps migrate-to-cloud, burst-to-cloud or failover-to-cloud
  • applications hosted in on-premises locations can be used as targets over a Direct Connect connection and EC2-Classic (using ClassicLink).

Preserve source IP address

  • preserves client side source IP allowing the back-end to see client IP address
  • Target groups can be created with target type as instance ID or IP address.
    • If targets registered by instance ID, the source IP addresses of the clients are preserved and provided to the applications.
    • If register targets registered by IP address, the source IP addresses are the private IP addresses of the load balancer nodes.

Static IP support

  • automatically provides a static IP per Availability Zone (subnet) that can be used by applications as the front-end IP of the load balancer.
  • Elastic Load Balancing creates a network interface for each enabled Availability Zone. Each load balancer node in the AZ uses this network interface to get a static IP address.
  • Internet-facing load balancer can optionally associate one Elastic IP address per subnet.

Elastic IP support

  • an Elastic IP per Availability Zone (subnet) can also be assigned, optionally, thereby providing a fixed IP.

Health Checks

  • supports both network and application target health checks.
  • Network-level health check
    • is based on the overall response of the underlying target (instance or a container) to normal traffic.
    • target is marked unavailable if it is slow or unable to respond to new connection requests
  • Application-level health check
    • is based on a specific URL on a given target to test the application health deeper

DNS Fail-over

  • integrates with Route 53
  • Route 53 will direct traffic to load balancer nodes in other AZs, if there are no healthy targets with NLB or if the NLB itself is unhealthy
  • if NLB is unresponsive, Route 53 will remove the unavailable load balancer IP address from service and direct traffic to an alternate Network Load Balancer in another region.

Integration with AWS Services

  • is integrated with other AWS services such as Auto Scaling, EC2 Container Service (ECS), CloudFormation, CodeDeploy, and AWS Config.

Long-lived TCP Connections

  • supports long-lived TCP connections ideal for WebSocket type of applications

Central API Support

  • uses the same API as Application Load Balancer.
  • enables you to work with target groups, health checks, and load balance across multiple ports on the same EC2 instance to support containerized applications.

Robust Monitoring and Auditing

  • integrated with CloudWatch to report Network Load Balancer metrics.
  • CloudWatch provides metrics such as Active Flow count, Healthy Host Count, New Flow Count, Processed bytes, and more.
  • integrated with CloudTrail to track API calls to the NLB

Enhanced Logging

  • use the Flow Logs feature to record all requests sent to the load balancer.
  • Flow Logs capture information about the IP traffic going to and from network interfaces in the VPC
  • Flow log data is stored using CloudWatch Logs

Zonal Isolation

  • is designed for application architectures in a single zone.
  • can be enabled in a single AZ to support architectures that require zonal isolation
  • automatically fails-over to other healthy AZs, if something fails in a AZ
  • its recommended to configure the load balancer and targets in multiple AZs for achieving high availability

Advantages over Classic Load Balancer

  • Ability to handle volatile workloads and scale to millions of requests per second, without the need of pre-warming
  • Support for static IP/Elastic IP addresses for the load balancer
  • Support for registering targets by IP address, including targets outside the VPC (on-premises) for the load balancer.
  • Support for routing requests to multiple applications on a single EC2 instance. Single instance or IP address can be registered with the same target group using multiple ports.
  • Support for containerized applications. Using Dynamic port mapping, ECS can select an unused port when scheduling a task and register the task with a target group using this port.
  • Support for monitoring the health of each service independently, as health checks are defined at the target group level and many CloudWatch metrics are reported at the target group level. Attaching a target group to an Auto Scaling group enables scaling each service dynamically based on demand

Network Load Balancer Pricing

  • charged for each hour or partial hour that an NLB is running and the number of Load Balancer Capacity Units (LCU) used per hour.
  • An LCU is a new metric for determining NLB pricing
  • An LCU defines the maximum resource consumed in any one of the dimensions (new connections/flows, active connections/flows, bandwidth and rule evaluations) the Network Load Balancer processes your traffic.

[do_widget id=text-15]

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company wants to use load balancer for their application. However, the company wants to forward the requests without any header modification. What service should the company use?
    1. Classic Load Balancer
    2. Network Load Balancer
    3. Application Load Balancer
    4. Use Route 53
  2. A company is hosting an application in AWS for third party access. The third party needs to whitelist the application based on the IP. Which AWS service can the company use in the whitelisting of the IP address?
    1. AWS Application Load Balancer
    2. AWS Classic Load balancer
    3. AWS Network Load Balancer
    4. AWS Route 53

References

AWS Documentation – ELB_Network_Load_Balancer

AWS Classic Load Balancer vs Application Load Balancer vs Network Load Balancer

AWS Classic Load Balancer vs Application Load Balancer vs Network Load Balancer

  • Elastic Load Balancing supports three types of load balancers:
    • Application Load Balancer,
    • Network Load Balancer and
    • Classic Load Balancers.
  • While there is some overlap in the features, AWS does not maintain feature parity between the different types of load balancers.

Content below lists down the feature comparison for all –

Usage Pattern

  • Classic Load Balancer
    • provides basic load balancing across multiple EC2 instances and operates at both the request level and connection level.
    • is intended for applications that were built within the EC2-Classic network.
    • is ideal for simple load balancing of traffic across multiple EC2 instances.
  • Application Load Balancer
    • is ideal for microservices or container-based architectures where there is a need to route traffic to multiple services or load balance across multiple ports on the same EC2 instance.
    • operates at the request level (layer 7), routing traffic to targets – EC2 instances, containers, IP addresses and Lambda functions based on the content of the request.
    • is ideal for advanced load balancing of HTTP and HTTPS traffic, and provides advanced request routing targeted at delivery of modern application architectures, including microservices and container-based applications.
    • simplifies and improves the security of the application, by ensuring that the latest SSL/TLS ciphers and protocols are used at all times.
  • Network Load Balancer
    • operates at the connection level (Layer 4), routing connections to targets – EC2 instances, microservices, and containers – within VPC based on IP protocol data.
    • is ideal for load balancing of both TCP and UDP traffic,
    • is capable of handling millions of requests per second while maintaining ultra-low latencies.
    • is optimized to handle sudden and volatile traffic patterns while using a single static IP address per AZ
    • is integrated with other popular AWS services such as Auto Scaling, ECS, CloudFormation and AWS Certificate Manager (ACM).
  • AWS recommends using Application Load Balancer for Layer 7 and Network Load Balancer for Layer 4 when using VPC.

AWS ELB Classic Load Balancer vs Application Load Balancer
Supported Protocols

  • Classic ELB operates at layer 4 and supports HTTP, HTTPS, TCP, SSL
  • ALB operates at layer 7 and supports HTTP, HTTPS, HTTP/2, WebSockets
  • NLB operates at the connection level (Layer 4)

Supported Platforms

  • Classic ELB supports both EC2-Classic and EC2-VPC
  • ALB and NLB supports only EC2-VPC

Connection Draining

  • Connection draining enables the load balancer to complete in-flight requests made to instances that are de-registering or unhealthy
  • All Load Balancer types support connection draining

Health Checks

  • All Load Balancer types support Health checks to determine if the instance is healthy or unhealthy
  • ALB provides health check improvements that allow detailed error codes from 200-399 to be configured

CloudWatch Metrics

  • All Load Balancer types integrate with CloudWatch to provide metrics, with ALB providing additional metrics

Load Balancing to multiple ports on the same instance

  • Only ALB & NLB supports Load Balancing to multiple ports on the same instance

Deletion Protection

  • Only ALB & NLB supports Deletion Protection, wherein a load balancer can’t be deleted if deletion protection is enabled

Idle Connection Timeout

  • Idle Connection Timeout helps specify a time period, which ELB uses to close the connection if no data has been sent or received by the time that the idle timeout period elapses
  • Both Classic ELB & ALB supports idle connection timeout
  • NLB does not support idle connection timeout

Cross-zone Load Balancing

  • Cross-zone Load Balancing help distribute incoming requests evenly across all instances in its enabled AZs. By default, Load Balancer will evenly distribute requests evenly across its enabled AZs, irrespective of the instances it hosts.
  • All Load Balancer types support Cross-zone load balancing, however for Classic it needs to be enabled while for ALB it is always enabled

Stick Sessions (Cookies)

  • Stick Sessions (Session Affinity) enables the load balancer to bind a user’s session to a specific instance, which ensures that all requests from the user during the session are sent to the same instance
  • Classic ELB & ALB supports sticky sessions to maintain session affinity
  • NLB does not support sticky sessions

Static IP and Elastic IP Address

  • NLB automatically provides a static IP per AZ (subnet) that can be used by applications as the front-end IP of the load balancer.
  • NLB also allows the option to assign an Elastic IP per AZ (subnet) thereby providing your own fixed IP.
  • Classic ELB and ALB does not support Static and Elastic IP address

Preserve source IP address

  • NLB preserves the client side source IP allowing the back-end to see the IP address of the client. This can then be used by applications for further processing.
  • Classic ELB and ALB do not preserve the client side source IP. It needs to be retrieved using X-Forward-Header or proxy protocol

WebSockets

  • Only ALB and NLB supports WebSockets

PrivateLink Support

  • Only NLB supports PrivateLink (TCP, TLS)

SSL Termination/Offloading

  • SSL Termination helps decrypt requests from clients before sending them to targets and hence reducing the load. SSL certificate must be installed on the load balancer.
  • All load balancers types support SSL Termination

Back-end Server Authentication

  • Back-end Server Authentication enables authentication of the instances. Load balancer communicates with an instance only if the public key that the instance presents to the load balancer matches a public key in the authentication policy for the load balancer.
  • Classic Load Balancer supports while Application Load Balancer does not support Back-end Server Authentication

Access Logs

  • Access logs capture detailed information about requests sent to the load balancer. Each log contains information such request  received time, client’s IP address, latencies, request paths, and server responses
  • All Load Balancer types provide access logs, with ALB providing additional attributes

Host-based Routing & Path-based Routing

  • Host-based routing use host conditions to define rules that forward requests to different target groups based on the host name in the host header. This enables ALB to support multiple domains using a single load balancer.
  • Path-based routing use path conditions to define rules that forward requests to different target groups based on the URL in the request. Each path condition has one path pattern. If the URL in a request matches the path pattern in a listener rule exactly, the request is routed using that rule.
  • Only ALB supports Host-based & Path-based routing.

[do_widget id=text-15]

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company wants to use load balancer for their application. However, the company wants to forward the requests without any header modification. What service should the company use?
    1. Classic Load Balancer
    2. Network Load Balancer
    3. Application Load Balancer
    4. Use Route 53
  2. A Solutions Architect is building an Amazon ECS-based web application that requires that headers are not modified when being forwarded to Amazon ECS. Which load balancer should the Architect use?
    1. Application Load Balancer
    2. Network Load Balancer
    3. A virtual load balancer appliance from AWS marketplace
    4. Classic Load Balancer
  3. An application tier currently hosts two web services on the same set of instances, listening on different ports. Which AWS service should a solutions architect use to route traffic to the service based on the incoming request?
    1. AWS Application Load Balancer
    2. Amazon CloudFront
    3. Amazon Route 53
    4. AWS Classic Load Balancer
  4. A Solutions Architect needs to deploy an HTTP/HTTPS service on Amazon EC2 instances with support for WebSockets using load balancers. How can the Architect meet these requirements?
    1. Configure a Network Load balancer.
    2. Configure an Application Load Balancer.
    3. Configure a Classic Load Balancer.
    4. Configure a Layer-4 Load Balancer.
  5. A company is hosting an application in AWS for third party access. The third party needs to whitelist the application based on the IP. Which AWS service can the company use in the whitelisting of the IP address?
    1. AWS Application Load Balancer
    2. AWS Classic Load balancer
    3. AWS Network Load Balancer
    4. AWS Route 53

AWS Certification – Compute Services – Cheat Sheet

EC2

  • provides scalable computing capacity
  • Features
    • Virtual computing environments, known as EC2 instances
    • Preconfigured templates for EC2 instances, known as Amazon Machine Images (AMIs), that package the bits needed for the server (including the operating system and additional software)
    • Various configurations of CPU, memory, storage, and networking capacity for your instances, known as Instance types
    • Secure login information for your instances using key pairs (public-private keys where private is kept by user)
    • Storage volumes for temporary data that’s deleted when you stop or terminate your instance, known as Instance store volumes
    • Persistent storage volumes for data using Elastic Block Store (EBS)
    • Multiple physical locations for your resources, such as instances and EBS volumes, known as Regions and Availability Zones
    • A firewall to specify the protocols, ports, and source IP ranges that can reach your instances using Security Groups
    • Static IP addresses, known as Elastic IP addresses
    • Metadata, known as tags, can be created and assigned to EC2 resources
    • Virtual networks that are logically isolated from the rest of the AWS cloud, and can optionally connect to on premises network, known as Virtual private clouds (VPCs)

Amazon Machine Image – AMI

    • template from which EC2 instances can be launched quickly
    • does NOT span across across regions, and needs to be copied
    • can be shared with other specific AWS accounts or made public

Instance Types

    • T for applications needing general usage
    • R for applications needing more RAM or Memory
    • C for applications needing more Compute
    • M for applications needing more Medium or Moderate performance on both Memory and CPU
    • I for applications needing more IOPS
    • for applications needing more GPU

Purchasing Option

    • On-Demand Instances
      • pay for instances and compute capacity that you use by the hour
      • no long-term commitments or up-front payments
    • Reserved Instances
      • provides lower hourly running costs by providing a billing discount
      • capacity reservation is applied to instances
      • suited if consistent, heavy, predictable usage
      • provides benefits with Consolidate Billing
      • can be modified to switch Availability Zones or the instance size within the same instance type, given the instance size footprint (Normalization factor) remains the same
      • pay for the entire term regardless of the usage, so if the question targets cost effective solution and answer mentions reserved instances are purchased & unused, it can be ignored
      • is not a physical instance that is launched, but rather a billing discount applied to the use of On-Demand Instances
    • Scheduled Reserved Instances
      • enable capacity reservations purchase that recur on a daily, weekly, or monthly basis, with a specified start time and duration, for a one-year term.
      • Charges are incurred for the time that the instances are scheduled, even if they are not used
      • good choice for workloads that do not run continuously, but do run on a regular schedule
    • Spot Instances
      • cost-effective choice but does NOT guarantee availability
      • applications flexible in the timing when they can run and also able to handle interruption by storing the state externally
      • provides a two minute warning if the instance is to be terminated to save any unsaved work
      • Spot blocks can also be launched with a required duration, which are not interrupted due to changes in the Spot price
      • Spot Fleet is a collection, or fleet, of Spot Instances, and optionally On-Demand Instances, which attempts to launch the number of Spot and On-Demand Instances to meet the specified target capacity
    • Dedicated Instances
      • is a tenancy option which enables instances to run in VPC on hardware that’s isolated, dedicated to a single customer
    • Dedicated Host
      • is a physical server with EC2 instance capacity fully dedicated to your use
    • Light, Medium, and Heavy Utilization Reserved Instances are no longer available for purchase and were part of the Previous Generation AWS EC2 purchasing model

Enhanced Networking

    • results in higher bandwidth, higher packet per second (PPS) performance, lower latency, consistency, scalability and lower jitter
    • supported using Single Root I/O Virtualization (SR-IOV) only on supported instance types
    • is supported only with an VPC (not EC2 Classic), HVM virtualization type and available by default on Amazon AMI but can be installed on other AMIs as well

Placement Group

    • Cluster Placement Group
      • provide low latency, High Performance Computing via 10Gbps network
      • is a logical grouping on instances within a Single AZ
      • don’t span availability zones, can span multiple subnets but subnets must be in the same AZ
      • can span across peered VPCs for the same Availability Zones
      • existing instances can’t be moved into an existing placement group
      • Existing instance can be moved to a placement group, or moved from one placement group to another, or removed from a placement group, given it is in the stopped state. 
      • for capacity errors, stop and start the instances in the placement group
      • use homogenous instance types which support enhanced networking and launch all the instances at once
    • Spread Placement Groups
      • is a group of instances that are each placed on distinct underlying hardware i.e. each instance on distinct rack across AZ
      • recommended for applications that have a small number of critical instances that should be kept separate from each other.
      • reduces the risk of simultaneous failures that might occur when instances share the same underlying hardware.
    • Partition Placement Groups
      • is a group of instances spread across partitions i.e. group of instances spread across racks across AZs
      • reduces the likelihood of correlated hardware failures for the application.
      • can be used to spread deployment of large distributed and replicated workloads, such as HDFS, HBase, and Cassandra, across distinct hardware

Elastic Load Balancer

    • Managed load balancing service and scales automatically
    • distributes incoming application traffic across multiple EC2 instances
    • is distributed system that is fault tolerant and actively monitored by AWS scales it as per the demand
    • are engineered to not be a single point of failure
    • need to Pre Warm ELB if the demand is expected to shoot especially during load testing. AWS documentation does not mentioned it now
    • supports routing traffic to instances in multiple AZs in the same region
    • performs Health Checks to route traffic only to the healthy instances
    • support Listeners with HTTP, HTTPS, SSL, TCP protocols
    • has an associated IPv4 and dual stack DNS name
    • can offload the work of encryption and decryption (SSL termination) so that the EC2 instances can focus on their main work
    • supports Cross Zone load balancing to help route traffic evenly across all EC2 instances regardless of the AZs they reside in
    • to help identify the IP address of a client
      • supports Proxy Protocol header for TCP/SSL connections
      • supports X-Forward headers for HTTP/HTTPS connections
    • supports Stick Sessions (session affinity) to bind a user’s session to a specific application instance,
      • it is not fault tolerant, if an instance is lost the information is lost
      • requires HTTP/HTTPS listener and does not work with TCP
      • requires SSL termination on ELB as it users the headers
    • supports Connection draining to help complete the in-flight requests in case an instance is deregistered
    • For High Availability, it is recommended to attach one subnet per AZ for at least two AZs, even if the instances are in a single subnet.
    • supports Static/Elastic IP (NLB only)
    • IPv4 & IPv6 support however VPC does not support IPv6. VPC now supports IPV6.
    • HTTPS listener does not support Client Side Certificate
    • For SSL termination at backend instances or support for Client Side Certificate use TCP for connections from the client to the ELB, use the SSL protocol for connections from the ELB to the back-end application, and deploy certificates on the back-end instances handling requests
    • supports a single SSL certificate, so for multiple SSL certificate multiple ELBs need to be created
    • Uses Server Name Indication to supports multiple SSL certificates

Application Load Balancer

  • supports HTTP and HTTPS (Secure HTTP) protocols
  • supports HTTP/2, which is enabled natively. Clients that support HTTP/2 can connect over TLS
  • supports WebSockets and Secure WebSockets natively
  • supports Request tracing, by default.
    • request tracing can be used to track HTTP requests from clients to targets or other services.
    • Load balancer upon receiving a request from a client, adds or updates the X-Amzn-Trace-Id header before sending the request to the target
  • supports containerized applications. Using Dynamic port mapping, ECS can select an unused port when scheduling a task and register the task with a target group using this port.
  • supports Sticky Sessions (Session Affinity) using load balancer generated cookies, to route requests from the same client to the same target
  • supports SSL termination, to decrypt the request on ALB before sending it to the underlying targets.
  • supports layer 7 specific features like X-Forwarded-For headers to help determine the actual client IP, port and protocol
  • automatically scales its request handling capacity in response to incoming application traffic.
  • supports hybrid load balancing, to route traffic to instances in VPC and an on-premises location
  • provides High Availability, by allowing more than one AZ to be specified
  • integrates with ACM to provision and bind a SSL/TLS certificate to the load balancer thereby making the entire SSL offload process very easy
  • supports multiple certificates for the same domain to a secure listener
  • supports IPv6 addressing, for an Internet facing load balancer
  • supports Cross-zone load balancing, and cannot be disabled.
  • supports Security Groups to control the traffic allowed to and from the load balancer.
  • provides Access Logs, to record all requests sent the load balancer, and store the logs in S3 for later analysis in compressed format
  • provides Delete Protection, to prevent the ALB from accidental deletion
  • supports Connection Idle Timeout – ALB maintains two connections for each request one with the Client (front end) and one with the target instance (back end). If no data has been sent or received by the time that the idle timeout period elapses, ALB closes the front-end connection
  • integrates with CloudWatch to provide metrics such as request counts, error counts, error types, and request latency
  • integrates with AWS WAF, a web application firewall that helps protect web applications from attacks by allowing rules configuration based on IP addresses, HTTP headers, and custom URI strings
  • integrates with CloudTrail to receive a history of ALB API calls made on the AWS account
  • back-end server authentication is NOT supported
  • does not provide Static, Elastic IP addresses

Network Load Balancer

  • handles volatile workloads and scale to millions of requests per second, without the need of pre-warming
  • offers extremely low latencies for latency-sensitive applications.
  • provides static IP/Elastic IP addresses for the load balancer
  • allows registering targets by IP address, including targets outside the VPC (on-premises) for the load balancer.
  • supports containerized applications. Using Dynamic port mapping, ECS can select an unused port when scheduling a task and register the task with a target group using this port.
  • monitors the health of its registered targets and routes the traffic only to healthy targets
  • enable cross-zone loading balancing only after creating the NLB
  • preserves client side source IP allowing the back-end to see client IP address. Target groups can be created with target type as instance ID or IP address. If targets registered by instance ID, the source IP addresses of the clients are preserved and provided to the applications. If register targets registered by IP address, the source IP addresses are the private IP addresses of the load balancer nodes.
  • supports both network and application target health checks.
  • supports long-lived TCP connections ideal for WebSocket type of applications
  • supports Zonal Isolation, which is designed for application architectures in a single zone and can be enabled in a single AZ to support architectures that require zonal isolation
  • does not support stick sessions

Auto Scaling

    • ensures correct number of EC2 instances are always running to handle the load by scaling up or down automatically as demand changes
    • cannot span multiple regions.
    • attempts to distribute instances evenly between the AZs that are enabled for the Auto Scaling group
    • performs checks either using EC2 status checks or can use ELB health checks to determine the health of an instance and terminates the instance if unhealthy, to launch a new instance
    • can be scaled using manual scaling, scheduled scaling or demand based scaling
    • cooldown period helps ensure instances are not launched or terminated before the previous scaling activity takes effect to allow the newly launched instances to start handling traffic and reduce load

AWS Auto Scaling & ELB

  • Auto Scaling & ELB can be used for High Availability and Redundancy by spanning Auto Scaling groups across multiple AZs within a region and then setting up ELB to distribute incoming traffic across those AZs
  • With Auto Scaling, use ELB health check with the instances to ensure that traffic is routed only to the healthy instances

AWS Auto Scaling & ELB

Auto Scaling & ELB

  • Auto Scaling dynamically adds and removes EC2 instances, while Elastic Load Balancing manages incoming requests by optimally routing traffic so that no one instance is overwhelmed
  • Auto Scaling helps to automatically increase the number of EC2 instances when the user demand goes up, and decrease the number of EC2 instances when demand goes down
  • ELB service helps to distribute the incoming web traffic (called the load) automatically among all the running EC2 instances
  • ELB uses load balancers to monitor traffic and handle requests that come through the Internet.
  • Using ELB & Auto Scaling
    • makes it easy to route traffic across a dynamically changing fleet of EC2 instances
    • load balancer acts as a single point of contact for all incoming traffic to the instances in an Auto Scaling group.

AWS Auto Scaling & ELB

Attaching/Detaching ELB with Auto Scaling Group

  • Auto Scaling integrates with Elastic Load Balancing and enables to attach one or more load balancers to an existing Auto Scaling group.
  • ELB registers the EC2 instance using its IP address and routes requests to the primary IP address of the primary interface (eth0) of the instance.
  • After the ELB is attached, it automatically registers the instances in the group and distributes incoming traffic across the instances
  • When ELB is detached, it enters the Removing state while deregistering the instances in the group.
  • If connection draining is enabled, ELB waits for in-flight requests to complete before deregistering the instances.
  • Instances remain running after they are deregistered from the ELB
  • Auto Scaling adds instances to the ELB as they are launched, but this can be suspended. Instances launched during the suspension period are not added to load balancer, after resumption, and must be registered manually.

High Availability & Redundancy

  • Auto Scaling can span across multiple AZs, within the same region
  • When one AZ becomes unhealthy or unavailable, Auto Scaling launches new instances in an unaffected AZ
  • When the unhealthy AZs recovers, Auto Scaling redistributes the traffic across all the healthy AZs
  • Elastic Load balancer can be setup to distribute incoming requests across EC2 instances in a single AZ or multiple AZs within a region
  • Using Auto Scaling & ELB by spanning Auto Scaling groups across multiple AZs within a region and then setting up ELB to distribute incoming traffic across those AZs helps take advantage of the safety and reliability of geographic redundancy
  • Incoming traffic is load balanced equally across all the AZs enabled for ELB

Health Checks

  • Auto Scaling group determines the health state of each instance by periodically checking the results of EC2 instance status checks
  • Auto Scaling marks the instance as unhealthy and replaces the instance, if the instance fails the EC2 instance status check
  • ELB also performs health checks on the EC2 instances that are registered with the it for e.g. application is available by pinging an health check page
  • Auto Scaling, by default, does not replace the instance, if the ELB health check fails
  • ELB health check with the instances should be used to ensure that traffic is routed only to the healthy instances
  • After a load balancer is registered with an Auto Scaling group, it can be configured to use the results of the ELB health check in addition to the EC2 instance status checks to determine the health of the EC2 instances in the Auto Scaling group.

Monitoring

  • Elastic Load Balancing sends data about the load balancers and EC2 instances to Amazon CloudWatch. CloudWatch collects data about the performance of your resources and presents it as metrics.
  • After registering one or more load balancers with the Auto Scaling group, Auto Scaling group can be configured to use ELB metrics (such as request latency or request count) to scale the application automatically

[do_widget id=text-15]

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company is building a two-tier web application to serve dynamic transaction-based content. The data tier is leveraging an Online Transactional Processing (OLTP) database. What services should you leverage to enable an elastic and scalable web tier?
    1. Elastic Load Balancing, Amazon EC2, and Auto Scaling
    2. Elastic Load Balancing, Amazon RDS with Multi-AZ, and Amazon S3
    3. Amazon RDS with Multi-AZ and Auto Scaling
    4. Amazon EC2, Amazon DynamoDB, and Amazon S3
  2. You have been given a scope to deploy some AWS infrastructure for a large organization. The requirements are that you will have a lot of EC2 instances but may need to add more when the average utilization of your Amazon EC2 fleet is high and conversely remove them when CPU utilization is low. Which AWS services would be best to use to accomplish this?
    1. Amazon CloudFront, Amazon CloudWatch and Elastic Load Balancing
    2. Auto Scaling, Amazon CloudWatch and AWS CloudTrail
    3. Auto Scaling, Amazon CloudWatch and Elastic Load Balancing
    4. Auto Scaling, Amazon CloudWatch and AWS Elastic Beanstalk
  3. A user has configured ELB with Auto Scaling. The user suspended the Auto Scaling AddToLoadBalancer, which adds instances to the load balancer. process for a while. What will happen to the instances launched during the suspension period?
    1. The instances will not be registered with ELB and the user has to manually register when the process is resumed
    2. The instances will be registered with ELB only once the process has resumed
    3. Auto Scaling will not launch the instance during this period due to process suspension
    4. It is not possible to suspend only the AddToLoadBalancer process
  4. You have an Auto Scaling group associated with an Elastic Load Balancer (ELB). You have noticed that instances launched via the Auto Scaling group are being marked unhealthy due to an ELB health check, but these unhealthy instances are not being terminated. What do you need to do to ensure trial instances marked unhealthy by the ELB will be terminated and replaced?
    1. Change the thresholds set on the Auto Scaling group health check
    2. Add an Elastic Load Balancing health check to your Auto Scaling group
    3. Increase the value for the Health check interval set on the Elastic Load Balancer
    4. Change the health check set on the Elastic Load Balancer to use TCP rather than HTTP checks
  5. You are responsible for a web application that consists of an Elastic Load Balancing (ELB) load balancer in front of an Auto Scaling group of Amazon Elastic Compute Cloud (EC2) instances. For a recent deployment of a new version of the application, a new Amazon Machine Image (AMI) was created, and the Auto Scaling group was updated with a new launch configuration that refers to this new AMI. During the deployment, you received complaints from users that the website was responding with errors. All instances passed the ELB health checks. What should you do in order to avoid errors for future deployments? (Choose 2 answer) [PROFESSIONAL]
    1. Add an Elastic Load Balancing health check to the Auto Scaling group. Set a short period for the health checks to operate as soon as possible in order to prevent premature registration of the instance to the load balancer.
    2. Enable EC2 instance CloudWatch alerts to change the launch configuration’s AMI to the previous one. Gradually terminate instances that are using the new AMI.
    3. Set the Elastic Load Balancing health check configuration to target a part of the application that fully tests application health and returns an error if the tests fail.
    4. Create a new launch configuration that refers to the new AMI, and associate it with the group. Double the size of the group, wait for the new instances to become healthy, and reduce back to the original size. If new instances do not become healthy, associate the previous launch configuration.
    5. Increase the Elastic Load Balancing Unhealthy Threshold to a higher value to prevent an unhealthy instance from going into service behind the load balancer.
  6. What is the order of most-to-least rapidly-scaling (fastest to scale first)? A) EC2 + ELB + Auto Scaling B) Lambda C) RDS
    1. B, A, C (Lambda is designed to scale instantly. EC2 + ELB + Auto Scaling require single-digit minutes to scale out. RDS will take at least 15 minutes, and will apply OS patches or any other updates when applied.)
    2. C, B, A
    3. C, A, B
    4. A, C, B
  7. A user has hosted an application on EC2 instances. The EC2 instances are configured with ELB and Auto Scaling. The application server session time out is 2 hours. The user wants to configure connection draining to ensure that all in-flight requests are supported by ELB even though the instance is being deregistered. What time out period should the user specify for connection draining?
    1. 5 minutes
    2. 1 hour (max allowed is 3600 secs that is close to 2 hours to keep the in flight requests alive)
    3. 30 minutes
    4. 2 hours

AWS ELB Monitoring

Following Features can be used for Monitoring Elastic Load Balancer

Cloud Watch Metrics

  • Elastic Load Balancing publishes data points to Amazon CloudWatch about your load balancers and back-end instances
  • Elastic Load Balancing reports metrics to CloudWatch only when requests are flowing through the load balancer. If there are requests flowing through the load balancer, Elastic Load Balancing measures and sends its metrics in 60-second intervals. If there are no requests flowing through the load balancer or no data for a metric, the metric is not reported.

Following metrics are available

  • HealthyHostCount, UnHealthyHostCount
    • Number of healthy and unhealthy instances registered with the load balancer.
    • Most useful statistics are average, min, and max
  • RequestCount
    • Number of requests completed or connections made during the specified interval (1 or 5 minutes).
    • Most useful statistic is sum
  • Latency
    • Time elapsed, in seconds, after the request leaves the load balancer until the headers of the response are received.
    • Most useful statistic is average
  • SurgeQueueLength
    • Total number of requests that are pending routing.
    • Load balancer queues a request if it is unable to establish a connection with a healthy instance in order to route the request.
    • Maximum size of the queue is 1,024. Additional requests are rejected when the queue is full.
    • Most useful statistic is max, because it represents the peak of queued requests.
  • SpilloverCount
    • The total number of requests that were rejected because the surge queue is full. Should ideally be 0
    • Most useful statistic is sum.
  • HTTPCode_ELB_4XX, HTTPCode_ELB_5XX
    • Client and Server error code generated by the load balancer
    • Most useful statistic is sum.
  • HTTPCode_Backend_2XX, HTTPCode_Backend_3XX, HTTPCode_Backend_4XX, HTTPCode_Backend_5XX
    • Number of HTTP response codes generated by registered instances
    • Most useful statistic is sum.

Elastic Load Balancer access logs

  • Elastic Load Balancing provides access logs that capture detailed information about all requests sent to your load balancer.
  • Each log contains information such as the time the request was received, the client’s IP address, latencies, request paths, and server responses.
  • Elastic Load Balancing captures the logs and stores them in the Amazon S3 bucket
  • Access logging is disabled by default and can be enabled without any additional charge. You are only charged for S3 storage

CloudTrail Logs

  • AWS CloudTrail can be used to capture all calls to the Elastic Load Balancing API made by or on behalf of your AWS account and either made using Elastic Load Balancing API directly, or indirectly through the AWS Management Console or AWS CLI
  • CloudTrail stores the information as log files in an Amazon S3 bucket that you specify.
  • Logs collected by CloudTrail can be used to monitor the activity of your load balancers and determine what API call was made, what source IP address was used, who made the call, when it was made, and so on

[do_widget id=text-15]

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. An admin is planning to monitor the ELB. Which of the below mentioned services does not help the admin capture the monitoring information about the ELB activity
    1. ELB Access logs
    2. ELB health check
    3. CloudWatch metrics
    4. ELB API calls with CloudTrail
  2. A customer needs to capture all client connection information from their load balancer every five minutes. The company wants to use this data for analyzing traffic patterns and troubleshooting their applications. Which of the following options meets the customer requirements?
    1. Enable AWS CloudTrail for the load balancer.
    2. Enable access logs on the load balancer.
    3. Install the Amazon CloudWatch Logs agent on the load balancer.
    4. Enable Amazon CloudWatch metrics on the load balancer
  3. Your supervisor has requested a way to analyze traffic patterns for your application. You need to capture all connection information from your load balancer every 10 minutes. Pick a solution from below. Choose the correct answer:
    1. Enable access logs on the load balancer
    2. Create a custom metric CloudWatch filter on your load balancer
    3. Use a CloudWatch Logs Agent
    4. Use AWS CloudTrail with your load balancer

References

Elastic Load Balance developer guide

AWS Elastic Load Balancer – ELB

AWS Elastic Load Balancer – ELB

  • Elastic Load Balancer allows the incoming traffic to be distributed automatically across multiple healthy EC2 instances.
  • ELB serves as a single point of contact to the client
  • ELB helps to being transparent and increases the application availability by allowing addition or removal of multiple EC2 instances across one or more availability zones, without disrupting the overall flow of information.
  • ELB benefits
    • is a distributed system that is fault tolerant and actively monitored
    • abstracts out the complexity of managing, maintaining, and scaling load balancers
    • can also serve as the first line of defense against attacks on network.
    • can offload the work of encryption and decryption (SSL termination) so that the EC2 instances can focus on their main work
    • offers integration with Auto Scaling, which ensures enough back-end capacity available to meet varying traffic levels
    • are engineered to not be a single point of failure
  • Elastic Load Balancer, by default, routes each request independently to the registered instance with the smallest load.
  • If an EC2 instance fails, ELB automatically reroutes the traffic to the remaining running healthy EC2 instances. If a failed EC2 instance is restored, Elastic Load Balancing restores the traffic to that instance.
  • Load Balancers only work across AZs within a region

Elastic Load Balancer basic architecture

AWS Elastic Load Balancer Types

Elastic Load Balancing supports three types of load balancers:

Application Load Balancer

Refer to Blog Post @ Application Load Balancer

Network Load Balancer

Refer to Blog Post @ Network Load Balancer

Refer Blog Post @ Classic Load Balancer vs Application Load Balancer vs Network Load Balancer

Elastic Load Balancer Features

Following ELB key concepts apply to all the Elastic Load Balancer types

Scaling ELB

  • Each ELB is allocated and configured with a default capacity
  • ELB Controller is the service which stores all the configuration and also monitors the load balancer and manages the capacity that is used to handle the client requests
  • As the traffic profile changes, the controller service scales the load balancers to handle more requests, scaling equally in all AZs.
  • ELB increases its capacity by utilizing either larger resources (scale up – resources with higher performance characteristics) or more individual resources (scale out).
  • AWS itself handles the scaling of the ELB capacity and this scaling is different to scaling of the EC2 instances to which the ELB routes its request to, which is handled by Auto Scaling
  • Time required for Elastic Load Balancing to scale can range from 1 to 7 minutes, depending on the changes in the traffic profile
  • When an Availability Zone is enabled for the load balancer, Elastic Load Balancing creates a load balancer node in the Availability Zone.
  • By default, each load balancer node distributes traffic across the registered targets in its Availability Zone only.

Pre-Warming ELB

  • ELB works best with gradual increase in traffic
  • AWS is able to scale automatically and handle a vast majority of use cases
  • However, in certain scenarios, if there is a flash traffic spike expected or a load test cannot be configured to gradually increase traffic, recommended to contact AWS support to have the load balancer “pre-warmed”
  • AWS will help Pre-warming the ELB, by configuring the load balancer to have the appropriate level of capacity based on expected traffic
  • AWS would need the information for the start, end dates and the expected request rate per second with the total size of request/response.
  • NOTE – AWS documentation does not include Pre-warming now

DNS Resolution

  • ELB is scaled automatically depending on the traffic profile
  • When scaled, Elastic Load Balancing service will update the Domain Name System (DNS) record of the load balancer so that the new resources have their respective IP addresses registered in DNS.
  • DNS record created includes a Time-to-Live (TTL) setting of 60 seconds
  • By default, ELB will return multiple IP addresses when clients perform a DNS resolution, with the records being randomly ordered on each DNS resolution request.
  • It is recommended that clients will re-lookup the DNS at least every 60 seconds to take advantage of the increased capacity

Load Balancer Types

  • Internet Load Balancer
    • An Internet-facing load balancer takes requests from clients over the Internet and distributes them across the EC2 instances that are registered with the load balancer
  • Internal Load Balancer – 
    • Internal load balancer routes traffic to EC2 instances in private subnets

Availability Zones/Subnets

  • Elastic Load Balancer should have atleast one subnet attached
  • Elastic Load Balancing allows subnets to be added and creates a load balancer node in each of the Availability Zone where the subnet resides.
  • Only one subnet per AZ can be attached to the ELB. Attaching a subnet with an AZ already attached replaces the existing subnet
  • Each Subnet must have a CIDR block with at least a /27 bitmask and has at least 8 free IP addresses, which ELB uses to establish connections with the back-end instances.
  • For High Availability, it is recommended to attach one subnet per AZ for at least two AZs, even if the instances are in a single subnet.
  • Subnets can be attached or detached from the ELB and it would start or stop sending requests to the instances in the subnet accordingly

Security Groups & NACL

  • Security groups & NACLs should allow Inbound traffic, on the load balancer listener port, from the Client for an Internet ELB or VPC CIDR for an Internal ELB
  • Security groups & NACLs should allow Outbound traffic to the back-end instances on both the instance listener port and the health check port
  • NACLs, in addition, should allow responses on the ephemeral ports
  • All EC2 instances should allow incoming traffic from ELB

SSL Negotiation Configuration

  • For HTTPS load balancer, Elastic Load Balancing uses a Secure Socket Layer (SSL) negotiation configuration, known as a security policy, to negotiate SSL connections between a client and the load balancer.
  • A security policy is a combination of SSL protocols, SSL ciphers, and the Server Order Preference option
    • Elastic Load Balancing supports the following versions of the SSL protocol TLS 1.2, TLS 1.1,  TLS 1.0, SSL 3.0, SSL 2.0 (deprecated now)
    • SSL protocols use several SSL ciphers to encrypt data over the Internet.
    • Elastic Load Balancing supports the Server Order Preference option for negotiating connections between a client and a load balancer.
    • During the SSL connection negotiation process, this allows the load balancer to control and select the first cipher in its list that is in the client’s list of ciphers instead of the default behavior of checking matching first cipher in client’s list with server’s list.
  • Elastic Load Balancer allows using a Predefined Security Policies or creating a Custom Security Policy for specific needs. If none is specified, ELB selects the latest Predefined Security Policy.
  • Elastic Load Balancer support multiple certificates using Server Name Indication (SNI)
    • If the hostname provided by a client matches a single certificate in the certificate list, the load balancer selects this certificate.
    • If a hostname provided by a client matches multiple certificates in the certificate list, the load balancer selects the best certificate that the client can support.
  • Classic Load Balancer does not support multiple certificates
  • ALB and NLB support multiple certificates

Health Checks

  • Load balancer performs health checks on all registered instances, whether the instance is in a healthy state or an unhealthy state.
  • Load balancer performs health checks to discover the availability of the EC2 instances, the load balancer periodically sends pings, attempts connections, or sends request to health check the EC2 instances.
  • Health check is InService for status of healthy instances and OutOfService for unhealthy ones
  • Load balancer sends a request to each registered instance at the Ping Protocol, Ping Port and Ping Path every HealthCheck Interval seconds. It waits for the instance to respond within the Response Timeout period. If the health checks exceed the Unhealthy Threshold for consecutive failed responses, the load balancer takes the instance out of service. When the health checks exceed the Healthy Threshold for consecutive successful responses, the load balancer puts the instance back in service.
  • Load balancer only sends requests to the healthy EC2 instances and stops routing requests to the unhealthy instances
  • All ELB types support health checks

Listeners

  • Listeners is the process which checks for connection requests from client
  • Listeners are configured with a protocol and a port for front-end (client to load balancer) connections, and a protocol and a port for back-end (load balancer to back-end instance) connections.
  • Listeners support HTTP, HTTPS, SSL, TCP protocols
  • A X.509 certificate is required for HTTPS or SSL connections and load balancer uses the certificate to terminate the connection and then decrypt requests from clients before sending them to the back-end instances.
  • If you want to use SSL, but don’t want to terminate the connection on the load balancer, use TCP for connections from the client to the load balancer, use the SSL protocol for connections from the load balancer to the back-end application, and deploy certificates on the back-end instances handling requests.
  • If you use an HTTPS/SSL connection for your back end, you can enable authentication on the back-end instance. This authentication can be used to ensure that back-end instances accept only encrypted communication, and to ensure that the back-end instance has the correct certificates.
  • ELB HTTPS listener does not support Client-Side SSL certificates

Idle Connection Timeout

  • For each request that a client makes through a load balancer, it maintains two connections, for each client request, one connection with the client and the other connection is to the back-end instance.
  • For each connection, the load balancer manages an idle timeout that is triggered when no data is sent over the connection for a specified time period. If no data has been sent or received, it closes the connection after the idle timeout period (defaults to 60 seconds) has elapsed
  • For lengthy operations, such as file uploads, the idle timeout setting for the connections should be adjusted to ensure that lengthy operations have time to complete.

X-Forwarded Headers & Proxy Protocol Support

  • As the Elastic Load Balancer intercepts the traffic between the client and the back end servers, the back end server does not know the IP address, Protocol and the Port used between the Client and the Load balancer.
  • ELB provides X-Forwarded headers support to help back end servers track the same when using HTTP protocol
    • X-Forwarded-For request header to help back end servers identify the IP address of a client when you use an HTTP or HTTPS load balancer.
    • X-Forwarded-Proto request header to help back end servers identify the protocol (HTTP/S) that a client used to connect to the server
    • X-Forwarded-Port request header to help back end servers identify the port that an HTTP or HTTPS load balancer uses to connect to the client.
  • ELB provides Proxy Protocol support to help back end servers track the same when using non-HTTP protocol  or when using HTTPS and not terminating the SSL connection on the load balancer.
    • Proxy Protocol is an Internet protocol used to carry connection information from the source requesting the connection to the destination for which the connection was requested.
    • Elastic Load Balancing uses Proxy Protocol version 1, which uses a human-readable header format with connection information such as the source IP address, destination IP address, and port numbers
    • If the ELB is already behind a Proxy with the Proxy protocol enabled, enabling the Proxy Protocol on ELB would add the header twice

Cross-Zone

  • By default, the load balancer distributes incoming requests evenly across its enabled Availability Zones for e.g. If AZ-a has 5 instances and AZ-b has 2 instances, the load will still be distributed 50% across each of the AZs
  • Without cross-zone load balancing, each load balancer node distributes traffic across the registered targets in the same Availability Zone.
  • Enabling Cross-Zone load balancing allows the ELB to distribute incoming requests evenly across all the back-end instances, regardless of the AZ
  • Cross-zone load balancer reduces the need to maintain equivalent numbers of back-end instances in each Availability Zone, and improves application’s ability to handle the loss of one or more back-end instances.
  • It is still recommended to maintain approximately equivalent numbers of instances in each Availability Zone for higher fault tolerance.
  • With cross-zone load balancing, each load balancer node distributes traffic across the registered targets in all enabled Availability Zones.
  • ALB -> Cross Zone load balancing is enabled by default and free
  • CLB -> Cross Zone load balancing is disabled, by default, and can be enabled and free
  • NLB -> Cross Zone load balancing is disabled, by default, and can be enabled and but charged for inter-az data transfer.

Connection Draining (Deregistration Delay)

  • By default, if an registered EC2 instance with the ELB is deregistered or becomes unhealthy, the load balancer immediately closes the connection
  • Connection draining can help the load balancer to complete the in-flight requests made while keeping the existing connections open, and preventing any new requests being sent to the instances that are de-registering or unhealthy.
  • Connection draining helps perform maintenance such as deploying software upgrades or replacing back-end instances without affecting customers’ experience
  • Connection draining allows you to specify a maximum time (between 1 and 3,600 seconds and default 300 seconds) to keep the connections alive before reporting the instance as de-registered. Maximum timeout limit does not apply to connections to unhealthy instances.
  • If the instances are part of an Auto Scaling group and connection draining is enabled for your load balancer, Auto Scaling waits for the in-flight requests to complete, or for the maximum timeout to expire, before terminating instances due to a scaling event or health check replacement.

Sticky Sessions (Session Affinity)

  • ELB can be configured to use sticky session feature (also called session affinity) which enables it to bind a user’s session to an instance and ensures all requests are sent to the same instance.
  • Stickiness remains for a period of time which can be controlled by the application’s session cookie, if one exists, or through cookie, named AWSELB, created through Elastic Load balancer.
  • Sticky sessions for CLB and ALB are disabled, by default.
  • NLB does not support sticky sessions

Requirements

  • An HTTP/HTTPS load balancer.
  • SSL traffic should be terminated on the ELB.
  • ELB does session stickiness on a HTTP/HTTPS listener is by utilizing an HTTP cookie. ELB has no visibility into the HTTP headers, if the SSL traffic is not terminated on the ELB and is terminated on the back-end instance.“
  • At least one healthy instance in each Availability Zone.

Duration-Based Session Stickiness

  • Duration-Based Session Stickiness is maintained by ELB using a special cookie created to track the instance for each request to each listener.
  • When the load balancer receives a request,
    • it first checks to see if this cookie is present in the request. If so, the request is sent to the instance specified in the cookie.
    • If there is no cookie, the ELB chooses an instance based on the existing load balancing algorithm and a cookie is inserted into the response for binding subsequent requests from the same user to that instance.
  • Stickiness policy configuration defines a cookie expiration, which establishes the duration of validity for each cookie.
  • Cookie is automatically updated after its duration expires.

Application-Controlled Session Stickiness

  • Load balancer uses a special cookie only to associate the session with the instance that handled the initial request, but follows the lifetime of the application cookie specified in the policy configuration.
  • Load balancer only inserts a new stickiness cookie if the application response includes a new application cookie. The load balancer stickiness cookie does not update with each request.
  • If the application cookie is explicitly removed or expires, the session stops being sticky until a new application cookie is issued.
  • If an instance fails or becomes unhealthy, the load balancer stops routing request to that instance, instead chooses a new healthy instance based on the existing load balancing algorithm.
  • The load balancer treats the session as now “stuck” to the new healthy instance, and continues routing requests to that instance even if the failed instance comes back.

Load Balancer Deletion

  • Deleting a load balancer does not affect the instances registered with the load balancer and they would continue to run

ELB with Autoscaling

Refer Blog Post @ ELB with Autoscaling

[do_widget id=text-15]

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A user has configured an HTTPS listener on an ELB. The user has not configured any security policy which can help to negotiate SSL between the client and ELB. What will ELB do in this scenario?
    1. By default ELB will select the first version of the security policy
    2. By default ELB will select the latest version of the policy
    3. ELB creation will fail without a security policy
    4. It is not required to have a security policy since SSL is already installed
  2. A user has configured ELB with SSL using a security policy for secure negotiation between the client and load balancer. The ELB security policy supports various ciphers. Which of the below mentioned options helps identify the matching cipher at the client side to the ELB cipher list when client is requesting ELB DNS over SSL
    1. Cipher Protocol
    2. Client Configuration Preference
    3. Server Order Preference
    4. Load Balancer Preference
  3. A user has configured ELB with SSL using a security policy for secure negotiation between the client and load balancer. Which of the below mentioned security policies is supported by ELB?
    1. Dynamic Security Policy
    2. All the other options
    3. Predefined Security Policy
    4. Default Security Policy
  4. A user has configured ELB with SSL using a security policy for secure negotiation between the client and load balancer. Which of the below mentioned SSL protocols is not supported by the security policy?
    1. TLS 1.3
    2. TLS 1.2
    3. SSL 2.0
    4. SSL 3.0
  5. A user has configured ELB with a TCP listener at ELB as well as on the back-end instances. The user wants to enable a proxy protocol to capture the source and destination IP information in the header. Which of the below mentioned statements helps the user understand a proxy protocol with TCP configuration?
    1. If the end user is requesting behind a proxy server then the user should not enable a proxy protocol on ELB
    2. ELB does not support a proxy protocol when it is listening on both the load balancer and the back-end instances
    3. Whether the end user is requesting from a proxy server or directly, it does not make a difference for the proxy protocol
    4. If the end user is requesting behind the proxy then the user should add the “isproxy” flag to the ELB Configuration
  6. A user has enabled session stickiness with ELB. The user does not want ELB to manage the cookie; instead he wants the application to manage the cookie. What will happen when the server instance, which is bound to a cookie, crashes?
    1. The response will have a cookie but stickiness will be deleted
    2. The session will not be sticky until a new cookie is inserted
    3. ELB will throw an error due to cookie unavailability
    4. The session will be sticky and ELB will route requests to another server as ELB keeps replicating the Cookie
  7. A user has created an ELB with Auto Scaling. Which of the below mentioned offerings from ELB helps the user to stop sending new requests traffic from the load balancer to the EC2 instance when the instance is being deregistered while continuing in-flight requests?
    1. ELB sticky session
    2. ELB deregistration check
    3. ELB connection draining
    4. ELB auto registration Off
  8. When using an Elastic Load Balancer to serve traffic to web servers, which one of the following is true?
    1. Web servers must be publicly accessible
    2. The same security group must be applied to both the ELB and EC2 instances
    3. ELB and EC2 instance must be in the same subnet
    4. ELB and EC2 instances must be in the same VPC
  9. A user has configured Elastic Load Balancing by enabling a Secure Socket Layer (SSL) negotiation configuration known as a Security Policy. Which of the below mentioned options is not part of this secure policy while negotiating the SSL connection between the user and the client?
    1. SSL Protocols
    2. Client Order Preference
    3. SSL Ciphers
    4. Server Order Preference
  10. A user has created an ELB with the availability zone us-east-1. The user wants to add more zones to ELB to achieve High Availability. How can the user add more zones to the existing ELB?
    1. It is not possible to add more zones to the existing ELB
    2. Only option is to launch instances in different zones and add to ELB
    3. The user should stop the ELB and add zones and instances as required
    4. The user can add zones on the fly from the AWS console
  11. A user has launched an ELB which has 5 instances registered with it. The user deletes the ELB by mistake. What will happen to the instances?
    1. ELB will ask the user whether to delete the instances or not
    2. Instances will be terminated
    3. ELB cannot be deleted if it has running instances registered with it
    4. Instances will keep running
  12. A Sys-admin has created a shopping cart application and hosted it on EC2. The EC2 instances are running behind ELB. The admin wants to ensure that the end user request will always go to the EC2 instance where the user session has been created. How can the admin configure this?
    1. Enable ELB cross zone load balancing
    2. Enable ELB cookie setup
    3. Enable ELB sticky session
    4. Enable ELB connection draining
  13. A user has setup connection draining with ELB to allow in-flight requests to continue while the instance is being deregistered through Auto Scaling. If the user has not specified the draining time, how long will ELB allow inflight requests traffic to continue?
    1. 600 seconds
    2. 3600 seconds
    3. 300 seconds
    4. 0 seconds
  14. A customer has a web application that uses cookie Based sessions to track logged in users. It is deployed on AWS using ELB and Auto Scaling. The customer observes that when load increases Auto Scaling launches new Instances but the load on the existing Instances does not decrease, causing all existing users to have a sluggish experience. Which two answer choices independently describe a behavior that could be the cause of the sluggish user experience?
    1. ELB’s normal behavior sends requests from the same user to the same backend instance (its not by default)
    2. ELB’s behavior when sticky sessions are enabled causes ELB to send requests in the same session to the same backend 
    3. A faulty browser is not honoring the TTL of the ELB DNS name (DNS TTL would only impact the ELB instances if scaled and not the EC2 instances to which the traffic is routed)
    4. The web application uses long polling such as comet or websockets. Thereby keeping a connection open to a web server tor a long time
  15. A customer has an online store that uses the cookie-based sessions to track logged-in customers. It is deployed on AWS using ELB and autoscaling. When the load increases, Auto scaling automatically launches new web servers, but the load on the web servers do not decrease. This causes the customers a poor experience. What could be causing the issue ?
    1. ELB DNS records Time to Live is set too high (DNS TTL would only impact the ELB instances if scaled and not the EC2 instances to which the traffic is routed)
    2. ELB is configured to send requests with previously established sessions
    3. Website uses CloudFront which is keeping sessions alive
    4. New Instances are not being added to the ELB during the Auto Scaling cool down period
  16. You are designing a multi-platform web application for AWS. The application will run on EC2 instances and will be accessed from PCs, tablets and smart phones. Supported accessing platforms are Windows, MACOS, IOS and Android. Separate sticky session and SSL certificate setups are required for different platform types. Which of the following describes the most cost effective and performance efficient architecture setup?
    1. Setup a hybrid architecture to handle session state and SSL certificates on-prem and separate EC2 Instance groups running web applications for different platform types running in a VPC.
    2. Set up one ELB for all platforms to distribute load among multiple instance under it. Each EC2 instance implements all functionality for a particular platform.
    3. Set up two ELBs. The first ELB handles SSL certificates for all platforms and the second ELB handles session stickiness for all platforms for each ELB run separate EC2 instance groups to handle the web application for each platform.
    4. Assign multiple ELBs to an EC2 instance or group of EC2 instances running the common components of the web application, one ELB for each platform type. Session stickiness and SSL termination are done at the ELBs. (Session stickiness requires HTTPS listener with SSL termination on the ELB and ELB does not support multiple SSL certs so one is required for each cert)
  17. You are migrating a legacy client-server application to AWS. The application responds to a specific DNS domain (e.g. www.example.com) and has a 2-tier architecture, with multiple application servers and a database server. Remote clients use TCP to connect to the application servers. The application servers need to know the IP address of the clients in order to function properly and are currently taking that information from the TCP socket. A Multi-AZ RDS MySQL instance will be used for the database. During the migration you can change the application code but you have to file a change request. How would you implement the architecture on AWS in order to maximize scalability and high availability?
    1. File a change request to implement Proxy Protocol support In the application. Use an ELB with a TCP Listener and Proxy Protocol enabled to distribute load on two application servers in different AZs. (ELB with TCP listener and proxy protocol will allow IP to be passed )
    2. File a change request to Implement Cross-Zone support in the application. Use an ELB with a TCP Listener and Cross-Zone Load Balancing enabled, two application servers in different AZs.
    3. File a change request to implement Latency Based Routing support in the application. Use Route 53 with Latency Based Routing enabled to distribute load on two application servers in different AZs.
    4. File a change request to implement Alias Resource support in the application Use Route 53 Alias Resource Record to distribute load on two application servers in different AZs.
  18. A user has created an ELB with three instances. How many security groups will ELB create by default?
    1. 3
    2. 5
    3. 2 (One for ELB to allow inbound and Outbound to listener and health check port of instances and One for the Instances to allow inbound from ELB)
    4. 1
  19. You have a web-style application with a stateless but CPU and memory-intensive web tier running on a cc2 8xlarge EC2 instance inside of a VPC The instance when under load is having problems returning requests within the SLA as defined by your business The application maintains its state in a DynamoDB table, but the data tier is properly provisioned and responses are consistently fast. How can you best resolve the issue of the application responses not meeting your SLA?
    1. Add another cc2 8xlarge application instance, and put both behind an Elastic Load Balancer
    2. Move the cc2 8xlarge to the same Availability Zone as the DynamoDB table (Does not improve the response time and performance)
    3. Cache the database responses in ElastiCache for more rapid access (Data tier is responding fast)
    4. Move the database from DynamoDB to RDS MySQL in scale-out read-replica configuration (Data tier is responding fast)
  20. An organization has configured a VPC with an Internet Gateway (IGW). pairs of public and private subnets (each with one subnet per Availability Zone), and an Elastic Load Balancer (ELB) configured to use the public subnets. The applications web tier leverages the ELB, Auto Scaling and a Multi-AZ RDS database instance. The organization would like to eliminate any potential single points of failure in this design. What step should you take to achieve this organization’s objective?
    1. Nothing, there are no single points of failure in this architecture.
    2. Create and attach a second IGW to provide redundant internet connectivity. (VPC can be attached only 1 IGW)
    3. Create and configure a second Elastic Load Balancer to provide a redundant load balancer. (ELB scales by itself with multiple availability zones configured with it)
    4. Create a second multi-AZ RDS instance in another Availability Zone and configure replication to provide a redundant database. (Multi AZ requires 2 different AZ for setup and already has a standby)
  21. Your application currently leverages AWS Auto Scaling to grow and shrink as load Increases/ decreases and has been performing well. Your marketing team expects a steady ramp up in traffic to follow an upcoming campaign that will result in a 20x growth in traffic over 4 weeks. Your forecast for the approximate number of Amazon EC2 instances necessary to meet the peak demand is 175. What should you do to avoid potential service disruptions during the ramp up in traffic?
    1. Ensure that you have pre-allocated 175 Elastic IP addresses so that each server will be able to obtain one as it launches (max limit 5 EIP and a service request needs to be submitted)
    2. Check the service limits in Trusted Advisor and adjust as necessary so the forecasted count remains within limits.
    3. Change your Auto Scaling configuration to set a desired capacity of 175 prior to the launch of the marketing campaign (Will cause 175 instances to be launched and running but not gradually scale)
    4. Pre-warm your Elastic Load Balancer to match the requests per second anticipated during peak demand (Does not need pre warming as the load is increasing steadily)
  22. Which of the following features ensures even distribution of traffic to Amazon EC2 instances in multiple Availability Zones registered with a load balancer?
    1. Elastic Load Balancing request routing
    2. An Amazon Route 53 weighted routing policy (does not control traffic to EC2 instance)
    3. Elastic Load Balancing cross-zone load balancing
    4. An Amazon Route 53 latency routing policy (does not control traffic to EC2 instance)
  23. Your web application front end consists of multiple EC2 instances behind an Elastic Load Balancer. You configured ELB to perform health checks on these EC2 instances, if an instance fails to pass health checks, which statement will be true?
    1. The instance gets terminated automatically by the ELB (it is done by Autoscaling)
    2. The instance gets quarantined by the ELB for root cause analysis.
    3. The instance is replaced automatically by the ELB. (it is done by Autoscaling)
    4. The ELB stops sending traffic to the instance that failed its health check
  24. You have a web application running on six Amazon EC2 instances, consuming about 45% of resources on each instance. You are using auto-scaling to make sure that six instances are running at all times. The number of requests this application processes is consistent and does not experience spikes. The application is critical to your business and you want high availability at all times. You want the load to be distributed evenly between all instances. You also want to use the same Amazon Machine Image (AMI) for all instances. Which of the following architectural choices should you make?
    1. Deploy 6 EC2 instances in one availability zone and use Amazon Elastic Load Balancer. (Single AZ will not provide High Availability)
    2. Deploy 3 EC2 instances in one region and 3 in another region and use Amazon Elastic Load Balancer. (Different region, AMI would not be available unless copied)
    3. Deploy 3 EC2 instances in one availability zone and 3 in another availability zone and use Amazon Elastic Load Balancer.
    4. Deploy 2 EC2 instances in three regions and use Amazon Elastic Load Balancer. (Different region, AMI would not be available unless copied)
  25. You are designing an SSL/TLS solution that requires HTTPS clients to be authenticated by the Web server using client certificate authentication. The solution must be resilient. Which of the following options would you consider for configuring the web server infrastructure? (Choose 2 answers)
    1. Configure ELB with TCP listeners on TCP/443. And place the Web servers behind it. (terminate SSL on the instance using client-side certificate)
    2. Configure your Web servers with EIPs. Place the Web servers in a Route53 Record Set and configure health checks against all Web servers. (Remove ELB and use Web Servers directly with Route 53)
    3. Configure ELB with HTTPS listeners, and place the Web servers behind it. (ELB with HTTPs does not support Client-Side certificates)
    4. Configure your web servers as the origins for a CloudFront distribution. Use custom SSL certificates on your CloudFront distribution (CloudFront does not Client-Side ssl certificates)
  26. You are designing an application that contains protected health information. Security and compliance requirements for your application mandate that all protected health information in the application use encryption at rest and in transit. The application uses a three-tier architecture where data flows through the load balancer and is stored on Amazon EBS volumes for processing, and the results are stored in Amazon S3 using the AWS SDK. Which of the following two options satisfy the security requirements? Choose 2 answers
    1. Use SSL termination on the load balancer, Amazon EBS encryption on Amazon EC2 instances, and Amazon S3 with server-side encryption. (connection between ELB and EC2 not encrypted)
    2. Use SSL termination with a SAN SSL certificate on the load balancer, Amazon EC2 with all Amazon EBS volumes using Amazon EBS encryption, and Amazon S3 with server-side encryption with customer-managed keys.
    3. Use TCP load balancing on the load balancer, SSL termination on the Amazon EC2 instances, OS-level disk encryption on the Amazon EBS volumes, and Amazon S3 with server-side encryption.
    4. Use TCP load balancing on the load balancer, SSL termination on the Amazon EC2 instances, and Amazon S3 with server-side encryption. (Does not mention EBS encryption)
    5. Use SSL termination on the load balancer, an SSL listener on the Amazon EC2 instances, Amazon EBS encryption on EBS volumes containing PHI, and Amazon S3 with server-side encryption.
  27. A startup deploys its photo-sharing site in a VPC. An elastic load balancer distributes web traffic across two subnets. The load balancer session stickiness is configured to use the AWS-generated session cookie, with a session TTL of 5 minutes. The web server Auto Scaling group is configured as min-size=4, max-size=4. The startup is preparing for a public launch, by running load-testing software installed on a single Amazon Elastic Compute Cloud (EC2) instance running in us-west-2a. After 60 minutes of load-testing, the web server logs show the following:WEBSERVER LOGS | # of HTTP requests from load-tester | # of HTTP requests from private beta users || webserver #1 (subnet in us-west-2a): | 19,210 | 434 || webserver #2 (subnet in us-west-2a): | 21,790 | 490 || webserver #3 (subnet in us-west-2b): | 0 | 410 || webserver #4 (subnet in us-west-2b): | 0 | 428 |Which recommendations can help ensure that load-testing HTTP requests are evenly distributed across the four web servers? Choose 2 answers
    1. Launch and run the load-tester Amazon EC2 instance from us-east-1 instead.
    2. Configure Elastic Load Balancing session stickiness to use the app-specific session cookie.
    3. Re-configure the load-testing software to re-resolve DNS for each web request. (Refer link)
    4. Configure Elastic Load Balancing and Auto Scaling to distribute across us-west-2a and us-west-2b.
    5. Use a third-party load-testing service which offers globally distributed test clients. (Refer link)
  28. To serve Web traffic for a popular product your chief financial officer and IT director have purchased 10 m1.large heavy utilization Reserved Instances (RIs) evenly spread across two availability zones: Route 53 is used to deliver the traffic to an Elastic Load Balancer (ELB). After several months, the product grows even more popular and you need additional capacity As a result, your company purchases two c3.2xlarge medium utilization RIs You register the two c3.2xlarge instances with your ELB and quickly find that the ml large instances are at 100% of capacity and the c3.2xlarge instances have significant capacity that’s unused Which option is the most cost effective and uses EC2 capacity most effectively?
    1. Use a separate ELB for each instance type and distribute load to ELBs with Route 53 weighted round robin
    2. Configure Autoscaling group and Launch Configuration with ELB to add up to 10 more on-demand mi large instances when triggered by CloudWatch shut off c3.2xlarge instances (increase cost as you still pay for the RI)
    3. Route traffic to EC2 m1.large and c3.2xlarge instances directly using Route 53 latency based routing and health checks shut off ELB (will not still use the capacity effectively)
    4. Configure ELB with two c3.2xlarge Instances and use on-demand Autoscailng group for up to two additional c3.2xlarge instances Shut on m1.large instances(Increases cost, as you still pay for the 10 m1.large RI)
  29. Which header received at the EC2 instance identifies the port used by the client while requesting ELB?
    1. X-Forwarded-Proto
    2. X-Requested-Proto
    3. X-Forwarded-Port
    4. X-Requested-Port
  30. A user has configured ELB with two instances running in separate AZs of the same region? Which of the below mentioned statements is true?
    1. Multi AZ instances will provide HA with ELB (ELB provides HA to route traffic to healthy instances only it does not provide scalability)
    2. Multi AZ instances are not possible with a single ELB
    3. Multi AZ instances will provide scalability with ELB
    4. The user can achieve both HA and scalability with ELB
  31. A user is configuring the HTTPS protocol on a front end ELB and the SSL protocol for the back-end listener in ELB. What will ELB do?
    1. It will allow you to create the configuration, but the instance will not pass the health check
    2. Receives requests on HTTPS and sends it to the back end instance on SSL
    3. It will not allow you to create this configuration (Will give error “Load Balancer protocol is an application layer protocol, but instance protocol is not. Both the Load Balancer protocol and the instance protocol should be at the same layer. Please fix.”)
    4. It will allow you to create the configuration, but ELB will not work as expected
  32. An ELB is diverting traffic across 5 instances. One of the instances was unhealthy only for 20 minutes. What will happen after 20 minutes when the instance becomes healthy?
    1. ELB will never divert traffic back to the same instance
    2. ELB will not automatically send traffic to the same instance. However, the user can configure to start sending traffic to the same instance
    3. ELB starts sending traffic to the instance once it is healthy
    4. ELB terminates the instance once it is unhealthy. Thus, the instance cannot be healthy after 10 minutes
  33. A user has hosted a website on AWS and uses ELB to load balance the multiple instances. The user application does not have any cookie management. How can the user bind the session of the requestor with a particular instance?
    1. Bind the IP address with a sticky cookie
    2. Create a cookie at the application level to set at ELB
    3. Use session synchronization with ELB
    4. Let ELB generate a cookie for a specified duration
  34. A user has configured a website and launched it using the Apache web server on port 80. The user is using ELB with the EC2 instances for Load Balancing. What should the user do to ensure that the EC2 instances accept requests only from ELB?
    1. Open the port for an ELB static IP in the EC2 security group
    2. Configure the security group of EC2, which allows access to the ELB source security group
    3. Configure the EC2 instance so that it only listens on the ELB port
    4. Configure the security group of EC2, which allows access only to the ELB listener
  35. AWS Elastic Load Balancer supports SSL termination.
    1. For specific availability zones only
    2. False
    3. For specific regions only
    4. For all regions
  36. User has launched five instances with ELB. How can the user add the sixth EC2 instance to ELB?
    1. The user can add the sixth instance on the fly.
    2. The user must stop the ELB and add the sixth instance.
    3. The user can add the instance and change the ELB config file.
    4. The ELB can only have a maximum of five instances.

References