New – Failover Controls for Amazon S3 Multi-Region Access Points

{"value":"We launched [Amazon S3 Multi-Region Access Points](https://aws.amazon.com/blogs/aws/s3-multi-region-access-points-accelerate-performance-availability/) to give you a global endpoint that spans S3 buckets in multiple Amazon Web Services Regions. With S3 Multi-Region Access Points, you can build multi-region applications with the same simple architecture used in a single Region. This cool and powerful feature uses [Amazon Web Services Global Accelerator](https://aws.amazon.com/global-accelerator/) to monitor network congestion and connectivity, and to route traffic to the closest copy of your data. In the event that connectivity between a client and a bucket in a particular Region is lost, the Multi-Region Access Point will automatically route all traffic to the closest bucket (synchronized via S3 Replication) in another Region.\n\nIn addition to the use case that I just described, customers have told us that they want to build highly available multi-region apps and need explicit control over failover and failback.\n\n**++New Failover Controls++**\nToday we are adding failover controls for Multi-Region Access Points. These controls let you shift S3 data access request traffic routed through an [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) Multi-Region Access Point to an alternate Amazon Web Services Region within minutes to test and build highly available applications for business continuity.\n\nThe existing Multi-Region Access Point model treats all of the Regions as active and can send traffic to any of them. The model that we are introducing today lets you designate Regions as either active or passive. Buckets in active Regions receive traffic (GET, PUT, and other requests) from the Multi-Region Access Point, buckets in passive Regions don’t. [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) Cross-Region Replication operates regardless of the active or passive status of a Region with respect to a particular Multi-Region Access Point.\n\nTo get started, I create a new Multi-Region Access Point that refers to two or more S3 buckets in distinct [Amazon Web Services Regions](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/). I enter a name for my Multi-Region Access Point (**jbarr-mrap-1**), and choose the buckets:\n\n\n\nI leave the [Amazon S3 Block Public Access](https://aws.amazon.com/s3/features/block-public-access/) settings as-is, and click **Create Multi-Region Access Point**:\n\n\n\nThen I wait until my Multi-Region Access Point is ready (generally just a few minutes):\n\n\n\nBy 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:\n\n\n\nI can scroll down to view, create, and modify my replication rules:\n\n\n\nAs you can see, the replication rules that I created for this demo preserve the storage class. [S3 Intelligent-Tiering](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/) is generally a better choice, since I would get automatic cost savings without increased data retrieval costs after a failover. I can use [S3 Replication metrics](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-metrics.html) to make sure that my replication rules are proceeding as expected. Also, [S3 Replication Time Control](https://aws.amazon.com/about-aws/whats-new/2019/11/amazon-s3-replication-time-control-for-predictable-replication-time-backed-by-sla/) provides a predictable replication time (backed by an SLA), and should also be considered.\n\nThe tab also includes the **failover configuration:**\n\n\n\nTo 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:\n\n\n\nAll is well until one fine day [Godzilla](https://en.wikipedia.org/wiki/Godzilla) wakes up and eats all of the submarine cables in and around Tokyo. I quickly pull up the console, return to the **Failover configuration**, select the active Tokyo Region and the passive Osaka Region, and click **Failover**:\n\n\n\nI confirm my intent, click **Failover** again, and the failover is complete within two minutes:\n\n\n\nLater, after Godzilla has been subdued and the cables have been repaired, I can fail back to the original bucket in the Tokyo Region:\n\n\n\n**++Things to Know++**\nHere are a couple of things to keep in mind as you start to make use of this important new Amazon Web Services feature:\n\n**Active/Passive** – There must be at least one active Region at all times.\n\n**CLI & API Access** – You can initiate a failover programmatically by calling```SubmitMultiRegionAccessPointRoutes```. You can retrieve the current set of routes by calling```GetMultiRegionAccessPointRoutes```. The endpoints for these APIs are available in the US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney, Tokyo), and Europe (Ireland) Regions.\n\n**Pricing** – There is no extra charge for this feature beyond the use of the new APIs, which are billed as standard S3 GET and PUT requests. For S3 Multi-Region Access Point usage prices, see the **Data transfer** tab of the[ Amazon S3 Pricing](https://aws.amazon.com/s3/pricing/) page.\n\n**Regions** – This feature is available in all Amazon Web Services Regions where Multi-Region Access Points are [currently available](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRestrictions.html).\n\n— [Jeff](https://twitter.com/jeffbarr);\n\n\n### [Jeff Barr](https://aws.amazon.com/blogs/aws/author/jbarr/)\nJeff Barr is Chief Evangelist for Amazon Web Services. He started this blog in 2004 and has been writing posts just about non-stop ever since.","render":"<p>We launched <a href=\\"https://aws.amazon.com/blogs/aws/s3-multi-region-access-points-accelerate-performance-availability/\\" target=\\"_blank\\">Amazon S3 Multi-Region Access Points</a> to give you a global endpoint that spans S3 buckets in multiple Amazon Web Services Regions. With S3 Multi-Region Access Points, you can build multi-region applications with the same simple architecture used in a single Region. This cool and powerful feature uses <a href=\\"https://aws.amazon.com/global-accelerator/\\" target=\\"_blank\\">Amazon Web Services Global Accelerator</a> to monitor network congestion and connectivity, and to route traffic to the closest copy of your data. In the event that connectivity between a client and a bucket in a particular Region is lost, the Multi-Region Access Point will automatically route all traffic to the closest bucket (synchronized via S3 Replication) in another Region.</p>\\n<p>In addition to the use case that I just described, customers have told us that they want to build highly available multi-region apps and need explicit control over failover and failback.</p>\n<p><strong><ins>New Failover Controls</ins></strong><br />\\nToday we are adding failover controls for Multi-Region Access Points. These controls let you shift S3 data access request traffic routed through an Amazon S3 Multi-Region Access Point to an alternate Amazon Web Services Region within minutes to test and build highly available applications for business continuity.</p>\n<p>The existing Multi-Region Access Point model treats all of the Regions as active and can send traffic to any of them. The model that we are introducing today lets you designate Regions as either active or passive. Buckets in active Regions receive traffic (GET, PUT, and other requests) from the Multi-Region Access Point, buckets in passive Regions don’t. Amazon S3 Cross-Region Replication operates regardless of the active or passive status of a Region with respect to a particular Multi-Region Access Point.</p>\n<p>To get started, I create a new Multi-Region Access Point that refers to two or more S3 buckets in distinct <a href=\\"https://aws.amazon.com/about-aws/global-infrastructure/regions_az/\\" target=\\"_blank\\">Amazon Web Services Regions</a>. I enter a name for my Multi-Region Access Point (<strong>jbarr-mrap-1</strong>), and choose the buckets:</p>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/5f5a29b51fe942faae7fede87b8dd81b_image.png\\" alt=\\"image.png\\" /></p>\n<p>I leave the <a href=\\"https://aws.amazon.com/s3/features/block-public-access/\\" target=\\"_blank\\">Amazon S3 Block Public Access</a> settings as-is, and click <strong>Create Multi-Region Access Point</strong>:</p>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/23c22268b8274e4fbd9c645cb4f76524_image.png\\" alt=\\"image.png\\" /></p>\n<p>Then I wait until my Multi-Region Access Point is ready (generally just a few minutes):</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/096a185fa0f44c568bd82b54f39ed39f_image.png\\" alt=\\"image.png\\" /></p>\n<p>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 <strong>Replication and failover</strong> tab (which used to be just a <strong>Replication</strong> tab). The map now allows me to see my replication rules and my failover status:</p>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/d6429bc9a12c46cf9e5da4556696c05a_image.png\\" alt=\\"image.png\\" /></p>\n<p>I can scroll down to view, create, and modify my replication rules:</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/3c36acc0819d4dd7a1b63e8324750c78_image.png\\" alt=\\"image.png\\" /></p>\n<p>As you can see, the replication rules that I created for this demo preserve the storage class. <a href=\\"https://aws.amazon.com/s3/storage-classes/intelligent-tiering/\\" target=\\"_blank\\">S3 Intelligent-Tiering</a> is generally a better choice, since I would get automatic cost savings without increased data retrieval costs after a failover. I can use <a href=\\"https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-metrics.html\\" target=\\"_blank\\">S3 Replication metrics</a> to make sure that my replication rules are proceeding as expected. Also, <a href=\\"https://aws.amazon.com/about-aws/whats-new/2019/11/amazon-s3-replication-time-control-for-predictable-replication-time-backed-by-sla/\\" target=\\"_blank\\">S3 Replication Time Control</a> provides a predictable replication time (backed by an SLA), and should also be considered.</p>\\n<p>The tab also includes the <strong>failover configuration:</strong></p>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/265b47e1a57f4886a9795bdac0d28681_image.png\\" alt=\\"image.png\\" /></p>\n<p>To change my failover configuration, I select the buckets of interest and click <strong>Edit failover configuration</strong>. 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:</p>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/8c2cdeb56d704cff9bc3f74ad1e9b2ac_image.png\\" alt=\\"image.png\\" /></p>\n<p>All is well until one fine day <a href=\\"https://en.wikipedia.org/wiki/Godzilla\\" target=\\"_blank\\">Godzilla</a> wakes up and eats all of the submarine cables in and around Tokyo. I quickly pull up the console, return to the <strong>Failover configuration</strong>, select the active Tokyo Region and the passive Osaka Region, and click <strong>Failover</strong>:</p>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/a37ac62bbf0143a9a7230a84164d59a7_image.png\\" alt=\\"image.png\\" /></p>\n<p>I confirm my intent, click <strong>Failover</strong> again, and the failover is complete within two minutes:</p>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/1d5ceb9486bb42aa924df7742398e5f2_image.png\\" alt=\\"image.png\\" /></p>\n<p>Later, after Godzilla has been subdued and the cables have been repaired, I can fail back to the original bucket in the Tokyo Region:</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/28aba0fed3ed4e8f92c8dcdf52d6fd10_image.png\\" alt=\\"image.png\\" /></p>\n<p><strong><ins>Things to Know</ins></strong><br />\\nHere are a couple of things to keep in mind as you start to make use of this important new Amazon Web Services feature:</p>\n<p><strong>Active/Passive</strong> – There must be at least one active Region at all times.</p>\\n<p><strong>CLI &amp; API Access</strong> – You can initiate a failover programmatically by calling<code>SubmitMultiRegionAccessPointRoutes</code>. You can retrieve the current set of routes by calling<code>GetMultiRegionAccessPointRoutes</code>. The endpoints for these APIs are available in the US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney, Tokyo), and Europe (Ireland) Regions.</p>\\n<p><strong>Pricing</strong> – There is no extra charge for this feature beyond the use of the new APIs, which are billed as standard S3 GET and PUT requests. For S3 Multi-Region Access Point usage prices, see the <strong>Data transfer</strong> tab of the<a href=\\"https://aws.amazon.com/s3/pricing/\\" target=\\"_blank\\"> Amazon S3 Pricing</a> page.</p>\\n<p><strong>Regions</strong> – This feature is available in all Amazon Web Services Regions where Multi-Region Access Points are <a href=\\"https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointRestrictions.html\\" target=\\"_blank\\">currently available</a>.</p>\\n<p>— <a href=\\"https://twitter.com/jeffbarr\\" target=\\"_blank\\">Jeff</a>;</p>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/e53a41706c3c4c3e889fdbebb0a84710_123%29%281%29.png\\" alt=\\"1231.png\\" /></p>\n<h3><a id=\\"Jeff_Barrhttpsawsamazoncomblogsawsauthorjbarr_65\\"></a><a href=\\"https://aws.amazon.com/blogs/aws/author/jbarr/\\" target=\\"_blank\\">Jeff Barr</a></h3>\\n<p>Jeff Barr is Chief Evangelist for Amazon Web Services. He started this blog in 2004 and has been writing posts just about non-stop ever since.</p>\n"}