[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"lesson-aws-certified-cloudops-engineer-associate-security-and-compliance-threat-detection-and-response-security-hub-and-automated-response-en":4,"prev-aws-certified-cloudops-engineer-associate-security-and-compliance-threat-detection-and-response-security-hub-and-automated-response-en":20,"next-aws-certified-cloudops-engineer-associate-security-and-compliance-threat-detection-and-response-security-hub-and-automated-response-en":1060},null,{"locked":5,"reason":6,"meta":7,"item":3},true,"paywall",{"title":8,"description":9,"isFree":10,"estimatedMinutes":11,"difficulty":12,"learningObjectives":13},"Security Hub and Automated Response","How to turn scattered findings from GuardDuty, Inspector, Macie, and Config into one prioritized queue and then act on it without a human in the loop: Security Hub CSPM aggregation and scoring, automation rules, EventBridge remediation, and where exposure findings and AWS Security Agent fit.",false,26,"intermediate",[14,15,16,17,18,19],"Explain what Security Hub CSPM adds on top of the individual detectors and why AWS Config recording is a prerequisite","Calculate how a standard's security score responds to passed, failed, unknown, and suppressed controls","Configure cross-Region aggregation and choose between central and local configuration for an organization","Distinguish automation rules from EventBridge rules and pick the right one for a stated requirement","Build an automated remediation loop from finding to action to closed workflow status","Place AWS Security Agent and Security Hub exposure findings against the runtime detectors covered so far",{"locked":10,"reason":3,"meta":21,"item":31},{"title":22,"description":23,"isFree":5,"estimatedMinutes":11,"difficulty":12,"learningObjectives":24},"Amazon GuardDuty and Amazon Inspector","The two detection services answer different questions: GuardDuty watches behavior in your logs to find attacks in progress, and Inspector scans your workloads to find the weaknesses an attacker would use. This lesson covers what each one sees, how to read their findings, and how suppression differs between them.",[25,26,27,28,29,30],"Distinguish GuardDuty threat detection from Inspector vulnerability management by the question each service answers","Identify the 3 GuardDuty foundational data sources and explain why none of them require you to enable logging first","Decode a GuardDuty finding type from its name and map a severity value to its level","Compare GuardDuty suppression rules with Inspector suppression rules and predict what each does to downstream delivery","Choose between Inspector agent-based and agentless scanning for a given instance","Configure both services across an organization, accounting for their Regional and delegated administrator rules",{"id":32,"title":22,"body":33,"description":23,"difficulty":12,"estimatedMinutes":11,"extension":955,"infographics":956,"isFree":5,"learningObjectives":970,"meta":971,"navigation":5,"path":972,"quiz":973,"seo":1057,"stem":1058,"__hash__":1059},"courses/courses/aws-certified-cloudops-engineer-associate/en/domains/04-security-and-compliance/04-threat-detection-and-response/01-guardduty-and-inspector.md",{"type":34,"value":35,"toc":941},"minimark",[36,40,43,48,51,139,142,146,149,185,188,195,198,202,213,291,298,305,320,331,335,338,348,363,368,371,389,453,456,517,520,524,535,550,556,579,582,586,592,595,645,652,659,662,666,669,687,718,724,727,734,745,749,752,834,841,845,848,878,888,892,938],[37,38,39],"p",{},"At 03:00 an EC2 instance in your production account opens a connection to an IP address in a country where you run nothing. Nobody deployed anything. Separately, that same instance has been running a version of a system library with a published CVE for 5 weeks.",[37,41,42],{},"Two facts about one instance, and 2 different questions. The first is \"is something bad happening right now?\" The second is \"what could an attacker use if they got in?\" AWS answers them with 2 different services, and the exam spends most of its detection questions on which service answers which question. Skill 4.2.5 asks you to configure reports and remediate findings from AWS Security Hub, Amazon GuardDuty, AWS Config, Amazon Inspector, and AWS Security Agent. This lesson takes the first 2 detectors in that list.",[44,45,47],"h2",{"id":46},"behavior-versus-state","Behavior versus state",[37,49,50],{},"The cleanest way to hold these apart is that GuardDuty reads activity and Inspector reads inventory.",[52,53,54,69],"table",{},[55,56,57],"thead",{},[58,59,60,63,66],"tr",{},[61,62],"th",{},[61,64,65],{},"Amazon GuardDuty",[61,67,68],{},"Amazon Inspector",[70,71,72,84,95,106,117,128],"tbody",{},[58,73,74,78,81],{},[75,76,77],"td",{},"Question answered",[75,79,80],{},"Is someone attacking or already inside?",[75,82,83],{},"What is exploitable if they get in?",[58,85,86,89,92],{},[75,87,88],{},"Input",[75,90,91],{},"CloudTrail management events, VPC flow logs, DNS query logs, plus optional log sources",[75,93,94],{},"Software inventory on EC2, ECR container images, Lambda functions, source code",[58,96,97,100,103],{},[75,98,99],{},"Detection basis",[75,101,102],{},"Threat intelligence feeds, machine learning, anomaly baselines",[75,104,105],{},"CVE databases, network path analysis, code analysis",[58,107,108,111,114],{},[75,109,110],{},"Nature of a finding",[75,112,113],{},"An event that happened",[75,115,116],{},"A condition that exists",[58,118,119,122,125],{},[75,120,121],{},"When it clears",[75,123,124],{},"You archive it or it ages out at 90 days",[75,126,127],{},"Inspector detects the remediation and closes it automatically",[58,129,130,133,136],{},[75,131,132],{},"Typical response",[75,134,135],{},"Contain the resource, rotate credentials, investigate",[75,137,138],{},"Patch, rebuild the image, redeploy",[37,140,141],{},"That last row is the practical difference. A GuardDuty finding is a report about the past that never fixes itself; an Inspector finding is a description of the present that disappears when you patch. Keep that in mind when a question describes a finding \"that closed on its own\" or one \"that stayed open after the instance was terminated\".",[44,143,145],{"id":144},"guardduty-reads-logs-you-never-had-to-turn-on","GuardDuty reads logs you never had to turn on",[37,147,148],{},"Enable GuardDuty in a Region and it immediately starts consuming 3 foundational data sources:",[150,151,152,173,179],"ul",{},[153,154,155,159,160,164,165,168,169,172],"li",{},[156,157,158],"strong",{},"AWS CloudTrail management events",", the control plane calls such as ",[161,162,163],"code",{},"AttachRolePolicy",", ",[161,166,167],{},"CreateSubnet",", and ",[161,170,171],{},"CreateTrail",".",[153,174,175,178],{},[156,176,177],{},"VPC Flow Logs"," from the EC2 instances in the account.",[153,180,181,184],{},[156,182,183],{},"Route 53 Resolver DNS query logs",", the name lookups your instances perform.",[37,186,187],{},"Here is where a predictable misconception starts. It is tempting to assume you must create a CloudTrail trail and enable VPC flow logs first, the way you would for most log-consuming services. You do not. GuardDuty consumes each of these through an independent, duplicated stream. Your CloudTrail configuration does not affect what GuardDuty sees, and GuardDuty does not affect your CloudTrail configuration. Disabling flow logs on a VPC does not blind GuardDuty. There is also no extra charge for the log access itself; you pay GuardDuty's own pricing after the 30-day free trial.",[37,189,190,191,194],{},"The DNS source carries the one real dependency, and it is a favorite exam detail. GuardDuty reads DNS queries through the internal AWS DNS resolvers. If your instances use the AWS-provided resolver, which is the default, GuardDuty sees the queries. If you point them at OpenDNS, Google DNS, or a resolver you run yourself, ",[156,192,193],{},"GuardDuty cannot access that data at all",", and every DNS-based finding type goes quiet. Enabling Route 53 Resolver query logging does not fix it, because GuardDuty uses a separate stream rather than that feature.",[37,196,197],{},"One more behavior worth knowing before you decide which Regions to enable. Global service events, from IAM, AWS STS, S3, CloudFront, and Route 53, are recorded by CloudTrail in one Region but matter everywhere. GuardDuty replicates those events and processes them in every Region where you have it enabled, which is how it keeps a user and role profile per Region. That is the argument for turning GuardDuty on even in Regions where you deploy nothing: an attacker who creates resources in an unused Region is exactly the case those profiles catch.",[44,199,201],{"id":200},"protection-plans-widen-the-surface","Protection plans widen the surface",[37,203,204,205,208,209,212],{},"The 3 foundational sources are the baseline. Everything else GuardDuty can watch comes from an optional ",[156,206,207],{},"protection plan",", which the API calls a ",[156,210,211],{},"feature",". Each one adds a log or event source:",[52,214,215,225],{},[55,216,217],{},[58,218,219,222],{},[61,220,221],{},"Protection plan",[61,223,224],{},"What it adds",[70,226,227,235,243,251,259,267,275,283],{},[58,228,229,232],{},[75,230,231],{},"S3 Protection",[75,233,234],{},"S3 data events from CloudTrail",[58,236,237,240],{},[75,238,239],{},"EKS Protection",[75,241,242],{},"EKS audit logs",[58,244,245,248],{},[75,246,247],{},"Runtime Monitoring",[75,249,250],{},"OS-level, network, and file events from a security agent on EKS, ECS on Fargate, and EC2",[58,252,253,256],{},[75,254,255],{},"Malware Protection for EC2",[75,257,258],{},"Scans of EBS volumes attached to EC2 instances and container workloads",[58,260,261,264],{},[75,262,263],{},"Malware Protection for S3",[75,265,266],{},"Scans of newly uploaded S3 objects",[58,268,269,272],{},[75,270,271],{},"RDS Protection",[75,273,274],{},"Login activity on supported Aurora and RDS engine versions",[58,276,277,280],{},[75,278,279],{},"Lambda Protection",[75,281,282],{},"Lambda network activity logs",[58,284,285,288],{},[75,286,287],{},"AI Protection",[75,289,290],{},"CloudTrail data events from Amazon Bedrock, Bedrock AgentCore, and SageMaker AI",[37,292,293,294,297],{},"Two details about how these switch on. When you enable GuardDuty for the first time, all protection plans ",[156,295,296],{},"except Runtime Monitoring"," are enabled automatically and included in the 30-day free trial. If you were already a GuardDuty customer when a plan launched, that plan is not enabled automatically and you have to opt in, which is why long-lived accounts often have coverage gaps that new accounts do not.",[37,299,300,301,304],{},"Malware Protection for S3 is the one exception to the whole model: you can use it on its own ",[156,302,303],{},"without enabling the GuardDuty service at all",". Every other protection plan requires GuardDuty.",[37,306,307,308,311,312,315,316,319],{},"Malware Protection for EC2 comes in 2 flavors that scenario questions like to separate. A ",[156,309,310],{},"GuardDuty-initiated malware scan"," fires automatically when a finding suggests malware on an instance, runs at most once every 24 hours per resource, and has its own 30-day free trial. An ",[156,313,314],{},"on-demand malware scan"," is one you start yourself with an instance ARN, requires no feature-level configuration beyond GuardDuty being enabled, can be repeated on the same resource 1 hour after the previous scan started, and has no free trial. Both honor the global ",[161,317,318],{},"GuardDutyExcluded"," tag. Snapshots of the scanned volumes are retained only when malware is found, and only if you configured retention.",[37,321,322,323,326,327,330],{},"Sitting above all of this is ",[156,324,325],{},"Extended Threat Detection",". It correlates events across data sources, resource types, and time inside one account to spot multi-stage attacks, then writes an ",[156,328,329],{},"attack sequence"," finding. It costs nothing extra, needs no protection plan, and is enabled automatically with GuardDuty. It is also the reason attack sequence findings land in the Critical band while individual signals sit lower: each event alone looked survivable, and the sequence did not.",[44,332,334],{"id":333},"reading-a-finding-type-without-opening-the-finding","Reading a finding type without opening the finding",[37,336,337],{},"GuardDuty names every finding type with the same grammar:",[339,340,345],"pre",{"className":341,"code":343,"language":344},[342],"language-text","ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact\n","text",[161,346,343],{"__ignoreMap":347},"",[37,349,350,351,354,355,358,359,362],{},"Walk one real type through it. ",[161,352,353],{},"CryptoCurrency:EC2/BitcoinTool.B!DNS"," says: the adversary's purpose is cryptocurrency activity, the affected resource type is an EC2 instance, the family of activity is a known Bitcoin tool, ",[161,356,357],{},".B"," is the detected variant, and ",[161,360,361],{},"!DNS"," names the artifact, meaning the instance was talking to a known Bitcoin-related domain.",[364,365],"infographic",{"alt":366,"slug":367},"A breakdown of the GuardDuty finding type CryptoCurrency:EC2/BitcoinTool.B!DNS showing what each segment of the name means.","guardduty-finding-type-anatomy",[37,369,370],{},"Two values in the DetectionMechanism position carry extra meaning:",[150,372,373,381],{},[153,374,375,380],{},[156,376,377],{},[161,378,379],{},".Custom"," means the match came from a threat list you uploaded, not from AWS threat intelligence.",[153,382,383,388],{},[156,384,385],{},[161,386,387],{},".Reputation"," means a domain reputation score model produced the match.",[37,390,391,392,164,395,164,398,164,401,164,404,164,407,164,410,164,413,164,416,164,419,164,422,164,425,164,428,164,431,164,434,164,437,164,440,168,443,446,447,449,450,452],{},"The ThreatPurpose values are worth skimming once because several map directly onto MITRE ATT&CK tactics: ",[161,393,394],{},"Backdoor",[161,396,397],{},"Behavior",[161,399,400],{},"CredentialAccess",[161,402,403],{},"Cryptocurrency",[161,405,406],{},"DefenseEvasion",[161,408,409],{},"Discovery",[161,411,412],{},"Execution",[161,414,415],{},"Exfiltration",[161,417,418],{},"Impact",[161,420,421],{},"InitialAccess",[161,423,424],{},"Pentest",[161,426,427],{},"Persistence",[161,429,430],{},"Policy",[161,432,433],{},"PrivilegeEscalation",[161,435,436],{},"Recon",[161,438,439],{},"Stealth",[161,441,442],{},"Trojan",[161,444,445],{},"UnauthorizedAccess",". You do not need to memorize the list, but you should recognize that ",[161,448,430],{}," means a best-practice violation rather than an attack, and that ",[161,451,424],{}," means the activity looks like known penetration testing tools, which GuardDuty cannot tell apart from an actual adversary using the same freely available tools.",[37,454,455],{},"Severity is a number from 1.0 to 10.0, split into 4 bands:",[52,457,458,471],{},[55,459,460],{},[58,461,462,465,468],{},[61,463,464],{},"Level",[61,466,467],{},"Value range",[61,469,470],{},"What it means",[70,472,473,484,495,506],{},[58,474,475,478,481],{},[75,476,477],{},"Critical",[75,479,480],{},"9.0 to 10.0",[75,482,483],{},"An attack sequence may be in progress or recently happened across one or more resources",[58,485,486,489,492],{},[75,487,488],{},"High",[75,490,491],{},"7.0 to 8.9",[75,493,494],{},"The resource is compromised and actively being used for unauthorized purposes",[58,496,497,500,503],{},[75,498,499],{},"Medium",[75,501,502],{},"4.0 to 6.9",[75,504,505],{},"Suspicious behavior that deviates from the baseline and may indicate compromise",[58,507,508,511,514],{},[75,509,510],{},"Low",[75,512,513],{},"1.0 to 3.9",[75,515,516],{},"Attempted activity that did not compromise anything, such as a port scan",[37,518,519],{},"Scenario questions usually hand you the number, not the label, so the boundary values are the part to hold.",[44,521,523],{"id":522},"aggregation-archiving-and-the-delay-that-surprises-people","Aggregation, archiving, and the delay that surprises people",[37,525,526,527,530,531,534],{},"GuardDuty does not create a new finding for every packet. When it detects new activity tied to the same security issue, it ",[156,528,529],{},"updates the original finding"," and increments the ",[161,532,533],{},"Count",", replacing the details with the most recent occurrence. Repeated SSH brute force attempts against one instance stay a single finding; the same attack against a second instance creates a second finding with its own ID, because that is a distinct security issue with a distinct resource.",[37,536,537,538,541,542,545,546,549],{},"That aggregation has a delivery consequence. New active findings reach EventBridge within about ",[156,539,540],{},"5 minutes",". Updates to existing findings follow a separate setting, ",[156,543,544],{},"Frequency for updated findings",", which defaults to ",[156,547,548],{},"every 6 hours"," and can be set to 15 minutes or 1 hour. So an ongoing attack, which arrives as updates rather than new findings, can sit for hours before your remediation Lambda hears about it. If a question describes automation that \"fired late\" on a continuing incident, this setting is the answer.",[37,551,552,555],{},[156,553,554],{},"Suppression rules"," are how you cut noise. A rule is filter criteria plus a value, and new findings matching it are automatically archived. Three properties matter:",[557,558,559,566,573],"ol",{},[153,560,561,562,565],{},"Suppressed findings are ",[156,563,564],{},"not sent to Security Hub CSPM, Amazon S3, Amazon Detective, or EventBridge",", and they do not trigger Malware Protection for EC2 scans. This is the point: it silences the SIEM, not just the console.",[153,567,568,569,572],{},"The findings are still generated and stored in GuardDuty for ",[156,570,571],{},"90 days",", viewable by filtering on Archived.",[153,574,575,576,172],{},"In a multi-account setup, ",[156,577,578],{},"only the GuardDuty administrator can create suppression rules",[37,580,581],{},"There is a cost to suppressing broadly that is easy to miss. Archived findings are not used as signals when Extended Threat Detection correlates events into attack sequences. Suppress every EKS cluster finding and you have also removed GuardDuty's ability to notice a chain where an attacker exploits a container, grabs a privileged token, and reaches sensitive resources. AWS's own guidance is to build suppression rules reactively, for specific behaviors you have repeatedly confirmed as false positives, never as a blanket filter.",[44,583,585],{"id":584},"inspector-scans-what-you-deployed","Inspector scans what you deployed",[37,587,588,589,172],{},"Amazon Inspector discovers workloads on its own and scans them continuously. There is no assessment to schedule and no scan window to plan. When a resource changes, when you install a package, or when a new CVE relevant to that resource is published, Inspector rescans. When you fix the problem, it detects the remediation and ",[156,590,591],{},"closes the finding for you",[37,593,594],{},"It produces 3 finding types:",[52,596,597,610],{},[55,598,599],{},[58,600,601,604,607],{},[61,602,603],{},"Finding type",[61,605,606],{},"Applies to",[61,608,609],{},"Detects",[70,611,612,623,634],{},[58,613,614,617,620],{},[75,615,616],{},"Package vulnerability",[75,618,619],{},"EC2 instances, ECR container images, Lambda functions",[75,621,622],{},"Software packages exposed to published CVEs",[58,624,625,628,631],{},[75,626,627],{},"Code vulnerability",[75,629,630],{},"Lambda functions (code scanning), Code Security",[75,632,633],{},"Exploitable lines of code: missing encryption, data leaks, injection flaws, weak cryptography",[58,635,636,639,642],{},[75,637,638],{},"Network reachability",[75,640,641],{},"EC2 instances only",[75,643,644],{},"Open TCP and UDP paths reachable from a VPC edge such as an internet gateway, peering connection, or virtual gateway",[37,646,647,648,651],{},"Network reachability is the one that catches people out on 2 counts: it is EC2 only, and it runs on a ",[156,649,650],{},"12-hour"," cycle rather than continuously.",[37,653,654,655,658],{},"Severity deserves a note because Inspector does something Config and GuardDuty do not. It takes the National Vulnerability Database CVSS base score and adjusts it for your environment, producing the ",[156,656,657],{},"Amazon Inspector score",". A network-exploitable vulnerability on an instance with no open path to the internet scores lower than the same CVE on an internet-facing instance. Two accounts can hold the same CVE at different severities and both be correct.",[37,660,661],{},"Retention rules follow the state model. Findings for deleted, terminated, or no-longer-eligible resources are closed automatically and deleted after 3 days. Findings closed for any other reason are deleted after 30 days. A remediated finding that reappears within 7 days is reopened rather than recreated. Findings on stopped instances stay active, because a stopped instance still has the vulnerable package on disk.",[44,663,665],{"id":664},"agent-based-agentless-and-how-inspector-picks","Agent-based, agentless, and how Inspector picks",[37,667,668],{},"Package vulnerability scanning on EC2 uses one of 2 collection methods, and the choice per instance is not arbitrary.",[37,670,671,674,675,678,679,682,683,686],{},[156,672,673],{},"Agent-based scanning"," collects the software inventory through the SSM Agent. The instance must be a ",[156,676,677],{},"managed instance in Systems Manager"," in the same account, which in practice means the SSM Agent installed and running plus an instance profile granting SSM permission (the ",[161,680,681],{},"AmazonSSMManagedInstanceCore"," managed policy covers everything Inspector needs). Inspector creates its own SSM associations, with names ending in ",[161,684,685],{},"-do-not-delete",", to install collection plugins and pull inventory. This method scans continuously: at launch, when new software is installed on Linux and Mac, and when a newly published CVE affects the instance. It is also the method that supports Inspector deep inspection for application programming language packages on Linux.",[37,688,689,692,693,696,697,164,700,703,704,707,708,164,711,703,714,717],{},[156,690,691],{},"Agentless scanning"," needs nothing on the instance. Inspector snapshots every attached EBS volume, tags the snapshot with ",[161,694,695],{},"InspectorScan",", reads it through the EBS direct APIs, generates findings, then deletes the snapshot. An instance is eligible when it has a supported OS, has a status of ",[161,698,699],{},"Unmanaged EC2 instance",[161,701,702],{},"Stale inventory",", or ",[161,705,706],{},"No inventory",", is EBS backed with an ",[161,709,710],{},"ext3",[161,712,713],{},"ext4",[161,715,716],{},"xfs"," file system, has fewer than 8 attached volumes totaling 1200 GB or less, and is not excluded by tag.",[37,719,720,723],{},[156,721,722],{},"Hybrid scanning mode"," combines the 2 and is what activating EC2 scanning enrolls you in: SSM managed instances go the agent-based route, and eligible unmanaged instances get agentless coverage. Agentless scans run every 24 hours, and Inspector looks for newly eligible instances every hour. A standalone account or the Inspector delegated administrator can change the scan mode, and when the delegated administrator sets it, the mode applies to every member account in the organization.",[37,725,726],{},"One consequence to expect rather than debug: the same instance can produce different findings depending on which method scanned it. On Linux, agentless scanning inspects all available paths for language packages, while agent-based scanning covers the default paths plus any extra paths you configured for deep inspection.",[37,728,729,730,733],{},"To take an instance out of scanning entirely, tag it with the key ",[161,731,732],{},"InspectorEc2Exclusion",". The tag key is case-insensitive and the value is optional. Excluded instances are not charged.",[37,735,736,737,740,741,744],{},"Beyond package scanning, Inspector also runs ",[156,738,739],{},"CIS scans"," against EC2 operating systems. These target instances by tag, need the instance to be SSM managed with the ",[161,742,743],{},"AmazonInspector2ManagedCisPolicy"," permissions attached, and run once on demand or on a daily, weekly, or monthly schedule. You pick CIS Benchmark Level 1 for baseline settings that should not disrupt service, or Level 2 for high-security environments, where Level 2 includes everything in Level 1.",[44,746,748],{"id":747},"suppression-means-2-different-things","Suppression means 2 different things",[37,750,751],{},"This is the boundary most worth carrying out of the lesson, because both services use the same word for genuinely different behavior.",[52,753,754,766],{},[55,755,756],{},[58,757,758,760,763],{},[61,759],{},[61,761,762],{},"GuardDuty suppression rule",[61,764,765],{},"Inspector suppression rule",[70,767,768,779,790,801,812,823],{},[58,769,770,773,776],{},[75,771,772],{},"Effect on the finding",[75,774,775],{},"Archived",[75,777,778],{},"Hidden from the default console view only",[58,780,781,784,787],{},[75,782,783],{},"Sent to Security Hub CSPM and EventBridge?",[75,785,786],{},"No",[75,788,789],{},"Yes, delivery is unaffected",[58,791,792,795,798],{},[75,793,794],{},"Closes or remediates?",[75,796,797],{},"No, and the finding ages out at 90 days",[75,799,800],{},"No, and Inspector explicitly states rules cannot close or remediate",[58,802,803,806,809],{},[75,804,805],{},"How it clears",[75,807,808],{},"You unarchive it",[75,810,811],{},"The underlying vulnerability is remediated",[58,813,814,817,820],{},[75,815,816],{},"Who can create it",[75,818,819],{},"The GuardDuty administrator in a multi-account setup",[75,821,822],{},"Standalone accounts and the Inspector delegated administrator only",[58,824,825,828,831],{},[75,826,827],{},"Time to take effect",[75,829,830],{},"Immediate for new findings",[75,832,833],{},"Up to 24 hours",[37,835,836,837,840],{},"Delete an Inspector suppression rule and the matching findings return to ",[161,838,839],{},"Active"," and are published to Security Hub CSPM and EventBridge again. Delete a GuardDuty suppression rule and future matches simply stop being archived; the ones already archived stay archived until you unarchive them.",[44,842,844],{"id":843},"running-both-across-an-organization","Running both across an organization",[37,846,847],{},"Both services integrate with AWS Organizations through a delegated administrator, and both are Regional, but the details differ enough to be tested.",[37,849,850,851,854,855,858,859,862,863,866,867,870,871,873,874,877],{},"For ",[156,852,853],{},"GuardDuty",", the Organizations management account designates the delegated administrator, and enabling it there activates GuardDuty in that Region only. The rule that trips people is a pair: the designation is ",[156,856,857],{},"per Region",", and it must be the ",[156,860,861],{},"same account in every Region",". Designate account 111122223333 in Ireland and you cannot designate 555555555555 in Canada. Auto-enable preferences let the administrator cover ",[161,864,865],{},"NEW"," member accounts only or ",[161,868,869],{},"ALL"," accounts including existing ones, and the ",[161,872,865],{}," setting has an ordering trap in opt-in Regions: the member must opt into the Region before joining the organization, or it is no longer new. One administrator manages a maximum of ",[156,875,876],{},"50,000 member accounts",". Removing the delegated administrator removes the member associations but leaves GuardDuty enabled in those accounts.",[37,879,850,880,883,884,887],{},[156,881,882],{},"Inspector",", the delegated administrator can activate the service for the whole organization in one step and set automatic activation for accounts that join later. It can view aggregated findings for all members, activate or deactivate scans for them, set the EC2 scan mode for the entire organization, and own CIS scan configurations at the organization level. There is one privacy boundary: the delegated administrator ",[156,885,886],{},"cannot view code snippets"," belonging to member accounts, because code vulnerability findings include captured source.",[44,889,891],{"id":890},"exam-tips","Exam tips",[150,893,894,897,900,903,906,913,916,923,926,929,935],{},[153,895,896],{},"\"Is someone attacking?\" points at GuardDuty. \"What is vulnerable or exposed?\" points at Inspector. A question mentioning CVEs, patch levels, or container images is Inspector even when it uses security language.",[153,898,899],{},"Nothing needs to be enabled before GuardDuty. If an option says \"first enable VPC flow logs\" or \"first create a CloudTrail trail\", it is wrong.",[153,901,902],{},"The exception is DNS. A non-AWS resolver means no DNS findings, and no setting anywhere fixes it.",[153,904,905],{},"Malware Protection for S3 works without GuardDuty enabled. Every other protection plan requires it.",[153,907,908,909,912],{},"Runtime Monitoring is the one protection plan ",[156,910,911],{},"not"," enabled automatically on first activation.",[153,914,915],{},"Severity boundaries: Low 1.0-3.9, Medium 4.0-6.9, High 7.0-8.9, Critical 9.0-10.0. Critical implies an attack sequence from Extended Threat Detection.",[153,917,918,919,922],{},"New findings hit EventBridge in about 5 minutes; ",[156,920,921],{},"updates"," follow the export frequency, default 6 hours. Late automation on an ongoing attack is almost always this setting.",[153,924,925],{},"GuardDuty suppression stops downstream delivery. Inspector suppression does not. Do not let the shared word merge them.",[153,927,928],{},"Inspector network reachability is EC2 only, every 12 hours. Agentless package scanning is every 24 hours. Different numbers, different mechanisms.",[153,930,931,932,934],{},"Hybrid mode: SSM managed goes agent-based, unmanaged and EBS backed goes agentless. Exclude with the ",[161,933,732],{}," tag.",[153,936,937],{},"GuardDuty delegated administrator: per Region, same account everywhere, 50,000 member ceiling, designated only by the Organizations management account.",[37,939,940],{},"The thing to carry forward is the split in the first table: GuardDuty tells you something happened, Inspector tells you something is possible. Neither one ranks the two against each other, deduplicates them, or does anything about them. A GuardDuty High on an instance that Inspector already flagged with a remotely exploitable CVE is a different situation from either finding alone, and no single detector can say so. That correlation, and the automation that acts on it, is what the next lesson builds with Security Hub.",{"title":347,"searchDepth":942,"depth":942,"links":943},3,[944,946,947,948,949,950,951,952,953,954],{"id":46,"depth":945,"text":47},2,{"id":144,"depth":945,"text":145},{"id":200,"depth":945,"text":201},{"id":333,"depth":945,"text":334},{"id":522,"depth":945,"text":523},{"id":584,"depth":945,"text":585},{"id":664,"depth":945,"text":665},{"id":747,"depth":945,"text":748},{"id":843,"depth":945,"text":844},{"id":890,"depth":945,"text":891},"md",[957],{"slug":367,"concept":958,"style":959,"aspectRatio":960,"labels":961},"A single-row anatomical breakdown of one real GuardDuty finding type string, CryptoCurrency:EC2/BitcoinTool.B!DNS, rendered large in monospace across the top with each segment visually separated by its delimiter. Callout lines drop from each segment to a short caption explaining what that position means. Two smaller side notes cover the special DetectionMechanism values. A takeaway strip runs along the bottom. Emphasis goes on the delimiters, because the delimiters are what let a reader parse an unfamiliar finding type on sight.","diagram","16:9",[353,962,963,964,965,966,967,968,969],"ThreatPurpose: what the adversary is trying to accomplish","ResourceTypeAffected: which resource type is the target","ThreatFamilyName: the specific malicious activity detected","DetectionMechanism: the variant or the method that caught it","Artifact: a resource owned by the attacker's tooling, optional",".Custom means your own threat list produced the match",".Reputation means a domain reputation model produced the match","Read the type left to right and you have the incident before you open the finding",[25,26,27,28,29,30],{},"/courses/aws-certified-cloudops-engineer-associate/en/domains/04-security-and-compliance/04-threat-detection-and-response/01-guardduty-and-inspector",{"passingScore":974,"questions":975},70,[976,985,995,1003,1011,1019,1027,1035,1043,1049],{"question":977,"type":978,"options":979,"correctAnswer":982,"explanation":984},"Your EC2 instances are configured to use a self-managed DNS resolver running in your VPC instead of the Amazon-provided resolver. What effect does this have on GuardDuty?","single",[980,981,982,983],"GuardDuty falls back to reading Route 53 Resolver query logging if you enable it in the Route 53 console","No effect, because GuardDuty inspects DNS traffic directly from VPC flow logs","GuardDuty cannot access or process DNS query data for those instances, so DNS-based finding types will not fire","GuardDuty generates a Policy finding warning that DNS monitoring is degraded","GuardDuty reads Route 53 Resolver DNS query logs through the internal AWS DNS resolvers, so the data exists only when your instances use the AWS resolvers, which is the default. With OpenDNS, Google DNS, or your own resolver, that stream is simply absent, and enabling Route 53 Resolver query logging does not help because GuardDuty uses its own independent stream rather than that feature. VPC flow logs record connections, not DNS names, so they cannot substitute.",{"question":986,"type":987,"options":988,"correctAnswers":993,"explanation":994},"Which statements about GuardDuty foundational data sources are correct? (Choose 2.)","multiple",[989,990,991,992],"You must create a CloudTrail trail before GuardDuty can analyze management events","GuardDuty consumes CloudTrail management events and VPC flow logs through independent, duplicated streams","You are not charged extra for the log data GuardDuty consumes from the foundational data sources","Disabling VPC flow logs on a VPC stops GuardDuty from analyzing network traffic for instances in that VPC",[990,991],"GuardDuty reads these sources through its own duplicated streams, so your CloudTrail and VPC flow log configuration neither enables nor blocks its analysis, and there is no additional cost for the log access itself. This is why the correct answer to 'what do I enable first' is nothing: turning GuardDuty on is the whole setup. You still pay GuardDuty's own per-volume pricing after the 30-day free trial.",{"question":996,"type":978,"options":997,"correctAnswer":998,"explanation":1002},"A finding arrives with the type Backdoor:EC2/C&CActivity.B!DNS. What does the segment after the exclamation mark tell you?",[998,999,1000,1001],"The artifact involved, in this case a domain owned by the attacker's tooling","The severity band assigned to the finding","The detection mechanism, meaning a custom threat list matched","The AWS Region where the activity was observed","The format is ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact, so everything after the exclamation mark names a resource owned by the tool used in the activity. The detection mechanism sits after the period, not the exclamation mark, and values like .Custom and .Reputation live there. Severity and Region are fields in the finding body, never encoded in the type name.",{"question":1004,"type":978,"options":1005,"correctAnswer":1009,"explanation":1010},"A GuardDuty finding has a severity value of 8.2. Which severity level is that, and what does GuardDuty recommend?",[1006,1007,1008,1009],"Critical, indicating an attack sequence may be in progress across multiple resources","Medium, indicating behavior that deviates from the baseline and should be reviewed at your earliest convenience","Low, indicating attempted activity that did not compromise the environment","High, indicating the resource is compromised and actively being used for unauthorized purposes, so remediate immediately","GuardDuty splits the 1.0 to 10.0 range into Low (1.0 to 3.9), Medium (4.0 to 6.9), High (7.0 to 8.9), and Critical (9.0 to 10.0), so 8.2 is High. Critical is reserved for attack sequence findings from Extended Threat Detection, where several correlated events suggest an attack spanning resources and time. Knowing the boundary values matters because scenario questions often give you a number rather than a label.",{"question":1012,"type":978,"options":1013,"correctAnswer":1015,"explanation":1018},"Your team creates a GuardDuty suppression rule for Recon:EC2/Portscan findings coming from the vulnerability scanner AMI. A colleague asks whether the findings will still appear in your SIEM, which reads from Security Hub CSPM. What do you tell them?",[1014,1015,1016,1017],"Yes, suppression only changes the console view and downstream delivery is unaffected","No, suppressed findings are archived and are not sent to Security Hub CSPM, S3, Detective, or EventBridge","Yes, but only for the first 90 days, after which delivery stops","No, and the findings are also deleted immediately rather than retained","A GuardDuty suppression rule auto-archives matching new findings, and archived findings are held out of every downstream integration, which is exactly why it reduces SIEM noise. The findings are still generated and stored in GuardDuty for 90 days, viewable by filtering on Archived, so nothing is lost for later investigation. Note the side effect: archived findings are not used as signals for Extended Threat Detection attack sequences, so broad suppression rules blind the correlation engine.",{"question":1020,"type":978,"options":1021,"correctAnswer":1024,"explanation":1026},"Which statement correctly contrasts Inspector suppression rules with GuardDuty suppression rules?",[1022,1023,1024,1025],"Both archive the finding and stop publication to Security Hub CSPM and EventBridge","Inspector suppression closes the finding, while GuardDuty suppression only hides it","Inspector suppression only hides findings from view and never closes or remediates them, and deleting the rule republishes them to Security Hub CSPM and EventBridge","Inspector suppression can be created by any member account, while GuardDuty suppression requires the administrator","Inspector explicitly states that suppression rules have no impact on the findings themselves and cannot close or remediate them; a suppressed finding closes only when the underlying vulnerability is actually remediated. GuardDuty goes further by archiving and cutting downstream delivery. Both services restrict rule creation to standalone accounts and the delegated administrator, so the last option describes neither.",{"question":1028,"type":978,"options":1029,"correctAnswer":1031,"explanation":1034},"An EC2 instance is not managed by Systems Manager, is EBS backed with an xfs file system, and has 2 attached volumes totaling 300 GB. Your account uses hybrid scanning mode. How does Inspector scan it for package vulnerabilities?",[1030,1031,1032,1033],"It skips the instance until you install and register the SSM Agent","It uses the agentless method, creating EBS snapshots, reading them through the EBS direct APIs, then deleting the snapshots","It uses the agent-based method through an SSM association installed at launch","It generates only network reachability findings for the instance","Hybrid mode routes SSM managed instances to agent-based scanning and unmanaged, stale-inventory, or no-inventory instances to agentless scanning, and this instance meets every agentless requirement: supported file system, fewer than 8 volumes, and 1200 GB or less in total. Agentless scans run every 24 hours, while agent-based scans are continuous and react to new packages and newly published CVEs. Network reachability findings are produced for EC2 instances regardless of the package scan method.",{"question":1036,"type":978,"options":1037,"correctAnswer":1040,"explanation":1042},"Which Inspector finding type applies only to EC2 instances, and on what schedule is it produced?",[1038,1039,1040,1041],"Package vulnerability, produced continuously as new CVEs are published","Code vulnerability, produced whenever a function is updated","Network reachability, produced by a scan that runs every 12 hours","Network reachability, produced by a scan that runs every 24 hours","Network reachability findings identify open TCP and UDP paths from VPC edges such as internet gateways, peering connections, and virtual gateways, and Inspector produces them only for EC2 instances on a 12-hour cycle. Package vulnerability findings cover EC2, ECR container images, and Lambda functions, and code vulnerability findings come from Lambda code scanning and Code Security. The 24-hour interval belongs to agentless package scanning, which is a different mechanism.",{"question":1044,"type":978,"options":1045,"correctAnswer":1047,"explanation":1048},"True or False: an organization can designate one account as the delegated GuardDuty administrator in us-east-1 and a different account in eu-west-1.",[1046,1047],"True","False","GuardDuty is Regional, so the Organizations management account must designate the delegated administrator separately in every Region, but it must be the same account each time. The Regional part of the rule catches people who assume a single global designation, and the same-account part catches people who assume Regional means independent. A GuardDuty administrator can manage a maximum of 50,000 member accounts.",{"question":1050,"type":978,"options":1051,"correctAnswer":1053,"explanation":1056},"A GuardDuty finding fired at 09:00 and your remediation Lambda ran at 15:00. The finding was an update to an existing SSHBruteForce finding rather than a new one. What is the most likely cause?",[1052,1053,1054,1055],"The EventBridge rule was throttled by the Lambda concurrency limit","The frequency for exporting updated findings is set to the default of 6 hours","GuardDuty batches all findings into a single hourly export","The finding was archived by a suppression rule and released later","New active findings are exported to EventBridge within about 5 minutes, but updates to existing findings follow the export frequency setting, which defaults to every 6 hours and can be changed to 15 minutes or 1 hour. Because GuardDuty aggregates repeated activity against the same resource into the original finding rather than creating new ones, ongoing attacks arrive as updates and inherit that delay. An archived finding would not have been delivered at all.",{"title":22,"description":23},"courses/aws-certified-cloudops-engineer-associate/en/domains/04-security-and-compliance/04-threat-detection-and-response/01-guardduty-and-inspector","r-GDaRGtnYa3ZcwbCUhZpoJYa8XPFoSNV-vNQVN9spc",{"locked":10,"reason":3,"meta":1061,"item":1072},{"title":1062,"description":1063,"isFree":5,"estimatedMinutes":11,"difficulty":1064,"learningObjectives":1065},"VPC, Subnets, and Route Tables","A VPC is an address range plus a router, and almost every networking incident traces back to one of those two. This lesson covers CIDR planning that you cannot undo, why a subnet gives you fewer addresses than the math suggests, and how route tables decide where every packet goes.","beginner",[1066,1067,1068,1069,1070,1071],"Explain how a VPC CIDR block, subnets, and Availability Zones fit together, and which of those choices you cannot reverse later","Calculate the usable IP addresses in a subnet by accounting for the 5 addresses AWS reserves","Identify what makes a subnet public or private, and why it is never a subnet setting","Distinguish the main route table from a custom route table and predict which one an unassociated subnet uses","Apply longest prefix match and the static-versus-propagated rules to resolve overlapping routes","Size subnets for a multi-AZ workload without exhausting the VPC CIDR",{"id":1073,"title":1062,"body":1074,"description":1063,"difficulty":1064,"estimatedMinutes":11,"extension":955,"infographics":1823,"isFree":5,"learningObjectives":1835,"meta":1836,"navigation":5,"path":1837,"quiz":1838,"seo":1909,"stem":1910,"__hash__":1911},"courses/courses/aws-certified-cloudops-engineer-associate/en/domains/05-networking-content-delivery/01-vpc-fundamentals/01-vpc-subnets-and-route-tables.md",{"type":34,"value":1075,"toc":1813},[1076,1087,1090,1094,1097,1108,1152,1174,1177,1181,1184,1196,1202,1227,1234,1253,1257,1260,1279,1282,1328,1335,1339,1346,1410,1414,1417,1485,1488,1494,1497,1501,1504,1510,1517,1520,1588,1594,1598,1605,1616,1622,1629,1632,1636,1643,1646,1690,1717,1724,1738,1741,1751,1762,1764,1806,1809],[37,1077,1078,1079,1082,1083,1086],{},"At 03:00 an Auto Scaling group stops launching. The event log says ",[161,1080,1081],{},"There are not enough free addresses in subnet subnet-0a1b2c3d to satisfy the requested number of instances",". The subnet is ",[161,1084,1085],{},"10.0.4.0/27",", the team sized it for 32 instances, and only 27 ever launched. Nothing is broken. The subnet did exactly what AWS documents it will do, and nobody read that part before picking the mask.",[37,1088,1089],{},"Address planning is the part of VPC design you cannot walk back. You can add a security group rule in 10 seconds and delete it in 10 more. You cannot resize a CIDR block at all. So this lesson starts with the address math, then moves to the route table, which is the other half of every VPC and the first place to look when traffic goes somewhere unexpected.",[44,1091,1093],{"id":1092},"a-vpc-is-an-address-range-plus-a-router","A VPC is an address range plus a router",[37,1095,1096],{},"Strip away the console and a VPC is 2 things: a block of IP addresses you claimed, and an implicit router that AWS runs for you inside that block. Everything else in this domain, subnets, gateways, endpoints, peering, is a way of telling that router where to send packets it does not already know about.",[37,1098,1099,1100,1103,1104,1107],{},"When you create a VPC you must give it an IPv4 CIDR block, and the allowed size runs from a ",[161,1101,1102],{},"/16"," (65,536 addresses) down to a ",[161,1105,1106],{},"/28"," (16 addresses). AWS recommends a block from the private ranges in RFC 1918:",[52,1109,1110,1120],{},[55,1111,1112],{},[58,1113,1114,1117],{},[61,1115,1116],{},"RFC 1918 range",[61,1118,1119],{},"Example VPC CIDR",[70,1121,1122,1132,1142],{},[58,1123,1124,1127],{},[75,1125,1126],{},"10.0.0.0 to 10.255.255.255",[75,1128,1129],{},[161,1130,1131],{},"10.0.0.0/16",[58,1133,1134,1137],{},[75,1135,1136],{},"172.16.0.0 to 172.31.255.255",[75,1138,1139],{},[161,1140,1141],{},"172.31.0.0/16",[58,1143,1144,1147],{},[75,1145,1146],{},"192.168.0.0 to 192.168.255.255",[75,1148,1149],{},[161,1150,1151],{},"192.168.0.0/20",[37,1153,1154,1155,164,1158,1161,1162,1165,1166,1169,1170,1173],{},"Four blocks are refused outright: ",[161,1156,1157],{},"0.0.0.0/8",[161,1159,1160],{},"127.0.0.0/8"," (loopback), ",[161,1163,1164],{},"169.254.0.0/16"," (link-local), and ",[161,1167,1168],{},"224.0.0.0/4"," (multicast). One more is allowed but should be avoided: several AWS services, including AWS Cloud9 and SageMaker AI, use ",[161,1171,1172],{},"172.17.0.0/16"," internally, and picking it invites conflicts inside those environments that are painful to diagnose.",[37,1175,1176],{},"You can also run a VPC on publicly routable addresses that you own. AWS still refuses to route from your VPC CIDR straight to the internet, and it never advertises a subnet range to the internet, so you always go through a gateway regardless.",[44,1178,1180],{"id":1179},"the-cidr-decisions-you-cannot-undo","The CIDR decisions you cannot undo",[37,1182,1183],{},"Three rules make the first CIDR choice expensive to get wrong.",[37,1185,1186,1189,1190,1192,1193,172],{},[156,1187,1188],{},"You cannot resize a CIDR block."," Not up, not down. If ",[161,1191,1131],{}," runs out, you do not turn it into a ",[161,1194,1195],{},"/15",[37,1197,1198,1201],{},[156,1199,1200],{},"You cannot remove the primary CIDR."," You can associate secondary IPv4 blocks (5 per VPC by default, adjustable up to 50) and disassociate those later. The block you created the VPC with stays for the life of the VPC.",[37,1203,1204,1207,1208,1211,1212,1215,1216,1219,1220,1223,1224,1226],{},[156,1205,1206],{},"Secondary blocks are restricted by the range the primary sits in."," If any CIDR on the VPC comes from ",[161,1209,1210],{},"10.0.0.0/8",", AWS refuses to add a block from ",[161,1213,1214],{},"172.16.0.0/12"," or ",[161,1217,1218],{},"192.168.0.0/16",". The same exclusion applies in each direction. AWS applies these restrictions because cross-VPC and cross-account features on the AWS side need non-conflicting blocks. Two more traps sit in the same rule set: if any associated block falls in ",[161,1221,1222],{},"10.0.0.0/15",", you cannot add one from ",[161,1225,1131],{},", and a new secondary block must not be the same size as or larger than any destination CIDR already sitting in one of your route tables.",[37,1228,1229,1230,1233],{},"Adding a secondary CIDR does one thing automatically: a new ",[161,1231,1232],{},"local"," route appears in every route table for that VPC, with the new block as the destination.",[37,1235,1236,1237,1240,1241,1244,1245,1248,1249,1252],{},"For IPv6 the shape is different. You request a block from Amazon's pool and you do not choose the range; a typical allocation looks like ",[161,1238,1239],{},"2001:db8:1234:1a00::/56",". You can associate up to 5 IPv6 blocks per VPC, from ",[161,1242,1243],{},"/44"," to ",[161,1246,1247],{},"/60"," in increments of ",[161,1250,1251],{},"/4",". Every Amazon-provided IPv6 address is globally unique and therefore public by default, which becomes the whole story in the next lesson.",[44,1254,1256],{"id":1255},"a-subnet-lives-in-exactly-one-availability-zone","A subnet lives in exactly one Availability Zone",[37,1258,1259],{},"A subnet is a slice of the VPC range, and it resides entirely within one Availability Zone. It cannot span zones. That single sentence sets the shape of every VPC you will ever build: to run a 2-tier workload across 3 zones you need 6 subnets, not 2.",[37,1261,1262,1263,1244,1265,1267,1268,1244,1270,1248,1273,1275,1276,1278],{},"Subnet IPv4 blocks run from ",[161,1264,1106],{},[161,1266,1102],{},", they must sit inside the VPC block, and they cannot overlap each other. The default quota is 200 subnets per VPC. For IPv6, subnet netmask lengths run from ",[161,1269,1243],{},[161,1271,1272],{},"/64",[161,1274,1251],{},", and a ",[161,1277,1272],{}," is the conventional choice.",[37,1280,1281],{},"The subnet types you will see named in exam questions are defined purely by routing, not by a setting:",[52,1283,1284,1294],{},[55,1285,1286],{},[58,1287,1288,1291],{},[61,1289,1290],{},"Subnet type",[61,1292,1293],{},"What its route table has",[70,1295,1296,1304,1312,1320],{},[58,1297,1298,1301],{},[75,1299,1300],{},"Public",[75,1302,1303],{},"A route to an internet gateway",[58,1305,1306,1309],{},[75,1307,1308],{},"Private",[75,1310,1311],{},"No route to an internet gateway (usually a route to a NAT device instead)",[58,1313,1314,1317],{},[75,1315,1316],{},"VPN-only",[75,1318,1319],{},"A route to a Site-to-Site VPN connection through a virtual private gateway, and no internet gateway route",[58,1321,1322,1325],{},[75,1323,1324],{},"Isolated",[75,1326,1327],{},"No routes to anything outside the VPC",[37,1329,1330,1331,1334],{},"One real subnet setting does exist and is worth knowing because it is often confused with the public/private distinction: ",[156,1332,1333],{},"auto-assign IP settings",", which decides whether a network interface created in that subnet automatically receives a public IPv4 address, and an IPv6 address if applicable. You can override it per instance at launch. It controls whether the instance has a public address, not whether traffic can reach the internet. Both are required, and they are configured in 2 different places.",[44,1336,1338],{"id":1337},"where-5-addresses-go-in-every-subnet","Where 5 addresses go in every subnet",[37,1340,1341,1342,1345],{},"Back to the 03:00 page. In a subnet with CIDR ",[161,1343,1344],{},"10.0.1.0/28",", AWS reserves the first 4 addresses and the last 1:",[52,1347,1348,1358],{},[55,1349,1350],{},[58,1351,1352,1355],{},[61,1353,1354],{},"Address",[61,1356,1357],{},"Reserved for",[70,1359,1360,1370,1380,1390,1400],{},[58,1361,1362,1367],{},[75,1363,1364],{},[161,1365,1366],{},"10.0.1.0",[75,1368,1369],{},"Network address",[58,1371,1372,1377],{},[75,1373,1374],{},[161,1375,1376],{},"10.0.1.1",[75,1378,1379],{},"The VPC router",[58,1381,1382,1387],{},[75,1383,1384],{},[161,1385,1386],{},"10.0.1.2",[75,1388,1389],{},"The Amazon DNS server",[58,1391,1392,1397],{},[75,1393,1394],{},[161,1395,1396],{},"10.0.1.3",[75,1398,1399],{},"Future use by AWS",[58,1401,1402,1407],{},[75,1403,1404],{},[161,1405,1406],{},"10.0.1.15",[75,1408,1409],{},"Network broadcast address (broadcast is not supported in a VPC)",[364,1411],{"alt":1412,"slug":1413},"The 16 addresses of subnet 10.0.1.0/28 laid out in order, with the first 4 and the last 1 marked as reserved by AWS and the 11 in between marked as usable.","subnet-reserved-addresses",[37,1415,1416],{},"Sixteen addresses in, 11 out. The overhead is a flat 5 at every size, so it hurts small subnets badly and large ones barely at all:",[52,1418,1419,1432],{},[55,1420,1421],{},[58,1422,1423,1426,1429],{},[61,1424,1425],{},"Subnet CIDR",[61,1427,1428],{},"Total addresses",[61,1430,1431],{},"Usable",[70,1433,1434,1446,1459,1472],{},[58,1435,1436,1440,1443],{},[75,1437,1438],{},[161,1439,1106],{},[75,1441,1442],{},"16",[75,1444,1445],{},"11",[58,1447,1448,1453,1456],{},[75,1449,1450],{},[161,1451,1452],{},"/27",[75,1454,1455],{},"32",[75,1457,1458],{},"27",[58,1460,1461,1466,1469],{},[75,1462,1463],{},[161,1464,1465],{},"/24",[75,1467,1468],{},"256",[75,1470,1471],{},"251",[58,1473,1474,1479,1482],{},[75,1475,1476],{},[161,1477,1478],{},"/20",[75,1480,1481],{},"4,096",[75,1483,1484],{},"4,091",[37,1486,1487],{},"This is where the predictable misconception lives. On premises you learn that a subnet loses 2 addresses, the network address and the broadcast address, and that rule is correct nearly everywhere except AWS. AWS takes 3 more. If you size a subnet by subtracting 2, you will be short by 3 exactly when it matters, during a scaling event.",[37,1489,1490,1491,1493],{},"A note on ",[161,1492,1386],{},". The Route 53 Resolver that your instances actually query lives at the base of the VPC range plus 2, and for a VPC with several CIDR blocks it sits in the primary block. AWS still reserves base-plus-2 in every subnet of every block, which is why the address is unavailable in each subnet even though only one of them hosts the resolver.",[37,1495,1496],{},"Two more consumers of subnet addresses surprise people during capacity planning: a NAT gateway takes a private address from the subnet it sits in, and every interface VPC endpoint takes one per subnet it is enabled in. Neither shows up as an instance.",[44,1498,1500],{"id":1499},"sizing-a-real-vpc","Sizing a real VPC",[37,1502,1503],{},"Take a workload with a web tier and a database tier across 2 Availability Zones, expected to grow.",[339,1505,1508],{"className":1506,"code":1507,"language":344},[342],"VPC            10.0.0.0/16      65,536 addresses\n\nPublic  AZ-a   10.0.0.0/24         251 usable  (ALB nodes, NAT gateway)\nPublic  AZ-b   10.0.1.0/24         251 usable\n\nPrivate AZ-a   10.0.16.0/20      4,091 usable  (application instances)\nPrivate AZ-b   10.0.32.0/20      4,091 usable\n\nData    AZ-a   10.0.48.0/24        251 usable  (RDS subnet group)\nData    AZ-b   10.0.49.0/24        251 usable\n",[161,1509,1507],{"__ignoreMap":347},[37,1511,1512,1513,1516],{},"Two things about this layout are deliberate. Public subnets are small because load balancer nodes and a NAT gateway need very few addresses, and private subnets are generous because that is where scaling happens. The blocks are also spaced out rather than packed end to end, leaving room to carve ",[161,1514,1515],{},"10.0.64.0/20"," and beyond for a third zone or a new tier without renumbering anything.",[37,1518,1519],{},"Verify capacity from the CLI rather than from a spreadsheet:",[339,1521,1525],{"className":1522,"code":1523,"language":1524,"meta":347,"style":347},"language-bash shiki shiki-themes material-theme-lighter github-light github-dark","aws ec2 describe-subnets \\\n  --filters \"Name=vpc-id,Values=vpc-0abc123def4567890\" \\\n  --query \"Subnets[].{Subnet:SubnetId,AZ:AvailabilityZone,CIDR:CidrBlock,Free:AvailableIpAddressCount}\" \\\n  --output table\n","bash",[161,1526,1527,1547,1565,1579],{"__ignoreMap":347},[1528,1529,1532,1536,1540,1543],"span",{"class":1530,"line":1531},"line",1,[1528,1533,1535],{"class":1534},"sbgvK","aws",[1528,1537,1539],{"class":1538},"s_sjI"," ec2",[1528,1541,1542],{"class":1538}," describe-subnets",[1528,1544,1546],{"class":1545},"s_hVV"," \\\n",[1528,1548,1549,1553,1557,1560,1563],{"class":1530,"line":945},[1528,1550,1552],{"class":1551},"stzsN","  --filters",[1528,1554,1556],{"class":1555},"sjJ54"," \"",[1528,1558,1559],{"class":1538},"Name=vpc-id,Values=vpc-0abc123def4567890",[1528,1561,1562],{"class":1555},"\"",[1528,1564,1546],{"class":1545},[1528,1566,1567,1570,1572,1575,1577],{"class":1530,"line":942},[1528,1568,1569],{"class":1551},"  --query",[1528,1571,1556],{"class":1555},[1528,1573,1574],{"class":1538},"Subnets[].{Subnet:SubnetId,AZ:AvailabilityZone,CIDR:CidrBlock,Free:AvailableIpAddressCount}",[1528,1576,1562],{"class":1555},[1528,1578,1546],{"class":1545},[1528,1580,1582,1585],{"class":1530,"line":1581},4,[1528,1583,1584],{"class":1551},"  --output",[1528,1586,1587],{"class":1538}," table\n",[37,1589,1590,1593],{},[161,1591,1592],{},"AvailableIpAddressCount"," is the number that matters during an incident. It already accounts for the 5 reserved addresses and for everything currently deployed.",[44,1595,1597],{"id":1596},"route-tables-decide-where-packets-go","Route tables decide where packets go",[37,1599,1600,1601,1604],{},"Every subnet must be associated with a route table. Associate one explicitly, or the subnet is implicitly associated with the VPC ",[156,1602,1603],{},"main route table",", which AWS creates with the VPC.",[37,1606,1607,1608,1611,1612,1615],{},"Each route has a ",[156,1609,1610],{},"destination"," (a CIDR block or a prefix list) and a ",[156,1613,1614],{},"target"," (an internet gateway, NAT gateway, network interface, peering connection, transit gateway, and so on). The router compares a packet's destination address against the destinations in the table and hands the packet to the matching target.",[37,1617,1618,1619,1621],{},"Every route table also contains a ",[156,1620,1232],{}," route, one per associated CIDR block, IPv4 and IPv6 counted separately. It covers traffic inside the VPC, it is added automatically, and you cannot delete it. You can replace or restore its target, and you can add a route more specific than the local route as long as the destination matches an entire subnet CIDR and the target is a NAT gateway, a network interface, or a Gateway Load Balancer endpoint. That exception exists so you can force traffic between 2 subnets through an inspection appliance.",[37,1623,1624,1625,1628],{},"The main route table has its own rules. You can edit its routes but not delete it, you cannot make a gateway route table the main table, and you can replace it by making a custom table the main one. AWS recommends leaving it with only the local route and associating every subnet explicitly, and there is a sharp reason for that recommendation. Put a ",[161,1626,1627],{},"0.0.0.0/0"," route to an internet gateway in the main route table and every subnet you create from then on, until someone associates it elsewhere, is a public subnet. Nobody sets out to do that. It happens when a route is added to the table that happened to be open in the console.",[37,1630,1631],{},"Quotas worth remembering: 200 route tables per VPC, 500 non-propagated routes per route table (adjustable to 1,000), and 100 propagated routes, which is not adjustable.",[44,1633,1635],{"id":1634},"two-routes-match-now-what","Two routes match. Now what?",[37,1637,1638,1639,1642],{},"Route tables are not firewall rule lists. They are not evaluated top to bottom, and there is no rule order to reason about. AWS picks the ",[156,1640,1641],{},"most specific matching route",", which is the longest prefix match.",[37,1644,1645],{},"Walk one table:",[52,1647,1648,1658],{},[55,1649,1650],{},[58,1651,1652,1655],{},[61,1653,1654],{},"Destination",[61,1656,1657],{},"Target",[70,1659,1660,1668,1679],{},[58,1661,1662,1666],{},[75,1663,1664],{},[161,1665,1131],{},[75,1667,1232],{},[58,1669,1670,1674],{},[75,1671,1672],{},[161,1673,1141],{},[75,1675,1676],{},[161,1677,1678],{},"pcx-11223344556677889",[58,1680,1681,1685],{},[75,1682,1683],{},[161,1684,1627],{},[75,1686,1687],{},[161,1688,1689],{},"igw-12345678901234567",[37,1691,1692,1693,1696,1697,1699,1700,1702,1703,1705,1706,1709,1710,1712,1713,1716],{},"A packet for ",[161,1694,1695],{},"172.31.5.10"," matches both ",[161,1698,1141],{}," and ",[161,1701,1627],{},". The ",[161,1704,1102],{}," is more specific, so the packet goes to the peering connection. A packet for ",[161,1707,1708],{},"93.184.216.34"," matches only ",[161,1711,1627],{}," and goes to the internet gateway. A packet for ",[161,1714,1715],{},"10.0.4.19"," matches the local route and never leaves the VPC.",[37,1718,1719,1720,1723],{},"When 2 routes have the ",[156,1721,1722],{},"same"," destination, the tie is broken by a priority ladder:",[557,1725,1726,1729,1732,1735],{},[153,1727,1728],{},"Longest prefix (this settles most cases before the rest matter)",[153,1730,1731],{},"Static routes",[153,1733,1734],{},"Prefix list routes",[153,1736,1737],{},"Propagated routes, in the order Direct Connect BGP routes, then VPN static routes, then VPN BGP routes",[37,1739,1740],{},"Static routes are the ones you create, plus those created by an internet gateway, NAT gateway, network interface, instance ID, gateway VPC endpoint, transit gateway, VPC peering connection, or Gateway Load Balancer endpoint. Propagated routes are the ones that appear automatically when you attach a virtual private gateway and enable route propagation.",[37,1742,1743,1744,1747,1748,1750],{},"This ladder produces one of the quieter production failures in AWS networking. A hybrid VPC propagates ",[161,1745,1746],{},"172.31.0.0/24"," from the on-premises network through a virtual private gateway. Someone later adds a static route for the same ",[161,1749,1746],{}," to an internet gateway. Nothing errors. The static route wins, and traffic that should have crossed the VPN heads for the public internet instead. If a scenario says traffic bound for a data center is \"leaving through the internet gateway\", check for a static route that shadows the propagated one.",[37,1752,1753,1754,1757,1758,1761],{},"Two ranges cannot be routed at all: ",[161,1755,1756],{},"169.254.168.0/22"," for IPv4 and ",[161,1759,1760],{},"fd00:ec2::/32"," for IPv6. AWS reserves them for services reachable only from instances, such as the Instance Metadata Service and the Amazon DNS server. A larger overlapping block is accepted, but packets aimed inside the reserved range are not forwarded.",[44,1763,891],{"id":890},[150,1765,1766,1775,1782,1785,1788,1791,1794,1797,1800,1803],{},[153,1767,1768,1769,1771,1772,1774],{},"Subnet address math: subtract 5, never 2. A ",[161,1770,1465],{}," gives 251 usable addresses, a ",[161,1773,1106],{}," gives 11. Insufficient-address errors during scaling are this calculation.",[153,1776,1777,1778,1781],{},"Public versus private is a property of the ",[156,1779,1780],{},"route table",", never of the subnet. A question that says \"the subnet was configured as private\" is describing a route table, and the fix is always routing.",[153,1783,1784],{},"Reaching the internet takes both a route to an internet gateway and a public IPv4 or IPv6 address on the resource. Missing either one produces the same symptom.",[153,1786,1787],{},"A subnet with no explicit route table association uses the main route table. This is how subnets accidentally become public.",[153,1789,1790],{},"Longest prefix match settles overlapping routes. Route tables have no evaluation order, so \"the first matching route\" is always a wrong answer.",[153,1792,1793],{},"Identical destinations: static beats propagated. Watch for this in hybrid scenarios where traffic is going out the wrong gateway.",[153,1795,1796],{},"You cannot resize a CIDR block or remove the primary CIDR. If an option offers to expand a VPC CIDR in place, it is wrong.",[153,1798,1799],{},"Secondary CIDR restriction: a VPC using one RFC 1918 range cannot add a block from a different RFC 1918 range.",[153,1801,1802],{},"A subnet sits in one Availability Zone. Multi-AZ means more subnets, not bigger ones.",[153,1804,1805],{},"The local route cannot be deleted. It can have its target replaced, and it can be overridden by a more specific route whose destination is an entire subnet CIDR and whose target is a NAT gateway, network interface, or Gateway Load Balancer endpoint.",[37,1807,1808],{},"The habit to carry forward is that a VPC answers exactly 2 questions about any packet: does this address belong to me, and if not, which target do I hand it to? Address planning answers the first, route tables answer the second, and almost every connectivity ticket in this domain is one of those 2 answers being wrong. The next lesson takes the most common target you will put in a route table, the gateways that connect a VPC to the internet, and shows why 3 of them exist instead of one.",[1810,1811,1812],"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 .sjJ54, html code.shiki .sjJ54{--shiki-light:#39ADB5;--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":347,"searchDepth":942,"depth":942,"links":1814},[1815,1816,1817,1818,1819,1820,1821,1822],{"id":1092,"depth":945,"text":1093},{"id":1179,"depth":945,"text":1180},{"id":1255,"depth":945,"text":1256},{"id":1337,"depth":945,"text":1338},{"id":1499,"depth":945,"text":1500},{"id":1596,"depth":945,"text":1597},{"id":1634,"depth":945,"text":1635},{"id":890,"depth":945,"text":891},[1824],{"slug":1413,"concept":1825,"style":959,"aspectRatio":960,"labels":1826},"A single horizontal band representing every address in the subnet 10.0.1.0/28, drawn as 16 equal cells left to right in address order. The first 4 cells and the final cell are shaded as unavailable and each carries a callout naming what AWS reserves it for; the 11 cells between them are shaded as usable and carry one shared bracket label. A footer strip states the rule that generalizes to every subnet size. Emphasis goes on the visual asymmetry, 4 lost at the start and 1 at the end, because that asymmetry is what learners miscount.",[1827,1828,1829,1830,1831,1832,1833,1834],"Subnet 10.0.1.0/28: 16 addresses, 11 usable","10.0.1.0: network address","10.0.1.1: reserved for the VPC router","10.0.1.2: reserved for the Amazon DNS server","10.0.1.3: reserved by AWS for future use","10.0.1.4 through 10.0.1.14: yours, 11 addresses","10.0.1.15: network broadcast address","Every subnet loses its first 4 addresses and its last 1, at every size",[1066,1067,1068,1069,1070,1071],{},"/courses/aws-certified-cloudops-engineer-associate/en/domains/05-networking-content-delivery/01-vpc-fundamentals/01-vpc-subnets-and-route-tables",{"passingScore":974,"questions":1839},[1840,1848,1856,1864,1873,1881,1889,1897,1901],{"question":1841,"type":978,"options":1842,"correctAnswer":1845,"explanation":1847},"An Auto Scaling group in a private subnet with CIDR 10.0.4.0/27 fails to launch its 28th instance with an insufficient free addresses error. The subnet also holds a NAT gateway network interface. How many addresses were ever available to your instances in that subnet?",[1843,1844,1845,1846],"32, because a /27 contains 32 addresses","31, because only the network address is reserved","27, because AWS reserves the first 4 addresses and the last 1","30, because the network and broadcast addresses are reserved","A /27 holds 32 addresses, but AWS takes the first 4 (network, VPC router, Amazon DNS, future use) and the last 1 (broadcast), leaving 27. The two-reserved-address answer is the on-premises convention and is the most common wrong assumption people bring to AWS. Anything else consuming addresses in the subnet, such as the NAT gateway interface or an interface VPC endpoint, comes out of those 27 as well.",{"question":1849,"type":978,"options":1850,"correctAnswer":1852,"explanation":1855},"You created a subnet, launched an instance into it with a public IPv4 address, attached an internet gateway to the VPC, and the instance still cannot reach the internet. What is the most likely cause?",[1851,1852,1853,1854],"The subnet's public IP addressing attribute is disabled","The subnet's route table has no route with the internet gateway as the target","The subnet was created as a private subnet and must be recreated as public","The internet gateway needs an Elastic IP address before it can pass traffic","There is no public or private flag on a subnet. A subnet is public only because the route table associated with it sends 0.0.0.0/0 to an internet gateway, so a missing or wrong route table association is the standard cause. The instance already has a public IP, which rules out the addressing attribute, and internet gateways never take an Elastic IP of their own.",{"question":1857,"type":978,"options":1858,"correctAnswer":1859,"explanation":1863},"A subnet in your VPC was never explicitly associated with any route table. Which route table controls its traffic?",[1859,1860,1861,1862],"The main route table for the VPC","No route table, so the subnet drops all traffic until you associate one","The route table of the first subnet created in the same Availability Zone","A private route table that AWS creates automatically for each subnet","Every subnet must be associated with a route table, and a subnet with no explicit association is implicitly associated with the VPC main route table. This is why adding an internet gateway route to the main route table quietly makes every unassociated subnet public. The recommended practice is to leave the main route table with only its local route and associate every subnet explicitly.",{"question":1865,"type":987,"options":1866,"correctAnswers":1871,"explanation":1872},"Which statements about the local route in a VPC route table are correct? (Choose 2.)",[1867,1868,1869,1870],"A VPC with 2 IPv4 CIDR blocks has 2 local routes in each route table","The local route can be deleted if you want to isolate a subnet from the rest of the VPC","You can add a route more specific than the local route if its destination matches an entire subnet CIDR and its target is a NAT gateway, network interface, or Gateway Load Balancer endpoint","The local route appears only in the main route table",[1867,1869],"Every route table gets a local route per associated CIDR block, IPv4 and IPv6 counted separately, and they appear in all route tables rather than just the main one. You cannot delete a local route, though you can replace or restore its target, and you can override it with a more specific route under the stated conditions, which is how middlebox inspection between subnets is built.",{"question":1874,"type":978,"options":1875,"correctAnswer":1879,"explanation":1880},"A subnet route table contains 0.0.0.0/0 pointing to an internet gateway and 172.31.0.0/16 pointing to a VPC peering connection. Where does traffic destined for 172.31.5.10 go?",[1876,1877,1878,1879],"To the internet gateway, because the default route is evaluated first","It is dropped, because the two routes conflict","To both targets, and the first response wins","To the peering connection, because /16 is more specific than /0","AWS routes using longest prefix match, so the most specific matching route wins regardless of the order the routes appear in the table. Route tables are not evaluated top to bottom like a firewall rule list, which is the misreading behind the first option. Only when 2 routes have identical destinations do the static-versus-propagated rules come into play.",{"question":1882,"type":978,"options":1883,"correctAnswer":1884,"explanation":1888},"Your route table has a propagated route for 172.31.0.0/24 to a virtual private gateway and a static route for 172.31.0.0/24 to an internet gateway. Which one wins?",[1884,1885,1886,1887],"The static route to the internet gateway","The propagated route to the virtual private gateway, because BGP routes reflect live reachability","Neither, because AWS rejects a static route that duplicates a propagated destination","Whichever route was created most recently","When destinations are identical, a static route takes priority over a propagated one, and internet gateways, NAT gateways, network interfaces, gateway VPC endpoints, transit gateways, peering connections, and Gateway Load Balancer endpoints all create static routes. Among propagated routes only, the order is Direct Connect BGP routes, then VPN static routes, then VPN BGP routes. AWS accepts both entries without complaint, which is exactly why this silently misroutes traffic.",{"question":1890,"type":978,"options":1891,"correctAnswer":1895,"explanation":1896},"You created a VPC with the primary CIDR 10.0.0.0/16 and are running out of space. Which secondary CIDR block can you associate?",[1892,1893,1894,1895],"172.20.0.0/16, because it is a different RFC 1918 range","192.168.0.0/16, because it does not overlap the primary","10.0.0.0/15, to widen the existing block","10.1.0.0/16, because it comes from the same 10.0.0.0/8 range","When an existing VPC CIDR sits in one RFC 1918 range, AWS restricts you from adding blocks from the other RFC 1918 ranges, so 172.20.0.0/16 and 192.168.0.0/16 are both refused. You also cannot resize an existing CIDR block, which rules out widening 10.0.0.0/16 to a /15. Any non-restricted block from 10.0.0.0/8 between /16 and /28 is permitted, and 10.1.0.0/16 qualifies.",{"question":1898,"type":978,"options":1899,"correctAnswer":1047,"explanation":1900},"True or False: a subnet can span 2 Availability Zones for higher availability.",[1046,1047],"A subnet resides entirely within one Availability Zone and cannot span zones, which is why multi-AZ designs mean one subnet per zone per tier rather than one wide subnet. This constraint drives most VPC address planning: the number of subnets you need is tiers multiplied by zones. It is also why a single NAT gateway or a single zonal resource becomes an availability problem for the subnets in other zones.",{"question":1902,"type":978,"options":1903,"correctAnswer":1904,"explanation":1908},"A team asks for a VPC CIDR that will not collide with anything. Which range should you avoid even though AWS technically allows it?",[1904,1905,1906,1907],"172.17.0.0/16, which several AWS services such as AWS Cloud9 and SageMaker AI use internally","10.0.0.0/16, because it is the AWS default and is always in use elsewhere","192.168.0.0/20, because it is too small for production","172.31.0.0/16, because AWS blocks it outright","AWS explicitly warns that some services use 172.17.0.0/16 internally and that overlapping it can produce IP address conflicts inside those environments. The blocks AWS refuses outright are 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, and 224.0.0.0/4. 172.31.0.0/16 is the default VPC range, which is worth avoiding for peering reasons but is not blocked, and 10.0.0.0/16 is merely conventional.",{"title":1062,"description":1063},"courses/aws-certified-cloudops-engineer-associate/en/domains/05-networking-content-delivery/01-vpc-fundamentals/01-vpc-subnets-and-route-tables","-PO9VNcRoRwdFQEf50Iy-tWgNcHnw8sLaXuJuQZmJOk"]