Amazon Web Services ブログ

AWS CloudFormation を使用して、推奨されるベストプラクティスによって Amazon Aurora PostgreSQL DB クラスターをデプロイする

このブログ記事では、Amazon Aurora PostgreSQL クラスターのクイックスタートリファレンスデプロイメントを構築する方法について説明します。クラスターはセキュリティと高可用性のための AWS のベストプラクティスに基づいており、AWS CloudFormation を使用して速やかに作成できます。必要に応じてカスタマイズできる CloudFormation の一連のサンプルテンプレートを見ていきます。

Amazon Aurora は、クラウド用に構築された MySQL および PostgreSQL 互換のリレーショナルデータベースです。Aurora は、ハイエンドの商用データベースのパフォーマンスと可用性、ならびにオープンソースデータベースのシンプルさと費用対効果を兼ね備えています。

PostgreSQL 互換エディションの Aurora は、同じハードウェアで動作する標準 PostgreSQL の最大 3 倍のスループットを実現します。これにより、既存の PostgreSQL アプリケーションおよびツールを変更することなく実行できます。PostgreSQL の互換性と Aurora のエンタープライズデータベース機能の組み合わせは、商用データベースの移行にとって理想的なターゲットです。

Aurora PostgreSQL で道筋を始めて、AWS Well-Architected フレームワークの推奨ベストプラクティスに基づいて AWS リソースを設定したい場合は、ここで提供されている CloudFormation テンプレートを使用できます。

アーキテクチャの概要

下の図は、アーキテクチャの図であり、これから設定しようとしているものの簡単な要約です。

サンプルの CloudFormation テンプレートは、ネットワークインフラストラクチャとアーキテクチャの図に示されているすべてのコンポーネントをプロビジョニングします。CloudFormation テンプレートを次の 3 つのスタックに分割しました。

  1. VPC、サブネット、ルートテーブル、インターネットゲートウェイ、NAT ゲートウェイ、S3 ゲートウェイエンドポイント、AWS Secrets Manager インターフェイスエンドポイント、およびその他のネットワークコンポーネントを設定する CloudFormation テンプレート。
  2. Aurora PostgreSQL DB クラスターに接続するために Auto Scaling グループで Amazon Linux Bastion ホストを設定する CloudFormation テンプレート。
  3. AWS Secrets Manager に保存されたマスターユーザーパスワードで Aurora PostgreSQL DB クラスターを設定し、AWS Lambda を使用してデータベースをブートストラップする CloudFormation テンプレート。

スタックは、エクスポートされた出力値を使用して統合されます。1 つのネストされたスタックの代わりに 3 つの異なる CloudFormation スタックを使用することで、ある程度の柔軟性が得られます。たとえば、AWS リージョンで VPC と Bastion ホストの CloudFormation スタックを 1 回デプロイし、Aurora PostgreSQL DB クラスターの CloudFormation スタックを複数回デプロイすることを選択できます。

ベストプラクティス

これらの CloudFormation テンプレートによって構築されたアーキテクチャは、高可用性とセキュリティのための AWS のベストプラクティスをサポートしています。

VPC の CloudFormation テンプレートは、以下をサポートします:

  1. 高可用性と災害復旧のために 3 つのアベイラビリティーゾーンを設定します。アベイラビリティーゾーンは、リージョン内に地理的に分散しており、自然災害が発生した場合に最適な分離と安定性が得られるように配置されています。
  2. それぞれのアベイラビリティーゾーンに、1 つのパブリックサブネットと 1 つのプライベートサブネットをプロビジョニングします。データ漏洩のリスクを軽減するために、外部と接するリソースにはパブリックサブネットを、内部リソースにはプライベートサブネットを使用することをお勧めします。
  3. ネットワーク ACL を作成し、デフォルトのルールでプライベートおよびパブリックのサブネットに関連付けます。AWS は、サブネットレベルでインバウンドトラフィックおよびアウトバウンドのトラフィックを制御するために、ファイアウォールとしてネットワーク ACL を使用することを推奨しています。これらのネットワーク ACL は、防御の第 2 層としてカスタマイズできる個別の制御を提供します。
  4. それぞれのプライベートサブネットに対して独立したルーティングテーブルを作成して関連付けます。これらは、Amazon VPC 内外のトラフィックのフローを制御するために必要に応じて設定できます。パブリックサブネットは、すべてがインターネットと通信するための唯一の経路として同じインターネットゲートウェイを使用するため、単一のルーティングテーブルを共有します。
  5. 高可用性のために 3 つのパブリックサブネットのそれぞれに NAT ゲートウェイを作成します。NAT ゲートウェイは、デプロイメント、可用性、メンテナンスに関して、NAT インスタンスよりも優れた利点を提供します。NAT ゲートウェイを使用すると、プライベートサブネット内のインスタンスはインターネットまたは他の AWS のサービスに接続できますが、インターネットはそれらのインスタンスとの接続を開始することはできません。
  6. 安全で信頼できる方法で Amazon S3 と通信するためにプライベートサブネットで、たとえば AWS Lambda などのリソースを提供する S3 VPC エンドポイントを作成します。
  7. インターネットアクセスを必要とせずに Secrets Manager サービスと安全な方法で通信するためにプライベートサブネットで Lambda リソースを提供するAWS Secrets Manager インターフェイス VPC エンドポイントを作成します。

Amazon Linux Bastion ホストの CloudFormation テンプレートは、以下をサポートします:

  1. VPC CloudFormation テンプレートによって設定された 3 つのパブリックサブネットにまたがる Auto Scaling グループを作成します。Auto Scaling グループは、Amazon Linux Bastion ホストが 3 つのアベイラビリティーゾーンのうちの 1 つで常に利用可能であることを保証します。
  2. Elastic IP アドレスを設定し、Amazon Linux Bastion ホストに関連付けます。Elastic IP アドレスを使用すると、これらの IP アドレスが覚えやすくなり、オンプレミスのファイアウォールで容易に許可することができます。インスタンスが終了し、Auto Scaling グループが代わりに新しいインスタンスを起動すると、既存の Elastic IP アドレスが新しいインスタンスに再関連付けされます。これにより、必ず同じ信頼された Elastic IP アドレスが使用されるようになります。
  3. EC2 セキュリティグループを設定し、Amazon Linux Bastion ホストに関連付けます。これにより、Bastion ホストへのアクセスを既知の CIDR スコープおよび入力用のポートに制限することができます。
  4. Amazon Linux Bastion ホストのシェル履歴ログを保持する Amazon CloudWatch Logs ロググループを作成し、SSH コマンド数を追跡する CloudWatch メトリクスを設定します。これにより、Bastion ホストがいつ、誰によってアクセスされているかを確認できるため、セキュリティ監査に役立ちます。
  5. Bastion ホストの CPU を監視し、アラームがトリガーされたときに SNS 通知を送信する CloudWatch アラームを作成します。

Aurora PostgreSQL DB クラスターのテンプレートは、以下をサポートします:

  1. 本稼働タイプまたは本稼働前タイプの環境用に、2 つの別々のアベイラビリティーゾーンにプライマリインスタンスと Aurora レプリカを持つマルチ AZ Aurora DB クラスターを作成します。これは、高可用性のために AWS によって推奨されています。プライマリ DB インスタンスが使用できなくなった場合、Aurora は自動的に Aurora レプリカにフェイルオーバーします。
  2. AWS セキュリティのベストプラクティスに従って、Aurora DB クラスターをプライベートサブネットに配置します。DB クラスターにアクセスするには、Linux Bastion ホストの CloudFormation テンプレートによって設定された Amazon Linux Bastion ホストを使用します。
  3. EC2 セキュリティグループを設定し、Aurora DB クラスターに関連付けます。これにより、DB クラスターへのアクセスを既知の CIDR スコープおよび入力用のポートに制限することができます。
  4. AWS Secrets Manager を使用してランダムなマスターユーザーパスワードを生成し、このパスワードを Aurora DB クラスターに関連付けます。CloudFormation のカスタムリソースに支えられる Python ベースの Lambda 関数が、AWS Secret Manager が提供する Serverless Application Repository を使用して 30 日ごとの自動パスワードローテーションを設定します。AWS は、パスワードが危険にさらされた場合に備えて、不正アクセスを防止するためにパスワードを定期的にローテーションすることを推奨しています。
  5. 次の設定で DB クラスターのパラメータグループを作成し、Aurora DB クラスターに関連付けます。以下の DB クラスターのパラメータは一般的なガイドとして提供されています。確認して、ニーズに合うようにカスタマイズする必要があります。
    パラメータ Value 説明
    rds.force_ssl 1 これにより、Aurora インスタンスへの接続に SSL が使用されるようになります。
  6. 次の設定で DB パラメータグループを作成し、Aurora DB インスタンスに関連付けます。以下の DB インスタンスのパラメータは一般的なガイドとして提供されています。確認して、ニーズに合うようにカスタマイズする必要があります。
    パラメータ Value 説明
    shared_preload_libraries

    auto_explain,

    pg_stat_statements,

    pg_hint_plan,

    pgaudit

    		 auto_explain モジュールは、手動で EXPLAIN を実行する必要なしに、遅いステートメントの実行計画を自動的に記録する手段を提供します。
    pg_stat_statements モジュールは、サーバーによって実行されたすべての SQL ステートメントの実行統計を追跡する手段を提供します。
    pg_hint_plan は、PostgreSQL に実行計画の決定を手動で強制する機能を与えます。
    pgaudit は、PostgreSQL が提供する標準のロギング機能を介して詳細なセッションおよび/またはオブジェクトの監査ロギングを提供します。
    log_statement “ddl” どの SQL ステートメントをログに記録するかを制御します。
    log_connections 1 各サーバーへの接続の試行、ならびにクライアント認証の正常な完了をログに記録します。
    log_disconnections 1 セッション終了をログに記録します。
    log_lock_waits 1 セッションがロックを獲得するために deadlock_timeout より長く待つ場合に、ログメッセージを生成するかどうかを制御します。
    log_min_duration_statement 5,000 ステートメントが少なくとも指定されたミリ秒数の間実行された場合、完了した各ステートメントの期間をログに記録します。
    auto_explain.log_min_duration 5,000 ステートメントの計画がログに記録される最小ステートメント実行時間 (ミリ秒単位)。
    auto_explain.log_verbose 1 実行計画がログに記録されるときに、詳細を表示するかどうかを制御します。
    log_rotation_age 1,440 logging_collector が有効であれば、このパラメータは個々のログファイルの最大保持時間を分単位で決定します。ここで指定された分数が経過すると、新しいログファイルが作成されます。
    log_rotation_size 102,400 logging_collector が有効であれば、このパラメータは個々のログファイルの最大サイズをキロバイト単位で決定します。ここで指定されたキロバイト数がログファイルに出力されると、新しいログファイルが作成されます。
    rds.log_retention_period 10,080 Amazon RDS は、指定された分数より古い PostgreSQL ログを削除します。
    random_page_cost 1 テーブルの逐次スキャンと比較して、インデックススキャンがプランナーにとってより魅力的に見えるようにします。
    track_activity_query_size 16,384 [pg_stat_activity.query] フィールドに、それぞれのアクティブセッションに対して現在実行中のコマンドを追跡するために予約されているバイト数を指定します。
    idle_in_transaction_session_timeout 7,200,000 指定された期間 (ミリ秒) よりも長い時間アイドル状態になっている、完了していないトランザクションがあるセッションを終了します。
    statement_timeout 7,200,000 コマンドがクライアントからサーバーに到着した時点から、指定されたミリ秒数を超えているステートメントをすべて中止します。
    search_path “$user”,public’ この変数は、スキーマが指定されていない単純な名前でオブジェクト (テーブル、データ型、関数など) が参照される場合にスキーマが検索される順序を指定します。
  7. AWS KMS を使用して顧客管理の暗号化キーを作成し、そのキーを使用して Aurora DB クラスターの保管中の暗号化を有効にします。
  8. 本稼働環境と非本稼働環境のそれぞれについて、バックアップの保持期間を 35 日と 7 日に設定します。これは、本稼働データベースを過去 35 日間の任意の時点に確実に復旧できるようにするためです。同様に、非本稼働データベースは過去 7 日間の任意の時点に復旧できます。
  9. リアルタイムの OS メトリクスを表示し、データベースのパフォーマンスの問題をトラブルシューティングできるように、1 秒の精度での本稼働環境の拡張モニタリングを自動的に有効にします。
  10. Performance Insight を自動的に有効にし、顧客管理のAWS KMS暗号化キーを使用して Performance Insight のデータ暗号化を設定します。本稼働環境と非本稼働環境の Performance Insight のデータの保存期間をそれぞれ 2 年と 7 日に設定します。Performance Insight は、データベースのパフォーマンスの問題を迅速に検出し、いつ、どこで対処するべきかを判断するのに役立ちます。
  11. IAM データベース認証を有効にして、AWS Identity and Access Management (IAM) を使用したデータベースログインで、データベースパスワードの代わりに認証トークンを使用するようにします。IAM データベース認証を使用する場合、データベースとの間でのネットワークトラフィックは Secure Sockets Layer (SSL) を使用して暗号化されます。
  12. これにより、すべての非本稼働環境がアップグレードされ、アプリケーション機能が正常にテストされたときに、スケジュールに従ってアップグレードを実行できるように、本稼働タイプの環境のマイナーバージョン自動アップグレードオプションを無効にします。
  13. Aurora データベースインスタンスの CPUUtilization、MaximumUsedTransactionID、FreeLocalStorage などの主要な CloudWatch メトリクスに対して CloudWatch アラームを設定し、アラームがトリガーされると SNS 通知を送信します。
  14. 重要なイベントが生成されたときに通知するように、db-cluster、db-instance、db-parameter-group の各ソースタイプの RDS イベント通知を設定します。
  15. Aurora クラスターとデータベースインスタンスに必須の共通タグをアタッチします。AWS は、クラウドインフラストラクチャリソースにタグを割り当てて、リソースのアクセスコントロール、コストの追跡、自動化、組織化を管理することを推奨しています。
  16. Lambda 関数を使用して、作成時に Aurora DB クラスターをブートストラップします。これにより、サーバによって実行されたすべての SQL ステートメントの実行統計を追跡する pg_stat_statements 拡張が作成されます。また、Lambda 関数は、セッションおよびオブジェクトレベルの監査機能を提供する pgaudit 拡張も作成します。

前提条件

CloudFormation スタックを設定する前に、以下の前提条件に注意してください。

  1. AWS マネジメントコンソールおよび「アーキテクチャの概要」セクションに記載されているサービスとやり取りするのに十分なアクセス許可を持つAWSアカウントと AWS Identity and Access Management (IAM) ユーザーが必要です。IAM権限には、AWS CloudFormationテンプレートによって作成されたIAMロールと、ポリシーを作成するアクセス権も含まれている必要があります。
  2. VPC CloudFormation スタックには、パブリックサブネットとプライベートサブネットを設定するための 3 つのアベイラビリティーゾーンが必要です。必ず、少なくとも 3 つのアベイラビリティーゾーンがある AWS リージョンを選択します。
  3. CloudFormation スタックを設定する予定の AWS リージョンで、Amazon EC2 コンソールを使用して EC2 キーペアを作成します。保存できるのはこの時だけなので、プライベートキーを必ず保存します。Amazon Linux Bastion ホスト CloudFormation スタックを設定するときに、この EC2 キーペアを入力パラメータとして使用します。
  4. 以下のように、Amazon S3 バケットを作成し、サンプルデータベースのブートストラップ AWS Lambda zip ファイルをアップロードします。
    1. Aurora PostgreSQL DB クラスターを設定する予定のと同じ AWS リージョンに S3 バケットを作成します。バケットの設定では、追加の設定は必要ありません。
    2. バケット内にフォルダ (プレフィックス) を作成します。
    3. GitHub からサンプル AWS Lambda zip ファイル zip をダウンロードします。
    4. zip ファイルを S3 バケットフォルダにアップロードします。アップロード画面で、追加設定は必要ありません。

    Aurora DB クラスター CloudFormation スタックを設定する際は、S3 キープレフィックスと共に S3 バケット名を入力パラメータとして使用します。この Zip ファイルは、Python 2.7 で書かれた Lambda 関数を作成するために使用されます。この関数は PyGreSQL モジュールを使用して Aurora PostgreSQL クラスターに接続し、作成時にブートストラップします。

    PyGreSQL は、BSD または MIT ライセンスに似ている自由なオープンソースライセンスである PostgreSQL ライセンスの下でリリースされています。詳細については、GitHub の LICENSE.txt を参照してください。

AWS CloudFormation を使用してリソースを設定する

これらの CloudFormation テンプレートは、一般的なガイドとして提供されています。確認して、ニーズに合うようにカスタマイズする必要があります。これらのスタックによってデプロイされたリソースの一部では、使用を終了しない限り、料金が発生します。

VPC、サブネット、その他のネットワークコンポーネントを設定する

  1. [Launch Stack] を選択します。このボタンは、お使いの AWS アカウントで、テンプレートを使って自動的に AWS CloudFormation サービスを開始します。必要に応じて、サインインするプロンプトが表示されます。必要に応じて、コンソール内から CloudFormation テンプレートを表示できます。
  2. 画面の右上でスタックを作成する AWS リージョンを選択してから、[Next] を選択します。この CloudFormation スタックには、パブリックサブネットとプライベートサブネットを設定するための 3 つのアベイラビリティーゾーンが必要です。少なくとも 3 つのアベイラビリティーゾーンがある AWS リージョンを選択します。
  3. 次のスクリーンショットに示すように、CloudFormation スタックにはいくつかのパラメータが必要です。
    • Stack name : スタックの分かりやすい名前を入力します。例、apgvpc
    • ClassB 2nd Octet : VPC 用の IPv4 CIDR ブロックの 2 番目のオクテット (10.XXX.0.0/16) を指定します。0 から 255 までの任意の数を指定できます。たとえば、33を指定すると、IPv4 CIDR ブロックが 10.33.0.0/16 で VPC を作成することになります。
      IPv4 用の VPC とサブネットのサイズ設定の詳細については、AWS VPC のドキュメントを参照してください。
  4. すべてのパラメータ値を入力した後、[Next] を選択します。
  5. 次の画面で、必要なタグ、IAM ロール、または詳細オプションを入力して、[Next] を選択します。
  6. 最後の画面で詳細を確認してから、[Create] を選択してネットワークリソースの構築を開始します。

スタックを作成するのに約 4 分かかります。AWS CloudFormation のリソースセクションを確認して、このスタックによって設定されたさまざまなコンポーネントの物理 ID を確認します。

それでは、Aurora PostgreSQL DB クラスターへのログインに使用する Amazon Linux Bastion ホストを設定しましょう。

Amazon Linux Bastion ホストを設定する

  1. [Launch Stack] を選択します。このボタンは、お使いの AWS アカウントで、起動するテンプレートを使って自動的に AWS CloudFormation サービスを開始します。
  2. 画面の右上でスタックを作成する AWS リージョンを選択してから、[Next] を選択します。
  3. 次のスクリーンショットに示すように、CloudFormation スタックにはいくつかのパラメータが必要です。
    • Stack name : スタックの分かりやすい名前を入力します。例、apgbastion
    • ParentVPCStack : 前の手順で設定した VPC スタックの CloudFormation スタック名を入力します。この名前を取得するには、AWS コンソールの CloudFormation ダッシュボードを参照してください。例、apgvpc
    • Allowed Bastion External Access CIDR : Bastion ホストへの外部 SSH アクセス用に許可された CIDR ブロックを x.x.x.x/x 形式で入力します。
    • Key Pair Name : 前提条件セクションで設定したキーペアの名前を選択します。
    • Bastion Instance Type : Bastion インスタンスの Amazon EC2 インスタンスタイプを選択します。
    • LogsRetentionInDays : Bastion ホストの CloudWatch ログイベントを保持する日数を指定します。
    • SNS Notification Email : CloudWatch アラーム通知を送信するための SNS トピックを設定するために使用される E メール通知リストを入力します。
    • Bastion Tenancy : Bastion ホストが起動されている VPC テナンシーを選択します。
    • Enable Banner : SSH で Bastion に接続するときにバナーを表示するかどうかを選択します。
    • Bastion Banner : デフォルトを使用するか、ログイン時に表示されるバナーテキストを含むファイルの AWS S3 の場所を指定します。
    • Enable TCP Forwarding : TCP 転送を有効/無効にするかどうかを選択します。この値を true に設定すると、TCP 転送 (SSH トンネリング) が有効になります。これは非常に便利ですが、セキュリティ上のリスクもあるため、必要な場合を除いてデフォルト (無効) の設定を使用することをお勧めします。
    • Enable X11 Forwarding : X11 転送を有効/無効にするかどうかを選択します。この値を true に設定すると、SSH を介した X Windows が有効になります。X11 転送は非常に便利ですが、セキュリティ上のリスクもあるため、必要な場合を除いてデフォルト (無効) の設定を使用することをお勧めします。
    • Custom Bootstrap Script : オプション。Bastion ホストの設定中に実行するカスタムブートストラップスクリプトの AWS S3 の場所を指定します
    • AMI override : オプション。インスタンスに使用する AWS リージョン固有のイメージを指定します。
  4. すべてのパラメータ値を入力した後、[Next] を選択します。
  5. 次の画面で、必要なタグ、IAM ロール、または詳細オプションを入力して、[Next] を選択します。
  6. 最後の画面で詳細を確認し、[I acknowledge that AWS CloudFormation might create IAM resources] のボックスにチェックを入れてから、[Create] を選択してネットワークリソースの構築を開始します。

スタックを作成するのに約 5 分かかります。AWS CloudFormation のリソースセクションを確認して、このスタックによって設定されたさまざまなコンポーネントの物理 ID を確認します。

これで、Aurora PostgreSQL DB クラスターを設定する準備が整いました。

Aurora PostgreSQL DB クラスターを設定する

  1. [Launch Stack] を選択します。このボタンは、お使いの AWS アカウントで、起動するテンプレートを使って自動的に AWS CloudFormation サービスを開始します。
  2. 画面の右上でスタックを作成する AWS リージョンを選択してから、[Next] を選択します。
  3. 次のスクリーンショットに示すように、CloudFormation スタックにはいくつかのパラメータが必要です。
    • Stack name : スタックの分かりやすい名前を入力します。例、apgprod-sampleapp
    • EnvironmentStage : Aurora PostgreSQL DB クラスターの環境ステージ (dev、test、pre-prod、prod) を選択します。このパラメータに「prod」オプションを指定すると、DB バックアップの保持期間は 35 日に設定され、拡張モニタリングは 1 秒単位で有効になり、マイナーバージョンの自動アップグレードは無効になります。このパラメーターに「prod」または「pre-prod」オプションを指定すると、2 つの別々のアベイラビリティーゾーンにプライマリインスタンスと Aurora レプリカを持つマルチ AZ Aurora DB クラスターが作成されます。
    • DBName : データベース名を入力します。例、sampledb
    • DBPort: データベースインスタンスの TCP/IP ポートを入力します。
    • DBUsername : データベースマスターのユーザー名を入力します。例、master
    • DBInstanceClass : データベースインスタンスのクラスを選択します。
    • DBEngineVersion : データベースエンジンのバージョンを選択します。
    • DBSnapshotName : オプション。復元する DB スナップショットの ID を入力します。スナップショットから復元しない場合は、空白のままにします。
    • NotificationList : CloudWatch アラームおよび RDS イベント通知を送信するための SNS トピックを設定するために使用される E メール通知リストを入力します。
    • LambdaBootStrapS3Bucket : 前提条件セクションで作成した S3 バケット名を指定します。例、apgbootstrapscript-us-east-1
    • LambdaBootStrapS3Key : データベースブートストラップスクリプトが保存されている S3 キー (前提条件セクションで作成したフォルダと zip フォルダ名を含む) を指定します。例、lambda/dbbootstrap.zip
    • ParentVPCStack : 親 VPC スタックのスタック名を入力します。この名前を取得するには、AWS コンソールの CloudFormation ダッシュボードを参照してください。
    • ParentSSHBastionStack : 親 Amazon Linux Bastion ホストスタックのスタック名を入力します。この名前を取得するには、AWS コンソールの CloudFormation ダッシュボードを参照してください。
    • Application : Application タグは、関連する AWS リソースのアプリケーションを指定するために使用されます。このキャパシティーでは、アプリケーションとはインストールされているソフトウェアコンポーネントではなく、リソースがサポートするビジネスアプリケーション全体を指します。
    • ApplicationVersion : ApplicationVersion タグは、アプリケーションの特定のバージョンを指定するために使用されます。
    • ProjectCostCenter : ProjectCostCenter タグは、特定の AWS リソースのプロジェクトに関連付けられているコストセンターを指定するために使用されます。
    • ServiceOwnersEmailContact : ServiceOwnersEmailContact タグは、停止通知またはメンテナンス通知を送信するための特定の AWS リソースに関連付けられている事業主の E メールアドレスを指定するために使用されます。
    • Confidentiality : Confidentiality タグは、リソースに関連付けられているデータの機密性分類を指定するために使用されます。
    • Compliance : Compliance タグは、AWS リソースのコンプライアンスレベルを指定するために使用されます。

  4. すべてのパラメータ値を入力したら、[Next] を選択します。
  5. 次の画面で、必要なタグ、IAM ロール、または詳細オプションを入力して、[Next] を選択します。
  6. 最後の画面で詳細を確認し、[I acknowledge that AWS CloudFormation might create IAM resources] のボックスにチェックを入れてから、[Create] を選択してネットワークリソースの構築を開始します。

スタックを作成するのに約 25 分かかります。このスタックは別の CloudFormation スタックを内部的に起動し、Secrets Manager が提供する Lambda 関数を設定します。これは Aurora PostgreSQL DB クラスターのマスターユーザーパスワードのローテーションに使用されます。AWS CloudFormation のリソースセクションを確認して、これらのスタックによって設定されたさまざまなコンポーネントの物理 ID を確認します。

それでは、Aurora PostgreSQL DB クラスターにログインし、いくつかの基本的なコマンドを実行しましょう。

Amazon Linux Bastion ホストを使用して Aurora DB クラスターにログインする

注意: 以下の手順では、Linux コンピュータがあり、SSH クライアントを使用して Bastion ホストに接続していることを前提としています。さまざまなクライアントを使用して接続する方法の詳細については、AWS のドキュメントを参照してください。

  1. (前提条件セクションで保存した) EC2 キーペアのプライベートキーを、SSH クライアントの Amazon Linux Bastion ホストに接続している場所に移動します。
  2. 次のコマンドを使用してプライベートキーのアクセス許可を変更し、公開されないようにします。 
    chmod 400 <プライベートキーのファイル名、例 apgbastion.pem>
  3. AWS コンソールの CloudFormation ダッシュボードに移動し、Amazon Linux Bastion ホストスタックを選択します。[Outputs] タブを選択し、Amazon Linux Bastion ホストへの SSH に使用する SSHCommand パラメータの値を書き留めます。
  4. SSH クライアントで、EC2 プライベートキーを保存した場所にディレクトリを変更してから、SSHCommand の値をコピーして、Amazon Linux Bastion ホストへの SSH に貼り付けます。
  5. AWS コンソールの AWS Secrets Manager ダッシュボードに移動します。Aurora PostgreSQL DB クラスターの CloudFormation スタック名と一致するシークレットの名前を、シークレットのリストから選択します。ページを下にスクロールして、[Retrieve secret value] を選択します。Aurora PostgreSQL データベースへのログインに使用する、[Secret key/value] の下にあるパスワードを書き留めます。
  6. CloudFormation ダッシュボードで、Aurora DB クラスタースタックを選択します。[Outputs] タブを選択し、psql クライアントを使用して Aurora PostgreSQL データベースにログインするために使用する PSQLCommandLine パラメータの値を書き留めます。
  7. PostgreSQL バイナリは、すでに EC2 Auto Scaling 起動設定によって Amazon Linux Bastion ホスト上に設定されています。Bastion ホストのコマンドプロンプトで、PSQLCommandLine の値をコピー/貼り付けします。 
    psql --host=ClusterEndpoint --port=Port --username=DBUsername --dbname=DBName

    プロンプトが表示されたら、上記の手順 5 でコピーしたマスターユーザーのパスワードを入力します。

  8. 以下に示すように基本的なコマンドを実行して、インストールされている拡張とデータベースを一覧表示します。データベースブートストラップスクリプトは、\dx コマンドを実行して確認できるように、pg_stat_statement および pgaudit 拡張を追加しました。

まとめ

このブログ記事では、AWS CloudFormation を使用して、AWS セキュリティと高可用性のベストプラクティスに基づいて Amazon Aurora PostgreSQL DB クラスターをデプロイする方法を紹介しました。サンプルの CloudFormation テンプレートが役立つものであり、ビジネスのニーズに合わせて変更して活用されることを願っています。また、AWS Lambda 関数を作成するために使用される Python ベースのデータベースブートストラップスクリプトを変更することも検討できます。その中に、Aurora PostgreSQL DB クラスターを設定した後に通常実行するすべての標準データベースコマンドを含めることができます。

Aurora DB クラスターを使用してアプリケーション関連のデータベースオブジェクトを設定する前に、以下を作成することを検討してください。

  • アプリケーションスキーマ。
  • アプリケーションスキーマ内のオブジェクトを作成および変更するための完全なアクセス許可を持つユーザー。
  • アプリケーションスキーマへの読み書きアクセス許可を持つユーザー。
  • アプリケーションスキーマへの読み取り専用アクセス許可を持つユーザー。

Aurora DB クラスターで設定されたマスターユーザーを使用して、DB クラスターだけを管理します。アプリケーションスキーマへの完全なアクセス許可を持つユーザーは、アプリケーション関連のデータベースオブジェクトの作成および変更に使用する必要があります。アプリケーションは、データの保存、更新、削除、取得に読み書きユーザーを使用する必要があります。どのような種類でも、レポートのアプリケーションでは読み取り専用ユーザーを使用する必要があります。必要なデータベース操作を実行するために必要な最小限の権限を付与することは、データベースセキュリティのベストプラクティスです。

AWS セキュリティのベストプラクティスに従って、AWS CloudTrail、AWS Config、Amazon GuardDuty サービスを確認し、それらを AWS アカウント用に設定します。これらのサービスを組み合わせることで、AWSリソースの設定の査定、監査、評価、悪意のある、または不正な行動を監視し、AWS リソースに対するセキュリティの脅威を検出するなど、AWS アカウントのアクティビティを監視できます。

このブログ記事の CloudFormation スタックによってデプロイされた AWS リソースの一部では、使用を終了しない限り、料金が発生します。不要になったスタックは削除します。スタックをクリーンアップするには、CloudFormation コンソールを使用して、作成した 3 つのスタックを逆の順序で削除します。

このブログ記事にご意見や質問がある場合は、下のコメント欄に自由に記入してください。

著者について

Arabinda Pani は、AWS パートナーデータベース専門ソリューションアーキテクトです。彼は、AWS を使用している場合にソリューションの価値を向上させる手助けとなるために、AWS のテクノロジーおよびコンサルティングパートナーと協力してデータベースプロジェクトに関する指導や技術支援を行っています。