AWS Feed
How to confirm your automated Amazon EBS snapshots are still created after the TLS 1.2 uplift on AWS FIPS endpoints
We are happy to announce that all AWS Federal Information Processing Standard (FIPS) endpoints have been updated to only accept a minimum of Transport Layer Security (TLS) 1.2 connections. This ensures that our customers who run regulated workloads can meet FedRAMP compliance requirements that mandate a minimum of TLS 1.2 encryption for data in transit. Attempts to connect to AWS FIPS endpoints using TLS 1.0 or TLS 1.1 will result in an HTTP response 503 Service Unavailable error. Over the past year, AWS shared information about this change, such as this March 1, 2021 Security Blog post, and messages on the AWS Personal Health Dashboard.
If you are using a script to automate creation of Amazon Elastic Block Store (EBS) snapshots, such as the AWS CLI or the AWS Tools for Windows PowerShell, please confirm that your most recent snapshots have been successfully created. This is especially important in the AWS GovCloud (US) Regions, where some AWS services continued to detect customers using the outdated TLS versions at the time of the TLS 1.2 policy update.
Why do I need to check my EBS Snapshots?
During the TLS policy update, we detected customer client applications that were attempting TLS 1.0 Application Programming Interface (API) calls that are commonly associated with automated EBS backup and snapshot handling applications. The detected API calls occurred for the EC2 FIPS endpoint in AWS GovCloud (US-West), ec2.us-gov-west-1.amazonaws.com, and were EC2:DescribeInstances, EC2:DescribeSnapshots, EC2:DeleteSnapshot, EC2:DescribeVolumes, and EC2:CreateSnapshot.
How can I confirm that my Amazon EBS snapshots are still being created?
To view snapshot information within the console or the command line, follow the steps described in View Amazon EBS snapshot information. You can use the console or the command line options to provide you with a list of all snapshots that are available within the account.
Take particular note of the Started value in the console, or the start-time value if using CLI, and if you see that your snapshots have not been created after April 1, 2021, then you may have an automation script that is unsuccessfully attempting to connect on a version of TLS below 1.2.
To remediate this issue, you can do one of the following:
- Update your automation to use TLS 1.2, which will restore connectivity to the FIPS endpoint. Customers using an AWS Software Development Kit (AWS SDK) or the AWS Command Line Interface (CLI) can find information about how to properly configure their client’s minimum and maximum TLS versions using the links provided in our March 31, 2020 Security Blog post.
- Use Amazon Data Lifecycle Manager to automate the creation, retention, and deletion of EBS snapshots.
- If you need to backup EBS volumes and other AWS services, you can use AWS Backup to centrally manage your backup policies.
How do I know if my API calls to other AWS services were impacted?
All customers whom AWS detected using outdated TLS versions to connect to FIPS endpoints were notified on their AWS Personal Health Dashboard and by email.
However, if you were connecting anonymously to an AWS shared resource, such as through a public Amazon Simple Storage Service (Amazon S3) bucket, then you did not receive a notification, because AWS cannot identify anonymous connections. Log in to your console and check for any Personal Health Dashboard notices, especially in AWS GovCloud (US) Regions. These notices contain useful data, such as the API call or other information to help you to identify whether you have possible failed AWS workflows. You can use AWS Health to receive alerts for when you have new Personal Health Dashboard notices.
Are there other things I should check?
If you believe that outdated TLS connections are causing your application’s connections to AWS FIPS endpoints to fail, please check your application logs for HTTP 503 Service Unavailable.
To detect connections that use outdated versions of TLS, you can perform a packet capture by using a tool such as Wireshark. Follow the instructions in the section EXAMPLE: TLS version detection using a packet capture in this previous AWS Security Blog post. Figure 1 is an example of a packet capture using Wireshark, showing that the client application only supports TLS 1.0 and must be modified to support a TLS 1.2 connection.
Figure 1: Wireshark packet capture showing that the client application only supports TLS 1.0
If you determine that your connections to AWS Systems Manager are failing, please install the latest version of the SSM Agent. For instructions, see the AWS Systems Manager User Guide topics Install SSM Agent for a hybrid environment (Linux) or Install SSM Agent for a hybrid environment (Windows).
You can also see the instructions to install the latest version of EC2Config (for Windows only) in the Amazon EC2 User Guide for Windows Instances.
If your connections to Amazon CloudWatch or Amazon CloudWatch Logs are failing, follow the instructions for installing the CloudWatch Agent, including instructions to download and configure the CloudWatch Agent using the command line.
Is there more assistance available?
If you have any questions or issues, you can start a new thread on one of the AWS forums, or contact AWS Support or your Technical Account Manager (TAM). The AWS support tiers cover development and production issues for AWS products and services, along with other key stack components. AWS Support doesn’t include code development for client applications.
If you have feedback about this post, submit comments in the Comments section below.