### Slide 1: ![Slide 1](slide_1.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 2: ![Slide 2](slide_2.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 3: ![Slide 3](slide_3.png) ::: Notes This slide sets the module context: Example Corp.'s application is experiencing traffic growth and needs to scale. Before covering the tools, ask students to think about what 'mitigating the impact of traffic changes' requires. It involves both scaling resources to meet demand and distributing traffic intelligently — neither alone is sufficient. Scaling without load balancing concentrates traffic; load balancing without scaling eventually runs out of capacity. #### Instructor notes #### Student notes Example Corp.'s new application is experiencing increasing traffic and user demand. You must design a plan to mitigate the impact of changes in application traffic by automating the expansion and contraction of your resources. ::: ### Slide 4: ![Slide 4](slide_4.png) ::: Notes Route 53 and Elastic Load Balancing operate at different layers of the traffic distribution stack. Route 53 routes traffic across regions by directing DNS queries to different endpoints; ELB distributes traffic within a region across multiple targets. Used together, they provide global traffic management and local fault tolerance. Understanding which layer to operate at for a given availability or performance goal requires understanding both services' capabilities and limitations. #### Instructor notes #### Student notes Amazon Route 53 is a cloud DNS web service that is highly available and scalable. The service can distribute traffic across multiple Regions. Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets, including Amazon Elastic Compute Cloud (Amazon EC2) instances, containers, IP addresses, and AWS Lambda functions. ::: ### Slide 5: ![Slide 5](slide_5.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 6: ![Slide 6](slide_6.png) ::: Notes Elastic Load Balancing provides automatic traffic distribution, health-based routing, and multi-AZ availability — but these features are only effective when targets are healthy and correctly configured. The health check integration is the key: a load balancer without properly configured health checks will continue routing traffic to unhealthy targets. Ask students: how would you configure health checks to distinguish between a target that's slow and one that's truly unavailable? #### Instructor notes #### Student notes **High availability** : *ELB* automatically distributes traffic across multiple targets in a single Availability Zone or multiple Availability Zones. Examples of targets include EC2 instances, containers, and IP addresses. **Layer 3, Layer 4, or Layer 7 load balancing** : ELB operates at the application layer (layer 7), the transport layer (layer 4), and the network layer (layer 3) of the OSI model. **Security features** : Use Amazon Virtual Private Cloud (Amazon VPC) to create and manage security groups associated with load balancers to provide additional networking and security options. You can also create an internal (non-internet-facing) load balancer. **Health checks** : ELB can do the following: Detect unhealthy targets, Stop sending traffic to them, Spread the load across the remaining healthy targets. **Monitoring operations** : To monitor the performance of your applications in real time, ELB integrates with Amazon CloudWatch metrics and provides request tracing. ::: ### Slide 7: ![Slide 7](slide_7.png) ::: Notes Choosing the right load balancer type depends on your protocol, performance requirements, and architecture. Application Load Balancer provides rich routing capabilities for HTTP/HTTPS; Network Load Balancer handles high-throughput TCP/UDP with low latency; Gateway Load Balancer integrates third-party appliances. Classic Load Balancer is included for legacy context. The decision involves understanding both your current needs and your architecture's expected evolution — changing load balancer types later requires redeployment. #### Instructor notes #### Student notes ELB supports four types of load balancers: Application Load Balancers, Network Load Balancers, Gateway Load Balancers, and Classic Load Balancers. You can select a load balancer based on your application needs. * **Application Load Balancer** : This load balancer functions at the application layer (Layer 7) of the Open Systems Interconnection (OSI) model. The Application Load Balancer is ideal for advanced load balancing of HTTP and HTTPS traffic. Application Load Balancers support the following: Content-based routing, Applications that run in containers, Open standard protocols (WebSocket and HTTP/2). * **Network Load Balancer** : This load balancer is designed to handle tens of millions of requests per second while maintaining high throughput at ultra-low latency. UDP prioritizes speed and efficiency, which are crucial to cloud operations. Network Load Balancer operates at the connection level (Layer 4), routing connections to targets based on IP protocol data. Targets include EC2 instances, containers, and IP addresses. The Network Load Balancer is ideal for load balancing of TCP traffic. * **Gateway Load Balancer** : This load balancer helps you deploy, scale, and manage your third-party virtual appliances. It provides one gateway for distributing traffic across multiple virtual appliances while scaling them up or down based on demand. This distribution reduces potential points of failure in your network and increases availability. The Gateway Load Balancer transparently passes all Layer 3 traffic through third-party virtual appliances and is invisible to the source and destination of the traffic. * **Classic Load Balancer** : This load balancer provides basic load balancing across multiple EC2 instances and operates at both the request level and connection level. The Classic Load Balancer is for applications that were built in the EC2-Classic network. For more information, see "Elastic Load Balancing Features" at https://aws.amazon.com/elasticloadbalancing/details/#compare. ::: ### Slide 8: ![Slide 8](slide_8.png) ::: Notes This comparison table helps map load balancer capabilities to architectural requirements. Notable differences: Network Load Balancer preserves the client's source IP address, which matters for applications that need to know who's connecting; Application Load Balancer can invoke Lambda functions as targets, enabling serverless architectures. The redirect and fixed-response actions on Application Load Balancer enable HTTP-to-HTTPS redirects and maintenance pages without requiring changes to application code. #### Instructor notes #### Student notes If you need flexible application management, consider an Application Load Balancer. If you need extreme performance and a static IP, consider a Network Load Balancer. If you have an existing application built within the EC2-Classic network, use a Classic Load Balancer. Here's a comparison of the different load balancers. * **Health checks** : ELB can perform the following tasks: Detects unhealthy targets, Stops sending traffic to the unhealthy targets, Spreads the load across the remaining healthy targets. * **CloudWatch metrics** : To monitor performance of your applications in real time, ELB integrates with CloudWatch metrics and request tracing. * **Logging** : Use the Amazon Simple Storage Service (Amazon S3) Access Logs feature to record all requests sent to your load balancer. Logs are stored in Amazon S3 for later analysis. * **SSL offloading** : Instead of the application instance, ELB handles the decryption of traffic. * **Connection draining (deregistration delay)** : ELB stops sending requests to targets that are deregistering. * **Preserve source IP address** : Network Load Balancer preserves the client-side source IP, which allows the backend to review the IP address of the client. Applications can then use the source IP for further processing. * **Static IP support** : Network Load Balancer automatically provides a static IP per Availability Zone (subnet). Applications can then use the static IP as the frontend IP of the load balancer. * **Lambda functions as a target** : Application Load Balancer supports invoking Lambda functions to serve HTTP(S) requests. Users can then access serverless applications from any HTTP client, including web browsers. * **Redirects** : Application Load Balancer can redirect an incoming request from one URL to another URL. * **Fixed-response actions** : With fixed-response actions, you can respond to incoming requests with HTTP error response codes and custom error messages from the load balancer itself. For more information, review "Elastic Load Balancing Features" at https://aws.amazon.com/elasticloadbalancing/details/#compare. ::: ### Slide 9: ![Slide 9](slide_9.png) ::: Notes The load balancer, listener, target group, and target model separates concerns clearly: the load balancer handles traffic entry; listeners define which traffic to accept; target groups define where to send it; targets receive it. Content-based routing — using listener rules to send different paths to different target groups — is a powerful capability but also a source of misrouting bugs when rules overlap or conflict. Rule priority and default rules determine how ambiguous requests are handled. #### Instructor notes #### Student notes A *load balancer* serves as the single point of contact for clients. The load balancer distributes incoming application traffic across multiple targets, such as EC2 instances, in multiple Availability Zones to increase the availability of your application. A load balancer works with listeners. You can have more than one listener per load balancer. A *listener* checks for connection requests from clients using the protocol and port that you configure. The load balancer then forwards requests to one or more target groups based on the rules that you define. Each rule specifies a target group, condition, and priority. When the condition is met, the traffic is forwarded to the target group. You must define a default rule for each listener. You can add rules that specify different target groups based on the content of the request (also called content-based routing). Each *target group* routes requests to one or more registered targets, such as EC2 instances, using the specified protocol and port number. 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 your load balancer listener rule. The diagram illustrates the essential components. Each listener contains a default rule. One listener contains another rule that routes requests to a different target group. One target is registered with two target groups. For more information, see "What Is an Application Load Balancer?" in Elastic Load Balancing Application Load Balancers at https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html. ::: ### Slide 10: ![Slide 10](slide_10.png) ::: Notes Health check configuration determines how quickly the load balancer detects and responds to unhealthy targets. Thresholds that are too sensitive remove targets from rotation during brief slowdowns; thresholds that are too lenient allow unhealthy targets to continue receiving traffic. The interval, timeout, healthy threshold, and unhealthy threshold must be calibrated together: a misconfigured combination can cause a target to be marked unhealthy before it's had time to recover from a transient issue. #### Instructor notes #### Student notes Load balancers also perform health checks on each target. Each load balancer node checks the health of each target using the health check settings for the target group. The two types of health checks are active and passive. **Active** : With active health checks, the load balancer periodically sends a request to each registered target to check its status. Each load balancer node checks the health of each target. It does this by using the health check settings for the target group with which the target is registered. After each health check is completed, the load balancer node closes the connection established for the health check. **Passive** : With passive health checks, the load balancer observes how targets respond to connections. Passive health checks enable the load balancer to detect an unhealthy target before it is reported as unhealthy. You cannot disable, configure, or monitor passive health checks. Passive health checks are not supported for UDP traffic. Health check settings include: * **Protocol** : The protocol to use to connect with the instance. * **Path** : The destination for the HTTP or HTTPS request. * **Port** : The port used to connect with the instance. * **Healthy threshold** : The number of consecutive successful health checks that must occur before declaring an EC2 instance healthy. * **Unhealthy threshold** : The number of consecutive failed health checks that must occur before declaring an EC2 instance unhealthy. * **Timeout** : The amount of time to wait, in seconds, when receiving a response from the health check. * **Interval** : The amount of time between the health checks of an individual instance, in seconds. For more information, see "Health Checks for Your Target Groups" in Elastic Load Balancing Network Load Balancers at https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html, "Health Checks for Your Target Groups" in Elastic Load Balancing Application Load Balancers at https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html, and "Configure Health Checks for Your Classic Load Balancer" in Elastic Load Balancing Classic Load Balancers at https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-healthchecks.html. ::: ### Slide 11: ![Slide 11](slide_11.png) ::: Notes CloudWatch metrics for load balancers provide visibility into request rates, error rates, and latency, which are the key signals for detecting availability and performance problems. HTTP status code categories — 2xx, 4xx, 5xx — indicate where errors originate: 4xx errors suggest client-side issues (bad requests, authentication failures); 5xx errors suggest server-side failures that may indicate unhealthy targets. Distinguishing between these is the first step in effective load balancer troubleshooting. #### Instructor notes #### Student notes Use CloudWatch to retrieve statistics about data points as an ordered set of time series data, called metrics. A metric is a variable to monitor, and the data points are the values of that variable over time. For example, you can monitor the total number of healthy targets for a load balancer over a specified period. Each data point has an associated timestamp and an optional unit of measurement. You can use metrics to verify that your system is performing as expected. For example, you can create a CloudWatch alarm to monitor a specified metric. The alarm can initiate an action if the metric goes outside what you consider an acceptable range. An example action is sending a notification to an email address. The following are HTTP code responses for troubleshooting load balancers: * HTTP 2xx = Successful request * HTTP 4xx = Client-side error * HTTP 5xx = Server-side error For more information, see "CloudWatch Metrics for Your Application Load Balancer" in Elastic Load Balancing Application Load Balancers at https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html and "CloudWatch Metrics for Your Network Load Balancer" in Elastic Load Balancing Network Load Balancers at https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html. ::: ### Slide 12: ![Slide 12](slide_12.png) ::: Notes Load balancer access logs capture every request sent to the load balancer, stored in S3 in compressed format. This granular data is invaluable for security analysis, compliance auditing, and troubleshooting specific request failures. The trade-off is storage cost and analysis overhead — logs accumulate quickly at high traffic volumes and require tooling to analyze effectively. Consider whether you need full request logs or whether CloudWatch metrics and CloudTrail API logs are sufficient for your use cases. #### Instructor notes #### Student notes You can use the access logs feature to record all requests sent to your load balancer. The feature stores the logs in 5-minute intervals in Amazon S3 for later analysis. The logs are compressed and have a gzip file extension. The compressed logs save both storage space and transfer bandwidth. They are also useful for diagnosing application failures and analyzing web traffic. You can also use AWS CloudTrail to record Application Load Balancer API calls for your account and deliver log files. Use the API call history to perform security analysis, resource change tracking, and compliance auditing. For more information, see "Access Logs for Your Application Load Balancer" in Elastic Load Balancing Application Load Balancers at https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html. ::: ### Slide 13: ![Slide 13](slide_13.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 14: ![Slide 14](slide_14.png) ::: Notes Route 53 enables global traffic distribution by routing DNS queries to different endpoints based on routing policies. However, DNS has inherent latency characteristics that affect failover speed: DNS TTLs determine how long clients cache resolution results, which means that even after Route 53 marks an endpoint as unhealthy, clients may continue routing to it until their cached records expire. Short TTLs improve failover speed but increase DNS query volume and cost. #### Instructor notes #### Student notes By using ELB and auto scaling, you can achieve highly flexible, scalable, and resilient architectural designs. But what if you want to distribute traffic across Regions? Reasons for distributing traffic across Regions include disaster recovery (DR) for widespread outages and reduced latency (providing services closer to the location of users). Route 53 is a highly available and scalable cloud DNS web service. It is designed to give developers and businesses a reliable and cost-effective way to route users to internet applications. Route 53 can achieve this by translating names, such as www.example.com, into the numeric IP addresses that computers use to connect. Route 53 connects user requests to infrastructure running on AWS, such as EC2 instances, load balancers, or S3 buckets. Route 53 can also route users to infrastructure outside of AWS. You can use Route 53 to do the following: * Configure DNS health checks to route traffic to healthy endpoints. * Monitor the health of your application and its endpoints. * Manage traffic globally through a variety of routing types, including latency-based routing, geo DNS, and weighted round-robin. You can combine these routing types with DNS failover to provide a variety of low-latency, fault-tolerant architectures. Route 53 also offers domain name registration. You can purchase and manage domain names, such as example.com, and Route 53 automatically configures DNS settings for your domains. ::: ### Slide 15: ![Slide 15](slide_15.png) ::: Notes Route 53 alias records extend DNS to point directly to AWS resources like load balancers and S3 buckets, with no additional charge for alias queries. The key advantage over CNAME records is that aliases can be created for the root domain (apex) — which standard DNS CNAMEs don't support. This is important for organizations that want to route their root domain (not just www) directly to a load balancer without using intermediate workarounds. #### Instructor notes #### Student notes To route domain traffic to an ELB load balancer, use Route * 53 to create an alias record that points to your load balancer. An alias record is a Route * 53 extension to DNS. Route 53 alias record compared with DNS CNAMEThe Route 53 alias is similar to a Canonical Name Record (CNAME). However, you can create an alias record both for the root domain, such as example.com, and for subdomains, such as www.example.com. You can create CNAME records only for subdomains. In addition, Route * 53 doesn't charge fees for alias queries to ELB load balancers or other AWS resources.For more information, see "Routing Traffic to an ELB Load Balancer" in the Amazon Route 53 Developer Guide at https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html. ::: ### Slide 16: ![Slide 16](slide_16.png) ::: Notes Route 53 health checks determine when failover routing activates by monitoring endpoint health, other health checks, or CloudWatch alarms. The health check configuration — protocol, path, thresholds — must be calibrated to match your application's normal behavior. A health check path that requires database access or session state may fail for reasons unrelated to the endpoint's availability, triggering unnecessary failovers. Choose health check endpoints that are lightweight and reflect actual service availability. #### Instructor notes #### Student notes Note: This is not a screenshot from the Route 53 console. It is a representation of the options that you will need to configure for Route 53 health checks.Route * 53 health checks monitor the health and performance of your web applications, web servers, and other resources. When you create or update health checks, specify the following values:What to monitor:Endpoint -- Monitors the health of a specified endpoint. You can specify the endpoint by providing a domain name or an IP address and a port.Other health checks -- Determines whether this health check is healthy based on the status of other specified health checks. You also specify how many of the health checks must be healthy for this health check to be considered healthy.CloudWatch alarm -- Determines whether this health check is healthy by monitoring the data stream for a CloudWatch alarm.Monitoring an endpoint:Protocol -- The method that you want Route * 53 to use to check the health of your endpoint.IP address -- The IPv4 or IPv6 address of the endpoint.Port -- The endpoint port on which you want Route * 53 to perform health checks.Path (HTTP and HTTPS protocols only) -- The path you want Route * 53 to request when performing health checks. The path can be any value for which your endpoint returns an HTTP status code of 2xx or 3xx when the endpoint is healthy. An example is the file /docs/route53-health-check.html.For more information, see "Values That You Specify When You Create or Update Health Checks" in the Amazon Route 53 Developer Guide at https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-values.html. ::: ### Slide 17: ![Slide 17](slide_17.png) ::: Notes Route 53 routing policies give you control over how traffic is distributed globally, each with different trade-offs. Weighted routing enables gradual traffic shifts for deployments; latency routing optimizes user experience by routing to the closest healthy region; failover routing provides active-passive disaster recovery. Geolocation routing adds compliance and data sovereignty options but requires careful fallback configuration — requests from locations not covered by specific rules must have a default route. #### Instructor notes #### Student notes Route 53 has the following routing policies:Simple routing policy -- Use for a single resource that performs a given function for your domain, for example, a web server that serves content for the example.com website.Weighted routing policy -- Use to route traffic to multiple resources in proportions that you specify.Latency routing policy -- Use when you have resources in multiple Regions, and you want to route traffic to the Region that provides the lowest latency.Failover routing policy -- Use when you want to configure active-passive failover.Geolocation routing policy -- Use when you want to route traffic based on the location of your users (DNS query location).Geoproximity routing policy -- Use when you want to route traffic based on the location of your resources. Use this policy if you want to shift traffic from resources in one location to resources in another (traffic flow to Region or latitude or longitude).Multivalue answer routing policy -- Use when you want Route 53 to respond to DNS queries with up to eight healthy records selected at random. ::: ### Slide 18: ![Slide 18](slide_18.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 19: ![Slide 19](slide_19.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 20: ![Slide 20](slide_20.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 21: ![Slide 21](slide_21.png) ::: Notes HTTP 4xx errors from a load balancer indicate client-side issues: malformed requests, missing authentication, or timeout conditions. These errors often appear in monitoring as load balancer errors, but the root cause is either the client's behavior or the load balancer's configuration (timeout settings, authentication requirements). Distinguishing between a client misconfiguration and a load balancer misconfiguration requires examining the specific error code and the request details in the access logs. #### Instructor notes #### Student notes The troubleshooting scenario in this example produces HTTP 4XX class status codes that need to be addressed on the client side. A bad request sent to a load balancer doesn't meet the HTTP specification or a header has exceeded limits. If a user hasn't been authenticated, they receive an unauthorized request. If the load balancer time out is too short or a client doesn't receive at least 1 B of traffic in 60 seconds, they will get a request timeout error.For more information, see "The Load Balancer Generates an HTTP Error" in Elastic Load Balancing, Application Load Balancers at https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#load-balancer-http-error-codes. ::: ### Slide 22: ![Slide 22](slide_22.png) ::: Notes #### Instructor notes #### Student notes ::: ### Slide 23: ![Slide 23](slide_23.png) ::: Notes #### Instructor notes #### Student notes :::