The title says preventive controls. The subject is AWS Service Catalog — and the argument is that the strongest control is the one builders actually want to use. Give people a short list of pre-approved products instead of a blank console, and compliance stops being a gate they route around.
The governance lifecycle has three legs. Module 2 built the foundation, which is the implement leg. Module 4 covers what happens after launch, which is operate. This module sits in the middle, on provision, and the middle leg is the one your builders touch every single day. Get it wrong and they will route around you.
Speed is not a single property. When an engineering team says it needs to ship faster, four separate dependencies are hiding behind that sentence — and provisioning touches all four.
Getting from an idea to something running, without a wait state in the middle. Every handoff to another team is a queue, and queues are where weeks go to die.
Teams move faster on technology they already recognise. A shared set of approved building blocks also gives two teams a common vocabulary, so a design review does not start from first principles.
The fastest compliance conversation is the one that happened months ago, when someone approved the pattern. If the environment ships pre-cleared, there is nothing left to argue about at release time.
Scaling and security failures usually trace back to a default nobody chose deliberately. Encoding the good default once removes a whole category of incident from the backlog.
Without governance at scale, those four dependencies collide with day-to-day reality. These three blockers show up together, because they share a root cause: nobody owns the provisioning path.
Clicking through the console, or filing a request and waiting on another team, is slow the first time and identically slow the fiftieth. Experimentation is the first casualty — when a spike costs a two-day wait, people stop spiking.
With no budget signal at the point of provisioning, a builder can launch something entirely reasonable in isolation that is completely unreasonable on the invoice. The discovery arrives 30 days later.
Tagging conventions and naming standards that live in a wiki page are suggestions, not controls. Every team implements a slightly different dialect, and cost allocation, ownership lookup and audit evidence all degrade together.
Meet Priya, a backend engineer at AnyCompany. She needs a server for an experiment, a database behind it, and network reachability for a demo. Watch her fail twice, in opposite directions.
Priya has her own development account with unrestricted self-service access. She signs in and the entire console is available — every service, every region, no signposting.
Root cause: access was granted, guidance was not. Permission is not the same thing as direction.
Now suppose Priya is conscientious and wants to get it right. She opens the console and immediately owes an answer to half a dozen questions she is not the right person to answer.
Root cause: the decisions were pushed to the person with the least context. She guesses — competently, probably — and the guess becomes production.
Not more permissions, and not fewer. She needed the decisions pre-made by the people who own them, expressed as a small set of things she can launch herself. That is the shape of the answer, and it has a name.
One place where an organisation publishes the AWS resources it has already agreed are acceptable, grouped so that each audience sees only what applies to them. It is a small idea with an outsized effect, because it moves the compliance decision from launch time to design time.
The phrase "service catalogue" comes from the IT Infrastructure Library, where it means a structured, published set of services that an IT function makes available — along with how each one is deployed and maintained. Most large organisations already run something like this for laptops, VPN access and database instances. Very few extend it to cloud infrastructure, which is exactly where the gap opens.
AWS Service Catalog is that construct applied to AWS. Central teams register what is deployable, decide who may deploy it, and retain the ability to change it later. Builders get self-service inside those lines. Nobody has to choose between governance and speed, because the governance was expressed as the fast path.
A portfolio is not restricted to plain AWS services. Three sources feed it, and the consumer cannot tell them apart at launch time — they all look like products.
Compute, storage, database, networking — described as infrastructure as code and pre-configured for your environment rather than left at defaults.
Third-party software your organisation has already procured and vetted, published into the catalogue so it arrives through the same governed path.
Internal patterns your platform team maintains — the standard service scaffold, the approved analytics stack, the compliant data-landing bucket.
Products are defined as code. CloudFormation templates in JSON or YAML are the common path; Terraform configurations are also supported, so a team already standardised on Terraform does not have to rewrite everything to publish into the catalogue.
The template says what gets built. Constraints say how far the consumer may bend it — security controls, validation on the parameters they can set, which IAM role does the launching, and tagging that is enforced rather than requested.
Take Priya from the previous tab and change one thing: instead of the full console, she opens a catalogue her organisation curated for developers.
| At launch time | Wide-open account | Curated catalogue |
|---|---|---|
| What she sees | Every service in every region, undifferentiated. | A handful of products scoped to her role and team. |
| Configuration decisions | Hers, all of them, made under time pressure. | Already made by the owners; she supplies only the parameters she is the right person to supply. |
| Compliance posture | Unknown until someone checks. | Known before she clicked, because the pattern was approved when it was published. |
| Tagging | Whatever she remembers to type. | Applied by the product, consistently, every time. |
| Cost visibility | Arrives with the monthly bill. | Attached to the product or portfolio as a budget, before provisioning. |
| Patch and version story | Per-instance, ad hoc, undiscoverable. | Tracked, because the product is versioned and the deployment is a known stack. |
Useful as a review checklist when someone proposes an internal provisioning portal — catalogue-based or otherwise.
Entitlement follows the role. A data scientist and a payments engineer should not be looking at the same product list, and neither should see the union of both.
Everything on offer already satisfies your security rules and your compliance regime. Alignment is a property of the catalogue, not a task assigned to the consumer.
Usage, product version and cost are all visible after the fact — including patch state. Self-service without this is just faster sprawl.
These words get thrown around loosely in design discussions, and the looseness causes real confusion — particularly the difference between a product and a provisioned product, and between a constraint and a service control policy. Worth being pedantic here; the rest of the module depends on it.
One IT service you have made available for deployment, made of one or more AWS resources managed as a single unit — compute, volumes, databases, monitoring configuration, networking, or a packaged AWS Marketplace item. Note the plural: a product is usually several resources that only make sense together.
A collection of products plus the configuration information around them. Critically, a portfolio is where you express who may use those products and how. Build one per audience type rather than one giant shared portfolio — the audience split is the point.
Granting a principal access to a portfolio lets them browse it and launch what is inside. Ordinary IAM controls who can view and who can modify the catalogue itself — so the ability to consume and the ability to curate are separable, and should be separated.
The definition underneath a product: which resources exist, how they relate, and which parameters the consumer is allowed to supply at launch — security group choices, key pairs, sizing inputs. Everything not exposed as a parameter is a decision you have taken away, deliberately.
Rules governing how the product's resources may be deployed. Use them to cap what a consumer can pick (which instance types are launchable), to satisfy a governance requirement, or to hold cost down. Constraints attach to a product within a portfolio, so the same product can be constrained differently for different audiences.
The running instance of a product — which is to say, a CloudFormation stack. The product is the recipe; the provisioned product is the meal. It has a lifecycle: it can be updated to a newer product version, and it can be terminated, which tears down the stack.
A product can carry multiple versions in the catalogue. Publish a new version and it becomes available to everyone entitled to the portfolio — no re-entitlement step. Keeping older versions around is not clutter; it is how you reproduce a defect that only appears on last month's template.
| Confused pair | The difference that matters |
|---|---|
| Product vs provisioned product | A product is a definition sitting in a catalogue costing nothing. A provisioned product is a live CloudFormation stack with real resources and a real bill. One product can have hundreds of provisioned products derived from it. |
| Portfolio vs product | A portfolio is not a folder. It is the entitlement boundary — access is granted at portfolio level, never per product. If two audiences need different access to the same product, that is two portfolios. |
| Constraint vs service control policy | An SCP is an account-wide ceiling on what any principal in the account can call, enforced by AWS Organizations. A constraint is narrower and lives inside the catalogue: it shapes one product's deployment for one portfolio. They are complementary, and both are preventive. |
| Template parameter vs constraint | A parameter is a question you chose to ask the consumer. A constraint restricts the answers that question will accept. Exposing a parameter with no constraint is how "pick any instance type" quietly gets shipped. |
| Launch constraint vs consumer permissions | A launch constraint names the IAM role the catalogue assumes when it builds the stack. The consumer does not need that role's permissions themselves — which is precisely why they can launch a compliant database without holding database-creation rights. |
A supporting term the slide list leaves implicit. Tag options are administrator-defined key/value pairs available on a portfolio or product, applied to whatever the consumer provisions. They matter for two reasons that both bite later:
The pattern generalises: anything you would otherwise write in a runbook as "remember to…" is a candidate for encoding in the product.
Pick one. The answer and the reasoning appear underneath.
Service Catalog only has two kinds of user, and they never do each other's job. Administrators author and entitle; end users browse and launch. Switch between the two views below, click any step to read what happens and who is doing it, or let it walk itself.
Authority over templates, products, portfolios, constraints and entitlement. Also the IAM role named in the launch constraint — the role with real permission on EC2, RDS, S3 and everything else the product creates. Administrators additionally manage the roles attached to products for advanced resource management.
Permission to browse an entitled portfolio and launch from it. That is frequently the whole permission set. They may also be allowed to manage the resources their products create, or restricted to specific features — it varies by operational need, and it should.
When you publish a new product version it becomes available immediately to everyone entitled to the portfolio — no re-entitlement, no announcement required. The instinct is then to retire the previous version to keep the list tidy. Resist it for a release or two.
When a consumer reports that "it worked last week", the fastest diagnosis is launching the previous version side by side and comparing. Retire versions on a schedule, not on the day you ship the replacement.
Two things happen once you accept the catalogue model. First, you notice you have already been using it — Account Factory is a Service Catalog product. Second, you need it in more than one account, which is what the hub-and-spoke model solves.
Module 2 introduced Account Factory as the thing in AWS Control Tower that vends new accounts. It is worth restating in this module's vocabulary, because the restatement is genuinely useful: Account Factory is a product, in a portfolio, in AWS Service Catalog. Control Tower creates both when you set up the landing zone.
Everything on the vocabulary tab therefore applies to it. It has a template. The template takes parameters. It is versioned. It has a portfolio with entitlement. Launching it produces a provisioned product — which in this case happens to be an entire AWS account rather than an EC2 instance.
Six steps. The first five are administrator-side and happen once, when the landing zone is established. Only the last one is a person asking for an account.
Standing up the landing zone quietly creates an Account Factory portfolio in Service Catalog. Most teams do not notice this on day one, then find it later and wonder who made it.
Control Tower publishes the product itself. You did not author this template; AWS did. Which is why account vending works before you have written a single line of infrastructure code.
A JSON or YAML template defines the questions asked at provisioning time and what to do with the answers. Same mechanism as any product you would write yourself.
Because the template is versioned, any update — including the automatic update when you add an organisational unit — results in a new version rather than a silent in-place edit. Your provisioning history stays legible.
The stack provisions what the product needs — account baseline, network baseline — and is also how deployment across multiple accounts and regions is expressed.
The only end-user step. You can launch it straight from Service Catalog, but the recommended route is the Enroll account path in Control Tower — it keeps Control Tower's own view of governance consistent with reality.
A catalogue that only exists in one account is a demo. In a real organisation the people who curate products and the people who consume them are in different accounts, often dozens of them. AWS Organizations sharing is what closes that gap — you manage from the hub instead of managing each spoke.
Products and portfolios are defined once in the hub. In a Control Tower environment the management account is the natural hub — it is already where landing-zone decisions live.
AWS Organizations sharing pushes portfolios out to spoke accounts. A change made in the hub reaches every spoke; there is no per-account copy waiting to fall out of date.
Developers, data scientists and platform engineers sign in to their own account — or hit the API, or the CLI — and the right products are simply there.
Cost usually gets filed under finance, which is why it arrives too late to prevent anything. Attach a budget to a product or a portfolio and it becomes a control that sits alongside the security constraints — same catalogue, same enforcement point, same moment.
These catch people out, because they live in AWS Billing and Cost Management rather than in Service Catalog. Budgets simply will not appear against your products until all three are done.
Do this in the AWS Billing and Cost Management console. Until a user-defined tag is activated it exists on your resources but carries no weight in cost reporting — which makes it useless for attributing spend to a product. This is also where the tag options from the vocabulary tab pay off: consistent tags plus activated tags equals attributable cost.
An account-level switch. Without it, IAM permissions alone are not enough — the console stays closed regardless of policy, and administrators cannot see the budget state you are asking them to manage.
Then grant the actual permission to the people who need it. If you plan to use Amazon SNS for notifications, this is also the point to allow those users to create SNS notifications — optional, but you will want it the first time a threshold fires at 2am.
All four happen in the AWS Billing and Cost Management console. The association step is the one that connects a finance construct to a provisioning construct, and it is the one people forget.
Set the budget period and its recurrence — monthly, quarterly or annually — with an expiry date if the thing you are budgeting for is finite. Choose between a fixed amount tracked every month, or a different amount per period. Then set the number.
Add filters to narrow what counts. Attach an SNS notification for breaching the amount, or for a forecast that says you are going to. And optionally attach a budget action — see below.
Bind the budget to a product or to a portfolio. Skip this and you have created an ordinary account budget with no relationship to the catalogue — still useful, but not a provisioning control.
Once associated, budget state shows up on the object it is attached to. Product-level budgets appear on the Products and Product details pages; portfolio-level budgets on the Portfolios and Portfolio details pages.
| Decision | Options | How to choose |
|---|---|---|
| Delivery channel | Email, or an Amazon SNS topic. | Email for humans who will read it. SNS when you want the alert to reach a chat channel, a ticketing system, or a Lambda function that does something about it. |
| Actual or forecast | Alert on spend already incurred, or on projected spend for the period. | Forecast alerts arrive early enough to change behaviour, which is the whole point of a preventive control. Actual alerts are the backstop. Configure both. |
| Threshold form | An absolute value, or a percentage of the budgeted amount. | Percentages travel well across teams with different budget sizes. Absolute values are clearer when a specific number matters contractually. |
A single alert at 100 percent tells you the period is already lost. Multiple thresholds on one budget turn a binary event into a gradient — a quiet signal at 50 percent, a loud one at 90 percent, an action at 100.
AWS Budgets can run an action on your behalf when a cost or usage threshold is crossed. The action that matters most here applies a restrictive custom policy to a user, group or role — removing their ability to provision further resources of a given type.
Concretely: a sandbox portfolio at AnyCompany carries a monthly budget with an action attached. Cross the threshold and the policy that lets that team launch additional compute is replaced by one that does not. Existing workloads keep running; new spend stops. The team can still read, still operate, still deploy code — they just cannot enlarge the footprint until someone with authority intervenes.
Two published customer stories, the two supported ITSM connectors, and what to take away. GoDaddy and Verizon are named here because both are public AWS case studies — worth reading in full if you are building the business case internally.
The problem was speed of migration without abandoning their own reference architecture and governance model along the way. Their answer was a self-service portal that vends multi-account, pre-approved, preconfigured landing zones with deployable resources already attached.
The pattern to notice: they did not catalogue individual resources first. They catalogued the landing zone, then the resources inside it.
The goal was reducing developer effort while holding governance and security requirements, and thereby accelerating AWS adoption. They built governance controls onto the AWS Service Management Connector for ServiceNow — keeping the request experience where their developers already were.
The pattern to notice: they met the organisation where it was. The catalogue moved to the developers' tool rather than the other way round.
If your organisation already runs an ITSM platform as the standard front door for requesting anything, a new AWS-native portal is a hard sell. Three specific difficulties come up:
Secure, compliant, pre-approved AWS products need to appear inside the tool people already use — not beside it.
Approvals, fulfilment, and change records already exist. AWS provisioning has to slot into that process rather than bypass it.
Custom integration work is where these projects stall. Months of connector-building is a common way for a good idea to quietly die.
The AWS Service Catalog API lets practically any ITSM tool with integration capability talk to the catalogue directly. That is the general answer, and it is the right one if you run something bespoke.
For the two most common platforms there is a shorter path. AWS publishes the AWS Service Management Connector for ServiceNow and for Jira Service Desk, which removes most of the integration effort that item three above is worried about.
| Connector | What end users get | What administrators get |
|---|---|---|
| ServiceNow service-oriented enterprise service management |
Order, configure and operate AWS infrastructure from within the ServiceNow portal itself — travelling through the same request, approval and fulfilment flow as anything else in their catalogue. | Service Catalog for procuring, publishing and governing what is on offer. A configuration management database populated by AWS Config to track resources inside ServiceNow. Systems Manager to run automation playbooks against them. |
| Jira Service Desk collaborative ITSM for rapid service delivery |
Order, run and retire AWS infrastructure from inside Jira Service Desk, and close out AWS problems in the same place — no context switch into the AWS console to finish the ticket. | Service Catalog for pre-approved, secured, governed products. Systems Manager automation documents that raise Jira issues when a resource has a problem — and Config rules that call an automation document to resolve them. Resource state appears as a configuration-item view powered by AWS Config. |
Click any option to reveal all five verdicts and the reasoning.
The administrator workflow from tab four, done by hand. Create a portfolio, define a product, attach a launch constraint that limits what the product may do, grant an IAM role access to browse the catalogue, then switch hats and deploy from it as the consumer.
Everything on this page happens before launch. Module 4 is the other half: recording configuration with AWS Config, evaluating it against rules, acting on groups of resources with Systems Manager, and closing the loop with automatic remediation. Preventive controls narrow the failure modes; they do not eliminate them.
If the constraint-versus-SCP distinction on the vocabulary tab left you wanting the actual policy documents side by side, this is the page. Same governance intent expressed twice, plus an honest account of what each approach cannot do.
This module teaches two preventive mechanisms: a curated catalogue that only offers approved shapes, and a policy layer that refuses the API call. A third mechanism has since appeared between them — a control that fires during a CloudFormation operation, before any resource is created, and it is drawn from the same catalogue of AWS managed controls that supplies the detective rules in Module 4. That is the headline. The rest of the CloudFormation change is about failing earlier and more legibly, which is the same argument this module makes about developer friction.
The vocabulary tab draws a line between preventive and detective, and the interception-point explorer in the controls deep dive measures the exposure window each one leaves behind. Managed proactive Hooks belong on that diagram and are not on it yet — they intercept later than an SCP and earlier than a Config rule, which is a position nothing in the deck occupies.
A Hook used to mean code. You authored the validation logic, packaged it, registered it in the account, and owned it forever — which is why almost nobody outside a platform team ever shipped one. Managed proactive controls remove the authoring step entirely: you pick controls from the AWS Control Tower Controls Catalog and AWS evaluates resource configurations against its own best-practice checks during the CloudFormation operation. No custom Hook logic at all.
Two details matter for adoption. There is a warn mode, so a control can report what it would have blocked before you switch it to enforcing. And the launch shipped a Hooks Invocation Summary page — a historical record of which controls ran, on what, with execution details and outcomes, rather than a failure buried in stack events.
Why it matters here This is the same Control Catalog that Module 4 uses for detective controls, so one catalogue now serves both sides of the prevent/detect pair the vocabulary tab sets up. It also changes the honest answer to “where do I put my policy check?” The scaling-out tab treats template quality as something the catalogue administrator guarantees by curating products; a proactive Hook enforces it on every stack operation, catalogue or not, including the ad-hoc deploy that never went near Service Catalog.
The invocation summary gained a granular level. Instead of a pass or fail for the whole Hook, the console now surfaces the individual control’s findings, its severity level, and remediation guidance.
Why it matters here The developer-friction tab argues that a control which blocks without explaining is a control your builders will route around. This is exactly that problem solved at the Hook layer: the person whose deployment just stopped can read which control objected and what to change, without a ticket to the platform team.
Service Catalog products are CloudFormation templates, so every improvement to the deployment engine is an improvement to the catalogue. This run of changes all pushes the same way: find the problem before anything is created, and say clearly what it was.
Validation that previously only happened when you created a change set now runs on stack creates and updates as well. It is on by default; pass the DisableValidation parameter to turn it off. Three warning checks joined the set: service quota limits, AWS Config Recorder conflict detection, and Amazon ECR repository delete readiness. Available in all Regions except China, and the CDK surfaces the results with construct-level tracing back to the code that produced them.
Why it matters here The Config Recorder conflict check is the one to point at in class. Module 4’s detective layer depends on a recorder, and a template that quietly tries to create a second one in an account that already has one is a classic multi-account failure — the kind of thing a catalogue product hits only after it has been vended into the fiftieth account. Service quota warnings matter for the same reason: a product that works in the pilot account and fails at scale is a governance problem, not a template bug.
Change-set creation began validating things that used to surface only mid-deployment — invalid property syntax, resource name conflicts, and whether an S3 bucket is actually empty. Separately, every stack operation now gets a unique operation ID, visible in the console or through describe-events, so a runtime error can be traced to the exact operation that caused it.
Why it matters here The two-workflows tab explains that the end user never sees the underlying stack; the launch constraint runs it on their behalf. That indirection is what makes a failed provision opaque. An operation ID gives the administrator a single handle to correlate the user’s failed launch with what CloudFormation actually did.
A change set used to compare your new template against the last-deployed template. A drift-aware change set compares three things: the new template, the last-deployed template, and the actual state of the infrastructure. It will recreate resources that were deleted outside IaC, and if provisioning errors it restores the infrastructure to its real pre-deployment state rather than to what the template claimed. Select the “Drift-aware” change-set type in the console, or pass --deployment-mode REVERT_DRIFT to CreateChangeSet.
Why it matters here Drift is framed in this course as something you detect after the fact — Config notices, and Module 4 decides whether to remediate. This closes part of that gap at deploy time: the next deployment of a catalogue product can put manual changes back rather than layering on top of them. It also means the exposure window in the controls deep dive is not the only place drift gets resolved.
The CloudFormation Language Server, delivered through the AWS Toolkit, brings auto-complete, schema validation, CloudFormation Guard policy checks, deployment validation and the drift-aware deployment view into the editor — Visual Studio, Kiro and others. Separately, the IaC generator gained targeted resource scans, so you can scan for a specific resource type instead of sweeping the whole account.
Why it matters here Both help the person the scaling-out tab calls the catalogue administrator. Guard checks in the editor mean a product template can be held to a policy standard before it is ever published as a product version, which is the earliest possible interception point in the whole model. Targeted scans make importing an existing hand-built resource into a template a smaller job than a full account scan.
The cost tab in this module makes the case that a budget is a preventive mechanism rather than a finance report. That argument holds, and the tooling behind it has moved — but the detail belongs to one module only, so it is not duplicated here.
Budgets and Cost Anomaly Detection are M01 services under this site’s routing, and their changes are written up in full on the Module 1 What’s new tab: faster anomaly detection, a single managed monitor that follows a tag across every linked account instead of one monitor per team, net-cost metrics for budgets, and guided root-cause investigation on a detected anomaly. Read that tab alongside this one if cost control is the mechanism you are actually being asked to build.
Worth saying plainly, because it is a teaching point rather than a gap in the research. Search the AWS What’s New feed for Service Catalog across 2025 and 2026 and you find essentially one kind of item: new Regions.
Region expansion. That is the substance of the Service Catalog announcement history for this period.
Why it matters here A quiet feed is not a warning sign by itself — it usually means the service does what it was built to do. But it does tell you where AWS is investing, and that is not here.
So what does that mean if you are choosing a mechanism today? Split the job in two. Service Catalog still owns curated self-service provisioning — a portfolio of approved products, a constrained set of parameters, versioning, and the permission indirection that Lab 1 exists to demonstrate, where a launch constraint lets someone provision a resource they have no direct permission to create. Nothing has replaced that, and nothing on this page changes Lab 1.
What has moved is policy validation at deploy time. If your requirement is “this configuration must never be created,” the growth is in the Control Catalog and in CloudFormation Hooks, not in catalogue curation. The two compose rather than compete: publish the approved shapes as products, and enforce the non-negotiables as managed proactive controls so they also apply to the deployments that bypass your portfolio.
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, Control Tower and the landing zone in M02, and the detective stack — Config, Systems Manager, GuardDuty, Security Hub — in M04.