AWS Detection and Incident Response: Course Purpose and Scope

That alert is the start of one investigation, and the whole thing lives in records like this one.

{
  "eventTime": "2026-05-12T02:14:09Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "ListBuckets",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "203.0.113.77",
  "userIdentity": {
    "type": "IAMUser",
    "userName": "m.chen-dev",
    "arn": "arn:aws:iam::444444444444:user/m.chen-dev",
    "accessKeyId": "AKIAEXAMPLEDEVKEY01"
  },
  "eventType": "AwsApiCall"
}

Read it. A developer's access key, used from an IP the company has never operated from, listing every bucket in the account. The AKIA prefix marks it as a long-lived key, the kind that gets committed to a repository and leaks. The source address is the tell: this key has never been used from there before.

There is no machine to log into, no disk to image, no agent to query. The instance the key was stolen from may already be gone. What remains is the record of the call and the thousands around it, and you answer the whole incident by reading those records well. That single shift, from host to log, is what this course trains.

Who this course is for

This course is for anyone who investigates and responds to attacks in AWS, with no minimum experience and no gatekeeping. Every concept is explained where it first appears, so if you have never opened CloudTrail, the course builds the picture from the first record.

What you need is a working knowledge of security operations: what an alert is, why initial access matters, what an attacker is after once inside. The AWS specifics are taught here.

The investigative discipline transfers directly from wherever you start: follow the identity, build the timeline, scope before you contain. The mechanics do not. Different log sources, a different query language, and a few load-bearing assumptions from on-premises and M365 work that are quietly false in AWS. The early modules spend their time on exactly those differences, because that is where experienced responders make their first mistakes.

If you come from Microsoft 365 security, you are closer than you think. The identity-first instinct is the right one; you are learning new log sources and a new query surface, not a new discipline.

From on-premises IR, your instincts about disks, memory, and packet captures mostly do not apply here, but the timeline-building muscle you already have is the most valuable thing you bring. The adjustment is getting the same answers from API logs instead of host artifacts.

Detection engineers get what a good rule has to key on: the exact CloudTrail and GuardDuty records an attack produces. Cloud and platform engineers, who already know IAM better than most responders ever will, gain the attacker's view of what they build, so the next permission they grant, they can see the path it opens.

What you will be able to do

By the end you can take an unfamiliar AWS account and run a real investigation in it. You read a raw record and say who did what, from where, and whether it succeeded. You pull the right evidence for each stage from the source that actually holds it, instead of guessing which log to open. You reconstruct a multi-step intrusion as a single, evidence-backed timeline.

That investigation is the one behind the alert above, and it runs like this.

You confirm the leaked key has no history at that IP, watch it enumerate buckets, users, and roles, then follow it as it finds an over-permissive role and assumes it. You see it plant a second access key and a Lambda function so it survives a password reset, and trace it into a storage bucket and out.

The part most training skips is saying clearly what the evidence does not show. Real investigations are full of gaps: a log source never enabled, a data event not captured, an action consistent with both an attack and a routine job.

"The key was used from this IP" is a fact. "The attacker read these files" may be an inference if data events were off. Reporting more certainty than the evidence supports does real damage, because containment and notification decisions get made on what you say. The course trains you to state each at its true strength and write down which is which.

The same judgment applies to GuardDuty. A finding tells you the platform noticed something; it does not tell you the scope, the timeline, or whether it is the whole incident or one edge of something larger. You learn to treat it as a lead to pull, not a verdict to accept, which is exactly where investigations that stop at the finding go wrong.

On the response side, you contain an incident without destroying the evidence you still need, revoke an attacker's access across keys, sessions, and roles, and write the investigation up so another responder, or a regulator, can follow it.

What this course does not teach

A course is defined as much by its boundaries as by its content. This one is detection and response, not certification prep, not secure architecture, not other clouds, and not deep host or container forensics. It teaches you to investigate when something gets in, not to design the account or image the disk. Holding that line is what lets it go deep on the part most AWS security content skips entirely: sitting in the responder's chair with the logs in front of you, working out what happened.

How the course is built

Every module investigates the same company. Northgate Engineering runs a four-account AWS Organization, and the people recur as the IAM principals you follow, so you know normal before you have to spot abnormal. When a developer's key leaks in Module 5, it is the same developer whose baseline activity you already saw.

That separation is not decoration. The same call means one thing in the noisy development account and something far more serious in management, where activity is rare. You investigate from the security account, which holds the central trail and the organization's GuardDuty findings, because it can see everything while almost no one can write to it.

The work is anchored to the frameworks practitioners actually reference, so the vocabulary you build matches the wider field. Attacker actions map to MITRE ATT&CK for Cloud; the response follows the AWS Security Incident Response Guide and the NIST incident-handling lifecycle. They appear as labels on the work you are already doing, not topics studied in the abstract.

You can take the whole course on prepared evidence with real query output on the page, no AWS account required. If you want to run the attacks in your own account, the lab pack stands the environment up with infrastructure-as-code, and it is the stronger path for committed students. The next section covers both.

One idea sits under all of it. In AWS you investigate what the platform recorded. The host may be gone, the credentials revoked, the resource deleted, and the record of the action remains. Once you can read that record, the absence of everything else stops being the obstacle it is on-premises. Most of this course trains that single ability.

AWS0.2 covers how to work through the course: the query surface, the two learning paths, and the predict-then-reveal habit that turns reading into skill.