Post

AWS - Balancing - ELB


Elastic Load Balancing

elb


Overall

The foundation of the web tier includes the use of ELB in the architecture.

  • distributes income app / network traffic evenly across multiple targets in or across Availability Zones.
    • Target: EC2 instances, containers, internet protocol (IP) addresses, and Lambda functions
  • An ELB has a DNS record, facilitates the public requests to be routed to an ELBs environment

  • scales load balancer
    • as traffic to application changes over time.
    • It can automatically scale to most workloads.
  • send traffic to EC2 instances, can also send metrics to CloudWatch, which is a managed monitoring service.
    • The metrics from EC2 and ELB can act as triggers,
    • if you notice a particularly high latency or that the servers are becoming overused,
    • can take advantage of Auto Scaling to add more capacity to the web server fleet

Screen Shot 2020-06-22 at 22.23.27


high availability

high availability in Region

Screen Shot 2020-06-22 at 22.57.39

  • create the load balancer in a VPC, make the load balancer internal / private, internet-facing / public.

  • Internet-facing load balancers
    • deployed in the public subnet
    • balance traffic from web server in Availability Zones
    • a DNS name will be created with the public IP address.
    • The DNS records are publicly resolvable in both cases.
  • An internal load balancer
    • not exposed to the internet.
    • distributes traffic to Amazon EC2 instances from clients with access to the VPC for the load balancer.
    • distributes traffic between the private subnets.
    • a DNS name will be created will the private IP address of the load balancer.

high availability across Regions

  • Each load balancer is comprised of nodes, deployed to one or more AZs.
    • A load balancer node is placed in each associated AZ,
    • a load balancer can have multiple nodes that can be placed into multiple AZs

component

Listeners

  • Listener
    • Before start using your Application Load Balancer, must add one or more listeners.
    • A listener is a process that checks for connection requests, using the protocol and port that you configure.
    • The rules that you define for a listener determine how the load balancer routes requests to its registered targets.
  • Listener rules
    • Each listener has a default rule, and you can optionally define additional rules.
    • Each rule consists of a priority, one or more actions, and one or more conditions.
  • Default rules
    • When you create a listener, you define actions for the default rule. Default rules can’t have conditions. If the conditions for none of a listener’s rules are met, then the action for the default rule is performed.
  • Rule priority
    • Each rule has a priority. Rules are evaluated in priority order, from the lowest value to the highest value. The default rule is evaluated last. You can change the priority of a nondefault rule at any time. You cannot change the priority of the default rule. For more information, see Reorder rules.
  • Rule actions
    • Each rule action has a type, an order, and the information required to perform the action. For more information, see Rule action types.
  • Rule conditions
    • Each rule condition has a type and configuration information. When the conditions for a rule are met, then its actions are performed. For more information, see Rule condition types.

Target groups

  • Target groups route requests to one or more registered targets, such as EC2 instances, using the protocol and port number that you specify.
  • You can register a target with multiple target groups.
  • You can configure health checks on a per target group basis. Health checks are performed on all targets registered to a target group that is specified in a listener rule for your load balancer.

  • Each target group is used to route requests to one or more registered targets.
    • When create each listener rule, specify a target group and conditions.
    • When a rule condition is met, traffic is forwarded to the corresponding target group.
    • create different target groups for different types of requests.
    • For example, create one target group for general requests and other target groups for requests to the microservices for your application. You can use each target group with only one load balancer. For more information, see Application Load Balancer components.
  • define health check settings for load balancer on a per target group basis.
    • Each target group uses the default health check settings
    • After you specify a target group in a rule for a listener, the load balancer continually monitors the health of all targets registered with the target group that are in an Availability Zone enabled for the load balancer.
    • The load balancer routes requests to the registered targets that are healthy.

ELB Type

Elastic Load Balancing is available in three types:

Screen Shot 2020-05-09 at 16.50.36


Application Load Balancer

  • operates at the Application level.

  • ideal for advanced load balancing of HTTP and HTTPS traffic.

  • content-based routing

    • routes traffic to targets based on the content of the request.

    • examine content attributes (host headers, path, HTTP headers, source IPs, ports) and route requests based on content rules.

    • content rule: an ALB rule that determines its route based on content and conditions.

  • provides advanced request routing

    • targeted at delivery of modern application architectures, including microservices and container-based applications.

    • they support applications that run in containers.

    • support a pair of industry-standard protocols—such as WebSocketand HTTP/2—and also provide additional visibility into the health of the target instances and containers.

    • Websites and mobile apps that run in containers or on EC2 instances will benefit from the use of Application Load Balancers.

  • simplifies and improves the security of the application

    • by ensuring that the latest SSL/TLS ciphers and protocols are used at all times.

    • Can host multiple SSL certificates

  • By default, ALB’s IP change over time due to changes in AWS’s infrastructure.

    • It is recommended to always use DNS to find the public IP.

Network Load Balancer

distributes this traffic across the targets within the same Availability Zone.

  • the Transport Layer (layer 4)
    • operates at the network transport level
  • NLB’s IP address will not change
    • optimized to handle sudden and volatile network traffic patterns , while using a single static IP address per Availability Zone.
  • load balancing both TCP and UDP traffic

  • routing connections to targets based on IP protocol data
    • It accepts incoming traffic from clients

    • NLBs supports routing using
      • Ports
      • TCP/UDP protocol
      • source/target IPs
  • handling millions of requests/sec while maintaining ultra-low latencies.

  • is API-compatible with the ALB, including full programmatic control of target groups and targets

  • advantage of using Network Load Balancers (NLBs)
    • When needing extreme performance
    • When the source IP must be preserved
    • packets are not modified on the route to its destination
    • supports routing to multiple applications within an EC2 instance
    • can handle volatile workloads
    • supports targets outside a VPC
    • faster performance than ALB and CLB
    • can be allocated a static IP address

Classic Load Balancer

provides basic load balancing across multiple EC2 instances

  • operates at both the application level and network transport level
    • supports the load balancing of applications that use HTTP, HTTPS, TCP, and SSL.
  • an older implementation. Recommends dedicated Application / Network Load Balancer

  • ideal for applications that were built within the EC2-Classic network.

  • listener accepts traffic based on ports and protocols
    • placed between tiers of an application or between instances.
  • The nodes of an internal load balancer have only private IP addresses.

  • Classic Load Balancer’s security group
    • Ensures that the instances receive traffic only from the load balancer.
      • restrict clients from accessing an instance directly.
    • Defines the type of traffic allowed to connect to a load balancer.
    • Can be shared amongst other load balancers in an AWS account.
      • A security group can be applied to more than one load balancer,
      • reducing the need to create a security group for each load balancer.

key difference

key difference in how the load balancer types are configured.

  • With ALB / NLB, register targets in target groups, and route traffic to the target groups.
  • With CLB, register instances with the load balancer.

Using an Application Load Balancer instead of a Classic Load Balancer has the following benefits:

  • Support for path-based routing
    • can configure rules for listener that forward requests based on the URL in the request.
    • to structure the application as smaller services, and route requests to the correct service based on the content of the URL.
  • Support for host-based routing
    • can configure rules for listener that forward requests based on the host field in the HTTP header.
    • to route requests to multiple domains using a single load balancer.
  • Support for routing based on fields in the request
    • such as standard and custom HTTP headers and methods, query parameters, and source IP addresses.
  • Support for routing requests to multiple APPs on a single EC2 instance </FONT>
    • can register each instance or IP address with the same target group using multiple ports.
  • Support for redirecting requests from one URL to another

  • Support for returning a custom HTTP response

  • Support for registering targets by IP address
    • including targets outside the VPC for the load balancer.
  • Support for registering Lambda functions as targets

  • Support for the load balancer to authenticate users of the applications through their corporate or social identities before routing requests

  • Support for containerized applications
    • Amazon ECS can select an unused port when scheduling a task and register the task with a target group using this port.
    • to make efficient use of the clusters.
  • 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 you to scale each service dynamically based on demand.
  • Access logs

    contain additional information and are stored in compressed format.

  • Improved load balancer performance.

  • accepts incoming traffic from clients and routes requests to its registered targets (such as EC2 instances) in one or more Availability Zones
    • configure load balancer to accept incoming traffic by specifying one or more listeners.
    • A listener is a process that checks for connection requests.
    • Listeners are tuned into incoming connections, internally or public
    • route requests to target groups based on defined rules.
    • configured with a protocol and port number for connections from clients to the load balancer and from the load balancer to the targets.

Screen Shot 2020-05-09 at 14.28.41

  • can also configure the load balancer to perform health checks
    • monitor the health of the registered targets
    • the load balancer only sends requests to the healthy instances.
    • detects an unhealthy target, it stops routing traffic to that target.
    • It then resumes routing traffic to that target when it detects that the target is healthy again.

Screen Shot 2020-06-09 at 21.38.59

Screen Shot 2020-06-09 at 21.39.14

  • EC2 instances behind a load balancer are directly accessible until the security group’s source has been updated to only accept connections from the ELB.

why ELB

Screen Shot 2020-05-09 at 14.29.23

  • high availability and better fault tolerance for the applications
    • balances traffic across healthy targets in a single Availability Zone or across multiple Availability Zones.
    • If targets in a single Availability Zone are unhealthy,
    • ELB will route traffic to healthy targets in other Availability Zones.
    • After the targets return to a healthy state, load balancing will automatically resume traffic to them
  • Health checks
    • To discover the availability of EC2 instances
    • the load balancer periodically sends pings, attempts connections, or sends requests to test the Amazon EC2 instances.
      • These tests are called health checks.
      • registered EC2 instance respond to the health check with an HTTP status code of 200 to be considered healthy by the load balancer.
    • unhealthy threshold
      • determines the number of health check failures before an EC2 instance is deemed unhealthy.

Screen Shot 2020-06-20 at 23.04.31

  • Security features
    • use Amazon VPC to create and manage security groups associated with load balancers to provide additional networking and security options. can also create an internal—or non-internet-facing—load balancer.
  • TLS termination
    • ELB provides integrated certificate management and SSL decryption
    • centrally manage the SSL settings of the load balancer and offload CPU intensive work from the application.
  • Automatically layer 4 or 7 load balance the containerized applications
    • With enhanced container support for Elastic Load Balancing, you can now load balance across multiple ports on the same EC2 instance.
      • take advantage of deep integration with Amazon ECS, which provides a fully-managed container offering.
      • register a service with a load balancer, and Amazon ECS transparently manages the registration and de-registration of Docker containers.
      • The load balancer automatically detects the port and dynamically reconfigures itself.
  • Automatically scale the applications
    • ELB works with CloudWatch and EC2 Auto Scaling
      • to scale the applications to the demands of the customers.
      • to automatically distribute incoming traffic across a dynamically changing number of instances.
    • CloudWatch alarms can trigger auto scaling for the EC2 instance fleet when the latency of any one of the EC2 instances exceeds a preconfigured threshold.
    • EC2 Auto Scaling then provisions new instances and the applications will be ready to serve the next customer request.
    • The load balancer will register the EC2 instance and direct traffic to it as needed.
  • Use Elastic Load Balancing in the VPC
    • use Elastic Load Balancing to create a public entry point into the VPC, or to route request traffic between tiers of the application within the VPC.
    • You can assign security groups to the load balancer to control which ports are open to a list of allowed sources. Because Elastic Load Balancing works with the VPC, all the existing network access control lists (network ACLs) and routing tables continue to provide additional network controls.
    • create a load balancer in VPC, specify the load balancer is public (default) or internal.
      • If internal, do not need to have an internet gateway to reach the load balancer, the private IP addresses of the load balancer will be used in the load balancer’s Domain Name System (DNS) record.
  • Enable hybrid load balancing
    • Elastic Load Balancing enables you to load balance across AWS and on-premises resources by using the same load balancer.
    • For example, if you must distribute application traffic across both AWS and on-premises resources, you can register all the resources to the same target group and associate the target group with a load balancer.
    • Alternatively, you can use DNS-based weighted load balancing across AWS and on-premises resources by using two load balancers, with one load balancer for AWS and other load balancer for on-premises resources.
    • You can also use hybrid load balancing to benefit separate applications where one application is in a VPC and the other application is in an on-premises location. Put the VPC targets in one target group and the on-premises targets in another target group, and then use content-based routing to route traffic to each target group.
  • Invoking Lambda functions over HTTP(S)
    • Elastic Load Balancing supports invoking Lambda functions to serve HTTP(S) requests.
    • enables users to access serverless applications from any HTTP client, including web browsers.
    • register Lambda functions as targets and use the support for content-based routing rules in Application Load Balancers to route requests to different Lambda functions. You can use an Application Load Balancer as a common HTTP endpoint for applications that use servers and serverless computing. You can build an entire website by using Lambda functions, or combine EC2 instances, containers, on-premises servers, and Lambda functions to build applications
  • It offers SSL offloading
    • it handles encryption/decryption of traffic.
  • supply an encrypted connection from internet users to AWS load balancers while reducing the admin overhead needed
    • The load balancer needs to be set to accept the HTTPS protocol.
    • require an SSL certificate on the ELB.
    • Load balancer port set to accept 443.
  • enable connection draining
    • the load balancer stop send new requests to the backend instance when instances are de-registering or become unhealthy,
    • but will allow existing requests to be completed while ensuring that in-flight requests continue to be served.
      • means that can perform maintenance
      • such as deploying software upgrades or replacing backend instances, without affecting the customers’ experience.
    • Connection draining is also integrated with Auto Scaling
      • use to manage the capacity behind the load balancer.
      • Auto Scaling will wait for outstanding requests to be completed before it terminates instances.
    • You can enable connection draining through:
      • AWS Management Console, API, CLI, and AWS CloudFormation

Monitor log

Screen Shot 2020-05-09 at 14.36.14

following features to monitor load balancers, analyze traffic patterns, and troubleshoot issues with the load balancers and targets:

  • Amazon CloudWatch metrics
    • Elastic Load Balancing publishes data points to Amazon CloudWatch for the load balancers and the targets.
    • CloudWatch enables retrieve statistics about those data points as an ordered set of timeseries data, known as metrics.
    • use metrics to verify that the system is performing as expected.
    • For example, you can create a CloudWatch alarm to monitor a specified metric and initiate an action (such as sending a notification to an email address) if the metric goes outside what you consider an acceptable range.
  • Access logs
    • use access logs to capture detailed information about the requests that were made to the load balancer
      • store as log files in Amazon Simple Storage Service (Amazon S3).
    • use these access logs to analyze traffic patterns and to troubleshoot issues with the targets or backend applications.
  • AWS CloudTrail logs
    • use AWS CloudTrail to capture detailed information about the calls that were made to the Elastic Load Balancing application programming interface (API)
    • store as log files in Amazon S3.
    • use these CloudTrail logs to determine who made the call, what calls were made, when the call was made, the source IP address of where the call came from, and so on.
This post is licensed under CC BY 4.0 by the author.

Comments powered by Disqus.