AWS Services
AWS Service Catalog
Understand AWS Service Catalog for approved self-service AWS products, including portfolios, products, provisioned products, constraints, governance, CloudFormation integration, security, cost, and SAA-C03 traps.
After this, you will understand
Service Catalog helps learners understand governed self-service: teams can launch approved infrastructure without broad direct access to every AWS service.
AWS Service Catalog publishes approved AWS products in portfolios so users can launch them within administrator-defined constraints.
Learners give every team broad AWS permissions or confuse Service Catalog with CloudFormation itself.
Use Service Catalog when central platform teams need to offer approved, versioned, constrained AWS products for self-service deployment.
Think before readingWhat problem does Service Catalog solve that CloudFormation alone does not?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- AWS Service Catalog
- Approved IT services
- Catalogs, portfolios, products, and provisioned products
- CloudFormation-backed products
- Constraints and access control
- Self-service infrastructure
- Governance and standardization
- Service Catalog versus CloudFormation, Control Tower, and Organizations
- Cost and compliance traps
1. Plain-English Mental Model
AWS Service Catalog is an approved menu of AWS things people are allowed to launch.
The simple model is:
platform team creates approved products -> users launch only allowed products -> constraints enforce guardrails
CloudFormation answers: "How do we provision this infrastructure from a template?"
Service Catalog answers: "Which approved infrastructure options should users be allowed to provision, and under what rules?"
This matters in larger organizations because giving every team full AWS access creates drift, security risk, inconsistent tagging, and surprise cost. Service Catalog turns platform governance into self-service instead of ticket-driven provisioning.
2. Why This Service Exists
Organizations want speed and control at the same time.
Application teams want to launch databases, development environments, analytics workspaces, machine images, or multi-tier application stacks without waiting days for central IT.
Security and platform teams want those resources to follow standards: approved AMIs, allowed instance types, required tags, controlled Regions, network placement, IAM boundaries, and compliance settings.
The naive solution is either too open or too slow. Full access is fast but risky. Ticket-based provisioning is controlled but slow.
Service Catalog exists to publish approved products that users can launch themselves inside administrator-defined boundaries.
For SAA-C03, Service Catalog appears in questions about self-service provisioning, approved products, standardized deployments, governance, compliance, and restricting what users can launch.
3. The Naive Approach And Where It Breaks
The naive pattern is:
give developers broad IAM -> ask them to follow standards -> audit later
This breaks because standards become optional under deadline pressure. Teams pick different instance types, skip tags, create public resources, choose unapproved AMIs, or forget logging.
Another naive pattern is central provisioning through tickets. That protects control but creates bottlenecks and frustrates teams. People work around it or duplicate infrastructure.
A third mistake is using CloudFormation alone as the self-service layer. CloudFormation can define a template, but it does not by itself provide a curated catalog, portfolio access model, launch constraints, and product governance experience for end users.
Service Catalog adds the governed distribution layer.
4. Core Primitives
A catalog is the collection of approved IT services managed through Service Catalog.
A portfolio groups products and controls access. Administrators grant users, groups, or roles access to portfolios.
A product is an approved service or application that users can launch. Products are often backed by CloudFormation templates.
A product version lets administrators update the approved template or configuration over time.
A provisioned product is the running instance of a product launched by an end user.
Constraints define rules for launching products. Launch constraints, template constraints, tag update constraints, notification constraints, and StackSet constraints support governance.
TagOptions help standardize tagging choices.
Access control determines who can see and launch which products.
5. Architecture Use Cases
Use Service Catalog when a central cloud platform team wants to offer approved application stacks:
approved CloudFormation template -> Service Catalog product -> developer self-service launch
Use portfolios to separate products by team, environment, compliance level, or workload type.
Use constraints to limit allowed instance types, required parameter values, launch roles, or tagging behavior.
Use product versions to roll out new approved infrastructure patterns without forcing every team to build from scratch.
Use Service Catalog with Organizations or Control Tower in multi-account environments where account vending and standardized products are part of the platform.
Use CloudFormation directly when a platform automation pipeline owns deployment and no end-user catalog is needed.
7. Security Model
Service Catalog security is about controlled delegation.
End users can launch approved products without needing broad permission to directly create every underlying resource.
Launch constraints can let products run under specific IAM roles. That helps separate "permission to request a product" from "permission to create all resources inside the product."
Template constraints can restrict parameters so users cannot choose unsafe or expensive values.
Portfolio access controls who can see and launch products.
Service Catalog does not replace IAM, SCPs, Config rules, CloudTrail, or security reviews. It complements them by reducing the chance that unapproved infrastructure is launched in the first place.
Product templates still need secure defaults.
8. Reliability And Resilience
Service Catalog improves reliability indirectly through standardization.
If every team launches a vetted RDS pattern, a standard VPC attachment, or a known-good application stack, fewer teams invent fragile one-off designs.
Versioned products help platform teams improve patterns over time.
However, launching an approved product does not guarantee it meets every workload's recovery objective. The underlying product design still needs Multi-AZ, backup, monitoring, scaling, and runbooks where required.
Provisioned product lifecycle matters. Teams need clear rules for updates, ownership, deprovisioning, and support.
If the central catalog is stale, users may avoid it. Governance must stay useful to remain adopted.
9. Performance And Scaling
Service Catalog is not a performance data-plane service. It affects how infrastructure is provisioned and governed.
Its scaling challenge is organizational: many teams, many accounts, many approved products, many versions, and many constraints.
Large organizations should design portfolios so users can find the right product quickly.
Too many products create confusion. Too few products force exceptions.
Performance of launched workloads depends on the underlying CloudFormation templates and AWS services, not on Service Catalog itself.
10. Cost Model
Service Catalog helps cost control by standardizing approved choices.
Template constraints can limit instance sizes, storage options, or parameter values.
TagOptions can improve cost allocation.
Portfolio design can keep expensive products available only to teams or environments that need them.
The provisioned resources still create normal AWS charges. Service Catalog is not a cost shield if approved products are oversized or left running.
Good product lifecycle policy includes ownership, expiration, cleanup, and budget visibility.
12. SAA-C03 Exam Signals
"Users should launch only approved AWS resources" points to Service Catalog.
"Central IT wants standardized self-service products" points to Service Catalog.
"Governed portfolio of approved infrastructure" points to Service Catalog.
"Restrict parameters users can choose when launching a product" points to Service Catalog constraints.
"Provision resources from a template" by itself points to CloudFormation.
"Manage accounts and landing zones" points to Control Tower or Organizations, not Service Catalog alone.
"Prevent actions across accounts with policy guardrails" points to SCPs, not Service Catalog.
13. Common Exam Traps
Do not choose Service Catalog when the only requirement is infrastructure as code. Choose CloudFormation.
Do not choose CloudFormation alone when the requirement is an approved self-service catalog for end users.
Do not treat Service Catalog as an identity provider. IAM and IAM Identity Center handle identity and permissions.
Do not assume Service Catalog prevents every bad action after launch. Use IAM, SCPs, Config, CloudTrail, and monitoring too.
Do not ignore product versioning and update lifecycle.
Do not publish products with insecure defaults.
15. Related Topics
Review AWS CloudFormation first because many Service Catalog products are backed by CloudFormation templates.
Next, study AWS Control Tower, AWS Organizations, and Service Control Policies to place Service Catalog inside a multi-account governance model.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.