IT Governance with AWS Service Catalog - Standardizing Approved Products and Enabling Self-Service
Learn how to catalog IT-approved CloudFormation templates and safely provide end-user self-service through launch constraints and template constraints.
The Role of Service Catalog
Service Catalog is a service that manages IT-approved AWS resource configurations as a catalog of up to 5,000 products, enabling end users to provision them through self-service. When end users freely create AWS resources, issues arise including security misconfigurations, cost management difficulties, and architectural inconsistency. With Service Catalog, IT teams register CloudFormation templates as products and provide only approved configurations to end users. End users simply select a product from the catalog and enter parameters, and standardized resources are provisioned automatically. Terraform templates can also be registered as products, allowing you to leverage existing IaC assets.
Designing Portfolios and Constraints
A portfolio is a collection of products that grants access to IAM principals (users, groups, roles). You can design portfolios such as a development team portfolio containing dev environment EC2 and RDS, and a data team portfolio containing Redshift and Glue. Launch constraints specify the IAM role used when provisioning a product - resources are created using the role's permissions rather than the end user's own IAM permissions. This allows you to permit resource creation only through the catalog without granting end users direct CloudFormation execution permissions. Template constraints restrict the allowed values of CloudFormation parameters, enabling controls such as limiting instance types to only t3.micro and t3.small. Setting TagOptions enforces cost allocation tags and ownership tags during provisioning, preventing cost tracking difficulties caused by missing tags.
Usage in Multi-Account Environments
Integration with Organizations lets you share portfolios created in the management account with all accounts or specific OUs in the organization. End users in each account can use products from shared portfolios, applying unified architecture patterns across the entire organization. Product version management enables gradual rollout of template updates. When a new version is published, existing provisioned products are not automatically updated - end users explicitly perform the version upgrade. This prevents unexpected impacts from updates. When used together with Control Tower, Service Catalog products can be automatically guaranteed to comply with Landing Zone guardrails. For planning Service Catalog operational design, related books (Amazon) are a helpful reference.
Design Best Practices and Pitfalls
The most critical aspect of Service Catalog design is product granularity. Including EC2 + RDS + VPC all in one product reduces flexibility, creating unnecessary resources for users who only need EC2. Conversely, making granularity too fine increases the burden on users to provision multiple products in the correct order. The recommended pattern is to separate network infrastructure (VPC, subnets) as one product, compute (EC2 + ALB) as one product, and database (RDS) as one product, connecting them via CloudFormation cross-stack references. Launch constraint IAM roles should be created with least privilege per product rather than reusing a common admin role across all products. A shared role means a vulnerability in one product could propagate access to all resources. Additionally, configuring delegated administrator accounts for portfolio sharing avoids concentrating permissions in the management account.
Service Catalog Pricing and Limits
Service Catalog itself incurs no additional charges. Costs consist only of the usage fees for provisioned AWS resources (EC2, RDS, etc.). However, if you use third-party resource types in AWS CloudFormation, charges apply per handler operation. Sharing portfolios via Organizations also incurs no additional fees, making it an attractive low-cost governance foundation for the entire organization. Template constraints that restrict instance types also reduce the risk of end users accidentally creating expensive resources. As for limits, the default quota is 100 portfolios per region and 150 products per portfolio. Large organizations may need to request quota increases. Note that provisioned product updates execute as CloudFormation stack updates, so change set compatibility requires attention.
Comparison with Related Services
Services with similar purposes to Service Catalog include AWS Proton and Control Tower. Proton targets platform engineering, achieving microservice standardization through a two-layer structure of environment templates and service templates. While Service Catalog suits general-purpose resource self-service, Proton specializes in container/serverless application deployment pipelines. Control Tower focuses on organization-wide account governance (guardrails, log aggregation, account provisioning), while Service Catalog focuses on standardizing individual resource provisioning. In practice, the common approach is to use Control Tower to establish the account foundation and Service Catalog to standardize resource provisioning within accounts.
Summary
Service Catalog is a service that balances IT governance with end-user self-service. It catalogs approved architecture patterns and enforces safe provisioning through launch constraints and template constraints. Integration with Organizations enables standardization across multi-account environments, and combining it with Control Tower builds consistent governance across the entire organization.