Managing AWS

This topic explains how to get started with AWS in Commander, and also explains how managing AWS services differs from managing your on-premise VMware and Hyper-V services. This topic assumes that you understand the basics of AWS.

In this topic:

Getting started

To manage AWS services with Commander, here's how to get started:

  1. Create an Amazon Web Services (AWS) account. Commander uses your account to connect to AWS. All of the private AMIs (Amazon Machine Images) and instances belonging to that account become a single managed system in Commander.
  2. Configure the appropriate AWS policies. You can create your own or modify existing ones. To view AWS assets, the policy must provide at least read access for all objects; to deploy and manage AWS assets, it must provide full access for the appropriate objects.

    Click below for an example IAM policy that allows for inventory and discovery of AWS resources.

  3. Create an access key or an IAM role, depending on the method you want to use to connect to AWS account when you add AWS managed systems to Commander. You create these in the AWS Management Console.
  4. Optional: Add private AMIs to your account. You do this in the AWS Management Console. If you created an instance from a public AMI, you need to convert the instance into an AMI before you can add it as a private AMI to the Service Catalog. When you create a private AMI, you must place it in each region where you want to be able to deploy it.

    This step is not necessary if you add Amazon Marketplace AMIs to the service catalog, or if you're using Amazon CloudFormation templates to deploy stacks (which can include EC2 VMs, EC2 load balancers, EC2 auto scaling groups and RDS databases).

  5. Optional: If Internet access is established through a web proxy server, integrate your web proxy server with Commander. See Connecting Public Clouds to Commander through a Web Proxy Server.
  6. Add your AWS account to Commander as a managed system. See Adding Managed Systems.
  7. Recommended: Retrieve your AWS billing data to ensure the accuracy of VM billing records. See Retrieving AWS Billing Data.
  8. Add private AMIs, Amazon Marketplace AMIs and CloudFormation templates to the Service Catalog. See Adding Multi-Cloud Services to the Catalog or Adding an AWS Service to the Catalog.
  9. Optional: If you want to enable automatic key pair SSH connections to EC2 Linux instances, you can add private keys to Commander. See Managing Key Pairs for AWS Regions.

To learn what features are supported for AWS, see Commander Capability Matrix.

How Commander works with AWS

Two levels of service request automation support

Commander supports both new service request automation and change request automation for EC2 AMIs and instances, as well as CloudFormation templates and stacks. This means that:

  • Amazon EC2 AMIs, Amazon Marketplace AMIs and CloudFormation templates can be added directly to the service catalog
  • Amazon EC2 instances and AWS stacks are deployed directly by Commander
  • Amazon EC2 instances and AWS stacks are affected by approval and completion workflows for new service requests, as well as for change requests

By contrast, Amazon RDS instances, Auto Scaling Groups and Elastic Load Balancers are supported for change request automation, but not for new service request automation. These objects:

  • can't be added directly to the service catalog; instead, they are added as part of a CloudFormation template
  • are deployed only as part of a CloudFormation template by Commander
  • are affected by approval and completion workflows for change requests, but not for new service requests

It's important to understand this distinction. For example, when you add a CloudFormation template to the service catalog, it becomes a service catalog component. A completion workflow can be assigned to the CloudFormation template in the service catalog blueprint for execution on the deployed stack, but not to the resources that will be deployed as part of the stack.

Infrastructure view

Because AWS doesn't provide visibility of its physical compute infrastructure, hosts and clusters are not shown in Commander.

You can hide AWS regions that don't contain any AMIs or instances, which improves usability for Commander administrators. Displaying fewer regions also improves performance by requiring less communication between Commander and AWS, and by not requiring Commander to communicate with geographically distant regions. See Selecting Public Cloud Regions to Display.

To learn about how the Infrastructure, Applications and Storage views differ for AWS managed systems, see Commander Views.

Supported AWS resources

Commander allows you to manage the AWS resources detailed in the following table.

Infrastructure / Resource Type Details

EC2 Instances

EC2 Instances are equivalent to VMs and are displayed as VMs in Commander. Instances can be managed from Commander's Infrastructure and Applications views and can be deployed through the service catalog. EC2 VMs are deployed using preconfigured instance types (such as micro, small, medium and large) rather than fine-grained configuration of CPU, memory, storage and networking resources. When you add an AMI to the Service Catalog, you choose the instance types to make available to users when they request that AMI. Once you have deployed an instance, the instance type and storage resources can be changed through a service change request, with the Reconfigure Resources command, or by applying a rightsizing recommendation.

Instance types added between Commander releases are fully supported in the next Commander release. If a new instance type is added between Commander releases, the instance type won't be available in Commander until a new instance with this instance type is deployed in the public cloud and Commander is synchronized with the public cloud. The new instance type will then be available for use in Commander deployments, but resource and cost information won't be available, and quota won't be calculated.


AMIs (Amazon machine images) are equivalent to VM templates and are displayed as VM templates in Commander. AWS provides a set of public AMIs known as Amazon Marketplace AMIs. Any AMIs you create in AWS are private AMIs. Both private and Marketplace AMIs are available for use in Commander. Private AMIs are available for deployment from Commander's Applications View and can also be added to the service catalog. Marketplace AMIs must be added to the service catalog in order to be deployed; they're not available in the Applications view.

Because private AMIs belong to regions, when you create a private AMI, you must place it in each region where you want to be able to deploy it. By contrast, Marketplace AMIs are global and can generally be deployed to any region.

RDS Instances

Amazon Relational Database Service (RDS) gives you online access to the capabilities of several relational database management systems. RDS instances can be managed from Commander's Infrastructure and Applications views. Deployment of RDS instances in Commander is supported only through CloudFormation templates.

Elastic Load Balancers

Elastic Load Balancers (ELBs) redirect traffic to healthy Amazon EC2 instances for more consistent application performance. An instance can be associated with multiple load balancers. Load balancers can span availability zones. ELBs can be managed from Commander's Infrastructure view. Deployment of ELBs in Commander is supported only through CloudFormation templates.


An Amazon EC2 VM may have both EBS– and instance store–backed volumes. Instance store–backed disks are not persistent: a VM with only instance store–backed disks is deleted when it's powered off. Commander doesn't display instance store–backed volumes. Commander displays EBS-based volumes as VM disks. Unattached volumes (volumes which aren't attached to an instance, but for which you're still charged) are included in the Unlinked Files Report.

Commander retrieves the size of the EBS and S3 disks from AWS during the regular update.

Commander allows you to modify storage resources for existing VMs.


Snapshots are displayed in Commander only as storage usage.

Reserved Instances

Reserved Instances provide a significant discount compared with on-demand pricing. Based on your Amazon EC2 instance uptime, Commander generates Reserved Instance purchase recommendations. You can also use the Reserved Instance Planner report directly to view EC2 Reserved Instance purchases for each combination of operating system, instance type and region, including the projected savings for each purchase.

Auto Scaling Groups

Auto Scaling Groups (ASGs) help you ensure that you have the correct number of EC2 instances available to handle the load for your application. ASGs can be managed from Commander's Infrastructure and Applications views. Deployment of ASGs in Commander is supported only through CloudFormation templates. See also Special considerations for Auto Scaling Groups.

CloudFormation Templates

CloudFormation simplifies provisioning and management on AWS. You can create CloudFormation templates for the service or application architectures you want and have AWS CloudFormation use those templates for reliable provisioning of services or applications (called stacks). CloudFormation 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 groups and availability zones used to configure the instances.

CloudFormation templates have parameters, such as instance type, SSH key and database credentials, that serve as inputs. 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, RDS, ElastiCache, beanstalk and others. You can add CloudFormation templates to the service catalog to deploy stacks.


Stacks can be managed from Commander's Infrastructure and Applications views. All stack resources (whether directly supported by Commander or not) are displayed on the Resources tab of these views. You can deploy a stack by adding a CloudFormation template to the service catalog.


By default, Commander's Infrastructure and Applications views display only the AWS regions that contain resources. See Selecting Public Cloud Regions to Display in Commander to learn how to change this. Commander also supports AWS GovCloud accounts, which have access only to isolated GovCloud regions.

Availability Zones

Each region is divided into multiple availability zones. Availability zones are somewhat equivalent to datacenters. Availability zones can be managed from Commander's Applications view. When deploying to EC2-Classic, Commander supports selection of an availability zone.


EC2 instances run in one of two supported platforms: EC2-Classic and EC2-VPC. Commander supports deployment to both of these platforms, as well as the configuration of automated deployment destinations targeting both platforms. VPCs can be managed from Commander's Infrastructure view.


When deploying to EC2-VPC, you select a subnet, which maps to an availability zone. Subnets are displayed in Commander's Infrastructure, Applications and Storage views. Commander supports the assignment of network zones to subnets. Commander also supports the assignment of subnets during manual and automated deployment.

Security Groups

Security groups are analogous to a firewall configuration, defining inbound and outbound access rules for network traffic. You can assign a security group during manual and automated deployment.

Key Pairs

Key pairs are used to log into EC2 Linux instances and retrieve the Administrator password for certain Windows instances. You can assign a key pair during manual and automated deployment. You can also manage key pairs for AWS regions.

Updates from AWS

Changes made to an AWS managed system within Commander are displayed as soon as the task has finished, just as they are with vCenter and SCVMM managed systems. Unlike vCenter and SCVMM, however, Commander retrieves changes made within AWS at a configurable update frequency. By default, Commander retrieves updates from AWS every 60 minutes. You can change the update frequency, but we recommend keeping at least 60 minutes between updates. The last update time is displayed on the Summary tab for the managed system.

Caution: More frequent updates (meaning lower values for this setting) may impact Commander performance, especially in large installations.

An advanced system property can be used to define an update frequency of less than 10 minutes. Contact for more information.

You can manually resynchronize the AWS inventory, just as you can with vCenter and SCVMM.

Commander retrieves new and updated Amazon Marketplace AMIs every 72 hours by default. You can change this refresh period.


If you configure Commander to retrieve your AWS billing data, Commander adds your billing data to the VM billing records. Retrieving your billing data means that historical VM costs, used in reports such as the VM Billing report, are much more accurate. Commander supports consolidated billing as well as GovCloud account billing.

Ensure that the currency set in Commander matches the currency of your AWS bill.

For all projected AWS costs, such as service catalog costs, deployed service costs and reports with a projected cost model configuration, Commander uses hard-coded costs for all supported component types and instance types, by region.

A cost model is automatically applied when an AWS account is added as a managed system. The cost model enables you to overlay the AWS billing data and hard-coded costs with additional IT support costs, backup costs, and application software licensing costs. You can create additional cost models for different parts of your AWS account.

To make sure your AWS list prices are current, you can use the command workflow Update Public Cloud List Prices. For more information, see Updating Public Cloud List Prices.

The cost model and cost files allow users to see accurate cost estimates when:

  • adding AMIs and CloudFormation templates to the Service Catalog
  • requesting VMs and CloudFormation templates
  • viewing cost details for deployed stacks, VMs, load balancers and databases

The service catalog entry displays the cost of the cheapest instance type defined in the blueprint for that service. Then, when a user requests a service with a particular instance type, Commander stores the cost of the submitted service.

Because Commander doesn't yet support all of the resource types that can be deployed in an AWS stack, there are special considerations when adding a CloudFormation template to the service catalog. See Managing AWS CloudFormation Templates and Stacks to learn more.

Auto Scaling Groups don't have a cost.

Cloud expense management

Commander provides several ways to help reduce your AWS bill.

Watch our Cloud Cost Optimization video.

To benefit most from our cloud expense management, carry out the steps in the following order:

  1. Apply rightsizing recommendations.
  2. Apply and configure power schedule recommendations.
  3. Use Reserved Instance recommendations or the Reserved Instance Planner Report to guide your RI purchases.
  4. Monitor and repeat.

If you begin with RI planning, you may end up purchasing the wrong size or quantity of RIs, which can be an expensive mistake.

Cost optimization is an ongoing, iterative process. Once you've rightsized, set power schedules and purchased RIs, it's critical to monitor your AWS infrastructure and your bill, and continually optimize.


Commander supports quota for AWS, with the following exception.

Load balancers, databases and stacks are not included in resource quota calculations. Resource quota-based service request approval workflows don't work for CloudFormation services. However, because VMs are included in quota calculations, once a stack is deployed, any VMs in the stack may cause quota to be exceeded. Cost quotas are fully supported for AWS services.


You can synchronize AWS tags with Commander custom attributes. Like AWS tags, custom attributes enable you to assign metadata to services and cloud infrastructure. Once assigned, this metadata persists throughout a service's lifecycle, enabling administrators to know exactly what a workload is being used for. Commander can also make power schedule recommendations based on AWS tag values. You can:

  • import tags as custom attributes
  • export custom attributes as tags
  • export the primary owner name, primary owner login, primary owner email address, assigned organization, and expiry date as tags

Networking and security

Amazon EC2 instances can have multiple public and private IP addresses. In Commander, the IP Address property displays the first public IP address; the Private IP property displays the first private IP address. You can view all assigned public and private IP addresses for an EC2 instance by clicking Details next to the Private IP Address property in the General section of the instance's Summary tab.

EC2 instances also have both a public and private DNS entry. In Commander, the DNS Name property displays the public DNS entry; the Private DNS property displays the private DNS entry.

To learn more about EC2 networking, including the differences between EC2-Classic and EC2-VPC, see Network and Security in the AWS documentation.

IAM roles

Commander allows you to assign AWS IAM roles to new VMs in several ways, depending on what works best in your situation. You can assign the required IAM role to the catalog blueprint for each template (AMI), or if you deploy the same template to multiple destinations, you can configure an IAM role for each deployment destination. Using variable substitution, you can assign the IAM role based on information users provide on the request form. Administrators can also assign an IAM role during manual deployment.

Precedence: Assigning the IAM role during manual deployment overrides any other settings. The catalog blueprint setting takes precedence over the deployment destination setting.

Important: Commander doesn't validate IAM role names, so ensure that role names entered in Commander match those in AWS. IAM role names are not case-sensitive.


  • AWS makes a distinction between an instance profile and an IAM role. These two entities generally have the same name, but not always, so it's important to note that you're actually configuring the instance profile. If you want to specify the full ARN (Amazon Resource Profile), specify the Instance Profile ARN, not the IAM Role ARN. See the AWS documentation to learn more.
  • At time of publication, AWS doesn't permit the modification of an IAM role for an existing instance.

Automated deployment

EC2 instances must be deployed in the same AWS region as their source template (or AMI). Therefore, if you are deploying to multiple AWS regions, you need to configure a service catalog entry and deployment destination for each region.

Special considerations for Auto Scaling Groups

If a user powers down a VM that's in an Auto Scaling Group, or submits a change request that results in the VM being powered down (such as changing the instance type or applying a rightsizing recommendation), AWS marks the VM as unhealthy and may terminate and then replace the VM.

When Commander is unable to fulfill a change request or apply a rightsizing recommendation because the VM has been terminated, the task will fail.

Storage and capacity

Because EC2 storage is elastic, Commander properties and variables related to capacity (for example, provisioning level) don't apply to EC2. Likewise, reports based on these properties (such as the Over-provisioned Disk Summary Report) don't include data for EC2. However, each AWS region does limit the number of instances that can be deployed. You can contact Amazon Support to change this limit.

Lifecycle and policy management

Commander's lifecycle and policy management capabilities are fully supported for AWS services, including stacks, instances, auto scaling groups, load balancers and RDS instances.

VM power scheduling

To reduce public cloud costs, Commander supports the ability to schedule a power on/off cycle for VMs. Commander also issues power schedule recommendations. See Configuring VM Power Schedules and Using Power Schedule Recommendations for more details.