AWS Security Services for Threat Detection and Data Protection

Welcome back. In the previous lesson, you separated three kinds of evidence: CloudTrail records AWS activity, AWS Config records supported resource configurations, and CloudWatch monitors operational behavior. A security investigation may use all three, but evidence alone does not tell you which risk deserves attention.

This lesson adds four services that answer different security questions. For SAA-C03, the task is usually to recognize the requirement—detect an active threat, find a vulnerability, discover sensitive data, or bring findings together—and select the service built for it. We will also connect those choices to the EC2, S3, and multi-account environments you may design.

Start with the security question

The AWS security-service map places GuardDuty, Inspector, and Security Hub under detection and response, but Macie under data protection. That placement is useful, provided you do not mistake a category for a precise selection rule.

Think of the four as answering separate questions:

These services can work together. A central finding is not necessarily a detection made by the central service itself; identifying where a finding originated is often the key exam distinction.

Detect suspicious activity with GuardDuty

Imagine credentials associated with an EC2-based application begin making unusual API calls. You do not yet know that a particular package is vulnerable, nor are you asking for a complete history of API requests. You want a service to assess activity for signs of compromise. That is GuardDuty’s threat-detection role.

Read AWS’s overview for the signals GuardDuty looks for and the kind of result it produces.

GuardDuty analyzes supported activity sources using techniques such as threat intelligence and anomaly detection. Its output is a finding: an assessment that something may require investigation. That is different from a CloudTrail event. CloudTrail might show an API call and its recorded context; GuardDuty might identify a pattern of calls as suspicious.

Your firewall-administration experience offers an important boundary here: GuardDuty is not an inline firewall rule that blocks the traffic it flags. Detection can prompt an investigation or a separately configured response, but enabling a detector should not be confused with enforcing a network policy. GuardDuty can analyze supported AWS activity without you first building your own log-processing pipeline; it still needs to be enabled and given the relevant coverage.

Assess vulnerable workloads with Inspector

Now change the question. Suppose you operate Linux and Windows EC2 instances and need to know which have affected software packages after a vulnerability is disclosed. There may be no observed attack at all. You need an inventory of vulnerable workloads and a way to prioritize remediation. Select Amazon Inspector.

AWS’s overview establishes the vulnerability-management role and introduces its risk-based findings.

Inspector also supports scanning eligible Amazon ECR container images and AWS Lambda functions. The following demonstration makes the scope and the shape of an Inspector finding concrete. Watch its console views, not its later deployment steps.

An Inspector finding such as “this instance has an affected package” describes a condition that could be exploited. A GuardDuty finding such as suspicious credential use describes observed activity that may indicate a threat. Both matter, but they answer different questions. In an EC2 fleet, also check Inspector’s coverage: an absence of findings is less reassuring if an instance is not eligible or configured for the relevant scan.

Discover sensitive data in S3 with Macie

Suppose an organization has many S3 buckets and needs to locate objects containing personal information before changing access or retention policies. Bucket names, encryption settings, and public-access settings will not tell you which objects contain that information. Choose Amazon Macie for sensitive-data discovery in Amazon S3.

Macie has two related but distinct uses in this reading: it provides S3 bucket inventory and security evaluation, and it can perform sensitive-data discovery against objects. For example, a publicly accessible bucket is a bucket-security concern; an object containing personal identifiers is a content-discovery concern. They can occur together, but one does not prove the other.

Do not generalize Macie into a scanner for every AWS datastore. If the scenario specifically asks you to identify sensitive information in S3 objects, Macie is the direct fit. It also does not automatically make an exposed object private merely because it reports a finding; protection or remediation requires an appropriate action.

Bring findings together with Security Hub

A security team may receive GuardDuty threat findings, Inspector vulnerability findings, and Macie sensitive-data findings across several accounts. Opening each service separately makes it harder to maintain a consolidated view. AWS Security Hub CSPM addresses that problem by aggregating supported findings in a common format. It also performs security best-practice checks through enabled standards and controls.

Read the service overview, then use the short console tour to distinguish a source finding from the place where you review it.

There are two traps to avoid. First, Security Hub does not replace its finding providers: bringing GuardDuty findings into one view does not cause Security Hub to perform GuardDuty’s threat analysis. Second, a dashboard is not automatically complete. Its coverage depends on which sources, checks, accounts, and Regions are enabled or integrated. Many Security Hub CSPM controls rely on AWS Config recording; seeing imported findings is not the same as having every posture check running.

Security Hub can support response workflows through integrations, but aggregation is not automatic remediation. Keep “show all the issues in one place” separate from “fix every issue.”

Put the distinctions to work

Consider a three-tier workload with EC2 application servers and S3 document storage. A security review produces four requests:

1. Investigate whether unusual API activity suggests that credentials have been misused. GuardDuty is the detection service; CloudTrail remains useful when investigating the underlying recorded activity.
2. Identify application instances affected by a newly disclosed package vulnerability. Inspector assesses the eligible workloads, even if no attack has been detected.
3. Find S3 documents containing personal information. Macie examines S3 data for sensitive content.
4. Give the security team a consolidated view of these findings and security-control results. Security Hub CSPM brings supported findings and checks together.

This is also a safe point to apply the lab-cost discipline established earlier in the course. You do not need to enable any of these services to learn the selection rule. Trials and Free Tier eligibility differ by service and feature; scanning, security checks, AWS Config recording, and retained data can create charges. If you later run a hands-on test, check current pricing and your budget first, enable only the intended scope, and verify what remains active afterward.

Key takeaways

Choose GuardDuty for suspicious activity, Inspector for workload vulnerabilities and unintended network exposure, Macie for sensitive-data discovery in S3, and Security Hub CSPM for consolidated findings and security-posture checks. A finding’s source matters: aggregation does not turn Security Hub into the detector that produced it.

The next module moves from identifying security risks to controlling access. You will determine effective permissions when IAM policies, resource policies, permissions boundaries, session policies, and service control policies interact.