2026-08-26 | 0gulcandogan | Imported from Medium| 18 min read

Finally, I Can Sleep Now: Last Part Incident Response and Compliance

Last time we covered eight services that each did one job: noticing something had gone wrong. None of them acted on it, that line was drawn deliberately. This post is about what happens after the alarm goes off, and it operates across three genuinely different timescales. Containment happens between seconds and minutes, you lock a single compromised EC2 instance into a windowless room. EventBridge is instant and automatic, no human touches it. Audit Manager and Trusted Advisor operate over days and weeks, they don’t react to a single incident, they keep asking “are we still doing this right?”

Four topics, three speeds, one thread tying them together. Let’s start.

Short on time? Here’s the quick version:

Containment = escalating levels (Security Group → NACL → Route Table → Internet Gateway), each trading precision for speed
Security-group isolation trick has a trap: tracked vs. untracked connections
EventBridge is the routing backbone that turns “GuardDuty found something” into “Lambda already fixed it”
Audit Manager collects evidence for you, it doesn’t grade you
Trusted Advisor gives you exactly 6 security checks without a paid support plan, know which 6

Containment: Locking a Compromised EC2 Into the Padded Room

You need a playbook before an incident happens, that’s not optional. Once an incident actually occurs, containment buys you time: time to investigate, to clean up, to recover data, all while keeping the compromised instance from doing further damage.

The idea is simple: cut the instance off from everything except itself. It shouldn’t see other instances, shouldn’t reach the internet, shouldn’t be able to talk to anything. Think padded room, not prison cell, this isn’t punishment, just isolation.

Quick reminder of how you learn something’s wrong: GuardDuty watches CloudTrail + VPC flow logs with ML behind it, catching things like a bitcoin miner running on your EC2. Inspector checks network reachability and app-level vulnerabilities, alerting you via email or SNS.

Once you know, you isolate. There are four levels, each trading precision for speed:

Level Scope Speed Trap Security Group Single instance Slow (multi-step) Tracked vs. untracked connections NACL Entire subnet Instant Hits every instance in the subnet, not just the bad one Route Table Entire subnet Instant Instances can still talk to each other within the VPC Internet Gateway Entire VPC Not actually available AWS won’t let you detach it while instances depend on it

Security Group: the targeted option, but never as clean as it looks

People think “security groups deny everything by default,” but that’s only true for inbound. A new security group comes with an outbound allow-all rule, you have to delete it yourself, otherwise your “isolated” instance is still reaching out.
People think “I can block traffic with a security group,” but you can’t. Security groups only ever grant, never deny. To isolate, you don’t add rules, you remove them.

Got multiple overlapping security groups? EC2 applies the most permissive one. And security groups are stateful, response traffic flows automatically regardless of your rules.

The trap that actually shows up on the exam is tracked vs. untracked connections:

Untracked = 0.0.0.0/0, all-ports rule in both directions. Change or remove that rule, and the connection dies instantly.
Tracked = a rule that names a specific IP/CIDR (e.g., 203.0.113.1/32). Remove the rule, and the connection keeps working anyway.
ICMP is always tracked, no exceptions, worth memorizing on its own.

So if the attacker got in over a tracked connection, slapping on an empty security group won’t save you, they’re still there. The real fix:

Create a dedicated isolation security group
Add one rule: 0.0.0.0/0, all traffic, both inbound and outbound
Remove the instance’s existing security groups
Attach the isolation security group
Delete the two rules you just added

Step 2 turns every connection into untracked. Step 5 kills them. Clumsy, but it’s the only way to guarantee nothing survives. If you don’t want to be editing rules live during an incident, prepare two security groups ahead of time: the first (with the 0.0.0.0/0 rule ready to go) and the second (empty). Attach the instance to the first, then the second, done.

NACL: blunter but faster

NACLs operate at the subnet level and are stateless, meaning you need explicit rules for return traffic too (security groups handle this for you; NACLs don’t). Rules are based only on external IPs, you can’t write a rule targeting something inside your own network. And a NACL always attaches to exactly one subnet.

The upside: one DENY ALL rule in each direction, and everything stops instantly. No multi-step dance like with security groups.

The downside: it’s not targeted. Change the NACL, and every instance in that subnet is affected, not just the compromised one.

To use it: add a 0.0.0.0/0 DENY ALL as rule #1 (highest priority) in both inbound and outbound. If the NACL is full, delete a rule to make room, but write down what you deleted so you can restore it later.

Route Table: cuts off the outside not the inside

Route tables also live at the subnet level. Public subnets route to an internet gateway, that’s the connection you’re cutting. Either strip all routes from the existing table, or (cleaner) attach a fresh, empty route table to the subnet.

Watch out: this kills outbound external communication, but instances within the same VPC can still talk to each other. If lateral movement is your concern, this alone isn’t enough.

Internet Gateway: exists on paper, not in practice

Obvious final move, detaching the internet gateway, doesn’t work. AWS won’t let you detach it while any EC2 dependency needs it. You’d have to kill every instance in the VPC first, which defeats the whole purpose.

Want the same effect anyway? You already have it, that’s the route table method above.

EventBridge: The Thing That Moves the Alarm For You

We touched on EventBridge briefly last time, routing CloudWatch alarms. Its real job is bigger: it’s an event coordinator pulling data from AWS services, third-party SaaS tools, and your own apps, then deciding where that information goes.

Quick context on why this architecture exists: monolith → microservice → event-driven is the usual path. Microservices still had to know about each other directly (the order service had to know about invoicing). Event-driven breaks that: a service just shouts “this happened,” and whoever’s listening decides what to do on their own. The order service never has to know who’s listening.

What’s inside an event (all JSON, always the same shape):

Field What it tells you version Always 0 for now id Unique to each event detail-type What kind of event this is source Who actually produced it, can surprise you (see below) account Which AWS account time When it happened region Where it happened resources Related ARNs detail The actual payload

Trap: an EBS Snapshot Notification event’s source is EC2, not EBS. detail-type and source don't always point to the same service. Don't assume.

More than 90 AWS services can produce these events.

Moving parts:

Event Bus is where events land. You automatically get a default bus (AWS events only), plus you can create custom buses for your own apps or partner buses for SaaS. Max 100 rules per bus.
Rules filter events and decide where they go. A single rule can fan out to multiple targets in parallel. Rules don’t run in a guaranteed order. They can also run on a schedule (including cron).
Targets are what actually does the work: Lambda, EC2, Kinesis, ECS tasks, and more, 15 target types total. A single Step Functions target alone can build out nearly an entire workflow.

Cross-account routing works too, a rule in one account can send events directly to another account’s bus.

EventBridge is CloudWatch Events rebranded and expanded, fully backward compatible. The real upgrade is SaaS integration, 30 partner providers (Zendesk, Auth0, Segment, etc.), and EventBridge is the only event service that connects to them directly.

Extra features worth knowing:

Archive: store events indefinitely (or with a TTL) and replay them later. Useful for disaster recovery or reprocessing old data with new logic. Replay currently can only go as far back as the same bus it arrived on.
Schema Registry: every AWS-service event comes with a ready-made schema. SaaS events don’t, but you can auto-discover them. Custom schemas from your own JSON work fine too.
Code Bindings: a Visual Studio extension generates typed bindings for Java, Python, and TypeScript, so your IDE catches errors before deployment.

EventBridge vs. SNS vs. Kinesis in one table:

Best for Where it falls short SNS Extremely simple pub/sub, millions of subscribers No SaaS connectivity, weak routing (triggering Step Functions is a hassle), filtering only on attributes Kinesis Massive-scale real-time data Consumer limits, each consumer filters its own noise EventBridge Rich, content-based routing + SaaS integration Not built for raw throughput like Kinesis

Want simple pub/sub? SNS. Want complex, multi-source routing? EventBridge.

Audit Manager: Collects the Evidence, Never Grades the Exam

Audit Manager continuously collects evidence for compliance reviews, so nobody has to manually screenshot config pages before an audit.

Core building blocks:

Control: a specific policy/procedure/activity that maps to a regulatory or industry requirement.
Framework: a bundle of controls tied to something real, GDPR, CIS, etc. You get 25 managed frameworks out of the box, plus the ability to build your own custom ones.
Assessment: the actual evidence-collection process, tied to exactly one framework. Need to check three frameworks? That’s three assessments.

Two roles:

Audit Owner creates and runs the assessment, usually GRC or SecOps, and should use AWSAuditManagerAdministratorAccess.
Audit Delegate is the subject-matter expert, reviewing only their assigned control set, not the whole assessment (textbook least privilege). They add evidence, write comments, update status, and send it back to the owner.

Setting up an assessment goes through these steps:

Name and description
Choose an S3 bucket for reports (same region, best practice)
Choose a framework
Choose in-scope accounts (if you use Organizations, you can consolidate multiple accounts under delegated admin; if not, you only see your own account)
Choose in-scope services (auto-populated if you’re using a managed framework)
Assign an Audit Owner

Don’t panic if it’s empty at first, give it 24 hours before checking for data.

The Assessment Report packages evidence directly with PDF links. It doesn’t judge whether you’re compliant, it just organizes what it found. Sections: cover page, overview, table of contents, control set page, control page, evidence summary, evidence detail. It lands in the S3 bucket you chose.

Trusted Advisor: The Free Tier Gives You 6 Checks, Know Which 6

Trusted Advisor scores your account across five categories:

Cost Optimization, reserved capacity, idle resources
Performance, are you missing something like provisioned throughput
Security, the category we care about most here
Fault Tolerance, resilience recommendations
Service Limits, flags anything at 80% of quota

There are over 115 checks total (the number shifts, check AWS’s page for the current count), but most require a Business or Enterprise support plan. Without one, you get exactly 6 security checks plus all Service Limit checks:

S3 bucket permissions
Security groups, unrestricted ports
EBS public snapshots
RDS public snapshots
IAM usage
MFA on the root account

Paid plans also unlock admin extras: recent-change tracking, Support API refresh access, CloudWatch integration for check-state changes.

Available to everyone regardless of plan:

Notifications: free weekly email, up to 3 recipients, billing/ops/security
Exclude Items: hide a resource from a specific check (reversible)
Action Links: jump straight to the fix
Access Management: IAM’s trustedadvisor namespace, narrowing access to specific categories, checks, or actions

Refresh rules: data auto-refreshes when you view it if it’s older than 24 hours. Manual refresh is available 5 minutes after the last refresh, per check or all at once. Runs in the background on the AWSTrustedAdvisorServiceRolePolicy service-linked role.

Reading the dashboard: three icons per category, check, triangle, circle. Gray means nothing triggered. Green means no issue. Yellow means go look. Red means fix it now. The number next to each icon is the count of checks in that state.

A real example: VPC limit is 5, you’re using 5, that’s 100%, red alert. Fix: request a limit increase, or delete a VPC. Or: a security group has SSH open to 0.0.0.0/0, that's yellow. Fix: restrict to your own IP, then refresh to verify (wait your 5 minutes), or exclude it if you did it on purpose. Want it all offline? Export to Excel, one tab per check.

The Thread Tying All Four Together

Containment happens within seconds to minutes; a single instance is isolated and locked down manually or by a script. EventBridge, on the other hand, kicks in instantly with no human intervention required. The alarm and the action are already connected before you even wake up. Audit Manager and Trusted Advisor operate over days and weeks. They don’t react to a single bad night; they continuously check whether you’re still doing the right things.

Detection finds it. This post closes the loop and automates the response. In the background, the slower mechanisms keep checking whether your environment has drifted from its intended configuration.

Same chain, different speeds.

Thank you for reading this series this far. I’ve tried my best to share the notes I’ve taken, what I’ve learned, and my experiences with you in a more engaging and easy-to-follow way. I hope I’ve managed to do that.

I’d love to hear your feedback and thoughts. If there’s anything you think is missing, something you see differently, or something you’d like to add, I’d really appreciate you sharing it.

Until the next post, take care.
See you next time 💛

Sources

Original: https://medium.com/@0gulcandogan/finally-i-can-sleep-now-last-part-incident-response-and-compliance-468664e44246?source=rss-746132cb79a8------2

#incident-response #governance #aws-certification #aws #cloud-security

Thanks for reading

If this write-up helped, consider sharing it or exploring more of the log.

← All posts About the author