When your organisation has hundreds or thousands of users, the logistics of controlling the deployment of software and services can be a complex and time consuming task.
You need to ensure your users are installing approved software applications and you need to know that they have the appropriate permissions to access only the resources and services they need.
Traditionally, this process would involve contacting IT support and raising a ticket requesting access and installation of the software. Within large organisations this process could take hours or days to resolve, preventing the end user from doing their job and impacting the overall productivity of the organisation.
AWS Service Catalog solves this bottleneck by allowing administrators to collate different AWS services and applications into catalog portfolios of approved applications and access policies so that AWS users within the organisation can select and install software and services listed in the catalog without needing direct access to the underlying services.
An administrator can create templates within a service catalog portfolio that can be selected by an end user for deployment. The template includes the resources and dependencies required by the application, so the user can self install the application without necessarily knowing what resources need to be provisioned to support the application. The template will also contain the security policies required to ensure the correct permissions are granted for the end user when the application is launched.
Portfolios can be shared to individual AWS accounts or entire organizational units.
Service Catalog can be found in the AWS Management Console under the “Management and Governance” options.
Catalog admins are responsible for creating portfolios within the catalog and registering products in the catalog. On top of this, admins also author the cloudformation templates that define how the application instance should be built, including the resources that need to be provisioned and the security settings that need to be applied during the provisioning process.
End users can then browse the service catalog, select an application and launch it knowing the admins have done all the work up front to ensure the correct resources and security is in place.
The advantage of deploying applications in this manner, is that the centralised nature of the catalog ensures that the correct applications and the correct versions of those applications are made available to your end users which ensures compliance with your organisation’s standards and security requirements as well as controlling the configuration options and permissions.
IAM roles within the service catalog are inherited by the end users as they deploy applications, which ensures your IT team aren’t bogged down manually updating IAM policies at the user level in order to get an application to run.
Best practice surrounding service catalogues suggest IAM policies should be applied to your products and portfolios to control who can add, modify or remove applications, services and portfolios. It is also recommended that IAM least privilege principles are applied to the catalog to prevent unauthorised access and operations.
Constraints can also be applied to catalogued applications which dictate how associated resources are allocated at launch.
Constraints are used in conjunction with policies to govern how specific AWS resources can be deployed when part of the service catalog application launch process. There are two types of constraints available: template constraints and launch constraints.
Template constraints allow you to use generic AWS cloudformation templates and then apply restrictions on a per product or per portfolio basis. This is the perfect place to apply restrictions to ensure your corporate security and governance policies are adhered to.
Launch constraints allow you to restrict user permissions while still enabling them to provision resources and launch applications from the service catalog.
AWS Service Catalog Use Cases.
Large organizations with hundreds or thousands of users can use the AWS service catalog to establish a standard method of provisioning cloud resources and applications without placing an unmanageable burden on the IT team.
IT Teams can use service catalog to manage AWS resources and services. The catalog could be used to provision standardised development and test environments. You could for instance have multiple portfolios of different dev environments with specific LAMP stacks and versions to spin up approved dev environment deployments.
MSPs can use the service catalog to centralise policies and deployment assets and speed up provisioning of environments for new clients.
In summary, the AWS service catalog can be used to standardise the deployment of approved applications and aws resources. A catalog administrator can set up pre approved applications and services that end users can install without having to contact IT, raise a support ticket or wait days for a response.
If you are building on AWS or exploring AWS Service Catalog as a method of letting end users deploy AWS resources and applications then monitoring exactly what is running in your AWS environments should be a major governance priority.
Hava automatically builds detailed network topology diagrams for any AWS accounts you choose to connect. Once connected diagrams are kept up to date and superseded diagrams are placed in version history so you know exactly what is running now and what was previously running.
Comparing historical diagrams with the current state of play ensures you can see what has been added or removed which is especially useful if you encounter unexpected network behaviour or a significant increase in billing charges.
You can check out Hava via a free 14 day trial. Learn more here:
