{"id":330,"date":"2026-04-13T16:37:02","date_gmt":"2026-04-13T16:37:02","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/aws-amazon-inspector-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security-identity-and-compliance\/"},"modified":"2026-04-13T16:37:02","modified_gmt":"2026-04-13T16:37:02","slug":"aws-amazon-inspector-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security-identity-and-compliance","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/aws-amazon-inspector-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security-identity-and-compliance\/","title":{"rendered":"AWS Amazon Inspector Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security, identity, and compliance"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Security, identity, and compliance<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What this service is<\/strong>: Amazon Inspector is an AWS managed vulnerability management service that continuously scans AWS workloads for software vulnerabilities and (for some resource types) unintended exposure.<\/li>\n<li><strong>One-paragraph simple explanation<\/strong>: You turn on Amazon Inspector, select what you want to scan (for example, EC2 instances, container images in Amazon ECR, and AWS Lambda functions), and it automatically produces prioritized security findings with remediation guidance.<\/li>\n<li><strong>One-paragraph technical explanation<\/strong>: Amazon Inspector analyzes software inventory and metadata for supported resources, correlates it with vulnerability intelligence (for example CVEs), evaluates reachability context for certain findings, and publishes findings into the AWS console and APIs. Findings can be routed to tools like AWS Security Hub and Amazon EventBridge for alerting, ticketing, and automation.<\/li>\n<li><strong>What problem it solves<\/strong>: It reduces the operational burden of continuously identifying known vulnerabilities and risky exposure across common AWS compute packaging models (instances, containers, and serverless), and it helps teams prioritize remediation with centralized reporting.<\/li>\n<\/ul>\n\n\n\n<p><strong>Important naming note (legacy vs current):<\/strong> AWS has two related offerings:\n&#8211; <strong>Amazon Inspector (current service)<\/strong> \u2014 the modern, continuously running vulnerability management service (this tutorial).\n&#8211; <strong>Amazon Inspector Classic (legacy)<\/strong> \u2014 the earlier assessment-run model. If you see \u201cInspector Classic\u201d in the console or docs, treat it as legacy and use it only if you must maintain older workflows. Prefer the current <strong>Amazon Inspector<\/strong> for new deployments. Verify the current lifecycle status of Inspector Classic in official AWS announcements and documentation.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Amazon Inspector?<\/h2>\n\n\n\n<p>Amazon Inspector is an AWS <strong>Security, identity, and compliance<\/strong> service focused on <strong>automated vulnerability management<\/strong> for supported AWS resources. Its official purpose is to help you <strong>discover, prioritize, and remediate<\/strong> software vulnerabilities and unintended exposure by continuously scanning common workload types.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities (what it does)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Continuously scans supported compute<\/strong> for vulnerabilities (for example, package vulnerabilities with CVEs).<\/li>\n<li><strong>Generates security findings<\/strong> with severity, affected resource, and remediation recommendations.<\/li>\n<li><strong>Adds context to prioritize<\/strong> (for example, reachability\/exposure signals for certain EC2 findings).<\/li>\n<li><strong>Integrates with AWS security and automation services<\/strong> to centralize and act on findings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (conceptual building blocks)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Coverage configuration<\/strong>: What resource types are enabled for scanning (EC2, ECR, Lambda\u2014availability depends on region and your account setup; verify in docs).<\/li>\n<li><strong>Findings<\/strong>: The primary output\u2014structured security issues that can be filtered, exported, and actioned.<\/li>\n<li><strong>Resource inventory &amp; scanning pipeline<\/strong>: Service-managed collection and analysis that powers continuous evaluation.<\/li>\n<li><strong>Integrations<\/strong>:<\/li>\n<li><strong>AWS Organizations<\/strong> for multi-account enablement (delegated administrator pattern).<\/li>\n<li><strong>Amazon EventBridge<\/strong> for event-driven automation on findings.<\/li>\n<li><strong>AWS Security Hub<\/strong> for centralized security posture management (optional).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed AWS service<\/strong> (you do not manage scanners or databases yourself).<\/li>\n<li><strong>Control plane + analysis plane<\/strong> operated by AWS; you interact via the <strong>AWS Console<\/strong>, <strong>AWS CLI<\/strong>, and <strong>Inspector APIs<\/strong> (commonly referred to as the <em>Inspector2<\/em> API in AWS SDK\/CLI naming).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope and availability model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Regional service<\/strong>: Amazon Inspector is enabled and produces findings <strong>per AWS Region<\/strong>. Multi-region coverage requires enabling it in each region you use.<\/li>\n<li><strong>Account-scoped with multi-account support<\/strong>: You enable it per account, and you can centrally manage it using <strong>AWS Organizations<\/strong> (recommended for production).<\/li>\n<li><strong>Resource-scoped<\/strong>: Findings are tied to specific resources (EC2 instance IDs, ECR image digests, Lambda function versions, etc.).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the AWS ecosystem<\/h3>\n\n\n\n<p>Amazon Inspector is typically one part of a broader AWS security stack:\n&#8211; <strong>AWS Security Hub<\/strong> aggregates findings from Inspector plus other services.\n&#8211; <strong>Amazon GuardDuty<\/strong> detects threats (behavioral\/telemetry-based), while Inspector focuses on <strong>known vulnerabilities<\/strong>.\n&#8211; <strong>AWS Systems Manager<\/strong> is commonly used alongside Inspector for patching workflows and fleet ops.\n&#8211; <strong>Amazon EventBridge<\/strong>, <strong>SNS<\/strong>, and ticketing tools drive remediation automation.<\/p>\n\n\n\n<p>Official documentation entry point: https:\/\/docs.aws.amazon.com\/inspector\/latest\/user\/what-is-inspector.html<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Amazon Inspector?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduce breach risk<\/strong> by systematically identifying exploitable known vulnerabilities.<\/li>\n<li><strong>Lower operational overhead<\/strong> versus building and maintaining your own scanning infrastructure.<\/li>\n<li><strong>Improve audit readiness<\/strong> by keeping a measurable vulnerability management process with centralized findings and history.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Native AWS coverage<\/strong> for common workload packaging models (instances, containers in ECR, and Lambda).<\/li>\n<li><strong>Continuous scanning<\/strong> rather than one-time or ad-hoc checks.<\/li>\n<li><strong>API-driven workflows<\/strong> for integrating with CI\/CD, security tooling, and ticketing systems.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Centralized visibility<\/strong> of vulnerabilities across accounts and regions (with AWS Organizations).<\/li>\n<li><strong>Automatable response<\/strong> through EventBridge rules (for example: auto-create Jira tickets, open ServiceNow incidents, or notify Slack via SNS\/Lambda).<\/li>\n<li><strong>Actionable remediation guidance<\/strong> (for example, update package versions, rebuild images, patch instances).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Supports vulnerability management controls that commonly appear in frameworks such as <strong>ISO 27001<\/strong>, <strong>SOC 2<\/strong>, <strong>PCI DSS<\/strong>, and internal security baselines (exact mapping depends on your program; verify with your compliance team).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Scales with AWS-managed backend services; no scanner fleet to scale yourself.<\/li>\n<li>Handles multi-account setups via delegated admin, avoiding per-account manual work.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You run workloads on <strong>EC2<\/strong>, <strong>ECR<\/strong>, and\/or <strong>Lambda<\/strong> and need continuous vulnerability visibility.<\/li>\n<li>You want <strong>AWS-native integrations<\/strong> and centralized governance.<\/li>\n<li>You need an <strong>audit-friendly<\/strong> vulnerability management pipeline with evidence in AWS.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it (or should supplement it)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You need <strong>deep web app scanning (DAST)<\/strong>, <strong>SAST<\/strong>, or <strong>SBOM governance<\/strong> across non-AWS registries and build systems\u2014Inspector is not a full AppSec platform.<\/li>\n<li>Your workloads are primarily <strong>on-premises<\/strong> or <strong>multi-cloud<\/strong> and you require uniform scanning across environments (you may need a third-party platform).<\/li>\n<li>You require scanning of container images stored <strong>outside Amazon ECR<\/strong> (Inspector\u2019s strongest container integration is with ECR; verify current coverage in docs).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Amazon Inspector used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS and software companies running on AWS.<\/li>\n<li>Financial services and fintech (strong compliance requirements).<\/li>\n<li>Healthcare and life sciences (regulated environments).<\/li>\n<li>Retail\/e-commerce (high availability and constant release cycles).<\/li>\n<li>Media\/gaming (large-scale compute fleets and containerized workloads).<\/li>\n<li>Public sector (standardized security baselines and continuous monitoring).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Security engineering \/ vulnerability management teams.<\/li>\n<li>Platform engineering and SRE teams responsible for fleet hygiene.<\/li>\n<li>DevOps teams owning CI\/CD and container pipelines.<\/li>\n<li>Cloud Center of Excellence (CCoE) teams standardizing controls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads and architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Microservices on EKS\/ECS<\/strong> using images in <strong>Amazon ECR<\/strong>.<\/li>\n<li><strong>EC2 fleets<\/strong> (ASGs, immutable infrastructure, golden AMIs).<\/li>\n<li><strong>Serverless applications<\/strong> (Lambda with shared layers and frequent deployments).<\/li>\n<li>Multi-account landing zones with AWS Organizations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: Always-on scanning, findings routed to Security Hub, automated ticketing, and patch SLAs.<\/li>\n<li><strong>Dev\/Test<\/strong>: Early detection in shared development accounts; integration with CI\/CD to block promotions when high severity findings exist (often implemented via custom logic consuming Inspector findings).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Amazon Inspector is commonly used.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Continuous EC2 vulnerability monitoring for patch SLAs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You must meet patch timelines (for example, critical CVEs within X days).<\/li>\n<li><strong>Why Inspector fits<\/strong>: Continuously detects vulnerable packages on supported EC2 instances and generates findings you can track over time.<\/li>\n<li><strong>Example<\/strong>: An operations team monitors findings and uses Systems Manager Patch Manager to patch instances weekly, verifying closure via updated findings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Container image vulnerability scanning for Amazon ECR<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Base images drift and new CVEs are disclosed after deployment.<\/li>\n<li><strong>Why Inspector fits<\/strong>: Scans images stored in ECR and produces findings tied to image digests and repositories.<\/li>\n<li><strong>Example<\/strong>: A platform team blocks deployment of images with critical findings by adding a pipeline gate that queries Inspector findings for the image digest.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Lambda package vulnerability scanning for serverless apps<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Lambda dependencies include vulnerable libraries that are hard to inventory manually.<\/li>\n<li><strong>Why Inspector fits<\/strong>: Scans supported Lambda packages and reports vulnerable components (verify exact runtime\/package coverage in docs).<\/li>\n<li><strong>Example<\/strong>: A serverless team gets EventBridge alerts when a new critical vulnerability affects a deployed Lambda function.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Multi-account vulnerability governance with AWS Organizations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Each application team runs its own AWS account; security needs central visibility.<\/li>\n<li><strong>Why Inspector fits<\/strong>: Supports delegated administration and organization-wide enablement.<\/li>\n<li><strong>Example<\/strong>: Security enables Inspector in a delegated admin account, monitors findings in aggregate, and routes them to Security Hub.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Prioritization using reachability context (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Too many CVEs; teams need help prioritizing what\u2019s actually exposed.<\/li>\n<li><strong>Why Inspector fits<\/strong>: Can provide exposure\/reachability-related context for certain findings (verify the current behavior and resource types in official docs).<\/li>\n<li><strong>Example<\/strong>: Focus remediation on instances reachable from the internet before internal-only systems.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Security Hub centralization for executive reporting<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Leadership wants a single security dashboard across accounts\/services.<\/li>\n<li><strong>Why Inspector fits<\/strong>: Findings can be sent to AWS Security Hub for aggregation with other signals.<\/li>\n<li><strong>Example<\/strong>: Security Hub shows Inspector critical findings trend over 90 days as a KPI.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Automated ticket creation and routing by ownership tags<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Findings aren\u2019t acted on because ownership is unclear.<\/li>\n<li><strong>Why Inspector fits<\/strong>: Findings include resource identifiers; you can map them to tags and owners via automation.<\/li>\n<li><strong>Example<\/strong>: An EventBridge rule triggers a Lambda that reads EC2 tags and creates a ticket in the correct team queue.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Immutable infrastructure validation (golden AMIs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You bake AMIs but want to ensure they stay compliant with vulnerability thresholds.<\/li>\n<li><strong>Why Inspector fits<\/strong>: Continuously scans running instances derived from those AMIs; you can also scan container images in ECR used by your AMI-based services.<\/li>\n<li><strong>Example<\/strong>: Findings spike after a new CVE; the AMI pipeline rebuilds a patched AMI and rotates the ASG.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Incident response enrichment<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: During an incident, responders need to quickly understand if affected hosts have known vulnerabilities.<\/li>\n<li><strong>Why Inspector fits<\/strong>: Inspector findings provide a quick view of known vulnerabilities on affected resources.<\/li>\n<li><strong>Example<\/strong>: IR team correlates a GuardDuty alert with Inspector findings on the same instance to prioritize containment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Compliance evidence for vulnerability management controls<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Auditors request proof of ongoing vulnerability monitoring and remediation.<\/li>\n<li><strong>Why Inspector fits<\/strong>: Provides centralized findings, timestamps, and statuses that can support evidence collection (you still need process and documentation).<\/li>\n<li><strong>Example<\/strong>: Security exports findings and remediation timelines for quarterly audit packages.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Pre-production hardening checks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Staging environments drift and ship vulnerabilities to production.<\/li>\n<li><strong>Why Inspector fits<\/strong>: Continuous scanning reveals drift and missing patches early.<\/li>\n<li><strong>Example<\/strong>: Release managers require \u201cno critical findings\u201d in staging before production cutover.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Vulnerability trend analytics and KPI tracking<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need measurable progress and accountability.<\/li>\n<li><strong>Why Inspector fits<\/strong>: Findings can be aggregated and analyzed (for example via Security Hub, SIEM exports, or data lakes).<\/li>\n<li><strong>Example<\/strong>: A security program tracks MTTR for critical findings by application team.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Feature availability can vary by region and resource type. Always confirm coverage and prerequisites in the official docs.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">6.1 Continuous vulnerability scanning for supported EC2 instances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Identifies vulnerable software packages and related CVEs on supported EC2 instances.<\/li>\n<li><strong>Why it matters<\/strong>: EC2 fleets often contain long-lived instances where patching gaps accumulate.<\/li>\n<li><strong>Practical benefit<\/strong>: You get continuously updated findings instead of periodic manual scans.<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>Requires supported operating systems and collection mechanisms (often involves AWS Systems Manager\/SSM availability). Verify exact OS support and requirements in docs.<\/li>\n<li>Instances without proper permissions\/agents may show reduced coverage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.2 Container image scanning for Amazon ECR<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Scans images stored in <strong>Amazon Elastic Container Registry (ECR)<\/strong> and reports OS\/package vulnerabilities.<\/li>\n<li><strong>Why it matters<\/strong>: Most container vulnerabilities come from base images and OS packages.<\/li>\n<li><strong>Practical benefit<\/strong>: You can tie findings to a repository, image tag, and digest to drive rebuild workflows.<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>Strongest integration is for images stored in ECR; external registries require alternative tooling.<\/li>\n<li>Findings depend on what the service can analyze (for example, OS packages vs application dependencies\u2014verify scope per language\/runtime).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.3 Lambda function package scanning (where available)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Scans Lambda function code packages to identify vulnerable dependencies (coverage depends on runtime and packaging; verify in docs).<\/li>\n<li><strong>Why it matters<\/strong>: Serverless removes server patching, but dependency vulnerabilities remain.<\/li>\n<li><strong>Practical benefit<\/strong>: Inventory and vulnerability visibility without adding agents.<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>Runtime and package type support varies.<\/li>\n<li>Layer handling and dependency resolution details should be verified in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.4 Network exposure \/ reachability findings (EC2-related)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Detects certain exposure conditions (for example, unintended network reachability) and emits findings.<\/li>\n<li><strong>Why it matters<\/strong>: Vulnerability risk increases when vulnerable systems are reachable from untrusted networks.<\/li>\n<li><strong>Practical benefit<\/strong>: Helps you prioritize remediation by exposure context.<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>The exact reachability logic and supported cases evolve; verify in docs.<\/li>\n<li>It is not a full network security analysis replacement for architecture review and network firewall policy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.5 Findings management: filtering, severity, and remediation guidance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides structured findings with severity, affected resources, and recommended fixes.<\/li>\n<li><strong>Why it matters<\/strong>: Vulnerability data is only useful if it\u2019s actionable.<\/li>\n<li><strong>Practical benefit<\/strong>: Teams can triage by severity, resource tags, repository, account, or environment.<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>\u201cFix available\u201d depends on upstream packages\/vendors and your patching model.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.6 Multi-account management via AWS Organizations (delegated admin)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Centralizes enablement and visibility for an organization.<\/li>\n<li><strong>Why it matters<\/strong>: Most production AWS environments use multi-account strategies.<\/li>\n<li><strong>Practical benefit<\/strong>: Security teams can standardize coverage without logging into every account.<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>Requires AWS Organizations configuration and the right delegated admin design.<\/li>\n<li>Cross-account permissions and data residency policies must be reviewed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.7 Integrations for alerting, automation, and aggregation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>:<\/li>\n<li><strong>EventBridge<\/strong>: route findings to automation.<\/li>\n<li><strong>Security Hub<\/strong>: aggregate and correlate security findings.<\/li>\n<li><strong>Why it matters<\/strong>: Vulnerability management requires workflow integration, not just dashboards.<\/li>\n<li><strong>Practical benefit<\/strong>: Create tickets, send notifications, or auto-remediate based on finding types.<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>Automation must be carefully designed to avoid unsafe auto-changes in production.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.8 APIs, AWS CLI, and SDK support (Inspector2 API)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Enables \u201ceverything as code\u201d enablement, reporting, and automation.<\/li>\n<li><strong>Why it matters<\/strong>: Production security programs need repeatable configuration and evidence.<\/li>\n<li><strong>Practical benefit<\/strong>: You can integrate findings into CI\/CD or scheduled reporting.<\/li>\n<li><strong>Limitations\/caveats<\/strong>:<\/li>\n<li>API names in CLI\/SDK often use <code>inspector2<\/code> even though the product name is Amazon Inspector.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>At a high level:\n1. You <strong>enable Amazon Inspector<\/strong> for one or more resource types in a region.\n2. Inspector <strong>discovers supported resources<\/strong> (instances, ECR images, Lambda functions).\n3. Inspector <strong>collects metadata\/inventory<\/strong> (service-managed; EC2 often depends on SSM-managed instance connectivity and permissions\u2014verify exact mechanisms in docs).\n4. Inspector <strong>analyzes<\/strong> the collected data against vulnerability intelligence and exposure context.\n5. Inspector <strong>publishes findings<\/strong> to the Inspector console\/API and optionally forwards them to <strong>Security Hub<\/strong> and\/or <strong>EventBridge<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Data\/control flow (practical view)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane<\/strong>:<\/li>\n<li>Enable\/disable scanning<\/li>\n<li>Configure organization coverage<\/li>\n<li>Configure integrations<\/li>\n<li><strong>Data plane<\/strong>:<\/li>\n<li>Findings emitted and updated over time<\/li>\n<li>Events produced for new\/updated findings<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related AWS services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Organizations<\/strong>: delegated admin, organization-wide coverage.<\/li>\n<li><strong>AWS Systems Manager (SSM)<\/strong>: commonly required for EC2 managed instance connectivity and inventory\/collection (exact prerequisites and supported OS list: verify in docs).<\/li>\n<li><strong>Amazon ECR<\/strong>: image storage and scanning source for container images.<\/li>\n<li><strong>AWS Lambda<\/strong>: functions scanned for package vulnerabilities (where supported).<\/li>\n<li><strong>Amazon EventBridge<\/strong>: event routing and automation.<\/li>\n<li><strong>AWS Security Hub<\/strong>: aggregation and security posture workflows.<\/li>\n<li><strong>Amazon CloudWatch Logs<\/strong>: for logs of any automation you build (Inspector itself is not a log-heavy service from your perspective; your integrations are).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services (what you often need in real deployments)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM<\/strong>: policies\/roles for enabling, reading findings, and automation actions.<\/li>\n<li><strong>SSM Agent + instance profile<\/strong> for EC2 scanning where required.<\/li>\n<li><strong>KMS<\/strong>: if your integrations write to encrypted destinations (for example, encrypted SNS topics, encrypted S3 exports you create).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM-based access<\/strong>: All actions are controlled by IAM policies.<\/li>\n<li>Common managed policies include Inspector read-only\/full-access variants. Prefer least privilege for automation roles.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Inspector is AWS-managed; you don\u2019t place it in your VPC.<\/li>\n<li>For EC2-related collection, your instances may need to reach <strong>SSM endpoints<\/strong> (public internet or VPC endpoints for Systems Manager) depending on your network design.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Governance<\/strong>: manage enablement via AWS Organizations and infrastructure-as-code.<\/li>\n<li><strong>Monitoring<\/strong>: monitor automation pipelines (EventBridge \u2192 Lambda) with CloudWatch metrics\/logs.<\/li>\n<li><strong>Auditability<\/strong>: use <strong>AWS CloudTrail<\/strong> to record Inspector API calls and changes to configuration (CloudTrail records API activity; verify events in your environment).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (single account)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  A[EC2 Instances] --&gt;|Inventory\/metadata| I[Amazon Inspector]\n  B[ECR Images] --&gt;|Image analysis| I\n  C[Lambda Functions] --&gt;|Package analysis| I\n\n  I --&gt; F[Findings in Inspector Console\/API]\n  I --&gt;|optional| SH[AWS Security Hub]\n  I --&gt;|events| EB[Amazon EventBridge]\n  EB --&gt; L[Automation Lambda \/ Notifications]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (multi-account, centralized security)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[AWS Organizations]\n    subgraph Sec[Security Account (Delegated Admin)]\n      I[Amazon Inspector&lt;br\/&gt;Delegated Admin]\n      SH[AWS Security Hub]\n      EB[Amazon EventBridge]\n      SIEM[External SIEM \/ Ticketing&lt;br\/&gt;(via automation)]\n    end\n\n    subgraph App1[App Account A]\n      EC2A[EC2 Fleet]\n      ECRA[ECR Repos]\n      LAMA[Lambda Apps]\n    end\n\n    subgraph App2[App Account B]\n      EC2B[EC2 Fleet]\n      ECRB[ECR Repos]\n      LAMB[Lambda Apps]\n    end\n  end\n\n  EC2A --&gt; I\n  ECRA --&gt; I\n  LAMA --&gt; I\n  EC2B --&gt; I\n  ECRB --&gt; I\n  LAMB --&gt; I\n\n  I --&gt; SH\n  I --&gt; EB\n  EB --&gt; SIEM\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">AWS account and billing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An <strong>AWS account<\/strong> with billing enabled.<\/li>\n<li>Permissions to create\/modify:<\/li>\n<li>Amazon Inspector configuration<\/li>\n<li>EC2 instances and IAM roles (for the lab)<\/li>\n<li>ECR repositories (optional lab part)<\/li>\n<li>If using multi-account: an <strong>AWS Organizations<\/strong> management account and appropriate org permissions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM permissions<\/h3>\n\n\n\n<p>Minimum recommended for the lab (choose one approach):\n&#8211; <strong>Approach A (fastest)<\/strong>: Use an admin role for the lab, then tighten later.\n&#8211; <strong>Approach B (safer)<\/strong>: Create a lab role with:\n  &#8211; Inspector enable\/list\/get permissions (<code>inspector2:*<\/code> limited to needed actions)\n  &#8211; EC2 create\/terminate, IAM PassRole for EC2 instance profile\n  &#8211; ECR create repo and push permissions (if doing ECR part)\n  &#8211; SSM permissions for managed instances (for EC2 scanning prerequisites)<\/p>\n\n\n\n<p>Managed policy names change over time; verify current AWS managed policies in the IAM console or official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS CLI v2<\/strong> (recommended)<br\/>\n  Install: https:\/\/docs.aws.amazon.com\/cli\/latest\/userguide\/getting-started-install.html<\/li>\n<li><strong>Docker<\/strong> (only if you do the ECR image push steps)<\/li>\n<li>Optional: <code>jq<\/code> for JSON filtering in CLI outputs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Amazon Inspector is <strong>regional<\/strong>. Choose a region where Inspector is available.<\/li>\n<li>Some capabilities (especially Lambda scanning) may be region-dependent\u2014verify in official docs for your region.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service quotas apply (for example, finding\/event throughput, resource coverage). Check:<\/li>\n<li>AWS Service Quotas console<\/li>\n<li>Inspector documentation for any listed limits<br\/>\nIf uncertain, <strong>verify in official docs<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services (for EC2 scanning)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Systems Manager (SSM)<\/strong> connectivity is commonly required for EC2 vulnerability scanning on supported OSes:<\/li>\n<li>SSM Agent installed\/running<\/li>\n<li>Instance profile with <code>AmazonSSMManagedInstanceCore<\/code><\/li>\n<li>Network path to SSM endpoints (public internet or VPC endpoints)<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Official pricing page (start here): https:\/\/aws.amazon.com\/inspector\/pricing\/<br\/>\nAWS Pricing Calculator: https:\/\/calculator.aws\/#\/<\/p>\n\n\n\n<blockquote>\n<p>Pricing changes over time and varies by region and usage patterns. Use the official pricing page and the AWS Pricing Calculator for current rates.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (how you are billed)<\/h3>\n\n\n\n<p>Amazon Inspector pricing is typically based on <strong>what you scan<\/strong> and <strong>how much of it you scan<\/strong>, such as:\n&#8211; <strong>EC2 instance scanning<\/strong>: commonly driven by the number of instances, their size (for example vCPU count), and time scanned. (Verify the exact unit\u2014such as vCPU-hours\u2014in the pricing page for your region.)\n&#8211; <strong>ECR image scanning<\/strong>: commonly driven by the number of container images scanned (and potentially re-scanned as new CVEs are published).\n&#8211; <strong>Lambda scanning<\/strong>: commonly driven by the number of functions and\/or amount of code scanned (verify the exact billing unit in the pricing page).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier \/ trial<\/h3>\n\n\n\n<p>AWS sometimes offers a <strong>free trial<\/strong> for Amazon Inspector for first-time enablement. Availability and duration can change. <strong>Verify in the official pricing page<\/strong> for your account\/region.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Main cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Scale of compute<\/strong>:<\/li>\n<li>Many EC2 instances (especially larger instances) increase scanning cost.<\/li>\n<li>High churn of ECR images (frequent builds) increases scanning cost.<\/li>\n<li>Large numbers of Lambda functions or frequent deployments may increase scanning volume.<\/li>\n<li><strong>Multi-account + multi-region<\/strong>: Enabling in many accounts\/regions multiplies coverage and cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<p>Inspector itself is managed, but your overall solution may include:\n&#8211; <strong>EventBridge + Lambda automation<\/strong> costs (invocations, logs).\n&#8211; <strong>Security Hub<\/strong> charges (if you enable it and ingest findings).\n&#8211; <strong>Data storage<\/strong> costs if you export findings to S3 or a data lake.\n&#8211; <strong>Operational cost<\/strong> of remediation (patching windows, rebuild pipelines).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Inspector is an AWS managed service; you generally don\u2019t pay special data transfer to \u201csend data to Inspector\u201d.<\/li>\n<li>If your automation exports findings cross-region or to the internet (for example to external SIEM), data transfer charges may apply.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost (practical guidance)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Scan only what you need<\/strong>: enable only the resource types you use.<\/li>\n<li><strong>Reduce ECR image churn<\/strong>: clean up unused tags\/images; keep a retention policy.<\/li>\n<li><strong>Use immutable pipelines<\/strong>: rebuild patched images rather than patching containers in place.<\/li>\n<li><strong>Prioritize critical workloads<\/strong> first in large environments (phased rollout).<\/li>\n<li><strong>Use centralized governance<\/strong>: avoid redundant overlapping tooling unless necessary.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (how to think about it)<\/h3>\n\n\n\n<p>A small dev account might include:\n&#8211; 1\u20132 small EC2 instances\n&#8211; A handful of ECR images\n&#8211; Few Lambda functions<\/p>\n\n\n\n<p>Estimate by plugging your <strong>instance sizes<\/strong>, <strong>hours<\/strong>, and <strong>image build volume<\/strong> into the AWS Pricing Calculator and comparing regions. Do not rely on fixed numbers from blogs\u2014rates vary.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, costs often correlate with:\n&#8211; Hundreds\/thousands of EC2 instances across multiple regions\n&#8211; CI\/CD pipelines producing many images per day\n&#8211; Organization-wide enablement across many accounts<\/p>\n\n\n\n<p>For enterprise forecasting:\n&#8211; Start with an <strong>inventory<\/strong> (instances by vCPU, image build count, function count).\n&#8211; Run a <strong>pilot<\/strong> in one region for 2\u20134 weeks, then extrapolate.\n&#8211; Validate assumptions against the pricing page for your region.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Enable Amazon Inspector in a single AWS account and region, scan:\n1) one EC2 instance for vulnerabilities, and<br\/>\n2) one container image pushed to Amazon ECR,<br\/>\nthen view findings and clean up resources to minimize cost.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create an EC2 instance that is managed by AWS Systems Manager (SSM).\n2. Enable Amazon Inspector scanning.\n3. Create an ECR repository and push a test image.\n4. Review Inspector findings in the console and via AWS CLI.\n5. Clean up EC2\/ECR and optionally disable Inspector.<\/p>\n\n\n\n<p><strong>Expected time<\/strong>: 45\u201390 minutes (depends on image push and scan time)<br\/>\n<strong>Cost<\/strong>: Low, but not zero. Use small instances and delete resources afterward. Inspector charges depend on usage\u2014see pricing page.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Choose a region and set up AWS CLI<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Pick a region you will use for the entire lab (example: <code>us-east-1<\/code>). Make sure Amazon Inspector is available in that region.<\/li>\n<li>Configure AWS CLI credentials:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws configure\n# Provide AWS Access Key ID, Secret Access Key, default region, and output format\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: AWS CLI can call AWS APIs in your chosen region.<\/p>\n\n\n\n<p><strong>Verify<\/strong>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws sts get-caller-identity\naws configure get region\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create IAM role for EC2 with SSM managed instance permissions<\/h3>\n\n\n\n<p>Amazon Inspector\u2019s EC2 vulnerability scanning commonly relies on EC2 being a <strong>managed instance in AWS Systems Manager<\/strong> (verify exact prerequisites for your OS in official docs).<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Create an IAM role for EC2 with the managed policy <code>AmazonSSMManagedInstanceCore<\/code>.<\/li>\n<\/ol>\n\n\n\n<p><strong>Console path<\/strong>: IAM \u2192 Roles \u2192 Create role \u2192 AWS service \u2192 EC2 \u2192 Attach permissions \u2192 search and attach:\n&#8211; <code>AmazonSSMManagedInstanceCore<\/code><\/p>\n\n\n\n<p>Name it: <code>LabEC2SSMRole<\/code><\/p>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>Create an instance profile automatically (the console will do this when you create the role).<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>: You have an EC2 role you can attach to an instance so it registers in SSM.<\/p>\n\n\n\n<p><strong>Verify<\/strong> (CLI):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws iam get-role --role-name LabEC2SSMRole\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Launch a small EC2 instance (SSM-managed)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>Launch an EC2 instance:\n   &#8211; AMI: <strong>Amazon Linux 2023<\/strong> or <strong>Amazon Linux 2<\/strong> (choose one supported by your org; OS support can affect findings).\n   &#8211; Instance type: small (for example <code>t3.micro<\/code> if eligible).\n   &#8211; IAM instance profile: <code>LabEC2SSMRole<\/code>\n   &#8211; Network: default VPC is fine for a lab\n   &#8211; Security group: allow no inbound access (recommended). You do not need SSH for this lab.\n   &#8211; Tags: <code>Name=inspector-lab-ec2<\/code>, <code>Env=lab<\/code><\/p>\n<\/li>\n<li>\n<p>Wait until the instance state is <strong>running<\/strong>.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>: Instance is running with SSM permissions.<\/p>\n\n\n\n<p><strong>Verify that the instance is managed by SSM<\/strong>:\n&#8211; Console: Systems Manager \u2192 Fleet Manager \u2192 Managed nodes (or \u201cManaged instances\u201d depending on console experience)\n&#8211; CLI:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ssm describe-instance-information \\\n  --query \"InstanceInformationList[].{InstanceId:InstanceId,PingStatus:PingStatus,PlatformName:PlatformName,AgentVersion:AgentVersion}\" \\\n  --output table\n<\/code><\/pre>\n\n\n\n<p><strong>If the instance does not appear<\/strong>:\n&#8211; Confirm SSM Agent is installed\/running (Amazon Linux typically includes it).\n&#8211; Confirm the instance has outbound network access to SSM endpoints (NAT\/IGW or VPC endpoints).\n&#8211; Confirm the instance profile includes <code>AmazonSSMManagedInstanceCore<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Enable Amazon Inspector<\/h3>\n\n\n\n<p>You can enable via the console or CLI. The CLI typically uses the <code>inspector2<\/code> namespace.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Option A: Enable via Console (recommended for beginners)<\/h4>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open Amazon Inspector console in your chosen region.<\/li>\n<li>Choose <strong>Get started<\/strong> \/ <strong>Enable<\/strong> (wording may vary).<\/li>\n<li>Select resource types to scan:\n   &#8211; <strong>EC2<\/strong>\n   &#8211; <strong>ECR<\/strong>\n   &#8211; (Optional) <strong>Lambda<\/strong> if available\/needed<\/li>\n<li>Confirm enablement.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>: Amazon Inspector starts evaluating supported resources in that region.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Option B: Enable via AWS CLI<\/h4>\n\n\n\n<blockquote>\n<p>CLI arguments can evolve. If a command fails, verify the current CLI syntax in the official AWS CLI reference for <code>inspector2<\/code>.<\/p>\n<\/blockquote>\n\n\n\n<p>Try:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws inspector2 enable --resource-types EC2 ECR\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: The service is enabled for the specified resource types.<\/p>\n\n\n\n<p><strong>Verify<\/strong> (one way is to check coverage statistics or list configured resources; exact commands may vary by version\u2014verify in docs\/CLI help):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws inspector2 list-account-permissions --max-results 10 2&gt;\/dev\/null || true\naws inspector2 get-configuration 2&gt;\/dev\/null || true\naws inspector2 list-coverage --max-results 10 2&gt;\/dev\/null || true\n<\/code><\/pre>\n\n\n\n<p>If these commands are not recognized or return errors, use:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws inspector2 help\n<\/code><\/pre>\n\n\n\n<p>\u2026and consult the current CLI reference.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Wait for EC2 findings and review them<\/h3>\n\n\n\n<p>Amazon Inspector findings may take time to appear after enabling.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>In the Inspector console:\n   &#8211; Go to <strong>Findings<\/strong>\n   &#8211; Filter by:<\/p>\n<ul>\n<li>Resource type: EC2 instance<\/li>\n<li>Resource ID: your instance ID<\/li>\n<\/ul>\n<\/li>\n<li>\n<p>In CLI (example approach):\n   &#8211; First list findings (can be large; consider filtering):<\/p>\n<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws inspector2 list-findings --max-results 25\n<\/code><\/pre>\n\n\n\n<p>To filter for EC2 findings only (filter syntax can be specific\u2014verify filter keys in current docs):<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws inspector2 list-findings \\\n  --filter-criteria '{\"resourceType\":[{\"comparison\":\"EQUALS\",\"value\":\"AWS_EC2_INSTANCE\"}]}' \\\n  --max-results 25\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: You see one or more findings (if the instance has vulnerable packages or exposure conditions detectable by Inspector).<\/p>\n\n\n\n<p><strong>If you see no findings<\/strong>:\n&#8211; The instance might be fully patched.\n&#8211; Wait longer (initial scans can take time).\n&#8211; Try installing a package and delaying patching (safe, non-production). For example, install common packages and then run updates later. Findings depend on actual package versions and vulnerability intelligence.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create an ECR repository and push a test image<\/h3>\n\n\n\n<p>This step helps demonstrate container image findings. You need Docker installed locally.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Create an ECR repository:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws ecr create-repository --repository-name inspector-lab-repo\n<\/code><\/pre>\n\n\n\n<p>Capture the repository URI:<\/p>\n\n\n\n<pre><code class=\"language-bash\">REPO_URI=$(aws ecr describe-repositories \\\n  --repository-names inspector-lab-repo \\\n  --query \"repositories[0].repositoryUri\" \\\n  --output text)\n\necho \"$REPO_URI\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>Authenticate Docker to ECR:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws ecr get-login-password | docker login --username AWS --password-stdin \"$REPO_URI\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>Create a simple Dockerfile that intentionally uses an older base OS (often yields findings). Results vary\u2014this is a demonstration.<\/li>\n<\/ol>\n\n\n\n<p>Create <code>Dockerfile<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-dockerfile\">FROM debian:9\nRUN apt-get update &amp;&amp; apt-get install -y curl ca-certificates &amp;&amp; rm -rf \/var\/lib\/apt\/lists\/*\nCMD [\"bash\",\"-lc\",\"curl --version &amp;&amp; sleep 3600\"]\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"4\">\n<li>Build and tag the image:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">docker build -t inspector-lab:1 .\ndocker tag inspector-lab:1 \"$REPO_URI:1\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"5\">\n<li>Push the image:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">docker push \"$REPO_URI:1\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Image is stored in ECR.<\/p>\n\n\n\n<p><strong>Verify<\/strong>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">aws ecr describe-images --repository-name inspector-lab-repo --output table\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Wait for ECR image findings and review them<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>Inspector console:\n   &#8211; Findings \u2192 filter resource type = ECR image\n   &#8211; Filter by repository name <code>inspector-lab-repo<\/code><\/p>\n<\/li>\n<li>\n<p>CLI (example):\n   &#8211; List findings and filter by resource type for container images (filter keys can vary; verify in docs):<\/p>\n<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws inspector2 list-findings \\\n  --filter-criteria '{\"resourceType\":[{\"comparison\":\"EQUALS\",\"value\":\"AWS_ECR_CONTAINER_IMAGE\"}]}' \\\n  --max-results 25\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Findings associated with the pushed image digest may appear (timing varies).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8 (Optional): Send findings to EventBridge for automation<\/h3>\n\n\n\n<p>Inspector findings can be routed through EventBridge. A simple lab-friendly automation is \u201clog the event\u201d (for example, to CloudWatch Logs via a Lambda). This optional step focuses on the EventBridge rule.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open Amazon EventBridge console \u2192 Rules \u2192 Create rule.<\/li>\n<li>Event source: AWS events (EventBridge pattern)<\/li>\n<li>Pattern: choose service\/provider corresponding to Inspector findings (wording varies).<\/li>\n<li>Target: choose an SNS topic or Lambda function you control.<\/li>\n<\/ol>\n\n\n\n<p>Because event schema and fields can change, <strong>verify the exact EventBridge event pattern<\/strong> for Amazon Inspector in official docs before relying on it in production.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: When new findings appear or change, your target receives events.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Inspector enabled<\/strong> in your region:\n   &#8211; Console shows \u201cEnabled\u201d<\/li>\n<li><strong>EC2 instance is SSM-managed<\/strong>:\n   &#8211; <code>aws ssm describe-instance-information<\/code> shows your instance<\/li>\n<li><strong>Findings visible<\/strong>:\n   &#8211; Inspector console shows findings for EC2 and\/or ECR<\/li>\n<li><strong>ECR image exists<\/strong>:\n   &#8211; <code>aws ecr describe-images<\/code> returns image tags\/digests<\/li>\n<\/ol>\n\n\n\n<p>If you want to validate remediation mechanics (optional):\n&#8211; Patch the EC2 instance (for example via SSM Run Command) and observe that findings reduce over time.\n&#8211; Rebuild the container image using a newer base image and push a new tag\/digest, then compare findings.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: EC2 instance not showing in SSM<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Confirm instance profile has <code>AmazonSSMManagedInstanceCore<\/code>.<\/li>\n<li>Confirm outbound connectivity to SSM endpoints:<\/li>\n<li>If in private subnets, configure <strong>VPC endpoints<\/strong> for Systems Manager (SSM, EC2Messages, SSMMessages) or provide NAT.<\/li>\n<li>Confirm SSM Agent is installed and running.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Inspector enabled but no EC2 findings<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Wait longer\u2014initial evaluations can take time.<\/li>\n<li>Ensure the OS is supported for vulnerability scanning (verify in docs).<\/li>\n<li>Ensure SSM managed node status is \u201cOnline\u201d.<\/li>\n<li>If the instance is fully patched, there may be few\/no findings.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Docker push fails to ECR authentication<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Re-run the <code>get-login-password<\/code> command.<\/li>\n<li>Ensure your IAM principal has ECR permissions (<code>ecr:GetAuthorizationToken<\/code>, <code>ecr:PutImage<\/code>, <code>ecr:InitiateLayerUpload<\/code>, etc.).<\/li>\n<li>Ensure the repository URI is correct for your account\/region.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: No ECR findings<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Wait longer after push; scans are not always instantaneous.<\/li>\n<li>Confirm Inspector is enabled for ECR in the region.<\/li>\n<li>Confirm you pushed to <strong>ECR in the same region<\/strong> where Inspector is enabled.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To minimize cost, clean up immediately after the lab.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Terminate the EC2 instance<\/strong>:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\"># Find instance ID by tag (adjust region\/profile if needed)\nINSTANCE_ID=$(aws ec2 describe-instances \\\n  --filters \"Name=tag:Name,Values=inspector-lab-ec2\" \"Name=instance-state-name,Values=running,stopped\" \\\n  --query \"Reservations[].Instances[].InstanceId\" \\\n  --output text)\n\necho \"$INSTANCE_ID\"\n\naws ec2 terminate-instances --instance-ids \"$INSTANCE_ID\"\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li><strong>Delete ECR images and repository<\/strong>:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\"># List image digests\naws ecr list-images --repository-name inspector-lab-repo --query 'imageIds[*]' --output json\n\n# Batch delete images (safe for lab repo)\naws ecr batch-delete-image --repository-name inspector-lab-repo --image-ids imageTag=1\n\n# Delete repository\naws ecr delete-repository --repository-name inspector-lab-repo\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li><strong>(Optional) Disable Inspector<\/strong> if you don\u2019t want ongoing charges:\n&#8211; Console: Amazon Inspector \u2192 Settings \u2192 Disable (wording varies)\n&#8211; CLI (verify current syntax):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws inspector2 disable --resource-types EC2 ECR\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"4\">\n<li><strong>Delete IAM role<\/strong> <code>LabEC2SSMRole<\/code> if created only for this lab.<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Enable organization-wide<\/strong> using AWS Organizations (delegated admin) for consistent coverage.<\/li>\n<li><strong>Adopt a standard severity policy<\/strong>: define what \u201cCritical\/High\u201d means operationally (SLA, escalation, exceptions).<\/li>\n<li><strong>Use immutable deployments<\/strong>:<\/li>\n<li>For containers: rebuild images from patched bases and redeploy.<\/li>\n<li>For EC2: prefer replacing instances via ASG\/launch templates after patching AMIs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Least privilege<\/strong> for:<\/li>\n<li>Roles that read findings<\/li>\n<li>Automation that remediates<\/li>\n<li>Separate roles:<\/li>\n<li><strong>Viewer<\/strong> role (read-only)<\/li>\n<li><strong>Automation<\/strong> role (limited actions like creating tickets, patching, updating security groups)<\/li>\n<li>Restrict sensitive actions with conditions (for example, tag-based conditions) where feasible.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Phase enablement<\/strong>: start with production accounts and internet-facing workloads.<\/li>\n<li><strong>Reduce ECR bloat<\/strong>: implement lifecycle policies to delete unneeded images.<\/li>\n<li><strong>Right-size EC2<\/strong>: cost scales with fleet size; right-sizing helps security and cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices (operational responsiveness)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>EventBridge<\/strong> to avoid polling the API.<\/li>\n<li>Optimize automation to handle bursty findings (batch, backoff, idempotency).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat remediation automation as production software:<\/li>\n<li>retries<\/li>\n<li>dead-letter queues (DLQs) where applicable<\/li>\n<li>alarms on failures<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Tagging<\/strong>: enforce tags like <code>App<\/code>, <code>Owner<\/code>, <code>Env<\/code>, <code>CostCenter<\/code>.<\/li>\n<li><strong>Triage workflow<\/strong>:\n  1. Confirm exploitability\/exposure (context)\n  2. Patch or rebuild\n  3. Verify closure\n  4. Track exceptions with expiration dates<\/li>\n<li><strong>Change management<\/strong>: schedule patch windows; coordinate with release cycles.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize:<\/li>\n<li>ECR repository naming (team\/app\/env)<\/li>\n<li>EC2 instance tags and ASG naming<\/li>\n<li>Lambda function naming<\/li>\n<li>Use AWS Organizations SCPs (carefully) to enforce minimum security baselines if needed.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>All access is controlled by <strong>IAM<\/strong>.<\/li>\n<li>Use:<\/li>\n<li>IAM roles for humans (SSO\/federation)<\/li>\n<li>IAM roles for automation (EventBridge\/Lambda)<\/li>\n<li>Monitor with <strong>CloudTrail<\/strong> for enable\/disable actions and configuration changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Findings are stored and managed by AWS; for exports\/integrations you build:<\/li>\n<li>Use <strong>SSE-KMS<\/strong> for S3 exports<\/li>\n<li>Encrypt SNS topics and queues with KMS<\/li>\n<li>Verify encryption defaults and options in Inspector docs and related service docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Inspector itself is AWS-managed.<\/li>\n<li>For EC2 scanning prerequisites (SSM connectivity), ensure:<\/li>\n<li>Instances can reach SSM endpoints securely (prefer VPC endpoints in private subnets).<\/li>\n<li>Restrict outbound egress where possible with proxy\/NACL\/security group policy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid embedding credentials in remediation scripts.<\/li>\n<li>Use <strong>AWS Secrets Manager<\/strong> or <strong>SSM Parameter Store<\/strong> for external ticketing tokens and API keys.<\/li>\n<li>Rotate credentials and restrict access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>CloudTrail<\/strong>: records Inspector API usage.<\/li>\n<li><strong>Security Hub<\/strong> (optional): central audit trail of findings across services.<\/li>\n<li>Automation logs: <strong>CloudWatch Logs<\/strong> for Lambdas and pipelines.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Inspector supports vulnerability management, but compliance requires:<\/li>\n<li>documented process<\/li>\n<li>remediation SLAs<\/li>\n<li>exception process<\/li>\n<li>evidence retention<\/li>\n<li>Validate against your framework requirements (PCI, HIPAA, SOC2, etc.).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enabling Inspector but <strong>not assigning ownership<\/strong> \u2192 findings pile up.<\/li>\n<li>Over-permissive automation that patches production without guardrails.<\/li>\n<li>Ignoring <strong>image rebuild discipline<\/strong> (containers) and repeatedly patching running workloads.<\/li>\n<li>Missing multi-region enablement in global architectures.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Centralize in a security account using AWS Organizations.<\/li>\n<li>Route findings to Security Hub and\/or a SIEM for retention and correlation.<\/li>\n<li>Implement automated triage, but keep remediation gated (approvals for production).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Regional enablement<\/strong>: If you forget to enable Inspector in a region where you run workloads, you\u2019ll have blind spots.<\/li>\n<li><strong>Resource coverage depends on prerequisites<\/strong>:<\/li>\n<li>EC2 scanning often depends on supported OS and SSM-managed connectivity\u2014verify the support matrix.<\/li>\n<li><strong>Container scope<\/strong>: Inspector\u2019s container scanning is primarily aligned to <strong>Amazon ECR<\/strong> usage; if your images live elsewhere, plan for additional tooling.<\/li>\n<li><strong>Finding volume<\/strong>: Large fleets produce lots of findings. Without filtering, routing, and ownership, teams get alert fatigue.<\/li>\n<li><strong>Timing<\/strong>: Initial scans and finding updates are not always immediate; plan for delays.<\/li>\n<li><strong>Multi-account complexity<\/strong>: Delegated admin setup is straightforward, but consistent tagging\/ownership across accounts is not\u2014plan governance early.<\/li>\n<li><strong>Cost surprises<\/strong>:<\/li>\n<li>High image build churn in CI\/CD can increase scanning volume.<\/li>\n<li>Enabling across many accounts\/regions multiplies usage.<\/li>\n<li><strong>Remediation verification<\/strong>: A patched system may take time to reflect updated findings; don\u2019t assume instant closure.<\/li>\n<li><strong>Legacy confusion<\/strong>: \u201cInspector Classic\u201d workflows are different; don\u2019t mix run-based classic assessments with the continuous model.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Amazon Inspector is best understood as <strong>AWS-native vulnerability management<\/strong> for certain AWS resource types. It complements (not replaces) threat detection, posture management, and AppSec testing.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Amazon Inspector<\/strong><\/td>\n<td>Continuous vulnerability scanning of EC2\/ECR\/Lambda in AWS<\/td>\n<td>Managed, integrates with AWS Organizations, Security Hub, EventBridge; continuous findings<\/td>\n<td>Not a full SAST\/DAST platform; scope depends on supported resources; region-by-region enablement<\/td>\n<td>You want AWS-native vulnerability management for core AWS workloads<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Security Hub<\/strong><\/td>\n<td>Central aggregation and posture dashboards<\/td>\n<td>Aggregates findings from many AWS services; compliance checks<\/td>\n<td>Not a scanner by itself; relies on producers like Inspector<\/td>\n<td>You need a single pane of glass and standardized workflows<\/td>\n<\/tr>\n<tr>\n<td><strong>Amazon GuardDuty<\/strong><\/td>\n<td>Threat detection based on logs\/telemetry<\/td>\n<td>Detects malicious activity patterns; strong signal for active threats<\/td>\n<td>Not focused on known CVEs\/package vulnerabilities<\/td>\n<td>You need threat detection and continuous monitoring<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Systems Manager Patch Manager<\/strong><\/td>\n<td>Patch orchestration for EC2<\/td>\n<td>Automates patching workflows and maintenance windows<\/td>\n<td>Doesn\u2019t inherently discover all vulnerability context; patching \u2260 vulnerability prioritization<\/td>\n<td>You need to execute patching at scale (often used with Inspector)<\/td>\n<\/tr>\n<tr>\n<td><strong>ECR basic scanning (if enabled separately)<\/strong><\/td>\n<td>Lightweight image scanning<\/td>\n<td>Simple, integrated<\/td>\n<td>May be less comprehensive than Inspector-based scanning; verify current capabilities<\/td>\n<td>Very small environments or early-stage scanning needs<\/td>\n<\/tr>\n<tr>\n<td><strong>Microsoft Defender for Cloud<\/strong> (other cloud)<\/td>\n<td>Multi-cloud security posture + some vuln capabilities<\/td>\n<td>Broad coverage across clouds<\/td>\n<td>Integration and depth vary; may not map perfectly to AWS resources<\/td>\n<td>You\u2019re standardizing multi-cloud security tooling<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Security Command Center \/ container scanning<\/strong> (other cloud)<\/td>\n<td>GCP-centric security<\/td>\n<td>Strong GCP integration<\/td>\n<td>Not AWS-native<\/td>\n<td>Workloads are primarily on GCP<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed OpenVAS\/Trivy\/Clair<\/strong> (open-source)<\/td>\n<td>Custom scanning pipelines<\/td>\n<td>Flexible; can run anywhere<\/td>\n<td>You manage infrastructure, updates, scaling, false positives<\/td>\n<td>You need portability, custom rules, or non-AWS registry coverage<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example (multi-account, regulated)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A regulated enterprise runs 200+ AWS accounts. Auditors require continuous vulnerability management with evidence of remediation SLAs.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>AWS Organizations with a dedicated <strong>Security tooling account<\/strong><\/li>\n<li>Amazon Inspector enabled org-wide (delegated admin)<\/li>\n<li>Findings forwarded to <strong>AWS Security Hub<\/strong><\/li>\n<li>EventBridge rules route critical findings to:<ul>\n<li>ticketing integration (Lambda)<\/li>\n<li>notification channels (SNS)<\/li>\n<\/ul>\n<\/li>\n<li>Patch and rebuild:<ul>\n<li>EC2 patched via Systems Manager maintenance windows<\/li>\n<li>Containers rebuilt via CI\/CD with updated base images<\/li>\n<\/ul>\n<\/li>\n<li><strong>Why Inspector was chosen<\/strong>:<\/li>\n<li>AWS-native continuous scanning and org-level governance<\/li>\n<li>Tight integration with Security Hub and AWS automation<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Reduced mean time to detect (MTTD) vulnerabilities<\/li>\n<li>Standardized reporting for audits<\/li>\n<li>Clear ownership routing and SLA tracking<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example (single account, container-first)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A small team ships weekly. They use ECS with images in ECR and want vulnerability visibility without running scanners.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>Enable Amazon Inspector for ECR in one region<\/li>\n<li>EventBridge \u2192 Slack notifications (via Lambda) for critical findings in production repositories<\/li>\n<li>CI\/CD gate: block deployment if the target image digest has critical findings (custom script querying Inspector API)<\/li>\n<li><strong>Why Inspector was chosen<\/strong>:<\/li>\n<li>Minimal operational overhead<\/li>\n<li>Native to ECR, fits existing AWS workflow<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Faster feedback loop on base image issues<\/li>\n<li>Fewer vulnerable images promoted to production<\/li>\n<li>Lightweight governance without extra infrastructure<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Is Amazon Inspector the same as Amazon Inspector Classic?<\/strong><br\/>\n   No. Amazon Inspector (current) is designed for continuous vulnerability scanning of supported AWS resources. Inspector Classic is the older run-based assessment product. Prefer the current Amazon Inspector for new deployments.<\/p>\n<\/li>\n<li>\n<p><strong>Is Amazon Inspector global or regional?<\/strong><br\/>\n   It is <strong>regional<\/strong>. Enable and manage it per AWS Region, and plan for multi-region enablement if your workloads span regions.<\/p>\n<\/li>\n<li>\n<p><strong>What resource types can Amazon Inspector scan?<\/strong><br\/>\n   Commonly: <strong>EC2 instances<\/strong>, <strong>ECR container images<\/strong>, and <strong>Lambda functions<\/strong>. Exact coverage and prerequisites vary\u2014verify in official docs for your region.<\/p>\n<\/li>\n<li>\n<p><strong>Does Inspector require an agent on EC2?<\/strong><br\/>\n   The current Inspector commonly relies on AWS-managed mechanisms and often works with <strong>SSM-managed instances<\/strong> rather than a dedicated legacy agent. Confirm the latest requirements and supported OS list in official docs.<\/p>\n<\/li>\n<li>\n<p><strong>How long does it take for findings to appear after enabling?<\/strong><br\/>\n   It varies. Initial discovery and scanning can take minutes to hours depending on resource type and environment conditions.<\/p>\n<\/li>\n<li>\n<p><strong>Can I enable Inspector across all accounts at once?<\/strong><br\/>\n   Yes, using <strong>AWS Organizations<\/strong> with a delegated administrator model (recommended for production).<\/p>\n<\/li>\n<li>\n<p><strong>How do I route findings to my SIEM?<\/strong><br\/>\n   Typical pattern: Inspector \u2192 Security Hub (optional) and\/or Inspector \u2192 EventBridge \u2192 Lambda\/Kinesis\/partner integration \u2192 SIEM. Exact implementation depends on your SIEM.<\/p>\n<\/li>\n<li>\n<p><strong>Does Inspector block deployments automatically?<\/strong><br\/>\n   Not by default. You implement deployment gates in CI\/CD by querying Inspector findings (or consuming them via Security Hub) and enforcing your policy.<\/p>\n<\/li>\n<li>\n<p><strong>Does Inspector scan images in Docker Hub or other registries?<\/strong><br\/>\n   Inspector\u2019s strongest container integration is with <strong>Amazon ECR<\/strong>. For other registries, use additional tooling or mirror images into ECR (validate policy and licensing).<\/p>\n<\/li>\n<li>\n<p><strong>How should I prioritize vulnerabilities from Inspector?<\/strong><br\/>\n   Use severity, exploitability context (where provided), resource exposure, asset criticality, and environment (prod vs dev). Tie this to SLAs and ownership.<\/p>\n<\/li>\n<li>\n<p><strong>Can Inspector generate false positives?<\/strong><br\/>\n   Any vulnerability tool can. Validate critical findings and maintain an exception workflow with expiration and review.<\/p>\n<\/li>\n<li>\n<p><strong>What\u2019s the difference between Inspector and GuardDuty?<\/strong><br\/>\n   Inspector focuses on <strong>known vulnerabilities<\/strong> and exposure. GuardDuty focuses on <strong>threat detection<\/strong> using logs\/telemetry and anomaly detection.<\/p>\n<\/li>\n<li>\n<p><strong>Do I need Security Hub to use Inspector?<\/strong><br\/>\n   No. Inspector can be used standalone, but Security Hub is helpful for aggregation and workflows.<\/p>\n<\/li>\n<li>\n<p><strong>How do I reduce Inspector costs?<\/strong><br\/>\n   Limit scanning to needed resource types\/regions, reduce ECR image churn, clean up unused images, and roll out in phases.<\/p>\n<\/li>\n<li>\n<p><strong>How do I prove remediation to auditors?<\/strong><br\/>\n   Combine Inspector findings history (timestamps\/status), ticketing evidence, patch logs (SSM), and change management records. Inspector is one input to the evidence package.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Amazon Inspector<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official Documentation<\/td>\n<td>Amazon Inspector User Guide<\/td>\n<td>Primary source for features, prerequisites, and workflows: https:\/\/docs.aws.amazon.com\/inspector\/latest\/user\/<\/td>\n<\/tr>\n<tr>\n<td>Official \u201cWhat is\u201d page<\/td>\n<td>What is Amazon Inspector?<\/td>\n<td>Clear scope and concepts: https:\/\/docs.aws.amazon.com\/inspector\/latest\/user\/what-is-inspector.html<\/td>\n<\/tr>\n<tr>\n<td>Official Pricing<\/td>\n<td>Amazon Inspector Pricing<\/td>\n<td>Current pricing dimensions and region notes: https:\/\/aws.amazon.com\/inspector\/pricing\/<\/td>\n<\/tr>\n<tr>\n<td>Pricing Tool<\/td>\n<td>AWS Pricing Calculator<\/td>\n<td>Build estimates for your fleet: https:\/\/calculator.aws\/#\/<\/td>\n<\/tr>\n<tr>\n<td>API\/CLI Reference<\/td>\n<td>AWS CLI Command Reference (<code>inspector2<\/code>)<\/td>\n<td>Exact CLI syntax and filters (verify your CLI version): https:\/\/docs.aws.amazon.com\/cli\/latest\/reference\/inspector2\/<\/td>\n<\/tr>\n<tr>\n<td>Architecture Guidance<\/td>\n<td>AWS Security Reference Architecture (SRA)<\/td>\n<td>Patterns for multi-account security tooling (Inspector often used with Security Hub): https:\/\/docs.aws.amazon.com\/prescriptive-guidance\/latest\/security-reference-architecture\/<\/td>\n<\/tr>\n<tr>\n<td>Eventing<\/td>\n<td>Amazon EventBridge Documentation<\/td>\n<td>For routing findings to automation: https:\/\/docs.aws.amazon.com\/eventbridge\/latest\/userguide\/what-is-amazon-eventbridge.html<\/td>\n<\/tr>\n<tr>\n<td>Centralization<\/td>\n<td>AWS Security Hub Documentation<\/td>\n<td>Aggregating Inspector findings: https:\/\/docs.aws.amazon.com\/securityhub\/latest\/userguide\/what-is-securityhub.html<\/td>\n<\/tr>\n<tr>\n<td>Fleet Ops<\/td>\n<td>AWS Systems Manager Documentation<\/td>\n<td>Managed instances and patching workflows: https:\/\/docs.aws.amazon.com\/systems-manager\/latest\/userguide\/<\/td>\n<\/tr>\n<tr>\n<td>Videos<\/td>\n<td>AWS YouTube Channel<\/td>\n<td>Search for \u201cAmazon Inspector\u201d for demos and updates: https:\/\/www.youtube.com\/@amazonwebservices<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>Exactly the following institutes are listed as training resources. Verify offerings, schedules, and delivery modes on their websites.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams, cloud engineers<\/td>\n<td>DevOps + AWS operations\/security fundamentals, hands-on labs<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>Software configuration management, DevOps foundations, tooling<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations teams, administrators<\/td>\n<td>Cloud ops practices, monitoring, operational readiness<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, reliability-focused engineers<\/td>\n<td>SRE practices, operational excellence, reliability engineering<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams adopting automation<\/td>\n<td>AIOps concepts, automation-driven operations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>The following sites are listed as training resources\/platforms. Validate specific Amazon Inspector coverage and credentials directly on each site.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content<\/td>\n<td>Engineers wanting guided learning paths<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps tools and cloud coaching<\/td>\n<td>Beginners to intermediate DevOps engineers<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps guidance\/services<\/td>\n<td>Teams needing short-term mentoring or implementation help<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and learning<\/td>\n<td>Ops\/DevOps teams needing troubleshooting support<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>Exactly the following consulting companies are listed. Descriptions are generic and should be validated through direct engagement.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting<\/td>\n<td>AWS security foundations, automation, platform engineering<\/td>\n<td>Organization-wide Inspector enablement, EventBridge automation, Security Hub aggregation<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud consulting\/training<\/td>\n<td>Cloud migration support, DevSecOps pipelines<\/td>\n<td>Integrate Inspector findings into CI\/CD, build remediation workflows<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting<\/td>\n<td>Operational maturity, tooling integration<\/td>\n<td>Design multi-account governance, implement alerting and ticketing for Inspector findings<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Amazon Inspector<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS fundamentals<\/strong>: IAM, VPC, EC2, ECR, Lambda<\/li>\n<li><strong>Security basics<\/strong>:<\/li>\n<li>CVEs, CVSS, patch management<\/li>\n<li>principle of least privilege<\/li>\n<li><strong>Operations basics<\/strong>:<\/li>\n<li>CloudTrail basics<\/li>\n<li>tagging strategies<\/li>\n<li><strong>Systems Manager (recommended)<\/strong>:<\/li>\n<li>managed instances, Run Command, patching concepts<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Amazon Inspector<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Security Hub<\/strong> for aggregation and security operations workflows<\/li>\n<li><strong>Amazon EventBridge<\/strong> + <strong>AWS Lambda<\/strong> for automation<\/li>\n<li><strong>Amazon GuardDuty<\/strong> for threat detection correlation<\/li>\n<li><strong>CI\/CD security<\/strong>:<\/li>\n<li>container build hardening<\/li>\n<li>SBOM concepts (tooling outside Inspector may be needed)<\/li>\n<li><strong>Enterprise governance<\/strong>:<\/li>\n<li>AWS Organizations, SCPs, centralized logging<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Security Engineer<\/li>\n<li>Vulnerability Management Engineer<\/li>\n<li>DevSecOps Engineer<\/li>\n<li>Platform Engineer \/ SRE<\/li>\n<li>Cloud Architect (security-focused)<\/li>\n<li>Security Operations Engineer<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (AWS)<\/h3>\n\n\n\n<p>Amazon Inspector is commonly encountered as part of broader AWS security knowledge. Consider:\n&#8211; <strong>AWS Certified Security \u2013 Specialty<\/strong> (if available in your region and current AWS certification catalog; verify on AWS Training &amp; Certification)\n&#8211; Associate-level certs (Solutions Architect \/ SysOps) for foundational AWS knowledge<\/p>\n\n\n\n<p>AWS Training &amp; Certification: https:\/\/aws.amazon.com\/training\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Org-wide enablement<\/strong>: Enable Inspector in a multi-account org and create a central reporting account.<\/li>\n<li><strong>CI\/CD gate<\/strong>: Block container deploys if the target ECR image digest has critical findings.<\/li>\n<li><strong>Auto-ticketing<\/strong>: EventBridge rule \u2192 Lambda \u2192 create tickets with ownership from tags.<\/li>\n<li><strong>Patch verification pipeline<\/strong>: After patching, verify closure by querying Inspector findings and producing a report.<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Amazon Inspector<\/strong>: AWS managed service for continuous vulnerability management of supported AWS resources.<\/li>\n<li><strong>Inspector Classic<\/strong>: Legacy assessment-run version of Inspector with different workflows.<\/li>\n<li><strong>Finding<\/strong>: A reported security issue (for example, a vulnerability) tied to a specific resource.<\/li>\n<li><strong>CVE<\/strong>: Common Vulnerabilities and Exposures identifier for publicly known vulnerabilities.<\/li>\n<li><strong>CVSS<\/strong>: Common Vulnerability Scoring System used to score severity.<\/li>\n<li><strong>ECR<\/strong>: Amazon Elastic Container Registry, AWS container image registry.<\/li>\n<li><strong>Image digest<\/strong>: Immutable identifier for a specific container image content.<\/li>\n<li><strong>SSM (AWS Systems Manager)<\/strong>: AWS service for fleet management; commonly used for managed node connectivity.<\/li>\n<li><strong>Managed node\/instance<\/strong>: An EC2 instance registered and reachable via Systems Manager.<\/li>\n<li><strong>EventBridge<\/strong>: AWS event bus for routing events to targets for automation.<\/li>\n<li><strong>Security Hub<\/strong>: AWS service for aggregating and managing security findings across AWS accounts\/services.<\/li>\n<li><strong>Delegated administrator<\/strong>: An AWS Organizations feature enabling a member account to administer a service for the organization.<\/li>\n<li><strong>Immutable infrastructure<\/strong>: Replacing servers\/images rather than patching in place; common for secure operations.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Amazon Inspector is an AWS <strong>Security, identity, and compliance<\/strong> service for <strong>continuous vulnerability management<\/strong> across supported AWS workload types (commonly EC2, ECR, and Lambda). It matters because vulnerability discovery and prioritization are ongoing problems\u2014new CVEs appear constantly, and fleets drift over time.<\/p>\n\n\n\n<p>Architecturally, Inspector fits best when you:\n&#8211; run AWS-native workloads,\n&#8211; want centralized findings (often via AWS Organizations and Security Hub),\n&#8211; and want automation through EventBridge.<\/p>\n\n\n\n<p>From a cost perspective, the main drivers are the amount of compute and artifacts you scan (instances by size\/time, number of images, and function scan volume). Avoid surprises by scoping enablement, managing ECR lifecycle, and piloting in one region before scaling.<\/p>\n\n\n\n<p>If your goal is practical next steps: enable Inspector in one region, validate EC2 and ECR coverage, route critical findings to a ticketing workflow, and then expand organization-wide with delegated admin once your remediation process is ready.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Security, identity, and compliance<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,39],"tags":[],"class_list":["post-330","post","type-post","status-publish","format-standard","hentry","category-aws","category-security-identity-and-compliance"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/330","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=330"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/330\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=330"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=330"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=330"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}