Amazon Inspector organization architecture SOC 2 is how a multi-account estate keeps one vulnerability scan, and how the client shows an auditor that the scan was on. Amazon Inspector discovers EC2 instances, ECR images, and Lambda functions, then keeps scanning them. Findings land in the delegated administrator account. The SOC 2 report, if there is one, is the client's. Rutagon does not hold that report. We wire the organization so the client's sample has coverage, findings, and a suppression reason.
New accounts that join with scanning off, or with a different scan type, are the ones an auditor's sample hits. Vulnerability management evidence is the control the finding has to support. This article is the org shape that produces the finding.
Amazon Inspector organization architecture SOC 2 in one admin
The delegated administrator documentation is the ownership line. Only the AWS Organizations management account can designate the administrator, and the organization needs all features activated. There is one delegated administrator. Designate that account in every Region where you run Inspector. The same account has to be the administrator in all of those Regions. Inspector is Regional. A designation in one Region does not cover another.
The delegated administrator can manage up to 10,000 member accounts. Past that, you get a notice in the CloudWatch Personal Health Dashboard and an email to the administrator account. Organization policies can enable Inspector for organizations of more than 10,000 accounts, up to 50,000, and the policy still applies to all of them. The console association stops at 10,000. The administrator can view findings and account status for those 10,000. We treat 10,000 as a real ceiling on what the admin console can show, and we say so before someone assumes one pane covers a larger org.
Organization policies take precedence over the administrator's scan settings. If a policy enables Inspector, the policy decides which scan types are on. AWS recommends designating the administrator before you create those policies, so the governance line exists first. Removing the administrator does not turn Inspector off for members. Those accounts become standalone, and their scan settings stay as they were. A "cleanup" that only unregisters the admin leaves the scanners running and splits the findings.
The first time you activate Inspector, AWS creates the service-linked role AWSServiceRoleForAmazonInspector in that account. Designating the administrator turns all scan types on for the administrator account by default. The management account is separate. The administrator has to activate it and choose scan types. We see estates where every member is scanned and the management account, which still holds a bastion or a pipeline, is dark. The activation step for that account is part of the build.
admin: one account id, designated in every Region you scan
members_in_console: up to 10,000
org_policy: decides scan types when a policy is in use
management_account: activate it from the admin, scan types chosen on purpose
evidence: coverage export, open findings, suppression rule text
report: the client's SOC 2, not Rutagon'sThe Inspector overview describes what the scan produces. Inspector discovers eligible resources and scans them without a schedule you maintain. It rescans when a package is installed, when a patch lands, and when a CVE that affects the resource is published. A finding is the report of a software vulnerability or an unintended network exposure. If you remediate it, Inspector detects that and closes the finding. You can filter findings, hide noise with suppression rules, and export CSV or JSON. Findings also go to EventBridge. If Security Hub CSPM is on, Inspector publishes findings there too.
The Inspector score is a CVSS-shaped adjustment of the NVD base score for your environment. The overview gives the example: a vulnerability that is exploitable over the network can score lower on an EC2 instance that has no open path from the internet. The score is useful. The evidence is still the finding, the resource, and the path. We do not let a lowered score delete the row from the export the auditor asked for.
What the client keeps for the sample
The auditor samples the client's system. They ask which workloads were in scope, whether they were scanned through the period, what was found, what was fixed, and what was accepted. Inspector can answer the scanning half if the organization is actually enrolled. A screenshot of one account's console does not answer it. The coverage list from the delegated administrator does: account id, scan types on, resources scanned, resources that failed to scan.
Suppression rules are part of the sample, not a way around it. A rule that hides a finding still needs a reason the client will say out loud: the instance is isolated, the package is not loaded, the exposure is a known admin path. We store that reason next to the rule. A suppression with an empty description is a finding the client will have to explain from memory. GuardDuty and Security Hub aggregation is the neighboring pipe. Inspector findings that already flow to Security Hub can sit in the same export rhythm. We do not build a second tracker that copies the finding into a spreadsheet and then drifts.
EventBridge is how a ticket gets opened without a person refreshing the console. The target can be a queue or a function the client already runs. We keep the ticket's id on the way back only when the client wants a closed loop. The SOC 2 sample needs the finding and the disposition. It does not need a new product. Rutagon does not replace the GRC tool the client already uses to hold the report, the policy, and the exception log. We make Inspector the place the vulnerability evidence comes from, and we leave the system of record for the audit where the client put it.
Regions are part of coverage. A workload in a second Region with no delegated administrator is a gap the console in the first Region will not show. We list Regions from the accounts, not from the Region we happened to open. The same administrator account id in each Region keeps the sample to one owner. Two administrator accounts, one per Region, will not match the rule that a single account is the administrator everywhere.
The 10,000 member cap is an architecture limit, not a rounding error. Above it, organization policy can still turn scanning on, and the admin console will not show every account. We say that in the evidence note so nobody exports 10,000 rows and calls it the org. Under it, the export from the administrator is the list we hand the client for the sample period.
What we turn on, and what we leave standalone
The build is small. Management account designates the administrator. The administrator activates members, including the management account, with the scan types the policy agrees with. New accounts get enabled as they join, which the overview describes as something you can automate. We put that enrollment in the same template as account vending, so a new account does not wait for a ticket. Suppression rules get a description. A monthly export of coverage and open findings goes to the bucket the client already uses for audit evidence.
We leave Inspector off for an account that is truly empty and out of scope, and we write the scope decision down. An account with one forgotten EC2 instance is in scope the moment that instance exists. Scan types follow the resources. EC2, ECR, and Lambda are different switches. An account that ships containers and has only the EC2 scan on will show a clean EC2 page and an unscanned registry. We match the switch to the resource before we call the account covered.
Rutagon runs this as an architecture diagnostic. We name the administrator account, the Regions, the member count against 10,000, the scan types, and the export the client will keep. The client's auditor uses that export. We do not issue the SOC 2 report, and we do not hold one for Rutagon. The delegated-admin page is the source for the single Regional administrator and the 10,000 member view. The overview is the source for what gets scanned and how a finding closes.
Frequently Asked Questions
Who holds the SOC 2 report in this architecture?
The client holds the report. Amazon Inspector organization architecture SOC 2 is the scan and the evidence trail inside the client's accounts, which Rutagon designs and builds. We do not attest, and we do not claim a SOC 2 report of our own. The auditor samples the client's coverage export, findings, and suppression reasons.
Why is the delegated administrator Regional?
Inspector is a Regional service. You designate the administrator in each Region you use, and the same account has to be the administrator in all of them. A designation in one Region leaves the others unmanaged. Only the Organizations management account can make the designation, and the organization needs all features on.
What happens at 10,000 member accounts?
The delegated administrator can manage up to 10,000 members, which is the set whose findings and status the console can show. Organization policies can still enable Inspector for larger organizations, up to 50,000 accounts, and the policy applies to all of them. The admin view does not grow past 10,000 on its own. The evidence note should say which accounts the export includes.
Does removing the administrator stop the scans?
Member accounts become standalone and their scan settings stay. Findings stop aggregating to the old administrator. Turning scanning off is a separate change on the members. Unregistering the admin leaves the scanners running.
Do suppression rules hide a finding from the auditor?
They hide it from the default views, and the rule is still configuration the client has to explain. We export the rule text with the coverage list. A lowered Inspector score, such as a network CVE with no open path, changes the severity you see and leaves the finding in an export you asked for.
Ask for an architecture diagnostic of the Inspector administrator, the Regions, and the evidence export. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.