AWS Service Catalog Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Management and governance

by

Category

Management and governance

1. Introduction

AWS Service Catalog is an AWS Management and governance service that helps organizations create a curated “menu” of approved cloud resources—called products—that users can provision safely and consistently.

In simple terms: platform or cloud administrators publish pre-approved templates (for example, “S3 bucket with encryption and blocked public access” or “standard VPC for apps”), and developers or application teams self-service provision those templates without needing broad permissions or deep infrastructure knowledge.

Technically, AWS Service Catalog organizes infrastructure blueprints into products (usually backed by AWS CloudFormation templates) grouped into portfolios, applies governance controls (constraints, tagging, access rules), and provisions them as provisioned products (typically implemented as CloudFormation stacks). It integrates with AWS IAM, AWS Organizations, AWS CloudTrail, and other governance services so you can scale self-service while retaining guardrails.

The problem it solves is common in growing AWS environments: without standardization, teams create inconsistent architectures, security controls drift, cost allocation tags are missing, and privileged access spreads. AWS Service Catalog centralizes approved patterns and enforces enterprise governance while still enabling fast delivery.

2. What is AWS Service Catalog?

Official purpose (in AWS terms): AWS Service Catalog enables organizations to create and manage catalogs of IT services (approved AWS resources) and allow users to provision them in a controlled manner. It is designed to help you achieve governance at scale while supporting self-service.

Core capabilities – Build a catalog of approved infrastructure products (most commonly CloudFormation-based). – Group products into portfolios and control who can see and provision them. – Enforce governance using constraints (for example, require provisioning through a specific IAM role). – Standardize tagging and metadata for cost allocation and operations. – Track and manage provisioned products over time, including updates and termination. – Provide application-level organization via AWS Service Catalog AppRegistry (a capability within the AWS Service Catalog console and APIs).

Major components – Portfolio: A collection of products, plus sharing and access controls. – Product: A deployable “blueprint,” typically a CloudFormation template plus metadata. – Provisioning artifact: A version of a product (for example, v1 template, v2 template). – Constraint: A rule that controls how a product is provisioned (launch role, notifications, etc.). – Provisioned product: What a user gets after provisioning a product (often a CloudFormation stack). – AppRegistry (optional but common): Define an “application” and associate AWS resources for governance and operations.

Service type – Management and governance service that orchestrates provisioning. – Control-plane heavy; it typically provisions resources into your account using AWS CloudFormation (and the permissions you define).

Regional / global scope – AWS Service Catalog is a regional service: portfolios, products, and provisioned products are created and managed per region. – Multi-account usage is common via AWS Organizations portfolio sharing, but the objects remain regional in each account/region where used.

How it fits into the AWS ecosystem AWS Service Catalog sits between platform governance and infrastructure provisioning: – Works closely with AWS IAM (who can provision and what role is used). – Provisions resources largely via AWS CloudFormation. – Supports enterprise multi-account patterns via AWS Organizations (portfolio sharing). – Audited by AWS CloudTrail, and often combined with AWS Config, Security Hub, Control Tower, and tagging strategies. – Complements developer and platform experiences when integrated with ITSM tools (for example, ServiceNow via connectors—verify current integrations in official docs for your environment).

3. Why use AWS Service Catalog?

Business reasons

  • Faster delivery with guardrails: teams provision pre-approved solutions quickly without waiting for manual reviews each time.
  • Standardization: consistent architectures reduce outages and rework.
  • Cost allocation and chargeback: consistent tagging and product metadata improves financial governance.
  • Reduced platform toil: fewer one-off infrastructure requests to central teams.

Technical reasons

  • Repeatable infrastructure: versioned provisioning artifacts provide controlled evolution of templates.
  • Separation of duties: end users can provision without broad infrastructure permissions.
  • Multi-account scalability: share portfolios across accounts in AWS Organizations for consistent patterns.

Operational reasons

  • Lifecycle management: provisioned products can be updated/terminated through a controlled interface.
  • Operational visibility: integration with CloudTrail and (optionally) AppRegistry improves traceability.
  • Controlled operational actions: AWS Service Catalog can expose approved “day-2” actions (often implemented via AWS Systems Manager Automation documents—verify applicability for your products).

Security/compliance reasons

  • Least privilege: users don’t need direct permissions to create underlying resources if you use launch roles and carefully scoped access.
  • Policy enforcement: constraints and template design enforce security baselines (encryption, network boundaries, logging).
  • Auditability: provisioning events are captured by CloudTrail; templates are reviewable and versioned.

Scalability/performance reasons

  • AWS Service Catalog is not a data-plane service; it scales primarily with governance and provisioning operations.
  • It supports large organizations by centralizing patterns and distributing them across accounts/teams without copying scripts everywhere.

When teams should choose it

Choose AWS Service Catalog when you need: – A curated, governed catalog of infrastructure for many teams. – Strong access control and self-service provisioning. – Multi-account governance via AWS Organizations. – Standard templates with controlled versioning and lifecycle.

When they should not choose it

Avoid (or reconsider) AWS Service Catalog if: – You only have a few stacks and no governance need—plain CloudFormation might be simpler. – You need a full internal developer portal with software catalog, scorecards, golden paths, and deep developer workflows—consider pairing with a developer portal (for example, Backstage) and using AWS Service Catalog for the governed provisioning backend. – Your organization mandates Terraform-only workflows and you don’t want CloudFormation as the primary provisioning mechanism (AWS Service Catalog can coexist with Terraform, but validate current product support and organizational fit in official docs).

4. Where is AWS Service Catalog used?

Industries

  • Financial services (strict guardrails, audit, and separation of duties)
  • Healthcare and life sciences (compliance, standardized encryption/logging)
  • Public sector (governance, repeatable baselines)
  • SaaS and technology (platform teams offering self-service)
  • Manufacturing/retail (multi-account environments, cost allocation)

Team types

  • Platform engineering teams building “paved roads”
  • Cloud Center of Excellence (CCoE)
  • Security engineering teams enforcing baselines
  • DevOps/SRE teams standardizing deployment building blocks
  • Shared services/IT teams providing internal catalogs

Workloads

  • Standard network foundations (VPC patterns)
  • Data platforms (approved S3/KMS/Glue patterns)
  • Application stacks (ECS/EKS base clusters, RDS patterns)
  • Observability stacks (CloudWatch alarms/dashboards baselines)
  • Sandbox/dev environments with constrained spend and access

Architectures and deployment contexts

  • Multi-account landing zones using AWS Organizations (often with AWS Control Tower)
  • Central “catalog” account sharing portfolios to workload accounts
  • Environment isolation patterns: dev/test/prod portfolios with different constraints
  • Hybrid governance: AWS Service Catalog + SCPs + IAM permissions boundaries + AWS Config rules

Production vs dev/test usage

  • Production: most value comes from strict governance—launch roles, constraints, mandatory tags, and well-reviewed templates.
  • Dev/test: can use more permissive portfolios but still enforce tagging and budget controls (often via separate accounts and SCPs).

5. Top Use Cases and Scenarios

Below are realistic ways AWS Service Catalog is used in real organizations.

1) Standard VPC “landing zone” blueprint

  • Problem: teams build VPCs differently, leading to security gaps and peering/routing chaos.
  • Why AWS Service Catalog fits: publish an approved VPC product with standardized subnets, flow logs, endpoints, and tags.
  • Scenario: a new application team provisions “VPC-Standard-3AZ” that automatically enables flow logs and private subnets.

2) Approved S3 buckets with encryption and public access blocked

  • Problem: inconsistent S3 settings cause data exposure risk.
  • Why it fits: template enforces encryption, block public access, and required tags.
  • Scenario: analysts provision “S3-Data-Bucket” that defaults to encryption and denies public ACLs.

3) RDS database with organization-approved parameters

  • Problem: teams launch databases without backups, logging, or encryption.
  • Why it fits: product preconfigures backups, KMS encryption, parameter groups, and subnet groups.
  • Scenario: a product “RDS-Postgres-Standard” provisions encrypted storage, automated backups, and CloudWatch logs export.

4) ECS/Fargate service baseline

  • Problem: services are deployed with inconsistent IAM roles, logging, and networking.
  • Why it fits: a product can standardize task execution roles, log drivers, and VPC settings.
  • Scenario: dev teams choose “ECS-Service-Baseline” and supply only app image and CPU/memory.

5) EKS cluster blueprint with controlled versions

  • Problem: unmanaged Kubernetes versions and add-ons create security and reliability risk.
  • Why it fits: versioned provisioning artifacts control when cluster upgrades are allowed.
  • Scenario: platform team publishes EKS v1.29 baseline; later adds v1.30 artifact after validation.

6) Developer sandbox accounts or environments (paired with multi-account strategy)

  • Problem: developers need autonomy but must stay within guardrails.
  • Why it fits: combined with AWS Organizations sharing and account boundaries; catalog provides safe building blocks.
  • Scenario: sandbox users can provision only pre-approved stacks with budget tags and limited instance types.

7) Approved CI/CD pipeline templates

  • Problem: every team creates pipelines differently; security scans and approvals are inconsistent.
  • Why it fits: product builds standardized CodePipeline/CodeBuild configurations with required scanning and artifact encryption.
  • Scenario: “Pipeline-Standard” provisions a pipeline with mandatory SAST step and artifact bucket encryption.

8) Shared observability components (alarms, dashboards, logging baselines)

  • Problem: missing alarms and inconsistent log retention cause slow incident response.
  • Why it fits: product provisions CloudWatch alarms/dashboards and log retention policies.
  • Scenario: every service provisions “Observability-Baseline” to get standard alarms and dashboards.

9) Network connectivity patterns (VPC endpoints, private connectivity)

  • Problem: public egress is overused; security teams want private access patterns.
  • Why it fits: product provisions VPC endpoints and route tables consistently.
  • Scenario: a product “Private-S3-Access” adds gateway endpoint and updates route tables.

10) Pre-approved partner software stacks (internal catalog experience)

  • Problem: teams deploy third-party stacks inconsistently and with licensing mistakes.
  • Why it fits: catalog metadata, constraints, and standard parameters reduce errors.
  • Scenario: “Vendor-Logging-Agent” product deploys with approved configuration and tagging.

11) Controlled operational actions (day-2 operations)

  • Problem: teams need safe operations (restart service, rotate keys) without full admin access.
  • Why it fits: Service Catalog can expose approved actions tied to automation (commonly AWS Systems Manager Automation).
  • Scenario: end users can run “Restart-App” action on their provisioned product without being allowed to modify infrastructure directly.

12) Application organization and governance using AppRegistry

  • Problem: it’s hard to understand what resources belong to which application across accounts/regions.
  • Why it fits: AppRegistry can model applications and associate resources for visibility and governance.
  • Scenario: platform team requires each provisioned stack to register resources under an AppRegistry application.

6. Core Features

This section focuses on important, current AWS Service Catalog features used in real environments. If a feature’s availability varies by region or account setup, verify in official docs.

Portfolios (collection + governance boundary)

  • What it does: groups products and controls access and sharing.
  • Why it matters: portfolios become the unit of governance (who can see what).
  • Practical benefit: separate dev/test/prod or business-unit catalogs cleanly.
  • Caveats: portfolios are regional; sharing across accounts requires planning (often AWS Organizations).

Products (approved blueprints)

  • What it does: defines deployable templates and metadata.
  • Why it matters: templates encode standards (security, networking, tagging).
  • Practical benefit: teams stop reinventing infrastructure patterns.
  • Caveats: product quality depends on template quality and review rigor.

Provisioning artifacts (versioning)

  • What it does: maintains versions of a product (v1, v2, etc.).
  • Why it matters: enables controlled evolution and rollback strategies.
  • Practical benefit: you can release updates without breaking existing consumers.
  • Caveats: updating provisioned products can still be disruptive depending on CloudFormation change sets.

Constraints (governance controls)

  • What it does: enforces rules around provisioning.
  • Why it matters: reduces privilege sprawl and prevents unsafe deployments.
  • Practical benefit: ensure provisioning uses approved IAM roles and parameters.
  • Caveats: constraint types and behaviors differ; test constraints with realistic user roles.

Common constraint patterns include: – Launch constraints: require provisioning through a specified IAM role. – Notification constraints: send events to SNS topics (useful for ops awareness). – Template constraints: enforce additional rules on template parameters (verify exact format/behavior in official docs). – Tag-related controls: support controlled tagging behavior (verify current options in official docs).

IAM-based access control (admin vs end users)

  • What it does: uses IAM policies to manage who administers catalogs and who provisions products.
  • Why it matters: enables separation of duties.
  • Practical benefit: end users can provision without being infrastructure admins.
  • Caveats: mis-scoped IAM permissions can either block provisioning or create security gaps.

Portfolio sharing (multi-account governance)

  • What it does: share portfolios across accounts, commonly using AWS Organizations.
  • Why it matters: central platform team can publish standards to many accounts.
  • Practical benefit: consistent patterns across the enterprise.
  • Caveats: cross-account role setup, access principals, and region planning can be non-trivial.

TagOptions (controlled tag vocabulary)

  • What it does: lets admins define approved tag key/value pairs and associate them with portfolios/products.
  • Why it matters: improves cost allocation and governance consistency.
  • Practical benefit: users pick from approved tags rather than free-typing.
  • Caveats: TagOptions help standardize but do not replace mandatory-tag enforcement (you may still need SCPs, IAM conditions, or template logic to enforce).

Provisioned product lifecycle management

  • What it does: provision, update, and terminate provisioned products.
  • Why it matters: provides a controlled lifecycle instead of ad-hoc stack changes.
  • Practical benefit: supports “day-1” provisioning and controlled updates.
  • Caveats: terminating a provisioned product usually deletes underlying resources; deletions can fail if resources have dependencies (for example, non-empty S3 bucket).

Integration with AWS CloudFormation (primary provisioning engine)

  • What it does: provisions most products as CloudFormation stacks.
  • Why it matters: CloudFormation provides declarative infrastructure and drift-aware updates.
  • Practical benefit: you can reuse your existing CloudFormation standards, linting, and security scanning.
  • Caveats: CloudFormation limitations apply (resource coverage, update behaviors, rollback constraints).

Service actions (controlled operational tasks)

  • What it does: allows admins to attach operational actions to provisioned products, commonly backed by automation documents.
  • Why it matters: gives users safe self-service operations without broad permissions.
  • Practical benefit: reduce tickets for common operational tasks (restart, rotate, patch).
  • Caveats: action implementation must be secured; verify how actions are executed and authorized in official docs.

AWS Service Catalog AppRegistry (application-centric governance)

  • What it does: helps define applications and associate resources for governance, operations, and visibility.
  • Why it matters: improves application ownership, inventory, and consistent metadata.
  • Practical benefit: align resources, stacks, and teams under an “application” concept.
  • Caveats: requires consistent adoption; it’s an organizational discipline as much as a tool.

Auditing via AWS CloudTrail

  • What it does: records Service Catalog API calls and provisioning operations.
  • Why it matters: compliance, incident investigation, and change tracking.
  • Practical benefit: you can answer “who provisioned what, when, and how.”
  • Caveats: ensure CloudTrail is configured organization-wide where required.

7. Architecture and How It Works

High-level architecture

At a high level, AWS Service Catalog operates as a governance and orchestration layer:

  1. Administrators create portfolios and products (templates + metadata).
  2. Administrators define who can access portfolios and add constraints (for example, a launch role).
  3. End users browse the catalog and provision products.
  4. AWS Service Catalog orchestrates provisioning—most commonly by calling AWS CloudFormation to create/update/delete stacks.
  5. Provisioning events and API calls are logged in AWS CloudTrail; resource-level logging depends on the resources you provision.

Request / data / control flow

  • Control plane: Service Catalog APIs (create portfolio/product, associate principals, provision product).
  • Provisioning control: Service Catalog calls CloudFormation using the permissions granted via launch roles/constraints and IAM.
  • Data plane: the provisioned resources’ traffic is not handled by Service Catalog; it is handled by the resources themselves (EC2, S3, RDS, etc.).

Key integrations

  • AWS CloudFormation: template execution and lifecycle management for provisioned products.
  • AWS IAM: policies for admins/end users; roles for provisioning (launch constraints).
  • AWS Organizations: portfolio sharing and enterprise-scale distribution.
  • AWS CloudTrail: audit of API activity.
  • Amazon SNS: often used with notification constraints (ops notifications).
  • AWS Systems Manager: commonly used for service actions and operational automation (verify setup in official docs).
  • AWS Config / Security Hub: often used to validate that provisioned resources comply with policies (complementary, not enforced purely by Service Catalog).

Dependency services

  • CloudFormation is a foundational dependency for CloudFormation-based products.
  • IAM is required for any meaningful access control model.
  • If using multi-account sharing: AWS Organizations is typically required.

Security and authentication model

  • Authentication and authorization rely on AWS IAM.
  • Admins manage catalogs; end users provision products.
  • Launch constraints can ensure provisioning occurs with a tightly scoped role rather than the end user’s permissions.
  • Cross-account sharing requires explicit trust and permissions in target accounts.

Networking model

  • AWS Service Catalog itself does not run inside your VPC.
  • Provisioned products can be VPC-based (EC2/EKS/RDS) or public services (S3, SNS, etc.) depending on templates.
  • For private enterprise environments, governance often includes VPC endpoints for provisioned services (for example, S3 gateway endpoint, interface endpoints) but those are part of your templates, not Service Catalog’s network plane.

Monitoring/logging/governance considerations

  • CloudTrail for API auditing.
  • CloudFormation events for provisioning success/failure and rollback.
  • CloudWatch metrics/logs for the provisioned resources (not Service Catalog).
  • Enterprise governance often includes:
  • mandatory tagging (IAM conditions, SCPs, or template enforcement),
  • drift detection (CloudFormation), and
  • compliance checks (AWS Config).

Simple architecture diagram (conceptual)

flowchart LR
  A[Admin / Platform Team] -->|Create portfolios & products| SC[AWS Service Catalog]
  U[End User] -->|Provision product| SC
  SC -->|Orchestrate| CF[AWS CloudFormation]
  CF --> R[Provisioned Resources\n(S3/EC2/RDS/VPC...)]
  SC --> CT[AWS CloudTrail]
  CF --> CT

Production-style architecture diagram (multi-account)

flowchart TB
  subgraph Org[AWS Organizations]
    Mgmt[Management / Catalog Account]
    Dev[Dev Account]
    Prod[Prod Account]
  end

  IdP[IAM Identity Center / IAM Federation] --> Users[Developers & App Teams]

  subgraph CatalogRegion[Region (e.g., us-east-1)]
    SC[AWS Service Catalog\n(Portfolios, Products)]
    AR[AppRegistry\n(Applications)]
  end

  Mgmt -->|Share portfolios| SC
  Users -->|Assume role| Dev
  Users -->|Assume role| Prod

  Dev -->|Provisioned product request| SC
  Prod -->|Provisioned product request| SC

  SC --> CFDev[CloudFormation in Dev]
  SC --> CFProd[CloudFormation in Prod]

  CFDev --> DevRes[Dev Resources\n(VPC/S3/RDS/ECS...)]
  CFProd --> ProdRes[Prod Resources\n(VPC/S3/RDS/ECS...)]

  SC --> CT[CloudTrail (org trail)]
  CFDev --> CT
  CFProd --> CT

  DevRes --> Config[AWS Config / Rules]
  ProdRes --> Config

  SC --> SNS[SNS Notifications\n(optional constraints)]
  SC --> SSM[Systems Manager\n(optional actions)]

8. Prerequisites

Before you start the lab and before using AWS Service Catalog in real environments, ensure you have the following.

Account requirements

  • An active AWS account with billing enabled.
  • If using multi-account patterns: AWS Organizations (optional for this lab, common in production).

Permissions / IAM roles

For the lab, you’ll use two personas: – AWS Service Catalog administrator (platform admin) – AWS Service Catalog end user (consumer)

AWS provides managed IAM policies commonly used for quick starts: – AWSServiceCatalogAdminFullAccess – AWSServiceCatalogEndUserFullAccess

For production, prefer custom least-privilege policies aligned to your governance model.

You will also create an IAM role used as a launch constraint (so end users can provision without broad IAM permissions).

Billing requirements

  • AWS Service Catalog itself is typically no additional charge (see pricing section), but the underlying resources provisioned by templates can incur charges.

Tools

  • AWS Management Console access
  • AWS CLI v2 (recommended for repeatability): https://docs.aws.amazon.com/cli/
  • Optional: a text editor for CloudFormation templates

Region availability

  • AWS Service Catalog is regional. Choose a supported region where you already deploy workloads.
  • This tutorial examples assume us-east-1, but you can use another region.

Quotas / limits

  • AWS Service Catalog has quotas (for example, around numbers of portfolios/products/associations).
  • CloudFormation has quotas (stacks, resources per stack, etc.).
  • Check Service Quotas for “AWS Service Catalog” and “AWS CloudFormation” in your region: https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html

Prerequisite services

  • AWS CloudFormation (used by the product in this tutorial)
  • AWS IAM (for roles and access control)
  • Amazon S3 (for the lab product)

9. Pricing / Cost

Current pricing model (accurate framing)

AWS Service Catalog pricing is generally: – No additional charge for using AWS Service Catalog features. – You pay for AWS resources you provision through the catalog (for example, EC2, RDS, S3, CloudWatch, data transfer).

Always confirm the latest statement on the official pricing page: – Official pricing: https://aws.amazon.com/servicecatalog/pricing/ – AWS Pricing Calculator: https://calculator.aws/#/

Pricing dimensions (what you actually pay for)

Because Service Catalog provisions other services, costs depend on: – Compute: EC2/Fargate/EKS nodes, Lambda executions – Storage: S3, EBS, EFS, RDS storage – Network: NAT gateways, load balancers, data transfer – Observability: CloudWatch logs, metrics, alarms – Security: KMS keys/requests, GuardDuty, Security Hub (if enabled), etc.

Free tier

  • AWS Service Catalog itself typically does not have a metered price line item.
  • The AWS Free Tier may reduce costs of underlying services (for example, some EC2 or S3 usage) depending on your account age and region. Verify in the Free Tier details: https://aws.amazon.com/free/

Cost drivers (direct and indirect)

Direct: – The resources created by the CloudFormation templates.

Indirect / hidden: – Logging: CloudTrail logs delivered to S3, CloudWatch logs retention. – Network architecture: NAT gateways and load balancers can dominate costs. – Operational sprawl: too many small stacks can increase operational overhead (not billed directly, but increases engineering time).

Network/data transfer implications

Service Catalog itself does not move application data, but products may provision: – Internet-facing load balancers (data processing + transfer) – NAT gateways (hourly + per-GB processing) – Cross-AZ traffic patterns

How to optimize cost with AWS Service Catalog

  • Publish cost-optimized products (right-sized instance types, autoscaling, lifecycle policies).
  • Use tagging and enforce cost allocation tags for chargeback/showback.
  • Provide tiered products (dev vs prod) with different sizes and constraints.
  • Use separate portfolios with allowed instance types and budgets (budget enforcement may require additional governance tooling—verify best approach in official docs and your org’s landing zone).

Example low-cost starter estimate (lab-style)

A starter catalog product that provisions only: – 1 S3 bucket with encryption and public access blocked, – minimal or no stored objects, will typically incur near-zero ongoing cost (S3 request/storage charges may be minimal). Exact costs depend on storage used, request volume, and region—use the Pricing Calculator for your region.

Example production cost considerations

A production catalog might include products for: – VPC + NAT gateways + ALBs + EKS/ECS + RDS In that case, networking (NAT/ALB) and databases often dominate monthly spend. Your catalog should include cost guardrails (right-sizing, autoscaling defaults, environment-based constraints).

10. Step-by-Step Hands-On Tutorial

Objective

Create a small, real AWS Service Catalog setup: – A portfolio named Storage-Standards – A CloudFormation-backed product named S3-Encrypted-Bucket – A launch role used via a launch constraint – An end user who can provision the product safely – Provision, validate, update, terminate, and clean up

Lab Overview

You will: 1. Create an IAM end user for Service Catalog (lab-only). 2. Create a launch role for provisioning. 3. Create a portfolio and a product (CloudFormation template). 4. Associate product + principal + constraint. 5. Sign in as the end user and provision the product. 6. Validate resources in S3 and CloudFormation. 7. Update and terminate the provisioned product. 8. Clean up all created artifacts.

Safety notes – This lab is designed to be low-cost (S3 bucket only), but charges can still occur depending on usage. – Do not store data in the lab bucket; keep it empty to ensure termination succeeds.

Step 1: Choose a region and set up AWS CLI

  1. Pick a region (example: us-east-1) and use it consistently for the lab.
  2. Configure your CLI credentials (admin persona).
aws configure
aws sts get-caller-identity

Expected outcome: you can successfully call AWS APIs and see your account ID.

Step 2: Create a lab end user (console sign-in) for Service Catalog

In production, prefer IAM Identity Center with roles. For this lab, an IAM user is straightforward.

  1. Go to IAM → Users → Create user
  2. User name: sc-enduser
  3. Select Provide user access to the AWS Management Console
  4. Set a password (or auto-generate) and require password reset (optional)
  5. Attach permission policy: AWSServiceCatalogEndUserFullAccess

Expected outcome: you have a console sign-in URL and credentials for sc-enduser.

Verification – Sign in as sc-enduser – Open AWS Service Catalog console – You may not see any products yet (that’s expected until you grant portfolio access).

Step 3: Create an IAM launch role for provisioning (Launch Constraint role)

This role will be used by AWS Service Catalog to provision the CloudFormation stack. The end user won’t need direct S3 or CloudFormation permissions beyond using Service Catalog.

3.1 Create trust policy

Create a file named sc-launch-role-trust.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "servicecatalog.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Create the role:

aws iam create-role \
  --role-name SCLaunchRoleS3Product \
  --assume-role-policy-document file://sc-launch-role-trust.json

3.2 Attach permissions policy (lab scope)

Create sc-launch-role-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CloudFormationProvisioning",
      "Effect": "Allow",
      "Action": [
        "cloudformation:CreateStack",
        "cloudformation:UpdateStack",
        "cloudformation:DeleteStack",
        "cloudformation:DescribeStacks",
        "cloudformation:DescribeStackEvents",
        "cloudformation:GetTemplateSummary",
        "cloudformation:ValidateTemplate",
        "cloudformation:ListStackResources"
      ],
      "Resource": "*"
    },
    {
      "Sid": "S3BucketProvisioning",
      "Effect": "Allow",
      "Action": [
        "s3:CreateBucket",
        "s3:DeleteBucket",
        "s3:GetBucketLocation",
        "s3:PutBucketEncryption",
        "s3:PutBucketPublicAccessBlock",
        "s3:PutBucketVersioning",
        "s3:PutBucketTagging",
        "s3:GetBucketEncryption",
        "s3:GetBucketPublicAccessBlock",
        "s3:GetBucketVersioning",
        "s3:GetBucketTagging"
      ],
      "Resource": "*"
    }
  ]
}

Attach it as an inline policy:

aws iam put-role-policy \
  --role-name SCLaunchRoleS3Product \
  --policy-name SCLaunchRoleS3ProductPolicy \
  --policy-document file://sc-launch-role-policy.json

Expected outcome: an IAM role exists with a trust relationship for Service Catalog and permissions to create/update/delete the CloudFormation stack and S3 bucket settings.

Verification

aws iam get-role --role-name SCLaunchRoleS3Product

Step 4: Create a CloudFormation template for the product

Create a file named s3-encrypted-bucket.yaml:

AWSTemplateFormatVersion: "2010-09-09"
Description: "Service Catalog product: S3 bucket with encryption + block public access + optional versioning"

Parameters:
  EnableVersioning:
    Type: String
    Default: "Suspended"
    AllowedValues:
      - "Enabled"
      - "Suspended"
    Description: "Enable or suspend S3 versioning"

  CostCenter:
    Type: String
    Default: "unknown"
    Description: "Cost allocation tag value (example: cc-1234)"

Resources:
  Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        IgnorePublicAcls: true
        BlockPublicPolicy: true
        RestrictPublicBuckets: true
      VersioningConfiguration:
        Status: !Ref EnableVersioning
      Tags:
        - Key: cost-center
          Value: !Ref CostCenter
        - Key: managed-by
          Value: aws-service-catalog

Outputs:
  BucketName:
    Description: "Name of the created S3 bucket"
    Value: !Ref Bucket

Expected outcome: you have a valid CloudFormation template that creates a secure-by-default S3 bucket.

Verification

aws cloudformation validate-template --template-body file://s3-encrypted-bucket.yaml

Step 5: Create a portfolio in AWS Service Catalog

Using the admin persona in the AWS Console:

  1. Open AWS Service Catalog (in your chosen region).
  2. Go to Portfolios → Create portfolio
  3. Name: Storage-Standards
  4. Owner: your team name (example: PlatformTeam)
  5. Description: Approved storage products

Expected outcome: a portfolio exists but contains no products yet.

Step 6: Create a product and add it to the portfolio

  1. In AWS Service Catalog, go to Products → Upload new product
  2. Product name: S3-Encrypted-Bucket
  3. Owner: PlatformTeam
  4. Description: S3 bucket with encryption and public access blocked
  5. Provisioning method: CloudFormation template
  6. Upload s3-encrypted-bucket.yaml
  7. Create the product.
  8. Now go to the Storage-Standards portfolio → Products tab → Associate product → select S3-Encrypted-Bucket.

Expected outcome: the portfolio contains the product.

Verification – In the portfolio, you should see S3-Encrypted-Bucket listed. – In the product details, you should see at least one provisioning artifact (version).

Step 7: Add a launch constraint (use the launch role)

  1. In the Storage-Standards portfolio, open the S3-Encrypted-Bucket association.
  2. Go to Constraints → Create constraint
  3. Constraint type: Launch constraint
  4. Choose role: SCLaunchRoleS3Product
  5. Save.

Expected outcome: provisioning this product will use the launch role permissions, not the end user’s broad infrastructure permissions.

Verification – The constraint appears in the product’s constraints list.

Step 8: Grant the end user access to the portfolio

  1. Go to Storage-Standards portfolio → Groups, roles, and users (or Principals, depending on console wording).
  2. Add principal: – Select sc-enduser (IAM user)
  3. Save.

Expected outcome: sc-enduser can now see and provision products from this portfolio.

Verification – Sign in as sc-enduser – Open AWS Service Catalog → Products – You should see S3-Encrypted-Bucket

Step 9: Provision the product as the end user

As sc-enduser:

  1. Open AWS Service Catalog → Products
  2. Select S3-Encrypted-Bucket
  3. Click Provision product
  4. Provide: – Provisioned product name: lab-s3-bucket-1 – EnableVersioning: Suspended (start simple) – CostCenter: cc-lab
  5. Provision.

Expected outcome: provisioning starts; after a few minutes, status becomes Available (or similar success status).

Verification – In Service Catalog → Provisioned products, open lab-s3-bucket-1 – Confirm status is successful – Click to view underlying CloudFormation stack (or go to CloudFormation and find the stack created for the provisioned product) – In the stack Outputs, note BucketName – In S3, confirm the bucket exists and: – default encryption is enabled (SSE-S3) – block public access is enabled – tag managed-by=aws-service-catalog exists

Step 10: Update the provisioned product (enable versioning)

As sc-enduser: 1. Go to the provisioned product lab-s3-bucket-1 2. Choose Update 3. Change EnableVersioning to Enabled 4. Submit update and wait for completion

Expected outcome: the provisioned product remains healthy and S3 versioning becomes enabled.

Verification – In S3 bucket properties, check Versioning: Enabled – In CloudFormation stack events, confirm update succeeded

Step 11: Terminate the provisioned product

As sc-enduser: 1. Go to Provisioned products 2. Select lab-s3-bucket-1 3. Choose Terminate

Expected outcome: CloudFormation deletes the stack and the S3 bucket is removed.

Verification – Provisioned product status becomes terminated/removed – CloudFormation stack is deleted – S3 bucket no longer exists

Validation

You have successfully validated: – End user visibility is controlled by portfolio principal association. – Provisioning uses an admin-defined launch role (launch constraint). – CloudFormation stack is created/updated/deleted through Service Catalog. – Governance defaults (encryption, block public access, tags) are implemented in the product template.

Troubleshooting

Common issues and fixes:

  1. End user can’t see the product – Confirm:

    • You added the product to the portfolio.
    • You associated the end user principal with the portfolio.
    • You are in the correct region.

  2. Provisioning fails with AccessDenied – Check the CloudFormation stack events for the exact denied action. – Fix by updating the launch role policy to include required actions (least privilege). – Confirm the launch role trust policy allows servicecatalog.amazonaws.com.

  3. Bucket deletion fails during termination – Cause: bucket is not empty. – Fix: delete objects/versions first, then terminate again. – Best practice: in real products, consider lifecycle policies or explicit cleanup automation when appropriate (but be careful with destructive behavior).

  4. Template validation errors – Run aws cloudformation validate-template. – Ensure parameters and AllowedValues match.

Cleanup

Perform cleanup using the admin persona:

  1. Delete provisioned products (ensure terminated)
  2. In AWS Service Catalog: – Remove principals from the portfolio (optional but tidy) – Remove constraints – Disassociate product from portfolio – Delete product – Delete portfolio
  3. In IAM: – Delete inline policy and role SCLaunchRoleS3Product – Delete IAM user sc-enduser

CLI cleanup (role + inline policy):

aws iam delete-role-policy \
  --role-name SCLaunchRoleS3Product \
  --policy-name SCLaunchRoleS3ProductPolicy

aws iam delete-role --role-name SCLaunchRoleS3Product

11. Best Practices

Architecture best practices

  • Design products as “golden paths”: pre-wire logging, encryption, networking, and tagging.
  • Keep products composable: smaller, focused products are easier to version and maintain than mega-stacks.
  • Use versioning intentionally: treat provisioning artifacts like releases; document changes and breaking impacts.
  • Test updates: validate CloudFormation update behavior in staging accounts before publishing new versions.

IAM/security best practices

  • Use launch constraints so end users don’t need broad permissions.
  • Least privilege launch roles: scope CloudFormation and resource permissions to what the product actually needs.
  • Separate admin and end-user roles: avoid giving developers catalog admin permissions.
  • Consider permission boundaries and SCPs as additional layers (especially in multi-account).

Cost best practices

  • Publish “dev” and “prod” variants (instance sizes, HA settings, logging retention).
  • Enforce cost allocation tags through:
  • template tags,
  • IAM conditions for tag keys/values where possible,
  • organizational tag policies (if used), and
  • ongoing compliance checks.
  • Build products with cost-safe defaults (no NAT gateway unless needed, sensible log retention).

Performance best practices

  • Service Catalog isn’t a runtime path; performance concerns mostly map to CloudFormation and underlying resources.
  • Optimize templates to avoid unnecessary resources and long-running custom resources.

Reliability best practices

  • Use CloudFormation best practices:
  • stable resource naming strategies,
  • avoid replacements for critical resources unless expected,
  • use update policies where applicable.
  • Ensure rollback behaviors are well understood (CloudFormation rollbacks can hide partial changes if not reviewed).

Operations best practices

  • Centralize logging: organization trail in CloudTrail; consistent CloudWatch log group retention in templates.
  • Use SNS notifications for provisioning failures/success where operationally helpful.
  • Establish a support process:
  • who owns product templates,
  • SLAs for fixes,
  • version retirement strategy.

Governance/tagging/naming best practices

  • Use consistent naming conventions:
  • portfolio names by domain (Networking-Standards, Data-Standards)
  • product names by capability (RDS-Postgres-Standard)
  • Standardize tags:
  • cost-center, owner, environment, application, data-classification
  • Use AppRegistry (when adopted) to map resources to applications consistently.

12. Security Considerations

Identity and access model

  • AWS Service Catalog uses IAM for:
  • admin actions (create/modify portfolios/products/constraints)
  • end-user actions (search/provision/update/terminate)
  • Launch constraints are central for least privilege:
  • end users can provision without direct access to underlying services
  • the launch role becomes the controlled permission boundary for provisioning

Recommendation: treat launch roles as sensitive security assets. Review them like you review production IAM roles.

Encryption

  • AWS Service Catalog stores metadata; encryption-at-rest is handled by AWS for the service’s managed storage. For specific details, verify in official docs.
  • Encryption for provisioned resources is your responsibility in templates:
  • S3 default encryption
  • EBS encryption
  • RDS encryption
  • KMS key policies and grants

Network exposure

  • Service Catalog itself is not deployed into your VPC.
  • Your product templates determine network exposure:
  • public subnets vs private subnets
  • security groups
  • load balancer scheme
  • VPC endpoints for private service access

Secrets handling

  • Do not embed secrets in CloudFormation templates or Service Catalog parameters.
  • Use AWS Secrets Manager or SSM Parameter Store (SecureString) and reference them appropriately.
  • Ensure launch roles have minimal access to secret retrieval paths.

Audit/logging

  • Enable CloudTrail (ideally org-wide) and ensure Service Catalog and CloudFormation events are captured.
  • Monitor:
  • who created/updated products
  • who provisioned which products
  • failures and repeated attempts (could indicate misconfiguration or abuse)

Compliance considerations

AWS Service Catalog supports compliance by making approved patterns easy and deviations harder. However, compliance still requires: – policy-as-code and continuous monitoring (AWS Config) – least privilege IAM (including launch role policies) – secure template review and approvals

Common security mistakes

  • Giving end users direct admin permissions “because provisioning failed.”
  • Overly broad launch roles (for example, AdministratorAccess) that effectively bypass governance.
  • Not separating portfolios by environment sensitivity (prod vs sandbox).
  • Not requiring tags, leading to poor ownership and cost accountability.

Secure deployment recommendations

  • Enforce multi-account strategy (prod isolated).
  • Combine:
  • Service Catalog (approved patterns),
  • SCPs (hard guardrails),
  • IAM permission boundaries (role safety),
  • Config rules (continuous compliance).

13. Limitations and Gotchas

Key limitations and operational gotchas to plan for:

  • Regional nature: portfolios/products are regional. If you operate in multiple regions, you need a replication strategy (process/automation).
  • CloudFormation behaviors apply: update/replace semantics can cause downtime if templates are not carefully designed.
  • Termination failures: resources with dependencies (for example, non-empty S3 buckets) can block stack deletion.
  • TagOptions are not full enforcement: they help standardize but don’t automatically guarantee mandatory tags for all resources.
  • Quotas exist: portfolios, products, associations, constraints have limits—check Service Quotas.
  • Cross-account sharing complexity: portfolio sharing requires careful IAM and governance design (especially with many OUs/accounts).
  • Change management: publishing a new provisioning artifact doesn’t automatically update existing provisioned products; updating is a controlled operation.
  • Drift and manual changes: if users change resources outside CloudFormation, you can get drift; manage with CloudFormation drift detection and policies.
  • Console UX differences: AWS console navigation and labels can change; rely on concepts (portfolio/product/constraint) and validate in current docs.

14. Comparison with Alternatives

AWS Service Catalog is part of a broader ecosystem of provisioning and governance tools. Here are common alternatives and complements.

Option Best For Strengths Weaknesses When to Choose
AWS Service Catalog Governed self-service provisioning in AWS Portfolios/products/constraints, IAM integration, CloudFormation lifecycle, multi-account sharing Regional catalogs, CloudFormation complexity, governance setup requires planning You need curated, controlled self-service at enterprise scale
AWS CloudFormation (direct use) Teams managing their own stacks Simple, direct, flexible Less centralized governance; IAM becomes harder to manage; no catalog UX Small teams or when you don’t need an internal catalog
AWS Control Tower Account Factory Standardized account provisioning Strong landing zone + account governance Not a product catalog for arbitrary infrastructure You need account vending and baseline guardrails
AWS Proton Platform-managed service templates for developers Opinionated app/service modeling, developer experience Different scope; not a general “all infra” catalog You want standardized microservice deployment patterns and platform workflows
AWS Marketplace (Private Marketplace) Controlled access to third-party products Governance for marketplace subscriptions Different scope from internal infrastructure blueprints You need to manage third-party software procurement/deployment paths
Backstage (open source) Internal developer portal Excellent developer catalog/UX; plugin ecosystem Requires hosting/ops; not a provisioning engine by itself Pair with Service Catalog/CloudFormation/Terraform to provide golden paths
Terraform + internal modules Terraform-first orgs Broad ecosystem, modules, multi-cloud Governance requires additional controls; module sprawl If Terraform is your standard and you have governance tooling around it
Azure Managed Applications / catalog patterns Azure-centric governed offerings Azure-native catalog experience Not AWS; concept differs If you are on Azure and need managed app offerings
Google Cloud Marketplace Private Catalog GCP catalog of solutions GCP-native catalog Different scope/tooling If you are on GCP and need curated solutions

15. Real-World Example

Enterprise example (regulated financial organization)

  • Problem: Hundreds of teams provision infrastructure across many accounts. Auditors require consistent encryption, logging, and change tracking. Developers need self-service without admin access.
  • Proposed architecture:
  • AWS Organizations with OUs per business unit and environment
  • Central catalog account where platform team manages AWS Service Catalog portfolios
  • Portfolios shared to workload accounts via Organizations
  • Mandatory launch constraints with least-privilege roles per product category
  • CloudTrail org trail + AWS Config rules + Security Hub
  • Optional AppRegistry for application ownership mapping
  • Why AWS Service Catalog was chosen:
  • Clear separation of duties between platform admins and end users
  • Centralized catalog distribution with guardrails
  • Works naturally with CloudFormation standards already used by the platform team
  • Expected outcomes:
  • Reduced security drift and fewer policy exceptions
  • Faster provisioning with fewer tickets
  • Improved audit posture (who provisioned what, using which approved template version)

Startup / small-team example (lean platform team)

  • Problem: A small platform team supports multiple product squads. Infrastructure is inconsistent, and onboarding new engineers is slow.
  • Proposed architecture:
  • A small set of portfolios: Networking, Datastores, Observability
  • Products for VPC baseline, S3 bucket baseline, RDS baseline, and CI/CD pipeline baseline
  • Lightweight constraints (launch role) and consistent tags for cost allocation
  • Why AWS Service Catalog was chosen:
  • Minimal direct cost for the governance layer
  • Self-service catalog reduces platform interruptions
  • Versioned templates improve repeatability and onboarding
  • Expected outcomes:
  • Faster environment creation
  • Less time debugging one-off infrastructure setups
  • Cleaner cost allocation and ownership

16. FAQ

  1. Is AWS Service Catalog still an active AWS service?
    Yes. AWS Service Catalog is active and commonly used for governance and self-service provisioning in AWS environments.

  2. Is AWS Service Catalog global or regional?
    It is a regional service. You create and manage portfolios/products per region.

  3. Does AWS Service Catalog create resources directly?
    Typically it orchestrates provisioning via AWS CloudFormation (and the permissions you provide via IAM roles/constraints).

  4. Do I pay extra for AWS Service Catalog?
    Usually no additional charge for the service itself; you pay for the underlying provisioned AWS resources. Confirm on the official pricing page for the latest details.

  5. What is the difference between a product and a provisioned product?
    A product is the blueprint/template definition. A provisioned product is an instance created from that blueprint (often a CloudFormation stack).

  6. What is a provisioning artifact?
    A version of a product (for example, template v1 vs v2). It enables controlled versioning.

  7. How do I stop end users from provisioning risky resources?
    Publish only approved products, use least-privilege launch roles, apply constraints, and add organization guardrails (SCPs, Config rules).

  8. Do end users need permissions to create EC2/S3/RDS if using Service Catalog?
    Not necessarily. With launch constraints, end users can provision products while the provisioning role performs the actual resource creation.

  9. Can I share portfolios across AWS accounts?
    Yes, portfolio sharing is a common pattern, often via AWS Organizations. The exact setup depends on your organization and IAM strategy.

  10. Can AWS Service Catalog enforce mandatory tags?
    It can help with tagging through templates and TagOptions, but strict mandatory tag enforcement often requires additional controls (IAM conditions/SCPs/template enforcement).

  11. How do updates work for already provisioned products?
    Updates generally map to CloudFormation stack updates. You can publish new provisioning artifacts and then choose to update existing provisioned products.

  12. What happens if someone changes resources outside CloudFormation?
    You can get drift. Use CloudFormation drift detection and governance controls to manage or prevent out-of-band changes.

  13. Is AWS Service Catalog a replacement for AWS Control Tower?
    No. Control Tower focuses on landing zones and account governance. Service Catalog focuses on a curated catalog of provisionable products. They are often used together.

  14. Does AWS Service Catalog support application-level grouping?
    Yes, via AWS Service Catalog AppRegistry, which helps model applications and associate resources. Validate current features in official docs.

  15. What’s the fastest way to get started?
    Start with 2–5 high-value products (S3 baseline, VPC baseline, RDS baseline), add launch constraints, define tags, and iterate with versioning.

17. Top Online Resources to Learn AWS Service Catalog

Resource Type Name Why It Is Useful
Official Documentation AWS Service Catalog Documentation Primary source for concepts, constraints, APIs, and workflows: https://docs.aws.amazon.com/servicecatalog/
Admin Guide AWS Service Catalog Administrator Guide Deep detail on portfolios, products, constraints, sharing: https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html
User Guide AWS Service Catalog User Guide End-user provisioning workflows and concepts: https://docs.aws.amazon.com/servicecatalog/latest/userguide/introduction.html
API Reference AWS Service Catalog API Reference Programmatic management and automation: https://docs.aws.amazon.com/servicecatalog/latest/dg/Welcome.html
CLI Reference AWS CLI – servicecatalog commands Automate catalog operations: https://docs.aws.amazon.com/cli/latest/reference/servicecatalog/
Pricing AWS Service Catalog Pricing Confirms pricing model and any updates: https://aws.amazon.com/servicecatalog/pricing/
Pricing Tool AWS Pricing Calculator Estimate costs for provisioned resources: https://calculator.aws/#/
AppRegistry Docs AppRegistry (within AWS Service Catalog) Application modeling and resource association (verify latest): https://docs.aws.amazon.com/servicecatalog/latest/adminguide/appregistry.html
CloudFormation Docs AWS CloudFormation User Guide Since Service Catalog products commonly use CloudFormation: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html
Governance AWS Organizations Documentation Portfolio sharing and multi-account governance: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html
Audit AWS CloudTrail Documentation Audit provisioning/admin activity: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html
Quotas Service Quotas User Guide Check Service Catalog and CloudFormation quotas: https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html
Video Learning AWS YouTube Channel Search for “AWS Service Catalog” sessions and demos: https://www.youtube.com/@amazonwebservices
Community (reputable) AWS Architecture Center Reference patterns that you can turn into products: https://aws.amazon.com/architecture/

18. Training and Certification Providers

  1. DevOpsSchool.com – Suitable audience: DevOps engineers, cloud engineers, SREs, platform teams – Likely learning focus: DevOps + cloud operations fundamentals, tooling, and workshops (verify specific AWS Service Catalog coverage on site) – Mode: check website – Website: https://www.devopsschool.com/

  2. ScmGalaxy.com – Suitable audience: beginners to intermediate DevOps learners – Likely learning focus: software configuration management, DevOps practices, foundational cloud/automation topics (verify current course list) – Mode: check website – Website: https://www.scmgalaxy.com/

  3. CLoudOpsNow.in – Suitable audience: cloud operations and DevOps practitioners – Likely learning focus: cloud operations, monitoring, automation (verify AWS-specific offerings) – Mode: check website – Website: https://cloudopsnow.in/

  4. SreSchool.com – Suitable audience: SREs, operations engineers, reliability-focused teams – Likely learning focus: SRE principles, operations maturity, incident response, automation (verify AWS modules) – Mode: check website – Website: https://sreschool.com/

  5. AiOpsSchool.com – Suitable audience: operations teams exploring AIOps and automation – Likely learning focus: AIOps concepts, observability, automation (verify cloud platform coverage) – Mode: check website – Website: https://aiopsschool.com/

19. Top Trainers

  1. RajeshKumar.xyz – Likely specialization: DevOps/cloud training content (verify current focus on site) – Suitable audience: engineers seeking hands-on mentoring – Website: https://rajeshkumar.xyz/

  2. devopstrainer.in – Likely specialization: DevOps training and practical labs (verify AWS coverage) – Suitable audience: DevOps engineers and students – Website: https://devopstrainer.in/

  3. devopsfreelancer.com – Likely specialization: DevOps consulting/training-style services (verify offerings) – Suitable audience: teams needing short-term guidance – Website: https://devopsfreelancer.com/

  4. devopssupport.in – Likely specialization: DevOps support and troubleshooting assistance (verify training vs support mix) – Suitable audience: teams needing operational help – Website: https://devopssupport.in/

20. Top Consulting Companies

  1. cotocus.com – Likely service area: cloud/DevOps consulting (verify service catalog on site) – Where they may help: platform setup, automation strategy, governance implementation – Consulting use case examples: designing a multi-account catalog strategy; implementing launch roles and guardrails – Website: https://cotocus.com/

  2. DevOpsSchool.com – Likely service area: DevOps and cloud consulting/training services (verify consulting offerings) – Where they may help: end-to-end DevOps transformations, AWS governance patterns, enablement workshops – Consulting use case examples: building standardized CloudFormation products; setting up portfolio sharing across AWS Organizations – Website: https://www.devopsschool.com/

  3. DEVOPSCONSULTING.IN – Likely service area: DevOps consulting services (verify specializations) – Where they may help: CI/CD, infrastructure automation, cloud operations – Consulting use case examples: integrating Service Catalog products into delivery workflows; establishing tagging and audit practices – Website: https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before AWS Service Catalog

  • AWS fundamentals: IAM, VPC, EC2, S3, RDS basics
  • Infrastructure as Code basics, especially AWS CloudFormation
  • AWS Organizations and multi-account design basics (recommended)
  • Tagging strategy and cost allocation fundamentals

What to learn after AWS Service Catalog

  • Advanced CloudFormation (nested stacks, macros, custom resources)
  • Governance services:
  • AWS Control Tower
  • AWS Config
  • Security Hub
  • IAM permission boundaries and SCP strategy
  • Platform engineering patterns:
  • developer portals (Backstage)
  • golden paths and paved roads
  • service templates and lifecycle management

Job roles that use AWS Service Catalog

  • Cloud engineer / cloud platform engineer
  • DevOps engineer / platform DevOps
  • Solutions architect
  • Site Reliability Engineer (SRE)
  • Cloud security engineer (governance and guardrails)
  • FinOps practitioner (tagging, cost allocation, policy enforcement)

Certification path (AWS)

AWS certifications don’t certify AWS Service Catalog specifically, but it appears in real-world architecture/governance work. Relevant certs include: – AWS Certified Solutions Architect – Associate/Professional – AWS Certified SysOps Administrator – Associate – AWS Certified DevOps Engineer – Professional – AWS Certified Security – Specialty
Verify current certification lineup: https://aws.amazon.com/certification/

Project ideas for practice

  • Build a “Network-Standards” portfolio with a VPC baseline product.
  • Add launch roles and separate dev/prod constraints.
  • Implement mandatory tags via templates + IAM/SCP conditions (where applicable).
  • Add SNS notification constraints to alert ops on provisioning events.
  • Use AppRegistry to register each provisioned product under an application.
  • Automate product publishing via CI/CD (lint CloudFormation, security scan, publish new provisioning artifact).

22. Glossary

  • AWS Service Catalog: AWS service for creating and managing catalogs of approved products that users can provision.
  • Management and governance: AWS category focused on controlling, standardizing, and auditing cloud usage at scale.
  • Portfolio: A collection of products with associated access controls and sharing configuration.
  • Product: A blueprint users can provision (often a CloudFormation template).
  • Provisioning artifact: A versioned definition of a product (template v1, v2, etc.).
  • Provisioned product: A deployed instance of a product (often implemented as a CloudFormation stack).
  • Constraint: A governance rule applied to products (for example, launch role).
  • Launch constraint / launch role: A constraint specifying the IAM role used to provision the product.
  • Principal: An IAM user/role/group granted access to a portfolio.
  • AWS CloudFormation: Infrastructure as code service used to create/update/delete AWS resources as stacks.
  • CloudTrail: AWS auditing service recording API calls.
  • AWS Organizations: Service for multi-account governance and policy management.
  • SCP (Service Control Policy): Organization-level policy that sets permission guardrails for accounts/OUs.
  • TagOptions: Service Catalog feature to define approved tag key/value options for products/portfolios.
  • AppRegistry: Capability within AWS Service Catalog for application-centric resource organization and governance.

23. Summary

AWS Service Catalog (AWS) is a Management and governance service that lets platform teams publish approved, versioned infrastructure products and lets end users self-service provision them safely. It matters because it reduces security drift, standardizes architectures, improves auditability, and enables governance at enterprise scale—especially in multi-account AWS Organizations environments.

Cost-wise, AWS Service Catalog is typically not billed as a separate line item; your costs come from the resources you provision (compute, storage, networking, logging). Security-wise, the biggest design lever is using least-privilege launch roles and well-reviewed templates, combined with organization guardrails (SCPs, Config rules, and centralized audit via CloudTrail).

Use AWS Service Catalog when you need a curated catalog with strong guardrails and self-service provisioning. Next, deepen your skills by mastering CloudFormation update behaviors, multi-account governance, and a robust template release process (CI/CD for product versions).