These are the building blocks that separate a Service Catalog novice from a Service Catalog architect. Each one exists to solve a specific governance problem that only appears once self-service infrastructure is running at real scale.

Portfolios: The Unit of Access Control

A Portfolio is a named collection of Products, and it is the actual boundary that IAM permissions are granted against — an end user is never granted access to a Product directly, only to a Portfolio that contains one or more Products. This indirection is deliberate: a platform team can reorganize which products live in which portfolio, or add a brand-new product to an existing portfolio, without ever touching the IAM policies that grant end users access, because those policies point at the portfolio, not at the individual products inside it.

Products and Provisioning Artifacts

A Product is a single type of launchable infrastructure — “Standard VPC,” “Three-Tier Web Application,” “RDS PostgreSQL Database.” Each Product can have multiple Provisioning Artifacts, which are simply versions of the underlying template. This versioning is what lets a platform team publish an improved template for a product — patching a security misconfiguration, for instance — while every already-provisioned instance of the older version keeps running unaffected, until an end user or an automated policy explicitly triggers an update to the newer artifact.

Constraints: Where Governance Actually Lives

A Constraint is a rule attached to a specific Product within a specific Portfolio, and constraints are the true governance mechanism of the entire service — without them, Service Catalog is little more than a launch button. A Launch Constraint specifies exactly which IAM role CloudFormation should assume when provisioning the product, meaning the end user launching it never needs the underlying permissions themselves. A Template Constraint restricts which parameter values an end user is allowed to choose — for example, permitting only db.t3.micro or db.t3.small as valid database instance classes, even though the underlying template technically supports any RDS instance class. A StackSet Constraint causes the product to provision as a StackSet across multiple accounts and regions instead of a single stack. A Notification Constraint routes provisioning events to an SNS topic. A Resource Update Constraint controls whether end users are even allowed to change specific resource properties after initial launch.

Principals: Who Gets Access

A Principal — an IAM user, group, or role — is associated with a Portfolio to grant it launch access. Because portfolio access is almost always granted to an IAM role rather than an individual user, most organizations map a single portfolio’s access to an entire team’s shared role, meaning access management becomes a question of “who is in this team’s role” rather than a constantly-changing list of individual grants.

Provisioning Artifact Types Beyond CloudFormation

A Provisioning Artifact is not limited to a single format. Alongside a standard CloudFormation template, an artifact can be marked as a CloudFormation-based Marketplace product, or authored using Terraform, giving a platform team the flexibility to publish products backed by whichever underlying technology best fits a given use case, all exposed through the exact same catalog interface to end users. This matters because it means adopting Service Catalog as an organization’s governance layer does not force every team onto a single infrastructure-as-code tool.

Product Types and Their Lifecycle Ownership

Beyond CloudFormation and Terraform products, Service Catalog also supports products sourced directly from the AWS Marketplace, letting a platform team curate third-party software alongside internally-authored infrastructure patterns in the same catalog. Regardless of the underlying source, every product still passes through the same constraint-resolution and permission-boundary model described throughout this tutorial, which is precisely what keeps the governance story consistent even as the catalog’s contents grow more varied.

Service Catalog is not a separate provisioning technology — it is a governance and permission layer built on top of CloudFormation, and understanding that relationship explains almost everything about how it behaves.

A Launch Is a CloudFormation Deployment in Disguise

When an end user launches a Product, Service Catalog does not provision resources itself. It resolves the applicable Launch Constraint to determine which IAM role to assume, merges the end user’s chosen parameter values with whatever a Template Constraint restricts them to, and then issues a standard CloudFormation CreateStack call using that assumed role’s credentials. Every guarantee CloudFormation itself provides — automatic rollback, a dependency graph, Stack Events — is fully inherited by every Provisioned Product, because underneath, it genuinely is a CloudFormation stack.

graph TD
    A[End User Launches Product] --> B[Service Catalog Resolves Constraints]
    B --> C{Launch Constraint
Defines IAM Role}
    C --> D[Assume Launch Role]
    D --> E[Merge Parameters With
Template Constraint Rules]
    E --> F[CloudFormation CreateStack
Using Assumed Role]
    F --> G[Standard CloudFormation
Provisioning Engine]
    G --> H[Provisioned Product Tracked
Status Mirrors Stack Status]
        

The Permission Boundary That Makes Self-Service Safe

The entire safety model of Service Catalog rests on a single architectural decision: the end user’s own IAM identity is never the identity that creates resources. An engineer with almost no direct AWS permissions can safely be granted access to launch a Product that internally creates an RDS instance, a VPC, and IAM roles, because the Launch Constraint’s role — not the engineer’s own role — performs the actual provisioning. This is precisely the mechanism that lets an organization offer broad self-service without broadly expanding what any individual engineer is personally permitted to do.

Provisioned Product State Tracking

Service Catalog maintains its own state machine for each Provisioned Product — AVAILABLE, UNDER_CHANGE, TAINTED, ERROR — layered directly on top of the underlying CloudFormation stack’s own status. A Provisioned Product enters TAINTED specifically when an update fails and the stack rolls back, signaling that the resources still exist and are running but are not in the state the currently-selected provisioning artifact describes, which is functionally very similar to CloudFormation drift but tracked at the catalog layer instead.

Terraform as a Second Provisioning Engine

Service Catalog is not exclusively a CloudFormation wrapper. Through Terraform Open Source and Terraform Cloud product types, a Product can be defined using a Terraform configuration instead of a CloudFormation template, with Service Catalog invoking Terraform’s plan and apply operations under the hood in much the same governed way it invokes CloudFormation’s Change Sets and stack operations — letting an organization standardize its self-service governance layer even across teams that have standardized on different underlying infrastructure-as-code tools.

How Constraint Resolution Handles Conflicts

When multiple constraints of the same type could theoretically apply — for instance, a product associated with several portfolios, each carrying its own Launch Constraint — Service Catalog resolves the applicable constraint based on the specific portfolio the end user is launching through, not some merged or averaged set of rules across every portfolio the product happens to belong to. This per-portfolio scoping is precisely what allows the same underlying product to be offered under stricter rules in one portfolio and looser rules in another, without the two ever interfering with each other.

The API Layer Underneath the Console

Every action available in the Service Catalog console — associating a product, attaching a constraint, launching a provisioned product — has a corresponding API operation, and virtually every serious platform team automates portfolio and product management entirely through that API rather than manual console clicks, treating the catalog’s own configuration as infrastructure-as-code in its own right, version-controlled and deployed through a pipeline just like the products it contains.

How Product Versioning Interacts With the Underlying Template Registry

Each Provisioning Artifact is stored with its own immutable identifier, meaning two different Provisioned Products launched from the same Product but different artifact versions can coexist indefinitely with genuinely different underlying templates, even while both appear under the same Product name in the catalog. This immutability is what makes rollback of a bad product version straightforward at the catalog level: pointing new launches back at a known-good prior artifact identifier requires no template rewriting, only a change to which artifact is marked active for new launches.

A Provisioned Product moves through a predictable set of phases, and every advanced operational skill — safe updates, clean terminations, constraint troubleshooting — depends on knowing exactly where in that lifecycle a given product currently sits.

How Parameters Actually Flow to CloudFormation

When an end user submits launch parameters, Service Catalog does not forward them to CloudFormation untouched. It first validates every value against any active Template Constraint’s allowed list or range, rejects the launch outright if a value falls outside those bounds, and only then passes the validated set through to the underlying CreateStack call as standard CloudFormation Parameters — meaning the constraint enforcement happens entirely within Service Catalog, before CloudFormation is ever invoked at all.

Outputs Surfaced Back to the End User

Just as a CloudFormation stack exposes Outputs, a Provisioned Product surfaces those same Outputs directly in the Service Catalog console and API — so an end user who launched a database product can retrieve its connection endpoint without ever needing direct access to view the underlying CloudFormation stack itself, preserving the abstraction boundary between the catalog and the infrastructure it manages.

The Role of Path IDs in Multi-Portfolio Products

When a Product is associated with more than one Portfolio, launching it requires specifying which “path” — effectively, which portfolio association — the launch should resolve through, since different paths can carry entirely different constraints. This Path ID is what allows Service Catalog to unambiguously determine which Launch Constraint role and which Template Constraint rules apply to a given launch request, even when the same underlying product is reachable through several different portfolios simultaneously.

Update Behavior and In-Place Versus Replacement Changes

Because a Provisioned Product update is a standard CloudFormation stack update underneath, the same in-place-versus-replacement distinction applies. An end user updating a parameter that CloudFormation can change in place experiences a quick, low-risk update; a parameter change that forces a resource replacement carries the same disruption risk it would in any standalone CloudFormation deployment, which is exactly why Resource Update Constraints exist — to prevent an end user from unknowingly triggering that kind of disruptive change through the catalog interface.

Service Catalog is a genuine trade — it exchanges some template flexibility for organization-wide governance. Knowing exactly what’s gained and what’s given up is what lets a platform team adopt it deliberately.

It’s worth being explicit about what the abstraction actually costs an individual engineer. A developer troubleshooting a failed direct CloudFormation deployment can read every Stack Event themselves in seconds. A developer troubleshooting a failed catalog launch may need to escalate to the platform team that owns the Launch Constraint role simply to see the equivalent detail, since the underlying stack often isn’t directly visible to the end user. Mature platform teams treat this as a support-load problem to design around — surfacing as much of the relevant failure detail as possible directly within the catalog’s own error messages — rather than an unavoidable cost of adopting the service.

Because every launch ultimately becomes a CloudFormation deployment, Service Catalog’s scalability characteristics closely mirror CloudFormation’s own — with an additional layer of constraint-resolution overhead and organization-wide sharing to account for.

Constraint Resolution at Launch Time

Before any CloudFormation call is made, Service Catalog must resolve which constraints apply to the specific product-in-portfolio combination being launched. In an organization with many portfolios and overlapping product associations, this resolution step, while fast, is a real piece of work performed on every single launch — which is why keeping the constraint model reasonably flat and avoiding excessive duplication of the same product across many nearly-identical portfolios keeps both performance and maintainability healthy.

Organization-Wide Portfolio Sharing at Scale

Sharing a portfolio with an entire AWS Organization, rather than individual accounts one at a time, is what allows a single administrative action to make a set of products available across thousands of accounts simultaneously. Internally, this shares the portfolio’s definition, not the provisioned products themselves — each account that later launches a product from the shared portfolio creates its own independent Provisioned Product, tracked entirely within that consuming account.

StackSet-Backed Products at Volume

A product governed by a StackSet Constraint inherits the same batching behavior — Max Concurrent Percentage and Failure Tolerance — that a standalone StackSet does, described in CloudFormation’s own scalability model. This means a single Service Catalog launch that fans out across two hundred accounts is still subject to the same controlled, staged rollout mechanics, rather than attempting all two hundred accounts simultaneously and risking a large-blast-radius partial failure.

Catalog Browsing Performance at Large Product Counts

As the number of products and portfolios grows into the hundreds across a large organization, the end-user experience of browsing the catalog itself becomes a real design concern, not just a backend scaling question. Organizing products into well-named, purpose-specific portfolios rather than one enormous flat list is what keeps the catalog navigable for end users, and is a far more effective scaling lever than anything on the API performance side, since the actual bottleneck at that point is human comprehension, not system throughput.

Parallel Launches and Account-Level Throttling

Because every launch ultimately calls CloudFormation, a burst of many simultaneous launches within a single account is still bound by that account’s own CloudFormation and underlying-service API throttling limits, exactly as described for standalone CloudFormation deployments. Platform teams supporting very active self-service usage sometimes stagger high-volume automated launches — for instance, a script provisioning dozens of ephemeral test environments — specifically to avoid tripping those account-level throttling limits all at once.

Reliability in Service Catalog is really CloudFormation’s reliability model, inherited wholesale, with a catalog-specific state machine layered on top to represent it to end users.

Failed Launches Resolve to Standard Rollback

When a launch fails, the underlying CloudFormation stack rolls back exactly as it would for a directly-authored template, and the Provisioned Product surfaces as ERROR to the end user. The end user never needs direct CloudFormation access to understand what happened, because Service Catalog surfaces the relevant failure reason from the underlying stack’s events directly in its own console and API.

The TAINTED State and Update Failures

An update that fails leaves the underlying resources running — CloudFormation rolls the stack back to its prior working state — but Service Catalog marks the Provisioned Product as TAINTED to make clear that the most recent update attempt did not fully succeed, even though the product is still functioning. This distinct state exists specifically so that platform teams can build automated alerting or dashboards around “how many provisioned products are currently in a tainted state,” a very different and more actionable signal than a generic failure count.

Resource Update Constraints as a Reliability Guardrail

A Resource Update Constraint that locks specific properties against end-user modification is, in effect, a reliability control: it prevents an end user from accidentally changing a property that would trigger a disruptive resource replacement — renaming a database identifier, for instance — without realizing the consequence, because that property is simply not exposed as editable at all.

StackSet Constraint Failure Tolerance

For a product launched across multiple accounts via a StackSet Constraint, the same Failure Tolerance mechanics that protect a standalone multi-account CloudFormation rollout apply here too — a small number of account-level failures within the configured tolerance do not fail the entire Provisioned Product launch, while exceeding that tolerance does, giving platform teams the same fine-grained control over acceptable partial failure that raw StackSets provide.

Recovering From a Deleted Launch Role

If a Launch Constraint’s underlying IAM role is deleted or loses a required permission after products have already been successfully provisioned through it, existing Provisioned Products continue running unaffected — the role is only needed at launch and update time, not for the resources to keep operating. New launches or updates through that constraint will fail immediately, which is why platform teams treat any change to a launch role as carrying the same review rigor as a change to the product template itself.

Cross-Region Reliability Considerations

A portfolio and its constraints are defined within a specific home region, and while portfolio sharing can extend a portfolio’s reach across accounts, StackSet Constraints are what actually extend a single launch’s reach across regions. A platform team designing for genuine multi-region reliability needs the underlying product template itself to be region-agnostic — following the same Mappings and dynamic Availability-Zone-resolution techniques used in standalone CloudFormation — since Service Catalog’s constraint layer cannot make a region-specific template portable on its own.

Service Catalog’s entire value proposition is a security one — separating who is allowed to request infrastructure from what permissions are actually needed to create it — and getting that separation right is the most important security skill in the service.

Launch Roles and the Principle of Least Privilege

The Launch Constraint role should be scoped as narrowly as the specific product genuinely requires — a product that only creates an S3 bucket and a CloudFront distribution has no legitimate reason for its launch role to also carry EC2 or IAM permissions. Over-scoped launch roles are a common, dangerous mistake: an end user with launch access to that single product effectively gains, indirectly, whatever broader permissions the overly generous launch role happens to carry.

Portfolio Sharing and Trust Boundaries

Sharing a portfolio across accounts, whether individually or organization-wide, extends the platform team’s governance — and its Launch Constraint roles — into every account that accepts the share. Because the consuming account’s own administrators typically cannot modify constraints defined by the sharing account, portfolio sharing is fundamentally a trust relationship: the sharing account is trusted to keep its launch roles appropriately scoped, since every consuming account inherits that scoping unchanged.

Template Constraints as a Security Guardrail

Beyond convenience, a Template Constraint is a genuine security control — restricting which CIDR ranges, instance types, or AMI IDs an end user may select prevents a well-intentioned but under-informed engineer from launching a product with a configuration the platform team never intended to allow, such as an instance size dramatically larger than approved, or a publicly-open CIDR range for a database security group.

Access Auditing Through CloudTrail

Every Service Catalog API call — ProvisionProduct, UpdateProvisionedProduct, TerminateProvisionedProduct — is captured by CloudTrail exactly like any other AWS API call, giving a complete audit trail of who launched what, when, and with which parameters, independent of and complementary to the CloudTrail record of the underlying CloudFormation operations Service Catalog triggers on their behalf.

Constraint Tampering and Who Can Change the Rules

Because constraints are themselves the governance mechanism, the IAM permissions controlling who can create, modify, or remove a Constraint deserve at least as much scrutiny as the Launch Constraint roles they define. An end user with permission to modify constraints on a portfolio they merely have launch access to could, in principle, loosen a Template Constraint or attach a more permissive Launch Constraint to grant themselves broader effective access — which is why constraint management permissions are almost always restricted to the platform team alone, separate entirely from end-user launch permissions.

Secrets and Sensitive Parameters at Launch Time

Because the underlying provisioning is standard CloudFormation, the same Dynamic References pattern used to pull a secret from Secrets Manager or Parameter Store at deployment time — rather than embedding a plaintext value in a template or exposing it as an end-user-entered parameter — applies equally well to catalog products, and is the preferred approach whenever a product needs a credential or API key during provisioning.

Observing Service Catalog well means watching two layers at once: the catalog’s own launch and update activity, and the underlying CloudFormation operations those actions trigger.

CloudTrail as the Catalog-Level Audit Trail

Because every provisioning action an end user takes flows through the Service Catalog API rather than directly through CloudFormation, CloudTrail’s record of Service Catalog calls is the most useful starting point for understanding catalog usage patterns — which products are launched most often, by which teams, and how frequently updates versus fresh launches occur.

EventBridge Notifications

A Notification Constraint routes Provisioned Product lifecycle events to an SNS topic, which is commonly wired into EventBridge for downstream automation — for example, automatically notifying a platform team’s Slack channel whenever a product enters an ERROR or TAINTED state, so failures are surfaced proactively rather than discovered only when an end user complains.

Tracing a Failure Down to the CloudFormation Layer

When a Provisioned Product shows ERROR, the Service Catalog console surfaces a status message, but the full, resource-by-resource failure detail still lives in the underlying CloudFormation stack’s own Stack Events — accessible to anyone with the appropriate CloudFormation read permissions, typically the platform team that owns the Launch Constraint role, even when the end user who triggered the launch cannot see it directly.

Usage Dashboards for Catalog Health

Mature platform teams build a lightweight dashboard tracking product launch counts, the ratio of provisioned products currently in TAINTED or ERROR state, and the average age of a provisioning artifact still in active use across the fleet — the last of which is a strong proxy for how much technical debt has accumulated in the form of provisioned products running outdated, potentially unpatched versions of a template.

Correlating Catalog Events With Application-Level Monitoring

Because a Provisioned Product’s Outputs often include identifiers — an endpoint, a resource ARN — that also appear in application-level monitoring and logging, some platform teams enrich their observability pipeline by tagging application logs and metrics with the originating Provisioned Product ID, making it straightforward to trace an application incident back to exactly which catalog launch, and which parameter choices, produced the infrastructure behind it.

Service Catalog is rarely deployed in isolation — it becomes the front door through which an entire organization’s self-service infrastructure story is told, wired together with several other AWS governance services.

Organizational Sharing as the Default Distribution Model

The dominant advanced pattern shares portfolios directly with an AWS Organization or specific Organizational Units, rather than sharing with individual accounts one at a time — meaning a new account automatically gains access to the appropriate set of portfolios the moment it’s placed into the correct Organizational Unit, with zero manual step required from either the platform team or the team onboarding the new account.

AppRegistry Integration for Application-Level Visibility

Provisioned Products can be associated with an AppRegistry Application, which aggregates resources across potentially many products and stacks into a single, coherent view of “everything that belongs to Application X” — letting a platform or FinOps team answer questions like total cost or full resource inventory for an application, even when that application was assembled from several independently-launched catalog products.

CI/CD-Driven Product Publishing

Rather than manually uploading a new Provisioning Artifact through the console, mature teams treat product templates exactly like application code: stored in version control, validated through the same CloudFormation Guard and linting pipeline described for standalone CloudFormation, and published as a new Provisioning Artifact automatically once a pull request merges — meaning the products a self-service catalog exposes are themselves continuously and safely delivered, not manually curated by hand.

graph TD
    Mgmt[Management Account] --> OU1[OU: Engineering]
    OU1 --> A1[Account: team-payments]
    OU1 --> A2[Account: team-checkout]
    Mgmt -->|Shares Portfolio| OU1
    A1 --> P1[End User Launches Product]
    A2 --> P2[End User Launches Product]
    P1 --> S1[Provisioned Product
in team-payments]
    P2 --> S2[Provisioned Product
in team-checkout]
        

Terraform-Backed Products for Mixed-Tooling Organizations

Organizations that standardized on Terraform for some teams and CloudFormation for others can still present a single, unified self-service catalog to every engineer — Service Catalog’s Terraform product type lets the same governance model, the same constraint system, and the same end-user experience apply regardless of which infrastructure-as-code tool actually backs a given product.

Landing Zone Integration

Organizations using AWS Control Tower or a custom-built landing zone frequently wire portfolio sharing directly into the account-vending process itself, so that the moment a new account is provisioned through the landing zone’s automation, it is simultaneously granted access to the appropriate baseline portfolios — meaning a brand-new account arrives with self-service infrastructure already available on day one, with no separate onboarding step required.

The difference between a catalog engineers actually trust and one they quietly route around almost always comes down to a handful of structural decisions made when the portfolio and product model is first designed.

Pattern: Portfolio-per-Team, Product-per-Pattern

A common, durable structure grants each team its own Portfolio containing only the specific infrastructure patterns relevant to that team’s work, while the underlying Products — a standard VPC, a standard RDS instance — are authored once and associated into as many team portfolios as are relevant. This avoids both extremes: a single mega-portfolio granting every team access to every product regardless of relevance, and a fully duplicated set of near-identical products maintained separately per team.

Pattern: Progressive Constraint Tightening

Rather than launching a brand-new product with maximally restrictive Template Constraints from day one, some platform teams intentionally launch with looser constraints, observe real usage patterns for a few weeks, and then tighten the allowed parameter ranges based on what engineers actually needed — avoiding the common failure mode where an overly cautious initial constraint set frustrates legitimate early users before the platform team has enough real usage data to know where the genuine risk actually lies.

Pattern: Guard Rules Applied to Product Templates

Because a Product’s Provisioning Artifact is, underneath, a standard CloudFormation template, the exact same CloudFormation Guard policy-as-code rules used for standalone infrastructure apply equally well here — run automatically in the CI pipeline that publishes new Provisioning Artifacts, catching a non-compliant change before it ever becomes available for an end user to launch.

These are the habits that separate a catalog engineers reach for by default from one they treat as a last resort.

Seeing how large organizations actually apply these mechanisms makes them feel far less abstract.

Constraints are what turn a plain launch button into an actual governance system. Understanding exactly how each type behaves is the difference between a catalog that enforces intent and one that only appears to.

Launch Constraints: Role Resolution in Detail

A Launch Constraint can point either at an existing IAM role or, in newer configurations, at a local role defined inline. When a product is shared across accounts via an organization-wide portfolio share, the Launch Constraint’s role must exist in each consuming account — which is why many platform teams pair portfolio sharing with a StackSet of their own that deploys the necessary launch role into every account automatically, ensuring the role is always present before any end user in that account attempts to launch.

Template Constraints and the Rules Syntax

A Template Constraint is itself expressed as a small piece of structured logic, capable of defining allowed value lists, numeric or string ranges, and even conditional rules that only apply an allowed-value restriction when a different parameter is set to a specific value — for example, only restricting instance size choices when an “Environment” parameter is set to “production,” while leaving development launches more permissive.

TagOptions: Reusable, Enforceable Tag Governance

A TagOption is a predefined key and an approved set of values for that key — for instance, a CostCenter key with a fixed list of valid cost center codes. Associating a TagOptions set with a Portfolio or Product means every launch through that portfolio is tagged consistently from a controlled vocabulary, rather than depending on an end user to correctly remember and type a value, which is precisely the kind of small, structural guarantee that keeps cost allocation and ownership tracking reliable at scale.

Layering Multiple Constraints on One Product

A single product-in-portfolio combination can carry several constraint types simultaneously — a Launch Constraint defining the provisioning role, a Template Constraint narrowing parameter choices, and a Notification Constraint routing events to an SNS topic, all active at once. Service Catalog resolves and applies all of them together at launch time, which is why testing a new constraint configuration against a non-production portfolio before applying it broadly is standard practice among experienced platform teams.

Every experienced Service Catalog operator has faced these situations. Knowing the pattern in advance turns a confusing support request into a quick, confident fix.

An End User Sees Far Fewer Parameter Options Than Expected

This is almost always a Template Constraint quietly restricting the allowed values. The fix is not to assume the underlying template is broken — it’s to review the active Template Constraint for that specific product-in-portfolio combination first, since the template itself may fully support the value the end user wants, with the restriction living entirely in the constraint layer instead.

A Launch Fails With an Access Denied Error the End User Can’t Explain

Because the actual provisioning happens under the Launch Constraint’s assumed role, not the end user’s own identity, an Access Denied error usually means the launch role itself is missing a permission the template needs — not that the end user lacks permission. The fix belongs with the platform team that owns the launch role, and the end user should never be advised to simply request broader personal IAM permissions to work around it.

A Portfolio Shared via Organizations Doesn’t Appear in a New Account

Organization-wide sharing propagates automatically for new accounts, but propagation is not always instantaneous, and it depends on the account genuinely being placed within the correct Organizational Unit the share targets. Confirming the account’s actual OU placement, and allowing a short propagation window, resolves the overwhelming majority of these reports before any deeper investigation is needed.

A Provisioned Product Is Stuck in UNDER_CHANGE

This mirrors a CloudFormation stack stuck mid-operation, since that’s exactly what it is underneath. The underlying CloudFormation Stack Events, accessible to whoever holds the Launch Constraint role’s permissions, will show precisely which resource is still pending and why — the same troubleshooting approach used for any slow or stuck CloudFormation deployment applies directly here.

A product published to the catalog without being tested against a real launch is a hypothesis, not infrastructure end users can trust. Advanced teams test at the product level, not just the template level.

Template-Level Testing Before Publishing

Because a Provisioning Artifact is a standard CloudFormation template underneath, every layer of testing that applies to standalone CloudFormation — static linting, Guard policy checks, API-level validation, and Change Set dry runs — applies equally well before a new artifact is ever published as a product version, and should run automatically in the same CI pipeline that publishes it.

Constraint-Level Testing in a Staging Portfolio

Template validation alone doesn’t catch a misconfigured constraint. Mature teams maintain a non-production staging Portfolio where a new product version, along with its intended constraints, is fully launched, updated, and terminated end-to-end exactly as a real end user would — catching an overly restrictive Template Constraint or a launch role missing a permission before either one ever reaches a production portfolio.

End-to-End Launch Simulation

The deepest layer of testing actually launches the product as a non-privileged test principal would, through the catalog API rather than a platform team’s own elevated access, to confirm the entire chain — portfolio access, constraint resolution, launch role permissions, and the resulting CloudFormation deployment — works exactly as an ordinary end user would experience it, not merely as the platform team’s own broader access would allow.

Regression Testing Across Provisioning Artifact Versions

Because multiple versions of a product’s Provisioning Artifact can remain active simultaneously, changes to shared elements — a Launch Constraint role, a TagOptions set — need to be regression-tested against every currently-supported artifact version, not just the newest one, since an older version’s template may rely on a slightly different set of permissions or parameters than the version currently being developed.

Because Service Catalog is the single choke point through which self-service infrastructure is created in a well-governed organization, it is also one of the most effective places to enforce cost discipline before spend ever happens.

TagOptions as a Cost Allocation Guarantee

Consistent cost allocation tagging depends entirely on every provisioned resource actually carrying the tags a FinOps team needs, and the TagOptions Library is the mechanism that guarantees this without relying on individual end-user discipline — every launch through a portfolio with an attached TagOptions set is tagged from that approved, controlled vocabulary automatically.

Right-Sizing Through Template Constraints

A Template Constraint that limits which instance sizes or database classes an end user may select doubles as a cost control — restricting a “development” product’s allowed instance types to only small, inexpensive options prevents accidental over-provisioning far more reliably than a written policy document ever could, because the oversized option simply isn’t selectable in the first place.

Tracking and Retiring Idle Provisioned Products

Because every Provisioned Product is individually tracked, platform teams can build automated reporting that identifies products which have existed past an expected lifetime — particularly common for temporary development or demo environments — and either alert the owning team or, where appropriate, automatically terminate them, reclaiming spend that would otherwise silently accumulate.

Approval Workflows for High-Cost Products

For products with a genuinely significant cost footprint — a large data warehouse cluster, a high-capacity compute fleet — some organizations layer a manual or automated approval step in front of the launch itself, commonly implemented through a Notification Constraint that routes the launch request to an approval workflow before the underlying CloudFormation deployment is permitted to proceed.

No. The Launch Constraint’s IAM role performs the actual CloudFormation deployment, not the end user’s own identity. An end user only needs Service Catalog permissions and portfolio access — they can safely launch a product that creates resources they could never create directly with their own personal IAM permissions.

Nothing changes automatically. Existing Provisioned Products keep running on whichever version they were originally launched or last updated to. Moving them to the new version requires an explicit update action, either by the end user or by an automated governance process the platform team builds separately.

Yes, and this is a common, intentional pattern. The same Product can be associated with multiple Portfolios, each carrying its own independent set of constraints — for example, a “Production” portfolio with a stricter Template Constraint and a more limited Launch Constraint role than a “Development” portfolio exposing the exact same underlying product.

Underneath, an update is a standard CloudFormation stack update, so the same replacement-triggering property rules apply. A seemingly minor template change can still force a resource replacement, and if that replacement fails or is blocked by a Resource Update Constraint, the Provisioned Product surfaces as TAINTED rather than completing the update.

No. While CloudFormation is the original and most common provisioning engine, Service Catalog also supports Terraform Open Source and Terraform Cloud product types, letting organizations apply the same governance and self-service model even when the underlying infrastructure is defined with Terraform instead.

A Template Constraint limits what values are selectable at launch time. A Resource Update Constraint instead controls whether specific properties can be changed at all once a product is already provisioned — it governs the update phase of the lifecycle, not the initial launch, and is commonly used to lock down a property that would trigger a disruptive replacement if changed.

Each consuming account sees the shared portfolio and can launch products from it, but every launch creates a Provisioned Product tracked entirely within that consuming account — the portfolio definition is shared, while the actual provisioned resources and their tracking remain local to whichever account launched them.

For any organization beyond a handful of products, managing portfolios, product associations, and constraints through code — typically CloudFormation itself — is strongly preferred. It provides an audit trail, an easy rollback path for an accidental misconfiguration, and a repeatable way to reconstruct the catalog’s structure, none of which a purely console-managed setup can offer.

AWS Service Catalog’s real value isn’t the launch button end users click — it’s the governance engine working underneath: Launch Constraints that separate who requests infrastructure from what permissions actually create it, Template Constraints that narrow flexible templates into safe, pre-approved choices, and organization-wide sharing that turns a single approved template into a consistent standard across an entire company. Mastering Service Catalog at an advanced level means designing portfolios, products, and constraints with that governance model in mind — thinking in terms of trust boundaries and blast radius, not just which products to publish.