Managing AWS CloudFormation Templates and Stacks
CloudFormation simplifies provisioning and management on AWS. You can create templates for the service or application architectures you want and have AWS CloudFormation use those templates for quick and reliable provisioning of services or applications (called stacks). By adding a CloudFormation template to the Commander service catalog, you can use Commander to deploy a stack.
CloudFormation templates are JSON files that specify AWS resources to deploy and configure. These templates can be thought of as an analogue to the Commander service catalog entry. They list the AMIs used to provision instances and they describe information such as security group and availability zones used to configure the instances.
CloudFormation templates have parameters that serve as inputs, such as instance type, SSH key and database credentials. CloudFormation templates provide outputs, such as the ID of a deployed instance and the public IP/DNS name of a load balancer. CloudFormation templates can include resource definitions for EC2, Auto Scaling Groups, RDS, ElastiCache, beanstalk and others. Commander displays all stack resources on the Resources tab.
CloudFormation templates can be configured as single-region or multi-region templates. All resources in a CloudFormation template must be deployed to the same region. You must configure distinct deployment destinations for each AWS region you will deploy to.
Commander allows you to add CloudFormation parameters to the request form with a combination of custom attributes and variables. When you add a CloudFormation template to the service catalog, the parameters and initial values displayed are retrieved from the template. Parameter values are encrypted when saved in the Commander database. Parameters can also be customized during manual deployment.
Custom attributes allow:
- requesters to select parameter values on the form
- requesters to specify a regular expression value for a parameter on the form
- administrators to select parameter values during manual deployment
- administrators to specify a regular expression value for a parameter during manual deployment
Variables allow you to access information about the deployment destination and the request form. See AWS CloudFormation Template Parameter Variables for the list of supported variables.
For example, if your CloudFormation template has a KeyName parameter, you can allow a user to select from available key pairs in the target region and allow an administrator to override the requester's choice.
- Add a CloudFormation template to the catalog as described in Adding AWS Services to the Catalog.
- On the Attributes tab, click Add Attributes.
- In the Add Attributes dialog, click Create New Attribute.
- Type "Key Pair" for the Name, and optionally add a description.
- For Applies To, select All Types.
- For Type, select List (to allow users to select from a list of key pairs).
To allow users to specify a regular expression instead, select Text. See Using Custom Attributes to Add Infrastructure Metadata for more information.
- Clear Edit in Service Portal and click Next.
- On the Configure Attribute page of the wizard, enter a comma-separated list of key pair names.
- Click Add to move your values to the list box.
- Click Finish.
The Key Pair attribute is now selected in the Add Attributes dialog.
- Click OK.
- On the Attributes tab, the Key Pair attribute appears. Select a default key pair if you want.
- On the Form tab, in the Attributes list, click the key pair to add it to the form.
- Click Edit and enable the Required option.
- Click OK to save the form element.
- Back on the Parameters tab, in the KeyName field, enter the following variable:
- Click Finish to save the service in the catalog.
Now, requesters will select a key pair when requesting this CloudFormation template from the service catalog. Their selection will be passed to AWS as a parameter through the Commander variable, unless an administrator overrides the requester's selection during manual deployment of the service request.
As the cost of an AWS stack can't be determined until the stack is created, you must provide an estimated Annual Stack Cost in the service catalog. This cost provides users with an estimate of the stack's cost at request time.
Once the stack is created, its base cost is determined by adding the total cost of the stack resources supported by Commander. Supported stack resources include VMs, load balancer and databases; Auto Scaling Groups are supported, but they don't have a cost. This resource cost is subtracted from the Annual Stack Cost, and the remainder is assigned to a custom attribute called "Additional Costs". The Additional Costs custom attribute captures the cost of all resources in this stack that aren't directly managed by Commander.
For example, let's say you enter an Annual Stack Cost of $4800 in the service catalog. Once the stack is requested and deployed, Commander calculates an annual cost of $3426 for VMs in this stack.
The Additional Costs custom attribute for this stack therefore has a value of $4800 - $783 - $923 - $1720 = $1374. This value is displayed on the stack's Summary tab, in the Details pane, as the Additional Costs property.
If you determine that $1374 is not an accurate cost for the remaining resources in this stack, you can navigate to the stack and set a value for the custom attribute. You can also adjust the value for Annual Stack Cost in the service catalog so that future deployments have a more accurate total cost.
Troubleshooting costing for stacks
If the Additional Costs property for a stack deployed by Commander has a value of 0, this means that the costs for the supported resources exceeded the value you entered for Annual Stack Cost. In this case, you should navigate to the stack and set a value for the custom attribute. You should also adjust the value for Annual Stack Cost in the service catalog so that future deployments have a more accurate total cost.
If a Service Portal user owns a stack, but doesn't own all of the VMs in the stack, the unowned VMs are displayed as unsupported resources. Unsupported resources are displayed in the Resources table for the stack, but the VM name can't be clicked to access its details, and an icon is not displayed in the Type column.