This blog is about AWS re:Invent 2022's exciting Storage related updates and Announcements regarding EFS, S3, Failover Controls, and AWS Backup.
Amazon EFS Elastic Throughput
"Use this mode for workloads with unpredictable I/O. With Elastic mode, your throughput scales automatically and you only pay for what you use".
Amazon EFS (Elastic File System) is a service that provides fully elastic and serverless file storage. While creating Amazon EFS (Elastic File System), a New performance Setting is been introduced in Throughput Mode as Amazon EFS Elastic Throughput Mode.
It is a new pay-as-you-use throughput mode for Amazon EFS that provides applications with as much throughput as they need. This mode is designed for dynamic and unpredictable workloads with difficult-to-forecast performance requirements. When enabled, Elastic Throughput actively manages file system performance and prevents over-payment for idle resources, ensuring optimal performance for applications.
Enabling Elastic Throughput eliminates the need to specify or provision throughput capacity, as Amazon EFS automatically delivers the required throughput performance. Customers only pay for the amount of data read or written.
With Elastic Throughput, Amazon EFS simplifies and extends its performance capabilities, allowing customers to use it for a wider range of file workloads. Amazon EFS is well suited for a variety of use cases, such as analytics, data science, machine learning, CI/CD tools, content management, web serving, and SaaS applications. Amazon EFS Elastic Throughput is available in all regions except for the AWS China regions.
Failover Controls for Amazon S3 Multi-Region Access Points
Amazon S3 Multi-Region Access Points provide a global endpoint for accessing S3 buckets in multiple AWS regions. This feature allows for the creation of multi-region applications using the same simple architecture as in a single region.
The Multi-Region Access Point uses AWS Global Accelerator to monitor network congestion and connectivity and routes traffic to the closest copy of the data.
If connectivity is lost between a client and a bucket in a particular region, the Multi-Region Access Point will automatically route traffic to the closest bucket (synchronized via S3 Replication) in another region.
Failover controls for Multi-Region Access Points allow users to shift S3 data access request traffic routed through a Multi-Region Access Point to an alternate AWS region within minutes. This allows users to test and build highly available applications for business continuity.
The existing Multi-Region Access Point model treats all regions as active and can send traffic to any of them. The new model introduced at AWS re:Invent allows users to designate regions as either active or passive. Buckets in active regions receive traffic (GET, PUT, and other requests) from the Multi-Region Access Point, while buckets in passive regions do not. Amazon S3 Cross-Region Replication operates regardless of the active or passive status of a region concerning a particular Multi-Region Access Point.
Amazon S3 > Multi-Region Access Points > Create Multi-Region Access Point
"By default, my new Multi-Region Access Point routes traffic to all of the buckets, and behaves as it did before we launched this new feature. However, I can now exercise control over routing and failover. I click on the Multi-Region Access Point, and on the Replication and failover tab (which used to be just a Replication tab). The map now allows me to see my replication rules and my failover status:" (Source from Author: Jeff Barr )
The tab for failover configuration (NEW): (source from Author: Jeff Barr )
"To change my failover configuration, I select the buckets of interest and click Edit failover configuration. My application runs in the Asia Pacific (Tokyo) Region and makes use of a bucket there, so I leave the Tokyo Region active and make the others passive:" (Source from Author: Jeff Barr )
New for AWS Backup – Protect and Restore Your CloudFormation Stacks
AWS Backup is a service offered by Amazon Web Services (AWS) that provides automated backups for AWS resources. The new feature allows users to protect and restore their CloudFormation stacks using AWS Backup.
CloudFormation is a service that allows users to create and manage infrastructure as code, and the ability to protect and restore these stacks using AWS Backup provides added security and resilience for users of the service.
When you use AWS Backup to protect your CloudFormation stacks, it creates a backup of all the stateful resources in the stack, such as Amazon Elastic Compute Cloud (Amazon EC2) instances and Amazon Elastic Block Store (Amazon EBS) volumes, at the same time. The backup also includes the stateless resources in the stack, such as IAM roles and Amazon VPC security groups, allowing you to restore the entire stack to its previous state if necessary.
Above Images source from here.
There is no additional cost for the stateless resources backed up and restored by AWS Backup. You only pay for the stateful resources such as databases, storage volumes, or file systems. For more information, see AWS Backup pricing.
Amazon Redshift Supported in AWS Backup
Amazon Redshift is a fully managed, cloud-based data warehousing service offered by AWS. AWS Backup allows users to automate the process of creating backups of their Amazon Redshift clusters, and provides options for scheduling these backups and setting retention policies.
AWS Backup > Settings > Configure Resources > Redshift - new
There is no additional cost for using AWS Backup compared to the native snapshot capability of Amazon Redshift. Overall costs depend on the amount of storage and retention you choose. For more information, see AWS Backup pricing.
Automated in-AWS Failback for AWS Elastic Disaster Recovery
Automated in-AWS failback for AWS Elastic Disaster Recovery (AWS EDR) is a feature that allows users to automatically fail back to their original primary AWS Region after a disaster recovery event. When a disaster occurs, AWS EDR automatically fails over to a specified secondary AWS Region to keep applications running. After the disaster has been resolved and the original primary AWS Region is available again, the automated in-AWS failback feature automatically fails back to the primary AWS Region, allowing users to resume normal operation in their primary environment. This helps to simplify the disaster recovery process and reduce downtime for applications.
AWS Elastic Disaster Recovery (AWS EDR) is a service that helps users to protect their applications and data from disasters by maintaining a constant replication posture for their operating systems, applications, and databases.
AWS EDR automatically fails over to a specified secondary AWS Region in the event of a disaster, allowing users to keep their applications running. The service now supports in-AWS failback, which allows users to automatically fail back to their primary AWS Region after the disaster has been resolved, as well as existing support for non-disruptive recovery drills and on-premises failback. This helps users to simplify the disaster recovery process and reduce downtime for their applications.
Failover vs. Failback
Failover is switching the running application to another AZ or Region.
Failback is the process of returning the application to the original AZ or Region.
Three Strages : 1. Preparation 2. Failover 3. Failback 4. Cleanup
Let’s assume an incident occurs with an in-AWS application, so we initiate a failover to another AWS Region. When the issue has been resolved, we want to fail back to the original Region. The following animation illustrates the failover and failback processes. Source here.
Learn more about in-AWS failback with Elastic Disaster Recovery here.
Those are Top Announcement regarding Storage in re:Invent this year(2022)
There are tons more announcements and exciting features announce throughout the year but mainly during re:invent. To keep up to date with AWS news, follow AWS News Blog.
Thank you for the read. Hope you like it.
I appreciate your time.
Follow for more Azure and AWS Content. Happy Learning!
Regards,
Jineshkumar Patel