Service Catalog

Create and manage catalogs of approved IT services for your organization

AWS Service Catalog allows organizations to create and manage catalogs of approved IT services - CloudFormation templates, Terraform configurations, or AMIs - that developers can self-service deploy without needing direct access to the underlying infrastructure or IAM permissions. It enforces governance and standardization while enabling developer agility.

Portfolios, Products, and the Provisioning Model

Service Catalog is organized into portfolios and products. A portfolio is a collection of products shared with specific IAM principals. A product is a deployable unit - typically a CloudFormation template - that provisions AWS resources.

Concept	Description	Analogy
Portfolio	Container for products; shared with IAM users, groups, or roles	App store category or catalog section
Product	A versioned CloudFormation template or external configuration (Terraform, etc.)	A specific app in the app store
Provisioned Product	A deployed instance of a product - an actual CloudFormation stack	An installed instance of an app
Launch Constraint	IAM role that Service Catalog assumes to deploy the product; user does not need direct CloudFormation/resource permissions	Privilege escalation with guardrails
Template Constraint	Limits parameter values or hides parameters from end users	Removes choices that could violate standards

The launch constraint is the most powerful feature. You attach a role to a product that has the permissions to create the underlying resources. End users who provision the product do not need those permissions themselves - they only need the servicecatalog:ProvisionProduct permission. This enables least-privilege access while allowing self-service.

💡

Service Catalog products are most valuable for infrastructure patterns that should be standardized: approved VPC configurations, compliant RDS instances (encryption on, Multi-AZ on), pre-configured EKS clusters, or standard EC2 workload patterns with required tags and agents pre-installed.

Governance, Versioning, and Enforcing Standards

Service Catalog enforces governance at two levels: who can deploy (portfolio sharing and access control) and what they can configure (template constraints and parameter restrictions).

Governance Mechanism	What It Controls
Portfolio sharing	Which IAM roles/users/groups can see and use the portfolio
Launch constraints	The IAM role used to deploy; ensures all deployments have consistent permissions
Template constraints (allowed values)	Restrict parameter choices (e.g., only allow t3.small and t3.medium instance types)
Template constraints (hidden)	Remove parameters from the end user form entirely; hardcode the value
Notification constraint	SNS topic notified of all provisioning events in this portfolio
StackSet constraints	Deploy the product to multiple accounts and regions via CloudFormation StackSets

bash

# Create a portfolio
aws servicecatalog create-portfolio \
  --display-name "Approved Database Products" \
  --description "Pre-approved RDS configurations" \
  --provider-name "Platform Engineering Team"

# Create a product from a CloudFormation template in S3
aws servicecatalog create-product \
  --name "Standard RDS PostgreSQL" \
  --product-type CLOUD_FORMATION_TEMPLATE \
  --owner "platform-team@example.com" \
  --provisioning-artifact-parameters file://product-version.json

# Associate product with portfolio
aws servicecatalog associate-product-with-portfolio \
  --product-id prod-xxxxxxxxxx \
  --portfolio-id port-xxxxxxxxxx

Product versioning lets you release new versions of a template while maintaining backward compatibility for existing provisioned products. End users can choose to update their provisioned product to a newer version when ready.

AppRegistry - Tracking Application Resources

AWS Service Catalog AppRegistry (now branded as AWS Systems Manager Application Manager in some contexts) lets you define application groupings - logical containers that associate AWS resources and CloudFormation stacks with a specific application.

This addresses a key operational challenge: in a large AWS account, it's difficult to know which resources belong to which application. AppRegistry creates application-level views for cost allocation, compliance, and operational management.

Feature	Value
Application definition	Group CloudFormation stacks, resources, and tags under one application entity
Attribute groups	Attach structured metadata (team, compliance requirements, business unit) to applications
Cost allocation	View costs by application using the application tag propagated to all resources
Integration with Insights	Application-level health, compliance status, and operational metrics

💡

AppRegistry is often overlooked but becomes critical at scale. When you have 200 EC2 instances and 50 RDS databases across 3 accounts, application grouping is the only way to make cost allocation and incident impact analysis tractable.

Portfolio Sharing Across AWS Organizations

Service Catalog integrates with AWS Organizations to share portfolios across all accounts in an organization without manually sharing to each account. This is how platform teams publish approved infrastructure products to development teams organization-wide.

bash

# Share a portfolio with the entire organization
aws servicecatalog create-portfolio-share \
  --portfolio-id port-xxxxxxxxxx \
  --organization-node "{\"Type\": \"ORGANIZATION\", \"Value\": \"o-xxxxxxxxxxxx\"}" \
  --share-tag-options

# In a member account, list portfolios shared from the management account
aws servicecatalog list-accepted-portfolio-shares

# Accept an imported portfolio in a member account
aws servicecatalog accept-portfolio-share \
  --portfolio-id port-xxxxxxxxxx

When portfolio sharing is combined with IAM Identity Center permission sets, you can grant developers in any account access to self-service deploy approved infrastructure patterns from a central portfolio, with all deployments governed by launch constraints and template constraints defined centrally.

🎯

Interview Focus Points

1What is a launch constraint in Service Catalog and why is it more secure than giving developers direct CloudFormation permissions?
2How do template constraints differ from launch constraints - what does each control?
3How would you use Service Catalog to standardize database provisioning across 50 developer teams?
4How does Service Catalog portfolio sharing work with AWS Organizations?
5What is AppRegistry and how does it help with cost allocation in a large multi-account environment?
6Compare Service Catalog to just giving developers CloudFormation access - what does Service Catalog add?
7How does product versioning work in Service Catalog and how do end users migrate to new versions?