Deploying Managed Infrastructure using AWS Service Catalog


Deploying Managed Infrastructure using AWS Service Catalog

One of the many benefits of cloud is being able to choose a deployment method that works for you. In our AWS practice, this has focused around CloudFormation and Terraform, with both having a range of templates/modules that we maintain internally to deploy for our customers. Deploying these resources involves a process with responsibilities shared by both the customer and Rackspace, as follows: raise a request, validation of the request, implementation of the changes, and handover of the provisioned infrastructure.

But what if you want your teams to be able to deploy these blocks of supported infrastructure? AWS has a service that enables Rackspace to provide you with that option: AWS Service Catalog.

In a recent successful project, we were involved in developing a portfolio of products for one of our largest enterprise customers. The ready portfolio can be deployed across two of their accounts. These accounts had different purposes; one is for production and the other is for pre-production. Rackspace reviewed the technical requirements for each of these accounts. We looked at which resources had been deployed previously.

As part of this assessment, we defined the build standards for the resources which were to be deployed. Given each AWS environment had a different use-case, consideration was given to aspects such as: service availability monitoring, backup requirements with consideration of mandated recovery point objectives (RPO) and recovery time objectives (RTO), along with how the resources would be secured. We also looked at aspects like application and operating system patches. Through developing these standards, Rackspace Cloud Engineers were then able to codify the majority of these into CloudFormation templates which were adapted for use with the AWS Service Catalog. This allowed Rackspace to deliver a standardised catalogue of services which is self-service from a customers’ perspective but still maintained a consistently high quality of service, across both use cases.

By enabling the function within the AWS portal the developers can access it easily. This allows them to deploy infrastructure without having to raise a request detailing provision. Developers can add the same level of detail to a self-service deployment page and begin provisioning immediately. The deployment times are significantly reduced. In addition, customisation reduces drift between deployments as the templates and variables are consistent. And also the customer’s tagging strategy is adhered to which aids internal cost allocations and governance.

Technical Overview
The AWS Service Catalog is primarily made up of portfolios and products. A portfolio can provide a number of products and have a portfolio level settings such as tags, constraints, and permissions. It can be deployed via the console, the command line and SDKs, CloudFormation, or 3rd party infrastructure as code (IAC) tools such as Terraform.

In the time we have been using the AWS Service Catalog we have experienced numerous uses:

  • Portfolio management can be assigned to specific users or roles so as to have a clear separation between the maintainer (Rackspace) and our customer’s end users.
  • When dealing with tag options there is a hard limit set by AWS of 25 values per tag key; this limitation can be overcome by working on splitting large value options across multiple keys.
  • Products can be versioned, and the end users given the choice on which version to deploy; these versions can also be used to migrate existing deployed products to newer versions of the underlying template.
  • The AWS Service Catalog is accompanied by CLI and SDK access, meaning you can programmatically deploy assigned products from your portfolio as part of your CI/CD pipeline.
  • Launch constraints can be used to allow products to be deployed without giving an end user permission to interact with billable services directly.
  • Template constraints can be used to tune which options are available at launch; a good example would be restricting the instance type to a cheaper option like the t2 family when the environment matches development.

The AWS Service Catalog is a great option for providing your teams with blocks of infrastructure that follow our implementation patterns. It offers security, governance, compliance and flexibility whilst still deploying Rackspace managed infrastructure as the underlying templates are backed by Cloud Engineer Rackers who are here to ensure you get a Fanatical Experience in your cloud journey.

If you have a workload that you feel is right for the AWS Service Catalog be sure to reach out to our team of experts!