[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"lesson-aws-certified-cloudops-engineer-associate-monitoring-logging-performance-rds-performance-rds-proxy-and-performance-tuning-en":4,"next-aws-certified-cloudops-engineer-associate-monitoring-logging-performance-rds-performance-rds-proxy-and-performance-tuning-en":20,"prev-aws-certified-cloudops-engineer-associate-monitoring-logging-performance-rds-performance-rds-proxy-and-performance-tuning-en":774},null,{"locked":5,"reason":6,"meta":7,"item":3},true,"paywall",{"title":8,"description":9,"isFree":10,"estimatedMinutes":11,"difficulty":12,"learningObjectives":13},"RDS Proxy and Performance Tuning","Fix connection exhaustion with RDS Proxy, recognize the session pinning that quietly cancels its benefit, and pick the right tuning lever when the bottleneck is the instance, the storage, or the queries instead.",false,30,"intermediate",[14,15,16,17,18,19],"Explain why database connections are expensive and how max_connections is derived from instance class memory","Describe how RDS Proxy pools and multiplexes connections, and what borrowing means","Identify the operations that cause session pinning and the metric that detects it","Configure the proxy connection pool settings and know their defaults","Explain how RDS Proxy shortens failover and Blue/Green switchover for applications","Choose between connection pooling, instance resizing, storage changes, parameter tuning, and read offloading for a given bottleneck",{"locked":10,"reason":3,"meta":21,"item":31},{"title":22,"description":23,"isFree":5,"estimatedMinutes":24,"difficulty":12,"learningObjectives":25},"Elastic Load Balancing Fundamentals","What a load balancer actually is in AWS, how ALB, NLB, and Gateway Load Balancer differ in the routing decision each can make, and the target group settings that decide how traffic reaches your instances.",26,[26,27,28,29,30],"Explain why a load balancer DNS name resolves to several IP addresses and what each one is","Compare Application, Network, and Gateway Load Balancers by OSI layer and by the routing decision each can make","Trace a request through a listener, a listener rule, a target group, and a target","Predict traffic distribution with cross-zone load balancing on and off, and state the default for each load balancer type","Select the target type and target group attributes that a given workload requires",{"id":32,"title":22,"body":33,"description":23,"difficulty":12,"estimatedMinutes":24,"extension":686,"infographics":687,"isFree":5,"learningObjectives":705,"meta":706,"navigation":5,"path":707,"quiz":708,"seo":771,"stem":772,"__hash__":773},"courses/courses/aws-certified-cloudops-engineer-associate/en/domains/02-reliability-business-continuity/01-load-balancing-and-health-checks/01-elastic-load-balancing-fundamentals.md",{"type":34,"value":35,"toc":676},"minimark",[36,40,43,48,56,68,105,108,115,118,129,133,136,141,148,159,169,285,288,292,295,313,320,328,343,360,367,371,374,415,424,428,431,437,484,491,502,506,509,512,526,535,549,556,559,563,566,587,607,619,634,637,641,669,672],[37,38,39],"p",{},"A payments API runs on 6 EC2 instances split across 2 Availability Zones. A deploy goes out, one instance comes up with a broken configuration, and for the next 40 minutes about a sixth of all requests return errors. Nobody was paged, because nothing was down. The instance was reachable, it answered on port 8080, and it returned HTTP 500 for every call.",[37,41,42],{},"A load balancer would have pulled that instance out of rotation in under a minute. That is what Elastic Load Balancing does for you: not only spreading requests, but continuously asking every target whether it is fit to receive them, and routing around the ones that are not. This lesson builds the model of how that distribution works. The next one covers what to do when the health check itself is the thing that is broken.",[44,45,47],"h2",{"id":46},"a-load-balancer-is-a-set-of-nodes-not-a-box","A load balancer is a set of nodes, not a box",[37,49,50,51,55],{},"The first thing to unlearn is the picture of a single appliance sitting in front of your fleet. When you enable an Availability Zone for a load balancer, Elastic Load Balancing creates a ",[52,53,54],"strong",{},"load balancer node"," in that zone. Enable 3 zones and you get 3 nodes, each with its own IP address, each able to receive client traffic.",[37,57,58,59,63,64,67],{},"Clients find those nodes through DNS. Your load balancer gets a name such as ",[60,61,62],"code",{},"my-lb-1234567890abcdef.elb.us-east-2.amazonaws.com",", and Amazon DNS answers a query for it with the IP addresses of the nodes. The record carries a ",[52,65,66],{},"time to live of 60 seconds",", which is short on purpose: it lets AWS add nodes as traffic grows, and remove a node whose zone is in trouble, without waiting on client caches.",[69,70,75],"pre",{"className":71,"code":72,"language":73,"meta":74,"style":74},"language-bash shiki shiki-themes material-theme-lighter github-light github-dark","dig +short my-lb-1234567890abcdef.elb.us-east-2.amazonaws.com\n3.13.20.147\n18.222.9.88\n","bash","",[60,76,77,93,99],{"__ignoreMap":74},[78,79,82,86,90],"span",{"class":80,"line":81},"line",1,[78,83,85],{"class":84},"sbgvK","dig",[78,87,89],{"class":88},"s_sjI"," +short",[78,91,92],{"class":88}," my-lb-1234567890abcdef.elb.us-east-2.amazonaws.com\n",[78,94,96],{"class":80,"line":95},2,[78,97,98],{"class":84},"3.13.20.147\n",[78,100,102],{"class":80,"line":101},3,[78,103,104],{"class":84},"18.222.9.88\n",[37,106,107],{},"Two consequences follow immediately, and both show up on the exam.",[37,109,110,111,114],{},"First, a load balancer needs subnets in the zones you want it to serve. An ",[52,112,113],{},"Application Load Balancer requires at least 2 Availability Zones","; a Network Load Balancer will run with one, though a single zone gives you no zonal redundancy. If you register targets in a zone you never enabled, those targets get no traffic at all.",[37,116,117],{},"Second, the client picks which node IP address to use. AWS does not steer the choice. So the shape of your traffic depends on how many nodes exist and which targets each node is allowed to reach, which is exactly the cross-zone question later in this lesson.",[37,119,120,121,124,125,128],{},"One more distinction before the types. An ",[52,122,123],{},"internet-facing"," load balancer has nodes with public IP addresses and needs public subnets with a route to an internet gateway. An ",[52,126,127],{},"internal"," load balancer has only private addresses. Both reach their targets over private IP addresses, so your instances never need public IPs to sit behind either one.",[44,130,132],{"id":131},"three-load-balancers-three-depths-of-inspection","Three load balancers, three depths of inspection",[37,134,135],{},"AWS offers 3 current generation load balancers. The temptation is to memorize a feature matrix. The faster model is to ask how deep into the packet each one is allowed to look, because that single fact determines everything it can decide.",[137,138],"infographic",{"alt":139,"slug":140},"Three columns comparing the Application, Network, and Gateway Load Balancers by the layer each inspects and the routing decision that layer makes possible, with a selection cue under each column.","elb-type-decision-boundary",[37,142,143,144,147],{},"An ",[52,145,146],{},"Application Load Balancer"," operates at layer 7. It parses the HTTP request, so it can route on the hostname, the path, a header, the method, a query string parameter, or the source IP. It can also terminate TLS, authenticate users against an identity provider, return a fixed response, and issue a redirect without ever touching a target.",[37,149,150,151,154,155,158],{},"A ",[52,152,153],{},"Network Load Balancer"," operates at layer 4. It never parses HTTP. It picks a target using a ",[52,156,157],{},"flow hash"," over the protocol, source IP and port, destination IP and port, and TCP sequence number, then pins that whole TCP connection to the chosen target for its lifetime. Because it does less per packet, it handles very high connection rates with low added latency, and because it does not need to rewrite anything, it can hand your target the client's real source IP.",[37,160,150,161,164,165,168],{},[52,162,163],{},"Gateway Load Balancer"," operates at layer 3. It listens for all IP packets on all ports and forwards them to virtual appliances, firewalls, intrusion detection systems, deep packet inspection tools, using the ",[52,166,167],{},"GENEVE protocol on port 6081",". Traffic reaches it through a Gateway Load Balancer endpoint that you set as the next hop in a route table, so the appliance fleet becomes a transparent bump in the wire.",[170,171,172,187],"table",{},[173,174,175],"thead",{},[176,177,178,181,183,185],"tr",{},[179,180],"th",{},[179,182,146],{},[179,184,153],{},[179,186,163],{},[188,189,190,205,219,233,247,259,272],"tbody",{},[176,191,192,196,199,202],{},[193,194,195],"td",{},"Layer",[193,197,198],{},"7",[193,200,201],{},"4",[193,203,204],{},"3",[176,206,207,210,213,216],{},[193,208,209],{},"Listener protocols",[193,211,212],{},"HTTP, HTTPS",[193,214,215],{},"TCP, UDP, TLS, TCP_UDP",[193,217,218],{},"all IP traffic",[176,220,221,224,227,230],{},[193,222,223],{},"Target selection",[193,225,226],{},"listener rules, then the target group algorithm",[193,228,229],{},"flow hash, pinned per connection",[193,231,232],{},"flow hash to an appliance",[176,234,235,238,241,244],{},[193,236,237],{},"IP address",[193,239,240],{},"changes as it scales",[193,242,243],{},"1 static IP per zone, Elastic IP supported",[193,245,246],{},"via endpoint",[176,248,249,252,254,257],{},[193,250,251],{},"Health check protocols",[193,253,212],{},[193,255,256],{},"TCP, HTTP, HTTPS",[193,258,256],{},[176,260,261,264,267,270],{},[193,262,263],{},"Cross-zone default",[193,265,266],{},"on at the load balancer, per target group override",[193,268,269],{},"off",[193,271,269],{},[176,273,274,277,280,283],{},[193,275,276],{},"Minimum zones",[193,278,279],{},"2",[193,281,282],{},"1",[193,284,282],{},[37,286,287],{},"The Classic Load Balancer still exists and still appears in older material, but AWS recommends migrating away from it, and SOA-C03 scenarios are built around the current generation.",[44,289,291],{"id":290},"how-an-application-load-balancer-decides-where-a-request-goes","How an Application Load Balancer decides where a request goes",[37,293,294],{},"Four objects sit between a client and an instance, and every ALB troubleshooting question depends on knowing which one owns which decision.",[37,296,150,297,300,301,304,305,308,309,312],{},[52,298,299],{},"listener"," checks for connections on a protocol and port, HTTP or HTTPS, port 1 to 65535. A ",[52,302,303],{},"listener rule"," has a priority, one or more conditions, and one or more actions. A ",[52,306,307],{},"target group"," collects targets that share a protocol, a port, and one set of health check settings. A ",[52,310,311],{},"target"," is the instance, IP address, or Lambda function that finally answers.",[37,314,315,316,319],{},"Walk one request through it. A client sends ",[60,317,318],{},"GET https://shop.example.com/api/orders/1042",". The HTTPS listener on port 443 terminates TLS using the ACM certificate attached to it. It then evaluates its rules in priority order, lowest number first:",[69,321,326],{"className":322,"code":324,"language":325},[323],"language-text","priority 10   IF path-pattern = /api/*        THEN forward to tg-api\npriority 20   IF host-header  = img.example.com THEN forward to tg-images\ndefault       (cannot be deleted)             forward to tg-web\n","text",[60,327,324],{"__ignoreMap":74},[37,329,330,331,334,335,338,339,342],{},"Rule 10 matches, so the request goes to ",[60,332,333],{},"tg-api",". Rules are first-match-wins, and the ",[52,336,337],{},"default rule is always evaluated last"," and cannot be deleted, so it functions as the catch-all. If your new path rule sits at priority 60000 behind a broad ",[60,340,341],{},"/*"," rule at priority 5, it will never fire, and that ordering mistake is a common exam stem.",[37,344,345,347,348,351,352,355,356,359],{},[60,346,333],{}," then picks one target using its routing algorithm and forwards the request over a backend connection, HTTP/1.1 by default. The load balancer adds ",[60,349,350],{},"X-Forwarded-For",", ",[60,353,354],{},"X-Forwarded-Proto",", and ",[60,357,358],{},"X-Forwarded-Port"," so the application can still see who the client was, since at layer 7 the packet the target receives comes from the load balancer, not from the client.",[37,361,362,363,366],{},"Two settings on this path are worth committing to memory. The ",[52,364,365],{},"connection idle timeout defaults to 60 seconds"," and can be set anywhere from 1 to 4000. And the load balancer allows 10 seconds to establish a TCP connection to a target before it gives up. Both of those numbers become error codes in the next lesson.",[44,368,370],{"id":369},"target-types-what-you-register-decides-what-you-can-reach","Target types: what you register decides what you can reach",[37,372,373],{},"A target group has one target type, chosen at creation and never changeable afterwards.",[375,376,377,386,407],"ul",{},[378,379,380,385],"li",{},[52,381,382],{},[60,383,384],{},"instance"," registers by instance ID. Traffic goes to the primary private IP of the primary network interface. Simple, and it is what an Auto Scaling group attaches to automatically. It cannot reach instances in a peered VPC.",[378,387,388,393,394,351,397,351,400,355,403,406],{},[52,389,390],{},[60,391,392],{},"ip"," registers by IP address. Allowed ranges are the target group VPC subnets plus ",[60,395,396],{},"10.0.0.0/8",[60,398,399],{},"100.64.0.0/10",[60,401,402],{},"172.16.0.0/12",[60,404,405],{},"192.168.0.0/16",". Publicly routable addresses are rejected. This is how you reach a peered VPC, a database, or an on-premises server over Direct Connect or Site-to-Site VPN, and it also lets several containers on one instance use the same port.",[378,408,409,414],{},[52,410,411],{},[60,412,413],{},"lambda"," registers a single function, which the load balancer invokes rather than connects to. Request and response bodies are capped at 1 MB.",[37,416,417,418,420,421,423],{},"The tempting mistake is to assume ",[60,419,384],{}," is always the safe default. It is the one target type that cannot cross a VPC peering boundary, so any hybrid or multi-VPC scenario points at ",[60,422,392],{},".",[44,425,427],{"id":426},"how-a-network-load-balancer-decides-and-why-client-ip-matters","How a Network Load Balancer decides, and why client IP matters",[37,429,430],{},"There are no rules to evaluate at layer 4. The node hashes the flow, picks a target, and keeps that connection there. Everything interesting is in the connection handling.",[37,432,433,436],{},[52,434,435],{},"Client IP preservation"," is the setting that surprises people. When it is on, your target sees the client's real source address, which means your security groups must allow the client range, not the load balancer. When it is off, the target sees the private IP of the load balancer node. The defaults are not uniform:",[170,438,439,452],{},[173,440,441],{},[176,442,443,446,449],{},[179,444,445],{},"Target group",[179,447,448],{},"Protocol",[179,450,451],{},"Client IP preservation default",[188,453,454,464,474],{},[176,455,456,458,461],{},[193,457,384],{},[193,459,460],{},"any",[193,462,463],{},"Enabled, cannot be disabled for UDP, TCP_UDP, QUIC, TCP_QUIC",[176,465,466,468,471],{},[193,467,392],{},[193,469,470],{},"UDP, TCP_UDP, QUIC, TCP_QUIC",[193,472,473],{},"Enabled, cannot be disabled",[176,475,476,478,481],{},[193,477,392],{},[193,479,480],{},"TCP, TLS",[193,482,483],{},"Disabled",[37,485,486,487,490],{},"If preservation is off and you still need the caller's address, turn on ",[52,488,489],{},"proxy protocol v2",", which prepends a binary header carrying the connection details. Make sure the application can parse it first: a target that chokes on the header will start failing health checks, because the header is added to health check connections too.",[37,492,493,494,497,498,501],{},"The idle timeouts are fixed points worth knowing. TCP flows default to ",[52,495,496],{},"350 seconds"," and can be set from 60 to 6000. TLS listeners are fixed at 350 seconds. UDP flows are fixed at ",[52,499,500],{},"120 seconds",", after which the next packet is treated as a new flow and can land on a different target.",[44,503,505],{"id":504},"cross-zone-load-balancing-with-the-arithmetic","Cross-zone load balancing, with the arithmetic",[37,507,508],{},"This is the single most testable behavior in the topic, and the numbers make it stick better than the definition does.",[37,510,511],{},"Take a load balancer with 2 enabled zones. Availability Zone A holds 2 targets, Availability Zone B holds 8. DNS hands out both node addresses about evenly, so each node receives 50% of client traffic.",[37,513,514,517,518,521,522,525],{},[52,515,516],{},"Cross-zone off."," Each node can only reach targets in its own zone. The node in zone A splits its 50% between 2 targets, so each gets ",[52,519,520],{},"25%",". The node in zone B splits its 50% across 8 targets, so each gets ",[52,523,524],{},"6.25%",". Two targets are doing 4 times the work of the other 8.",[37,527,528,531,532,423],{},[52,529,530],{},"Cross-zone on."," Each node can reach all 10 targets, so every target receives ",[52,533,534],{},"10%",[37,536,537,538,541,542,545,546,548],{},"The defaults differ by type, and the reason is architectural rather than arbitrary. An Application Load Balancer is always cross-zone at the load balancer level and cannot be turned off there, though an individual target group can set ",[60,539,540],{},"load_balancing.cross_zone.enabled"," to ",[60,543,544],{},"false"," and become zonal. Network Load Balancers and Gateway Load Balancers default to ",[52,547,269],{},", which keeps each zone a self-contained failure domain and avoids cross-zone data transfer charges.",[37,550,551,552,555],{},"That charge is the practical catch. Turning cross-zone on for a Network Load Balancer means traffic crosses Availability Zone boundaries, and ",[52,553,554],{},"EC2 data transfer charges apply",". Turning it off means you must plan enough capacity in every zone, because a zone with too few targets will overload them while another zone sits idle.",[37,557,558],{},"There is one trap in the off configuration. When cross-zone is off, an empty or all-unhealthy zone is a real outage for the clients that resolved to it. For an Application Load Balancer this produces HTTP 503 responses for every request entering that zone, which is why AWS warns against creating empty subnets.",[44,560,562],{"id":561},"the-target-group-attributes-that-change-production-behavior","The target group attributes that change production behavior",[37,564,565],{},"Health check settings get their own lesson. These 4 attributes decide how traffic reaches a healthy target, and each one exists to solve a specific failure.",[37,567,568,571,572,575,576,579,580,583,584,586],{},[52,569,570],{},"Deregistration delay"," (",[60,573,574],{},"deregistration_delay.timeout_seconds",", default ",[52,577,578],{},"300"," seconds, range 0 to 3600). When a target is deregistered it enters the ",[60,581,582],{},"draining"," state and stops receiving new requests while in-flight ones finish. If the delay expires while a request is still running, the client gets a 502. If the target has no in-flight requests and no active connections, deregistration completes immediately, though the console keeps showing ",[60,585,582],{}," until the timer runs out.",[37,588,589,571,592,575,595,598,599,602,603,606],{},[52,590,591],{},"Routing algorithm",[60,593,594],{},"load_balancing.algorithm.type",[60,596,597],{},"round_robin","). Round robin assumes similar requests hitting similar targets. ",[52,600,601],{},"Least outstanding requests"," sends each request to the target with the fewest in-progress requests, which is the right answer when request cost or target capacity varies. ",[52,604,605],{},"Weighted random"," distributes randomly and is the only algorithm that supports Automatic Target Weights anomaly mitigation. Neither of the last 2 can be combined with slow start.",[37,608,609,571,612,575,615,618],{},[52,610,611],{},"Slow start",[60,613,614],{},"slow_start.duration_seconds",[52,616,617],{},"0",", meaning disabled, range 30 to 900). A newly healthy target normally receives its full share of traffic the instant it passes one health check. For an application that needs to warm a cache or a JIT compiler, that full share arrives as a wall of latency. Slow start ramps the target up linearly over the configured window instead.",[37,620,621,571,624,575,627,629,630,633],{},[52,622,623],{},"Stickiness",[60,625,626],{},"stickiness.enabled",[60,628,544],{},"). Duration-based stickiness makes the load balancer issue an encrypted ",[60,631,632],{},"AWSALB"," cookie that pins a client to a target; application-based stickiness follows a cookie your application sets. Both are configured per target group, with a duration from 1 second to 7 days. Two constraints catch people out: stickiness requires cross-zone load balancing to be on, and it does not work with the weighted random algorithm.",[37,635,636],{},"It is tempting to treat stickiness as the fix for a session problem. It is a workaround, and it costs you even distribution, because a scale-out event leaves old clients pinned to old targets. The durable fix is to move session state out of the instance, into ElastiCache or DynamoDB, which is where a later topic in this domain picks the thread back up.",[44,638,640],{"id":639},"exam-tips","Exam tips",[375,642,643,646,649,652,655,658,663],{},[378,644,645],{},"\"Route based on URL path or hostname\" is always an Application Load Balancer. \"Static IP address\", \"Elastic IP\", \"millions of requests per second\", or a protocol that is not HTTP points at a Network Load Balancer. \"Firewall appliance\", \"intrusion detection\", or \"third-party inspection\" points at a Gateway Load Balancer.",[378,647,648],{},"\"The targets must terminate TLS themselves\" rules out an HTTPS listener on an ALB. The answer is a Network Load Balancer with a TCP listener on port 443.",[378,650,651],{},"Uneven load across instances with cross-zone in the stem is the 25% versus 6.25% arithmetic. Reach for the target count per zone before reading the options.",[378,653,654],{},"If a question mentions cost as a reason to leave a Network Load Balancer setting alone, it is talking about cross-zone data transfer charges.",[378,656,657],{},"Requests dropped during a deploy point at deregistration delay. New instances slow for their first minute point at slow start. The 2 are opposites and their names do not make that obvious.",[378,659,660,661,423],{},"A target group registered by instance ID cannot reach a peered VPC. If the stem mentions peering, hybrid, or on-premises targets, the target type must be ",[60,662,392],{},[378,664,665,666,668],{},"\"The application needs the client's real IP address\" is ",[60,667,350],{}," on an Application Load Balancer, and client IP preservation or proxy protocol v2 on a Network Load Balancer. Note the default is disabled for TCP and TLS ip target groups.",[37,670,671],{},"The idea worth carrying forward is that a load balancer routes only to targets it believes are healthy, and belief is built entirely from health check settings you chose. Every distribution behavior in this lesson assumes those checks are telling the truth. When they are not, targets go missing from rotation for reasons that have nothing to do with the application, and that is where the next lesson starts.",[673,674,675],"style",{},"html pre.shiki code .sbgvK, html code.shiki .sbgvK{--shiki-light:#E2931D;--shiki-default:#6F42C1;--shiki-dark:#B392F0}html pre.shiki code .s_sjI, html code.shiki .s_sjI{--shiki-light:#91B859;--shiki-default:#032F62;--shiki-dark:#9ECBFF}html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":74,"searchDepth":101,"depth":101,"links":677},[678,679,680,681,682,683,684,685],{"id":46,"depth":95,"text":47},{"id":131,"depth":95,"text":132},{"id":290,"depth":95,"text":291},{"id":369,"depth":95,"text":370},{"id":426,"depth":95,"text":427},{"id":504,"depth":95,"text":505},{"id":561,"depth":95,"text":562},{"id":639,"depth":95,"text":640},"md",[688],{"slug":140,"concept":689,"style":690,"aspectRatio":691,"labels":692},"A three-column comparison of the current generation load balancers, arranged left to right by how deep into the packet each one looks. Each column shows a single client request entering at the top and the routing decision the load balancer can make on it, drawn as a decision point labeled with the information available at that layer. Column headers carry the OSI layer, the body carries the protocols and the decision, and a footer strip carries the one-line selection cue. The emphasis is that the layer determines the decision, not the other way around.","comparison","16:9",[693,694,695,696,697,698,699,700,701,702,703,704],"Application Load Balancer: layer 7, reads the HTTP request","Protocols: HTTP, HTTPS, gRPC, WebSockets","Decision: host, path, header, method, query string, source IP","Network Load Balancer: layer 4, reads the TCP or UDP connection","Protocols: TCP, UDP, TLS, TCP_UDP","Decision: flow hash over the 5-tuple, same target for the whole connection","Gateway Load Balancer: layer 3, reads the IP packet","Protocols: all IP traffic, GENEVE on port 6081 to the appliances","Decision: flow hash to one appliance, packet returns to its original path","Route by URL or hostname? Application Load Balancer","Need a static IP, extreme throughput, or a non-HTTP protocol? Network Load Balancer","Sending traffic through a firewall or inspection appliance? Gateway Load Balancer",[26,27,28,29,30],{},"/courses/aws-certified-cloudops-engineer-associate/en/domains/02-reliability-business-continuity/01-load-balancing-and-health-checks/01-elastic-load-balancing-fundamentals",{"passingScore":709,"questions":710},70,[711,720,730,738,746,752,757,763],{"question":712,"type":713,"options":714,"correctAnswer":716,"explanation":719},"A team runs 2 EC2 targets in Availability Zone A and 8 in Availability Zone B behind a Network Load Balancer with default settings. Roughly what share of client traffic does each target in Availability Zone A receive?","single",[715,716,717,718],"10%, because the load balancer spreads traffic evenly across all 10 targets","25%, because each zonal node receives half the traffic and splits it between the 2 local targets","50%, because clients prefer the zone with fewer targets","6.25%, because the load balancer weights by target count","Cross-zone load balancing is off by default on a Network Load Balancer, so each zonal node serves only the targets in its own zone. DNS hands out both node addresses about evenly, so each node gets 50% of traffic: the 2 targets in zone A split it 25% each while the 8 targets in zone B get 6.25% each. Turning cross-zone on would give all 10 targets 10%.",{"question":721,"type":722,"options":723,"correctAnswers":728,"explanation":729},"Which statements about cross-zone load balancing are correct? (Choose 2.)","multiple",[724,725,726,727],"Cross-zone load balancing is always on at the load balancer level for an Application Load Balancer and cannot be turned off there","Enabling cross-zone load balancing on a Network Load Balancer can add EC2 data transfer charges","Cross-zone load balancing is on by default for Network Load Balancers","An Application Load Balancer target group cannot override the load balancer cross-zone setting",[724,725],"An Application Load Balancer is always cross-zone at the load balancer level, but an individual target group can set the attribute to false and become zonal. Network Load Balancers default to off, and turning it on means traffic crosses Availability Zone boundaries, which is billable data transfer.",{"question":731,"type":713,"options":732,"correctAnswer":735,"explanation":737},"An application needs a fixed IP address that partners can add to their firewall allow lists, and it terminates TLS on the instances themselves. Which load balancer fits?",[733,734,735,736],"Application Load Balancer with an HTTPS listener","Gateway Load Balancer with an appliance target group","Network Load Balancer with a TCP listener on port 443","Application Load Balancer with the host header preservation attribute enabled","A Network Load Balancer gets one static IP per enabled Availability Zone, and you can attach your own Elastic IP addresses, which is what an allow list needs. A TCP listener passes the encrypted bytes straight through so the instance does the TLS handshake. An Application Load Balancer changes IP addresses as it scales and would have to terminate TLS itself to read the request.",{"question":739,"type":713,"options":740,"correctAnswer":744,"explanation":745},"An Application Load Balancer has a listener rule with priority 10 forwarding /api/* to the api target group, and a default action forwarding everything to the web target group. A request arrives for /api/orders. What happens?",[741,742,743,744],"The default action wins, because default actions are evaluated first","The request is rejected with a 404 because no rule matches exactly","Both target groups receive a copy of the request","Rule 10 matches, so the request goes to the api target group","Listener rules are evaluated in priority order, lowest number first, and the first match wins. The default rule cannot be deleted and is always performed last, so it catches only requests that no other rule matched.",{"question":747,"type":713,"options":748,"correctAnswer":749,"explanation":751},"True or False: registering targets by IP address lets you send traffic to an on-premises server reached over Direct Connect.",[749,750],"True","False","The ip target type accepts addresses from the target group VPC subnets plus the RFC 1918 and RFC 6598 private ranges, which covers peered VPCs and on-premises resources reached over Direct Connect or Site-to-Site VPN. Publicly routable addresses are rejected, and instance IDs only work for instances in the load balancer VPC.",{"question":753,"type":713,"options":754,"correctAnswer":574,"explanation":756},"A deployment terminates instances as soon as the Auto Scaling group replaces them, and users report occasional broken uploads. Which target group attribute addresses this directly?",[614,755,574,594],"stickiness.lb_cookie.duration_seconds","Deregistration delay is the window in which a draining target finishes its in-flight requests before the load balancer marks it unused and the instance can be terminated. The default is 300 seconds and the range is 0 to 3600, so a long upload needs a value that covers it. Slow start solves the opposite problem, a cold target being flooded on arrival.",{"question":758,"type":713,"options":759,"correctAnswer":601,"explanation":762},"Which routing algorithm should a target group use when requests vary widely in cost and the targets vary in capacity?",[601,760,605,761],"Round robin","Flow hash","Least outstanding requests sends each new request to the target currently holding the fewest in-progress requests, which naturally steers work away from a slow or busy target. Round robin assumes similar requests and similar targets, and flow hash is the Network Load Balancer mechanism, not an Application Load Balancer option. Note that least outstanding requests cannot be combined with slow start.",{"question":764,"type":713,"options":765,"correctAnswer":767,"explanation":770},"What does a Gateway Load Balancer use to exchange traffic with its registered virtual appliances?",[766,767,768,769],"TLS on port 443 with mutual authentication","The GENEVE protocol on port 6081","Proxy protocol v2 over TCP","VXLAN on port 4789","A Gateway Load Balancer encapsulates the original packet in GENEVE on port 6081 so the firewall or inspection appliance sees the traffic unchanged and can return it to its original path. Proxy protocol v2 is how a Network Load Balancer passes client connection details to targets, which is a different problem at a different layer.",{"title":22,"description":23},"courses/aws-certified-cloudops-engineer-associate/en/domains/02-reliability-business-continuity/01-load-balancing-and-health-checks/01-elastic-load-balancing-fundamentals","mZ8WqpElN3ckAAxCkDCSuBQyM36x3eonABbTKM8Nii0",{"locked":10,"reason":3,"meta":775,"item":785},{"title":776,"description":777,"isFree":5,"estimatedMinutes":24,"difficulty":12,"learningObjectives":778},"RDS Monitoring and Performance Insights","Tell apart the 3 layers of RDS monitoring by where their data comes from, and read DB load in average active sessions to find which query and which wait event is actually holding the database back.",[779,780,781,782,783,784],"Distinguish CloudWatch instance metrics, Enhanced Monitoring, and Performance Insights by data source, granularity, and destination","Interpret the CloudWatch metrics that matter most for an RDS DB instance, including the 2 different burst-balance metrics","Calculate and interpret DB load in average active sessions against the Max vCPU line","Diagnose a slow database by slicing DB load by wait event and top SQL","Explain what changed when Performance Insights moved to CloudWatch Database Insights, and what Standard and Advanced modes each give you","Choose the correct monitoring layer for a given RDS symptom",{"id":786,"title":776,"body":787,"description":777,"difficulty":12,"estimatedMinutes":24,"extension":686,"infographics":2043,"isFree":5,"learningObjectives":2061,"meta":2062,"navigation":5,"path":2063,"quiz":2064,"seo":2132,"stem":2133,"__hash__":2134},"courses/courses/aws-certified-cloudops-engineer-associate/en/domains/01-monitoring-logging-performance/05-rds-performance/01-rds-monitoring-and-performance-insights.md",{"type":34,"value":788,"toc":2031},[789,808,811,814,818,822,910,913,917,927,1146,1149,1157,1179,1183,1186,1189,1192,1248,1299,1308,1312,1315,1325,1335,1338,1414,1421,1424,1428,1435,1442,1464,1467,1519,1528,1539,1542,1549,1553,1564,1629,1632,1663,1666,1670,1677,1687,1694,1698,1701,1710,1832,1838,1863,1869,1873,1981,1983,2025,2028],[37,790,791,792,795,796,799,800,803,804,807],{},"A payments API times out for about 4 minutes every morning at 09:05. You open the RDS console. ",[60,793,794],{},"CPUUtilization"," peaks at 41%. ",[60,797,798],{},"FreeableMemory"," is flat. ",[60,801,802],{},"ReadLatency"," sits at 2 milliseconds. ",[60,805,806],{},"FreeStorageSpace"," has plenty of room. Every metric you have says the database is healthy, and the database is very clearly not healthy.",[37,809,810],{},"Nothing is broken in your monitoring. You are looking at the wrong layer. CloudWatch instance metrics measure the machine the database runs on. They cannot see 30 sessions queued behind a single row lock, because a lock costs no CPU, no memory, and no I/O. It costs time, and time is not something the hypervisor can measure.",[37,812,813],{},"RDS gives you 3 monitoring layers, each looking at the database from a different place. Knowing which one answers which question is most of the skill here.",[44,815,817],{"id":816},"_3-layers-3-different-questions","3 layers, 3 different questions",[137,819],{"alt":820,"slug":821},"A stacked diagram of the 3 RDS monitoring layers, showing CloudWatch instance metrics collected outside the instance, Enhanced Monitoring collected by an agent in the operating system, and Performance Insights collected from the database engine, each with its granularity and the question it answers.","rds-monitoring-three-layers",[170,823,824,842],{},[173,825,826],{},[176,827,828,830,833,836,839],{},[179,829,195],{},[179,831,832],{},"Data source",[179,834,835],{},"Granularity",[179,837,838],{},"Where it lands",[179,840,841],{},"Question it answers",[188,843,844,865,889],{},[176,845,846,849,852,855,862],{},[193,847,848],{},"CloudWatch instance metrics",[193,850,851],{},"The hypervisor and the RDS service, outside the instance",[193,853,854],{},"60 seconds",[193,856,857,858,861],{},"CloudWatch metrics, ",[60,859,860],{},"AWS/RDS"," namespace",[193,863,864],{},"Is the machine under pressure?",[176,866,867,870,873,876,886],{},[193,868,869],{},"Enhanced Monitoring",[193,871,872],{},"An agent inside the DB instance operating system",[193,874,875],{},"1 to 60 seconds",[193,877,878,879,351,882,885],{},"CloudWatch ",[52,880,881],{},"Logs",[60,883,884],{},"RDSOSMetrics"," log group",[193,887,888],{},"Which OS process is consuming the machine?",[176,890,891,894,897,900,907],{},[193,892,893],{},"Performance Insights (now CloudWatch Database Insights)",[193,895,896],{},"The database engine itself",[193,898,899],{},"1-second samples",[193,901,902,903,906],{},"Its own dashboard, plus ",[60,904,905],{},"DBLoad"," metrics in CloudWatch",[193,908,909],{},"Which session, query, and wait event is causing the load?",[37,911,912],{},"Read that middle column again, because it is the whole lesson in one line. Layer 1 stands outside the instance and sees resource totals. Layer 2 stands inside the operating system and sees processes. Layer 3 stands inside the database engine and sees sessions. The 09:05 incident is invisible at layer 1 and obvious at layer 3.",[44,914,916],{"id":915},"the-cloudwatch-metrics-worth-watching","The CloudWatch metrics worth watching",[37,918,919,920,922,923,926],{},"RDS sends metrics to CloudWatch in 1-minute periods by default, in the ",[60,921,860],{}," namespace with a ",[60,924,925],{},"DBInstanceIdentifier"," dimension. Those 60-second data points stay available for 15 days.",[170,928,929,942],{},[173,930,931],{},[176,932,933,936,939],{},[179,934,935],{},"Metric",[179,937,938],{},"Unit",[179,940,941],{},"What it tells you",[188,943,944,956,969,981,993,1007,1023,1038,1054,1066,1081,1099,1111,1134],{},[176,945,946,950,953],{},[193,947,948],{},[60,949,794],{},[193,951,952],{},"Percent",[193,954,955],{},"CPU busy at the hypervisor level",[176,957,958,963,966],{},[193,959,960],{},[60,961,962],{},"DatabaseConnections",[193,964,965],{},"Count",[193,967,968],{},"Client network connections, not total sessions",[176,970,971,975,978],{},[193,972,973],{},[60,974,798],{},[193,976,977],{},"Bytes",[193,979,980],{},"Available RAM. A steady decline toward zero precedes swapping",[176,982,983,988,990],{},[193,984,985],{},[60,986,987],{},"SwapUsage",[193,989,977],{},[193,991,992],{},"Swap in use. Any sustained value on a database is a problem",[176,994,995,999,1001],{},[193,996,997],{},[60,998,806],{},[193,1000,977],{},[193,1002,1003,1004],{},"Free storage. Hitting zero puts the instance in ",[60,1005,1006],{},"storage-full",[176,1008,1009,1017,1020],{},[193,1010,1011,351,1014],{},[60,1012,1013],{},"ReadIOPS",[60,1015,1016],{},"WriteIOPS",[193,1018,1019],{},"Count/second",[193,1021,1022],{},"Operations completed per second, independent of I/O size",[176,1024,1025,1032,1035],{},[193,1026,1027,351,1029],{},[60,1028,802],{},[60,1030,1031],{},"WriteLatency",[193,1033,1034],{},"Seconds",[193,1036,1037],{},"Time from I/O submission to completion",[176,1039,1040,1048,1051],{},[193,1041,1042,351,1045],{},[60,1043,1044],{},"ReadThroughput",[60,1046,1047],{},"WriteThroughput",[193,1049,1050],{},"Bytes/second",[193,1052,1053],{},"Bytes moved per second",[176,1055,1056,1061,1063],{},[193,1057,1058],{},[60,1059,1060],{},"DiskQueueDepth",[193,1062,965],{},[193,1064,1065],{},"I/O requests waiting because the device is busy",[176,1067,1068,1073,1075],{},[193,1069,1070],{},[60,1071,1072],{},"BurstBalance",[193,1074,952],{},[193,1076,1077,1078],{},"gp2 burst-bucket I/O credits left, on the ",[52,1079,1080],{},"storage volume",[176,1082,1083,1091,1093],{},[193,1084,1085,351,1088],{},[60,1086,1087],{},"EBSIOBalance%",[60,1089,1090],{},"EBSByteBalance%",[193,1092,952],{},[193,1094,1095,1096],{},"EBS burst credits left, on the ",[52,1097,1098],{},"DB instance",[176,1100,1101,1106,1108],{},[193,1102,1103],{},[60,1104,1105],{},"ReplicaLag",[193,1107,1034],{},[193,1109,1110],{},"How far a read replica trails its source",[176,1112,1113,1118,1121],{},[193,1114,1115],{},[60,1116,1117],{},"CPUCreditBalance",[193,1119,1120],{},"vCPU-minutes",[193,1122,1123,1124,351,1127,351,1130,1133],{},"CPU credits on ",[60,1125,1126],{},"db.t2",[60,1128,1129],{},"db.t3",[60,1131,1132],{},"db.t4g"," classes, at 5-minute frequency only",[176,1135,1136,1141,1143],{},[193,1137,1138],{},[60,1139,1140],{},"MaximumUsedTransactionIDs",[193,1142,965],{},[193,1144,1145],{},"PostgreSQL transaction ID consumption, the wraparound warning",[37,1147,1148],{},"Two of these hide traps.",[37,1150,1151,1156],{},[52,1152,1153,1155],{},[60,1154,962],{}," is not a session count."," It counts client network connections, so it excludes sessions the engine spawns for itself, job scheduler sessions, parallel execution sessions, sessions whose network connection died before cleanup, and RDS's own management connections. The real session count is higher, sometimes much higher, and sessions are what consume connection memory.",[37,1158,1159,1167,1168,1170,1171,1163,1173,1175,1176,1178],{},[52,1160,1161,1163,1164,1166],{},[60,1162,1072],{}," and ",[60,1165,1087],{}," are different buckets."," ",[60,1169,1072],{}," is the gp2 volume's own I/O credit bucket. ",[60,1172,1087],{},[60,1174,1090],{}," describe the DB instance's EBS burst capacity, which exists on many instance sizes regardless of storage type, and they are based on the throughput of every volume including the root volume. When ",[60,1177,1090],{}," trends to zero, the instance is running out of computing capacity and the answer is a larger instance class, not more provisioned IOPS. Getting these 2 backwards leads you to buy the wrong thing.",[44,1180,1182],{"id":1181},"enhanced-monitoring-the-view-cloudwatch-cannot-give-you","Enhanced Monitoring: the view CloudWatch cannot give you",[37,1184,1185],{},"CloudWatch reads CPU from the hypervisor. Enhanced Monitoring reads it from an agent running inside the DB instance's operating system. That difference is why the 2 numbers rarely match exactly, and the gap grows on smaller instance classes where more virtual machines share one physical host.",[37,1187,1188],{},"The agent buys you something the hypervisor cannot deliver at any granularity: a per-process and per-thread breakdown. When CPU is at 90% and you need to know whether that is the database engine, a backup, or a runaway maintenance thread, this is the only layer that answers.",[37,1190,1191],{},"The details that get tested:",[375,1193,1194,1203,1217,1239,1245],{},[378,1195,1196,1198,1199,1202],{},[52,1197,835],{}," is 1, 5, 10, 15, 30, or 60 seconds. Setting ",[60,1200,1201],{},"--monitoring-interval 0"," turns it off.",[378,1204,1205,1206,1209,1210,1212,1213,1216],{},"Metrics go to ",[52,1207,1208],{},"CloudWatch Logs",", in the ",[60,1211,884],{}," log group, with a default retention of ",[52,1214,1215],{},"30 days",". You change that on the log group, not on the DB instance.",[378,1218,1219,1220,1223,1224,1227,1228,1231,1232,1235,1236,423],{},"It needs an ",[52,1221,1222],{},"IAM role",". The console can create ",[60,1225,1226],{},"rds-monitoring-role"," for you; via CLI or API you create it yourself with the ",[60,1229,1230],{},"AmazonRDSEnhancedMonitoringRole"," policy and a trust relationship for the ",[60,1233,1234],{},"monitoring.rds.amazonaws.com"," service principal. The caller needs ",[60,1237,1238],{},"iam:PassRole",[378,1240,1241,1242,423],{},"Turning it on ",[52,1243,1244],{},"does not require a reboot",[378,1246,1247],{},"The RDS console refreshes at best every 5 seconds. If you set 1-second granularity, you get the 1-second data from CloudWatch Logs, not from the console.",[69,1249,1251],{"className":71,"code":1250,"language":73,"meta":74,"style":74},"aws rds modify-db-instance \\\n  --db-instance-identifier payments-prod \\\n  --monitoring-interval 5 \\\n  --monitoring-role-arn arn:aws:iam::123456789012:role/rds-monitoring-role\n",[60,1252,1253,1268,1279,1290],{"__ignoreMap":74},[78,1254,1255,1258,1261,1264],{"class":80,"line":81},[78,1256,1257],{"class":84},"aws",[78,1259,1260],{"class":88}," rds",[78,1262,1263],{"class":88}," modify-db-instance",[78,1265,1267],{"class":1266},"s_hVV"," \\\n",[78,1269,1270,1274,1277],{"class":80,"line":95},[78,1271,1273],{"class":1272},"stzsN","  --db-instance-identifier",[78,1275,1276],{"class":88}," payments-prod",[78,1278,1267],{"class":1266},[78,1280,1281,1284,1288],{"class":80,"line":101},[78,1282,1283],{"class":1272},"  --monitoring-interval",[78,1285,1287],{"class":1286},"srdBf"," 5",[78,1289,1267],{"class":1266},[78,1291,1293,1296],{"class":80,"line":1292},4,[78,1294,1295],{"class":1272},"  --monitoring-role-arn",[78,1297,1298],{"class":88}," arn:aws:iam::123456789012:role/rds-monitoring-role\n",[37,1300,1301,1302,1304,1305,1307],{},"Here is the misconception this layer creates. Because the RDS console draws Enhanced Monitoring as graphs, people assume they can alarm on those values the way they alarm on ",[60,1303,794],{},". They cannot, not directly. Enhanced Monitoring output is log events, so alarming on it means creating a CloudWatch Logs metric filter over ",[60,1306,884],{}," first, then alarming on the metric that filter produces.",[44,1309,1311],{"id":1310},"db-load-the-metric-that-answers-why","DB load: the metric that answers \"why\"",[37,1313,1314],{},"Layer 3 measures something different from every metric above. Not a resource, but work in progress.",[37,1316,150,1317,1320,1321,1324],{},[52,1318,1319],{},"session"," is an application's conversation with the database. A session is ",[52,1322,1323],{},"active"," when it has submitted work and is waiting for an answer: either running on CPU, or waiting for a resource such as a page to be read into memory, a lock to be released, or a log write to complete. Idle sessions do not count.",[37,1326,1327,1330,1331,1334],{},[52,1328,1329],{},"DB load"," is the number of active sessions, and its unit is ",[52,1332,1333],{},"average active sessions (AAS)",". Performance Insights samples the count once per second. AAS is the total sessions counted divided by the number of samples.",[37,1336,1337],{},"Take 5 consecutive 1-second samples:",[170,1339,1340,1356],{},[173,1341,1342],{},[176,1343,1344,1347,1350,1353],{},[179,1345,1346],{},"Sample",[179,1348,1349],{},"Sessions running a query",[179,1351,1352],{},"Running total",[179,1354,1355],{},"AAS so far",[188,1357,1358,1369,1380,1391,1402],{},[176,1359,1360,1362,1364,1366],{},[193,1361,282],{},[193,1363,279],{},[193,1365,279],{},[193,1367,1368],{},"2.0",[176,1370,1371,1373,1375,1377],{},[193,1372,279],{},[193,1374,617],{},[193,1376,279],{},[193,1378,1379],{},"1.0",[176,1381,1382,1384,1386,1389],{},[193,1383,204],{},[193,1385,201],{},[193,1387,1388],{},"6",[193,1390,1368],{},[176,1392,1393,1395,1397,1399],{},[193,1394,201],{},[193,1396,617],{},[193,1398,1388],{},[193,1400,1401],{},"1.5",[176,1403,1404,1407,1409,1412],{},[193,1405,1406],{},"5",[193,1408,201],{},[193,1410,1411],{},"10",[193,1413,1368],{},[37,1415,1416,1417,1420],{},"DB load for that interval is ",[52,1418,1419],{},"2 AAS",": on average, 2 sessions were active at any moment. The averaging matters. A 1-second spike to 40 sessions barely moves AAS, while 5 sessions stuck for a full minute pushes it hard. That is the right bias, because a database is hurt by sustained queueing, not by momentary bursts.",[37,1422,1423],{},"For each active session it samples, Performance Insights also captures the SQL statement, whether the session was on CPU or waiting, the host, and the user. Those 4 pieces of information are what make the number actionable rather than merely interesting.",[44,1425,1427],{"id":1426},"reading-the-chart-max-vcpu-waits-and-top-sql","Reading the chart: Max vCPU, waits, and top SQL",[37,1429,1430,1431,1434],{},"The DB load chart draws a horizontal line at the DB instance's vCPU count, labeled ",[52,1432,1433],{},"Max vCPU",". This is the reference that turns an abstract number into a verdict.",[37,1436,1437,1438,1441],{},"Work through it on a ",[60,1439,1440],{},"db.r6g.2xlarge",", which has 8 vCPUs:",[375,1443,1444,1451,1458],{},[378,1445,1446,1447,1450],{},"DB load steady at ",[52,1448,1449],{},"3 AAS",": 3 sessions active against 8 vCPUs of capacity. Comfortable.",[378,1452,1453,1454,1457],{},"DB load at ",[52,1455,1456],{},"8 AAS, nearly all on CPU",": the instance is saturated on CPU. More vCPUs would help.",[378,1459,1453,1460,1463],{},[52,1461,1462],{},"21 AAS with 18 of them waiting",": 21 sessions are active but only a few are doing work. The other 18 are queued behind something. Adding vCPUs changes nothing, because CPU was never the constraint.",[37,1465,1466],{},"That last case is the one people misread, and it is exactly why the load is split into 2 CloudWatch metrics:",[170,1468,1469,1478],{},[173,1470,1471],{},[176,1472,1473,1475],{},[179,1474,935],{},[179,1476,1477],{},"Meaning",[188,1479,1480,1489,1499,1509],{},[176,1481,1482,1486],{},[193,1483,1484],{},[60,1485,905],{},[193,1487,1488],{},"All active sessions",[176,1490,1491,1496],{},[193,1492,1493],{},[60,1494,1495],{},"DBLoadCPU",[193,1497,1498],{},"Active sessions whose wait event type is CPU",[176,1500,1501,1506],{},[193,1502,1503],{},[60,1504,1505],{},"DBLoadNonCPU",[193,1507,1508],{},"Active sessions waiting on anything else",[176,1510,1511,1516],{},[193,1512,1513],{},[60,1514,1515],{},"DBLoadRelativeToNumVCPUs",[193,1517,1518],{},"DB load divided by the vCPU count",[37,1520,1521,1523,1524,1527],{},[60,1522,1505],{}," dominating is the signal to stop looking at instance size and start looking at what the sessions are waiting for. That is what the ",[52,1525,1526],{},"wait event"," dimension is for. Slice DB load by wait event and you usually find 2 or 3 events accounting for most of the load: I/O reads, row locks, log flushes. The specific names vary by engine, but the shape of the answer does not.",[37,1529,1530,1531,1534,1535,1538],{},"Then slice by ",[52,1532,1533],{},"top SQL"," to find which statements are producing that wait. It is common for one query out of hundreds to account for the majority of DB load. Performance Insights also captures ",[52,1536,1537],{},"execution plans"," for the most resource-intensive queries every 5 minutes, so you can see how the engine chose to run the query that is hurting you. You can also slice by host and by user, which is how you identify a single misbehaving application server or reporting account.",[37,1540,1541],{},"The workflow, in order: DB load says how bad, wait events say what kind of bad, top SQL says who is causing it, and the plan says why that query is slow.",[37,1543,1544,1545,1548],{},"Back to the 09:05 incident. DB load spikes to 25 AAS on an 8 vCPU instance, almost entirely on a row lock wait event, and top SQL shows a single ",[60,1546,1547],{},"UPDATE"," against the accounts table. A nightly batch job holds a long transaction, and the API's writes queue behind it. No resource metric would ever have shown you that, because no resource was under pressure.",[44,1550,1552],{"id":1551},"performance-insights-is-now-cloudwatch-database-insights","Performance Insights is now CloudWatch Database Insights",[37,1554,1555,1556,1559,1560,1563],{},"AWS retired the Performance Insights console on ",[52,1557,1558],{},"31 July 2026",". The console now redirects to ",[52,1561,1562],{},"CloudWatch Database Insights",". Nothing about the underlying measurement changed: it is the same DB load, the same average active sessions, the same wait events and top SQL. What changed is where you look at it and how it is packaged.",[170,1565,1566,1578],{},[173,1567,1568],{},[176,1569,1570,1572,1575],{},[179,1571],{},[179,1573,1574],{},"Standard mode",[179,1576,1577],{},"Advanced mode",[188,1579,1580,1590,1601,1611,1620],{},[176,1581,1582,1585,1588],{},[193,1583,1584],{},"DB load, waits, top SQL, hosts, users",[193,1586,1587],{},"Yes",[193,1589,1587],{},[176,1591,1592,1595,1598],{},[193,1593,1594],{},"Retention",[193,1596,1597],{},"The same flexible periods as before, at the same cost",[193,1599,1600],{},"Same, plus advanced telemetry",[176,1602,1603,1606,1609],{},[193,1604,1605],{},"Fleet-level monitoring across databases",[193,1607,1608],{},"No",[193,1610,1587],{},[176,1612,1613,1616,1618],{},[193,1614,1615],{},"Lock diagnostics",[193,1617,1608],{},[193,1619,1587],{},[176,1621,1622,1625,1627],{},[193,1623,1624],{},"Execution plan capture and on-demand analysis",[193,1626,1608],{},[193,1628,1587],{},[37,1630,1631],{},"The things worth remembering:",[375,1633,1634,1640,1653,1658],{},[378,1635,1636,1639],{},[52,1637,1638],{},"Standard mode is the default",", and it is what instances using Performance Insights fell back to automatically, keeping their existing retention period.",[378,1641,1642,1645,1646,1163,1649,1652],{},[52,1643,1644],{},"The Performance Insights API did not change."," CloudFormation templates, Terraform configurations, and scripts that set ",[60,1647,1648],{},"PerformanceInsightsEnabled",[60,1650,1651],{},"PerformanceInsightsRetentionPeriod"," keep working exactly as written.",[378,1654,1655,1657],{},[52,1656,1594],{}," is still 7 days by default at no extra cost, or 1 to 24 months on a paid tier.",[378,1659,1660,1661,423],{},"Execution plans and on-demand analysis now require ",[52,1662,1577],{},[37,1664,1665],{},"For the exam, treat \"Performance Insights\" and \"the DB load view in Database Insights\" as the same answer. A question that describes finding the top SQL statement behind a load spike is pointing at this layer either way.",[44,1667,1669],{"id":1668},"proactive-recommendations","Proactive recommendations",[37,1671,1672,1673,1676],{},"Performance Insights watches selected metrics, learns a threshold from that specific resource's own baseline, and raises a ",[52,1674,1675],{},"proactive recommendation"," when values cross it for long enough. The point is to catch a problem while it is still developing rather than after it pages you.",[37,1678,1679,1680,1683,1684,1686],{},"Recommendations appear in the RDS console, either on the account-wide ",[52,1681,1682],{},"Recommendations"," page sorted by severity, or on the ",[52,1685,1682],{}," tab of a single database. Each one gives you the detected issue, graphs of the metric against its learned threshold, and an analysis explaining the suggested action. You act on it or dismiss it.",[37,1688,1689,1690,1693],{},"One requirement that gets tested: ",[52,1691,1692],{},"proactive recommendations need a paid retention tier",". The free 7-day retention is not enough for the feature to build a baseline, so an instance on default retention produces none.",[44,1695,1697],{"id":1696},"alarming-on-the-right-layer","Alarming on the right layer",[37,1699,1700],{},"Alarms behave differently per layer, and this is where the layers stop being an academic distinction.",[37,1702,1703,1706,1707,1709],{},[52,1704,1705],{},"Layer 1"," is straightforward. ",[60,1708,860],{}," metrics are ordinary CloudWatch metrics, so an alarm is a normal alarm:",[69,1711,1713],{"className":71,"code":1712,"language":73,"meta":74,"style":74},"aws cloudwatch put-metric-alarm \\\n  --alarm-name payments-prod-low-storage \\\n  --namespace AWS/RDS \\\n  --metric-name FreeStorageSpace \\\n  --dimensions Name=DBInstanceIdentifier,Value=payments-prod \\\n  --statistic Average \\\n  --period 300 \\\n  --evaluation-periods 2 \\\n  --threshold 10737418240 \\\n  --comparison-operator LessThanThreshold \\\n  --alarm-actions arn:aws:sns:us-east-1:123456789012:dba-oncall\n",[60,1714,1715,1727,1737,1747,1757,1768,1779,1790,1801,1812,1823],{"__ignoreMap":74},[78,1716,1717,1719,1722,1725],{"class":80,"line":81},[78,1718,1257],{"class":84},[78,1720,1721],{"class":88}," cloudwatch",[78,1723,1724],{"class":88}," put-metric-alarm",[78,1726,1267],{"class":1266},[78,1728,1729,1732,1735],{"class":80,"line":95},[78,1730,1731],{"class":1272},"  --alarm-name",[78,1733,1734],{"class":88}," payments-prod-low-storage",[78,1736,1267],{"class":1266},[78,1738,1739,1742,1745],{"class":80,"line":101},[78,1740,1741],{"class":1272},"  --namespace",[78,1743,1744],{"class":88}," AWS/RDS",[78,1746,1267],{"class":1266},[78,1748,1749,1752,1755],{"class":80,"line":1292},[78,1750,1751],{"class":1272},"  --metric-name",[78,1753,1754],{"class":88}," FreeStorageSpace",[78,1756,1267],{"class":1266},[78,1758,1760,1763,1766],{"class":80,"line":1759},5,[78,1761,1762],{"class":1272},"  --dimensions",[78,1764,1765],{"class":88}," Name=DBInstanceIdentifier,Value=payments-prod",[78,1767,1267],{"class":1266},[78,1769,1771,1774,1777],{"class":80,"line":1770},6,[78,1772,1773],{"class":1272},"  --statistic",[78,1775,1776],{"class":88}," Average",[78,1778,1267],{"class":1266},[78,1780,1782,1785,1788],{"class":80,"line":1781},7,[78,1783,1784],{"class":1272},"  --period",[78,1786,1787],{"class":1286}," 300",[78,1789,1267],{"class":1266},[78,1791,1793,1796,1799],{"class":80,"line":1792},8,[78,1794,1795],{"class":1272},"  --evaluation-periods",[78,1797,1798],{"class":1286}," 2",[78,1800,1267],{"class":1266},[78,1802,1804,1807,1810],{"class":80,"line":1803},9,[78,1805,1806],{"class":1272},"  --threshold",[78,1808,1809],{"class":1286}," 10737418240",[78,1811,1267],{"class":1266},[78,1813,1815,1818,1821],{"class":80,"line":1814},10,[78,1816,1817],{"class":1272},"  --comparison-operator",[78,1819,1820],{"class":88}," LessThanThreshold",[78,1822,1267],{"class":1266},[78,1824,1826,1829],{"class":80,"line":1825},11,[78,1827,1828],{"class":1272},"  --alarm-actions",[78,1830,1831],{"class":88}," arn:aws:sns:us-east-1:123456789012:dba-oncall\n",[37,1833,1834,1837],{},[52,1835,1836],{},"Layer 2"," needs a CloudWatch Logs metric filter first, because Enhanced Monitoring produces log events.",[37,1839,1840,1843,1844,351,1846,351,1848,355,1850,1852,1853,1855,1856,1862],{},[52,1841,1842],{},"Layer 3"," is split. The ",[60,1845,905],{},[60,1847,1495],{},[60,1849,1505],{},[60,1851,1515],{}," metrics are published to CloudWatch in the ",[60,1854,860],{}," namespace, so you alarm on them normally. Every other Performance Insights counter metric is not published directly, and you reach it with the ",[52,1857,1858,1861],{},[60,1859,1860],{},"DB_PERF_INSIGHTS"," metric math function",", which turns it into a time series you can graph and alarm on, including sub-minute high-resolution alarms.",[37,1864,1865,1866,1868],{},"One behavior to expect: the ",[60,1867,905],{}," metrics are only published when there is load on the instance. Gaps in the graph on a quiet database are normal, so configure how your alarm treats missing data rather than reading a gap as a failure.",[44,1870,1872],{"id":1871},"which-layer-answers-which-symptom","Which layer answers which symptom",[170,1874,1875,1887],{},[173,1876,1877],{},[176,1878,1879,1882,1884],{},[179,1880,1881],{},"Symptom",[179,1883,195],{},[179,1885,1886],{},"What to look at",[188,1888,1889,1899,1909,1921,1932,1947,1960,1971],{},[176,1890,1891,1894,1896],{},[193,1892,1893],{},"Application is slow, all resource metrics look normal",[193,1895,204],{},[193,1897,1898],{},"DB load by wait event, then top SQL",[176,1900,1901,1904,1906],{},[193,1902,1903],{},"CPU at 95%, need to know what is using it",[193,1905,279],{},[193,1907,1908],{},"Enhanced Monitoring process list",[176,1910,1911,1914,1916],{},[193,1912,1913],{},"CPU at 95%, need to know if it is the database's own queries",[193,1915,204],{},[193,1917,1918,1920],{},[60,1919,1495],{}," and top SQL",[176,1922,1923,1926,1928],{},[193,1924,1925],{},"Storage filling up",[193,1927,282],{},[193,1929,1930],{},[60,1931,806],{},[176,1933,1934,1937,1939],{},[193,1935,1936],{},"Storage slow after roughly 30 minutes of heavy work",[193,1938,282],{},[193,1940,1941,1943,1944,1946],{},[60,1942,1072],{}," on gp2, or ",[60,1945,1087],{}," for the instance",[176,1948,1949,1952,1955],{},[193,1950,1951],{},"\"Too many connections\" errors",[193,1953,1954],{},"1 then 3",[193,1956,1957,1959],{},[60,1958,962],{},", then sessions by host and user",[176,1961,1962,1965,1967],{},[193,1963,1964],{},"Read replica serving stale data",[193,1966,282],{},[193,1968,1969],{},[60,1970,1105],{},[176,1972,1973,1976,1978],{},[193,1974,1975],{},"One query got slow after a data load",[193,1977,204],{},[193,1979,1980],{},"Top SQL and its execution plan",[44,1982,640],{"id":639},[375,1984,1985,1988,1991,1997,2000,2003,2013,2016],{},[378,1986,1987],{},"\"All CloudWatch metrics look normal but the database is slow\" is a Performance Insights question every time. Resource metrics cannot see waiting.",[378,1989,1990],{},"\"Process-level\" or \"per-process CPU and memory on the DB instance\" points at Enhanced Monitoring, and only Enhanced Monitoring. You cannot install the CloudWatch agent on an RDS instance, so any option offering to do so is wrong on its face.",[378,1992,1993,1994,1996],{},"Enhanced Monitoring goes to CloudWatch ",[52,1995,881],{},". If an answer says its metrics appear directly in CloudWatch metrics, eliminate it.",[378,1998,1999],{},"Watch the granularity numbers: CloudWatch metrics at 60 seconds, Enhanced Monitoring at 1 to 60 seconds, Performance Insights sampling at 1 second.",[378,2001,2002],{},"Max vCPU is a reference line, not a hard limit. DB load above it means queueing, and only the CPU-versus-non-CPU split tells you whether a bigger instance is the answer.",[378,2004,2005,2007,2008,1163,2010,2012],{},[60,2006,1072],{}," is the gp2 volume. ",[60,2009,1087],{},[60,2011,1090],{}," are the DB instance. Different buckets, different fixes.",[378,2014,2015],{},"Proactive recommendations require paid retention. Free 7-day retention gets you the dashboard, not the recommendations.",[378,2017,2018,2020,2021,2024],{},[60,2019,1117],{}," only exists on ",[60,2022,2023],{},"db.t"," classes and is published at 5-minute frequency, so a 1-minute alarm period on it will not behave the way you expect.",[37,2026,2027],{},"The one thing to retain: choose the monitoring layer by where the answer lives, not by which console you opened first. Resource metrics tell you the machine is fine; DB load tells you the database is not. The next lesson takes the most common cause of that gap, sessions piling up faster than the database can serve them, and fixes it with connection pooling and a short list of tuning levers.",[673,2029,2030],{},"html pre.shiki code .sbgvK, html code.shiki .sbgvK{--shiki-light:#E2931D;--shiki-default:#6F42C1;--shiki-dark:#B392F0}html pre.shiki code .s_sjI, html code.shiki .s_sjI{--shiki-light:#91B859;--shiki-default:#032F62;--shiki-dark:#9ECBFF}html pre.shiki code .s_hVV, html code.shiki .s_hVV{--shiki-light:#90A4AE;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .stzsN, html code.shiki .stzsN{--shiki-light:#91B859;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .srdBf, html code.shiki .srdBf{--shiki-light:#F76D47;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":74,"searchDepth":101,"depth":101,"links":2032},[2033,2034,2035,2036,2037,2038,2039,2040,2041,2042],{"id":816,"depth":95,"text":817},{"id":915,"depth":95,"text":916},{"id":1181,"depth":95,"text":1182},{"id":1310,"depth":95,"text":1311},{"id":1426,"depth":95,"text":1427},{"id":1551,"depth":95,"text":1552},{"id":1668,"depth":95,"text":1669},{"id":1696,"depth":95,"text":1697},{"id":1871,"depth":95,"text":1872},{"id":639,"depth":95,"text":640},[2044],{"slug":821,"concept":2045,"style":2046,"aspectRatio":691,"labels":2047},"A stacked diagram of the 3 RDS monitoring layers, drawn as 3 horizontal bands moving from outside the database inward. The top band is CloudWatch instance metrics collected outside the DB instance, the middle band is Enhanced Monitoring collected by an agent inside the operating system, and the bottom band is Performance Insights collected from the database engine itself. Each band carries its data source, its granularity, where the data lands, and the one question it answers. A footer states that a symptom invisible at the top layer is often obvious at the bottom one.","diagram",[2048,2049,2050,2051,2052,2053,2054,2055,2056,2057,2058,2059,2060],"Layer 1: CloudWatch instance metrics","Source: the hypervisor and the RDS service, outside the DB instance","Granularity: 60 seconds, stored as metrics in the AWS/RDS namespace","Answers: is the machine under pressure? CPU, memory, storage, IOPS, connections","Layer 2: Enhanced Monitoring","Source: an agent running inside the DB instance operating system","Granularity: 1 to 60 seconds, delivered to CloudWatch Logs in RDSOSMetrics","Answers: which OS process or thread is consuming the machine?","Layer 3: Performance Insights and Database Insights","Source: the database engine, sampled once per second","Granularity: 1 second, reported as DB load in average active sessions","Answers: which session, SQL statement, and wait event is causing the load?","A problem invisible at layer 1 is often obvious at layer 3, because the layers measure different things.",[779,780,781,782,783,784],{},"/courses/aws-certified-cloudops-engineer-associate/en/domains/01-monitoring-logging-performance/05-rds-performance/01-rds-monitoring-and-performance-insights",{"passingScore":709,"questions":2065},[2066,2074,2082,2090,2098,2108,2112,2116,2124],{"question":2067,"type":713,"options":2068,"correctAnswer":2071,"explanation":2073},"Performance Insights samples 5 consecutive seconds and finds 2, 0, 4, 0, and 4 sessions running a query. What DB load does it report for that interval?",[2069,2070,2071,2072],"4 average active sessions, the peak value","10 average active sessions, the total","2 average active sessions","0 average active sessions, because 2 of the samples were idle","Average active sessions is the total number of sampled sessions divided by the number of samples: 10 sessions over 5 samples is 2 AAS. The metric is deliberately an average rather than a peak, so a short spike raises it only in proportion to how long it lasted, which is why AAS is comparable against the vCPU count.",{"question":2075,"type":713,"options":2076,"correctAnswer":2078,"explanation":2081},"A db.r6g.2xlarge DB instance has 8 vCPUs. Performance Insights shows DB load at 21 AAS, with roughly 18 of those sessions on non-CPU wait events. What does this tell you?",[2077,2078,2079,2080],"The instance needs more vCPUs, because DB load is well above 8","Sessions are queued waiting for a resource other than CPU, so adding vCPUs is unlikely to help","Performance Insights is misconfigured, since DB load cannot exceed the vCPU count","The database is healthy, because 21 AAS is a normal reading","The Max vCPU line tells you how much CPU work the instance can do at once, but exceeding it only points to CPU when the load is CPU wait events. Here the split between DBLoadCPU and DBLoadNonCPU shows most sessions waiting on I/O or locks, so the fix lives in storage, queries, or contention, not in a bigger CPU count.",{"question":2083,"type":713,"options":2084,"correctAnswer":2085,"explanation":2089},"Where does Enhanced Monitoring deliver its metrics?",[2085,2086,2087,2088],"To CloudWatch Logs, in the RDSOSMetrics log group","To CloudWatch metrics, in the AWS/RDS namespace","To the Performance Insights dashboard only","To an S3 bucket you specify when you enable it","Enhanced Monitoring publishes JSON documents to CloudWatch Logs, not to CloudWatch metrics, which is why its default retention is 30 days and why you need a metric filter before you can alarm on any of its values. Standard RDS metrics like CPUUtilization go to the AWS/RDS metric namespace instead.",{"question":2091,"type":713,"options":2092,"correctAnswer":2095,"explanation":2097},"Why can Enhanced Monitoring report a different CPU number than the CloudWatch CPUUtilization metric for the same DB instance?",[2093,2094,2095,2096],"Enhanced Monitoring reports a 5-minute average while CloudWatch reports an instantaneous value","CloudWatch measures only user CPU while Enhanced Monitoring includes system CPU","CloudWatch measures CPU at the hypervisor while Enhanced Monitoring measures it with an agent inside the instance","Enhanced Monitoring excludes the database engine's own processes","The hypervisor does a small amount of work of its own, so the 2 vantage points do not agree exactly, and the gap widens on smaller instance classes where more guests share a physical host. The agent view is also the only one that can break the number down per process.",{"question":2099,"type":722,"options":2100,"correctAnswers":2106,"explanation":2107},"Which statements about Performance Insights data retention and proactive recommendations are correct? (Choose 2.)",[2101,2102,2103,2104,2105],"The default retention is 7 days at no additional cost","The default retention is 30 days at no additional cost","Longer retention can be set from 1 to 24 months","Longer retention can be set from 1 to 24 weeks","Proactive recommendations are available on the free default retention",[2101,2103],"The free default keeps 7 days of performance data, and paid retention runs from 1 to 24 months. Proactive recommendations need a paid retention tier, because the feature builds a baseline for the resource over time and cannot do that from a week of data.",{"question":2109,"type":713,"options":2110,"correctAnswer":1072,"explanation":2111},"An RDS for MySQL instance runs on gp2 storage. Which metric warns you that its storage is about to be clamped to baseline IOPS?",[1087,1060,1072,806],"BurstBalance is the percentage of gp2 burst-bucket I/O credits left on the storage volume, so a downward trend predicts the slowdown before latency shows it. EBSIOBalance% looks similar but describes a different bucket, the DB instance's own EBS burst capacity, and it applies regardless of the storage type.",{"question":2113,"type":713,"options":2114,"correctAnswer":750,"explanation":2115},"True or False: after the Performance Insights console reached end of life, the Performance Insights API stopped working and existing CloudFormation and Terraform definitions had to be rewritten.",[749,750],"Only the console experience was retired, and it now redirects to CloudWatch Database Insights. The API is unchanged, all Performance Insights parameters including retention are preserved, and instances that took no action default to Standard mode with the retention period they already had.",{"question":2117,"type":713,"options":2118,"correctAnswer":2120,"explanation":2123},"A dashboard shows DatabaseConnections at 180 while the DBA reports well over 200 sessions on the same instance. What explains the gap?",[2119,2120,2121,2122],"DatabaseConnections is a 5-minute average, so it lags the real count","The metric counts client network connections and excludes engine-internal, scheduler, and RDS management sessions","The metric caps at the value of max_connections in the parameter group","Read replica sessions are counted on the replica, not on the primary","DatabaseConnections is a count of client network connections, so sessions the engine creates for itself, job scheduler sessions, parallel execution sessions, and RDS's own connections do not appear in it. Reading it as a session count makes you underestimate the real pressure on connection memory.",{"question":2125,"type":713,"options":2126,"correctAnswer":2130,"explanation":2131},"You need a CloudWatch alarm on a Performance Insights counter metric that RDS does not publish to CloudWatch directly. What lets you do this?",[2127,2128,2129,2130],"A CloudWatch Logs metric filter over the RDSOSMetrics log group","A custom metric published by the CloudWatch agent installed on the DB instance","An EventBridge rule matching RDS performance events","The DB_PERF_INSIGHTS metric math function in CloudWatch","Only the DBLoad family is published to CloudWatch as ordinary metrics, so counter metrics need the DB_PERF_INSIGHTS metric math function to become an alarmable time series. You cannot install the CloudWatch agent on an RDS DB instance at all, since you have no OS access, which rules that option out immediately.",{"title":776,"description":777},"courses/aws-certified-cloudops-engineer-associate/en/domains/01-monitoring-logging-performance/05-rds-performance/01-rds-monitoring-and-performance-insights","B3MG0yIhcgxQz_1sxUZLU2WYm_AfYVn4AnhED3Ynx90"]