# 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 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 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 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 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 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 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 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 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 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 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 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)