Every link the course points at, in one place. Documentation, whitepapers, blog posts, conference sessions, workshops and learning paths — grouped by topic, annotated so you know what each one actually gives you, and filterable so you can find the one you half-remember. This is the page to bookmark.
Try a shorter word or drop a type filter. The filter searches titles, descriptions and module tags across every tab at once.
Twelve links, in the order I would actually read them. The course pointed at well over a hundred resources; these are the ones that repay the time on their own, without a classroom around them. Everything else is organised by topic on the other five tabs.
The single most useful document in this entire list. It lays out which security service belongs in which account of a multi-account organisation, and why — the reasoning behind every landing-zone diagram in the course. Read it before you design anything.
AWS’s own opinionated starting point for structuring an organisation. Short, prescriptive, and the fastest way to sanity-check an account layout you have already built.
The framing the course’s security checklist is derived from. Use it as the agenda for an architecture review rather than as bedtime reading — each section ends in questions you can actually put to a team.
The index page for every security service’s docs. Worth a bookmark purely so you stop landing on the marketing page when you meant to land on the API reference.
The orientation page. Read this to understand what Control Tower automates on your behalf before you decide whether you want it to — because undoing an opinionated landing zone is far harder than choosing not to deploy one.
The reference for the course’s central preventive control. Pay particular attention to what an SCP does not do: it never grants permission, and it does not apply to the management account.
Where self-service provisioning starts. The concept you came for is the launch constraint — the mechanism that lets a product deploy with permissions the person launching it does not personally hold.
The detective half of the course in one page. The distinction that matters and is easy to miss: recording configuration is one feature, evaluating it against rules is another, and you pay for them separately.
The most immediately actionable link here. Several hundred rules AWS already wrote for you. Skim it before anyone on your team starts writing a Lambda-backed custom rule, because roughly nine times in ten the rule already exists.
Systems Manager is really a dozen loosely-related tools sharing a console, which makes it genuinely hard to learn from the service docs alone. This whitepaper is the map that tells you which capability solves which operational problem.
Read it on a calm afternoon, not during an incident. The value is in the preparation chapters — the access, tooling and logging decisions you have to make long before anything goes wrong.
The most current session in the course’s video list, and the one that best matches how controls are actually managed today. A good single hour if you only watch one thing from this library.
AWS Organizations, organisational unit design, Control Tower and the landing zone, centralised identity, and the industry research the course uses to argue that manual governance stops scaling. This is the morning session’s reading list.
The feature inventory, straight from the user guide. Useful when someone asks whether Organizations can do a particular thing and you want an answer you can cite rather than remember.
Why OUs should reflect what you want to control rather than how your company draws its org chart. If you take one habit from this post, make it grouping accounts by the policies they need instead of by the team that owns them.
The long-form treatment of the same territory: what an account boundary actually buys you, and how to decide when a new workload deserves its own account.
Attribute-based access control applied at organisation scale. Reach for this when your policy count is growing faster than your account count — tags let one policy cover cases that would otherwise need ten.
The grammar. Keep it open the first few times you write an SCP, because the elements an SCP supports are a deliberately narrower set than a normal IAM policy — no Principal, and condition support varies by element.
Copy-paste starting points: region restrictions, protecting the Control Tower baseline roles, denying root-user actions. Faster than writing from scratch and less likely to lock you out of your own organisation.
The root of the docs tree, including the API and CLI references the user guide does not surface. Start here when you are automating Control Tower rather than clicking it.
Pricing, region availability and the current feature summary. The page to send to whoever is asking what this costs before you get to the architecture conversation.
The same product page with its blog list pre-sorted by date. Control Tower changes quickly, so this is the honest way to check whether a limitation you read about last year is still a limitation.
Unusually good for an FAQ page. This is where the awkward questions get answered — what happens to existing accounts, how controls interact with your own SCPs, what you can and cannot customise.
The mechanics behind the abstraction: which underlying services get configured, in what order, and which resources you must not rename or delete afterwards.
Deep link to the section explaining the log archive and audit accounts. Worth reading closely: the separation between them is a design decision with real consequences for who can read what.
The end-to-end first-landing-zone walkthrough. Read the prerequisites section twice — most failed launches are a prerequisite that was skipped, not a bug.
The prelaunch checklist: management account requirements, email addresses you need available, and the existing-resource conditions that will stop a launch before it starts.
Check this before you promise anyone a design. Several of the quotas here are not adjustable, and finding that out during implementation is an expensive way to learn it.
The brownfield path, which is the situation most teams are actually in. Covers what happens to your existing OUs, accounts and policies when Control Tower is layered on top.
The reasoning behind the default OU and account layout — why security and sandbox exist as separate OUs from day one rather than being added later.
The full control catalogue, plus the two axes that matter: behaviour (preventive, detective, proactive) and guidance (mandatory, strongly recommended, elective). The course returns to this page repeatedly — it is the reference for activating controls too.
The CloudFormation-based predecessor to Control Tower. Included for context and for anyone maintaining an environment built this way — new builds should use Control Tower instead.
One place to manage workforce access to every account in the organisation. The mental shift is that permission sets are defined centrally and projected into accounts, rather than each account owning its own users.
How identities arrive: typed in by hand, synced from an external directory over SCIM, or supplied by an existing identity provider. Get this decision right early, because migrating provisioning models later is painful.
The product-side getting-started page, cited on the course’s security checklist. Shorter than the user guide and enough to get a first permission set assigned.
The standard itself, from the body that maintains it. You rarely need this, but when a federation handshake fails in a way no AWS doc explains, the answer is in here.
The short, clear statement of why the root user is different in kind and not just in privilege. Useful for settling the argument about whether it is acceptable to use it for routine work. It is not.
The definitive list of the handful of tasks that genuinely require root, so you can lock it down for everything else without discovering a gap later.
The single highest-value ten minutes on the whole security checklist, for every account in the organisation. Deep link straight to the procedure.
The API behind every assumed role and every federated session. Reach for it when you are building cross-account automation and need to reason about session duration, tags or policy scoping.
Third-party research on delivery performance, cited in the opening module. Its value in a governance conversation is the finding that speed and stability rise together — which undercuts the assumption that controls must slow teams down.
Workload and traffic growth projections used to set up the scale argument. Treat it as historical framing rather than current data — the numbers are dated, the direction of travel is not.
The container-adoption forecast behind the “more workloads, more surface area, same size platform team’’ framing. Cited for the trend, not the dollar figure.
The service-category landing page. Handy for the wider picture — the course covers maybe half of what lives in this category, and the other half is worth knowing exists.
Which services are covered by which attestation — SOC, PCI DSS, HIPAA, FedRAMP and the rest. The first page to check when an auditor asks whether a service you depend on is in scope.
Vetted third-party security tooling, filterable by category. Relevant to this course because Security Hub ingests findings from many of these partners, so the aggregation story only works if you know who is on the list.
Service Catalog, Account Factory, launch constraints, sharing catalogues across many accounts, budgets as a governance control, cost allocation tags, and wiring provisioning into the ticketing system your organisation already uses.
The vocabulary page: product, portfolio, provisioned product, constraint. Read it once properly and the rest of the admin guide stops being confusing, because these four terms carry the whole model.
Account Factory is a Service Catalog product that happens to provision whole accounts — once that clicks, the design makes sense. This page covers both the provisioning flow and how to customise the baseline it applies.
The pattern that turns Service Catalog from a single-account convenience into an organisation-wide capability: one hub account owns the portfolios, every spoke account consumes them. This is the post to read before you build your second catalogue.
The service-management framework whose language your change and request processes probably already speak. Included because self-service provisioning has to land inside an existing ITSM process, not beside it.
How to attach a budget to a portfolio or a product so spend is visible at the level people actually make decisions — per capability, not just per account.
Deep link to the setup conditions. The one that catches people is cost allocation tags: without them activated, the budget has nothing to group spend by and reports zero.
The product page for the service that turns cost from a monthly surprise into a threshold with an action behind it. The deck also cites this page without the trailing slash; both resolve to the same place.
The procedure, including alert thresholds. Set at least two — one early warning you can act on, one hard line that means something has gone wrong.
The step everyone forgets. A tag exists on the resource immediately but does not appear in cost reporting until you activate it here, and activation is not retroactive — so do it before you need the data, not after.
Where a budget stops being a notification and becomes a preventive control: apply a policy, stop instances, or require approval when a threshold is crossed. The most governance-relevant page in the cost documentation.
Surfaces your Service Catalog products inside the ServiceNow portal, so builders request AWS resources the same way they request everything else. Meets people where they already are.
The step-by-step install, with the IAM and ServiceNow-side configuration spelled out. More practical than the reference documentation if you are doing this for the first time.
The same idea for Atlassian shops. Also pulls Config, Systems Manager and Security Hub data into the ticket, which makes the ticket genuinely useful rather than just a request form.
A published account of building an internal platform on top of these services. The honest part is the organisational work — getting teams to adopt a standard platform is harder than building one.
Systems Manager applied at genuine enterprise scale. Read it for the patterns around inventory and patch compliance across a fleet nobody can enumerate by hand.
The afternoon’s detective half: recording configuration and evaluating it against rules, the CloudFormation underneath custom rules, operating a fleet through Systems Manager, and the detection and logging services that feed the whole picture.
The root of the Config docs tree, including the API and CLI references. Where to go when you have outgrown the console and are defining rules as code.
Features and pricing. Read the pricing detail carefully — configuration items, rule evaluations and conformance packs are billed on separate meters, and a broad recorder across many accounts adds up.
How evaluation actually works: what triggers it, the difference between change-triggered and periodic rules, and how compliance state is recorded. The page that explains why a rule sometimes appears not to have fired yet.
For the genuine gaps the managed rules do not cover. Covers both Lambda-backed rules and Guard-based custom policy rules, which are considerably less work when your requirement is expressible as a property check.
How to get the same Config setup into every account without visiting each one. StackSets plus organisation-level Config is the pattern that makes multi-account compliance reporting practical.
The Config console is fine for one account and useless for eighty. This post queries the delivered configuration snapshots with Athena and puts a dashboard on top — the practical route to an executive compliance view.
Conformance packs bundle a set of rules and remediations into one deployable artefact, which is how you ship “our PCI baseline” as a single unit. Useful even if you use CloudFormation — the pack structure is the transferable part.
The sharing half of the dashboard story. Relevant because a compliance dashboard nobody outside the platform team can open is not really reporting.
The anatomy of the section you spend the most time in. Worth revisiting once you have written a few templates, because the properties you skipped early on are usually the ones you need later.
The substitution function that makes templates reusable across accounts and regions instead of hard-coding ARNs. Small page, disproportionate payoff.
Exactly how you declare a Config rule in a template — the property that decides whether the rule is AWS-managed or points at your own Lambda function. The reference you need to define rules as code.
The capability overview. Systems Manager is best understood as a suite rather than a service, so this page is mainly useful for working out which of its dozen or so tools you actually need.
Run a command across many instances without SSH, bastion hosts or inbound ports. The clearest single demonstration of why removing shell access improves both security and operability.
Patch baselines, maintenance windows and compliance reporting. The reporting side is the governance-relevant part: it turns “we patch regularly” into evidence you can hand to an auditor.
Patching estates that are not all in AWS, using the hybrid activation model. Directly relevant if you have on-premises servers you would rather not manage with a second toolchain.
The pattern for driving patch operations from one place across the whole organisation. This is the blog post that answers “fine, but who runs it, and from which account?”
What GuardDuty analyses and what it can conclude. The key point for a governance discussion is that it needs no agents and no log pipeline of your own — it reads the sources AWS already has.
The same page, cited again in the deck alongside the Security Hub feature list. Listed separately because both forms of the link appear in the course material.
Overview and pricing. Pricing is volume-based on the logs analysed, so estimate from your CloudTrail and flow-log volumes rather than from account count.
Enablement, including the delegated-administrator model that switches it on for every account in the organisation at once. Do it that way from the start; retrofitting per-account enablement is tedious.
The finding-type catalogue and how severity is assigned. Read it before you build alerting, so your routing rules reflect what the finding types actually mean rather than a guess from the name.
The aggregation layer — one place for findings from GuardDuty, Inspector, Macie, Config and third-party partners. The service that stops each detection tool being its own separate inbox.
The documentation entry point. The concept worth understanding here is the normalised finding format — it is what makes findings from very different tools comparable and sortable.
The API activity record that everything else depends on. If you only get one logging decision right in a new organisation, make it an organisation trail delivering to a locked-down archive account.
The bucket policy and trail configuration for central log collection. The point is not convenience, it is that a compromised member account must not be able to delete its own history.
Network-level visibility, and one of the sources GuardDuty consumes. Use custom log formats rather than the default — the extra fields cost nothing and answer questions the default cannot.
Object-level request logging for buckets. Worth enabling on anything holding regulated data, because CloudTrail data events and S3 access logs answer subtly different questions.
On the checklist as an edge-protection control, not just a cache. Terminating traffic at the edge is where WAF rules and TLS policy get applied before anything reaches your origin.
Application-layer filtering in front of CloudFront, an Application Load Balancer or API Gateway. Start from the AWS managed rule groups rather than writing rules from nothing.
DDoS protection. The standard tier is already on for everyone; the decision this page helps with is whether the advanced tier’s response team and cost protection are worth it for your exposure.
The governance layer over WAF, Shield and security groups: define a policy once in the organisation and have it enforced in every account, including accounts created tomorrow.
Fundamentals, on the checklist because overly-open security groups remain one of the most common Config rule failures in practice. Referencing other security groups instead of CIDR ranges is the habit worth forming.
Where encryption governance lives. The governance lever is the key policy: it decides who can use a key, which is often a more meaningful boundary than who can reach the data.
A per-region setting that removes a whole class of finding permanently. Turn it on in every region you use, including the ones you think nobody uses.
When a customer-managed key is worth the extra cost over the default S3 encryption: when you need the key policy as an independent access boundary, and when you need the usage audit trail.
Managed TLS certificates with automatic renewal. On the checklist mostly because expired certificates are a self-inflicted availability incident, and this removes the failure mode.
Credential storage with built-in rotation. The reason it earns its cost over a plain parameter store is rotation — a secret nobody ever rotates is a credential with an indefinite blast radius.
Conference sessions, product walkthroughs, playlists and hands-on workshops. Some of these are dated — consoles have moved on and features have been renamed — but the architectural reasoning in a good re:Invent session ages far better than its screenshots.
A sequence of short walkthroughs covering landing zone launch and the first configuration steps. Better than one long session if you want to watch just the part you are stuck on.
The identity half of a landing zone, demonstrated end to end. Note the service is now called IAM Identity Center — the mechanics shown are unchanged.
Timestamped straight to the Service Catalog portion, so you do not sit through the introduction. Good on the trade-off between a curated catalogue and letting teams bring their own templates.
A second cue point in the same session, covering how portfolios get shared across accounts. Pairs directly with the hub-and-spoke blog post on the provisioning tab.
The connector demonstrated from the requester’s side. Useful for showing a sceptical service-management team that this looks like a normal catalogue item, not a new tool to learn.
The Atlassian equivalent, including the part people usually forget: decommissioning through the same workflow that provisioned the resource.
Timestamped past the opening housekeeping. The framing of configuration as a continuously-evaluated stream rather than a periodic audit is the idea to take away.
The complete session. Worth the full hour if AWS Config is new to you, because it builds the multi-account aggregation story in the right order.
A year on from the session above, with more emphasis on automatic remediation. The natural follow-up once you have rules reporting and want them fixing.
The best single overview of how the Systems Manager capabilities fit together, which is exactly the thing the service documentation is worst at conveying.
A calmer, more demo-led introduction than the launch session. Good for the standards-checks side, which is where most teams get their first real value from Security Hub.
The original launch talk. Dated on features but genuinely useful on intent — why a normalised finding format was the design problem worth solving.
The ongoing playlist for this service category. The place to browse when you want to know what has changed since the course material was written.
Live shows with a chat window, which makes them the rare format where you can actually ask the service team a question. Schedules vary by region and time zone.
Past Twitch episodes, pre-sorted and filterable by show, series and level. More useful than the channel itself if you missed something specific.
The on-demand back catalogue of AWS-run technical webinars. Pitched deeper than a product page and shorter than a re:Invent session, which is often exactly the right depth.
Self-paced, hands-on labs you run in your own account. The closest thing to the classroom labs once your class-provided lab access expires — search it for Control Tower, Service Catalog and Config workshops.
Where to go next: the certification landscape, the digital-training platforms, hands-on lab environments, structured ramp-up paths, and the handful of course-logistics links that do not belong under any topic.
The hub: every certification, its level, and what it validates. Start here to work out which credential your role actually needs rather than collecting them in order. Also cited in the course without the trailing slash.
Per-exam detail: the official exam guide, the sample questions, and the domain weightings. The domain weightings are the most under-used study aid on the site — they tell you where the marks actually are.
Official preparation resources gathered in one place — exam guides, official practice question sets, and the free preparation courses. Use this instead of third-party question dumps of unknown provenance.
Test centre versus online proctored, and the requirements for each. Check the online-proctoring room and identification rules before booking — they are stricter than most people expect.
Certifications expire. This page explains the renewal window and which paths count towards it — worth reading the day you pass, not the month before you lapse.
The digital learning catalogue: free courses, subscription content, official practice exams and the game-based Cloud Quest tracks. The natural next stop after a classroom course.
The platform landing page, cited on the course’s digital-training slide. Sign in here if a deep link into a course sends you to a login wall.
Guided labs in a real, temporary AWS account that AWS pays for. The same delivery platform the three labs in this course run on, so the experience will already be familiar.
The overview of what is available online and what it costs. Cited twice in the course, once as the general starting point and once specifically as the route into Skill Builder.
Instructor-led offerings, including the courses that follow on from this one. Useful if the value you got today was the room and the questions rather than the slides.
One-page curricula per role and per domain, sequencing free and paid content into a defensible order. The security ramp-up guide is the direct continuation of this course.
The legacy training portal address, which now redirects into the current platform. Kept because the course material still references it and old bookmarks still point here.
The blog index across every channel. For this course the two that matter are Management & Governance and Security — most of the blog links elsewhere on this page came from those two. Also cited without the trailing slash.
Vetted, deployable reference implementations — usually a CloudFormation template plus an architecture document. Check here before building a governance capability from scratch; someone has often published it already.
Enablement material on the lab platform itself, aimed at people delivering the course rather than taking it. Included for completeness — access is restricted.
Where the digital course books are redeemed and read. You need the access code from your instructor — the site is not useful without it.
The support route for lab access problems, exam voucher issues and certification account queries. Every module of the course closes by pointing here, which is a fair signal of how often it is needed.