Skip to main content
Welcome. This lesson explains AWS Service Catalog and how to use reusable, pre-approved templates to deliver standardized, governed resources across your organization. Topics covered: what Service Catalog is, how it works, typical workflows, integrations, key features, constraints and governance, recommended best practices, and a concise summary for exam prep. Why use Service Catalog?
  • Centralizes pre-approved infrastructure blueprints so end users can self-service without needing broad AWS permissions.
  • Prevents inconsistent deployments, governance gaps, and uncontrolled spend by exposing only regulated, versioned product templates.
  • Integrates with standard IaC tooling (for example, CloudFormation) so templates can be versioned, tested, and evolved alongside application code.
A presentation slide titled "Without Service Catalog" showing an AWS Service Catalog graphic on the left and a dashed box of circular icons on the right. The icons list problems such as inconsistent deployments, lack of governance and compliance, uncontrolled spending, complexity in multi-account management, and slow resource deployment.

​
What is a Service Catalog product?

A Service Catalog product is typically an infrastructure provisioning template (a template-backed artifact) that provisions a stack or related resource group. Products are grouped into portfolios and then shared with target accounts or organizational units (OUs). End users see only the portfolios and products they are permitted to access and can launch approved products into their environment.
Service Catalog products are backed by provisioning templates, so you can author templates directly (CloudFormation) or use higher-level IaC tools that compile into CloudFormation templates. This enables versioning, testing, and consistent deployments.

​
Typical workflow and responsibilities

The Service Catalog workflow separates catalog management from day-to-day usage:
  • Catalog administrators:
    • Create and maintain products (template artifacts).
    • Group products into portfolios.
    • Manage portfolio permissions, constraints, and lifecycle controls.
    • Distribute portfolios across accounts or OUs.
  • End users:
    • Discover and browse available products.
    • Launch products according to the permissions and launch constraints defined by administrators.
    • Manage provisioned product lifecycles within the allowed operations.
Administrators can enforce lifecycle controls such as termination protection, deletion policies, scheduled shutdowns (via Lambda or Systems Manager), or other automations.
A workflow infographic with two rows for Catalog Administrators and End Users. Each row shows colored icons and arrows detailing steps — admins: create, organize, manage and distribute portfolios; end users: discover, select, launch and manage product lifecycle.

​
Integrations and access control

Service Catalog integrates with these AWS controls and services to implement governance:
  • CloudFormation (templates) for provisioning.
  • AWS Identity and Access Management (IAM) to restrict who can view or launch products and which IAM roles are used during launches.
  • AWS Organizations for distributing portfolios to accounts and OUs.
  • Service Actions and automation (Lambda, Systems Manager) to expose safe, constrained operational tasks for provisioned products.
A diagram of AWS Service Catalog showing how Service Catalog entries flow to AWS CloudFormation and IAM, which provision AWS resources (compute, database, storage, S3) using portfolios and products. It also shows portfolio/product assignments deployed to organizational units like Dev, Staging, and Prod.

​
Key features

  • Products provision stacks or resource groups (managed templates), and are grouped into portfolios for distribution.
  • Granular access control: specify which users, roles, or accounts can list, view, and launch products.
  • Service Actions: expose approved operational actions for provisioned products without granting wide permissions.
  • Versioning: maintain product versions to support staged rollouts and controlled updates.
A "Features" slide showing five rounded cards with colorful icons labeled: Products, Stack or resource group, Portfolios, Granular access control, and Service actions.

​
Constraints and governance

You can apply constraints and guardrails to enforce security, compliance, and cost controls. Common constraint types include:
  • Launch constraints — require a specific IAM role when provisioning a product.
  • StackSet constraints — deploy products across multiple accounts/regions using cross-account stack deployments.
  • Tag constraints — require specific tags (billing codes, owner, contact) and validate tag patterns.
  • Resource limits — restrict instance types, allowed regions, or other resource properties.
  • Update restrictions — prevent or limit end-user updates to provisioned products.
These constraints prevent misuse and enforce organizational policies before resources are provisioned.
A presentation slide titled "Types of AWS Service Catalog Constraints" showing a three-column table of constraint types, their purposes, and examples. Examples listed include launch, stack set, and tag constraints (e.g., forcing EC2 instances to use a predefined IAM role or enforcing networking policies across accounts).

​
Best practices

  • Use IAM role constraints so products launch with least privilege and under controlled identities.
  • Enforce tagging (owner, billing codes, environment) to enable cost allocation and accountability.
  • Author each product as a validated infrastructure template (CloudFormation), organizing templates modularly with clear parameters and outputs.
  • Restrict expensive instance types and non-approved regions to control costs.
  • Keep product templates under version control and perform staged rollouts for updates.
Tagging and IAM controls are essential. Enforce required tags (billing and ownership) and ensure that only appropriate roles can launch or modify products to avoid unexpected costs or configuration drift.
A presentation slide titled "AWS Service Catalog – Best Practices" showing four recommendations. It lists: use IAM role constraints, apply tagging constraints for cost allocation, use CloudFormation templates for standardization, and prevent launching expensive instance types in non‑approved regions.

​
When to choose AWS Service Catalog

  • You need to offer self-service, pre-approved infrastructure while enforcing policies.
  • You must centrally manage templates across multiple accounts and environments (Dev, Staging, Prod).
  • You want to expose operational tasks safely via Service Actions without expanding IAM permissions.
  • Compliance or cost controls require enforced tags, constrained resource types, or standardized templates.

​
Summary

AWS Service Catalog is a governance-focused mechanism for publishing, versioning, and distributing pre-approved infrastructure templates (products) in portfolios. It integrates with CloudFormation, IAM, and Organizations to deliver controlled, repeatable provisioning at scale. Expect Service Catalog concepts (products, portfolios, constraints, launch roles, Service Actions) to appear on exams and in architecture decisions where governance, repeatability, and cost control matter. Thanks for reading this lesson.

Watch Video