The structural heart of the course. If it is always Day 1 — a new team, a new workload, a new business unit — then hand-building accounts is a losing race. This module builds the multi-account pattern, hands it to AWS Control Tower to automate, centralises who can sign in where, and vends new accounts that are compliant before anyone logs into them.
"Day 1" is not the day you signed up for AWS. It is the state you never leave. There is always a person to onboard, a workload to stand up, a resource to hand out, or a business unit arriving with its own compliance obligations. The question this module answers is not how do I do these things — you already know how. It is how do I do them the hundredth time, in a way that is identical to the first time, without a human checking the work.
A new engineer needs access to the right accounts and nothing else. Where that runs through an approval chain and a ticket queue, the delay is not a security control — it is just a delay.
A new workload arrives and needs somewhere to live. If "somewhere" is decided case by case, no two environments end up alike, and nobody can describe the estate accurately.
Provisioning by hand means no baseline is applied automatically. Nothing enforces the encryption default, the logging default, or the spend ceiling — so those become optional in practice.
A whole division arrives, and it has to land correctly on the first attempt — security requirements met, compliance obligations met, spend visible. Retrofitting governance onto a live business unit is the expensive version of this.
Governance at scale runs as a loop: implement, then provision, then operate, then round again. Module 2 owns the first leg. Implementing means building the multi-account foundation once, from a blueprint, so that provisioning and operations have somewhere predictable to happen.
Create and automate a landing zone. Decide the account boundaries, the shared services, where identity lives, and which controls attach where. Done once, correctly, so the other two legs inherit it.
Let builders help themselves from a catalogue of pre-approved products, inside the boundaries the landing zone established.
Record configuration, evaluate it against rules, alert on drift, remediate. Then feed what you learn back into the implement stage.
A single account is a perfectly reasonable place to start and a genuinely bad place to stay. Five separate pressures push in the same direction, and each one on its own is usually enough to justify the split.
Teams sharing one account share one blast radius and one bill. Visibility blurs and accountability follows it. Separate accounts turn "who changed this" into a question with an obvious answer.
Development, staging and production have genuinely different risk appetites. Keeping them in one account means the weakest of the three sets the real security posture.
Some applications need controls the rest of the estate would find intolerable. Giving the regulated workload its own account means you can point an auditor at exactly one boundary — a PCI DSS scope of one account is a scope you can actually defend.
Business units and product lines have their own approval paths, their own change windows and their own lifecycles. Account boundaries let those differ without negotiation.
You cannot cleanly split spend inside one account. Tagging helps and tagging leaks. An account is the only boundary that gives a business unit, team or workload a number nobody argues about.
Put the five drivers together and you have a design pattern, not a preference. Group accounts into organizational units by the policies they need — not by the shape of the org chart.
A is correct. Nothing forces MFA on vended accounts, which is exactly why it belongs on your baseline. Apply it to the root and management accounts first, then everywhere else.
C is correct. These three are the reasons the pattern exists: different security profiles need different homes, isolation keeps teams from tripping over each other, and billing separation gives each unit a real number.
B is wrong because those four are the floor, not the design. Stopping there means you have a management structure with no workload separation. D is wrong — the driver is policy diversity, not headcount. E is wrong; automation is the entire point of the module.
A landing zone is a well-architected, multi-account environment built from a blueprint rather than assembled by hand. Think of it as an enterprise-wide container holding your organizational units, your accounts, your people, and everything subject to a compliance regime. The management account sits at the root. Everything else hangs off it, grouped by the policies it needs.
Before you think about where workloads go, build the two groupings that hold the estate together. These are the accounts nobody deploys an application into — they exist so that everything else can be observed and connected.
Log archive account. One repository for API activity and resource configuration history from every account in the zone. Centralising it here means a member account cannot quietly erase evidence of its own behaviour — the record lives somewhere its owner cannot reach.
Audit account. Deliberately restricted, and deliberately programmatic. It grants security and compliance teams read and write reach across the zone without offering a way to sit down and click around inside another account. It is also the natural delegated administrator for GuardDuty and Security Hub, and the home of the Config aggregator.
Network account. Shared connectivity lives once, not per team. Transit Gateway for inter-VPC and hybrid routing, Direct Connect for the private link back to your own data centre. The alternative — every account peering with every other account — scales quadratically and audits terribly.
Shared services account. Hosts the hub portfolio for AWS Service Catalog and the common code repositories. This is where a curated product exists once and is shared outward, rather than being copied into every workload account and drifting.
The workload groupings are where the isolation argument gets cashed in. Match them to the level of separation you actually need — which, for most organisations, means matching them to the software development lifecycle.
| Grouping | What lives there | Why it is separate |
|---|---|---|
| Sandbox | Individual developer playgrounds. Throwaway work, spikes, learning. | People need somewhere to be wrong. Isolating that keeps experimentation from becoming an incident, and lets you attach a much tighter spend ceiling than production would tolerate. |
| Workloads_SDLC | Development, test and pre-production accounts for real applications. | Same code as production, different data and different blast radius. Promotion between accounts becomes an explicit step rather than a change of tag. |
| Workloads_Prod | Live, customer-facing member accounts. | The tightest controls in the estate attach here, and only here. Nothing that has not survived the SDLC accounts gets in. |
| Workload_Shared_Services | Spoke portfolios, per-workload baselines, detective controls, security service members. | The pieces every workload account needs but no single workload team should own. |
Every account emits CloudTrail events and Config configuration items. Those travel inward to the log archive account, landing in an S3 bucket that Control Tower provisions for the purpose. You can add your own buckets there for other log sources. The result is a single source of truth for account activity, which is the difference between an audit you can answer and one you cannot.
Connectivity travels outward from the network account. On-premises traffic arrives over Direct Connect, joins Transit Gateway, and reaches sandbox, SDLC and production accounts through routes the network team controls centrally. Builders get connectivity without being handed the ability to redesign it.
Setting up a landing zone is normally a once-per-organisation event, which is exactly why it is worth getting right. Control Tower does the heavy assembly — the OUs, the shared accounts, the identity store, the initial controls — but there is a short list of things it cannot do on your behalf, and a set of checks it will run against your management account before it starts.
An existing AWS account is fine; you do not need a fresh one. What you do need is discipline about the root user. Sign in as root only for the handful of tasks that genuinely require it, then put those credentials somewhere retrieving them is a deliberate act.
Day-to-day setup work happens as an administrative identity, not as root. This is the identity that will actually run the landing zone deployment.
Every administrative user involved in building the landing zone gets multi-factor authentication before they touch it. A second factor on the identity that can define your controls is not optional in any serious environment.
Control Tower uses them to provision the two shared accounts: one for audit, one for log archive. They must be addresses not already tied to an AWS account, and they should belong to the people who genuinely own auditing and log management — not to whoever happened to run the setup.
Control Tower validates the management account before it provisions anything. These run for both brand-new organisations and existing ones. Knowing them ahead of time turns a failed deployment into a five-minute prerequisite.
Most real deployments are not greenfield. You already have AWS Organizations, you already have accounts, and people are already working in them. Control Tower can be set up alongside that.
Setup does not restructure or automatically enrol what you already have. Existing OUs stay unregistered until you choose to register them, which lets you adopt governance one grouping at a time instead of all at once.
The audit and log archive accounts are created and become part of your existing organisation. Everything rolls into one bill, so unified billing arrives whether or not you had it before.
Account administration moves to a single management account, and control application and enforcement covers new and existing accounts alike once they are enrolled.
Once the landing zone exists, the Control Tower console is the single place governance is visible. Five areas are worth a tour on day one.
Multiplying accounts multiplies the sign-in problem. Twenty accounts with local IAM users is twenty places to offboard someone from, and twenty chances to miss one. IAM Identity Center exists to make workforce access a single administrative surface: connect or create your people once, then assign them into accounts from one place.
Identity Center extends IAM with a central place to administer users and their access across every account in the organisation, plus cloud applications. A new landing zone comes with it enabled and a directory ready to use.
You do not assign permissions to people. You put people in groups, and groups get permission sets in specific accounts. When someone changes role, you change one membership.
The AWS access portal is the single front door — console, CLI and supported SaaS applications all behind one authentication event. The AWS Single Sign-On name is retired; the single-sign-on behaviour is not.
Control Tower creates a set of preconfigured groups for the tasks a governed organisation actually needs performed. The point of reading this table carefully is that the same group name means different things in different accounts — that asymmetry is the design, not an accident.
| Group | Where it applies | What a member can do |
|---|---|---|
| AWSControlTowerAdmins | Management, log archive, audit, member | The only group with access to the Control Tower console itself, via administrator access in the management account. Administrator in the log archive and audit accounts; full Organizations access in member accounts. |
| AWSAccountFactory | Management account only | Provisions new accounts through Account Factory, using end-user access to Service Catalog. This is the group that vends accounts — and nothing else. |
| AWSServiceCatalogAdmins | Management account only | Makes administrative changes to Account Factory. Notably cannot provision accounts unless also in AWSAccountFactory — a deliberate separation between changing the vending machine and using it. |
| AWSSecurityAuditPowerUsers | Every account | Power-user access: create and configure resources and services for application development work, but not user and group management. |
| AWSSecurityAuditors | Every account | Read-only across all services and resources. This is the group you add a third-party auditor to for the duration of a review. |
| AWSLogArchiveAdmins | Log archive account | Administrator access, scoped to the log archive account alone. |
| AWSLogArchiveViewers | Log archive account | Read-only access to the log archive account. Enough to investigate, not enough to alter the record. |
| AWSAuditAccountAdmins | Audit account | Administrator access, scoped to the audit account alone. |
A permission set is a named collection of policies that Identity Center uses to work out a user's effective permissions in a given account. Groups say who; permission sets say what; the assignment binds them to a where.
| Permission set | Grants |
|---|---|
| AWSServiceCatalogEndUserAccess | Enough to provision new accounts through Account Factory in the management account. Consumer of the catalogue, not owner of it. |
| AWSServiceCatalogAdminFullAccess | Administrative changes to Account Factory. Holding this alone still does not let you provision an account — AWSAccountFactory membership is also required. |
| AWSPowerUserAccess | Full access to AWS services for building things, without the ability to manage users and groups. |
| AWSAdministratorAccess | Administrator rights within the account it is assigned in. Used by the Control Tower, log archive and audit admin groups. |
| AWSReadOnlyAccess | Read-only across all services and resources. The auditor and log-viewer posture. |
Identity Center cannot assign access to a user it has never heard of. Before any assignment exists, the users and groups have to be present in Identity Center — and there are three routes to that.
Use the built-in identity store. Fine for a small platform team, a workshop, or an organisation with no existing corporate directory. It becomes a second place to offboard from once you do have one.
This is the target state. SAML 2.0 handles authentication: your identity provider issues an assertion, Identity Center consumes it, and the user lands in the access portal without a second password. SCIM handles the population problem — the provider pushes users and groups into Identity Center and keeps them in step as people join, move and leave. Microsoft Entra ID and Okta are both tested against the SCIM implementation.
Where the provider has no SCIM support, you still get single sign-on, but you maintain both the users and the groups manually in the Identity Center console. Workable, and the mode where a leaver most easily gets missed — so pair it with a scheduled reconciliation.
Account Factory is a vending machine for AWS accounts. An administrator loads it once with a pre-approved baseline; after that, getting a new account stops being a project and becomes a request. The thing it prevents is account sprawl — accounts and identities multiplying without a consistent baseline, each one widening the surface an attacker can work with.
Walk the pipeline below. The first five steps happen once, on the administrator side. The sixth happens every time somebody needs an account.
The end user filled in a short form. What comes back is not an empty account — it is an account that is already governed, before anybody signs into it.
A pre-agreed VPC layout with the CIDR range, subnet structure and Region set from the standard the platform team chose. No blank-canvas networking decisions taken under time pressure.
CloudFormation StackSets land the standard IAM roles, the CloudTrail and Config wiring back to the log archive, GuardDuty and Security Hub membership, and the spoke Service Catalog portfolios.
The account is placed in an OU, so it inherits every control attached to that OU and everything above it. Mandatory controls are active from the first second of the account's life.
The pipeline above is the mechanism. There are three doors into it, and which one you use depends on whether a human or a system is asking.
The Enroll account flow. Best for one-off requests and for bringing an account that already exists under governance.
Landing-zone setup creates a Service Catalog portfolio containing the Account Factory product. Launching that product provisions a governed account and applies the network baseline. This is the door end users see.
Call it programmatically from the management account. This is how account creation becomes a step in a pipeline rather than a ticket — onboarding a new team triggers an API call, not an email.
A control is a high-level rule that keeps governing after you stop paying attention. Controls come in two behaviours and three guidance tiers, and the two axes are independent — a control can be preventive and elective, or detective and mandatory. Getting this grid straight is the single most transferable idea in the module.
A preventive control keeps accounts compliant by disallowing the actions that would break compliance. The API call does not partially succeed and get rolled back; it is denied. Because the denial happens in the authorisation path, there is no window during which the estate is wrong.
A detective control discovers non-compliance that already exists inside an account and raises it on the dashboard. It does not stop anything. In exchange it can evaluate things a policy decision cannot see — the resulting state of a resource, rather than the API call that produced it.
Guidance is advice about where to attach a control, and it is orthogonal to whether the control prevents or detects. The practical consequence sits in the last column.
| Tier | What it means | On by default in a new landing zone? |
|---|---|---|
| Mandatory | Always enforced. These are the rules Control Tower considers non-negotiable for a governed environment — protecting the integrity of the log archive, for instance. | Yes — enabled automatically, and OUs created through Control Tower get them applied without you asking. |
| Strongly recommended | Common practice for well-architected multi-account environments. Sensible almost everywhere, but AWS will not assume your situation on your behalf. | No — you turn these on deliberately. This is the tier people most often assume is automatic. |
| Elective | Lets you track or lock down actions that enterprises commonly restrict. Useful, but genuinely situational — plenty of organisations legitimately want the opposite. | No — opt in per OU as your requirements dictate. |
Take a concrete requirement: nobody deletes an S3 object or bucket without having presented a second authentication factor. As a preventive control that is one service control policy, and it is short enough to read line by line.
Deny. Remember what an SCP is: a ceiling on what identity policies can grant, not a grant itself. An SCP alone never gives anyone permission.
BoolIfExists on aws:MultiFactorAuthPresent equal to false means the deny bites only when the request demonstrably arrived without MFA. Present a second factor and the same call proceeds.
Now a requirement a policy decision genuinely cannot express: every S3 bucket should have versioning turned on. Versioning is a property of a bucket's state, and state is what AWS Config evaluates. This control is elective and sits in the data-security category.
ConfigRuleName, declared as a string. Parameterising the name is what lets one template be reused across OUs and environments without editing it.
CheckForS3VersioningEnabled is your name for the resource inside the stack. CloudFormation uses it for references and for change tracking; pick something a reader understands.
AWS::Config::ConfigRule. The control is literally a Config rule resource — nothing bespoke, nothing hidden.
!Sub intrinsic function, which substitutes the parameter value at deploy time. This is the mechanism that makes the template generic.
Owner: AWS means this is an AWS-managed rule, so you do not write or maintain the evaluation logic. SourceIdentifier selects which managed rule — here, the one that checks bucket versioning. Set Owner to a custom value instead and you supply your own Lambda function.
The catalogue is organised by category, and reading a few from each is the fastest way to calibrate what a control is for.
Block EC2 instance types that are not EBS-optimised, so storage traffic stops competing with everything else on the instance. Block EBS volumes left unattached, so storage does not outlive the instance it was created for — a cost control and a data-retention control at the same time.
Refuse internet-facing RDP and SSH. Unrestricted remote console access from anywhere is the single most reliable way for a server to become somebody else's server.
Refuse policy changes to the log archive bucket, so nobody can quietly widen or narrow access to the audit record. Send CloudTrail events into CloudWatch Logs so activity data can be analysed as it happens rather than at quarter end.
Refuse access for IAM users without MFA, and specifically refuse console access without MFA. A password plus a second factor is a materially different security posture from a password.
B is correct. Mandatory controls arrive with the OU. You do not enable them and you cannot forget them.
D is correct. A vended account inherits whatever is attached to the OU it lands in, and to everything above that OU. This is why the placement decision matters more than any per-account configuration you might do afterwards.
A is wrong on one word: strongly recommended controls are not enabled by default. Only mandatory controls are. That single assumption is the most common misreading of the tiers, and it produces environments people believe are more governed than they are. C is wrong — "default" and "selective" are not tiers; the three are mandatory, strongly recommended and elective. E is wrong for the same reason as A.
Fn::SubIf you remember five things from the largest module in the course, these are the five. Everything in the afternoon assumes them.
Governance at scale is not a stricter version of governance. It is governance expressed as where a thing sits rather than what someone remembered to do to it. An account is compliant because of the OU it landed in. A control applies because it was attached one level up. A user has access because of a group membership. Every one of those is a property of structure, and structure is the only thing that survives growth.
This module showed you that Account Factory is a Service Catalog product. M03 takes the lid off Service Catalog itself — portfolios, products, template versions, and the launch constraints that let a builder deploy something using permissions they do not personally hold. It is the same machinery, pointed at workloads instead of accounts.
The diagram on the Landing zone tab is fixed. This one is not. Add OUs, place the shared accounts, attach a control at a level of your choosing, and watch inheritance cascade — which answers the question a static architecture slide cannot: what actually changes if I move this control one level down?
This is the module the last two years have been hardest on. The reasoning behind it holds up entirely — you still want a blueprint rather than a hand-assembled estate, and you still want controls that keep working after everyone stops paying attention. What changed is the packaging. Control Tower stopped being an all-or-nothing landing zone deployment, the control library it draws from grew by hundreds of entries, and the identity layer underneath it became multi-Region. Read this tab as a set of corrections to the mechanics, not to the argument.
You can now reach AWS managed controls directly, without deploying a full Control Tower landing zone. Over 750 managed controls can be enabled from the Control Catalog into your existing AWS Organization, and Control Tower no longer requires a mandatory organizational unit structure — you keep the account and OU layout you already have. The Config and CloudTrail integrations were also pulled apart, each getting its own S3 buckets and SNS notifications, which makes permissions and cost attribution per-integration rather than one shared pile.
The v4.0 release does not remove anything. If you want the whole blueprint — the OUs, the shared log archive and audit accounts, the guided setup on the Control Tower setup tab — that path is still there and still the fastest way to stand up a greenfield organisation.
Why it matters here The Landing zone and Control Tower setup tabs both frame this as a single decision: adopt Control Tower and accept its structure, or govern by hand. That trade-off has been unbundled, and it is genuinely good news for the room. The most common objection to Control Tower in a mature organisation was never the controls — it was “we already have 200 accounts in an OU tree we designed, and we are not re-parenting them.” You can now take the control library and leave the structure alone. When you work through the landing zone composer, treat the OU hierarchy and the control set as two separate choices rather than one package.
Enabling a detective control used to mean Control Tower pushing a CloudFormation StackSet out to every account and Region in scope. Those controls are now implemented as service-linked AWS Config managed rules, which lands them across accounts and Regions considerably faster. The trade is that a service-linked rule can only be changed through Control Tower — you cannot reach in and edit it as an ordinary Config rule.
Why it matters here The Control types tab walks the detective chain as granular policy, Config rule, OU, accounts — and the Account Factory tab describes StackSets as the delivery vehicle for the account baseline generally. For Control Tower’s own detective controls that delivery step is no longer a StackSet. Two practical consequences: enablement across a large organisation is no longer a coffee-break operation, and if someone in Lab 3 goes looking for a Control Tower detective control in the Config console expecting to tune its parameters, they will find it read-only, and correctly so. Control Tower owns it.
Turn on the automatically enroll accounts flag in Landing Zone settings — or pass it through the CreateLandingZone / UpdateLandingZone API — and an account dragged into a registered OU is enrolled as a consequence of the move. It is opt-in, not the default.
Why it matters here The Account Factory tab makes the point that governance has to be a property of the vending pipeline rather than a step someone remembers. Enrollment on OU move extends that to accounts which did not come from the factory — the migrated ones, the acquisitions, the account someone opened with a corporate card in 2019. The OU becomes the single act that confers governance, which is exactly the model the Landing zone tab argues for.
A single page listing the controls enabled across the Control Tower organisation, rather than requiring you to walk each OU and read its control list.
Why it matters here Small feature, large teaching value. The gap between the control set you designed and the control set that is running is where governance quietly fails, and the governance lifecycle deep dive is entirely about closing that kind of gap. This is the console page you point an auditor at.
The Asia Pacific (New Zealand) launch brought the total to 35 Regions, GovCloud (US) included. Existing customers extend governance into a newly supported Region by updating their landing zone settings rather than redeploying.
Why it matters here Region coverage is a governance input, not a footnote. An account operating in a Region your landing zone does not govern is an ungoverned account with a plausible-looking dashboard, which is why Region pinning shows up as a preventive control in the first place. Check the supported list against where your workloads actually run before you promise organisation-wide coverage.
The catalog is the shared library that Control Tower, and now CloudFormation Hooks over in M03, both draw from. It is where the interesting movement has been.
The catalog gained 279 additional AWS Config managed rules and seven new compliance frameworks: ACSC-Essential-Eight-Nov-2022, ACSC-ISM-02-Mar-2023, AWS-WAF-v10, CCCS-Medium-Cloud-Control-May-2019, CIS-AWS-Benchmark-v1.2, CIS-AWS-Benchmark-v1.3 and CIS-v7.1.
The quieter half of the announcement is the more interesting one. ListControlMappings was enhanced to show where a Config rule and a service control policy cover the same requirement — a detective control and a preventive control pointing at one obligation, discoverable through an API call.
Why it matters here The Control types tab asks you to reason about preventive versus detective as a design choice, and the interception-point deep dive turns that into an exposure window. Until now, pairing the two for a given requirement was manual archaeology across two consoles. Being able to query the mapping means you can ask “which of my detections have no matching prevention?” and get an answer instead of an opinion.
Security Hub contributed 176 additional controls, filterable in the catalog by Control owner set to AWS Security Hub, and reachable through the ListControls, GetControl and EnableControl APIs like any other catalog entry.
Why it matters here This is the seam between this module and M04. The course introduces Security Hub as a findings aggregator sitting downstream of everything else; here its control library becomes something you enable from the same catalog, through the same API, as a Control Tower control. One vocabulary and one enablement path across preventive and detective is a meaningful simplification of the picture the Control types tab draws.
Set aft_customization_triggers = ["account_move"] and AFT re-runs an account’s customizations after it moves between OUs, skipping the bootstrap and provisioning stages so the run is quick. Individual accounts can be held back with account_skip_customization_triggers = "true". The same release added custom workspace naming for Terraform Cloud and Enterprise, tightened access to the AFT logging bucket, and improved scaling for large Enterprise Support enrollment runs.
Why it matters here The Account Factory tab treats the baseline as something applied at vending time. That leaves a hole the moment an account is re-purposed — a sandbox promoted into the production OU inherits the new OU’s policies immediately, but nothing re-runs the customizations that make it look like a production account. Pair this with automatic enrollment above and an OU move becomes a complete re-baselining rather than a policy change with an account-shaped gap behind it.
AWS Transform can now build the landing zone itself inside a migration workflow — you customise the OU hierarchy, the accounts and the SCPs, then choose between agent-managed deployment or generating infrastructure as code as CloudFormation, CDK, or Landing Zone Accelerator templates.
Why it matters here Worth flagging for anyone whose real starting point is a data centre rather than an empty organisation. The Always Day 1 tab argues that the estate never stops arriving; migration is the most concentrated form of that. The IaC output is the part to note — a landing zone you can read, review and re-apply is a different artefact from one that was clicked into existence, and it is what makes the closed-loop model possible at all.
An organization instance can replicate from its primary Region into additional Regions — 17 commercial Regions are supported, and a multi-Region customer managed KMS key is required. February 2026 covered instances connected to an external identity provider; July 2026 extended the same capability to instances using the Identity Center directory itself. Identity Center remains free; the KMS key is billed as normal.
Why it matters here The Identity tab presents the access portal as a single front door, and the Control Tower setup tab lists the Identity Center home-Region match as the most common blocker on an existing account — both written when an instance was a single-Region thing. Replication changes the resilience conversation: if you have thought about what happens when workforce sign-in is unavailable while every workload is healthy, this is the answer, priced at one multi-Region customer managed key. It does not change the home-Region rule for a Control Tower deployment, so plan the primary Region as carefully as before.
New organization instances can be created without the account-access capability. With it disabled, Identity Center does not provision its service-linked role into member accounts at all, which narrows the access surface for organisations using it purely for application assignments. It can be switched on later from instance settings or through UpdateInstance.
Why it matters here The Identity tab presents Identity Center as the thing you use to hand out account access, and for most people in the room it will be. But least privilege applies to the governance tooling too: a role installed in every member account for a capability you are not using is surface you did not need. Worth asking which of the two jobs you actually want it doing.
You can now assign IAM roles that already exist in your accounts to users and groups in IAM Identity Center, keeping a single federation point while continuing to use the roles you have. Available through the console, the SDKs and CloudFormation or CDK, in all commercial Regions, at no additional cost.
Why it matters here This removes the most common reason people stop halfway through centralising identity. The Identity tab’s argument is that twenty accounts with local IAM users means twenty offboarding surfaces — but the migration path used to imply rebuilding a carefully tuned role estate as permission sets before you saw any benefit. Now the roles stay and the sign-in consolidates, which is a much easier first step to get approved.
Every module page carries its own What’s new tab, scoped to the services that module owns. Organizations and the policy types are in M01, Service Catalog and CloudFormation Hooks in M03, and the detective stack — Config, Systems Manager, GuardDuty, Security Hub — in M04. If you read only one of the others, read M04: the service this course calls Security Hub has been renamed underneath us, and that is the change most likely to trip you up in your own console.