AWS service catalog is an organizational tool developed with the purpose of making provisioning and creation of IT stacks easier for both the end user as well as your IT admins.

These stacks can include almost everything under the AWS sun – such as EC2 instances, Databases, software, and all the underlying infrastructures to create multi-tiered applications and architectures.

Service Catalog allows your end users to select the content that they need from a list of preapproved services that your IT or Admin teams set up ahead of time. This helps to bring down those barriers of entry for content creation, as well as helping to keep best practices and system security a key component of any deployment.

Before service Catalog, your End User might have needed to ask their IT or Admin professionals to help them provision or determine what services were and were not within their scope of work. This could of course be achieved by limiting accessibility through IAM on a job role by job role basis. It is a bit tedious, however, and becomes a constantly changing battle, especially if you have many different roles within your company.

Now with AWS Service Catalog, we have the ability to browse through a list of ‘Products’ which are just a set of pre-approved services - and provision what we need from there. By setting up our system in this way, we can create and build with the full confidence that we as developers are creating solutions using only acceptable components that our security, administration, and leadership teams approve of. And on the Admin side, I'm not constantly being bugged with approval requests from every developer and department under the corporate sun. I think you can see the point, so let's dive in a bit.

This is an important question because ‘products’ are the heart and soul of the AWS Service Catalog. Products are an IT service that you want to make available for deployment on AWS.

A product can consist of just a single AWS Resource or can be comprised of multiple items such as EC2 instances, Their associated EBS volumes, Database that you want them connected to, and all the monitoring capabilities you would come to expect from these services within the cloud.

A product can even be a package listed on the AWS Marketplace. For example, this could be helpful if you were using a database that AWS does not natively support but was available on the marketplace.

In the end, a product is a service. It can range from something as small as a single instance doing basic web hosting to an enormous multi-tiered web application.

Creating a product is actually very simple. AWS service catalog requires you to upload AWS Cloud Formation Templates, and from these templates, the service will add that entire stack into the catalog as a single product. Again that product can be something as small as a single EC2 instance, or a very large multi-tiered web application.

When uploading your products, you have the ability to add detailed product descriptions, any version information, and required support details and tags. These descriptions can be very helpful for your end users, allowing them to know who to contact if something goes wrong with the product.

Tags are very important for keeping track of cost. They can also be used to create metrics and analytics for your most commonly used product, Helping you to determine what your End Users are actually consuming. So, Make sure you appropriately tag your products during this phase.

You also have the ability to update any products you have already created. New versions of a product are added almost exactly how you built the initial product in the first place. Simply go to your product - click add new version - and upload your updated Cloud Formation Template to override the old product.

Once the new version is fully uploaded, and your product is published, your End User will have the option to update their running stacks to this version. You also have the option to deprecate old versions of a product. Your users will still have the ability to update but will not be able to provision more instances of that version.

Products can even be customized and have different deployments based on options you specify. Let's say you wanted your product to use different ec2 instances based on the number of daily active users expected. When you set up your cloud formation template that describes your product, you can set predefined business-level input parameters. These parameters include questions you can ask your End Users when they select the product for deployment. Each question can have a predefined list of answers. Based on their answers to these questions you could completely change the architectural configuration of the product. That's pretty Neat.

Now that we have a handle on what a product is, and how to create them, the next step within service catalog is to add these products into portfolios.

A portfolio is a collection of products with configuration information, that helps in determining who can use the products within. Each portfolio requires a name, description, and a product owner. That last one is very important because if something goes wrong with an available product it's important to know who to send your complaints to. And just like with products, you can also tag each of your portfolios for all the normal good tagging reasons.

Portfolios can also be customized for each type of user within your organization, having individual controls and allowances per individual, group, or team.

When you are ready to publish your portfolios to your end users, you will need to add IAM users, groups, or roles to the portfolio from the console. This will allow them to actually see your finalized products within their Service Catalog.

You can also share portfolios between other AWS accounts, and give the administrators of those accounts the ability to add their own products to your portfolio. This could be useful when you have teams that operate independently, that each deal with creating their own products. You would want their product managers or admins in charge of when new versions are available and to whom they can be provisioned. All you need to do to allow sharing for your portfolio is specify the account id you want to share with (within the service catalog console) and provide the

One of the best features and really the whole goal of service catalog, is that you have full control over what your end users have access to. From an administrator perspective that is incredibly powerful and can help you maintain high levels of both security and credibility.

AWS Service Catalog allows you to apply constraints on the products within your portfolios. These constraints allow you to limit the scope and ability of your products based on pre-defined settings. They also allow you to have additional functionality, at least on the administrative side. When you apply a constraint, they become active as soon as you create them, however, they are not retroactive.

So, what can you do with a constraint? Well, there are a few types of constraints out there that we need to look at. First, we have the Launch constraint. This constraint specifies a specific AWS Identity and access management role that AWS service catalog will use when an End User decides to launch one of your products. By having a launch constraint, you are allowing the service to do the heavy lifting of creating the products instead of your user. This means that your users do not need to have all the permissions required to create your product, such as the ability to use cloud formation - which you probably didn't want your new junior intern to have access to, for example.

With that in mind of course, the IAM role you apply to the product as a constraint needs to have the following permissions: AWS Cloud Formation, All the services used by that Cloud Formation Template, And read access to s3 bucket that houses the cloud formation template.

Notification Constraint. This constraint allows you to receive Amazon SNS notifications about stack events related to your product. These events are all created from deployment of the cloud formation template that specifies your product.

These are nice to have as an administrator because you can see what is being deployed and where. As well as being able to see if your products are deploying successfully or not.

Tag Update Constraint. This constraint specifies whether or not the user can update the tags on the given resources created by your product. This can allow for more specific tagging per group or user without you having to update the tags for them. However if you have good reasons to have the tags applied to the product or portfolio that are currently on there, maybe avoid letting the users have this ability.

Stack Set Constraints. This constraint gives you the option to configure where you want your products to launch. Specifically, you can control what regions and accounts you would like them available in. From there your End User can manage those accounts and determine where the product deploys and the order of those deployments.

Template Constraints. Template constraints allow you to limit what options that are available to your End User when they are provisioning your products. These options might include forcefully limiting the availability of certain ec2 instances based on the specific user group. You might need to do this if the parameter's values in your cloud formation template are too broad for the target user group. In this situation, you can define a template constraint to narrow the band of available options.

This can be especially useful when you want your users to be able to use a certain product but to do so within the bounds of some compliance or regulation requirements set by your organization. These template constraints are bound to whatever portfolio they are in and do not cross over to other products in other portfolios.

You can also use template constraints to stop your users from inputting impossible, or obviously incorrect values. For example, you can create a rule that validates that a given subnet is in a particular VPC. This rule will be checked before creating or updating the stack, preventing CloudFormation from failing to create it.

Check out this example that makes sure the users are selecting an appropriate instance type for their workload.

Here we can see this constraint is setting the available instance type based on the environment the user is trying to set up. If they are trying to create a small test environment, the rules limit them to only using m1.small instances. However, if they are going to create a production environment, we don't want the end users to be subjected to the slow speeds and underperformance of an m1.small, so let's make sure they can only create m1.large instances.

After your End Users have created their applications using the products you have set up, they might have additional needs and requests. Some of these requests are repeatable and are general ‘day to day’ service level operations that need doing. For example, it would be quite common for someone to need a database backed up, but they don't have the technical expertise or the trust level appropriate with being given access to the underlying RDS service.

This is where a Service Action can really shine. A service action is an End User available action - that you have explicitly given permission to use. Service actions allow you to give back some control to your end user, and helps to remove blockers from your operation. For this example, the service actions could be starting that RDS backup.

Service actions can enable your users to perform their own operations tasks: such as troubleshooting, running service level commands, or even request permissions to run additional products through service catalog. Service actions are also product-specific, so you can define exactly where you want them available. Behind the scenes, Service actions are based on AWS Systems Manager automation documents.

When working with service catalog, as well as with most aws services, pricing is of course a factor you should be aware of. There is a free tier for this service that lets you have up to 1000 API calls per month at no charge. When you start to exceed this number you will be charged at a rate of 1 cent per 14 API calls.

I think this is a pretty reasonable rate, as this is not a service that will be called all that often. Basically, you will only be paying for when people are thinking about provisioning new resources. Most of the time your users will be developing or actually using the product itself.