AWS Detection and Incident Response: Course Purpose and Scope

Who this course is for

This course is for anyone who wants to investigate and respond to attacks in AWS. That includes SOC analysts moving from on-premises or Microsoft 365 into cloud work, incident responders who keep getting handed AWS accounts they were not trained for, detection engineers who need to write rules against CloudTrail, and cloud and platform engineers who want to understand what an attack looks like in the logs they already generate.

There is no minimum experience requirement and no gatekeeping. Every concept is explained where it first appears. If you already know what an IAM role is or how AssumeRole works, you will move through those parts quickly. 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: you understand what an alert is, why initial access matters, and what an attacker is trying to do once they are in. The AWS specifics are taught here.

If your background is Microsoft 365 security, you are closer than you think and further than you expect. The investigative discipline transfers directly: follow the identity, build the timeline, scope before you contain. The mechanics do not. The log sources are different, the query language is different, and a few of the load-bearing assumptions from on-premises and M365 work are quietly false in AWS. The early modules spend their time on exactly those differences, because they are where experienced responders make their first mistakes.

The other backgrounds arrive with different gaps, and the course is built to meet each. If you come from on-premises incident response, your instincts about disks, memory, and network captures are sound but mostly inapplicable here, and the adjustment is learning to get the same answers from API logs instead of host artifacts. You will find the timeline-building muscle you already have is the most valuable thing you bring. If you are a detection engineer, your goal is the rule at the end, and the course gives you the evidence to write rules against: you see the exact CloudTrail and GuardDuty records an attack produces, which is what a good detection has to key on. If you are a cloud or platform engineer, you already understand IAM, roles, and the services better than most responders ever will, and what you gain is the attacker's view of the environment you build, so that the next time you grant a permission you can see the path it opens. None of these readers is the wrong audience. Each one is missing a different piece, and the course is sequenced so the pieces arrive in an order that works regardless of where you started.

What you will be able to do

By the end of the course you can take an unfamiliar AWS account and run a real investigation in it. Concretely, you will be able to read a raw CloudTrail record and say who did what, from where, and whether it succeeded. You will pull the right evidence for each stage of an attack from the source that actually holds it, rather than guessing which log to open. You will reconstruct a multi-step intrusion, from a leaked key through privilege escalation, persistence, and exfiltration, as a single timeline supported by evidence. You will triage a GuardDuty finding instead of taking it at face value, and you will know when the finding is the whole story and when it is one symptom of something larger.

You will also learn to say clearly what the evidence does not show, which is a skill most training skips entirely. Real AWS investigations are full of gaps: a log source that was never enabled, a data event that was not captured, an action that is consistent with both an attack and a routine job. A responder who reports more certainty than the evidence supports does real damage, because containment and notification decisions get made on what you say. So alongside reading evidence, the course trains the discipline of separating what a record proves from what it merely suggests, and stating each at its true strength. "The key was used from this IP" is a fact. "The attacker read these files" may be an inference if data events were off. Knowing which is which, and writing it down that way, is part of what makes an investigation trustworthy.

A specific version of that judgment is reading GuardDuty findings well. GuardDuty is the AWS threat-detection service, and a finding arrives with a type, a severity score, and the resource or identity it implicates. It is a useful starting point and a poor stopping point. 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 visible edge of a larger one. You will learn to take a finding as a lead, pull the CloudTrail around the named identity and time, and decide for yourself what actually happened. Sometimes the finding is the whole story. More often it is the thread you pull to reach everything the detector did not flag, and treating it as the conclusion rather than the opening is one of the most common ways a real investigation stops too early.

On the response side, you will know how to contain an AWS incident without destroying the evidence you still need, how to revoke an attacker's access across keys, sessions, and roles, and how to preserve what matters before resources are terminated. You finish able to write the investigation up in a way another responder, or a regulator, can follow.

To make that concrete, picture the investigation behind the scenario at the top of this section, the one you will actually run later in the course. It starts with a single GuardDuty finding about a developer's access key used from an unfamiliar location. You confirm from CloudTrail that the key is being used from an IP with no history, then watch the identity run a burst of enumeration, listing buckets, users, and roles, mapping what it can reach. You follow it as it finds an over-permissive role and assumes it, gaining reach it did not start with. You see it create a second access key on a different user so it keeps a way in even if the first key is found, and stand up a Lambda function that quietly re-creates that access if it is removed. Finally you trace it into a storage bucket and out. By the end you can state the whole sequence as a timeline, name every identity and action, separate what the evidence proves from what it only suggests, and lay out the containment that closes all of the attacker's footholds rather than just the first one. That is the shape of the capability. Each module builds one part of it, and the capstone hands you the whole chain at once.

These are capabilities, not topics you will have heard about. The course causes the experience of doing the work, against a realistic environment, with the real evidence on the page.

What this course does not teach

A course is defined as much by its boundaries as by its content. Holding these boundaries is what lets the course go deep on detection and response instead of spreading thin.

What remains after those exclusions is the part most AWS security content skips: sitting in the responder's chair, with the logs in front of you, and working out what happened.

How the course is built

Every module investigates the same company. Northgate Engineering is a mid-size engineering firm with an AWS Organization: separate accounts for management, security and logging, production, and development. The people are consistent too, and they appear in the logs as the IAM principals you will follow. When a developer's key leaks in Module 5, it is the same developer whose normal activity you saw in the baseline. When an attacker pivots into the production account, you already know what production is supposed to look like. The continuity is deliberate, because real investigation depends on knowing normal before you can spot abnormal.

The four-account structure is not decoration; it is how real organizations on AWS separate risk, and each account plays a role in the investigations. The management account sits at the top of the Organization and is where organization-wide settings live, so activity there is rare and any change is significant. The security account holds the central CloudTrail bucket and the GuardDuty findings for the whole organization, and it is the account you investigate from, because it can see everything while being writable by almost no one. The production account runs the live workloads, the EC2 instances, the customer-facing storage, the roles those workloads assume, and it is where the impact of an attack usually lands. The development account is busier and looser, the kind of place where a long-lived key gets committed to a repository, and it is often where an intrusion begins. Knowing which account an event happened in is itself a piece of evidence: the same call means one thing in development and something far more serious in management.

The investigations are anchored to the frameworks practitioners actually reference, so the vocabulary you build here matches the wider field. Attacker actions map to MITRE ATT&CK for Cloud, which gives you a shared language for techniques like valid-account abuse and unused-region activity. The response work follows the AWS Security Incident Response Guide and the NIST incident-handling lifecycle, so the containment and recovery steps line up with what an organization's IR plan is likely to expect. These are not topics studied in the abstract. They appear as labels on the work you are already doing, so that when you finish you can describe an investigation in terms a colleague at another company would immediately recognize.

The course is built to work whether or not you have an AWS account of your own. Every hands-on moment runs against prepared evidence with real query output on the page. If you want to stand up the environment in your own account and run the attacks yourself, the lab pack supports that, and it is the stronger path for committed students. Neither path is required to learn. The next section covers how to get the most from whichever path you choose.

One idea sits under all of this and is worth carrying forward. 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 still remains. Once you can read that record, the absence of everything else stops being the obstacle it would be on-premises, and most of this course is training that single ability.

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