Understanding the Service Catalog in AWS

AWS Service Catalog has gotten complicated with all the portfolio management, product versioning, and governance features flying around. As someone who has implemented Service Catalog across multiple enterprise AWS environments, I learned everything there is to know about standardizing cloud resource provisioning. Today, I will share it all with you.

Here’s my typical approach for a new portfolio:

1. Identify the target audience — which teams or roles will use this portfolio?
2. List the common infrastructure patterns they need
3. Build CloudFormation templates for each pattern with sensible defaults
4. Add constraints to limit parameter choices to approved values
5. Create a launch role with least-privilege permissions
6. Share the portfolio with the appropriate accounts or OUs
7. Document each product with clear descriptions and usage guidelines

One thing I learned the hard way: keep your templates simple enough that non-infrastructure engineers can understand the parameters. If your template has 47 parameters with cryptic names, nobody will use it and they’ll go back to manually creating resources — which defeats the entire purpose.

Defining Products

Products are the heart of Service Catalog. Each product wraps a CloudFormation template and adds metadata like a description, support contact, and version history. I always include detailed descriptions that explain what the product creates, what it costs approximately, and any prerequisites.