Close-up of a computer chip

AWS Service Catalog: How to set up self-service

Enabling self-service for the AWS Service Catalog is a win-win. Learn why and bring self-service to your users

October 01 2021Artur Schneider

The dual benefits of self-service

In large AWS environments, you want to provide your users with secure and compliant ways to use AWS cloud services. You can empower them to consume services independently and reduce your operational teams‘ workloads. The result? Increased user satisfaction and more time for operations to concentrate on value-adding activities. AWS offers a native way to create and share your products in your AWS organization with the AWS Service Catalog.  

Why do you need an AWS Service Catalog?

A man sitting at his desk infront of a computer screen

Creating, managing, and controlling your organization's AWS Service Catalog products is the first step to providing self-service. Your organization benefits from a variety of advantages, including:

  • Compliance by enabling corporate standards for products
  • Increased user satisfaction by enabling self-service via the AWS Service Catalog portal 
  • Reduced operational workloads
  • Integration capabilities with ServiceNow or Jira Service Desk
  • Programmatic deployment capabilities for AWS Service Catalog products
  • As a native AWS service, good integration with other AWS services
  • A central location for compliant products

What about security?

Each AWS product is based on an AWS CloudFormation template. The definition of what a product executes and, consequently, what a user can do, is determined in the template. It’s also possible to enable additional restrictions through various measures, called constraints:

Launch Constraints define which IAM role the AWS Service Catalog assumes when it launches the product

Notification Constraints give the possibility to get information via SNS (Simple Notification Service) when products are managed

Tag Update Constraints provides the ability to prevent tag updates on deployed resources

Stack Set Constraints enables StackSets deployments to multiple accounts or regions

Template Constraints limit the options for users at launch

As well as constraints, there are so-called ‘service actions’ which offer the possibility to perform predefined actions on already provisioned AWS Service Catalog products. (For example, initiate a restart of an EC2 machine). Service actions can be defined in AWS Systems Manager documents and attached to a product.

A real-world use case for self-service

One of our enterprise customers needed a way to enable self-service capabilities to centrally managed and shared services. Furthermore, users are only allowed to use services that provide a minimum level of security. And this is where the AWS Service Catalog comes into play, as its capabilities can cover the requirements.As our customer also has high demands for automation, the entire solution had to be rolled out in an automated and reusable way. In this case, a CI/CD integration was essential.

How T-Systems implemented the solution

Diagramm of AWS Service Catalog

During the implementation, we worked with our customers’ private GitLab repository and AWS CodePipeline, and CodeBuild. According to security requirements, the IAM permissions for the programmatic GitLab access to the AWS account are supposed to be as light as possible. For this reason, GitLab is only used as a repository that pushes the solution code to an S3 bucket in each of the customer's test and production accounts.

The above actions trigger the actual deployment of the AWS Service Catalog portfolio, including the products. Deployment is done automatically when new products are integrated into the AWS Service Catalog configuration or when an existing product is replaced with a new template.

The accounts in which the configuration of the AWS Service Catalog portfolios and products are rolled out are provided with a delegated AWS Service Catalog administrator permission. The permission enables the sharing of the products into the AWS Organization from the respective AWS Service Catalog accounts.

AWS Service Catalog in an enterprise AWS Organization in combination with Gitlab

Wrapping up, and a note of caution

If you want to provide your users a secure and compliant way to consume AWS cloud services, the AWS Service Catalog provides good capabilities. However, a possible weakness is an unavoidable interconnection with the AWS CloudFormation Service, which occasionally requires a workaround with custom resources to trigger a Lambda function. In that case, the AWS Service Catalog product is just a shell, and the actual automation logic is placed in a Lambda function.

About the author
Artur Schneider – Senior Cloud Consultant

Artur Schneider

Senior Cloud Consultant, T-Systems International GmbH

Show profile and articles

You might also be interested in:

Do you visit t-systems.com outside of Germany? Visit the local website for more information and offers for your country.