AWS Service Catalog FAQs

You create portfolios in the AWS Service Catalog console. For each portfolio, you specify the name, a description, and owner.

Each Service Catalog product is based on an infrastructure-as-code (IaC) template. You can use CloudFormation templates or Terraform configurations (single tar.gz file). You can create a product via the AWS Service Catalog console by either uploading an IaC template, providing a link to an S3 bucket where the template is stored, or connecting to an external Git repository where the template is stored. When creating products, you can provide additional information for the product listing, including a detailed product description, version information, support information, and tags.

Tags are useful for identifying and categorizing AWS resources that are provisioned by end users. You can also use tags in AWS Identity and Access Management (IAM) policies to allow or deny access to IAM users, groups, and roles or to restrict operations that can be performed by IAM users, groups, and roles. When you add tags to your portfolio, the tags are applied to all instances of resources provisioned from products in the portfolio.

You publish portfolios that you’ve created or that have been shared with you to make them available to IAM users in the AWS account. To publish a portfolio, you add IAM users, groups, or roles to the portfolio from the AWS Service Catalog console by navigating to the portfolio details page. When you add users to a portfolio, they can browse and launch any of the products in the portfolio. Typically, you create multiple portfolios with different products and access permissions customized for specific types of end users. For example, a portfolio for a development team will likely contain different products from a portfolio targeted at the sales and marketing team. A single product can be published to multiple portfolios with different access permissions and provisioning policies.

Yes. You can share your portfolios with users in one or more other AWS accounts. When you share your portfolio with other AWS accounts, you retain ownership and control of the portfolio. Only you can make changes, such as adding new products or updating products. You, and only you, can also “unshare” your portfolio at any time. Any products, or stacks, currently in use will continue to run until the stack owner decides to terminate them.

To share your portfolio, you specify the account ID you want to share with, and then send the Amazon Resource Number (ARN) of the portfolio to that account. The owner of that account can create a link to this shared portfolio, and then assign IAM users from that account to the portfolio. To help end users with discovery, you can curate a directory of portfolios.

Yes. You can use an existing Amazon EC2 AMI to create a product by wrapping it in an AWS CloudFormation template.

Yes. You can subscribe to a product in the AWS Marketplace and use the copy to Service Catalog action to copy your Marketplace product directly to Service Catalog. Also you can use the Amazon EC2 AMI for the product to create an AWS Service Catalog product. To do that, you wrap the subscribed product in an AWS CloudFormation template. For more details on how to copy or package your AWS Marketplace products, please click here.

To control access to portfolios and products, you assign IAM users, groups, or roles on the Portfolio details page. Providing access allows users to see the products that are available to them in the AWS Service Catalog console.

Yes. You can create new product versions in the same way you create new products. When a new version of a product is published to a portfolio, end users can choose to launch the new version. They can also choose to update their running stacks to this new version. AWS Service Catalog does not automatically update products that are in use when an update becomes available.

Yes. You have full control over the AWS accounts and roles used to provision products. To provision AWS resources, you can use either the user’s IAM access permissions or your pre-defined IAM role. To retain full control over the AWS resources, you specify a specific IAM role at the product level. AWS Service Catalog uses the role to provision the resources in the stack.

Yes. You can define rules that limit the parameter values that a user enters when launching a product. These rules are called template constraints because they constrain how the AWS CloudFormation template for the product is deployed. You use a simple editor to create template constraints, and you apply them to individual products.

AWS Service Catalog applies constraints when provisioning a new product or updating a product that is already in use. It always applies the most restrictive constraint among all constraints applied to the portfolio and the product. For example, consider a scenario where the product allows all EC2 instances to be launched and the portfolio has two constraints: one that allows all non-GPU type EC2 instances to be launched and one that allows only t1.micro and m1.small EC2 instances to be launched. For this example, AWS Service Catalog applies the second, more restrictive constraint (t1.micro and m1.small). Currently, template constraints are not supported for Terraform configurations. 

Yes, we currently support both JSON and YAML language templates.

Yes. The AWS Service Management Connector for ServiceNow and Jira Service Desk (formerly the AWS Service Catalog Connector) provides integrations features on ServiceNow and Jira Service Desk projects. This simplifies cloud provisioning and resource management for ServiceNow and Jira Service Desk administrators, and makes it easier for ServiceNow users to request AWS products, which can be any IT service that administrators want to make available for deployment on AWS.

ServiceNow and Jira Service Desk administrators can configure the connector to work with existing or new AWS accounts and roles. ServiceNow and Jira Service Desk users can browse and request AWS products approved by administrators. You can also view configuration item details on provisioned products and execute AWS Systems Manager automation documents within ServiceNow and Jira Service Desk. This simplifies AWS product request actions for ServiceNow and Jira Service Desk users and provides ServiceNow and Jira Service Desk administrators governance and oversight over AWS products.

The AWS Service Management Connector for ServiceNow is available at no charge in the ServiceNow Store. This new feature is generally available in all AWS Regions where AWS Service Catalog is available. For more information, please visit the documentation.

The AWS Service Management Connector for Jira Service Desk is available at no charge in the Atlassian Marketplace. This new feature is generally available in all AWS Regions where AWS Service Catalog, For more information, please visit the documentation.

You can see which products are available by logging in to the AWS Service Catalog console and searching the portal for products that meet your needs, or you can navigate to the full product list page. You can sort to find the product that you want.

For each product, you can view a Product details page that displays information about the product, including the version, whether a newer version of the product is available, a description, support information, and tags associated with the product. The Product details page might also indicate whether the product will be provisioned using your access permissions (Self) or an administrator-specified role (role-arn).

When you find a product that meets your requirements in the portal, choose Launch. You will be guided through a series of questions about how you plan to use the product. The questions might be about your business needs or your infrastructure requirements (such as “Which EC2 instance type?”). When you have provided the required information, you’ll see the product in the AWS Service Catalog console. While the product is being provisioned, you will see that it is “in progress.” After provisioning is complete, you will see “complete” and information, such as endpoints or Amazon Resource Names (ARNs), that you can use to access the product.

Yes. You can see which products you are using in the AWS Service Catalog console. You can see all of the stacks that are in use, along with the version of the product used to create them.

When a new version of a product is published, you can use the Update Stack command to use that version. If you are currently using a product for which there is an update, it continues to run until you close it, at which point you can choose to use the new version.

You can see the products that you are using and their health state in the AWS Service Catalog console.

AWS Service Catalog enables customers using Terraform open source and Terraform Cloud to provide self-service provisioning with governance to their end users in AWS. Central IT can use a single tool to organize, govern, and distribute their Terraform configurations within AWS at scale. They can access AWS Service Catalog key features, including cataloging of standardized and pre-approved templates, access control, least privileges during provisioning, versioning, sharing to thousands of AWS accounts, and tagging. End-users simply see the list of products and versions they have access to, and can deploy them in a single action.

To get started, use the AWS-provided Terraform Reference Engine for Terraform open source or Terraform Reference Engine for Terraform Cloud that installs and configures the code and infrastructure required for the Terraform open-source engine to work with AWS Service Catalog. This one-time setup takes just minutes.

To learn how to catalog, govern, share, and deploy Terraform products using AWS Service Catalog, read our documentation.

If Terraform open source or Terraform Cloud is your IaC tool of choice, you can use Service Catalog to offer your teams Terraform configurations self-service provisioning. If you use a mix of CloudFormation and Terraform configurations across different teams or use cases, you can now use AWS Service Catalog as the single tool to catalog and share both. For your end users, AWS Service Catalog provides an easy-to-use, common interface to view and provision resources regardless of the IaC technology.

To use AWS Service Catalog with Terraform open source, you need to setup a Terraform open source engine in one of your accounts. Create a Terraform open source engine by using the AWS provided Terraform Reference Engine, that will install and configure the code and infrastructure required for your Terraform open source engine to work with AWS Service Catalog. After this one-time setup, that takes just minutes, you can start creating Terraform open source type products in AWS Service Catalog.

To use AWS Service Catalog with Terraform Cloud, use the Terraform Reference Engine for Terraform Cloud that will install and configure the code and infrastructure required for your Terraform Cloud Engine to work with AWS Service Catalog. To learn more, read our documentation.

Yes. AWS Service Catalog supports a “hub and spoke” model where a product is defined in a single central account, and can then be shared with thousands of AWS accounts. For Terraform, you can install your Terraform open source or Terraform Cloud engine and create your Terraform products in this central Hub account. You can then share these with spoke accounts and enable access to IAM roles/users/groups in those accounts. Note that you will need to define launch roles with sufficient permissions in each of those accounts.

Partially. AWS supports the cataloging, sharing, and end-user access for Terraform products. You are responsible for making sure your Terraform open source or Terraform Cloud environment is ready and well-integrated with AWS Service Catalog. You also need to define a launch role with permissions to provision and tag all the resources associated with Terraform products.

Yes. AWS Service Catalog allows you to sync products to template files that are managed through GitHub, GitHub Enterprise, or Bitbucket. Regardless of which repository is chosen, the template file format is still required to be a single file archived in Tar and compressed in Gzip. 

Each Terraform open source or Terraform Cloud product has a single state file, that is stored in the AWS account of your Terraform open source engine or Terraform Cloud engine in AWS S3 bucket. AWS Service Catalog administrators will see the list of state files, but they won’t be able to read or write their contents. Only your Terraform open source engine or Terraform Cloud Engine can read and write the contents of the state files.

This feature is priced the same as all other AWS Service Catalog features, at $0.0007 per API call after the first 1,000 calls in an account/region. To learn more, read here. 

AWS Service Catalog AppRegistry allows organizations to understand the application context of their AWS resources. AppRegistry provides a repository for the information that describes the applications and associated resources that you use within your enterprise.

AWS Service Catalog AppRegistry was developed for organizations that need a single, up-to-date, definition of applications within their AWS environment.

AWS Service Catalog AppRegistry enables you to define your application including a name, description, the associated CloudFormation stacks, and the application metadata represented by Attribute Groups. The associated CloudFormation stacks represent all the resources required for the application. This might be the infrastructure required in a single environment, or it could also include the code repositories, pipelines, and IAM resources that support the application across all environments. Either existing or new CloudFormation Stacks can be associated to applications. New stacks can be associated to the application upon provisioning by including an association to the application with the stack’s CloudFormation template.

Attribute groups contain the application metadata that is important to your enterprise. Attribute groups include an open JSON schema, providing you the flexibility to capture complex enterprise metadata. Application attributes might include metadata such as the application security classification, organizational ownership, application type, cost center, and support information. Builders association attribute groups to their application. When attribute groups are updated, these updates are automatically reflected in all applications associated to the attribute group.

For a full list of supported AWS Regions, see the AWS Region Table.

Yes, a full set of API and CLI actions are available.