AWS Service Catalog

AWS Service Catalog lets a central team publish approved infrastructure and lets everyone else provision it, without giving anyone the permissions they would need to build it themselves. It is the answer to the standing tension between “developers should be able to create a database” and “developers should not have RDS administrator rights”.

Portfolios and products

• A product is a CloudFormation template packaged for self-service, with a name, a description and one or more versions.
• A portfolio is a collection of products, plus the constraints and access grants that apply to them.
• Products are versioned. An administrator can add a version or retire an old one without disturbing anything already provisioned from it.

Access is granted at the portfolio level to IAM users, groups or roles. Users see only the portfolios they have been given, and inside them only the products.

Constraints

Constraints are the rules that apply when an end user launches a product. There are five types.

Constraint	What it does	Why it matters
Launch	Names an IAM role that Service Catalog assumes to deploy the product.	Without it, the end user needs every permission the template requires in their own credentials — which defeats the point of the catalog.
Notification	Names an SNS topic to receive CloudFormation stack events.	Deployments become observable; failures reach someone.
Template	Rules that narrow the values a user may choose for a parameter.	Restrict production to approved instance types, or force encryption on anything holding personal data.
Stack set	Configures a product to deploy across multiple accounts and Regions as a CloudFormation StackSet.	One launch, many accounts — how a baseline is rolled out.
Tag update	Controls whether tags on a provisioned product can be changed after launch.	Keeps cost allocation tags from being edited away.

The launch constraint is the one that carries the security argument. It turns “grant the developer RDS admin” into “grant the developer permission to launch this product”, with the actual privileges held by a role Service Catalog assumes on their behalf.

Across multiple accounts

A portfolio can be shared from a management or central IT account to other accounts, which then import it.

• Products, launch constraints and template constraints stay synchronised with the source portfolio: update the master and imported copies follow.
• A receiving administrator can create their own local portfolios and add further constraints, making the deployment criteria more restrictive locally — but not less.
• IAM access does not travel with the share. Users, groups and roles are not inherited; the receiving administrator grants access locally.
• Launch roles are inherited from the shared portfolio by default and can be overridden with a local role, which is usually what you want when the role’s permissions differ per account.

Practices worth adopting

1. Put the templates in version control and publish product versions from a pipeline, not from the console. A catalog whose products drift from their source is worse than no catalog.
2. Use template constraints to encode the rules people would otherwise have to remember — instance types, encryption, Region.
3. Attach notification constraints from the start, so a failed provision is noticed by the platform team rather than reported by the user.
4. Review portfolio access on the same cycle as any other permission grant.
5. Keep the launch role’s permissions to what the template actually needs. It is a privileged role by design, which is exactly why it should not be AdministratorAccess.

Related: AWS Control Tower builds its Account Factory on Service Catalog, so an organization using Control Tower is already running it.