暗号化していないRDS DBインスタンスを暗号化する | DevelopersIO
Amazon RDS リソースの暗号化オプションを有効化すると、AES-256 暗号化アルゴリズムにより以下のデータを暗号化することができます。 ※対応しているインスタンスクラスや制限事項についてはAmazon RDS リソースの暗号化をご確認ください。 DB インスタンス 自動バックアップ リードレプリカ スナップショット ログ 暗号化オプションはDB インスタンスの作成時にのみ有効にすることができ、作成後のインスタンスでは有効にすることができません。ただし暗号化されていないスナップショットのコピーは暗号化することが可能です。 そのため暗号化してコピーしたスナップショットから暗号化されたインスタンスを復元することができます。 今回は、暗号化していない既存インスタンスを暗号化オプションを有効化にしたインスタンスにする方法をご紹介します。 要件 MySQLエンジンの暗号化オプションを有効にし
【AWS】暗号化されていないRDSを暗号化したい | 大阪のシステム開発なら 株式会社ウィズテクノロジー
「このRDS、暗号化できたらいいのにな」ってこと、ありませんか？ ネットセキュリティ対策が求められる昨今、稼働中のRDSが「暗号化」されていないものも多少なり存在していると思います。 コンプライアンス要件の達成も含め、掲題のようにお考えの方もいいらっしゃるのではないでしょうか？ そこで今回は、稼働中のRDS暗号化の方法・手順をご紹介します。 RDSを暗号化するメリット 文字通り、RDSのデータ保護が最大のメリットになります。 万一、AWSデータセンタへ不正アクセスや侵入被害にあった場合に効力を発揮しますので、リスクヘッジとしては大きな役割を担います。 ※XSSなどによるアプリケーションの脆弱を突かれた場合、RDS暗号化では侵入・漏えいは防げません。 一方で暗号化によるRDSパフォーマンス低下が気になるところですが、大幅なパフォーマンス低下はなさそうです。それでも不安という方は、負荷テストを
本番環境でダウンタイムを最小限にするためRDSをMulti-AZ構成にした後スケールアップを行う - Qiita
こんにちわ！OCEAN'Sの大庭です。 今回は、本番環境でRDSのスケールアップを行いましたのでその手順とログを紹介していきます 概要 まず、RDSがSingle-AZ構成のままスケールアップを行うと、 インスタンス停止 インスタンスタイプの変更（スケールアップ） インスタンス起動 となってしまい、DBサイズにもよるがサービスダウンタイムが10分弱はかかってしまいます。 そのため、今回は以下の方法でスケールアップを行います RDSをMulti-AZ構成に変更 RDSのスケールアップ プライマリにフェイルバック RDSをMulti−AZに変更 まず、RDSをMulti−AZ構成に変更する。 Multi-AZ構成への変更はダウンタイムが発生しませんが、 シングル AZ からマルチ AZ への変換時のダウンタイムを回避できますが、マルチ AZ への最初の変換時にパフォーマンスに大きな影響が出るこ
RDSフェイルオーバーによるダウンタイムの実測（PostgreSQL編） | 技術畑 | 情報畑でつかまえて
RDSフェイルオーバーによるダウンタイムの実測（PostgreSQL編） オンプレミスなシステムをAWSに移行する際など、DBサーバにはRDSを使うかという点がよく議論になります。RDSは非常に便利ですが、導入の検討段階で「定期メンテナンスやフェイルオーバーでダウンタイムが発生するからNGになった」という話をよく聞きます。 ダウンタイムはどの程度か、という話はAWSの公式サイトにも記述があり、「通常」60～120秒とされています。可用性担保を使命とするエンジニアとしては、この「通常」という言葉がとても気になりますよね。 ということで、今回はRDSのフェイルオーバーによるダウンタイムを実測してみました。
マルチAZ構成のRDS(MySQL)を強制フェイルバックさせてみた | DevelopersIO
はじめに AWSチームのすずきです。 マルチAZ構成で作成されたRDS(MySQL)は、メンテナンスウィンドウによるインスタンスタイプやストレージ容量の変更後、 マスタDBの稼働するアベイラビリティーゾーン(AZ)がフェイルオーバーにより変化する事があります。 【AWS】RDSのインスタンスタイプ変更にかかる時間を調べてみた EC2とRDS間の通信がクロスAZとなる事で、レイテンシの増加やAZ間のネットワーク転送費(0.01$/GB)が問題となる環境で、 手動フェイルオーバーを実施する機会がありましたので紹介させて頂きます。 構成図 EC2、RDS間の通信がクロスAZとなった環境(右)、フェイルバックにより復旧させました。 操作 再起動 手動(強制)フェイルオーバは、RDSの再起動で実施します。 「フェイルオーバし再起動」をチェックし、再起動を行います。 通常、数分でフェイルオーバが完了、
拡張モニタリングを使用した OS メトリクスのモニタリング - Amazon Relational Database Service
Enhanced Monitoring を使用すると、DB インスタンスのオペレーティングシステムをリアルタイムでモニタリングできます。さまざまなプロセスまたはスレッドが CPU をどのように使用しているかを確認するには、Enhanced Monitoring メトリクスが役立ちます。 Enhanced Monitoring の概要 Amazon RDS には、DB インスタンスが実行されているオペレーティングシステム (OS) のリアルタイムのメトリクスが用意されています。RDS DB インスタンスのすべてのシステムメトリクスとプロセス情報をコンソールに表示できます。各インスタンスでモニタリングするメトリクスを管理し、要件に応じてダッシュボードをカスタマイズできます。拡張モニタリングメトリクスの説明については、「拡張モニタリングの OS メトリクス」を参照してください。 RDS は、拡張
RDSのフェイルオーバー時の挙動を理解してみる | TF Lab - クラウド開発記録 -
突然ですが皆さん、RDS、使ってますか？ こんにちは、クラウドエンジニアの大田です。 先月8月23日に起こった東京リージョンでの大規模障害が起きて久しいですね。 当初単一AZでの影響のみと考えられていた障害でしたが、 RDSやALBでのInternal Server Errorを吐いていたことが分かり、 障害の影響はマルチAZ配置のシステムにも波及していました。 「ウチはマルチAZでフェイルオーバーするから安心！」と思っていたらRDSが停止または自動再起動していた…という方もいらっしゃったのではないでしょうか。 さて、今回のテーマは「RDSのフェイルオーバー時の挙動を理解してみる」です。 主なゴールは、RDSのフェイルオーバー時の挙動を学び、安定稼働のためのヒントを得ていただくことです。 思考停止でとりあえずRDS使っとけ！的な風潮はありますが、やはり内部の動きを正確に理解しておかないと、
Amazon Redshift編～パフォーマンス比較（MySQL vs Redshift） 後編～
こんにちは！中の人です。 前回までのレシピでは、『Amazon Redshift編～パフォーマンス比較（MySQL vs Redshift） 前編～』ということで、RDSとRedshiftに対して通常のselect文でのパフォーマンス比較を行いました。 後編ではカラムナー型であるRedshiftが得意とする方法でのパフォーマンスを検証します。 では実際に、検証結果を見ていきましょう！ ≪通常のRDBMS≫ 1行1行を取り出して、条件に一致しているかをチェックしています。 大量のデータから特定の条件に一致するデータを取り出して集計するといったような事には向いていません。 ≪カラムナーデータベース≫ 列方向に対してデータを圧縮して保持し、列に対してチェックします。 列方向のデータのみを取り出すために無駄なカラムを取得する必要がありません。 「7月1日～31日の5000円以上のプランの平均価格は
Amazon Redshift編～パフォーマンス比較（MySQL vs Redshift） 前編～
こんにちは！ 中の人です。 前回までのレシピでは、RedshiftのXLノード1～数台に対して様々なSQLを実行してパフォーマンス比較およびまとめを行いました。 ※ 下記、過去記事参照 ■ Amazon Redshift編～複数クエリ同時実行時パフォーマンス比較（シングル）～ ■ Amazon Redshift編～複数クエリ同時実行時パフォーマンス比較（マルチ）～ ■ Amazon Redshift編～複数クエリ同時実行時パフォーマンス比較（XL vs 8XL）～ ■ Amazon Redshift編～複数クエリ同時実行時パフォーマンス比較(まとめ)～ 今回は『Amazon Redshift編～パフォーマンス比較（MySQL vs Redshift）前編～』と題して、同じデータをMySQLに流しこんで、実際にパフォーマンス比較を行なってみます。 比較を行ったのは以下の2つです。 RDS x
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
