Episode 5: Load Balancers, Health Checks & Cross-Zone Balancing | AWS SAA-C03

Hey everyone, Balu here. Welcome back to Tech Talk with Balu. Your complete guide passing the AWS Solutions Architect Associate Exam. We are now on episode 5 and today we are diving deep into one of the most critical services for building high available applications. It's called the Elastic Load Balancing or ELB for short. By the way, if you've been listening to my podcast and it has been beneficial for you, please do drop a follow. That means a lot to me. Now here's why ELB matters. Every production application on AWS should be using a load balancer. I'm not exaggerating. If you're running a single EC2 instance serving traffic directly, you're doing it wrong. One server failure and your entire application goes down. Load balancers are the foundation of high availability and scalability. They distribute traffic, detect failures and seamlessly route around problems. And on the exam, they show up everywhere. So today we are covering what load balancers are and why they're essential. We're covering application load balancer. That's the smart, less seven load balancer. We are covering the network load balancer. That's the ultra high performance layer four option. We're covering the gateway load balancer. That's the new key on the block. We're covering the target groups and health checks. We are covering the crow zone load balancing. That's a critical exam trap. We are covering SSL, TLS, termination and SNI. We are covering sticky sessions and connection training. And finally, we will end with some real world architecture patterns. By the end of this episode, you will know exactly when to use what kind of load balancer, how to configure them properly and how to avoid the exam traps that trip people up. So let's dive in. Alrighty, let's start with the fundamentals. What exactly is a load balancer? So load balancer is a server that sits in front of your application service and distributes incoming traffic across multiple service. Think of it like a host at a busy restaurant. You walk in and instead of choosing your own table, the host directs you to an available table. They balance the customers across all the tables. So no single server gets overvalued while others sit empty. So why do load balancers exist in the first place? And what are the core problems they solve? Problem one, single point of failure. You have one easy to instance running your application. Then it crashes. Your entire website goes down every user season error. You're losing money every second with the load balancer and multiple instances. If one instant crashes, the load balancer automatically stops sending traffic to it and routes everything to the healthy instances. Your users never notice. Problem two, limited capacity. Your application normally gets about 1000 requests per second and one day you're mentioned on Twitter and suddenly now you're getting about 50,000 requests per second. Your single instance can't handle it. It slows to a crawl or crashes completely. Now with the load balancer, you can horizontally scale and more instances behind the load balancer, it automatically then distributes the 50,000 requests across all your instances and each instance handles a manageable load. Problem three, maintenance and updates. You need to update your application. Now with the single instance, you will have to take it down, update it, and bring it back up. There is a downtime. With the load balancer and multiple instances, you can do what we call rolling updates. Update one instance, the load balancer stops sending it traffic, update finishes, bring it back up, repeat for other instances, there is literally zero downtime. A real well example is Netflix. Netflix uses load balancers extensively. They have thousands of instances serving streaming video when an instant fails or needs maintenance. Load balancers seamlessly route traffic to the healthy instance. That's why you never experience downtime when you're watching shows. Now elastic load balancer is an AWS managed service. AWS provides ELB as a fully managed service and this is huge. Now what does managed mean? What it means is AWS guarantees that the load balancer will be working. It handles all its upgrades and maintenance. AWS ensures high availability of the load balancer itself. You just have to configure it and it works. So could you run your own load balancer on EC2? And the answer is yes, technically, but then you have to ensure high availability of the load balancer. You have to handle its updates and patches, keep monitoring it, maintaining it, and scale it as your traffic grows. But with elastic load balancing, AWS handles all of that. You just have to focus on your application. So now let's look at the cost consideration. ELB costs money. It's not free, but it's generally cheaper than the operational overhead of managing your own load balancers. Plus downtime costs way more than ELB costs. For the exam, know this. The AWS recommendation is to always use elastic load balancers for production workloads, not custom load balancers. So how does this integrate with other AWS services? ELB integrates seamlessly with auto scaling groups, automatically register the registers instances. It integrates with ECS. That's container-based applications. It integrates with AWS certificate manager. So that's your SSL, TLS certificates. It integrates with cloud wash. That's monitoring and metrics. We talked about earlier. It integrates with route 53. We also talked about this. That's DNS integration. It integrates with WAF. That's web application firewall for security. And it integrates also well with global accelerator. That's global traffic acceleration. This deep integration is why ELB is so very powerful. So now let's look at the different types of load balancers. AWS offers four types of load balancers and let me break them down for you. Number one, classic load balancer. CLB. That's the legacy option. It was launched in 2009. This is the V1. That's the old generation of load balancer. It supports HTTP and HTTPS. That's last seven and TCP and SSL. That's layer four. Now should you be using it? The answer is no, unless you have a legacy application that requires it. You don't use normally classic load balancers for new projects. And the reason to that is that it lacks features that newer load balancers have. So there's no advance routing, no web socket, no HTTP, no server name indication for multiple SSL certificates and so on. For the exam, classic load balancer is not recommended for new applications. If a question asks you about a new application, the answer is ELB or NLB. Not CLB, not classic load balancer. Remember that. Next, let's look at the application load balancer or the ELB. This is the smart HTTP load balancer. It was launched in 2016. This is the V2 generation and the most commonly used load balancer. It operates at level seven. That's the HTTP or the HTTPS level. So what are its key features? So there is content-based routing. Multiple applications can run on the same load balancer. There is support for HTTP to and web socket. It redirects that's HTTP to HTTPS and it's perfect for microservices and containers. Some of the use cases are web applications, API, microservices, so forth. For the exam, if the question mentions HTTP, HTTPS, web applications, microservices, or containers, the answer is application load balancer. Next, let's look at the network load balancer or the NLB. This is the ultra-performance option. It was launched in 2017. This is also a version 2 generation. It operates at level four. That's the TCP, UDP, TLS level. What are its key features? It's got extreme performance. That's it can cater for millions of requests per second. It's got ultra low latency. That's microseconds instead of milliseconds. Static IP addresses, so there's one per availability zone. Can assign elastic IPs to it and it preserves source IP addresses. What are its use cases? Gaming servers, IoT, real-time bidding, financial applications where latency matters. So for the exam, the question mentions extreme performance. Millions of requests low latency, static IP, or TCP, UDP traffic. The answer is network load balancer. Number four, we look at gateway load balancer, GWLB. This is the security appliance load balancer. It was launched in 2020 and this is the newest. It operates at layer three. That's the network layer IP packets. What is it for? It's for deploying and managing third-party network virtual appliances. Common example use cases are for managing firewalls, intrusion detection and prevention systems, and for deep-pocket inspection systems. How does it work? So all traffic flows through the GWLB to security appliances then to your application. So for the exam, if the question mentions third-party security appliances, firewall fleet, or intrusion detection, you know the answer is gateway load balancer. This is much less common in the exam than the ALB. and the NLB. So now let's look at a comparison table as in which load balancer would you want to choose. So if you wanted to look at layer 7 that's HTTP or HTTPS traffic that is going to be the ALB. If it's layer 4 which is TCP or UDP traffic that is going to be the NLB. If extreme performance is needed that's again the NLB. If multiple SSL certificates are required on one load balancer that the answer is going to be ALB or NLB not CLB. If microservices or containers are required then you want to go for ALB. If static IP is required it's again NLB. Security appliances that would be GWLB and for legacy applications you want to use CLB. But remember migrate that to ALB or NLB if possible. Let's now look at an exam trap which load balancer should be used. The example describe a scenario and ask which load balancer to use. Look for the keywords. If it mentions HTTP routing, path-based routing, host-based routing then you know it's the ALB. If it mentions TCP traffic, UDP traffic, static IP then it's the NLB. Millions of requests per second or sub-mily second latency that is again the NLB. Security appliances or intrusion detection that would be the GWLB. Now let's dive deep into the application load balancer because this is the most tested on the exam. It's operating at level 7 so you know ALB operates at level 7 which is the HTTP protocol layer. This means it understands HTTP requests. You can see the URL path that's whether it's a slash user versus the slash products. It can see the host name that's api.example.com versus let's say web.example.com. It can query strings whether it's the ID or a sort string. It can query the headers whether it's user agent, content type, custom editor, so and so forth. Now this is powerful because it enables intelligent routing. So now let's look at the advanced routing which is the killer feature of this ELB. ELB can route traffic to different target groups based on the requested content. So let's look at path based routing first. So if you had a website called example.com/users what it could do is to route to the user service target group. If you had example.com/products then it could route to the product service target group and if you had example.com/search it could route to the search service target group. Do you see this? It's one load balancer, multiple applications and this is perfect for microservices. Let's look at a real world example. You're building an e-commerce site with microservices architecture. User service handles the authentication and profiles. Product service handles product catalog or the service handles shopping cart and checkout and search service handles product search. Now instead of four separate load balancer you can just use one application load balancer with path based routing. That is if the core was to API/user/star then you route it to user service. If that was to product/star then you route it to product service. If it's orders you route it to order service search you route it to search service so and so forth. So that's one load balancer one SSL certificate one DNS entry and multiple services all achieved through the ALB. Now let's look at host based routing. That's host name routing. So it's basically different host names route to different target groups. For instance users.example.com you could route that to user service API.example.com could then be routed to API service so and so forth. So now for a real world example your company has multiple applications on different subdomains. app.yourcompany.com would be your main application API.yourcompany.com would be the public API admin.yourcompany.com would be the admin dashboard. You could use one ALB with host name based routing that handles all the three. Next let's look at query string and header based routing. So for example if you had an application that could be run in two platforms let's say on the mobile and on your desktop you could then base on the header and then route it accordingly to a mobile target group or a desktop target group. So use case would be serving different versions of your app like I said to mobile phone or desktop users. So next let's look at what target groups are. This is where the traffic goes. A target group is a collection of resources that receive traffic from the load balancer. ALB can route to these target types. Number one easy to instances. This is the most common. Your application runs on easy to and ALB can route to those instances. Number two ECS tasks for containerized applications. ALB routes directly to the containers. Number three lambda functions. Yes you can route HTTP requests directly to lambda functions. The ALB translates the HTTP request into a JSON event for lambda. The use cases are serverless APIs. There is no easy to instances needed there. Number four IP addresses. Private IP addresses including on premises service. The use cases are hybrid architectures. ALB can route to resources in your data center. ALB can also route to multiple target groups based on the routing rules. An example architecture would be as default route to primary EC2 target group. But when queried with API slash V2, then route the new API version. That's lambda function. If queried for legacy slash star, then route to an on premises service. That's based on IP address. So that's one ALB. Three different target groups. Three different backend types. How cool is that? Now let's look at the health checks that happen for these different target group levels. Each target group has its own health check configuration. Let's look at an example. So for protocol HTTP on port 80, the path would be slash health. The healthy threshold would be two consecutive successes. An unhealthy threshold would be three consecutive failures. The interval would be every 30 seconds and the timeout would be five seconds. So if an instant fails, the health checks, ALB stops routing traffic to it automatically. Let's now look at connection termination. This is very important for the exam. ALB terminates the connection from the client and creates a new connection to the backend. What this means is the backend server doesn't see the client's IP address directly and the backend sees ALB's private IP address. So how to get the client's real IP? The ALB inserts it into the HTTP headers. Remember that. X-forwarded 4 would have the client's IP address. X-forwarded port would have the original port. X-forwarded proto would have the original protocol that's whether it's HTTP or HTTPS. Now onto an exam question. An application behind an ALB needs to log the client's IP address for security auditing. How should this be done? The wrong answer is to get the source IP from the TCP connection. That's the ALB's IP, not the source IP. So the right answer is to read from the X-forwarded 4 header. This comes up all the time on the exam. Now let's look at HTTP2 and web socket support. ALB supports HTTP2 which allows multiple requests over a single connection. That's more efficient. ALB also supports web socket which allows persistent bidirectional communication. That's perfect for chat applications, real-time updates and gaming. Classic load balancer doesn't support these. This is why you don't use CLB anymore. Now onto fixed hostname. When you create an ALB, you get a fixed DNS hostname. This hostname never changes. You point your route 53 domain to this hostname using an alias record. The IP addresses behind this hostname can change and AWS manages all this. You don't have to worry, but the hostname stays the same. So for the exam, you cannot assign a static IP to an ALB. Remember that. If the question requires a static IP address, you need a network load balancer, not ALB. So one more final point is that ALB can redirect requests. The most common use case is HTTP to HTTPS redirect. Users can access your site via HTTP, let's say example.com, and ALB automatically redirects them to HTTPS example.com. This is configured at the listener level. No code is needed in your application to do that. So onto an exam scenario. A company wants all HTTP traffic to automatically redirect to HTTPS. Where should this be configured? The answer is to configure an HTTP to HTTPS redirect rule on the application load balancer listener. Now let's talk about network load balancer. This is for when you need extreme performance. It operates at layer 4, which is the TCP or UDP transport layer that you use. Unlike ALB, it doesn't understand HTTP. It just sees TCP UDP packets and just forwards them. This is actually an advantage for performance. Less processing means lower latency. ALB is designed for millions of requests per second ultra low latency kind of requirements that's microseconds instead of milliseconds and for high throughput applications. So for some real world numbers here ALB can process up to about 50,000 requests per second per load balancer. We'll have approximately millisecond latency, whereas NLB processes millions of requests per second with microsecond latency. See the difference. So what are the use cases of NLB? These are for gaming servers where every millisecond of latency matters for financial training systems processing millions of transactions or IoT applications with millions of devices and for real time bidding platforms where latency is key. Now one key thing to remember for the exam is NLB provides one static IP address per availability zone. So if you deploy NLB in three A's you get three static IP addresses. Even better you can assign your own elastic IP addresses to the NLB. Now why does this matter? Some clients have firewalls that only allow traffic to specify IP addresses. That's IP white listing. With LB the IP addresses can change. You had had to white list DNS names which doesn't always work. With NLB you get static IPs. Clients can white list those IPs permanently. Now onto an exam scenario. A client requires the company to white list specific IP addresses in their firewall which load balancer should they use. The answer is network load balancer because it provides static IP addresses. You can also assign elastic IPs to it. The answer is not ALB because it doesn't have static IPs. So now if you recollect with the ALB the backend sees the load balancer's IP. Whereas with NLB the backend sees the actual client's IP address. This is important. It preserves the source IP address. This is useful for security applications that need to know what its real client IP address is like geographical restrictions rate limiting based on source IP. These kind of use cases creep up where you want to use NLB for. So now let's look at the target types for NLB. You can use easy to instances that's the most common. IP addresses private IPs for hybrid kind of architectures or you can use application load balancer. Yes you can chain them. You can also use NLB in front of ALB. That's a common pattern and why would you do this? NLB provides static IPs for client white listing whereas ALB provides intelligent HTTP routing. The use case is client needs static IPs but you also need path-based routing and the solution is to use NLB, ALB on the target groups. From a health check perspective NLB supports TCP, HTTP and HTTPs health checks. For TCP just checks if the port is open for HTTP, HTTPs it can check a specific path like slash health. Now what are the protocols supported? NLB supports TCP, UDP and TLS that's sec and TLS that's secure TCP. Now on to connection handling. Unlike ALB, NLB does not terminate connections. It forwards the TCP connection directly to the target. This is called pass through load balancing. What are the advantages? Low latency, no connection termination or reestablishment happening there. The disadvantage is it can't modify requests or insert headers. An exam trap, an application needs to read the x-forwarded for header to get the client IP. Should it use ALB or NLB? The answer is ALB, NLB does not insert headers because it does not simply understand HTTP. It operates at layer 4. Remember that. So now let's discuss health checks. Health checks are absolutely critical. This is how load balancers know which targets are healthy and can receive traffic. So how does health checks work? The load balancer periodically sends requests to each target. If the target responds successfully it's healthy. If the target fails to respond or responds with an error it's unhealthy. What are the health check configurations? So you configure from a protocol level HTTP, HTTP, TCP or GRPC. For HTTP, HTTP, the load balancer sends an HTTP get request. For TCP, the load balancer just checks if the port is open. For the port, which port to check? Usually the same port your application listens on. Example your app runs on port 80. Health check port is then port 80. For the path for HTTP and HTTPS, which you are all part to check. The common ones are like slash health or slash health check. Your application should have a health endpoint that returns 200. Okay, if healthy. What about the interval? How often to check? The default is 30 seconds. You can set it as low as 5 seconds. It costs more though or as high as 300 seconds. Time out. How long to wait for a response? Again, default is 5 seconds. If the target doesn't respond within the timeout, it's considered a failed check. What's a healthy threshold? That's how many consecutive successful checks before considering the target healthy. The default is 3 consecutive successes. The unhealthy threshold, that's how many consecutive failed checks before considering the target unhealthy. The default is 2 consecutive failures. So an example configuration would look like, let's say protocol HTTP port 80 path slash health interval 30 seconds. Time out 5 seconds. Healthy threshold 3 and unhealthy threshold 2. What happens is every 30 seconds, the load balancer sends a get slash health to each target. If the target response with 200 okay within 5 seconds, it's a success. If the target fails to consecutive checks, it's marked unhealthy. That's no traffic is then sent. If an unhealthy target passes 3 consecutive checks, it's marked healthy. That means traffic is resumed. So what should your health end point check? You have to be very careful there. A bad health endpoint might just get the request and return 200 okay straight away. Though the application might be broken. So a better health endpoint would then check the database connection, look at critical dependencies, look at all the checks you need to do and if everything is healthy, you only then return 200 okay. If anything else is broken, then you return 503 which is service unavailable. This actually verifies your application can now serve requests. On to a real world example. What would an e-commerce applications health endpoint checks look like? So database connection can be connected to the product database. Cash connection is retis responding okay. Critical API can be reached to the payment gateway. If all of these fail, then return a 503. Load balancer marks the instance unhealthy and stops sending it traffic. Now on to an exam scenario question. An easy to instance is running but not responding to requests. How will the load balancer handle this? The answer is hellcheck will fail. After n consecutive failures, that's the unhealthy threshold. The load balancer will stop sending traffic to that instance. If using auto scaling, ASG can terminate and replace it. An important example point is that when you attach a load balancer to an auto scaling group, ASG can use ELB health checks instead of EC2 health checks. EC2 health check checks if the instance is running which is a VM level kind of feature. ELB health checks on the other hand checks if the application is actually responding that's at the application level. ELB health checks are better because they detect application failures not just instance failures. Exam question. Instances in an auto scaling group are running but the application on them has crushed. How can ASG detect this and replace the instances? The answer is to configure the auto scaling group to use ELB health checks instead of EC2 health checks. Then ASG will terminate that instance that fail the ELB health checks. Let's now look at cross zone load balancing. This is a critical exam topic and it trips people up constantly so please pay close attention. The problem. You have a load balancer in two available zones. AZ1, load balancer plus node plus two EC2 instances and in AZ2 you have a load balancer node plus eight EC2 instances so a total of 10 instances but distributed unevenly. How should traffic be distributed in this case? Now without cross zone load balancing each load balancer node distributes traffic evenly among instances in its own AZ only. So the result is AZ1 receives 50% of the total traffic because there are two load balancer nodes. This 50 person is split among the two instances. Each instance then gets 25% of the total traffic and what happens to AZ2 that receives 50% of the total traffic. This 50% is split among eight instances. Each instance gets 6.25% of the total traffic. The two instances in AZ1 are each handling 25% of the traffic. The eight instances in AZ2 are each handling 6.25% that's a massive imbalance right there. Now with cross zone load balancing, each load balancer node distributes traffic evenly across all instances in all Asis. The result is there is 100% of traffic distributed evenly across all the 10 instances, each instance then receives 10% of the traffic. That's perfect balance regardless of how instances are distributed across Asis. So why does this matter? And even distribution leads to number one some instances being overloaded, number two some instances being underutilized, number three that's inefficient resource usage and number four potential performance issues. So cross zone load balancing solves all of this. So next now let's look at the default settings by load balancer type. This is critical for the exam too. Application load balancer ALB, cross zone load balancing that's enabled by default can be disabled at the target group level. No charges for inter AZ data transfer. Network load balancer that's NLB, cross zone load balancing that's disabled by default it can be enabled and UP charges for inter AZ data if enabled. Kadeve load balancer GWLB, cross zone load balancing it's disabled by default it can be enabled UP charges for inter AZ data if enabled and finally classic load balancer CLB, cross zone load balancing is disabled by default also it can be enabled but there are no charges for inter AZ data. Now for an exam question pattern. A company notices uneven traffic distribution across instances in different Asis behind a network load balancer. What could be the cost? The answer is cross zone load balancing is disabled by default for NLB, enable it to distribute traffic evenly across all your Asis. So the keyword NLB plus uneven traffic then you know cross zone is disabled you want to enable that. Now for another exam trap question. What's the cost implication of enabling cross zone load balancing? The answer it depends on the load balancer type. For ALB no additional cost it's enabled by default. For NLB and GWLB data transfer charges for inter AZ traffic takes place. For NLB or GWLB data transfer charges for inter AZ traffic is applicable for CLB there is no additional cost. So real world recommendation would be is to always enable cross zone load balancing unless you have a specific reason not to. The cost for NLB or GWLB is usually worth it for even traffic distribution. Now for the next section let's talk about SSL or TLS and SNI. SSL or TLS termination and Serviname indication this is heavily tested on the exam. So what are its basics? So SSL stands for Secure Sockets Layer and TLS is Transport Layer Security. They are encryption purgols. They encrypt data in transit between the clients and the servers. HTTPS is HTTP over SSL or TLS. So consider this example when you visit HTTPS example.com the connection is encrypted using TLS. So now instead of terminating TLS at your EC2 instances you can terminate it at the load balancer. How does it work? Clined to HTTPS which is encrypted to load balancer to HTTP which is unencrypted to the backend instances. The load balancer handles all the TLS encryption or decryption your backend instances just deal with plain HTTP. The benefits are you offload encryption work from backend instances. You manage certificates in one place that's the load balancer. It's simpler backend configuration and better performance. Load balancers have dedicated hardware for encryption. Now where do these certificates come from? You can use AW certificate manager that's ACM to provision free SSL or TLS certificates. ACM automatically handles certificate renewal. You never have to worry about expired certificates. You attach ACM certificates to your load balancer listeners. So what you do is you attach ACM certificates to your load balancer listeners. Now listeners and SSL certificates. A listener is a process that checks for connection requests on a specific port. For example is that you have listener one at port 80 that's a CTP and that redirects to HTTPS and then you have listener two that's listening to port 443 that's HTTPS that forwards to a target group. The HTTPS listener needs an SSL certificate. So now let's look at multiple SSL certificates server name indication SNI. The whole problem you have one server one IP address one SSL certificate. So if you wanted to host example.com and example two.com on the same server you needed two IP addresses and two service. SNI now solves this. SNI allows one server to have multiple SSL certificates and serve multiple domains. This is how it works. So first step is client connects and says I want to talk to www.example.com server then looks at the host name in the request. Server selects the correct SSL certificate for www.example.com and then the handshake continues with the certificate. So what SNI support is available for the load balances. Let's look at that. ALB supports SNI. NLB supports SNI. ALB and NLB support SNI. Whereas CLB does not support SNI. An exam scenario. A company is to host api.example.com and web.example.com behind the same load balancer each with its own SSL certificate which load balancer should they use. The wrong answer is classic load balancer that doesn't support multiple certificates. So the right answer is application load balancer or network load balancer both support SNI. Now how do you handle multiple SSL certificates on ALB? You can attach multiple certificates to a single ALB. For example you could have certificate one for www.example.com. You can have certificate two for api.example.com and you can have certificate three for admin.example.com. The ALB uses SNI in this case to select the correct certificate based on the host name the client requests. Now onto a real world use case. You're running a SaaS platform. Each customer gets their own subdomain. Customer one dot your app dot com. Customer two dot your app dot com and customer three dot your app dot com. Each needs its own SSL certificate. One ALB with SNI can handle all of them. One load balancer for all your customers. Next let's look at end to end encryption. If you need encryption all the way from client to backend instances not just client to load balancer you can do this. Clined to HTTPS to load balancer to HTTPS to backend instances. The load balancer still terminates the client's dealers connection but it establishes a new encrypted connection to the backend. The use cases are compliance requirements that mandate encryption at all stages. An exam question. A company must ensure data is encrypted in transit from the client to the application service. How should this be configured? The answer is configure HTTPS listener on the load balancer with an SSL certificate and then configure the backend instances to accept HTTPS connections. Now this provides end to end encryption. Next let's look at sticky sessions. Sticky sessions also called session affinity is yet another important feature. What's the problem? Your application stores session data in memory on each instance. Example the user logs in instance one stores user is logged in in memory. Next request from the same user goes to instance two. Instance two now doesn't have the session data the user appears logged out. This is a problem. So solution one using sticky sessions. So what we do is configure the load balancer to always send requests from the same client to the same instance. So this is how it works. Users first request goes to the instance one. Load balancer then generates a cookie and sends it to the user. User subsequent requests include this cookie. So load balancer sees this cookie and always routes to instance one. The user technically sticks to instance one for the duration of the session. Now sticky session configuration. How would you configure that? Duration how long the cookie is valid which is in seconds and then you would configure the cookie name that's for the application control cookies. Now what are the different cookie types? There is duration based cookies. This is generated by the load balancer. Load balancer generates this cookie. Cookie name is called AWS ALB for ALB or AWS ELB for CLB and you just set the duration. Then there is application based cookies. That's your application generates a custom cookie. Load balancer uses this cookie for stickiness and the cookie name is your choice but not AWS ALB or AWS ALB app or AWS ALB TG. These are all reserved and then there is the load balancer generated application cookie. Load balancer generates this one. The cookie name is typically AWS ALB app. This is used for target group level stickiness. Now what are the downside of sticky sessions? If you have 10 instances and one gets sticky with many users, it becomes overloaded while the others are underutilized. Stickie sessions can cause load imbalance. So what's a better solution here? Better solution is to extend lies session data. So instead of storing session data in memory on instances, what you want to do is store it in a shared location like elasty cache, that's reddish or memcache, or a dynamo DB. Now it doesn't matter which instances handles the request. All instances can access the session data from the shared store. Let's look at a real world architecture now. So that's one for e-commerce shopping cart. The user adds items to the cart. Shopping cart data is stored in elasty cache. Any instance can retrieve the cart data. No need for sticky sessions. There is perfect load distribution. So for the exam, if the question asks how to maintain user sessions across multiple instances, the best answer is always to store session data in elasty cache or dynamo DB. An alternative answer could be to use sticky sessions on the load balancer, but externalized session storage is generally preferred. So now let's look at the next topic which is connection training. Connection training is about gracefully handling instance terminations. So what's the problem? You have active users connected to an instance. The instance now needs to be terminated that could be for maintenance, scaling down or because it's simply unhealthy. If you just terminate it immediately, those active connections are abruptly closed users see errors. Connection training on the other hand solves this. That's when an instance is being deregistered or marked unhealthy. The load balancer stops sending new requests to that instance. Existing in flight requests are not allowed to complete. After all the existing requests are finished or timed out, the instance is then fully deregistered. Now you can safely terminate the instance. What are its configurations? So you set a D-registration delay which is also called a connection training timeout. The minimum is typically one second, the maximum is normally an hour. The default is normally five minutes and it can be disabled by setting to zero. Now how do you choose this timeout? For short requests that's APA calls or symbol web pages, set it to between 30 to 60 seconds. Requests should finish quickly. For long requests that file uploads video streaming or report generation, set it to typically 300 to 600 seconds. This gives long requests time to complete. Now for a real world example, your application generates PDF reports. This takes about 2 to 3 minutes per request. What you want to do is to set the D-registration delay to 300 seconds at about 5 minutes. This ensures PDF generation completes even when the instance is being deregistered. Now what happens during connection training? From a load balancer perspective, instance state changes to training. No new connections are sent to this instance. Hellchecks are still being performed. After timeout or all connections close, instance is deregistered. Now from an instance perspective, it continues to serve existing requests. It doesn't receive new requests. It can gracefully finish all its work and can close the database connections very clearly. Now how does this integrate with auto scaling? When auto scaling terminates an instance, it waits for D-registration delay before actually terminating. This ensures graceful shutdown. So for an exam question, a company wants to ensure its users don't experience errors when instances are terminated during auto scaling scale in events. The answer is to configure connection training, that is D-registration delay, on the load balancer, with an appropriate timeout value. Now here we come to our most popular section, exam traps and gotchas. Let's go through the most common exam traps for load balancers. Trap number 1. ALB versus NLP. Which one would you use? Question. An application needs to handle TCP traffic on port 3306, that's my SQL, which load balancer should be used. People think TCP traffic means NLP, but wait. NLP is for extreme performance or when you need static IPs. Remember that. So the correct answer is, both can handle TCP. If the question doesn't mention performance requirements or static IPs, ALB is typically the answer for most of the use cases. However, if it's raw TCP, not HTTP, NLP is more appropriate. For my SQL specifically, use NLP, because it's TCP, not HTTP. So the real decision matrix, HTTP or HTTP s traffic, you use ALB unless performance is critical, known HTTP, TCP or UDP, you want to use NLP. Static IP required, you want to use NLP, if we are talking about millions of requests per second, that's NLP again, WebSocket or HTTP to needed, that is ALB, and if it's path-based or host-based routing, that's also ALB. Onto Trap 2. Cross zone load balancing default settings. The question is, a network load balancer shows uneven traffic distribution across A's. What's the likely cost? People forget, cross zone is disabled by default for NLP. So the answer is, always to enable cross zone load balancing on the NLP, note that the inter-AZ data transfer charge will apply. So memorize the defaults, ALB, enabled, and it's free, NLP is disabled, cost money if it's enabled, GWLB that is disabled, again, cost money if it's enabled, and CLB is disabled, it's free if it's enabled. Now onto Trap 3. X-forwarded for header. Question. Application needs the client's real IP address, the application is behind an ALB. There is this information. People think source IP of the connection gives you the information. Sorry wrong, that's the ALB's IP. So the answer is X-forwarded for header contains the client's real IP address. For NLP, the source IP is the client's IP. No header is needed. Remember that. Now onto Trap 4. Static IP address requirement. Question. Client's firewall requires white listing specific IP addresses, which load balancer to use. People think ALB can handle this. That's wrong. ALB has dynamic IPs. It provides static IP addresses that's one per easy and supports assigning elastic IPs. Trap number 5. Multiple SSL certificates. The question. One load balancer needs to serve multiple domains, each with its own SSL certificate, which load balancer supports this. People think now all load balancer support SSL. That's wrong. Also remember CLB supports only one SSL certificate. So the answer is ALB or NLP, because both support SNI for multiple certificates, not CLB. Remember that. Trap number 6. Hell check configuration. Question. Instances are running, but unhealthy according to the load balancer. What could be wrong? The answer is check is the hell check path correct. That's the slash health endpoint exists. Is the hell check port correct? Is the security group allowing traffic from the load balancer? Is the application actually responding on that path slash port? Are the thresholds too aggressively configured? Common issue is hell check path is slash health, but the application doesn't have that endpoint. Onto trap number 7. Sticky sessions and load imbalance. The question is, load balancer shows some instances are at 80% CPU while the others are at 20%. Sticky sessions are enabled. What's happening? The answer is sticky sessions can cause uneven load distribution. We talked about that. Users stick to specific instances, consider disabling sticky sessions or using external session storage. Much advised. Onto trap number 8. Connection draining timeout. Question. Users experience errors during auto scaling scale in events. What should be checked? The answer is connection draining. That is deregistration delay. That might not be configured or the timeout might be too short. Set an appropriate deregistration delay to allow in-flight requests to complete. So now onto trap 9. Target type limitations. Question. Can an ALB route to lambda functions? The answer is yes. ALB supports EC2 instances, ECS tasks, lambda functions and IP addresses. Trap number 10. Security group configuration. The question is, backend instances aren't receiving traffic from the load balancer. The answer is, the security group on the backend instances must allow traffic from the load balancer security group for ALB or from the load balancer's IP range for NLB. A common mistake is that backend security group only allows traffic from 0.0.0.0/0, not specifically from the load balancer. Best practice is that backend instant security group should allow traffic from the load balancer's security group onto trap 11. Target health status. The question is, what are the possible target health status? The answer is, initial target is being registered, healthy target is responding to health checks. unhealthy target is failing health checks, unused the target is not registered, draining target is de-registering, completing in-flight requests and unavailable the health checks are disabled. Trap number 12. Load Balancer Scheme Question. What's the difference between internal and external load balancers? The answer. External, which is internet-facing, has public IP addresses accessible from the internet. Internal has only private IP addresses accessible only within the VPC. Use internal load balancers for multi-tier architectures. So external LB would be web tier, internal LB would be application tier, and internal NLB would be database tier. Now onto the next section. Exam Quick Tips. Let's finish with the rapid-fire exam tips. Tip number one, LB versus NLB decision tree. If you're talking about HTTP or HTTPS traffic, then think ALB. Starting IP needed, then think NLB. Extreme performance, it's NLB. Path or host-based routing, then it's ALB. Web socket, then that's ALB. Millions of requests per second. That is NLB. Tip number two. Cross zone defaults. ALB, remember that's enabled, and it's free. NLB that's disabled, but if you enable it, it costs, and remember, NLB is uneven traffic, enable cross zone. Tip number three. Client IP address. ALB, you get that from the x forwarded for header, and for NLB, the source IP of the connection. Just know the difference. Tip number four. ALB and NLB support SNI, that's multiple certificates. CLB only support one certificate. So for a new application, never want to use CLB. Tip number five. Hel checks. Save lives. Always configure health checks. Use application level health checks, not just the poor checks. Set up operator shows and integrate with auto scaling. Onto tip six. Connection, draining. Always do enable it. Set timeout based on request duration. Short request about 30 to 60 seconds, and for long request, that will be 300 to 600 seconds, roughly. Tip number seven. Security groups. Back in instances, allow from load balances security group, not from 0.0.0.0/0, that's more secure and explicit. Tip number eight. Sticky sessions. Use only if it's necessary. The better solution is to use elastic cache for sessions. It avoids load imbalances. Tip number nine. Internal versus external. Internet facing, then think public IPs accessible from internet. Fits internal, then it's private IPs only, VPC access only. Remember multi-tier architectures use both. Tip number 10. Integration matters. Load balancers can integrate with auto scaling groups, ACM route 53, WF, cloud watch and global accelerator. All right, everyone, that wraps up episode five on elastic load balancing. We covered a ton today. We started with what load balancers are and why they're essential for high availability. We compared the four types of load balancers. That's classic application network and gateway. We went deep on application load balancer, the most common and most tested on the exam. Pathbase routing, target groups and that critical X forwarded forehead error topic. We covered network load balancer for extreme performance and static IP requirements. We then discussed health checks how to configure them properly and why they are critical. We dove into cross zone load balancing and the default settings that trip people up on the exam. We covered SSL or TLS termination, SNI for multiple certificates and sticky sessions. And we finished with exam traps and real world architecture patterns. I wanted to remember that load balancers are the foundation of highly available AWS architectures. Master this and your well on a way to passing your exam and building production grade systems. In our next episode, episode six, we are covering auto scaling groups how to automatically scale your easy to fleet based on demand scaling policies and integration with load balancers. If this episode helped you understand load balancers, please do consider to leave a five star rating on Spotify and share it with anyone studying for the AWS exam. Until next time, keep studying, keep practicing and I will see you in episode six. This is Balu signing off. Bye.