Amazon Web Services ブログ

Category: Amazon RDS

Amazon RDS for PostgreSQL から Amazon Aurora PostgreSQL リードレプリカを作成可能になりました

Amazon Aurora PostgreSQL リードレプリカ(2018/1/23現在英語版ドキュメントのみとなっています)を Amazon RDS for PostgreSQL のインスタンスとして作成し、継続的に Amazon Aurora PostgreSQL へレプリケーション出来るようになりました。これにより、実稼働ワークロードを Amazon RDS for PostgreSQL から Amazon Aurora PostgreSQL に移行する際、アプリケーションとユーザーを Amazon Aurora PostgreSQL へ移す準備ができるまで、インスタンスタイプを同期させておくことで、ダウンタイムを最小化させることが可能です。 Amazon Auroraは、高性能の商用データベースのパフォーマンスや可用性と、オープンソースデータベースのシンプルさや費用対効果を兼ね備えています。スケーラビリティ、耐久性、およびセキュリティの向上とともに、高いクエリ並列度、データサイズが大きい環境下で標準的なPostgreSQLデータベースのパフォーマンスを最大で3倍向上させます。詳細については、Amazon Auroraの製品ページをご覧ください。 翻訳は江川が担当しました。原文はこちらをご覧ください。

Read More

Amazon RDS for PostgreSQL が新しいマイナーバージョン 9.6.6, 9.5.10, 9.4.15, 9.3.20 をサポート

PostgreSQL コミュニティによるアップデートに追従し、PostgreSQL のマイナーバージョンである 9.6.6, 9.5.10, 9.4.15, 9.3.20 が Amazon RDS for PostgreSQL でサポートされました。このリリースでは、PostgreSQLの3つのセキュリティ上の脆弱性が修正され、追加のバグ修正と改善が行われています。 このアップデートでは、Oracle Database で利用される関数、パッケージの一部を実装した Extension “orafce” と、プレフィックスマッチングを提供する Extension “prefix” のサポートがバージョン 9.6.6 に含まれています。 マネジメントコンソールを使い数クリックで新たな RDS for PostgreSQL を作成するか、既存のインスタンスをワンクリックでアップグレードすることで、新しいバージョンを利用できます。アップグレードする場合、短いダウンタイムが発生することにご注意ください。データベースインスタンスをアップグレードするにあたっての詳細は、 Amazon RDS ユーザーガイドをご覧ください。 Amazon RDS for PostgreSQL は、クラウドで簡単に PostgreSQL を設定、運用、スケール可能です。それぞれのリージョンでご利用いただけるかどうかは、Amazon RDS for PostgreSQL の料金ページをご覧ください。 翻訳は江川が担当しました。原文はこちらです。

Read More

Amazon RDS for MySQLとMariaDBのログをAmazon CloudWatchで監視出来るようになりました

Amazon RDSは、トラブルシューティングなどの目的にお使い頂けるように、DBインスタンスで生成されたログを表示およびダウンロードする機能を提供してきました。Amazon Relational Database Service(Amazon RDS) for MySQLとAmazon RDS for MariaDBでは、DBインスタンスのログイベントをAmazon CloudWatch Logsに直接保存出来るようになりました。これにより、AWSサービスを使用して、よりシームレスにDBインスタンスログを扱うことができます。 DBインスタンスログのニアリアルタイム分析 Amazon CloudWatch Logsを使用すると、アプリケーションの様々なコンポーネントからのログを集中的かつ永続的に保存できます。また、特定のフレーズ、値、パターン(メトリック)について、ニアリアルタイムでログを監視することもできます。さらに、設定した状態が発生したときに警告するアラームを設定することもできます。Amazon CloudWatchは他の様々なAWSサービスと統合することが可能です。これにより、以下のような幅広いユースケースでログを利用する価値を向上できます: 通常デジではありえない大量のスロークエリや接続の失敗など、異常な状態を検知するためのアラーム設定 他のアプリケーションログと関連させる セキュリティおよびコンプライアンスの目的でログを保持する ログデータの傾向を分析する 以下の図がアーキテクチャの概要です: ログエクスポートの概念 新しいログエクスポート機能は、MySQLおよびMariaDBの次のログタイプをサポートしています: Error log – 起動および停止にデータベースエンジンによって生成された診断メッセージが含まれています General query log – クライアントから受け取ったすべてのSQLステートメントのレコードと、クライアントの接続および切断時間を含みます Slow query log – 設定された時間よりも実行に時間かかったクエリや、定義された行数を超える行を走査したSQL文のレコードが含まれています。 両方の閾値は設定可能です Audit log – MariaDB Audit Pluginを使用して提供されるこのログは、監査目的でデータベースアクティビティを記録します これらのソースからのログイベントは、Amazon CloudWatchのロググループにログストリーム(ログイベントのシーケンス)の形式で保存されます。 各DBインスタンスとログの種類に応じて、DBインスタンスと同じAWS Region内に別のグループを次の命名パターンで作成します: /aws/rds/instance/<db-instance-id>/<log-type> ログデータは耐久性のあるCloudWatch Logsに保存され、透過的に暗号化されます。ただし、ログには機密情報が含まれている可能性があります。データを保護するために、アカウント内の適切なユーザーにアクセスを制限する必要があります。そのために、データベースログを含むロググループに対して適切なIAMアクセスポリシーを設定することが重要です。 Amazon RDSはDBインスタンスと同じアカウント内のロググループにservice-linked roleを使用してログを送信します。これにより、Amazon RDSはアカウント内の関連するロググループにアクセスできます。ログの送信を有効にすると、AWSServiceRoleForRDSという追加のIAMロールが表示されることがあります。 CloudWatch Logsへログの送信を有効にするには、以下のように設定を行います。 […]

Read More

Amazon RDSのリードレプリカがMulti-AZ配置をサポートしました

本日より、Amazon RDS for MySQL, MariaDBのリードレプリカがMulti-AZ配置をサポートしました。Multi-AZ配置を設定したリードレプリカを利用することによって、データベースエンジンのアップグレードプロセスの簡素化やディザスタリカバリを見据えた環境を構築することが可能になります。 Amazon RDSのリードレプリカは1つ以上の読み込み専用のデータベースインスタンスをマスターインスタンスと同一のAWSリージョン、もしくは異なるAWSリージョンに作成することが出来ます。ソースデータベースで行われた変更は非同期でリードレプリカへ伝播されます。読み込みが多いワークロードに対するスケーラビリティに加えて、リードレプリカを必要に応じて単一のデータベースインスタンスへ昇格させることも可能です。 Amazon RDS Multi-AZ配置は1つのAWSリージョン内での可用性を向上させます。Multi-AZ環境では、異なるアベイラビリティゾーン(AZ)に存在するスタンバイインスタンスに対してデータが同期的に伝播されます。インフラストラクチャの障害が発生した場合、Amazon RDSはスタンバイインスタンスへ自動的にフェイルオーバーを行い、アプリケーションへの影響を最小限に抑えます。 本番データベースへのディザスタリカバリ(DR)対応として、Multi-AZ配置のリードレプリカをお使いいただけるようになりました。よくデザインされ、テストされたDRプランは災害が発生した後の事業継続性に対して非常に重要な要素になります。ソースデータベースとは別のリージョンにある、リードレプリカをスタンバイ・データベースとして使用し、万が一リージョン障害が発生した場合に新しい本番データベースへ昇格することが可能です。 また、データベースエンジンのアップグレードプロセスにMulti-AZ配置のリードレプリカを利用可能です。本番データベースにリードレプリカを作成し、新しいデータベースエンジンバージョンへ更新します。アップグレードが完了した後に、アプリケーションを一時的に停止し、リードレプリカを単一のデータベースインスタンスとして昇格させます。そして、アプリケーションの接続先を変更します。既に昇格したデータベースインスタンスはMulti-AZ配置になっているため、追加の作業は必要ありません。 更に詳細な情報はこちらをご覧ください。リードレプリカでMulti-AZ配置を行う際に注意していただきたいパラメータについて記載しています。   翻訳は星野が担当しました。(原文はこちら)

Read More

プロセッサの投機的実行に関する調査の公開について

【日本語訳】日本時間 2018年02月14日19:30 関連する CVE: CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 日本時間 2018年02月06日09:30 以下は本件に関するアップデートです。 Amazon Linux 用の更新されたカーネルは、Amazon Linux のリポジトリにて入手できます。2018年1月13日以降にデフォルトの Amazon Linux 設定で起動された EC2 インスタンスには自動的に最新のパッケージが含まれています。 最新のパッケージでは、 CVE-2017-5715 に対処するための安定版オープンソース Linux セキュリティの改善がカーネル内に組み込まれています。また 以前取り込まれた CVE-2017-5754 に対処するカーネルページテーブルアイソレーション(KPTI)にもとづいて作成されています。インスタンス内の CVE-2017-5715 のプロセスープロセス間の問題と CVE-2017-5754 のプロセスーカーネル間の問題を効果的に軽減するには、最新の Amazon Linux カーネルまたは AMI にアップグレードする必要があります。詳細は「プロセッサの投機的実行 – オペレーティングシステムの更新」を参照してください。 para-virtualized(PV)インスタンスについては、以下の「PV インスタンスガイダンス」の情報を参照してください。   Amazon EC2   Amazon EC2 のすべてのインスタンスは、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 […]

Read More

Amazon Kinesis を用いた Databaseの継続的な変更

Emmanuel Espina は、アマゾン ウェブ サービスのソフトウェア開発エンジニアです。 このブログ記事では、Amazon Kinesis を使用して変更をストリーミングすることによって、中央リレーショナルデータベース を他のシステムと統合する方法について説明します。 次の図は、分散システムにおける一般的なアーキテクチャ設計を示しています。これには、「」と呼ばれる中央ストレージと、この中央ストレージを消費するいくつかの派生「衛星」システムが含まれます。 この設計アーキテクチャを使用して、リレーショナルデータベースを中央データストアとして使用し、このシステムのトランザクション機能を利用してデータの整合性を維持することができます。このコンテキストにおける派生システムは、この変化の事実の単一ソースを観察し、それらの変更を変換し、フィルタリングし、最終的にはその内部インデックスを更新する全文検索システムとすることができます。もう 1 つの例は、OLAP クエリに適した列形式ストレージです。一般に、中央リレーショナルシステムの個々の行を変更する際にアクションを取る必要のあるシステムは、派生データストアに適した候補となります。 これらの種類のアーキテクチャの単純な実装では、変更された行を検索するために派生システムが定期的にクエリを発行し、本質的に SELECT ベースのクエリで中央データベースをポーリングします。 このアーキテクチャのより優れた実装となるのが、非同期の更新ストリームを使用するアーキテクチャです。データベースには通常、行のすべての変更が格納されるトランザクションログがあるため、この変更のストリームが外部オブザーバシステムに公開されている場合、これらのシステムにこれらのストリームを添付して行の変更を処理およびフィルタリングできます。ここでは、中央データベースとして MySQL、メッセージバスとして Amazon Kinesis を使用して、このスキーマの基本的な実装をご紹介します。 通常、MYSQL バイナリログは、マスター上のすべての変更を読み取ってローカルに適用する読取りレプリカに公開されます。この記事では、変更をローカルデータベースに適用するのではなく、Amazon Kinesis ストリームに変更を公開する、一般化されたリードレプリカを作成します。 このメソッドの重要な点の 1 つは、コンシューマーが SQL クエリを受け取らないことです。SQL クエリは公開される可能性もありますが、一般的なオブザーバーは、SQL 互換のデータレプリカを維持しない限り、SQL にはあまり関心がありません。代わりに、変更されたエンティティ (行) を 1 つずつ受け取ります。このアプローチの利点は、コンシューマーが SQL を理解する必要はなく、事実の単一ソースは誰が変更を消費するのかを知る必要はないということにあります。これは、さまざまなチームが、必要なデータ形式で調整することなく作業できることを意味します。さらに都合がいいことに、Amazon Kinesis クライアントはが特定の時点から読む機能を備えているため、各コンシューマーは独自のペースでメッセージを処理します。これが、メッセージバスがシステムを統合するための結合されていない方法の 1 つとなる理由です。 この記事で使用されている例では、行フェッチャーは中央データベースに接続する通常の Python プロセスであり、リードレプリカをシミュレートします。 データベースは、Amazon RDS または MySQL の任意のインストールのいずれかになります。RDS の場合、フェッチャープロセスは RDS インスタンスホストにカスタムソフトウェアをインストールすることができないため、別のホスト […]

Read More

Amazon Neptune – フルマネージドのグラフデータベースサービス

現代の生活を可能にするために必要な全てのデータ構造やアルゴリズムの中でも、グラフは日々世界を変えています。ビジネスからは、複雑な関係性を持つリッチなデータが生まれ続け、また取り込まれ続けています。しかし開発者は未だにトラディショナルなデータベースの中でグラフのような複雑な関係性を扱うことを強要されています。必然的に、そのような関係性-リレーションシップが追加されるにつれ、パフォーマンスは劣化し、いらいらするくらい高コストで複雑なクエリとなっていきます。我々はそのようなモダンで複雑性が日々高まるようなデータセットやリレーションシップ、パターンを簡単に扱えるようにしたいと考えました。 Hello, Amazon Neptune 2017年11月29日、我々は限定プレビュー版のAmazon Neptuneを発表します。Amazon Neptuneにより、高度に接続されたデータセット間のリレーションシップから簡単に洞察を得ることができます。Neptuneのコア部分は、数十億ものリレーションシップが格納可能で、グラフに対してミリ秒レベルの遅延となるよう最適化された、専用の、高性能なグラフデータベースエンジンです。フルマネージドなデータベースとして提供されることで、Neptuneはお客様をメンテナンスやパッチ適用、バックアップ/リストアなどの退屈なオペレーションから解放し、アプリケーションに集中できるようにします。高速なフェイルオーバー、Point-in-Timeリカバリ、そしてマルチAZでの実装など高可用性のための各種機能も備えるサービスです。最大15個のリードレプリカによりクエリのスループットを秒間10万件レベルまでスケールさせることも可能です。Amazon NeptuneはAmazon VPC内で動作し、データを暗号化して保管でき、保管時や転送時にデータの整合性について完全に制御することができます。

Read More

Scaling Your Amazon RDS Instance Vertically and Horizontally

Marie Yap はアマゾン ウェブ サービスのソリューションアーキテクトです。 Amazon RDSは、マネージド型サービスとして、リレーショナルデータベースのスケーリングを処理し、データベースがアプリケーションやアプリケーションの増加する要求に対応できるようにします。 このブログ記事では、RDS インスタンスを縦横に拡大縮小する方法について説明します。ほぼ同じ数の読み取りと書き込みを使用するアプリケーションの増加する要求に対応するために、垂直方向に拡大縮小することができます。また、読み取りが重いアプリケーションの場合は、水平方向に拡大縮小することもできます。 垂直スケーリング データベースの高い負荷を処理するために、ボタンを押すだけでマスターデータベースを垂直方向にスケールアップできます。現在、RDS MySQL、PostgreSQL、MariaDB、Oracle、または Microsoft SQL Server インスタンスのサイズを変更する際に、18 種類以上のインスタンスサイズを選択できます。Amazon Aurora では、5 つのメモリ最適化インスタンスサイズを選択できます。インスタンスタイプを幅広く選択することで、データベースサーバーに最適なリソースとコストを選択できます。 以下は、RDS インスタンスをスケールアップする際の考慮事項です。 スケールを変更する前に、商用エンジン (SQL Server、Oracle) の正しいライセンスを取得していることを確認してください (特に、ライセンス持ち込み (BYOL) が必要な場合)。重要なことは、商用エンジンの場合はライセンスによって制限されていることです。ライセンスは、通常 CPU ソケットまたはコアに関連付けられています。 変更をいつ適用するかを決めます。変更をすぐに適用するか、インスタンスで指定されたメンテナンス期間中に変更を適用するかを選択できます。 ストレージとインスタンスのタイプは切り離されています。データベースインスタンスを上下にスケールしたときは、ストレージサイズは同じままで、変更の影響を受けません。DB インスタンスを個別に変更して、割り当てられたストレージスペースを増やすか、ストレージタイプを変更して (一般目的 SSD からプロビジョニング IOPS SSD などに) パフォーマンスを向上させることができます。 スタンバイデータベースが最初にアップグレードされた後で、新しくサイズの変更されたデータベースでフェイルオーバーが発生するため、Multi-AZ 環境でスケールアップする場合のダウンタイムは最小限に抑えられます。シングル AZ インスタンスは、スケール操作中は使用できません。 インスタンスのタイプを変更するには、RDS コンソールの [インスタンスの操作] メニューから [変更] を選択します。 次に、新しい DB インスタンスクラスを選択します。 最後に、変更をすぐに適用するかどうかを決定します。変更をすぐに適用するには、[変更] […]

Read More

Amazon Aurora: Fast DDLの詳細

Anurag GuptaはAmazon Auroraを含む彼がデザインに参加した、いくつかのAWSデータベースサービスに携わっています。 Under the Hoodシリーズでは、Auroraを支える技術や設計について説明します。 Amazon Auroraはオープンソースデータベースのシンプルさとコスト効率とハイエンドなコマーシャルデータベースの可用性と性能を兼ね備えたMySQL互換のデータベースです。この投稿では、Amazon Auroraが一般的な、完了までMySQLでは数時間かかるようなDDL文をほぼ即座に実行出来る仕組みを見ていこうと思います。   Fast DDLとは?なぜ考慮するのか アプリケーションを変更すると、それに付随するデータベースのスキーマを変更する必要があるケースがあります。クエリのワークロードが変わると、インデックスの追加や削除を行う必要があります。データのフォーマットが変更になると、既存のカラムのデータタイプを変更する必要があります。そして、このような変更は頻繁に起こりえます。Ruby on Railsアプリケーションをサポートする一部のDBAは、週に数十回スキーマを変更すると話しています。 多くのMySQLのDBAはご存知のように、このようなスキーマの変更はプロダクションシステムの中断が発生する可能性があります。変更に時間がかかるからです。場合によっては、完了まで数時間から数日かかることもあります。システムのリソースも奪われるため、アプリケーションのスループットも低下します。また、長時間のオペレーションは長時間のクラッシュリカバリが発生する可能性があります。DDL操作の一部は書き込みロックが必要なため、アプリケーションの一部が使用できなくなります。加えて一時的なスペースを多く必要とする可能性があり、小規模のインスタンスではディスクが不足する可能性もあります。 私たちはこのような点を取り除けるように改善を行っており、良く見る一般的なDDL操作(nullableカラムをテーブルの最後に追加)から改善を始めました。   なぜ既存の方法では問題が起こるのか? MySQLがどの様にnullableカラムをテーブルの最後に追加する実装になっているか見ていきましょう。 MySQLは以下のような処理を行っています: データベースはトランザクションのprepareフェーズでオリジナルテーブルに対して排他ロックを取得します 変更後のスキーマで新しい空のテーブルを作成します 1行ずつコピーを行ない、インデックスをその後作成する。同時に実行されたデータ操作(DML)文は、一時ファイルに記録されます 再度、排他ロックを取得し一時ファイルから新しく作成したテーブルへDML文を適用します。適用すべき操作が多くある場合、この処理に時間を要します オリジナルテーブルをdropし、テーブルをリネームします これらの処理には多くのロックが必要になり、データのコピーやインデックスの作成にオーバヘッドが必要になります。そして、I/Oが多く発生し、一時領域も消費します。   もっと良い方法はないのでしょうか? これについてはないと思うかもしれません。各行のデータ形式は変更する必要があります。しかし、この変更をテーブル上で実行されている他のDML(および関連するI/O)操作の上にのせることで、多くのことが実行できます。 完全なアプローチは、ブログポストではやや複雑すぎるので、ここでは簡単に説明します。 Auroraでは、DDLをユーザが実行すると データベースがINFORMATION_SCHEMAのシステムテーブルを新しいスキーマで更新します。加えて、各操作に対してタイムスタンプを付与し変更をリードレプリカに伝搬します。古いスキーマ情報は新しいシステムテーブル(Schema Version Table)内に格納されます 同期的に行う操作はこれだけで完了です。 そして、その後のDML文は、影響のうけるデータページがスキーマの変更を待っている状態か監視します。この操作は、各ページのlog sequence number (LSN)タイムスタンプとスキーマ変更のLSNタイムスタンプを比べるだけで簡単に行なえます。必要に応じて、DML文を適用する前に新しいスキーマにページを更新します。この操作は、redo-undoレコードページの更新と同じ更新プロセスで実行されます。そして、I/Oはユーザの実行するクエリと同様に扱います。 DML操作では、ページ分割が発生する可能性があるため、ページの変更に注意する必要があります。変更はAuroraのレプリカノードでも同様に扱う必要があります。そして、リードレプリカではどのデータへの変更も許可されていません。SELECT文のために、MySQLに戻されるメモリ上のバッファ内のイメージ変更します。この方法では、ストレージ内で新旧のスキーマが混在していたとしても常に最新のスキーマを参照出来ます。 もし、皆さんがAuroraがどのようにストレージからの読み込みとログの適用を行っているかご存知の場合、このアプローチが似ていると感じると思います。しかし、このアプローチではredo logのセグメントではなく、変更を記録するためにテーブルを使用します。 パフォーマンス比較は以下のようになっています。Auroraは Schema Version Tableを変更するために一定の時間で処理が完了しているのがおわかりになると思います。しかし、MySQLではテーブルサイズにほぼ比例して線形に処理時間が増加しています。 明らかに私達が改善すべき多くのDDL文があります。しかし、殆どの物は同様のアプローチで対処可能と考えています。 このことは重要です。たとえデータベースが通常の可用性で稼働していても、これらの長い操作ではアプリケーションへ影響が発生します。それらを並列、バックグラウンド、非同期処理に移すことで違いが出てきます。 質問やフィードバックはありますか?aurora-pm@amazon.comへ是非お寄せ下さい。皆さんの考えや提案を私たちは非常に大切にしています。 注: こちらの機能は2017年4月6日現在Lab modeにてご提供しております。 翻訳は星野が担当しました。原文はこちら。

Read More

Amazon Auroraアップデート: クロスリージョン・クロスアカウントサポートの拡張、T2.Small DBインスタンス、リージョンの追加

Amazon Auroraの最近のアップデートを振り返ってみたいと思います。Amazon AuroraはMySQL互換のハイパフォーマンスなデータベースです(間もなくPostgreSQL互換のAuroraもリリース予定です)。Amazon Auroraの紹介は、【AWS発表】Amazon Auroraをご利用頂けるようになりました!や【AWS発表】Amazon Aurora – Amazon RDSに費用対効果の高いMySQL互換のデータベースが登場!!をご覧ください。 最近Auroraへ追加された機能は以下のとおりです クロスリージョンスナップショットコピー 暗号化されたデータベースのクロスリージョンレプリケーション 暗号化されたスナップショットのアカウント間の共有 US West (Northern California)リージョンのサポート T2.smallインスタンスサポート   クロスリージョンスナップショットコピー Amazon Auroraのスナップショット(自動・手動取得に関わらず)リージョン間でコピー出来るようになりました。スナップショットを選択し、Snapshot ActionsからCopy Snapshotを選択します。その後、リージョンを選択後、新しいスナップショットの名前を入力します。 この操作の中で、暗号化済みスナップショットも選択可能です。詳細はドキュメントをご覧ください。   暗号化されたデータベースのクロスリージョンレプリケーション Amazon Aurora DBを作成する際に暗号化オプションを設定出可能です。 数クリックで他のリージョンにリードレプリカを作成することが出来るようになりました。この機能を利用することで、マルチリージョン、ハイアベイラビリティなシステムが構築可能になりますし、ユーザに近い位置にデータを移動することも可能です。クロスリージョンリードレプリカを作成するには、既存のDBインスタンスを選択し、メニューからCreate Cross Region Read Replicaを選択するだけです。 その後、Network & Securityからリージョンを選択し、Createをクリックします。 レプリケーション先のリージョンには必ず2つ以上のアベイラビリティゾーンを含んだDB Subnet Groupが必要です。 このパワフルな新機能について詳細は、ドキュメントをご覧ください。   暗号化されたスナップショットのアカウント間の共有 Amazon Aurora DBインスタンスを作成する際に、定期的に自動でスナップショットを行う設定が可能です。この他にも、数クリックで任意のタイミングでスナップショットを作成することも可能です。 DBインスタンスが暗号化されている場合はスナップショットも暗号化されます。 AWS間で暗号化されたスナップショットを共有出来るようになりました。この機能を使うためには、DBインスタンスはdefault RDS keyではないマスターキーで暗号化されている必要があります。まず、スナップショットを選択し、Snapshot ActionsメニューからShare Snapshotを選択します。 そして、共有先のAWS Account […]

Read More