In the previous subchapter, we saw the golden paths: prepared and secure ways to create infrastructure so that developers can self-serve without being experts. AWS offers a concrete tool to implement that idea of a "catalog of pre-approved resources that teams can deploy themselves": the AWS Service Catalog. It's like creating an internal "store" of infrastructure products approved by the company, where developers "buy" (deploy) what they need with the guarantee that it meets the standards.

A company faces a tension when giving its teams access to the cloud:

• If you give developers total freedom to create anything in AWS, they gain agility, but they can create insecure, expensive, or non-compliant resources.
• If you block everything and require every resource to be approved and created by a central team, there is control, but teams become slow (waiting for others to give them what they need), losing the agility of the cloud.

You need a middle ground: teams should be able to self-serve what they need, but only from a set of approved and secure options. That is the Service Catalog.

AWS Service Catalog allows you to create a catalog of approved infrastructure products that teams can deploy themselves, in a controlled way. The company defines what can be deployed (preconfigured and compliant products), and developers choose from that catalog and deploy it themselves, with the guarantee that it meets the standards.

Analogy: Service Catalog is like the approved purchasing catalog of a company. In a large company, you can't buy anything you want with company money freely; nor do you have to ask for permission for every pencil. There is a catalog of approved suppliers and products from which you can directly order what you need, knowing it has already been validated (price, quality, standards). Service Catalog does the same with infrastructure: an "internal store" of pre-approved resources that teams request themselves.

The platform or governance team creates products: preconfigured, secure, and compliant infrastructure templates according to company standards. These products are usually built on infrastructure as code (often connecting with the Terraform modules from subchapter 31.1, or with native AWS templates). Each product encapsulates best practices.

The products are grouped into a catalog, and it is controlled which teams can see and deploy which products (with permissions, remember IAM, Chapter 7). Thus, each team only accesses what corresponds to them.

A developer enters the catalog, chooses the product they need (for example, "standard database"), fills in a few parameters, and deploys it themselves. They get their infrastructure in minutes, without waiting for anyone and with the guarantee that it meets the standards (because the product was already approved).

The great value of Service Catalog is achieving the balance between freedom and control: teams have autonomy to self-serve (agility), but within safe limits defined by the company (governance). It's "freedom within a framework":

This links directly to the golden paths (subchapter 31.1): Service Catalog is a way to offer those golden paths as concrete products that teams deploy. And it reinforces security and compliance (Chapter 23) without sacrificing speed.

Real-world example: a company wants its teams to be agile but without creating insecure resources. They set up an AWS Service Catalog with pre-approved products: "standard web application," "standard database," "compliant storage bucket," etc., all built following their best practices for security and cost. They give each team access to the products they need. Now, when a team needs a database, they deploy it themselves from the catalog in minutes, instead of opening a ticket and waiting days for the central team. And the company has the peace of mind that everything deployed is pre-approved and compliant. They have gained agility and maintained control: teams move fast, but on safe paths.

• There is a tension between giving teams total freedom (agile but risky) and locking everything down (safe but slow); the solution is controlled freedom.
• AWS Service Catalog allows you to create a catalog of approved infrastructure products that teams deploy themselves, in a controlled way. Like an internal store of pre-approved products for the company.
• It works in three steps: the company defines products (secure and compliant templates, often on Terraform), organizes them into a catalog with permissions, and developers self-serve (choose, fill in a few parameters, and deploy).
• Its value: governed self-service — team autonomy (agility) within safe limits defined by the company (control). "Freedom within a framework."
• It is a way to offer the golden paths (subchapter 31.1) as concrete products, reinforcing security and compliance without sacrificing speed.

In the next subchapter, we will see a very popular tool to give developers a unified "portal" from which to access all this: Backstage.