# What are change types?
Change type refers to the action that an AWS Managed Services (AMS) request for change (RFC) performs and encompasses the change action itself, and the type of change – manual vs automated. AMS has a large collection of change types not used by other Amazon web services. You use these change types when submitting a request for change (RFC) to deploy, or manage, or gain access to, resources.
**Topics**
+ [Automated and manual CTs](ug-automated-or-manual.md)
+ [CT approval requirements](constrained-unconstrained-ctis.md)
+ [Change type versions](ct-versions.md)
+ [Create change types](ct-creates.md)
+ [Update change types](ct-updates.md)
+ [Internal-only change types](ct-internals.md)
+ [Change type schemas](ct-schemas.md)
+ [Managing permissions for change types](ct-permissions.md)
+ [Redacting sensitive information from change types](ct-redaction.md)
+ [Finding a change type, using the query option](ug-find-ct-ex-section.md)
# Automated and manual CTs
A constraint on change types is whether they are automated or manual, this is the change type `AutomationStatusId` attribute, called the **Execution mode** in the AMS console.
Automated change types have expected results and execution times and run through the AMS automated system, generally within an hour or less (this largely depends on what resources the CT is provisioning). Manual change types are uncommon, but they are treated differently because they require that an AMS operator act on the RFC before it can be run. That sometimes means communicating with the RFC submitter, so, manual change types require varying lengths of time to complete.
For all scheduled RFCs, an unspecified end time is written to be the time of the specified `RequestedStartTime` plus the `ExpectedExecutionDurationInMinutes` attribute of the submitted change type. For example, if the `ExpectedExecutionDurationInMinutes` is "60" (minutes), and the specified `RequestedStartTime` is `2016-12-05T14:20:00Z` (December 5, 2016 at 4:20 AM), the actual end time would be set to December 5, 2016 at 5:20 AM. To find the `ExpectedExecutionDurationInMinutes` for a specific change type, run this command:
```
aws amscm --profile saml get-change-type-version --change-type-id CHANGE_TYPE_ID --query "ChangeTypeVersion.{ExpectedDuration:ExpectedExecutionDurationInMinutes}"
```
**Note**
Scheduled RFCs with **Execution mode**= Manual, in the Console, must be set to run at least 24 hours in the future.
**Note**
When using manual CTs, AMS recommends that you use the ASAP **Scheduling** option (choose **ASAP** in the console, leave start and end time blank in the API/CLI) as these CTs require an AMS operator to examine the RFC, and possibly communicate with you before it can be approved and run. If you schedule these RFCs, be sure to allow at least 24 hours. If approval does not happen before the scheduled start time, the RFC is rejected automatically.
AMS aims to respond to a manual CT within four hours, and will correspond as soon as possible, but it could take much longer for the RFC to actually be run.
For a list of the CTs that are Manual and require AMS review, see the Change Type CSV file, available on the **Developer's Resources** page of the Console.
**YouTube Video**: [ How can I find automated change types for AMS RFCs?](https://www.youtube.com/watch?v=sOzDuCCOduI&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=2&t=1s)
To find the **Execution mode** for a CT in the AMS console, you must use the **Browse change types** search option. The results show the execution mode of the matching change type or change types.
To find the `AutomationStatus` for a specific change type by using the AMS CLI, run this command:
```
aws amscm --profile saml get-change-type-version --change-type-id CHANGE_TYPE_ID --query "ChangeTypeVersion.{AutomationStatus:AutomationStatus.Name}"
```
You can also look up change types in the [AMS Change Type Reference](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html), which provides information about all AMS change types.
**Note**
The AMS API/CLI are not currently part of the AWS API/CLI. To access the AMS API/CLI, you download the AMS SDK through the AMS console.
# CT approval requirements
AMS CTs always have two approval conditions, **AwsApprovalId** and **CustomerApprovalId** that indicate whether the RFC requires AMS or you, or anyone, to approve the execution.
The approval condition is somewhat related to the execution mode; for details, see [Automated and manual CTs](ug-automated-or-manual.md).
To find out the approval condition for a CT, you can look in the [AMS Change Type Reference](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html), or run [GetChangeTypeVersion](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_GetChangeTypeVersion.html). Both will also give you the CT `AutomationStatusId` or **Execution mode**.
You can approve RFCs by using the AMS console or with the following command:
```
aws amscm approve-rfc --rfc-id RFC_ID
```
**CT approval condition**
| If the CT approval condition is | It requires approval from | And |
| --- | --- | --- |
| `AwsApprovalId: Required` | The AMS change type system, | No action is required. This condition is typical for automated CTs. |
| `AwsApprovalId: NotRequiredIfSubmitter` | The AMS change type system and no one else, if the submitted RFC is for the account it was submitted against, | No action is required. This condition is typical for manual CTs because they will always be reviewed by AMS operators. |
| `CustomerApprovalId: NotRequired` | The AMS change type system, | If the RFC passes syntax and parameter checks, it is auto approved. |
| `CustomerApprovalId: Required` | The AMS change type system and you, | A notification is sent to you, and you must explicitly approve the RFC, either by responding to the notice, or running the [ApproveRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ApproveRfc.html) operation. |
| `CustomerApprovalId: NotRequiredIfSubmitter` | The AMS change type system and no one else, if you submitted the RFC. | If the RFC passes syntax and parameter checks, it is auto approved. |
| Urgent Security Incident or Patch | AMS | Is auto approved and implemented. |
# Change type versions
Change types are versioned and the version changes when a major update is made to the change type.
After selecting a change type using the AMS console, you have the option of opening the **Additional configuration** area and selecting a change type version. You can also specify a change type version at the API/CLI command line. You might want to do this for various reasons, including:
+ You know that the version of the **Update** change type that you want must match the version of the **Create** change type that you used to create the resource that you now want to update. For example, you might have an Elastic Load Balancer (ELB) instance that you created with ELB Create change type version 1. To update it, choose ELB Update version 1.
+ You want to use a change type version that has different options in it than the most recent change type. We don't recommend this because AMS updates change types mainly for security reasons and we recommend that you always choose the most recent version.
# Create change types
Create change types are matched version-to-version with the Update change types. That is, the change type version that you use to provision a resource must match the version of the Update change type that you would use later to modify that resource. For example, if you create an S3 bucket with the Create S3 Bucket change type version 2.0, and later want to submit an RFC to modify that S3 bucket, you must use the Update S3 Bucket change type version 2.0 as well, even if there is an Update S3 Bucket change type with version 3.0.
We recommend keeping a record of the change type ID and version that you use when provisioning a resource with a Create change type in case you later want to use an Update change type to modify it.
# Update change types
AMS provides Update change types to update resources that were created with Create change types. The Update change types must be matched version-to-version with the Create change type originally used to provision the resource.
We recommend keeping a record of the change type ID and version that you use when provisioning a resource to make it easy to update it.
**YouTube Video**: [ How do I use update CTs to change resources in an AWS Managed Services (AMS) account?](https://www.youtube.com/watch?v=dqb31yaAXhc&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=8&t=30s)
# Internal-only change types
You can see change types that are for internal use only. This is so you know what actions AMS can, or does, take. If there is an internal-only change type that you would like to have available for your use, submit a service request.
For example, there is a Management \$1 Monitoring and notification \$1 CloudWatch alarm suppression \$1 Update CT that is internal-only. AMS uses it to deploy infrastructure updates (such as patching) to turn off alarm notifications that the updates might erroneously trigger. When this CT is submitted, you will notice the RFC for the CT in your RFC list. Any internal-only CT that is deployed in an RFC appears in your RFC list.
# Change type schemas
All change types provide a JSON schema for your input in the creation, modification, or access, of resources. The schema provides the parameters, and their descriptions, for you to create a request for change (RFC).
The successful execution of an RFC results in execution output. For provisioning RFCs, the execution output includes a "stack\$1id" that represents the stack in CloudFormation and can be searched in the CloudFormation console. The execution output sometimes includes output of the ID of the instance created and that ID can be used to search for the instance in the corresponding AWS console. For example, the Create ELB CT execution output includes a "stack\$1id" that is searchable in CloudFormation and outputs a key=ELB value= that is searchable in the Amazon EC2 console for Elastic Load Balancing.
Let's examine a CT schema. This is the schema for CodeDeploy Application Create, a fairly small schema. Some schemas have very large `Parameter` areas.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/userguide/ct-schemas.html)
**Note**
This schema allows up to seven tags; however, EC2, EFS, RDS, and the multi-tier create schemas allow up to 50 tags.
# Managing permissions for change types
You can use a custom policy to restrict which change types (CTs) are available to different groups or users.
To learn more about doing this, see the AMS User Guide section [Setting Permissions](https://docs.aws.amazon.com/managedservices/latest/userguide/setting-permissions.html).
# Redacting sensitive information from change types
AMS change type schemas offer a parameter attribute, `"metadata":"ams:sensitive":"true"` that is used for parameters that would contain sensitive information, such as a password. When this attribute is set, the input provided is obscured. Note that you cannot set this parameter attribute; however, if you are working with AMS to create a change type and have a parameter that you would like obscured at input, you can request this.
# Finding a change type, using the query option
This example demonstrates how to use the AMS Console to find the appropriate change type for the RFC that you want to submit.
You can use the console or the API/CLI to find a change type ID (CT) or version. There are two methods, either a search or choosing the classification. For both selection types, You can sort the search by choosing either **Most frequently used**, **Most recently used**, or **Alphabetical**.
**YouTube Video**: [ How do I create an RFC using the AWS Managed Services CLI and where can I find the CT Schema?](https://www.youtube.com/watch?v=IluDFwnJJFU&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=3&t=150s)
In the AMS console, on the **RFCs** -> **Create RFC** page:
+ With **Browse by change type** selected (the default), either:
+ Use the **Quick create** area to select from AMS's most popular CTs. Click on a label and the **Run RFC** page opens with the **Subject** option auto-filled for you. Complete the remaining options as needed and click **Run** to submit the RFC.
+ Or, scroll down to the **All change types** area and start typing a CT name in the option box, you don't have to have the exact or full change type name. You can also search for a CT by change type ID, classification, or execution mode (automated or manual) by entering the relevant words.
With the default **Cards** view selected, matching CT cards appear as you type, select a card and click **Create RFC**. With the **Table** view selected, choose the relevant CT and click **Create RFC**. Both methods open the **Run RFC** page.
+ Alternatively, and to explore change type choices, click **Choose by category** at the top of the page to open a series of drop-down option boxes.
+ Choose **Category**, a **Subcategory**, an **Item**, and an **Operation**. The information box for that change type appears a panel appears at the bottom of the page.
+ When you're ready, press **Enter**, and a list of matching change types appears.
+ Choose a change type from the list. The information box for that change type appears at the bottom of the page.
+ After you have the correct change type, choose **Create RFC**.
**Note**
The AMS CLI must be installed for these commands to work. To install the AMS API or CLI, go to the AMS console **Developers Resources** page. For reference material on the AMS CM API or AMS SKMS API, see the AMS Information Resources section in the User Guide. You may need to add a `--profile` option for authentication; for example, `aws amsskms ams-cli-command --profile SAML`. You may also need to add the `--region` option as all AMS commands run out of us-east-1; for example `aws amscm ams-cli-command --region=us-east-1`.
**Note**
The AMS API/CLI (amscm and amsskms) endpoints are in the AWS N. Virginia Region, `us-east-1`. Depending on how your authentication is set, and what AWS Region your account and resources are in, you may need to add `--region us-east-1` when issuing commands. You may also need to add `--profile saml`, if that is your authentication method.
To search for a change type using the AMS CM API (see [ListChangeTypeClassificationSummaries](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListChangeTypeClassificationSummaries.html)) or CLI:
You can use a filter or query to search. The ListChangeTypeClassificationSummaries operation has [Filters](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListChangeTypeClassificationSummaries.html#amscm-ListChangeTypeClassificationSummaries-request-Filters) options for `Category`, `Subcategory`, `Item`, and `Operation`, but the values must match the existing values exactly. For more flexible results when using the CLI, you can use the `--query` option.
**Change type filtering with the AMS CM API/CLI**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/userguide/ug-find-ct-ex-section.html)
1. Here are some examples of listing change type classifications:
The following command lists all change type categories.
```
aws amscm list-change-type-categories
```
The following command lists the subcategories belonging to a specified category.
```
aws amscm list-change-type-subcategories --category CATEGORY
```
The following command lists the items belonging to a specified category and subcategory.
```
aws amscm list-change-type-items --category CATEGORY --subcategory SUBCATEGORY
```
1. Here are some examples of searching for change types with CLI queries:
The following command searches CT classification summaries for those that contain "S3" in the Item name and creates output of the category, subcategory, item, operation, and change type ID in table form.
```
aws amscm list-change-type-classification-summaries --query "ChangeTypeClassificationSummaries [?contains(Item, 'S3')].[Category,Subcategory,Item,Operation,ChangeTypeId]" --output table
```
```
+---------------------------------------------------------------+
| ListChangeTypeClassificationSummaries |
+----------+-------------------------+--+------+----------------+
|Deployment|Advanced Stack Components|S3|Create|ct-1a68ck03fn98r|
+----------+-------------------------+--+------+----------------+
```
1. You can then use the change type ID to get the CT schema and examine the parameters. The following command outputs the schema to a JSON file named CreateS3Params.schema.json.
```
aws amscm get-change-type-version --change-type-id "ct-1a68ck03fn98r" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateS3Params.schema.json
```
For information about using CLI queries, see [How to Filter the Output with the --query Option](https://docs.aws.amazon.com/cli/latest/userguide/controlling-output.html#controlling-output-filter) and the query language reference, [JMESPath Specification](http://jmespath.org/specification.html).
1. After you have the change type ID, we recommend verifying the version for the change type to make sure it's the latest version. Use this command to find the version for a specified change type:
```
aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CHANGE_TYPE_ID
```
To find the `AutomationStatus` for a specific change type, run this command:
```
aws amscm --profile saml get-change-type-version --change-type-id CHANGE_TYPE_ID --query "ChangeTypeVersion.{AutomationStatus:AutomationStatus.Name}"
```
To find the `ExpectedExecutionDurationInMinutes` for a specific change type, run this command:
```
aws amscm --profile saml get-change-type-version --change-type-id ct-14027q0sjyt1h --query "ChangeTypeVersion.{ExpectedDuration:ExpectedExecutionDurationInMinutes}"
```