[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"prev-aws-certified-cloudops-engineer-associate-monitoring-logging-performance-rds-performance-rds-monitoring-and-performance-insights-en":4,"lesson-aws-certified-cloudops-engineer-associate-monitoring-logging-performance-rds-performance-rds-monitoring-and-performance-insights-en":20,"next-aws-certified-cloudops-engineer-associate-monitoring-logging-performance-rds-performance-rds-monitoring-and-performance-insights-en":1426},null,{"locked":5,"reason":6,"meta":7,"item":3},true,"paywall",{"title":8,"description":9,"isFree":10,"estimatedMinutes":11,"difficulty":12,"learningObjectives":13},"EFS and FSx Shared Storage","Choose and tune shared file storage on AWS: EFS performance and throughput modes, lifecycle policies, the four FSx file systems, and the protocol question that decides between them.",false,26,"intermediate",[14,15,16,17,18,19],"Explain why EBS cannot serve a fleet that shares files, and what shared storage provides instead","Compare EFS performance modes and throughput modes, and choose the right one from a workload description","Calculate the baseline and burst throughput of an EFS file system using Bursting throughput","Configure EFS lifecycle policies to move cold data into IA and Archive storage","Match each FSx file system and Mountpoint for Amazon S3 to the protocol and workload it serves","Diagnose an FSx for Windows File Server performance ceiling using throughput capacity and storage configuration",{"locked":10,"reason":3,"meta":21,"item":31},{"title":22,"description":23,"isFree":5,"estimatedMinutes":11,"difficulty":12,"learningObjectives":24},"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.",[25,26,27,28,29,30],"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":32,"title":22,"body":33,"description":23,"difficulty":12,"estimatedMinutes":11,"extension":1327,"infographics":1328,"isFree":5,"learningObjectives":1347,"meta":1348,"navigation":5,"path":1349,"quiz":1350,"seo":1423,"stem":1424,"__hash__":1425},"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":35,"toc":1315},"minimark",[36,57,60,63,68,73,170,173,177,187,406,409,417,439,443,446,449,452,511,573,582,586,589,600,610,613,694,701,704,708,715,722,744,747,799,808,819,822,829,833,844,909,912,943,946,950,957,967,974,978,981,990,1112,1118,1144,1150,1154,1262,1266,1308,1311],[37,38,39,40,44,45,48,49,52,53,56],"p",{},"A payments API times out for about 4 minutes every morning at 09:05. You open the RDS console. ",[41,42,43],"code",{},"CPUUtilization"," peaks at 41%. ",[41,46,47],{},"FreeableMemory"," is flat. ",[41,50,51],{},"ReadLatency"," sits at 2 milliseconds. ",[41,54,55],{},"FreeStorageSpace"," has plenty of room. Every metric you have says the database is healthy, and the database is very clearly not healthy.",[37,58,59],{},"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,61,62],{},"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.",[64,65,67],"h2",{"id":66},"_3-layers-3-different-questions","3 layers, 3 different questions",[69,70],"infographic",{"alt":71,"slug":72},"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",[74,75,76,98],"table",{},[77,78,79],"thead",{},[80,81,82,86,89,92,95],"tr",{},[83,84,85],"th",{},"Layer",[83,87,88],{},"Data source",[83,90,91],{},"Granularity",[83,93,94],{},"Where it lands",[83,96,97],{},"Question it answers",[99,100,101,123,149],"tbody",{},[80,102,103,107,110,113,120],{},[104,105,106],"td",{},"CloudWatch instance metrics",[104,108,109],{},"The hypervisor and the RDS service, outside the instance",[104,111,112],{},"60 seconds",[104,114,115,116,119],{},"CloudWatch metrics, ",[41,117,118],{},"AWS/RDS"," namespace",[104,121,122],{},"Is the machine under pressure?",[80,124,125,128,131,134,146],{},[104,126,127],{},"Enhanced Monitoring",[104,129,130],{},"An agent inside the DB instance operating system",[104,132,133],{},"1 to 60 seconds",[104,135,136,137,141,142,145],{},"CloudWatch ",[138,139,140],"strong",{},"Logs",", ",[41,143,144],{},"RDSOSMetrics"," log group",[104,147,148],{},"Which OS process is consuming the machine?",[80,150,151,154,157,160,167],{},[104,152,153],{},"Performance Insights (now CloudWatch Database Insights)",[104,155,156],{},"The database engine itself",[104,158,159],{},"1-second samples",[104,161,162,163,166],{},"Its own dashboard, plus ",[41,164,165],{},"DBLoad"," metrics in CloudWatch",[104,168,169],{},"Which session, query, and wait event is causing the load?",[37,171,172],{},"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.",[64,174,176],{"id":175},"the-cloudwatch-metrics-worth-watching","The CloudWatch metrics worth watching",[37,178,179,180,182,183,186],{},"RDS sends metrics to CloudWatch in 1-minute periods by default, in the ",[41,181,118],{}," namespace with a ",[41,184,185],{},"DBInstanceIdentifier"," dimension. Those 60-second data points stay available for 15 days.",[74,188,189,202],{},[77,190,191],{},[80,192,193,196,199],{},[83,194,195],{},"Metric",[83,197,198],{},"Unit",[83,200,201],{},"What it tells you",[99,203,204,216,229,241,253,267,283,298,314,326,341,359,371,394],{},[80,205,206,210,213],{},[104,207,208],{},[41,209,43],{},[104,211,212],{},"Percent",[104,214,215],{},"CPU busy at the hypervisor level",[80,217,218,223,226],{},[104,219,220],{},[41,221,222],{},"DatabaseConnections",[104,224,225],{},"Count",[104,227,228],{},"Client network connections, not total sessions",[80,230,231,235,238],{},[104,232,233],{},[41,234,47],{},[104,236,237],{},"Bytes",[104,239,240],{},"Available RAM. A steady decline toward zero precedes swapping",[80,242,243,248,250],{},[104,244,245],{},[41,246,247],{},"SwapUsage",[104,249,237],{},[104,251,252],{},"Swap in use. Any sustained value on a database is a problem",[80,254,255,259,261],{},[104,256,257],{},[41,258,55],{},[104,260,237],{},[104,262,263,264],{},"Free storage. Hitting zero puts the instance in ",[41,265,266],{},"storage-full",[80,268,269,277,280],{},[104,270,271,141,274],{},[41,272,273],{},"ReadIOPS",[41,275,276],{},"WriteIOPS",[104,278,279],{},"Count/second",[104,281,282],{},"Operations completed per second, independent of I/O size",[80,284,285,292,295],{},[104,286,287,141,289],{},[41,288,51],{},[41,290,291],{},"WriteLatency",[104,293,294],{},"Seconds",[104,296,297],{},"Time from I/O submission to completion",[80,299,300,308,311],{},[104,301,302,141,305],{},[41,303,304],{},"ReadThroughput",[41,306,307],{},"WriteThroughput",[104,309,310],{},"Bytes/second",[104,312,313],{},"Bytes moved per second",[80,315,316,321,323],{},[104,317,318],{},[41,319,320],{},"DiskQueueDepth",[104,322,225],{},[104,324,325],{},"I/O requests waiting because the device is busy",[80,327,328,333,335],{},[104,329,330],{},[41,331,332],{},"BurstBalance",[104,334,212],{},[104,336,337,338],{},"gp2 burst-bucket I/O credits left, on the ",[138,339,340],{},"storage volume",[80,342,343,351,353],{},[104,344,345,141,348],{},[41,346,347],{},"EBSIOBalance%",[41,349,350],{},"EBSByteBalance%",[104,352,212],{},[104,354,355,356],{},"EBS burst credits left, on the ",[138,357,358],{},"DB instance",[80,360,361,366,368],{},[104,362,363],{},[41,364,365],{},"ReplicaLag",[104,367,294],{},[104,369,370],{},"How far a read replica trails its source",[80,372,373,378,381],{},[104,374,375],{},[41,376,377],{},"CPUCreditBalance",[104,379,380],{},"vCPU-minutes",[104,382,383,384,141,387,141,390,393],{},"CPU credits on ",[41,385,386],{},"db.t2",[41,388,389],{},"db.t3",[41,391,392],{},"db.t4g"," classes, at 5-minute frequency only",[80,395,396,401,403],{},[104,397,398],{},[41,399,400],{},"MaximumUsedTransactionIDs",[104,402,225],{},[104,404,405],{},"PostgreSQL transaction ID consumption, the wraparound warning",[37,407,408],{},"Two of these hide traps.",[37,410,411,416],{},[138,412,413,415],{},[41,414,222],{}," 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,418,419,427,428,430,431,423,433,435,436,438],{},[138,420,421,423,424,426],{},[41,422,332],{}," and ",[41,425,347],{}," are different buckets."," ",[41,429,332],{}," is the gp2 volume's own I/O credit bucket. ",[41,432,347],{},[41,434,350],{}," 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 ",[41,437,350],{}," 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.",[64,440,442],{"id":441},"enhanced-monitoring-the-view-cloudwatch-cannot-give-you","Enhanced Monitoring: the view CloudWatch cannot give you",[37,444,445],{},"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,447,448],{},"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,450,451],{},"The details that get tested:",[453,454,455,465,479,502,508],"ul",{},[456,457,458,460,461,464],"li",{},[138,459,91],{}," is 1, 5, 10, 15, 30, or 60 seconds. Setting ",[41,462,463],{},"--monitoring-interval 0"," turns it off.",[456,466,467,468,471,472,474,475,478],{},"Metrics go to ",[138,469,470],{},"CloudWatch Logs",", in the ",[41,473,144],{}," log group, with a default retention of ",[138,476,477],{},"30 days",". You change that on the log group, not on the DB instance.",[456,480,481,482,485,486,489,490,493,494,497,498,501],{},"It needs an ",[138,483,484],{},"IAM role",". The console can create ",[41,487,488],{},"rds-monitoring-role"," for you; via CLI or API you create it yourself with the ",[41,491,492],{},"AmazonRDSEnhancedMonitoringRole"," policy and a trust relationship for the ",[41,495,496],{},"monitoring.rds.amazonaws.com"," service principal. The caller needs ",[41,499,500],{},"iam:PassRole",".",[456,503,504,505,501],{},"Turning it on ",[138,506,507],{},"does not require a reboot",[456,509,510],{},"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.",[512,513,518],"pre",{"className":514,"code":515,"language":516,"meta":517,"style":517},"language-bash shiki shiki-themes material-theme-lighter github-light github-dark","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","bash","",[41,519,520,540,552,564],{"__ignoreMap":517},[521,522,525,529,533,536],"span",{"class":523,"line":524},"line",1,[521,526,528],{"class":527},"sbgvK","aws",[521,530,532],{"class":531},"s_sjI"," rds",[521,534,535],{"class":531}," modify-db-instance",[521,537,539],{"class":538},"s_hVV"," \\\n",[521,541,543,547,550],{"class":523,"line":542},2,[521,544,546],{"class":545},"stzsN","  --db-instance-identifier",[521,548,549],{"class":531}," payments-prod",[521,551,539],{"class":538},[521,553,555,558,562],{"class":523,"line":554},3,[521,556,557],{"class":545},"  --monitoring-interval",[521,559,561],{"class":560},"srdBf"," 5",[521,563,539],{"class":538},[521,565,567,570],{"class":523,"line":566},4,[521,568,569],{"class":545},"  --monitoring-role-arn",[521,571,572],{"class":531}," arn:aws:iam::123456789012:role/rds-monitoring-role\n",[37,574,575,576,578,579,581],{},"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 ",[41,577,43],{},". They cannot, not directly. Enhanced Monitoring output is log events, so alarming on it means creating a CloudWatch Logs metric filter over ",[41,580,144],{}," first, then alarming on the metric that filter produces.",[64,583,585],{"id":584},"db-load-the-metric-that-answers-why","DB load: the metric that answers \"why\"",[37,587,588],{},"Layer 3 measures something different from every metric above. Not a resource, but work in progress.",[37,590,591,592,595,596,599],{},"A ",[138,593,594],{},"session"," is an application's conversation with the database. A session is ",[138,597,598],{},"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,601,602,605,606,609],{},[138,603,604],{},"DB load"," is the number of active sessions, and its unit is ",[138,607,608],{},"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,611,612],{},"Take 5 consecutive 1-second samples:",[74,614,615,631],{},[77,616,617],{},[80,618,619,622,625,628],{},[83,620,621],{},"Sample",[83,623,624],{},"Sessions running a query",[83,626,627],{},"Running total",[83,629,630],{},"AAS so far",[99,632,633,646,658,671,682],{},[80,634,635,638,641,643],{},[104,636,637],{},"1",[104,639,640],{},"2",[104,642,640],{},[104,644,645],{},"2.0",[80,647,648,650,653,655],{},[104,649,640],{},[104,651,652],{},"0",[104,654,640],{},[104,656,657],{},"1.0",[80,659,660,663,666,669],{},[104,661,662],{},"3",[104,664,665],{},"4",[104,667,668],{},"6",[104,670,645],{},[80,672,673,675,677,679],{},[104,674,665],{},[104,676,652],{},[104,678,668],{},[104,680,681],{},"1.5",[80,683,684,687,689,692],{},[104,685,686],{},"5",[104,688,665],{},[104,690,691],{},"10",[104,693,645],{},[37,695,696,697,700],{},"DB load for that interval is ",[138,698,699],{},"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,702,703],{},"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.",[64,705,707],{"id":706},"reading-the-chart-max-vcpu-waits-and-top-sql","Reading the chart: Max vCPU, waits, and top SQL",[37,709,710,711,714],{},"The DB load chart draws a horizontal line at the DB instance's vCPU count, labeled ",[138,712,713],{},"Max vCPU",". This is the reference that turns an abstract number into a verdict.",[37,716,717,718,721],{},"Work through it on a ",[41,719,720],{},"db.r6g.2xlarge",", which has 8 vCPUs:",[453,723,724,731,738],{},[456,725,726,727,730],{},"DB load steady at ",[138,728,729],{},"3 AAS",": 3 sessions active against 8 vCPUs of capacity. Comfortable.",[456,732,733,734,737],{},"DB load at ",[138,735,736],{},"8 AAS, nearly all on CPU",": the instance is saturated on CPU. More vCPUs would help.",[456,739,733,740,743],{},[138,741,742],{},"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,745,746],{},"That last case is the one people misread, and it is exactly why the load is split into 2 CloudWatch metrics:",[74,748,749,758],{},[77,750,751],{},[80,752,753,755],{},[83,754,195],{},[83,756,757],{},"Meaning",[99,759,760,769,779,789],{},[80,761,762,766],{},[104,763,764],{},[41,765,165],{},[104,767,768],{},"All active sessions",[80,770,771,776],{},[104,772,773],{},[41,774,775],{},"DBLoadCPU",[104,777,778],{},"Active sessions whose wait event type is CPU",[80,780,781,786],{},[104,782,783],{},[41,784,785],{},"DBLoadNonCPU",[104,787,788],{},"Active sessions waiting on anything else",[80,790,791,796],{},[104,792,793],{},[41,794,795],{},"DBLoadRelativeToNumVCPUs",[104,797,798],{},"DB load divided by the vCPU count",[37,800,801,803,804,807],{},[41,802,785],{}," dominating is the signal to stop looking at instance size and start looking at what the sessions are waiting for. That is what the ",[138,805,806],{},"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,809,810,811,814,815,818],{},"Then slice by ",[138,812,813],{},"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 ",[138,816,817],{},"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,820,821],{},"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,823,824,825,828],{},"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 ",[41,826,827],{},"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.",[64,830,832],{"id":831},"performance-insights-is-now-cloudwatch-database-insights","Performance Insights is now CloudWatch Database Insights",[37,834,835,836,839,840,843],{},"AWS retired the Performance Insights console on ",[138,837,838],{},"31 July 2026",". The console now redirects to ",[138,841,842],{},"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.",[74,845,846,858],{},[77,847,848],{},[80,849,850,852,855],{},[83,851],{},[83,853,854],{},"Standard mode",[83,856,857],{},"Advanced mode",[99,859,860,870,881,891,900],{},[80,861,862,865,868],{},[104,863,864],{},"DB load, waits, top SQL, hosts, users",[104,866,867],{},"Yes",[104,869,867],{},[80,871,872,875,878],{},[104,873,874],{},"Retention",[104,876,877],{},"The same flexible periods as before, at the same cost",[104,879,880],{},"Same, plus advanced telemetry",[80,882,883,886,889],{},[104,884,885],{},"Fleet-level monitoring across databases",[104,887,888],{},"No",[104,890,867],{},[80,892,893,896,898],{},[104,894,895],{},"Lock diagnostics",[104,897,888],{},[104,899,867],{},[80,901,902,905,907],{},[104,903,904],{},"Execution plan capture and on-demand analysis",[104,906,888],{},[104,908,867],{},[37,910,911],{},"The things worth remembering:",[453,913,914,920,933,938],{},[456,915,916,919],{},[138,917,918],{},"Standard mode is the default",", and it is what instances using Performance Insights fell back to automatically, keeping their existing retention period.",[456,921,922,925,926,423,929,932],{},[138,923,924],{},"The Performance Insights API did not change."," CloudFormation templates, Terraform configurations, and scripts that set ",[41,927,928],{},"PerformanceInsightsEnabled",[41,930,931],{},"PerformanceInsightsRetentionPeriod"," keep working exactly as written.",[456,934,935,937],{},[138,936,874],{}," is still 7 days by default at no extra cost, or 1 to 24 months on a paid tier.",[456,939,940,941,501],{},"Execution plans and on-demand analysis now require ",[138,942,857],{},[37,944,945],{},"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.",[64,947,949],{"id":948},"proactive-recommendations","Proactive recommendations",[37,951,952,953,956],{},"Performance Insights watches selected metrics, learns a threshold from that specific resource's own baseline, and raises a ",[138,954,955],{},"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,958,959,960,963,964,966],{},"Recommendations appear in the RDS console, either on the account-wide ",[138,961,962],{},"Recommendations"," page sorted by severity, or on the ",[138,965,962],{}," 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,968,969,970,973],{},"One requirement that gets tested: ",[138,971,972],{},"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.",[64,975,977],{"id":976},"alarming-on-the-right-layer","Alarming on the right layer",[37,979,980],{},"Alarms behave differently per layer, and this is where the layers stop being an academic distinction.",[37,982,983,986,987,989],{},[138,984,985],{},"Layer 1"," is straightforward. ",[41,988,118],{}," metrics are ordinary CloudWatch metrics, so an alarm is a normal alarm:",[512,991,993],{"className":514,"code":992,"language":516,"meta":517,"style":517},"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",[41,994,995,1007,1017,1027,1037,1048,1059,1070,1081,1092,1103],{"__ignoreMap":517},[521,996,997,999,1002,1005],{"class":523,"line":524},[521,998,528],{"class":527},[521,1000,1001],{"class":531}," cloudwatch",[521,1003,1004],{"class":531}," put-metric-alarm",[521,1006,539],{"class":538},[521,1008,1009,1012,1015],{"class":523,"line":542},[521,1010,1011],{"class":545},"  --alarm-name",[521,1013,1014],{"class":531}," payments-prod-low-storage",[521,1016,539],{"class":538},[521,1018,1019,1022,1025],{"class":523,"line":554},[521,1020,1021],{"class":545},"  --namespace",[521,1023,1024],{"class":531}," AWS/RDS",[521,1026,539],{"class":538},[521,1028,1029,1032,1035],{"class":523,"line":566},[521,1030,1031],{"class":545},"  --metric-name",[521,1033,1034],{"class":531}," FreeStorageSpace",[521,1036,539],{"class":538},[521,1038,1040,1043,1046],{"class":523,"line":1039},5,[521,1041,1042],{"class":545},"  --dimensions",[521,1044,1045],{"class":531}," Name=DBInstanceIdentifier,Value=payments-prod",[521,1047,539],{"class":538},[521,1049,1051,1054,1057],{"class":523,"line":1050},6,[521,1052,1053],{"class":545},"  --statistic",[521,1055,1056],{"class":531}," Average",[521,1058,539],{"class":538},[521,1060,1062,1065,1068],{"class":523,"line":1061},7,[521,1063,1064],{"class":545},"  --period",[521,1066,1067],{"class":560}," 300",[521,1069,539],{"class":538},[521,1071,1073,1076,1079],{"class":523,"line":1072},8,[521,1074,1075],{"class":545},"  --evaluation-periods",[521,1077,1078],{"class":560}," 2",[521,1080,539],{"class":538},[521,1082,1084,1087,1090],{"class":523,"line":1083},9,[521,1085,1086],{"class":545},"  --threshold",[521,1088,1089],{"class":560}," 10737418240",[521,1091,539],{"class":538},[521,1093,1095,1098,1101],{"class":523,"line":1094},10,[521,1096,1097],{"class":545},"  --comparison-operator",[521,1099,1100],{"class":531}," LessThanThreshold",[521,1102,539],{"class":538},[521,1104,1106,1109],{"class":523,"line":1105},11,[521,1107,1108],{"class":545},"  --alarm-actions",[521,1110,1111],{"class":531}," arn:aws:sns:us-east-1:123456789012:dba-oncall\n",[37,1113,1114,1117],{},[138,1115,1116],{},"Layer 2"," needs a CloudWatch Logs metric filter first, because Enhanced Monitoring produces log events.",[37,1119,1120,1123,1124,141,1126,141,1128,1130,1131,1133,1134,1136,1137,1143],{},[138,1121,1122],{},"Layer 3"," is split. The ",[41,1125,165],{},[41,1127,775],{},[41,1129,785],{},", and ",[41,1132,795],{}," metrics are published to CloudWatch in the ",[41,1135,118],{}," namespace, so you alarm on them normally. Every other Performance Insights counter metric is not published directly, and you reach it with the ",[138,1138,1139,1142],{},[41,1140,1141],{},"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,1145,1146,1147,1149],{},"One behavior to expect: the ",[41,1148,165],{}," 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.",[64,1151,1153],{"id":1152},"which-layer-answers-which-symptom","Which layer answers which symptom",[74,1155,1156,1168],{},[77,1157,1158],{},[80,1159,1160,1163,1165],{},[83,1161,1162],{},"Symptom",[83,1164,85],{},[83,1166,1167],{},"What to look at",[99,1169,1170,1180,1190,1202,1213,1228,1241,1252],{},[80,1171,1172,1175,1177],{},[104,1173,1174],{},"Application is slow, all resource metrics look normal",[104,1176,662],{},[104,1178,1179],{},"DB load by wait event, then top SQL",[80,1181,1182,1185,1187],{},[104,1183,1184],{},"CPU at 95%, need to know what is using it",[104,1186,640],{},[104,1188,1189],{},"Enhanced Monitoring process list",[80,1191,1192,1195,1197],{},[104,1193,1194],{},"CPU at 95%, need to know if it is the database's own queries",[104,1196,662],{},[104,1198,1199,1201],{},[41,1200,775],{}," and top SQL",[80,1203,1204,1207,1209],{},[104,1205,1206],{},"Storage filling up",[104,1208,637],{},[104,1210,1211],{},[41,1212,55],{},[80,1214,1215,1218,1220],{},[104,1216,1217],{},"Storage slow after roughly 30 minutes of heavy work",[104,1219,637],{},[104,1221,1222,1224,1225,1227],{},[41,1223,332],{}," on gp2, or ",[41,1226,347],{}," for the instance",[80,1229,1230,1233,1236],{},[104,1231,1232],{},"\"Too many connections\" errors",[104,1234,1235],{},"1 then 3",[104,1237,1238,1240],{},[41,1239,222],{},", then sessions by host and user",[80,1242,1243,1246,1248],{},[104,1244,1245],{},"Read replica serving stale data",[104,1247,637],{},[104,1249,1250],{},[41,1251,365],{},[80,1253,1254,1257,1259],{},[104,1255,1256],{},"One query got slow after a data load",[104,1258,662],{},[104,1260,1261],{},"Top SQL and its execution plan",[64,1263,1265],{"id":1264},"exam-tips","Exam tips",[453,1267,1268,1271,1274,1280,1283,1286,1296,1299],{},[456,1269,1270],{},"\"All CloudWatch metrics look normal but the database is slow\" is a Performance Insights question every time. Resource metrics cannot see waiting.",[456,1272,1273],{},"\"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.",[456,1275,1276,1277,1279],{},"Enhanced Monitoring goes to CloudWatch ",[138,1278,140],{},". If an answer says its metrics appear directly in CloudWatch metrics, eliminate it.",[456,1281,1282],{},"Watch the granularity numbers: CloudWatch metrics at 60 seconds, Enhanced Monitoring at 1 to 60 seconds, Performance Insights sampling at 1 second.",[456,1284,1285],{},"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.",[456,1287,1288,1290,1291,423,1293,1295],{},[41,1289,332],{}," is the gp2 volume. ",[41,1292,347],{},[41,1294,350],{}," are the DB instance. Different buckets, different fixes.",[456,1297,1298],{},"Proactive recommendations require paid retention. Free 7-day retention gets you the dashboard, not the recommendations.",[456,1300,1301,1303,1304,1307],{},[41,1302,377],{}," only exists on ",[41,1305,1306],{},"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,1309,1310],{},"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.",[1312,1313,1314],"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 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":517,"searchDepth":554,"depth":554,"links":1316},[1317,1318,1319,1320,1321,1322,1323,1324,1325,1326],{"id":66,"depth":542,"text":67},{"id":175,"depth":542,"text":176},{"id":441,"depth":542,"text":442},{"id":584,"depth":542,"text":585},{"id":706,"depth":542,"text":707},{"id":831,"depth":542,"text":832},{"id":948,"depth":542,"text":949},{"id":976,"depth":542,"text":977},{"id":1152,"depth":542,"text":1153},{"id":1264,"depth":542,"text":1265},"md",[1329],{"slug":72,"concept":1330,"style":1331,"aspectRatio":1332,"labels":1333},"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","16:9",[1334,1335,1336,1337,1338,1339,1340,1341,1342,1343,1344,1345,1346],"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.",[25,26,27,28,29,30],{},"/courses/aws-certified-cloudops-engineer-associate/en/domains/01-monitoring-logging-performance/05-rds-performance/01-rds-monitoring-and-performance-insights",{"passingScore":1351,"questions":1352},70,[1353,1362,1370,1378,1386,1397,1401,1407,1415],{"question":1354,"type":1355,"options":1356,"correctAnswer":1359,"explanation":1361},"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?","single",[1357,1358,1359,1360],"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":1363,"type":1355,"options":1364,"correctAnswer":1366,"explanation":1369},"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?",[1365,1366,1367,1368],"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":1371,"type":1355,"options":1372,"correctAnswer":1373,"explanation":1377},"Where does Enhanced Monitoring deliver its metrics?",[1373,1374,1375,1376],"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":1379,"type":1355,"options":1380,"correctAnswer":1383,"explanation":1385},"Why can Enhanced Monitoring report a different CPU number than the CloudWatch CPUUtilization metric for the same DB instance?",[1381,1382,1383,1384],"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":1387,"type":1388,"options":1389,"correctAnswers":1395,"explanation":1396},"Which statements about Performance Insights data retention and proactive recommendations are correct? (Choose 2.)","multiple",[1390,1391,1392,1393,1394],"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",[1390,1392],"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":1398,"type":1355,"options":1399,"correctAnswer":332,"explanation":1400},"An RDS for MySQL instance runs on gp2 storage. Which metric warns you that its storage is about to be clamped to baseline IOPS?",[347,320,332,55],"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":1402,"type":1355,"options":1403,"correctAnswer":1405,"explanation":1406},"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.",[1404,1405],"True","False","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":1408,"type":1355,"options":1409,"correctAnswer":1411,"explanation":1414},"A dashboard shows DatabaseConnections at 180 while the DBA reports well over 200 sessions on the same instance. What explains the gap?",[1410,1411,1412,1413],"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":1416,"type":1355,"options":1417,"correctAnswer":1421,"explanation":1422},"You need a CloudWatch alarm on a Performance Insights counter metric that RDS does not publish to CloudWatch directly. What lets you do this?",[1418,1419,1420,1421],"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":22,"description":23},"courses/aws-certified-cloudops-engineer-associate/en/domains/01-monitoring-logging-performance/05-rds-performance/01-rds-monitoring-and-performance-insights","B3MG0yIhcgxQz_1sxUZLU2WYm_AfYVn4AnhED3Ynx90",{"locked":5,"reason":6,"meta":1427,"item":3},{"title":1428,"description":1429,"isFree":10,"estimatedMinutes":1430,"difficulty":12,"learningObjectives":1431},"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.",30,[1432,1433,1434,1435,1436,1437],"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"]