Today, Amazon EBS announced a new latency injection action in AWS Fault Injection Service (FIS), a fully managed service for running fault injection experiments. You can now use this action to inject I/O latency on your volumes as part of a controlled testing experiment to understand how your mission-critical applications respond to storage faults. With the new fault action, you can test your architecture against elevated storage latency, allowing you to observe application behavior and fine-tune your monitoring and recovery processes to ensure high availability. EBS volumes are designed to meet the needs of highly available, latency-sensitive applications such as Oracle, SAP HANA, and Microsoft SQL Server. The latency injection action simulates degraded I/O performance on your volume to replicate the real-world signals, such as Amazon CloudWatch alarms and operating system timeouts, that occur during storage performance issues. Using this action, you can build confidence that your application can withstand and quickly recover from disruptions that cause high I/O latency on your EBS volume. To get started, you can directly use the pre-defined latency injection experiment templates available in the EBS and FIS consoles. Alternatively, you can customize these experiment templates or create your own experiment templates to meet your application-specific testing needs. You can integrate these latency injection experiments into your existing chaos engineering tests, continuous integration, and release testing, as well as combine multiple FIS actions in one experiment. This new action is available in all https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ where AWS FIS is available. To learn more, visit the https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fis.html.

Today, Amazon EBS announced a new latency injection action in AWS Fault Injection Service (FIS), a fully managed service for running fault injection experiments. You can now use this action to inject I/O latency on your volumes as part of a controlled testing experiment to understand how your mission-critical applications respond to storage faults. With the new fault action, you can test your architecture against elevated storage latency, allowing you to observe application behavior and fine-tune your monitoring and recovery processes to ensure high availability. EBS volumes are designed to meet the needs of highly available, latency-sensitive applications such as Oracle, SAP HANA, and Microsoft SQL Server. The latency injection action simulates degraded I/O performance on your volume to replicate the real-world signals, such as Amazon CloudWatch alarms and operating system timeouts, that occur during storage performance issues. Using this action, you can build confidence that your application can withstand and quickly recover from disruptions that cause high I/O latency on your EBS volume. To get started, you can directly use the pre-defined latency injection experiment templates available in the EBS and FIS consoles. Alternatively, you can customize these experiment templates or create your own experiment templates to meet your application-specific testing needs. You can integrate these latency injection experiments into your existing chaos engineering tests, continuous integration, and release testing, as well as combine multiple FIS actions in one experiment. This new action is available in all AWS Regions where AWS FIS is available. To learn more, visit the EBS FIS actions user guide.

Amazon Data Lifecycle Manager now offers customers the option to use Internet Protocol version 6 (IPv6) addresses for their new and existing endpoints. Customers moving to IPv6 can simplify their networks stack by running their Data Lifecycle Manager dual-stack endpoints on a network supporting both IPv4 and IPv6, depending on the protocol used by their network and client. Customers create Amazon Data Lifecycle Manager policies to automate the creation, retention, and management of EBS Snapshots and EBS-backed Amazon Machine Images (AMIs). The policies can also automatically copy created resources across AWS Regions, move EBS Snapshots to EBS Snapshots Archive tier, and manage Fast Snapshot Restore. Customers can also create policies to automate creation and retention of application-consistent EBS Snapshots via pre and post-scripts, as well as create Default Policies for comprehensive protection for their account or AWS Organization. Amazon Data Lifecycle Manager with IPv6, supported in all AWS Commercial Regions, is now available in the AWS GovCloud (US) Regions. To learn more about configuring Amazon Data Lifecycle Manager endpoints for IPv6, please refer to our https://docs.aws.amazon.com/ebs/latest/userguide/dlm-service-endpoints.html.  

Amazon Data Lifecycle Manager now offers customers the option to use Internet Protocol version 6 (IPv6) addresses for their new and existing endpoints. Customers moving to IPv6 can simplify their networks stack by running their Data Lifecycle Manager dual-stack endpoints on a network supporting both IPv4 and IPv6, depending on the protocol used by their network and client. Customers create Amazon Data Lifecycle Manager policies to automate the creation, retention, and management of EBS Snapshots and EBS-backed Amazon Machine Images (AMIs). The policies can also automatically copy created resources across AWS Regions, move EBS Snapshots to EBS Snapshots Archive tier, and manage Fast Snapshot Restore. Customers can also create policies to automate creation and retention of application-consistent EBS Snapshots via pre and post-scripts, as well as create Default Policies for comprehensive protection for their account or AWS Organization. Amazon Data Lifecycle Manager with IPv6, supported in all AWS Commercial Regions, is now available in the AWS GovCloud (US) Regions. To learn more about configuring Amazon Data Lifecycle Manager endpoints for IPv6, please refer to our documentation.

Amazon Elastic Block Store (Amazon EBS) now supports additional resource-level permissions for https://docs.aws.amazon.com/ebs/latest/userguide/ebs-copy-snapshot.html. When moving your data across Regions, accounts, and Availability Zones, you can copy any snapshot accessible to you to another Region or account, including snapshots created by you or shared with you. With this launch, you have more granular controls to set resource-level permissions for the snapshot copy and selection of the source snapshot. This allows you to control the IAM identities that can copy EBS snapshot from source snapshots, and the conditions that they can use these source snapshots for the snapshot copy operation. To meet your specific permission needs on the source snapshots, you can also specify any of 6 EC2-specific condition keys for your https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html action in your IAM policy: ec2:Encrypted, ec2:VolumeSize, ec2:Owner, ec2:ParentVolume, ec2:SnapshotTime, and ec2:ParentSnapshot. Additionally, you can use https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html for the source snapshot. This new resource-level permission model is available in all AWS Regions where EBS snapshots are available. To learn more about using resource-level permissions to copy EBS snapshot, or transitioning to the new resource-level permission model from previous permission model, please visit the https://aws.amazon.com/blogs/storage/enhancing-resource-level-permissions-for-copying-amazon-ebs-snapshots/. For more information about Amazon EBS, please visit the https://aws.amazon.com/ebs/.

Amazon Elastic Block Store (Amazon EBS) now supports additional resource-level permissions for copying EBS snapshots. When moving your data across Regions, accounts, and Availability Zones, you can copy any snapshot accessible to you to another Region or account, including snapshots created by you or shared with you. With this launch, you have more granular controls to set resource-level permissions for the snapshot copy and selection of the source snapshot. This allows you to control the IAM identities that can copy EBS snapshot from source snapshots, and the conditions that they can use these source snapshots for the snapshot copy operation. To meet your specific permission needs on the source snapshots, you can also specify any of 6 EC2-specific condition keys for your CopySnapshot action in your IAM policy: ec2:Encrypted, ec2:VolumeSize, ec2:Owner, ec2:ParentVolume, ec2:SnapshotTime, and ec2:ParentSnapshot. Additionally, you can use global condition keys for the source snapshot. This new resource-level permission model is available in all AWS Regions where EBS snapshots are available. To learn more about using resource-level permissions to copy EBS snapshot, or transitioning to the new resource-level permission model from previous permission model, please visit the launch blog. For more information about Amazon EBS, please visit the product page.

Amazon EC2 now supports automated recovery of Microsoft SQL Server databases from Volume Shadow Copy Services (VSS) based EBS snapshots. Customers can use an AWS Systems Manager Automation Runbook and specify a restore point of time to automate the recovery process without needing to stop a running Microsoft SQL Server database. Volume Shadow Copy Services (VSS) allows application data to be backed up while applications are still running. This new feature allows customers to automate the recovery from VSS-based EBS snapshots and ensure rapid recovery of large databases within minutes. This feature also offers customers the flexibility to restore to a new database or achieve point-in-time recovery. This feature is available in all commercial AWS Regions and the AWS GovCloud (US) Regions. To learn more, visit this https://docs.aws.amazon.com/sql-server-ec2/latest/userguide/ms-ssdb-ec2-restore-vss.html in the Microsoft SQL Server on Amazon EC2 User Guide.

Amazon EC2 now supports automated recovery of Microsoft SQL Server databases from Volume Shadow Copy Services (VSS) based EBS snapshots. Customers can use an AWS Systems Manager Automation Runbook and specify a restore point of time to automate the recovery process without needing to stop a running Microsoft SQL Server database. Volume Shadow Copy Services (VSS) allows application data to be backed up while applications are still running. This new feature allows customers to automate the recovery from VSS-based EBS snapshots and ensure rapid recovery of large databases within minutes. This feature also offers customers the flexibility to restore to a new database or achieve point-in-time recovery. This feature is available in all commercial AWS Regions and the AWS GovCloud (US) Regions. To learn more, visit this technical document in the Microsoft SQL Server on Amazon EC2 User Guide.

Today, AWS announces Internet Protocol version 6 (IPv6) support for Recycle Bin, a data recovery feature that enables restoration of accidental deleted Amazon EBS Snapshots and EBS-backed AMIs. You now have the option of using IPv6 addresses for new and existing endpoints. By moving to IPv6, you can simplify your network stack by running dual-stack Recycle Bin endpoints on a network that supports both IPv4 and IPv6. Customers can create rules in Recycle Bin to retain deleted EBS Snapshots or deregistered EBS-backed AMI for a specific retention time. This capability allows you to immediately recover your deleted snapshots or EBS-backed AMIs when you create volumes or launch instance without a need to roll back to a snapshot or AMI from an earlier point in time. Recovered snapshots or AMIs retain attributes such as prior to deletion and can be used immediately for creating volumes or launching instances. Snapshots and AMIs that are not recovered from the Recycle Bin are permanently deleted upon expiration of the retention time. Recycle Bin with IPv6 and AWS PrivateLink is now available in all AWS Regions including the AWS GovCloud (US) Regions. To learn more about configuring Recycle Bin endpoints for IPv6, please refer to our https://docs.aws.amazon.com/ebs/latest/userguide/rbin-service-endpoints.html.  

Today, AWS announces Internet Protocol version 6 (IPv6) support for Recycle Bin, a data recovery feature that enables restoration of accidental deleted Amazon EBS Snapshots and EBS-backed AMIs. You now have the option of using IPv6 addresses for new and existing endpoints. By moving to IPv6, you can simplify your network stack by running dual-stack Recycle Bin endpoints on a network that supports both IPv4 and IPv6. Customers can create rules in Recycle Bin to retain deleted EBS Snapshots or deregistered EBS-backed AMI for a specific retention time. This capability allows you to immediately recover your deleted snapshots or EBS-backed AMIs when you create volumes or launch instance without a need to roll back to a snapshot or AMI from an earlier point in time. Recovered snapshots or AMIs retain attributes such as prior to deletion and can be used immediately for creating volumes or launching instances. Snapshots and AMIs that are not recovered from the Recycle Bin are permanently deleted upon expiration of the retention time. Recycle Bin with IPv6 and AWS PrivateLink is now available in all AWS Regions including the AWS GovCloud (US) Regions. To learn more about configuring Recycle Bin endpoints for IPv6, please refer to our documentation.

Today, Amazon announced the availability of detailed performance statistics for Amazon Elastic Block Store (EBS) volumes. This new capability provides you with real-time visibility into the performance of your EBS volumes, making it easier to monitor the health of your storage resources and take actions sooner. With detailed performance statistics, you can access 11 metrics at up to a per-second granularity to monitor input/output (I/O) statistics of your EBS volumes, including driven I/O and I/O latency histograms. The granular visibility provided by these metrics helps you quickly identify and proactively troubleshoot application performance bottlenecks that may be caused by factors such as reaching an EBS volume's provisioned IOPS or throughput limits, enabling you to enhance application performance and resiliency. Detailed performance statistics for EBS volumes are available by default for all EBS volumes attached to a Nitro-based EC2 instance in all AWS Commercial, China, and the AWS GovCloud (US) Regions, at no additional charge. To get started with EBS detailed performance statistics, please visit the documentation https://docs.aws.amazon.com/ebs/latest/userguide/nvme-detailed-performance-stats.html to learn more about the available metrics and how to access them using NVMe-CLI tools.

Today, Amazon announced the availability of detailed performance statistics for Amazon Elastic Block Store (EBS) volumes. This new capability provides you with real-time visibility into the performance of your EBS volumes, making it easier to monitor the health of your storage resources and take actions sooner. With detailed performance statistics, you can access 11 metrics at up to a per-second granularity to monitor input/output (I/O) statistics of your EBS volumes, including driven I/O and I/O latency histograms. The granular visibility provided by these metrics helps you quickly identify and proactively troubleshoot application performance bottlenecks that may be caused by factors such as reaching an EBS volume's provisioned IOPS or throughput limits, enabling you to enhance application performance and resiliency. Detailed performance statistics for EBS volumes are available by default for all EBS volumes attached to a Nitro-based EC2 instance in all AWS Commercial, China, and the AWS GovCloud (US) Regions, at no additional charge. To get started with EBS detailed performance statistics, please visit the documentation here to learn more about the available metrics and how to access them using NVMe-CLI tools.