AWS SCS-C03: Threat Detection, Logging and Response

At 02:17, a workload role begins calling an API it never used before. One monitoring tool reports unusual behavior. A second shows a configuration change to an exposed endpoint, and an operations engineer remembers that a deployment was scheduled overnight. Are these three observations a breach, normal maintenance, or an instrumentation error? AWS security operations begin by finding evidence that can answer the question, not by assigning certainty to a single alert. AWS SCS-C03 tests Detection as a distinct domain worth 16% of scored content, with Incident Response contributing a further 14%. Together they demand both visibility and a practiced response capability.

The distinction matters. Detection selects telemetry, analyzes behavior, and surfaces actionable deviations. Response validates scope, preserves evidence, contains credible threats, and restores safe operation. A well-tuned detection rule cannot compensate for an untested response account, while an excellent runbook is ineffective if the necessary logs were never collected. Engineers need to plan both functions as one operational system without confusing their responsibilities.

Begin with the questions the investigation must answer

Logging programs often fail when every source is enabled without explaining what risk each source addresses. Start with a handful of security questions. Which principal changed a bucket policy? Which workload accessed an unexpected external address? Did a compromised credential act in more than one account? Was the suspicious activity possible before the latest deployment? Each question determines events, identities, timestamps, resource identifiers, and retention periods. It also reveals the gaps a particular telemetry product cannot fill.

A hypothetical data-access incident may require AWS CloudTrail activity, application logs, IAM policy history, configuration snapshots, network-flow metadata, and evidence from the affected data service. A flow record may indicate that communication occurred but not the content transferred. A management-plane API event may show a security setting changed but not prove that confidential records were read. Make an evidence matrix that distinguishes facts observed, hypotheses supported, and unknowns. This prevents an analyst from mistaking “no matching alert” for “no malicious activity.”

Build organization-wide logs without creating a single point of failure

In a multi-account estate, relying on each application owner to configure auditing independently creates inconsistent coverage. An AWS Organizations CloudTrail trail and appropriately controlled log destinations can support centralized event collection, subject to the selected settings and event types. Protected logging accounts reduce the risk that a compromise of one production workload also permits the attacker to overwrite its audit history. Define who can read, change, suspend, or delete the collected records; avoid giving routine deployment automation those privileges.

Collection still needs ongoing verification. A newly created account may lack a required configuration, a role may lose permission to deliver a log, or a region may not be covered as intended. Check ingestion age, source counts, schema changes, encryption, retention, and the operational cost of high-volume event collection. A well-designed failure alarm detects missing data rather than declaring the environment healthy because no security events arrived. Test that responders can search necessary logs when an application account is isolated or unavailable.

Use the correct AWS service for the evidence needed

Amazon GuardDuty produces managed threat-detection findings from supported signals; AWS Security Hub brings security findings and control visibility into an aggregation workflow; AWS Config evaluates resource configurations and histories; Amazon Macie helps identify sensitive data in S3. AWS Security Lake supports security-data aggregation using a normalized data model, while CloudWatch and services such as Athena, OpenSearch, or Logs Insights can support investigation depending on the data source. These tools overlap in workflows but are not equivalent data collectors.

For example, an Amazon GuardDuty alert about unusual API activity should trigger verification of the actor, expected change work, relevant AWS CloudTrail events, and follow-on actions. Marking the finding closed based only on its severity is poor investigation. Conversely, a low-severity signal affecting an especially sensitive asset may deserve immediate triage. Security Hub findings can help operators see patterns across accounts, but their presence does not establish that every required telemetry source was enabled. Engineers should know which tool produced a statement and what assumptions underlie it.

Make network logs and DNS evidence useful to analysts

VPC Flow Logs and transit gateway flow logs can help reconstruct traffic metadata across relevant paths. Resolver query logs can show which names systems attempted to resolve. Neither mechanism guarantees complete application-layer visibility. An unusual DNS request may point to a legitimate dependency or a threat; an unfamiliar destination IP may belong to shared cloud infrastructure. Correlate network observations with workload inventory, deployment records, process or application information, and known organizational traffic before declaring malicious behavior.

Design collection scope to match the architecture. If a centralized egress system carries traffic for dozens of accounts, identify how its records map back to original workloads and roles. If a network device is outside the AWS environment, plan its separate evidence source. DNS can be a valuable correlation pivot, but naming behavior is affected by caching, private zones, and endpoint implementation. The practical mechanics of Route 53 resolution explain why an absence of a particular query does not necessarily mean the application never contacted that service.

Decide what makes an alert actionable

Useful alerting combines a credible signal, a clear affected resource, appropriate urgency, and a next investigative step. “Unexpected API call” is a starting hypothesis. “A production role disabled access logging, from a session originating outside known deployment automation, and then made repeated changes to sensitive bucket policies” is much closer to a useful response trigger. Correlation should make uncertainty smaller, not turn several weak signals into an unsupported certainty claim.

Automated remediation should be similarly scoped. A rule that isolates every instance with one suspicious outbound connection could damage production if a legitimate update service changes behavior. Set conditions, approvals, blast-radius limits, rollback plans, and observable run results. Use dry runs where possible and test the failure mode in a sandbox. Machine-assisted detection can improve triage speed, but false positives, telemetry drift, and stale allowlists remain engineering responsibilities. Monitoring should measure the time from a meaningful event to a defensible decision, not simply the volume of alerts forwarded into a queue.

Preserve evidence before destroying the original scene

Once an incident is credible, containment choices depend on what could continue happening. Revoking an exposed session may be urgent; isolating a compute resource may be useful; removing an entire account from operations may be disproportionate. Responders need to know how to capture relevant system snapshots, record AWS API activity, export logs safely, and establish who can authorize disruptive actions. A compromised instance may contain volatile state that a rebuild would remove. Waiting too long can also permit further damage. The plan must explain how to make that tradeoff quickly and document it clearly.

Keep investigator access separate from everyday workload administration. Store artifacts in protected locations with controlled write access, time records, and appropriate retention. Verify chain-of-custody expectations for the organization and investigation type. A log record is not self-authenticating evidence of every business consequence, so avoid claims beyond what the record supports. Coordination with legal, privacy, and business owners may be necessary when sensitive data or external notifications are involved. Detection is a technical discipline; accountable incident handling is an organizational discipline as well.

Rebuild from trustworthy configuration and validate recovery

Containment does not complete response. Investigators should identify how the activity began, which permissions or exposure permitted it, what systems were affected, and how recurrence can be prevented. AWS Detective and correlated log searches may help explore relationships, but analysts still need a testable root-cause narrative. A rebuild from a known-good image or configuration is preferable to assuming a compromised instance becomes trustworthy after deleting one suspicious process. The decision must account for workload state and operational recovery needs.

Recovery needs independent backups, verified identities, network routes, secrets, and key access. Test whether restored systems still produce the expected security logs. An organization that restores service but leaves detection disabled has traded immediate availability for an unobserved recurrence risk. Record lessons about missing telemetry, policy exceptions, time-consuming approvals, and untested automation. A response runbook should evolve from evidence gathered in actual drills, not from optimism about what a diagram suggests will happen during a crisis.

Measure investigative quality rather than alert volume

A security team may celebrate that it closed hundreds of findings, but the number can reflect noisy detections or automation that hides unresolved issues. Useful evaluation considers whether important incidents were detected, whether the scope was established accurately, whether containment matched the threat, and whether preventive changes were tested. Mean time to detect and mean time to respond help when their definitions remain stable and the underlying incident mix is understood. A period with fewer alerts is not automatically safer.

Security-operations training benefits from comparing the AWS-specific tooling with broader analyst skills represented by CompTIA CySA+ CS0-003 and Microsoft SC-200. Different technologies supply different evidence, but the reasoning discipline is familiar: establish scope, correlate independent observations, separate assumptions from facts, and communicate an authorized next action. These relationships are useful because the cloud engineer and the incident analyst must eventually understand each other’s evidence.

Rehearse a controlled incident from detection to evidence pack

In a sandbox account, perform a permitted configuration change to a test bucket, trigger a deliberately safe but unusual API pattern, and produce ordinary application traffic. Before examining alerts, write a hypothesis explaining which events should appear in which sources. Check CloudTrail delivery, service findings, network records, and any configured aggregation path. Then change one telemetry setting intentionally and observe whether a health check detects the missing data. This teaches the boundary between a benign event, a detection finding, and an ingestion failure.

Close the exercise with an incident note: timestamped observations, scope of verified impact, actions taken, evidence preserved, unresolved questions, and the condition for returning to normal operation. The aim is not to simulate an elaborate attack. It is to prove that the organization can turn scattered signals into trustworthy operational decisions while preserving safe access for responders. That is the practical core behind the Detection and Incident Response sections of SCS-C03.