Resources & Next Steps

Put the account itself on a proper footing

Three separate things hide inside this one line. Bring your accounts under AWS Organizations so there is a single boundary to attach policy to. Treat the root user as a break-glass credential rather than a login — there are a handful of tasks that genuinely require it, and MFA on it is not optional. And fill in the account contacts, because the alternate security and operations contacts are how AWS reaches a human when something is wrong and the person who created the account left two years ago.

The contacts item is the one teams skip, and it is the one that costs you hours during a real incident. An abuse notification sent to a mailbox nobody reads is functionally the same as no notification.

Have one identity source, not one per account

The recommendation is to run workforce access through a central provider — IAM Identity Center, or a third-party identity provider federated into it — instead of creating IAM users and handing out long-lived access keys. The reason is arithmetic. An IAM user exists in exactly one account, so a person who needs access to eight accounts either gets eight identities or gets a role-chaining scheme somebody has to maintain. Federation collapses that: one identity, permission sets projected into whichever accounts the person should reach.

The credential argument matters just as much. A long-term access key has no natural expiry, which means a leaked key is valid until somebody notices and revokes it. Federated sessions expire on their own, so the same mistake has a much shorter blast window.

Use account count as a security boundary

Separate workloads from each other, and separate stages of the same workload — production away from everything that is not production. An account boundary is the strongest isolation AWS offers: distinct resource namespaces, distinct default quotas, and a blast radius that stops at the edge. It is also the attachment point for service control policies, so putting production in its own account and its own organisational unit is what makes a "never disable CloudTrail here" guardrail expressible in the first place.

This is the argument for Control Tower rather than a hand-rolled organisation. The pattern is well understood enough to be automated, and standing up the OU layout, the shared accounts and the baseline controls by hand is a lot of undifferentiated work to redo per environment.

Prefer credentials that expire; store the rest properly

The order of preference is explicit. First choice is a temporary credential — a session issued by AWS Security Token Service, which arrives scoped and expires on a clock you set. Only when that is genuinely impossible does the second option apply: keep the value in AWS Secrets Manager, which encrypts it, rotates it on a schedule, and controls who can read it through IAM rather than through who has access to the repository.

Anything that is neither of those — a database password in an environment variable baked into an image, a key pasted into a Systems Manager parameter as plaintext, credentials in a private Git repo — is a finding waiting to be written up. The distinction is not "encrypted or not", it is whether the secret has a rotation story and an access log.

Turn on the three foundational services — in every account

CloudTrail records API activity, so you can answer "who called this, from where, with which credential". GuardDuty watches continuously for behaviour that looks like compromise rather than misconfiguration. Security Hub collects what the others produce and gives you one posture view instead of one console per account per service.

The words that carry the weight are every account. A member account with detection switched off is not a small gap; it is the account an attacker will find first, because the absence of findings from it is indistinguishable from good behaviour. Enable all three at the organisation level so new accounts inherit them on creation, rather than as a step in an onboarding runbook somebody will eventually skip.

Log at the service layer, not just the application layer

Your application logs tell you what your code did. They cannot tell you that a security group was opened to the world at 02:14, or that an unfamiliar address moved four gigabytes out of a subnet. That evidence lives in service-level logging: VPC Flow Logs for network conversations, S3 server access logs for object-level reads, load balancer access logs for what reached the front door, CloudTrail for the control plane.

Then two conditions that turn logs into evidence. They flow to a central account, so the investigation is one query rather than a scavenger hunt. And they are protected against modification and deletion — which is precisely why a landing zone puts the log archive in its own account, with nobody in the workload accounts holding write access to the destination. An attacker who compromises an account and can also erase that account's history has removed the only record of how they got in.

Monitor, alert, and actually investigate

AWS Config is the piece that turns a log into a control. It records the configuration of your resources over time, so you can ask what a resource looked like before the change, and Config managed rules evaluate that state against a desired condition — then alert, or remediate, when it drifts. That is a materially different capability from a log you can search: the rule notices without anybody looking.

The rest of the recommendation is about triage discipline. Every log and finding source you own — CloudTrail, GuardDuty, Config, your own application logs — needs a defined set of high-priority events with an alert attached, and someone whose job it is to look. Alerting on everything produces the same outcome as alerting on nothing, just with more noise on the way there.

Patch all three layers, on a schedule, without SSH

The recommendation covers the operating system, the applications running on it, and the dependencies your own code pulls in. All three are yours under the shared responsibility model, and the third one is the layer teams forget: a fully patched host running a service with a two-year-old library in it is not patched.

Patch Manager is the mechanism because it makes the work schedulable and reportable. You define a baseline that says which classes of update are approved and how long they sit in quarantine, attach a maintenance window, and get compliance state per instance afterwards. That last part is what makes it a governance control rather than an ops chore — "which instances are behind" becomes a query instead of a survey.

Give internet-facing resources a real edge

Three services, three different layers of the problem. CloudFront moves the point of first contact away from your origin and absorbs volume at the edge. Shield handles the network and transport floods — the layer 3 and layer 4 attacks that are about exhausting capacity. WAF handles layer 7, where the traffic is well-formed HTTP that happens to be an injection attempt or a credential-stuffing run.

Worth being clear that these compose rather than substitute. WAF rules do nothing about a volumetric UDP flood, and Shield does not know that a request body contains SQL. Anything AnyCompany exposes publicly wants all three, and the ordering matters: put the distribution in front, then attach the web ACL to it, so filtering happens before the request reaches anything you pay per-request for.

Let the network topology do some of the work

Security groups are the per-resource control for inbound and outbound traffic, and the useful discipline is to reference other security groups rather than address ranges — "the application tier may reach the database tier" survives a re-IP; a hard-coded CIDR does not.

Subnet layering is the structural half. If your database subnets have no route to an internet gateway, then a misconfigured security group on a database instance is a much smaller problem, because there is nowhere for the traffic to go. That is defence in depth expressed as routing rather than as policy, and routing is harder to fat-finger.

Firewall Manager is what makes either of these hold across an organisation. Rather than hoping every account configures its own rules the same way, you author the rule once centrally and it is applied and enforced everywhere — for both security groups and web ACLs.

Encrypt at rest, and make it the default rather than a decision

KMS is the key management layer that a long list of AWS services integrate with directly, plus your own applications through the SDK. Encryption at rest is the easy half of this recommendation; the interesting half is the word default. Switch on default encryption for EBS at the account and Region level, and set bucket-level encryption on S3, so an engineer who forgets to tick the box still gets an encrypted volume or object.

The governance value is not really the cryptography — it is that the key policy becomes an independent authorisation check. Someone who acquires read access to an object but cannot use the key gets ciphertext. That separation is why a customer-managed key is worth the extra administration for anything genuinely sensitive.

Encrypt in transit, including the hops you think are internal

The recommendation is TLS on all network traffic, and the important scope note is that it does not stop at the public edge. Traffic between a load balancer and its targets, between microservices, and between an application and its database all counts. "It is inside the VPC" is an assumption about the network you do not fully control.

Certificate Manager exists so that this is not a calendar problem. It provisions and renews certificates for the AWS services that integrate with it, which removes the classic outage where a certificate nobody owned expired on a Sunday. Manual certificate management is the reason encryption in transit gets quietly turned off.

Design so that nobody needs to touch the data

The most under-rated line on the whole checklist. Rather than tightening the permissions on direct access to sensitive systems, remove the reason for direct access. A business analyst who needs to see aggregate numbers gets a QuickSight dashboard, not a read-only database credential — and now there is no query they can run that returns a customer record.

The operational equivalent is acting at a distance. Instead of granting interactive shell access so an engineer can restart a service or collect a log bundle, publish that task as a Systems Manager automation document or a Run Command target. The engineer runs a defined operation, the parameters and the outcome are recorded, and no long-lived SSH path into production needs to exist. It is a better security posture and a better audit trail arriving from the same change.

Build the plan out of runbooks, not principles

The recommendation is deliberately specific about the shape of the artefact. Start from runbooks — one per class of unexpected event you can imagine in your workload — rather than from a policy document that describes escalation tiers in the abstract. A runbook has to name the console, the query, the role you assume, and the person you call. That specificity is what makes it usable at three in the morning, and it is also what exposes the gaps: you cannot write "pull the flow logs for the affected subnet" without discovering whether flow logs are on.

The AWS Security Incident Response Guide is the reference for structuring this, including the parts teams skip — how you preserve evidence before you remediate, and how you decide when an event is over.

Make sure a finding reaches a person who can act on it

Start with GuardDuty, because its findings are the closest thing to a genuine "something is wrong right now" signal you get for free. Turn it on, then close the loop: the notification has to arrive somewhere a human with the authority to do something will see it, within a timeframe that still matters.

The stated best practice is to create a ticket automatically rather than send mail. The reasoning is unglamorous and correct — a ticket has an owner, a state, and an ageing report, and a shared mailbox has none of those. Wiring findings into the queue your team already works from is what turns detection into an operational process instead of a dashboard somebody checks on Fridays.

It is also worth reading the finding types before the first one fires. Knowing which of them mean "credentials are being used from an unusual place" versus "an instance is talking to a known command-and-control host" is the difference between triaging in five minutes and reading documentation during an incident.

Rehearse, then change the plan based on what broke

Run game days on a regular cadence: simulate an event, work the runbook as written, and record every point at which reality diverged from the document. The second half of the recommendation is the half that gets dropped — feed the lessons back into the plan and keep doing that. A game day that produces a report nobody merges into the runbook was an expensive fire drill.

What game days reliably surface is not gaps in knowledge but gaps in access: the responder who cannot assume the role the runbook names, the log bucket in an account nobody on call can reach, the automation document that exists in staging only. None of those appear in a tabletop discussion. All of them appear within ten minutes of a live exercise.