# RFC mode RFC mode is the default mode for AMS Advanced operations plan customers. It includes a change management system with requests for change or RFCs and a catalog of change types to use to request the addition or change that you need to your accounts. This change management system provides a level of security in limiting who can make changes to your accounts. For details on AMS Advanced change types, see [What Are AMS Change Types?](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html). For details about onboarding to AMS Advanced, see [AWS Managed Services Onboarding Introduction](https://docs.aws.amazon.com/managedservices/latest/onboardingguide/index.html). For change type example walkthroughs, see the "Additional Information" section for the relevant change type in the *AMS Advanced Change Type Reference* [Change Types by Classification](https://docs.aws.amazon.com/managedservices/latest/ctref/classifications.html) section. **Note** RFC mode was previously called "Change Management mode" or "Standard CM mode." **Topics** + [Learn about RFCs](ex-rfc-works.md) + [What are change types?](understanding-cts.md) + [Troubleshooting RFC errors in AMS](rfc-troubleshoot.md) # Learn about RFCs Requests for change, or RFCs, work in a two-fold manner. First, there are parameters required for the RFC itself. These are the options in the `CreateRfc` API. And second, there are parameters required for the action of the RFC (the execution parameters). To learn about the `CreateRfc` options, see the [CreateRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html) section of the *AMS API Reference*. These options typically appear in the **Additional configurations** area of the Create RFC pages. You can create and submit an RFC with the `CreateRfc` API, `aws amscm create-rfc` CLI, or using the AMS console Create RFC pages. For a tutorial on creating an RFC, see [Create an RFC](ex-rfc-create-col.md). **Topics** + [What are RFCs?](what-r-rfcs.md) + [Authenticate when using the AMS API/CLI](ex-rfc-authentication.md) + [Understand RFC security reviews](rfc-security.md) + [Understand RFC change type classifications](ex-rfc-csio.md) + [Understand RFC action and activity states](ex-rfc-action-state.md) + [Understand RFC status codes](ex-rfc-status-codes.md) + [Understand RFC update CTs and CloudFormation template drift detection](ex-rfc-updates-and-dd.md) + [Schedule RFCs](ex-rfc-scheduling.md) + [Approve or reject RFCs](ex-rfc-approvals.md) + [Request RFC restricted run periods](ex-rfc-restrict-execute.md) + [Create, clone, update, find, and cancel RFCs](ex-rfc-use-examples.md) + [Use the AMS console with RFCs](ex-rfc-gui.md) + [Learn about common RFC parameters](rfc-common-params.md) + [Sign up for the RFC daily email](rfc-digest.md) # What are RFCs? A request for change, or RFC, is how you make a change in your AMS-managed environment, or ask AMS to make a change on your behalf. To create an RFC, you choose from AMS change types, choose RFC parameters (such as schedule), and then submit the request using either the AMS console or the API commands [CreateRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html) and [SubmitRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_SubmitRfc.html). An RFC contain two specifications, one for the RFC itself, and one for the change type (CT) parameters. At the command line, you can use an Inline RFC command, or a standard CreateRfc template in JSON format, that you fill out and submit along with the CT JSON schema file that you create (based on the CT parameters). The CT name is an informal description of the CT. A CSIO (category, subcategory, item, operation) is a more formal description of a CT. Only the CT ID must be specified when creating an RFC. RFCs go through two key stages: Validation and Execution. 1. In the Validation Stage, AMS reviews the RFC Request for completeness and correctness. AMS also evaluates the request for security in accordance with our [security technical standards](rfc-security.md#rfc-security.title). AMS validates that the requested change is valid and executable. 1. In the Execution Stage, AMS attempts the requested changes on your account. AMS handles both stages through an automated process, manual process, or a combination of both. The manual process is handled by the AMS Operations team. For more information, see [Automated and manual CTs](ug-automated-or-manual.md). AMS provides three execution modes for handling requests: + **(AMS Recommended) Execution mode: Automated**. These CTs use automation for RFC validations and executions, which is the quickest way to achieve your business outcomes. + **(AMS Suggested) Execution mode: Manual and Designation: Managed Automation**. These CTs utilize a combination of automated and manual processes for RFC validations and executions. If automation cannot execute your requested change, then the RFC is transferred (by either automated routing or by the creation of a replacement RFC) to the AMS Operations team for manual handling. Submission of these CTs allow for a more structured intake of your request, supplemented by AMS automation to improve the handling and execution outcome time frame. + **Execution mode: Manual and Designation: Review Required**. Changes requested through [ct-1e1xtak34nx76 Management \$1 Other \$1 Other \$1 Update (review required)](https://docs.aws.amazon.com/managedservices/latest/ctref/management-other-other-update-review-required.html) or [ct-0xdawir96cy7k Management \$1 Other \$1 Other \$1 Create (review required)](https://docs.aws.amazon.com/managedservices/latest/ctref/management-other-other-create-review-required.html). These CTs rely on manual handling for validations and executions. These CTs are dependent on manual interpretation of the change request. AMS notifies you when the change has completed successfully (Success) or unsuccessfully (Failure). **Note** For information about troubleshooting RFC failures, see [Troubleshooting RFC errors in AMS](rfc-troubleshoot.md). The following graphic depicts the workflow of an RFC submitted by you. ![\[The workflow of a customer-submitted RFC.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/requestForChange-v5g.png) # Authenticate when using the AMS API/CLI When you use the AMS API/CLI, you must authenticate with temporary credentials. To request temporary security credentials for federated users, cal [ GetFederationToken](https://docs.aws.amazon.com/STS/latest/UsingSTS/CreatingFedTokens.html), [AssumeRole](https://docs.aws.amazon.com/STS/latest/UsingSTS/sts_delegate.html), [AssumeRoleWithSAML](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithsaml), or [ AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithwebidentity) AWS security token service (STS) APIs. A common choice is SAML. After set up, you add an argument to each operation that you call. For example: `aws --profile saml amscm list-change-type-categories`. A shortcut for SAML 2.0 profiles is to set the profile variable at the start of each API/CLI with `set AWS_DEFAULT_PROFILE=saml` (for Windows; for Linux it would be `export AWS_DEFAULT_PROFILE=saml`). For information about setting CLI environment variables, see [ Configuring the AWS Command Line Interface, Environment Variables](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-environment). # Understand RFC security reviews The AWS Managed Services (AMS) change management approval process ensures that we perform a security review of changes we make in your accounts. AMS evaluates all the requests for change (RFCs) against AMS technical standards. Any change that might lower your account's security posture by deviating from the technical standards, goes through a security review. Duringthe security review, AMS highlights relevant risk and, in cases of high or very high security risk, your authorized security personnel accepts or rejects the RFC. All changes are also evaluated to assess for adverse impact on AMS's ability to operate. If potential adverse impacts are found, then additional reviews and approvals are required within AMS. ## AMS technical standards AMS Technical Standards define the minimum security criteria, configurations, and processes to establish the baseline security of your accounts. These standards must be followed by both AMS and you. Any change that could potentially lower the security posture of your account by deviating from the technical standards, goes through a Risk Acceptance process, where relevant risk is highlighted by AMS and accepted or rejected by the authorized security personnel from your end. All such changes are also evaluated to assess if there would be any adverse impact on AMS's ability to operate the account and, if so, additional reviews and approvals are required within AMS. ## RFC customer security risk management (CSRM) process When someone from your organization requests a change to your managed environment, AMS reviews the change to determine whether the request might deteriorate the security posture of your account by falling outside the technical standards. If the request does lower the security posture of the account, AMS notifies your security team contact with the relevant risk, and executes the change; or, if the change introduces high or very high security risk in the environment, AMS seeks explicit approval from your security team contact in the form of risk acceptance (explained next). The AMS Customer Risk Acceptance process is designed to: + Ensure risks are clearly identified and communicated to the right owners + Minimize identified risks to your environment + Obtain and document approval from the designated security contacts who understand your organization's risk profile + Reduce ongoing operational overhead for identified risks ## How to access technical standards and high or very high risks We have made AMS Technical Standards documentation available for your reference in the [https://console.aws.amazon.com/artifact/](https://console.aws.amazon.com/artifact/) as a report. Use the AMS Technical Standards documentation to understand whether a change would require risk acceptance from your authorized security contact prior to submitting a request for change (RFC). Find the Technical Standards report by searching on "AWS Managed Services (AMS) Technical Standards" in the AWS Artifact **Reports** tab search bar after logging in with the default **AWSManagedServicesChangeManagementRole**. **Note** The AMS technical standard document is accessible for the Customer\$1ReadOnly\$1Role in single-account landing zone. In multi-account landing zone, the AWSManagedServicesAdminRole used by security admins and AWSManagedServicesChangeManagementRole used by application teams, can be used to access the document. If your team uses a custom role, create an Other \$1 Other RFC to request access and we will update the specified custom role. # Understand RFC change type classifications The change types that you use when submitting an RFC are divided into two broad categories: + **Deployment**: This classification is for creating resources. + **Management**: This classification is for updating or deleting resources. The **Management** category also contains change types for accessing instances, encrypting or sharing AMIs, and starting,stopping,rebooting, or deleting stacks. # Understand RFC action and activity states `RfcActionState` (API) / **Activity State** (console) help you understand the status of human intervention, or action, on an RFC. Used primarily for manual RFCs, the `RfcActionState` helps you understand when there is action needed by either you or AMS operations, and helps you see when AMS Operations is actively working on your RFC. This provides increased transparency into the actions being taken on an RFC during its lifecycle. `RfcActionState` (API) / **Activity State** (console) definitions: + **AwsOperatorAssigned**: An AWS operator is actively working on your RFC. + **AwsActionPending**: A response or action from AWS is expected. + **CustomerActionPending**: A response or action from the customer is expected. + **NoActionPending**: No action is required from either AWS or the customer. + **NotApplicable**: This state can't be set by AWS operators or customers, and is used only for RFCs that were created prior to this functionality being released. RFC action states differ depending on whether the change type submitted requires manual review and has scheduling set to **ASAP** or not. + RFC **ActionState** changes during the review, approval, and start of a manual change type with deferred scheduling: + After you submit a manual, scheduled, RFC, the **ActionState** automatically changes to **AwsActionPending** to indicate that an operator needs to review and approve the RFC. + When an operator begins actively reviewing your RFC, the **ActionState** changes to **AwsOperatorAssigned**. + When the operator approves your RFC, the RFC Status changes to Scheduled, and the **ActionState** automatically changes to **NoActionPending**. + When the scheduled start time of the RFC is reached, the RFC Status changes to **InProgress**, and the **ActionState** automatically changes to **AwsActionPending** to indicate that an operator needs to be assigned for review of the RFC. + When an operator begins actively running the RFC, they change the **ActionState** to **AwsOperatorAssigned**. + Once completed, the Operator closes the RFC. This automatically changes the **ActionState** to **NoActionPending**. ![\[RFC ActionState changes during the review, approval, and start of a manual change type with deferred scheduling\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/actionStateRfc.png) **Important** Action states can't be set by you. They are either set automatically based on changes in the RFC, or set manually by AMS operators. If you add correspondence to an RFC, the **ActionState** is automatically set to **AwsActionPending**. When an RFC is created, the **ActionState** is automatically set to **NoActionPending**. When an RFC is submitted, the **ActionState** is automatically set to **AwsActionPending**. When an RFC is Rejected, Canceled, or completed with a status of Success or Failure, the **ActionState** is automatically reset to **NoActionPending**. Action states are enabled for both automated and manual RFCs, but mostly matter for manual RFCs because those type of RFCs often require communications. # Review RFC action states use case examples **Use Case: Visibility on Manual RFC Process** + Once you submit a manual RFC, the RFC action state automatically changes to `AwsActionPending` to indicate that an operator needs to review and approve the RFC. When an operator begins actively reviewing your RFC, the RFC action state changes to `AwsOperatorAssigned`. + Consider a manual RFC that has been approved and scheduled and is ready to begin running. Once the RFC status changes to `InProgress`, the RFC action state automatically changes to `AwsActionPending`. It changes again to `AwsOperatorAssigned` once an operator starts actively running the RFC. + When a manual RFC is completed (closed as "Success" or "Failure"), the RFC Action state changes to `NoActionPending` to indicate that no further actions are necessary from either the customer or operator. **Use case: RFC correspondence** + When a manual RFC is `Pending Approval`, an AMS Operator might need further information from you. Operators will post a correspondence to the RFC and change the RFC action state to `CustomerActionPending`. When you respond by adding a new RFC correspondence, the RFC action state automatically changes to `AwsActionPending`. + When an automated or manual RFC has failed, you can add a correspondence to the RFC details, asking the AMS Operator why the RFC failed. When your correspondence is added, the RFC action state is automatically set to `AwsActionPending`. When the AMS operator picks up the RFC to view your correspondence, the RFC action state changes to `AwsOperatorAssigned`. When the operator responds by adding a new RFC correspondence, the RFC action state may be set to `CustomerActionPending`, indicating that there is another response from the customer expected, or to `NoActionPending`, indicating that no response from the customer is needed or expected. # Understand RFC status codes RFC status codes help you track your requests. You can observe these status codes during an RFC run in the CLI output, or by refreshing the RFC list page in the console. You can also see the codes for an RFC on the details page for that RFC, which might look like this: ![\[RFC status codes.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/guiRfcStatusCodes.png) You might see an RFC in your list that you didn't submit. When AMS operators use an internal-only CT, they submit it in an RFC and it displays in your RFC list. For more information, see [Internal-only change types](ct-internals.md). **Important** You can request notifications of RFC state changes. For details, see [RFC State Change Notifications](https://docs.aws.amazon.com/managedservices/latest/userguide/rfc-state-change-notices.html). **RFC status codes** | Success | Failure | | --- | --- | | Editing: the RFC has been created but not submitted PendingApproval / Submitted: The RFC has been submitted and the system is determining if it requires approval, and obtaining that approval, if required Approved by AWS / Approved by customer: the RFC has been approved. Automated RFCs are approved by AWS, manual RFCs are approved by Operators and, sometimes, customers Scheduled: the RFC has passed syntax and requirement checks and is scheduled for running InProgress: the RFC is being run, note that RFCs that provision multiple resources or have long-running UserData, take longer to run Executed: The RFC has been run Success / Succeeded: The RFC has been successfully completed | Rejected: RFCs are rejected typically because they fail validation; for example, an unusable resource, i.e. a subnet, is specified Canceled: RFCs are canceled typically because they do not pass validation before the configured start time has passed Failure: The RFC has failed; see the StatusReason in the output for failure reasons, and AMS operations automatically creates a trouble ticket and communicates with you as needed | **Note** Canceled or rejected RFCs can be re-submitted using [UpdateRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_UpdateRfc.html); see also [Update RFCs](ex-update-rfcs.md). If the RFC passes all the necessary conditions (for example, all required parameters are specified), the status changes to `PendingApproval` (even automated CTs require approval, which happens automatically if syntax and parameter checks pass). If it does not pass, the status changes to `Rejected`. The `StatusReason` provides information about rejections; the `ExecutionOutput` fields provide information about approval and completion. Error codes include: + InvalidRfcStateException: The RFC is in a status that doesn't allow the operation that was called. For example, if the RFC has moved to the Submitted state, it can no longer be modified. + InvalidRfcScheduleException: The StartTime, EndTime, or TimeoutInMinutes parameters were breached. + InternalServerError: A difficulty with the system was encountered. + InvalidArgumentException: A parameter is incorrectly specified; for example, an unacceptable value is used. + ResourceNotFoundException: A value, such as the stack ID, cannot be found. If the scheduled requested start and end times (also known as the change run window) occur before the change is approved, the RFC status changes to `Canceled`. If the change is approved, the RFC status changes to `Scheduled`. The change run window for ASAP RFCs is the submitted time plus the `ExpectedExecutionDuration` value for the CT. At any time before the arrival of the change run window, a scheduled change (submitted with a `RequestedStartTime` in the CLI) can be modified or canceled. If the scheduled change is modified, it must then be re-submitted. When the change start time arrives (scheduled or ASAP) and after approvals are complete, the status changes to `InProgress` and no modifications can be made. If the change is completed within the specified change run window, the status changes to `Success`. If any part of the change fails, or if the change is still in progress when the change run window ends, the status changes to `Failure`. **Note** During the `InProgress`, `Success`, or `Failure` change states, the RFC cannot be modified or canceled. The following diagram illustrates the RFC statuses from the CreateRFC call through to resolution. ![\[The RFC statuses from the CreateRFC call through to resolution.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/RfcStateFlow2.png) # Understand RFC update CTs and CloudFormation template drift detection Resources provisioned in AMS use a modified CloudFormation template. If a resource has a parameter changed directly through a service's AWS Management Console, then the CloudFormation creation record of that resource becomes out of sync. If this happens and you attempt to use an AMS update change type to update the resource in AMS, then AMS references the original resource configuration and potentially resets changed parameters. This reset might be damaging, so AMS disallows RFCs with update change types if any extra AMS configuration changes are detected. For a list of update change types, use the console filter. ## Drift remediation FAQs Questions and answers on AMS drift remediation. There are two change types that you can use to initiate drift remediation, one is execution mode=manual or "managed automation," the other is execution mode=automated. ### Drift remediation supported resources (ct-3kinq0u4l33zf) These are the resources that are supported by the drift remediation change type, (ct-3kinq0u4l33zf).   For remediation of any resource, use the "managed automation" (ct-34sxfo53yuzah) change type instead. ``` AWS::EC2::Instance AWS::EC2::SecurityGroup AWS::EC2::VPC AWS::EC2::Subnet AWS::EC2::NetworkInterface AWS::EC2::EIP AWS::EC2::InternetGateway AWS::EC2::NatGateway AWS::EC2::NetworkAcl AWS::EC2::RouteTable AWS::EC2::Volume AWS::AutoScaling::AutoScalingGroup AWS::AutoScaling::LaunchConfiguration AWS::AutoScaling::LifecycleHook AWS::AutoScaling::ScalingPolicy AWS::AutoScaling::ScheduledAction AWS::ElasticLoadBalancing::LoadBalancer AWS::ElasticLoadBalancingV2::Listener AWS::ElasticLoadBalancingV2::ListenerRule AWS::ElasticLoadBalancingV2::LoadBalancer AWS::CloudWatch::Alarm ``` ### Drift remediation change types Questions and answers on using the AMS drift remediation change types. For a list of supported resources for the drift remediation feature, see [Drift remediation supported resources (ct-3kinq0u4l33zf)](#drift-remeditate-faqs-sr). **Important** Drift remediation modifies the stack template and/or parameters and it is mandatory to update your local template repositories or any automation that is updating these stacks to use the latest stack template and parameters. Using old template and/or parameters without syncing can cause damaging changes to underlying resources. The no managed automation, automated, CT (ct-3kinq0u4l33zf) supports remediating only 10 resources per RFC. To remediate remaining resources in batches of 10 create new RFCs until all resources are remediated. Which drift remediation change type should I use? We recommend using the **no managed automation**, automated CT (ct-3kinq0u4l33zf) when: + You attempt to perform an update to an existing stack resource using an automated CT and the RFC gets rejected as the stack is `DRIFTED`. + You used an Update CT in the past and it failed as the stack was DRIFTED. You do not need to attempt an update again and can use the managed automation, manual, CT instead. We recommend using the **managed automation**, manual CT (ct-34sxfo53yuzah) only when drifted resource types are not supported by the drift remediation no managed automation, automated, CT (ct-3kinq0u4l33zf), or when the drift remediation no managed automation, automated, CT fails. What changes are performed to the stack during remediation? Remediation requires updates to the stack template and/or parameters depending on the properties that are drifted. Remediation also updates the stack policy of the stack during remediation and restores the stack policy to its previous value once remediation is completed. How can we see the changes performed to the stack template and/or parameters? In the response to the RFC, a change summary is provided with the following information: + `ChangeSummaryJson`: Contains change summary of Stack Template and/or Parameters as part of drift remediation. Remediation is performed in multiple phases. This change summary consists of changes for individual phases. If Remediation is successful check changes of the last phase. See ExecutionPlan in the JSON for phases executed in order. For example, RestoreReferences section when present is always executed at the end and contains JSON for post remediation changes. If remediation is run in DryRun mode none of these changes would have been applied to the stack. + `PreRemediationStackTemplateAndConfigurationJson`: Contains configuration snapshot of CloudFormation Stack including Template, Parameters, Outputs, StackPolicyBody before remediation was triggered on the stack. What do I need to do once remediation is performed? You need to update your local template repositories, or any automation, that would be updating the remediated stack, with the latest template and parameters provided in the RFC summary. It is very important to do this because using the old template and/or parameters can cause further destructive changes on the stack resources. Will my application be effected during this remediation? Remediation is an offline process that is performed only on the CloudFormation stack configuration. No updates are performed on the underlying resource. Can I continue using Management \$1 Other \$1 Other RFCs to perform updates to resources after remediation? We recommend that you always perform updates to stack resources using the available automated Update CTs. When the available Update CTs do not support your use case, use Management \$1 Other \$1 Other requests. Does remediation create any new resources in the stack? Remediation does not create any new resources in the stack. However, remediation creates new outputs and updates the stack template [metadata](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/metadata-section-structure.html) section to store the remediation summary for your reference. Will remediation always be successful? Remediation requires careful analysis and validation of the template configuration to determine if it can be performed. In scenarios where these validations fail, the remediation process is stopped and no changes are performed to the stack template or parameters. Also, remediation can only be performed on supported resource types. How can I perform updates to stack resources if remediation is not successful? You can use the Management \$1 Other \$1 Other \$1 Update CT (ct-0xdawir96cy7k) to request changes. AMS monitors such scenarios and works towards improving the remediation solution. Can I remediate stacks that have both supported and unsupported resource types? Yes. However, remediation is performed only if the supported resource types are found DRIFTED in the stack. If any unsupported resource types are DRIFTED, remediation does not continue. Can I request remediation for stacks created through non-CFN Ingest CTs? Yes. Remediation can be performed on stacks irrespective of the change type used for creating the stack. Can I know the changes that would be performed to the stack before remediation? Yes. Both change types provide a **DryRun** option that you can use to request changes that would be performed if the stack was remediated. However, the final remediation changes may differ depending on the drift present on the stack at the time of remediation. # Schedule RFCs The **Scheduling** feature allows you to choose a start time for RFCs. The following options are available in the **Scheduling** feature: + **Execute this change ASAP**: AMS runs the RFC as soon as it's approved. Most CTs are automatically approved. Use this option if don't want the RFC to start at a specific time. + **Schedule this change**: Set a day, time, and time zone for the RFC to run. For automated change types, it's a best practice to request a start time that's at least 10 minutes after you plan to submit the RFC. For managed automation change types, it's required that you request a start time that's at least 24 hours after you plan to submit the RFC. If the RFC isn't approved by the configured start time, then the RFC is rejected. ## Set an RFC schedule To schedule an RFC, use one of the following methods: **Execute this change ASAP**: + Console: Do nothing. This uses the default RFC schedule. + API or CLI: Remove the `RequestedStartTime` and `RequestedEndTime` options in the Create RFC operation. **ASAP** "managed automation" RFCs are auto-rejected if they are not approved within thirty days of submission. **Schedule this change**: + Console: Select the ** Schedule this change** radio button. A **Start time** area opens. Manually type in a day or use the calendar widget to pick a day. Enter a time, in UTC, expressed in ISO 8601 format, and use the drop-down list to pick a location. By default, AMS uses the ISO 8601 format YYYYMMDDThhmmssZ or YYYY-MM-DDThh:mm:ssZ, either format is accepted. **Note** The **Default End Time** is 4 hours from the **Start time** that you enter. To set the **End Time** of your scheduled change beyond 4 hours, use the API or CLI to run the change. + API or CLI: Submit values for the `RequestedStartTime` and `RequestedEndTime` parameters in the Create RFC operation. Passing a configured `RequestedEndTime` doesn't stop the run for an automated change type that has already started. For a "managed automation" change type, if the `RequestedEndTime` is reached while AMS Operations research is still ongoing, and you're in communication with AMS, then you can request an extension, or you might be asked to re-submit the RFC. **Tip** For an example of a UTC time readout, see [UTC](https://time.is/UTC) on the Time-is website. Example ISO 8601 format for a date/time value of 2016-12-05 at 2:20pm: **2016-12-05T14:20:00Z** or **20161205T142000Z**. If you provide... + only a `RequestedStartTime`, the RFC is considered scheduled and the `RequestedEndTime` is populated using the `ExecutionDurationInMinutes` value. + only a `RequestedEndTime`, we throw an InvalidArgumentException. + both `RequestedStartTime` and `RequestedEndTime`, we overwrite the `RequestedEndTime` with the specified start time plus the `ExecutionDurationInMinutes` value. + neither `RequestedStartTime` nor `RequestedEndTime`, we keep those values as null and the RFC is treated as an ASAP RFC. **Note** 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}" ``` ## Use the RFC Priority option Use the **Priority** option in `execution mode = manual` change types to alert AMS Operations to the urgency of the request. **Priority** option in `execution mode = manual`: Specify the priority of a manual RFC as **High**, **Medium**, or **Low**. RFCs classified as **High** are reviewed and approved prior to RFCs classified as **Medium**, subject to RFC service level objectives (SLOs) and their submission times. RFCs with **Low** priority or no priority specified are processed in the order they are submitted. # Approve or reject RFCs RFCs submitted with approval-required (manual) CTs must be approved by you or AMS. Pre-approved CTs are automatically processed. For more information, see [CT approval requirements](constrained-unconstrained-ctis.md). **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. If an approval-required RFC is successfully submitted by AMS, then it must be explicitly approved by you. Or, iff you submit an approval-required RFC, then it must be approved by AMS. If you're required to approve an RFC that AMS submitted, then an email or other predetermined communication is sent to you requesting the approval. The communication includes the RFC ID. After the communication is sent, do one of the followings: + Console Approve or Reject: Use the RFC details page for the relevant RFC: ![\[RFC details page.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/AMS_Console-App-Rej.png) + API / CLI Approve: [ApproveRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ApproveRfc.html) marks a change as approved. The action must be taken by both the owner and operator, if both are required. The following is an example CLI approve command. In the following example, replace RFC\$1ID with the appropriate RFC ID. ``` aws amscm approve-rfc --rfc-id RFC_ID ``` + API / CLI Reject: [RejectRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_RejectRfc.html) marks a change as rejected. The following is an example CLI reject command. In the following example, replace RFC\$1ID with the appropriate RFC ID. ``` aws amscm reject-rfc --rfc-id RFC_ID --reason "no longer relevant" ``` # Request RFC restricted run periods Formerly known as blackout days, you can request to restrict certain time periods. No changes can be run during those times. To set a restricted run period, use the [UpdateRestrictedExecutionTimes](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_UpdateRestrictedExecutionTimes.html) API operation and set a specific time period, in UTC. The period that you specify overrides any previous periods that were specified. If you submit an RFC during the specified restricted run time, submission fails with the error Invalid RFC Schedule. You can specify up to 200 restricted time periods. By default, no restricted period is set. The following is an example request command (with SAML authentication configured): ``` aws amscm --profile saml update-restricted-execution-times --restricted-execution-times="[{\"TimeRange\":{\"StartTime\":\"2018-01-01T12:00:00Z\",\"EndTime\":\"2018-01-01T12:00:01Z\"}}]" ``` You can also view your current RestrictedExecutionTimes setting by running the [ListRestrictedExecutionTimes](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListRestrictedExecutionTimes.html) API operation. Example: ``` aws amscm --profile saml list-restricted-execution-times ``` If you want to submit an RFC during a specified restricted execution time, then add the **RestrictedExecutionTimesOverrideId** with the value of **OverrideRestrictedTimeRanges**, and then submit the RFC as you normally would. It's a best practice to only use this method for a critical or emergency RFC. For more information, see the API reference for [SubmitRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_SubmitRfc.html). # Create, clone, update, find, and cancel RFCs The following examples walk you through various RFC operations. **Topics** + [Create an RFC](ex-rfc-create-col.md) + [Clone RFCs (re-create) with the AMS console](ex-clone-rfcs.md) + [Update RFCs](ex-update-rfcs.md) + [Find RFCs](ex-rfc-find-col.md) + [Cancel RFCs](ex-cancel-rfcs.md) # Create an RFC ## Creating an RFC with the console The following is the first page of the RFC Create process in the AMS console, with **Quick cards** open and **Browse change types** active: ![\[Quick create section with options for common AWS stack operations and access management.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/quickCreate1.png) The following is the first page of the RFC Create process in the AMS console, with **Select by category** active: ![\[Create RFC page with change type categorization options for managed services environment.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/guiRfcCreate1-2.png) How it works: 1. Navigate to the **Create RFC** page: In the left navigation pane of the AMS console click **RFCs** to open the RFCs list page, and then click **Create RFC**. 1. Choose a popular change type (CT) in the default **Browse change types** view, or select a CT in the **Choose by category** view. + **Browse by change type**: You can click on a popular CT in the **Quick create** area to immediately open the **Run RFC** page. Note that you cannot choose an older CT version with quick create. To sort CTs, use the **All change types** area in either the **Card** or **Table** view. In either view, select a CT and then click **Create RFC** to open the **Run RFC** page. If applicable, a **Create with older version** option appears next to the **Create RFC** button. + **Choose by category**: Select a category, subcategory, item, and operation and the CT details box opens with an option to **Create with older version** if applicable. Click **Create RFC** to open the **Run RFC** page. 1. On the **Run RFC** page, open the CT name area to see the CT details box. A **Subject** is required (this is filled in for you if you choose your CT in the **Browse change types** view). Open the **Additional configuration** area to add information about the RFC. In the **Execution configuration** area, use available drop-down lists or enter values for the required parameters. To configure optional execution parameters, open the **Additional configuration** area. 1. When finished, click **Run**. If there are no errors, the **RFC successfully created** page displays with the submitted RFC details, and the initial **Run output**. 1. Open the **Run parameters** area to see the configurations you submitted. Refresh the page to update the RFC execution status. Optionally, cancel the RFC or create a copy of it with the options at the top of the page. ## Creating an RFC with the CLI How it works: 1. Use either the Inline Create (you issue a `create-rfc` command with all RFC and execution parameters included), or Template Create (you create two JSON files, one for the RFC parameters and one for the execution parameters) and issue the `create-rfc` command with the two files as input. Both methods are described here. 1. Submit the RFC: `aws amscm submit-rfc --rfc-id ID` command with the returned RFC ID. Monitor the RFC: `aws amscm get-rfc --rfc-id ID` command. To check the change type version, use this command: ``` aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CT_ID ``` **Note** You can use any `CreateRfc` parameters with any RFC whether or not they are part of the schema for the change type. For example, to get notifications when the RFC status changes, add this line, `--notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}"` to the RFC parameters part of the request (not the execution parameters). For a list of all CreateRfc parameters, see the [AMS Change Management API Reference](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html). *INLINE CREATE*: Issue the create RFC command with execution parameters provided inline (escape quotes when providing execution parameters inline), and then submit the returned RFC ID. For example, you can replace the contents with something like this:: ``` aws amscm create-rfc --change-type-id "CT_ID" --change-type-version "VERSION" --title "TITLE" --execution-parameters "{\"Description\": \"example\"}" ``` *TEMPLATE CREATE*: **Note** This example of creating an RFC uses the Load Balancer (ELB) stack change type. 1. Find the relevant CT. The following command searches CT classification summaries for those that contain "ELB" in the **Item** name and creates output of the Category, Item, Operation, and ChangeTypeID in table form (Subcategory for both is `Advanced stack components`). ``` aws amscm list-change-type-classification-summaries --query "ChangeTypeClassificationSummaries[?contains(Item,'ELB')].[Category,Item,Operation,ChangeTypeId]" --output table ``` ``` --------------------------------------------------------------------- | CtSummaries | +-----------+---------------------------+---------------------------+ | Deployment| Load balancer (ELB) stack | Create | ct-123h45t6uz7jl | | Management| Load balancer (ELB) stack | Update | ct-0ltm873rsebx9 | +-----------+---------------------------+---------------------------+ ``` 1. Find the most current version of the CT: `ChangeTypeId` and `ChangeTypeVersion`: The change type ID for this walkthrough is `ct-123h45t6uz7jl` (create ELB), to find out the latest version, run this command: ``` aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=ct-123h45t6uz7jl ``` 1. Learn the options and requirements. The following command outputs the schema to a JSON file named CreateElbParams.json. ``` aws amscm get-change-type-version --change-type-id "ct-123h45t6uz7jl" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateElbParams.json ``` 1. Modify and save the execution parameters JSON file. This example names the file CreateElbParams.json. For a provisioning CT, the StackTemplateId is included in the schema and must be submitted in the execution parameters. For TimeoutInMinutes, how many minutes are allowed for the creation of the stack before the RFC is failed, this setting will not delay the RFC execution, but you must give enough time (for example, don't specify "5"). Valid values are "60" up to "360," for CTs with long-running UserData: Create EC2 and Create ASG. We recommend the max allowed "60" for all other provisioning CTs. Provide the ID of the VPC where you want the stack to be created; you can get the VPC ID with the CLI command `aws amsskms list-vpc-summaries`. ``` { "Description": "ELB-Create-RFC", "VpcId": "VPC_ID", "StackTemplateId": "stm-sdhopv00000000000", "Name": "MyElbInstance", "TimeoutInMinutes": 60, "Parameters": { "ELBSubnetIds": ["SUBNET_ID"], "ELBHealthCheckHealthyThreshold": 4, "ELBHealthCheckInterval": 5, "ELBHealthCheckTarget": "HTTP:80/", "ELBHealthCheckTimeout": 60, "ELBHealthCheckUnhealthyThreshold": 5, "ELBScheme": false } } ``` 1. Output the RFC JSON template to a file in your current folder named CreateElbRfc.json: ``` aws amscm create-rfc --generate-cli-skeleton > CreateElbRfc.json ``` 1. Modify and save the CreateElbRfc.json file. Because you created the execution parameters in a separate file, remove the `ExecutionParameters` line. For example, you can replace the contents with something like this: ``` { "ChangeTypeVersion": "2.0", "ChangeTypeId": "ct-123h45t6uz7jl", "Title": "Create ELB" } ``` 1. Create the RFC. The following command specifies the execution parameters file and the RFC template file: ``` aws amscm create-rfc --cli-input-json file://CreateElbRfc.json --execution-parameters file://CreateElbParams.json ``` You receive the ID of the new RFC in the response and can use it to submit and monitor the RFC. Until you submit it, the RFC remains in the editing state and does not start. ## Tips **Note** You can use the AMS API/CLI to create an RFC without creating an RFC JSON file or a CT execution parameters JSON file. To do this, you use the `create-rfc` command and add the required RFC and execution parameters to the command, this is called "Inline Create". Note that all provisioning CTs have contained within the `execution-parameters` block a `Parameters` array with the parameters for the resource. The parameters must have quote marks escaped with a back slash (\$1). The other documented method of creating an RFC is called "Template Create." This is where you create a JSON file for the RFC parameters and another JSON file for the execution parameters, and submit the two files with the `create-rfc` command. These files can serve as templates and be re-used for future RFCs. When creating RFCs with templates, you can use a command to create the JSON file with the contents you want by issuing a command as shown. The commands create a file named "parameters.json" with the shown content; you could also use these commands to create the RFC JSON file. # Clone RFCs (re-create) with the AMS console You can use the AMS console to clone an existing RFC. To clone, or recreate, an RFC by using the AMS console, follow these steps: 1. Find the relevant RFC. From the left navigation, click **RFCs**. The RFCs dashboard opens. 1. Scroll through the pages until you find the RFC you want to clone. Use the **Filter** option to narrow the list. Choose the RFC that you want to clone. The RFC details page opens. 1. Click **Create a Copy**. The **Create a request for change** page opens with all options set as in the original RFC. 1. Make the changes you want. To set additional options, change the **Basic** option to **Advanced**. After you have set all options, choose **Submit**. The active RFC details page opens with a new RFC ID for the cloned RFC and the cloned RFC appears in the RFC dashboard. # Update RFCs You can resubmit an RFC that has been rejected or that has not yet been submitted, by updating the RFC and then submitting it, or re-submitting it. Note that most RFCs are rejected because the specified `RequestedStartTime` has passed before submission or the specified TimeoutInMinutes is inadequate to run the RFC (since TimeoutInMinutes does not prolong a successful RFC, we recommend always setting this to at least "60" and up to "360" for an Amazon EC2 or an Amazon EC2 Auto Scaling group with long-running UserData). This section describes how to use the CLI version of the `UpdateRfc` command to update an RFC with a new RFC parameter, or new parameters using either stringified JSON or an updated parameters file. This example describes using the CLI version of the AMS UpdateRfc API (see [Update RFC](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/update-rfc.html)). While there are change types for updating some resources (DNS private and public, load balancer stacks, and stack patching configuration), there is no CT to update an RFC. We recommend that you submit one UpdateRfc operation at a time. If you submit multiple updates, for example on a DNS stack, the updates might fail attempting to update the DNS at the same time. REQUIRED DATA: `RfcId`: The RFC you're updating. OPTIONAL DATA: `ExecutionParameters`: Unless you're updating a non-required field, like `Description`, you would submit modified execution parameters to address the issues that caused the RFC to be rejected or canceled. All submitted non-null values overwrite those values in the original RFC. 1. Find the relevant rejected or canceled RFC, you can use this command (you can substitute the value with `Canceled`): ``` aws amscm list-rfc-summaries --filter Attribute=RfcStatusId,Value=Rejected ``` 1. You can modify any of the following RFC parameters : ``` { "Description": "string", "ExecutionParameters": "string", "ExpectedOutcome": "string", "ImplementationPlan": "string", "RequestedEndTime": "string", "RequestedStartTime": "string", "RfcId": "string", "RollbackPlan": "string", "Title": "string", "WorstCaseScenario": "string"} ``` Example command updating the Description field: ``` aws amscm update-rfc --description "AMSTestNoOpsActionRequired" --rfc-id "RFC_ID" --region us-east-1 ``` Example command updating the ExecutionParameters VpcId field: ``` aws amscm update-rfc --execution-parameters "{\"VpcId\":\"VPC_ID\"}" --rfc-id "RFC_ID" --region us-east-1 ``` Example command updating the RFC with an execution parameters file that contains the updates; see example execution parameters file in step 2 of: [EC2 stack \$1 Create](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ec2-stack-create.html): ``` aws amscm update-rfc --execution-parameters file://CreateEc2ParamsUpdate.json --rfc-id "RFC_ID" --region us-east-1 ``` 1. Resubmit the RFC using `submit-rfc` and the same RFC ID that you have from when the RFC was first created: ``` aws amscm submit-rfc --rfc-id RFC_ID ``` If the RFC succeeds, you receive no confirmation or error messages at the command line. 1. To monitor the status of the request and to view Execution Output, run the following command. ``` aws amscm get-rfc --rfc-id RFC_ID ``` # Find RFCs ## Find a request for change (RFC) with the console To find an RFC by using the AMS console, follow these steps. **Note** This procedure applies only to scheduled RFCs, that is, RFCs that did not use the **ASAP** option. 1. From the left navigation, click **RFCs**. The RFCs dashboard opens. 1. Scroll through the list or use the **Filter** option to refine the list. The RFC list changes per filter criteria. 1. Choose the Subject link for the RFC you want. The RFC details page opens for that RFC with information including RFC ID. 1. If there are many RFCs in the dashboard, you can use the **Filter** option to search by RFC: + **Subject**: The subject line, or title (in the API/CLI) given to the RFC when it was created. + **RFC ID**: The identifier for the RFC. + **Activity state**: If you know the RFC state, you can choose between **AwsOperatorAssigned** meaning an operator is currently looking at the RFC, **AwsActionPending** meaning that an AMS operator must perform something before the RFC execution can proceed or **CustomerActionPending** meaning that you need to take some action before the RFC execution can proceed. + **Status**: If you know the RFC status, you can choose between: + **Scheduled**: RFCs that were scheduled. + **Canceled**: RFCs that were canceled. + **In progress**: RFCs in progress. + **Success**: RFCs that executed successfully. + **Rejected**: RFCs that were rejected. + **Editing**: RFCs that are being edited. + **Failure**: RFCs that failed. + **Pending approval**: RFCs that cannot proceed until either AMS or you approve. Typically, this indicates that you need to approve the RFC. You will have gotten a service notification of this in your Service Requests list. + **Change type**: Pick the **Category**, **Subcategory**, **Item**, and **Operation**, and the change type ID is retrieved for you. + **Requested start time** or **Requested end time**: This filter option lets you choose **Before** or **After**, and then enter a **Date** and, optionally, a **Time** (hh:mm and time zone). This filter operates successfully only on scheduled RFCs (not ASAP RFCs). + **Status**: Either **Scheduled**, **Canceled**, **In progress**, **Success**, **Rejected**, **Editing**, or **Failure**. + **Subject**: The subject (or title, if the RFC was created with the API/CLI) that you gave the RFC. + **Change type ID**: Use the identifier for the change type submitted with the RFC. The search allows you to add the filters, as shown in the following screenshot. ![\[Search or filter options including Subject, RFC ID, Activity state, and various time-related fields.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/filterRfcAllOptions3.png) 1. Click on the Subject link for the RFC you want. The RFC details page opens for that RFC with information including RFC ID. ## Finding a request for change (RFC) with the CLI You can use multiple filters to find an RFC. To check the change type version, use this command: ``` aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CT_ID ``` **Note** You can use any `CreateRfc` parameters with any RFC whether or not they are part of the schema for the change type. For example, to get notifications when the RFC status changes, add this line, `--notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}"` to the RFC parameters part of the request (not the execution parameters). For a list of all CreateRfc parameters, see the [AMS Change Management API Reference](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html). If you don’t write down the RFC ID, and need to find it later, you can use the AMS change management (CM) system to search for it and narrow the results with a filter or query. 1. The CM API [ListRfcSummaries](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListRfcSummaries.html) operation has filters. You can [Filter](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_Filter.html) results based on an `Attribute` and `Value` combined in a logical AND operation, or based on an `Attribute`, a `Condition`, and `Values`. **RFC filtering** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/ex-rfc-find-col.html) Examples: To find the IDs of all the RFCs related to SQS (where SQS is contained in the Item portion of the CT), you can use this command: ``` list-rfc-summaries --query 'RfcSummaries[?contains(Item.Name,`SQS`)].[Category.Id,Subcategory.Id,Type.Id,Item.Id,RfcId]' --output table ``` Which returns something like this: ``` ---------------------------------------------------------------------------- | ListRfcSummaries | +----------+--------------------------------+-------+-------+----------------+ |Deployment| Advanced Stack Components |SQS |Create |ct-123h45t6uz7jl| |Management| Monitoring & Notification |SQS |Update |ct-123h45t6uz7jl| +----------+--------------------------------+-------+-------+----------------+ ``` Another filter available for `list-rfc-summaries` is `AutomationStatusId`, to look for RFCs that are automated or manual: ``` aws amscm list-rfc-summaries --filter Attribute=AutomationStatusId,Value=Automated ``` Another filter available for `list-rfc-summaries` is `Title` (**Subject** in the console): ``` Attribute=Title,Value=RFC-TITLE ``` Example of the new request structure in JSON that returns RFCs where: + (Title CONTAINS the phrase "Windows 2012" OR "Amazon Linux") AND + (RfcStatusId EQUALS "Success" OR "InProgress") AND + (20170101T000000Z <= RequestedStartTime <= 20170103T000000Z) AND (ActualEndTime <= 20170103T000000Z) ``` { "Filters": [ { "Attribute": "Title", "Values": ["Windows 2012", "Amazon Linux"], "Condition": "Contains" }, { "Attribute": "RfcStatusId", "Values": ["Success", "InProgress"], "Condition": "Equals" }, { "Attribute": "RequestedStartTime", "Values": ["20170101T000000Z", "20170103T000000Z"], "Condition": "Between" }, { "Attribute": "ActualEndTime", "Values": ["20170103T000000Z"], "Condition": "Before" } ] } ``` **Note** With more advanced `Filters`, AMS intends to deprecate the following fields in an upcoming release: Value: The Value field is part of the Filters field. Use the Values field that supports more advanced functionality. RequestedEndTimeRange: Use the RequestedEndTime inside the Filters field that supports more advanced functionality RequestedStartTimeRange: Use the RequestedStartTime inside the Filters field that supports more advanced functionality. 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. If you're using the AMS console: Go to the **RFCs** list page. If needed, you can filter on the RFC **Subject**, which is what you entered as the RFC `Title` when you created it. ## Tips **Note** This procedure applies only to scheduled RFCs, that is, RFCs that did not use the **ASAP** option. # Cancel RFCs You can cancel an RFC using the Console or the AMS API/CLI. To cancel an RFC with the console, find the RFC in your RFC list, open it, click **Cancel**. Required Data: + `Reason`: Why you are canceling the RFC. + `RfcId`: The RFC you are canceling. 1. Typically you would cancel an RFC right after submitting it (so the RFC ID should be handy); otherwise, you would not be able to cancel it unless you scheduled it and it's before the specified start time. If you need to find the RFC ID, you can use this command (you can substitute the `Value` with `PendingApproval` for an RFC that is manually approved): ``` aws amscm list-rfc-summaries --filter Attribute=RfcStatusId,Value=Scheduled ``` 1. Example command to cancel an RFC: ``` aws amscm cancel-rfc --reason "Bad Stack ID" --rfc-id "RFC_ID" --profile saml --region us-east-1 ``` # Use the AMS console with RFCs The AMS console provides features to help you succeed with creating and submitting RFCs. ## Use the RFC List page (Console) The AMS console **RFCs** list page provides you with the following options: + Advanced RFC search through a **Filter**. For information, see [Find RFCs](ex-rfc-find-col.md). + Finding the last time the RFC was **Modified**. This value represents that last time that the RFC status was changed. + Viewing RFC details with the RFC **Subject**. Choosing this link opens the details page for that RFC. + Viewing RFC status. For information, see [Understand RFC status codes](ex-rfc-status-codes.md) ![\[RFC list page.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/guiRfcListTable.png) ## Use RFC quick create (console) Use the RFC quick create cards, or list table, or choose change types for RFCs by classification. To learn more, see [Create an RFC](ex-rfc-create-col.md). ## Add RFC correspondence and attachments (console) You can add correspondence to an RFC after it has been submitted and before it is approved; for example, while it's in the state of "PendingApproval". After an RFC is approved (in a state of "Scheduled" or "InProgress"), correspondence cannot be added, because it could be construed as a change to the request. After an RFC is completed (in a state of "Canceled", "Rejected", "Success", or "Failure"), correspondence is once again enabled, though correspondence is disabled once an RFC is closed for more than 30 days. **Note** Each correspondence is limited to 5,000 characters. **Limitations for attachments:** + Only three attachments per correspondence. + Limit fifty attachments per RFC. + Each attachment must be less than 5 MB in size. + Only text files are accepted such as plaintext (`.txt`), comma-separated values (`.csv`), JSON (`.json`), or YAML (`.yaml`). In the case of YAML format, the file must be attached using file extension `.yaml`. **Note** Text files that have XML content are prohibited. If you have XML content to share with AMS, use a service request. + File names are limited to 255 characters, with only numbers, letters, spaces, dashes (-), underscores (\$1), and dots (.). + Updating and deleting attachments on an RFC is not currently supported. To add correspondence and attachments to an RFC, follow these steps: 1. In the AMS console, on the RFC details page for an RFC, find the **Correspondence** section at the bottom of the page. Before any correspondence: ![\[Empty correspondence section.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/correspondence-rfc-detail-new.png) After some correspondence: ![\[Correspondence section showing reply form and received correspondence.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/correspondence-reply-form2.png) 1. To add a new correspondence, type your message in the **Reply** text box. To attach files related to the correspondence, choose **Add Attachment**, and then choose the files you want. ![\[Correspondence section showing comment box and attachments.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/correspondence-add-attachments.png) 1. When you're finished, choose **Submit**. The new correspondence, along with links to the attached files, appear in the correspondence list on the RFC details page. ![\[List of received correspondence.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/correspondence-list2.png) # Configure RFC email notifications (console) The AMS console **Requests for Change** create page provides you with an option to add email addresses to receive notifications of RFC state changes: ![\[Add email addresses to receive notifications of RFC state changes.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/emailNoticeOption2.png) Additionally, you can add email addresses for notifications to any change type, for example: ``` aws amscm create-rfc --change-type-id --change-type-version 1.0 --title "TITLE" --notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}" ``` Add a similar line (`--notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}"`) to any change type inline or template request in the RFC parameters part of the request, not the parameters part. # Learn about common RFC parameters The following are RFC parameters that you are required to submit, and parameters that are commonly used in RFCs: + Change type information: ChangeTypeId and ChangeTypeVersion. Ror a list of change type IDs and version numbers, see [Change Type Reference](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html). Run `list-change-type-classification-summaries` in the CLI with the `query` argument to narrow the results. For example, narrow results to change types that contain "Access" in the `Item` name. ``` aws amscm list-change-type-classification-summaries --query "ChangeTypeClassificationSummaries [?contains (Item, 'access')].[Category,Subcategory,Item,Operation,ChangeTypeId]" --output table ``` Run `get-change-type-version` and specify the change type ID. The following command gets the CT version for ct-2tylseo8rxfsc. ``` aws amscm get-change-type-version --change-type-id ct-2tylseo8rxfsc ``` + Title: A name for the RFC; this becomes the **Subject** of the RFC in the AMS console RFC list and you can search on it with the `GetRfc` command and a filter on `Title` + Scheduling: If you want a scheduled RFC, you must include the `RequestedStartTime` and `RequestedEndTime` parameters, or use the **Schedule this change** console option. For an **ASAP** RFC (that runs as soon as it's approved), when using the CLI, leave `RequestedStartTime` and `RequestedEndTime` null. When using the console, accept the **ASAP** option. If the `RequestedStartTime` is missed, the RFC is rejected. + Provisioning CTs: The execution parameters, or `Parameters` are the specific settings that are required to provision the resource. They vary widely depending on the CT. + Non-provisioning CTs: CTs that do not provision a resource, such as access CTs or Other \$1 Other, or delete stack, have minimal execution parameters and no `Parameters` block. + Some RFCs also require that you specify a `TimeoutInMinutes`, or how many minutes are allowed for the creation of the stack before the RFC is failed. Valid values are 60 (minutes) up to 360, for long-running UserData. If the execution can't be completed before the `TimeoutInMinutes` is exceeded, the RFC fails. However, this setting doesn't delay the execution of the RFC. + RFCs that create instances, such as an S3 bucket or an ELB, generally provide a schema that allows you to add up to seven tags (key/value pairs). You can add more tags to your S3 bucket by submitting an RFC using the Deployment \$1 Advanced stack components \$1 Tag \$1 Create change type (ct-3cx7we852p3af). EC2, EFS, RDS, and the multi-tiered (HA Two-Tiered and HA One-Tiered) schemas allow up to fifty tags. Tags are specified in the `ExecutionParameters` part of the schema. Providing tags can be of great value. For more information, see [Tagging Your Amazon EC2 Resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html). When using the AMS console, you must open the **Additional configuration** area in order to add tags. **Tip** Many CT schemas have a `Description` and `Name` field near the top of the schema. Those fields are used to name the stack or stack component, they don't name the resource you're creating. Some schemas offer a parameter to name the resource you're creating, and some do not. For example, the CT schema for Create EC2 stack doesn't offer a parameter to name the EC2 instance. In order to do so, you must create a tag with the key "Name" and the value of what you want the name to be. If you do not create such a tag, your EC2 instance displays in the EC2 console without a name attribute. ## Use the RFC AWS Region option The AMS API and CLI (`amscm` and `amsskms`) endpoints are in `us-east-1`. If you federate with Security Assertion Markup Language (SAML), then scripts are provided to you at onboarding that set your AWS Region to us-east-1. If you use SAML, then you don't need to specify the `--region` option when you issue a command. If your SAML is configured to use us-east-1 but your account isn't in that AWS Region, then you must specify your account-onboarded Region when you issue other AWS commands (for example, `aws s3`). **Note** Most of the command examples provided in this guide don't include the `--region` option. # Sign up for the RFC daily email You can sign up for a daily email summarizing the RFC activity in your account over the last 24 hours using the RFC digest feature. The RFC digest feature is a streamlined process that reduces the number of email notifications you receive regarding your account's RFCs. The RFC digest might reduce the likelihood that you miss actions that are pending your response. To turn on the RFC digest feature, contact your AMS Cloud Service Delivery Manager (CSDM). The CSDM subscribes you. You can request up to 20 email addresses (or aliases) to include on your RFC digest email list. The current email schedule is fixed at 09:00 UTC-8. To turn off the RFC digest feature, contact your CSDM with your request. If you don't set up RFC digest and want notifications regarding your RFCs, or if you want more detailed information on your RFCs than what the RFC digest provides, then use the Change Management System to set up CloudWatch Events notifications or email notifications for every individual RFC that you want information on. For information on setting up RFC notifications, see [RFC State Change Notifications](https://docs.aws.amazon.com/managedservices/latest/userguide/rfc-state-change-notices.html). The topics contained in the RFC digest include the following: + Pending Customer Approval: Lists RFCs that are in **PendingApproval** status, awaiting your approval + Pending Customer Reply: Lists RFCs that are awaiting your reply on RFC correspondence + Pending AWS Approval or Reply: Lists RFCs that are waiting on AMS for reply or approval + Completed: Lists RFCs in **Success**, **Failure**, **Cancelled** and **Rejected** status The following is an example RFC digest: ![\[Example RFC digest\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/RFCDigestExample.png) # 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/onboardingguide/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/onboardingguide/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}" ``` # Troubleshooting RFC errors in AMS Many AMS provisioning RFC failures can be investigated through the CloudFormation documentation. See [ Troubleshooting AWS CloudFormation: Troubleshooting Errors](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors) Additional troubleshooting suggestions are provided in the following sections. ## "Management" RFC errors in AMS AMS "Management" Category change types (CTs) allow you to request access to resources as well as manage existing resources. This section describes some common issues. ### RFC access errors + Make sure the Username and FQDN you specified in the RFC are correct and exist in the domain. For help finding your FQDN, see [Finding your FQDN](https://docs.aws.amazon.com/managedservices/latest/userguide/find-FQDN.html). + Make sure the stack ID you specified for access is an EC2-related stack. Stacks such as ELB and Amazon Simple Storage Service (S3) are not candidates for access RFCs, instead, use your read only access role to get access these stacks resources. For help finding a stack ID, see [Finding stack IDs](https://docs.aws.amazon.com/managedservices/latest/userguide/find-stack.html) + Make sure the stack ID you provided is correct and belongs to the relevant account. For help with other access RFC failures, see [Access management](https://docs.aws.amazon.com/managedservices/latest/userguide/access-mgmt.html). **YouTube Video**: [ How do I raise a Request for Change (RFC) properly to avoid rejections and failures?](https://www.youtube.com/watch?v=IFOn4Q-5Cas&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=5&t=242s) ### RFC (manual) CT scheduling errors Most change types are ExecutionMode=Automated, but some are ExecutionMode=Manual and that affects how you should schedule them to avoid RFC failure. Scheduled RFCs with ExecutionMode=Manual, must be set to execute at least 24 hours in the future if you are using the AMS Console to create the RFC. AMS aims to respond to a manual CT within eight hours, and will correspond as soon as possible, but it could take much longer for the RFC to actually be executed. ### Using RFCs with manual update CTs AMS Operations reject Management \$1 Other \$1 Other RFCs for updates to stacks, when there is an Update change type for the type of stack that you want to update. ### RFC delete stack errors RFC delete stack failures: If you use the Management \$1 Standard stacks \$1 Stack \$1 Delete CT, you will see the detailed events in the CloudFormation Console for the stack with the AMS stack name. You can identify your stack by checking it against the name it has in the AMS Console. The CloudFormation Console provides more details about failure causes. Before deleting a stack, you should consider how the stack was created. If you created the stack using an AMS CT and did not add or edit the stack resources, then you can expect to delete it without issue. However, it is a good idea for you remove any manually-added resources from a stack before submitting a delete stack RFC against it. For example, if you create a stack using the full stack CT (HA Two Tier), it includes a security group - SG1. If you then use AMS to create another security group - SG2, and reference the new SG2 in the SG1 created as part of the full stack, and then use the delete stack CT to delete the stack, the SG1 will not delete as it is referenced by SG2. **Important** Deleting stacks can have unwanted and unanticipated consequences. AMS prefers to \$1not\$1 delete stacks or stack resources on behalf of customers for this reason. Note, that AMS will only delete resources on your behalf (through a submitted Mangement \$1 Other \$1 Other \$1 Update change type) that are not possible to delete using the appropriate, automated, change type to delete. Additional considerations: If the resources are enabled for 'delete protection', AMS can help to unblock this if you submit a Management \$1 Other \$1 Other \$1 Update change type and, after the deletion protection is removed, you can use the automated CT to delete that resource. If there are multiple resources in a stack, and you want to delete only a subset of the stack resources, use the CloudFormation Update change type (see [CloudFormation Ingest Stack: Updating](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-cfn-ingest-update-col.html)). You can also submit a Management \$1 Other \$1 Other \$1 Update change type and AMS engineers can help you craft the changeset, if needed. If there are issues using the CloudFormation Update CT due to drifts, AMS can help if you submit a Management \$1 Other \$1 Other \$1 Update to resolve the drift (as far as supported by the AWS CloudFormation Service) and provide a ChangeSet that you can then validate and execute using the automated CT, Management/Custom Stack/Stack From CloudFormation Template/Approve Changeset and Update. AMS maintains the above restrictions to help ensure there are no unexpected or unanticipated resource deletions. For more information, see [ Troubleshooting AWS CloudFormation: delete stack fails](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-delete-stack-fails). ### RFC update DNS errors Multiple RFCs to update a DNS hosted zone can fail, some without reason. Creating multiple RFCs at the same time to update DNS hosted zones (private or public) can cause some RFCs to fail because they are trying to update the same stack at the same time. AMS change management rejects or fails RFCs that are not able to update a stack because the stack is already being updated by another RFC. AMS recommends that you create one RFC at a time and wait for the RFC to succeed before raising a new one for the same stack. ### RFC IAM entities errors AMS provisions a number of default IAM roles and profiles into AMS accounts that are designed to meet your needs. However, you may need to request additional IAM resources occasionally. The process for submitting RFCs requesting custom IAM resources follows the standard workflow for manual RFCs, but the approval process also includes a security review to ensure appropriate security controls are in place. Therefore, the process typically takes longer than other manual RFCs. To reduce the cycle time on these RFCs, please follow the following guidelines. For information on what we mean by an IAM review and how it maps to our Technical Standards and Risk Acceptance process, see [Understand RFC security reviews](rfc-security.md). Common IAM resources requests: + If you are asking for a policy pertaining to a major cloud-compatible application, such as CloudEndure, see the AMS pre-approved IAM CloudEndure policy: Unpack the [WIGs Cloud Endure Landing Zone Example](samples/wigs-ce-lz-examples.zip) file and open the `customer_cloud_endure_policy.json` **Note** If you want a more permissive policy, discuss your needs with your CloudArchitect/CSDM and obtain, if needed, an AMS Security Review and Signoff before submitting an RFC implementing the policy. + If you want to modify a resource deployed by AMS in your account by default, we recommend that you ask for a modified copy of that resource instead of changes to the existing one. + If you are requesting permissions for a human user (instead of attaching the permissions to the user) attach the permissions to a role, and then grant the user permission to assume that role. For details on doing this, see [Temporary AMS Advanced console access](https://docs.aws.amazon.com/managedservices/latest/userguide/access-console-temp.html). + If you require exceptional permissions for a temporary migration or workflow, provide an end date for those permissions in your request. + If you’ve already discussed the subject of your request with your security team, provide evidence of their approval to your CSDM with as much detail as possible. If AMS rejects an IAM RFC we provide a clear reason for the rejection. For example, we might reject an IAM policy create request and explain what about the policy is inappropriate. In that case, you can make the identified changes and resubmit the request. If additional clarity on the status of a request is required, submit a service request, or contact your CSDM. The following list describes the typical risks that AMS tries to mitigate as we review your IAM RFCs. If your IAM RFC has any of these risks, it may result in the rejection of the RFC. In cases where you require an exception, AMS asks for approvals from your security team. To seek such an exception, coordinate with your CSDM. **Note** AMS may, for any reason, decline any change to IAM resources inside of an account. For concerns regarding any RFC rejection, reach out to AMS Operations via a service request, or contact your CSDM. + Privilege escalation, such as permissions that allow you to modify your own permissions, or to modify the permissions of other resources inside the account. Examples: + The use of `iam:PassRole` with another, more privileged role. + Permission to attach/detach IAM policies from a role or user. + The modification of IAM policies in the account. + The ability to make API calls in the context of management infrastructure. + Permissions to modify resources or applications that are required to provide AMS services to you. Examples: + Modification of AMS infrastructure like the bastions, management host, or EPS infrastructure. + Deletion of log management AWS Lambda functions, or log streams. + The deletion or modification of the default CloudTrail monitoring application. + The modification of the Directory Services Active Directory (AD). + Disabling CloudWatch (CW) alarms. + The modification of the principals, policies, and namespaces deployed in the account as a part of the landing zone. + Deployment of infrastructure outside of best practices, such as permissions that allow the creation of infrastructure in a state that endangers your information security. Examples: + The creation of public, or unencrypted, S3 buckets or public sharing of EBS volumes. + The provisioning of public IP addresses. + The modification of security groups to allow broad access. + Overly broad permissions capable of causing application impact, such as permissions that can result in data loss, integrity loss, inappropriate configuration, or interruptions of service for your infrastructure and the applications inside the account. Examples: + Disabling, or redirecting, network traffic through APIs like `ModifyNetworkInterfaceAttribute` or `UpdateRouteTable`. + The disabling of managed infrastructure by detaching volumes from managed hosts. + Permissions for services not a part of the AMS service description and not supported by AMS. Services not listed in the AMS Service description cannot be used in AMS accounts. To request support for a feature or service, please reach out to your CSDM. + Permissions that do not meet your stated goal as they are either too generous, or too conservative, or are applied to the wrong resources. Examples: + A request for `s3:PutObject` permissions to an S3 bucket that has mandatory KMS encryption, without `KMS:Encrypt` permissions to the relevant key. + Permissions that pertain to resources that don’t exist in the account. + IAM RFCs where the description of the RFC does not seem to match the request. ## "Deployment" RFC errors AMS "Deployment" Category change types (CTs) allow you to request various AMS-supported resources be added to your account. Most AMS CTs that create a resource are based on CloudFormation templates. As a customer you have read-only access to all AWS services including CloudFormation, you can quickly identify the CloudFormation stack that represents your stack based on the stack description using the CloudFormation Console. The failed stack will likely be in a state of DELETE\$1COMPLETE. Once you have identified the CloudFormation stack, the events will show you the specific resource that failed to create, and why. ### Using CloudFormation documentation to troubleshoot Most AMS provisioning RFCs use a CloudFormation template and that documentation can be helpful for troubleshooting. See documentation for that CloudFormation template: + Create application load balancer failure: [ AWS::ElasticLoadBalancingV2::LoadBalancer (Application Load Balancer)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticloadbalancingv2-loadbalancer.html) + Create Auto scaling group: [ AWS::AutoScaling::AutoScalingGroup (Auto Scaling Group)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-group.html) + Create memcached cache: [ AWS::ElastiCache::CacheCluster (Cache Cluster)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-elasticache-cache-cluster.html) + Create Redis cache: [ AWS::ElastiCache::CacheCluster (Cache Cluster)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-elasticache-cache-cluster.html) + Create DNS Hosted Zone (used with Create DNS private/public): [ AWS::Route53::HostedZone (R53 Hosted Zone)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-route53-hostedzone.html) + Create DNS Record Set (used with Create DNS private/public): [ AWS::Route53::RecordSet (Resource Record Sets)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-route53-recordset.html) + Create EC2 stack: [ AWS::EC2::Instance (Elastic Compute Cloud)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html) + Create Elastic File System (EFS): [ AWS::EFS::FileSystem (Elastic File System)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-efs-filesystem.html) + Create Load balancer: [ AWS::ElasticLoadBalancing::LoadBalancer (Elastic Load Balancer)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-elb.html) + Create RDS DB: [ AWS::RDS::DBInstance (Relational Database)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-rds-database-instance.html) + Create Amazon S3: [ AWS::S3::Bucket (Simple Storage Service)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket.html) + Create Queue: [ AWS::SQS::Queue (Simple Queue Service)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-sqs-queues.html) ### RFC creating AMIs errors An Amazon Machine Image (AMI) is a template that contains a software configuration (for example, an operating system, an application server, and applications). From an AMI, you launch an instance, which is a copy of the AMI running as a virtual server in the cloud. AMIs are very useful, and required to create EC2 instances or Auto Scaling groups; however, you must observe some requirements: + The instance you specify for `Ec2InstanceId` must be in a stopped state for the RFC to succeed. Do not use Auto Scaling group (ASG) instances for this parameter because the ASG will terminate a stopped instance. + To create an AMS Amazon Machine Image (AMI), you must start with an AMS instance. Before you can use the instance to create the AMI, you must prepare it by ensuring that it is stopped and dis-joined from its domain. For details, see [ Create a Standard Amazon Machine Image Using Sysprep](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/Creating_EBSbacked_WinAMI.html#23ami-create-standard) + The name you specify for the new AMI must be unique within the account or the RFC fails. How to do this is described in [AMI \$1 Create](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ami-create.html), and for more details, see and [AWS AMI Design](https://aws.amazon.com/answers/configuration-management/aws-ami-design/). **Note** For additional information for prepping for AMI creation, see [AMI \$1 Create](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ami-create.html). ### RFCs creating EC2s or ASGs errors For EC2 or ASG failures with timeouts, AMS recommends that you confirm if the AMI used is customized. If it is, please refer to the AMI creation steps included in this guide (see [AMI \$1 Create](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ami-create.html)) to ensure that the AMI was created correctly. A common mistake when creating a custom AMI is not following the steps in the guide to rename or invoke Sysprep. ### RFCs creating RDS errors Amazon Relational Database Service (RDS) failures can occur for many different reasons because you can use many different engines when you create the RDS, and each engine has its own requirements and limitations. Before attempting to create an AMS RDS stack, carefully review AWS RDS parameter values, see [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html). To learn more about Amazon RDS in general, including size recommendations, see [Amazon Relational Database Service Documentation](https://aws.amazon.com/documentation/rds/). ### RFCs creating Amazon S3s errors One common error when creating an S3 storage bucket is not using a unique name for the bucket. If you submitted an S3 bucket Create CT with the same name as one previously submitted, it would fail because an S3 bucket would already exist with that BucketName. This would be detailed in the CloudFormation Console, where you will see that the stack event shows that the bucket name is already in use. ## RFC validation versus execution errors RFC failures and related messages differ in the output messages on the AMS console RFC details page for a selected RFC: + Validation Failures reasons are available in Status Field only + Execution Failures reasons are available in Execution Output as well as Status Fields. ![\[Request for change details showing rejected status due to no domain trust found.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/rfcReason.png) ## RFC error messages When you come across the following error for the listed change types (CTs), you can use these solutions to help you find the source of the problems and fix them. `{"errorMessage":"An error has occurred during RFC execution. We are investigating the issue.","errorType":"InternalError"}` If you require further assistance after referring to the following troubleshooting options, then engage AMS through RFC correspondence. For more information, see [RFC Correspondence and Attachment (Console)](https://docs.aws.amazon.com/managedservices/latest/userguide/ex-rfc-gui.html#ex-rfc-correspondence). ### Workload ingestion (WIGS) errors **Note** Validation tools for both Windows and Linux can be downloaded and run directly on your on-premises servers, as well as EC2 instances in AWS. These can be found through the *AMS Advanced Application Developer's Guide* [Migrating workloads: Linux pre-ingestion validation](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-migrate-instance-linux-validation.html) and [Migrating workloads: Windows pre-ingestion validation](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-migrate-instance-win-validation.html). + Make sure EC2 instance exists in target AMS account. For example, if you have shared your AMI from a non-AMS account to an AMS account, you'll have to create an EC2 instance in your AMS account with the shared AMI before you can submit a Workload Ingest RFC. + Check to see if the security groups attached to the instance have egress traffic allowed. The SSM Agent needs to be able to connect to its public endpoint. + Check to see if the instance has the right permissions to connect with the SSM agent. These permissions come with the `customer-mc-ec2-instance-profile`, you can check for this in the EC2 console: ![\[EC2 instance details showing IAM role set to customer-mc-ec2-instance-profile.\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/images/ec2ConsoleWCircle.png) ### EC2 instance stack stop errors + Check to see if the instance is already in a stopped or terminated state. + If the EC2 instance is online and you see the `InternalError` error, then submit a service request for AMS to investigate. + Note that you can't use the change type Management \$1 Advanced stack components \$1 EC2 instance stack \$1 Stop ct-3mvvt2zkyveqj to stop an Auto Scaling group (ASG) instance. If you need to stop an ASG instance, then submit a service request. ### EC2 instance stack create errors The `InternalError` message is from CloudFormation; a CREATION\$1FAILED status reason. You can find details on the stack failure in CloudWatch stack events by following these steps: + In the AWS Management console, you can view a list of stack events while your stack is being created, updated, or deleted. From this list, find the failure event and then view the status reason for that event. The status reason might contain an error message from AWS CloudFormation or from a particular service that can help you understand the problem. + For more information about viewing stack events, see [ Viewing AWS CloudFormation Stack Data and Resources on the AWS Management Console](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html). ### EC2 instance volume restore errors AMS creates an internal troubleshooting RFC when EC2 instance volume restore fails. This is done because EC2 instance volume restore is an important part of disaster recovery (DR) and AMS creates this internal troubleshooting RFC for you automatically. When the internal troubleshooting RFC is created, a banner is displayed providing you with links to the RFC. This internal troubleshooting RFC provides your with more visibility into RFC failures and, rather than submitting retry RFCs leading to the same errors, or making you manually reach out to AMS for this failure, you can keep track of your changes and know that the failure is being worked on by AMS. This also reduces the time-to-recovery (TTR) metric for their change as AMS Operators proactively work on the RFC failure instead of waiting for your request. ## How to get help with an RFC You can reach out to AMS to identify the root cause of your failure. AMS business hours are 24 hours a day, 7 days a week, 365 days a year. AMS provides several avenues for you to ask for help. + If you require assistance with an open RFC or an RFC which is completed but was incorrect, engage AMS through RFC bi-directional correspondence. For more information, see [RFC Correspondence and Attachment (Console)](https://docs.aws.amazon.com/managedservices/latest/userguide/ex-rfc-gui.html#ex-rfc-correspondence). + To report an AWS or AMS service performance issue that impacts your managed environment, use the AMS console and submit an incident report. For details, see [Reporting an Incident](https://docs.aws.amazon.com/managedservices/latest/userguide/gui-ex-report-incident.html). For general information about AMS incident management, see [Incident response](https://docs.aws.amazon.com/managedservices/latest/userguide/sec-incident-response.html). + For specific questions about how you or your resources or applications are working with AMS, or to escalate an incident, email one or more of the following: 1. First, if you are unsatisfied with the service request or incident report response, email your CSDM: ams-csdm@amazon.com 1. Next, if escalation is required, you can email the AMS Operations Manager (but your CSDM will probably do this): ams-opsmanager@amazon.com 1. Further escalation would be to the AMS Director: ams-director@amazon.com 1. Finally, you are always able to reach the AMS VP: ams-vp@amazon.com