Before any diagrams, let’s build a clear mental model of the problem Service Catalog solves and the vocabulary it uses.

The Problem: Self-Service vs. Control

Organizations constantly face a tug-of-war between two goals that seem to pull in opposite directions. On one side, developers want to move fast — spin up a database, launch a server, deploy an application — without waiting days for approval. On the other side, IT and security teams need to make sure every resource created follows company policy: proper tagging, approved instance sizes, required encryption, correct network placement. AWS Service Catalog resolves this tension directly, giving both sides what they actually need rather than forcing one to compromise indefinitely at the expense of the other.

What AWS Service Catalog Actually Is

AWS Service Catalog is a service that lets organizations create, manage, and distribute a curated catalog of approved IT resources — called “products” — that end users can then launch themselves through a simple, self-service interface, without needing to understand the underlying infrastructure details or wait for manual approval each time.

Why Not Just Give Everyone Full AWS Access?

Granting every developer unrestricted access to build anything in AWS invites inconsistency and risk: differently sized servers with no standard naming, forgotten encryption settings, orphaned resources nobody remembers creating. Granting no access at all creates a bottleneck where every request queues behind a central team. Service Catalog offers a middle path: broad self-service freedom within a narrow, pre-approved set of choices, letting speed and safety coexist rather than forcing a choice between them.

Service Catalog is built from a small number of core objects that fit together like a real-world retail catalog.

• Product — a specific IT resource template made available to end users, defined using an underlying provisioning artifact such as an AWS CloudFormation template.
• Portfolio — a collection of related products, grouped together and shared with specific users, groups, or roles — like a category page in a retail catalog.
• Provisioning Artifact — the actual CloudFormation template (or Terraform configuration, in newer integrations) that defines what gets built when a product is launched.
• Constraints — rules layered on top of a product that restrict what end users can change, such as limiting allowed EC2 instance sizes or specifying which IAM role is used to actually provision the resources.
• Provisioned Product — the live, running instance of a product that a user has launched — the actual servers, databases, or other resources now deployed in their account.
• End User — the person browsing the catalog and launching products, typically without deep infrastructure knowledge or broad AWS permissions of their own.

graph LR
    A[Platform / Admin Team] -->|Builds| B[Product
CloudFormation Template]
    B --> C[Portfolio
Grouped Products]
    C -->|Shared With| D[End Users / Teams]
    D -->|Launches| E[Provisioned Product
Live Resources]
    F[Constraints] -.Restrict Options On.-> C
    G[Launch Role
IAM Permissions] -.Used to Provision.-> E
        

What actually happens between an end user clicking “Launch” and their resources appearing?

When a user launches a product, Service Catalog does not provision the underlying resources using the end user’s own permissions. Instead, it uses a dedicated launch role — an IAM role with exactly the permissions needed to create the specific resources defined in that product’s template — regardless of what permissions the end user personally has. This is what makes the “self-service without broad access” model possible: a user with very limited IAM permissions can still launch a fully functional, complex piece of infrastructure, because the provisioning happens under the launch role’s authority, not their own.

How Products Get Built and Updated

An administrator authors a CloudFormation template defining the resources a product should create, then adds it to Service Catalog as a new provisioning artifact (essentially a version) of a product. When the underlying template needs to change — a new required tag, an updated AMI, a security fix — the administrator uploads a new provisioning artifact. Existing provisioned products can then be updated to the new version in a controlled way, rather than every past deployment being silently and automatically altered.

Sharing Portfolios Across Accounts

In an AWS Organizations environment, a portfolio built once in a central account can be shared across many member accounts simultaneously, letting an organization maintain one single, centrally governed source of approved products used consistently by every team, no matter which AWS account they operate in.

How Parameters Flow Through a Launch

When an administrator builds a product, the underlying CloudFormation template typically exposes a handful of parameters — things like environment name, instance size, or an application identifier. Service Catalog surfaces exactly those parameters to the end user at launch time, using friendly labels and descriptions the administrator defines, rather than exposing raw template syntax. Constraints can further limit which parameter values are even selectable, so a dropdown might only offer “small” and “medium” sizes even though the underlying template technically supports many more options.

TagOptions and Consistent Metadata

Beyond controlling infrastructure choices, Service Catalog lets administrators define TagOptions — pre-approved key-value tag combinations, such as CostCenter values or Environment labels — that get applied automatically to every resource a product creates. This solves a very common real-world problem where inconsistent or missing tags make it nearly impossible to answer basic questions like “which team is responsible for this server” months after it was created.

Every product’s journey, from creation to a live, running resource, follows a consistent sequence.

The Core Trade-off: Speed and Safety vs. Coverage

Service Catalog is extremely effective for the 80% of common, repeatable infrastructure requests a company sees over and over. The remaining 20% — highly custom, one-off needs — often still requires direct engineering involvement outside the catalog. Recognizing that Service Catalog isn’t meant to cover every conceivable use case, only the common and repeatable ones, helps set the right expectations from the start.

Teams that try to force every possible infrastructure need into the catalog often end up with an unwieldy number of near-duplicate products, each handling a slightly different edge case. A healthier approach accepts that some genuinely unusual requests belong outside the catalog entirely, keeping the catalog itself focused, well-maintained, and trustworthy for the requests it was actually designed to serve.

Service Catalog’s real value compounds as the number of teams and requests grows.

A five-person startup might not feel much benefit from Service Catalog — a Slack message to the one person who manages infrastructure is fast enough. A thousand-person enterprise with dozens of teams, each regularly needing standard resources, feels an enormous difference: instead of a central platform team fielding hundreds of individual requests every week, that same team builds and maintains a smaller set of well-designed products once, and every subsequent request is served instantly through self-service.

Organizing Portfolios as the Catalog Grows

As the number of products grows into the dozens or hundreds, a common scaling pattern organizes portfolios by team, environment, or resource category — a “Database Portfolio,” a “Networking Portfolio,” a “Sandbox Environment Portfolio” — each shared only with the specific groups that need it, rather than a single sprawling portfolio containing everything for everyone.

Federating Ownership as Teams Multiply

A single central team authoring every product eventually becomes its own bottleneck once an organization reaches a large enough scale. Many mature Service Catalog deployments federate product ownership, letting individual application teams author and maintain their own specialized products, while a central platform team retains ownership of foundational, cross-cutting products (like networking or identity baselines) and governs the overall constraints and standards every product must follow, regardless of who authored it.

AWS Service Catalog itself runs as a managed service across AWS’s highly available infrastructure, so the service that lets users browse and launch products is not a single point of failure. Reliability concerns in a Service Catalog context tend to center less on the platform’s own uptime and more on whether the underlying CloudFormation templates are well-tested and whether launch roles have exactly the permissions they need — no more, no less.

Handling Failed Provisioning Gracefully

Because Service Catalog provisioning is backed by CloudFormation, a failed launch triggers CloudFormation’s normal rollback behavior, cleaning up any partially created resources rather than leaving orphaned, half-built infrastructure behind. This built-in safety net means a failed self-service launch is far less risky than it might otherwise sound.

Because the underlying mechanics are simply CloudFormation, teams already skilled at debugging CloudFormation stack events can apply that exact same knowledge to troubleshoot a failed Service Catalog launch, rather than needing to learn an entirely separate diagnostic process specific to the catalog layer.

Service Catalog’s entire design is fundamentally a security and governance tool, so its own security model needs to be equally solid.

• Launch Roles — scoped IAM roles that do the actual provisioning, following least-privilege principles so end users never need broad AWS permissions themselves.
• Portfolio Sharing Controls — determine exactly which users, groups, roles, or accounts can even see a given portfolio, keeping sensitive or specialized products restricted to the right audience.
• Constraints — restrict specific parameter choices at launch time, preventing an end user from silently deviating from approved configurations like instance size or encryption settings.
• Tag Options — enforce consistent, approved tagging across every resource launched through the catalog, supporting accurate cost allocation and asset tracking.
• CloudTrail Integration — every catalog action, including product launches and terminations, is logged for auditing and accountability.

Separating Who Authors from Who Consumes

A healthy Service Catalog security model keeps a clear separation between the small group of administrators authorized to create and publish products or portfolios, and the much larger group of end users authorized only to browse and launch what’s already been published. This separation ensures that the standards embedded in a product — its encryption defaults, its network placement, its required tags — cannot be casually altered by whoever happens to be launching it that day.

AWS CloudTrail records every significant action taken within Service Catalog — who launched which product, when, and with what parameters — giving administrators a clear audit trail of self-service activity across the organization. Because provisioned products map directly to underlying CloudFormation stacks, standard CloudFormation events and drift detection also apply, surfacing any manual changes made directly to a resource after it was launched through the catalog.

Many platform teams also track adoption metrics — how many teams are using the catalog, which portfolios see the most traffic — to guide where to invest further product development effort, treating the catalog itself as a product with its own usage-driven roadmap.

Tracking failed launches specifically by product also reveals which templates need attention most urgently — a product with a high failure rate is quietly eroding trust in self-service every time someone hits it, even if the overall catalog is otherwise working well for everyone else.

Service Catalog rarely stands entirely alone — it typically plugs into a broader governance and provisioning ecosystem.

A very common pattern pairs Service Catalog with AWS Control Tower’s Account Factory, where newly created accounts automatically receive access to a standard set of portfolios the moment they’re provisioned, ensuring every new team starts with the same approved self-service menu from day one. Another pattern integrates Service Catalog with AWS Service Catalog AppRegistry, which groups related provisioned resources into logical applications, making it easier to see and manage everything belonging to a specific business application, even when it spans multiple underlying products and services.

graph LR
    CT[Control Tower
Account Factory] --> NA[New Account Created]
    NA --> P[Shared Service Catalog Portfolios]
    P --> U[End User Launches Product]
    U --> AR[AppRegistry
Groups Resources into Applications]
        

Service Catalog also supports Terraform-based provisioning artifacts alongside CloudFormation, letting organizations that have already invested in Terraform bring that same infrastructure-as-code investment into a governed, self-service catalog rather than starting from scratch with a different templating language.

For organizations building an internal developer platform, Service Catalog is often used as the underlying provisioning engine behind a friendlier custom front-end — a web portal or internal tool that presents the catalog’s products with company-specific branding and workflow, while Service Catalog itself continues to handle the actual governance, launch roles, and provisioning logic underneath.

A frequently overlooked best practice is collecting direct feedback from end users about which products feel too restrictive or too slow to launch, treating the catalog as an evolving internal product rather than a one-time governance project that’s finished once it’s published.

It’s also worth establishing a clear, lightweight process for requesting a brand-new product, so teams with a genuinely new, repeatable need have an obvious path to get it added to the catalog rather than quietly working around the system because they don’t know how, or assume, requesting a new product is possible at all.