Four Findings and Four Different Services

The situation

A health-tech company runs a patient-appointment platform across three AWS accounts: production, staging, and a data account holding an analytics warehouse. Roughly 40 EC2 instances, a dozen container images in Amazon ECR, 60 S3 buckets, and an RDS cluster.

A new security lead arrives and writes four questions on a whiteboard.

1. Is anything malicious happening in these accounts right now? An instance mining cryptocurrency, credentials being used from an unusual location, a host talking to a known command-and-control address.
2. Do the running instances and the container images carry known vulnerabilities, with CVE numbers attached?
3. Is patient data sitting in an S3 bucket where it should not be? Sixty buckets accumulated over four years and nobody can say what is in all of them.
4. Are the accounts drifting away from the standard the company told its auditor it follows, and where is the one screen that shows it?

There is a fifth question underneath: when something does happen, how does anyone reconstruct what led to it?

What actually matters

The useful way to separate these services is by what each one reads. Nearly every mix-up on this ground comes from treating them as interchangeable security products rather than as tools pointed at different data. One reads the account’s activity logs, one reads the software inventory on a host, one reads the contents of objects, and one reads the findings the others produce. Once the input is clear, the boundaries stop blurring.

The second thing to settle is detection versus prevention, because a scenario usually turns on one or the other. A service that reports that something has happened does not stop it happening; a service that filters a request before it reaches an application does not tell you about activity elsewhere in the account. Both belong in the estate, and confusing them puts a good service on the wrong job.

Third, deployment effort separates the options more than the marketing does. Some of these services read logs AWS already produces and need nothing installed; others need an agent on a host, or need a scan scheduled, or need Config turned on first. In an estate of three accounts with no dedicated security team, “enable it and it works” is a real property rather than a nice one.

Finally, aggregation is its own requirement rather than a bonus. Four services producing findings in three accounts is twelve places to look. The fourth question on the whiteboard is not a fifth detection problem; it is asking for one screen, mapped to a named standard, that the auditor can be shown. That is a different job from any of the detection services and it needs its own answer.

What we’ll filter on

1. What the service reads: activity logs, host software inventory, object contents, resource configuration, or other services’ findings.
2. Detects after the fact, or prevents at request time.
3. What has to be deployed: an agent, a prerequisite service, or nothing.
4. Whether it works across several accounts from one place.
5. Whether it maps findings to a named compliance standard.

The landscape

Amazon GuardDuty reads three foundational sources: CloudTrail management events, VPC Flow Logs, and Route 53 Resolver DNS query logs. It applies threat intelligence and machine learning to them. It finds cryptocurrency mining, credential use from an anomalous location, communication with known malicious addresses, and unusual API behaviour. Optional protection plans widen the input rather than change the method. S3 Protection adds CloudTrail S3 data events, RDS Protection adds database login activity, Malware Protection for EC2 scans EBS volumes. Extended Threat Detection, on automatically at no extra charge, correlates findings into attack sequences. Nothing is installed for any of that except Runtime Monitoring, which uses an agent. Enabling GuardDuty does not require CloudTrail, flow logs or DNS query logging to be set up separately for its own use. It reports; it does not block.

Amazon Inspector reads the software inventory of a workload and compares it to vulnerability databases. It scans EC2 instances, container images in Amazon ECR, and Lambda functions, producing findings with CVE identifiers attached. EC2 scanning comes in two methods, and hybrid mode runs both: the Systems Manager agent where the instance is SSM-managed, EBS snapshots where it is not. ECR images are scanned on push. For EC2 package findings, Inspector also publishes a score that adjusts the CVSS base score using network reachability and exploitability data from the environment. Inspector is where to look whenever a scenario names patch levels or CVEs.

Amazon Macie reads the contents of S3 objects. It uses machine learning and pattern matching to discover and classify sensitive data: names, addresses, health identifiers, card numbers, credentials. It also keeps an inventory of the account’s S3 general purpose buckets and evaluates each one for security and access control, so it reports which buckets are public, unencrypted, or shared outside the account. It is the only service here that opens the objects.

AWS Security Hub CSPM reads the findings of the others. The name moved in December 2025. What was AWS Security Hub became Security Hub CSPM, and a second service, now called AWS Security Hub, went generally available alongside it to correlate findings into prioritised exposures. The posture and standards work belongs to the CSPM service. It ingests from GuardDuty, Inspector, Macie, other AWS services and partner products, normalises them into the AWS Security Finding Format, and runs automated checks against standards including the AWS Foundational Security Best Practices, CIS AWS Foundations Benchmark, PCI DSS and NIST. A delegated administrator account covers the whole organisation. Most controls run as service-linked AWS Config rules, so resource recording has to be on.

AWS Config reads resource configuration. It records what every resource looks like, keeps the history, and evaluates rules that say what a compliant configuration is. It answers “what changed and when” and “which resources are non-compliant”, and it can remediate automatically. It is a prerequisite for much of what Security Hub CSPM reports.

Amazon Detective reads CloudTrail management events and VPC flow logs, ingests GuardDuty findings, and builds a linked behaviour graph across them holding up to a year of history. It exists for the question after an alert: what else did that principal touch, when did this start, what is the normal baseline for that instance. It investigates rather than detects.

AWS CloudTrail records the API calls themselves: who, what, when, from where. It is the underlying record every investigation returns to, and the source GuardDuty and Detective read.

AWS WAF and AWS Shield sit in front of an application and act at request time. WAF filters HTTP requests by rule: injection patterns, rate limits, geography. Shield Standard protects against network and transport layer DDoS automatically at no extra charge. Shield Advanced adds application-layer protection through AWS WAF, access to the Shield Response Team, which needs a Business or Enterprise Support plan of its own, and service credits for attack-driven cost spikes. These prevent rather than detect, and neither answers any of the four questions on the whiteboard.

AWS Trusted Advisor checks the account against best practice across six categories: cost optimisation, performance, security, fault tolerance, service limits and operational excellence. Its security checks are broad and shallow by design: unrestricted ports on security groups, S3 bucket permissions, MFA on the root user, public EBS and RDS snapshots, exposed access keys. It is a health check rather than a detection service. A Basic Support account sees every service-limit check and a handful of the security ones. The full set needs a paid support plan, which now means Business Support+, Enterprise Support or Unified Operations.

Evaluation

Side by side

Service	What it reads	Detect or prevent	Agent or prerequisite	Multi-account	Maps to a standard
Amazon GuardDuty	CloudTrail management events, VPC Flow Logs, DNS logs	Detect	None	✓	✗
Amazon Inspector	Host and image software inventory	Detect	SSM agent or EBS snapshot	✓	✗
Amazon Macie	S3 object contents	Detect	None	✓	✗
AWS Security Hub CSPM	Other services’ findings	Detect	Config recording for most controls	✓	✓
AWS Config	Resource configuration	Detect	Must be enabled per Region	✓	✓
Amazon Detective	CloudTrail and flow logs, as a graph	Investigate	None	✓	✗
AWS CloudTrail	API calls	Record	90-day Event history with no setup	✓	✗
AWS WAF / Shield	HTTP requests in flight	Prevent	Attach to the front door	Via Firewall Manager	✗
AWS Trusted Advisor	Account configuration, broadly	Detect	Paid support plan for all checks	Via Organizations	✗

No row answers more than one of the four questions, which is the answer to the whiteboard: four questions, four services, and a fifth to aggregate them.

Matching the question to the service

The solution

Enable GuardDuty across all three accounts, from the organisation’s delegated administrator, with auto-enable set for accounts added later. That designation is per-Region, and it has to be the same account in every Region. GuardDuty needs nothing installed and starts producing findings from logs that already exist, which makes it the first thing to turn on. A first-time activation switches on every protection plan except Runtime Monitoring, so the work here is confirming the ones that matter rather than adding them: S3 Protection for the data account, Malware Protection for EC2, and RDS Protection for the cluster.

Turn on Inspector next, with EC2 and ECR scanning, then check the account’s EC2 scan mode. In hybrid mode the SSM-managed instances are scanned continuously through the agent, and the unmanaged ones are scanned from EBS snapshots every 24 hours. In agent-based mode an instance without a managed agent is not scanned at all. Either way, knowing which of the 40 are SSM-managed tells you what coverage you have. ECR scanning triggers on push, so the twelve images start reporting as soon as the pipeline next runs. The Inspector score for an EC2 finding factors in whether the vulnerable component is reachable from the network, which turns a list of several thousand CVEs into a shortlist somebody can work through.

Point Macie at the S3 estate, and run a discovery job over the 60 buckets. It answers the question nobody can answer by hand, and it answers it as a classification rather than a guess: which buckets hold personal or health data, how much, and which of those buckets are public, unencrypted or shared outside the account. That last part matters as much as the classification, because the risk is the combination of sensitive contents and an over-permissive bucket.

Enable Security Hub CSPM with the organisation’s delegated administrator. It consumes the findings from GuardDuty, Inspector and Macie, normalises them, and runs the standards checks. Most of those checks read AWS Config, and how Config gets there depends on what else is enabled. With Security Hub turned on alongside CSPM, CSPM creates and manages its own service-linked configuration recorder in each account and Region. With CSPM on its own, AWS Config has to be enabled by hand, with resource recording on, in every Region where CSPM runs and in every member account. Then enable the AWS Foundational Security Best Practices standard plus whichever named standard the auditor was told about. That produces the one screen the fourth question asked for, mapped to control identifiers rather than a pile of alerts.

Add Detective for the fifth, unwritten question. It collects CloudTrail management events and VPC flow logs itself and links them to GuardDuty findings. When a finding appears, it shows what else that principal did, when the behaviour started, and what normal looked like before it. Investigating without it means reading CloudTrail by hand, which is possible and slow.

Two things worth confirming rather than assuming. CloudTrail keeps the last 90 days of management events in Event history with no setup at all. A trail that stores them durably, in an S3 bucket in a separate account with object lock, is what survives an incident in which the attacker has permissions in the account being investigated. And Trusted Advisor’s security checks are worth reading on day one for the obvious exposures, since S3 bucket permissions, MFA on the root user and unrestricted ports are among the handful available without a paid support plan.

Nothing here stops an attack in flight. If the appointment platform is internet-facing, WAF in front of it filters injection attempts and abusive request rates before they reach the application, and Shield Standard is already protecting the network layer at no cost. That is a separate decision from the four on the whiteboard, and it should be made rather than skipped.

What’s worth remembering

1. Tell the detection services apart by what each one reads: GuardDuty reads account activity logs, Inspector reads host and image software inventory, Macie reads S3 object contents, and Config reads resource configuration.
2. Security Hub CSPM, which is what AWS Security Hub was renamed to in December 2025, reads the other services’ findings and checks them against named standards such as CIS and PCI DSS; most of its controls run as AWS Config rules.
3. GuardDuty needs nothing installed and does not require CloudTrail, flow logs or DNS logging to be configured separately; Inspector scans EC2 through the Systems Manager agent, from EBS snapshots, or both in hybrid mode.
4. Detective investigates after a finding appears, building a linked view from CloudTrail and VPC flow logs; it is not a detection service in its own right.
5. WAF and Shield act on requests in flight, so they prevent rather than detect, and Shield Standard is automatic and free while Advanced adds application-layer protection, a response team and cost protection.
6. Trusted Advisor is a broad best-practice health check across six categories, including security and service limits, with the full set of checks available only on a paid support plan.