はじめに
Amazon Web Service の Relational Database Service (RDS) は、その柔軟性と堅牢な機能セットにより、データベースホスティングの一般的な選択肢となっています。開発チームは、個人使用、ステージング環境、本番ワークロード用の新しいデータベースをプロビジョニングし、AWS の他の製品スイートとシームレスに統合できます。
このガイドでは、Amazon の RDS を使用して本番環境対応の PostgreSQL データベースを構成する方法について説明します。作成プロセスにおける重要なオプションについて説明し、トレードオフについて議論し、初期の本番環境デプロイメント向けに設計された信頼性が高く堅牢なデータベースセットアップを構成します。
Amazon Web Service の RDS を選ぶ理由
始める前に、AWS の Relational Database Service が多くのチームにとって適切な選択肢となる理由について簡単に説明しましょう。
RDS は、MySQL データベースの構成可能でマネージドサービスとして 2009 年に最初にリリースされました。PostgreSQL のサポートは 2013 年に追加され、プラットフォームが安定して成熟するのに十分な時間が与えられ、新しい機能がリリースされ、追加のユースケースが考慮されました。
RDS を魅力的なオプションにするコア機能のいくつかを以下に示します。
- 個別の物理ロケーションへのデプロイメント（マルチ AZ）：ロケーションベースの停止が発生した場合の可用性と信頼性を高めるために、物理的に異なるデータセンターにアクティブまたはスタンバイレプリカを作成します。
- AWS IAM セキュリティモデルとの統合：既存のアクセス制御と ID 機能を活用して、データベースとクライアントアプリケーション間の認証、認可、およびロールベースのアクセスポリシーを構成します。
- 構成可能なバックアップ、暗号化、およびモニタリング：プラットフォーム統合されたバックアップ、可観測性ツール、および暗号化を使用して、データベースの維持運用コストを削減および集中化します。
- 使用量に基づくコスト：コストはデータベースの機能と使用量に直接結び付けられており、長期的な容量計画に関する不確実性を軽減します。
これらの利点を念頭に置いて、プロセスを説明するために PostgreSQL データベースインスタンスの設定を開始しましょう。
データベース作成プロセスの開始
開始するには、AWS 認証情報を使用してAmazon Web Services コンソールにログインします。まだ AWS にサインアップしていない場合は、サインアッププロセスに従って今すぐサインアップできます。
AWS コンソールホームから、サービス検索バーに「rds」と入力して RDS サービスを見つけます
サービスの下のRDSをクリックして、Amazon RDS のメインページに移動します
データベースの作成セクションが表示されるまで下にスクロールし、データベースの作成をクリックします
データベース作成ページに移動し、そこで目的の構成を選択できます。
ガイドの残りの部分では、利用可能なさまざまなオプションについて説明し、本番環境対応の構成に関する提案を提供します。
標準的な PostgreSQL デプロイメントオプションの構成
RDS 作成プロセスの最初の部分では、データベースの構成方法と、データベースエンジン、デプロイメントタイプ、基本構成など、新しいデータベースの基本プロパティを決定します。始めましょう。
作成方法の構成
RDS で新しいデータベースをプロビジョニングする最初のステップは、作成方法を選択することです
簡易作成方法は、いくつかの妥当なデフォルトを選択するのに役立ちますが、環境にとって重要なデータベースを構成する場合に望ましい柔軟性のレベルを提供しません。標準作成オプションは追加のオプションを提供し、それでも比較的短いプロセスです。
作成プロセスを完全に制御できるように、標準作成を選択してください。
PostgreSQL エンジンとバージョンの選択
次に、データベースエンジンを選択します
このガイドでは、PostgreSQL データベースを構成するため、PostgreSQLオプションを選択します。Amazon Aurora は、Amazon 独自のスケールと管理機能を提供する、PostgreSQL 互換の代替オプションです。ただし、このガイドでは、PostgreSQL ネイティブデプロイメントに焦点を当てます。
使用する PostgreSQL のバージョンを選択します。デフォルトで選択されているバージョンは通常安全な選択ですが、新しい機能の場合は最新リリースを、アプリケーションライブラリとの互換性によっては古いリリースを選択することもできます。
本番環境テンプレートの選択
次に、テンプレートを選択するように求められます
テンプレートは、一般的なデプロイメントシナリオに一致する事前選択されたオプションを提供することを目的としています。本番データベースをプロビジョニングしているため、本番環境テンプレートを選択します。
データベースの可用性の設定
次のセクションには、デプロイメントに関して最初に行う必要のある重要な決定が含まれています。データベースの可用性と耐久性です
このセクションでは、データベースが AWS 環境内でどのようにデプロイされるかを正確に決定します。これは、特定インスタンスの障害と停止の両方、および Amazon インフラストラクチャの地域的な中断に対するセットアップの耐性に影響を与えます。
利用可能なさまざまなオプション、それらが提供するもの、およびそれらが役立つシナリオを見てみましょう。このガイドでは、単一 DB インスタンスをお勧めするため、他のオプションに関心がない場合は、先に進んでください。
マルチ AZ DB クラスター
最も安全で堅牢、そして最も高価なオプションは、マルチ AZ DB クラスターです。
これは、プライマリ DB インスタンスと 2 つの読み取り専用スタンバイレプリカで構成される PostgreSQL クラスターを構成し、それぞれ異なる物理ロケーションにデプロイします。このオプションは、障害が発生した場合のデータベースの停止を防ぎ、レプリカを介して利用可能な読み取りスループットを向上させるのに役立ちます。
そうは言っても、このオプションは非常にコストがかかります。異なるアベイラビリティーゾーンにデプロイされた 3 つの個別のデータベースインスタンスの料金を支払う必要があるためです。
データベースのダウンタイムが収益の著しい損失に直接つながる場合に、これは良いオプションとなる可能性があります。通常のデータベース使用パターンが読み取りヘビーである場合、読み取り IO の増加も注目に値します。これがユースケースに一致する場合は、最終的によりコストが低くなる可能性のある同様のレベルの可用性について、Amazon Aurora の評価を検討することもできます。
マルチ AZ DB インスタンス
このオプションは、アクティブなプライマリインスタンスとしてデータベースをデプロイし、異なるアベイラビリティーゾーンにスタンバイレプリカを配置します。スタンバイレプリカは最新の状態に保たれるため、プライマリインスタンスで中断が発生した場合、フェイルオーバーがトリガーされ、スタンバイがプライマリの責任を引き継ぐことができます。
上記のマルチ AZ DB クラスターとは対照的に、マルチ AZ DB インスタンスにはスタンバイレプリカが 1 つしかありません。さらに、スタンバイレプリカはスタンバイ容量にのみ使用できます。読み取り専用ワークロードはサポートされていません。
このオプションは、読み取りスループットの向上を必要とせずに、可用性の保護が必要な場合に適しています。2 つのデータベースインスタンスのコストを考慮する必要があるため、価格は単一インスタンスよりも高くなります。ダウンタイムが運用にとって非常にコストがかかる場合は、停止が発生した場合の可用性の低下を防ぐために、これが良いオプションとなる可能性があります。
単一 DB インスタンス
単一 DB インスタンスは、1 つのアベイラビリティーゾーン内での単一データベースの標準的なデプロイメントです。これは追加の可用性を提供しないため、データベースの可用性はデータベースインスタンスの稼働時間に直接結び付けられます。問題が発生した場合、データベースとその管理対象のすべてのデータは、サービスが復旧するまでアクセスできなくなります。
そうは言っても、このオプションは最も安価でもあります。デプロイメントは単一インスタンスで構成されているため、課金される追加のリソースはありません。
このオプションにはある程度のリスクが伴いますが、多くのユースケースでは、リスクは許容範囲であり、リスクを軽減するためのコストが高すぎます。Amazon RDS は、単一 AZ 内であっても、信頼性に関して優れた実績があるため、多くのユースケースでは、短期間のダウンタイムの可能性は許容範囲です。
このガイドでは、ダウンタイムに非常に敏感でない本番環境デプロイメントには十分であることが多いため、単一 DB インスタンスを選択します。ただし、収益と評判がデータベースの稼働時間と強く関連付けられている場合は、別の選択肢を検討することをお勧めします。
基本設定の構成
次のセクションでは、デプロイメントの基本設定を構成できます
まず、DB インスタンス識別子を設定して、データベースインスタンスに名前を付けることができます。AWS コンソールに表示されたときにデータベースの役割と目的を理解するのに役立つ一意の名前を選択します。
次に、データベースインスタンスの認証情報を構成します。まず、PostgreSQL データベースのマスターユーザー名を設定します。デフォルトでは、ほとんどの PostgreSQL クライアントツールは、マスターユーザーがpostgresと呼ばれていると想定しているため、適切であればそのユーザー名を保持できます。
注：マスターユーザー名は、PostgreSQL データベースインスタンス内のメインの管理者アカウントです。データベースインスタンスをプロビジョニングした後、特権が制限されたアプリケーション固有の追加のユーザー名を常に作成して構成する必要があります。データベースクライアントとアプリケーションが日常業務に特権の低い ID を使用するように構成します。最初の構成と、より制限された範囲の狭いアクセス手段を作成するためにのみ、マスターユーザー名を使用してください。
次に、マスターユーザー名のパスワードを設定して確認するオプションがあります。アカウントに強力なパスワード（できればマシン生成）を選択するか、パスワードを自動生成ボックスをオンにして、AWS にセキュアなパスワードを自動的に生成させることができます。
独自のパスワードを選択する場合は、後で取得できなくなるため、パスワードを安全な場所に保存してください。同様に、パスワードを自動生成する場合は、作成後に AWS コンソールで認証情報にアクセスする最初の時のみパスワードにアクセスできます。後で再度取得することはできないため、パスワードを安全に記録してください。
DB インスタンスクラスの選択
次に行う必要のある重要な決定は、DB インスタンスクラスです
基本的に、データベースのインスタンスクラスは、データベースがデプロイされる仮想マシンのサイズと、利用可能なリソースを決定します。選択するインスタンスのタイプと、各タイプ内のリソースの組み合わせには、いくつかの異なるオプションがあります。
インスタンスクラスの 3 つの主要なカテゴリは次のとおりです。
- 標準：これらには、AWS の EC2（Elastic Compute Cloud）インスタンスでおなじみの「m」クラスが含まれます。基本的に、これらは CPU とメモリの比率が妥当になるように設計された、バランスの取れた汎用インスタンスです。
- メモリ最適化：これらには、EC2 の「r」および「x」インスタンスクラスが含まれます。このカテゴリのインスタンスは、大量のデータセットを一度にメモリにロードするデータベース操作に役立つ、CPU に対するメモリの比率が高くなっています。
- バースト可能：これらのインスタンスは一般的に他のインスタンスよりもパフォーマンスが少し低いですが、多くのアプリケーションにとってスイートスポットを占めることができます。ベースライン CPU パフォーマンスは低いですが、スパイクに対応するためにより高いパフォーマンスのバーストを許可します。これにより、平均使用量を抑えながら、時折追加のワークロードを処理することができます。
選択するインスタンスクラスと、必要な特定のリソースの配置は、アプリケーションの使用パターンに大きく依存します。ただし、選択を支援するための一般的なガイダンスをいくつか提供できます。ニーズが変化した場合は、いつでもデータベースをスケールアップできることに注意してください。
DB インスタンスクラスの選択に関する一般的な提案
一般に、RAM はほとんどのリレーショナルデータベースワークロードで CPU よりも重要な要素になる傾向があります。このため、パフォーマンスが低いことを恐れてバースト可能なクラスを必ずしも割り引く必要はありません。それらは妥当なパフォーマンスを維持しながら、最高の価値のいくつかを提供します。
具体的には、db.t3.mediumのようなインスタンスは、2 つの vCPU と 4 GiB の RAM を提供し、始めたばかりの場合は多くのユースケースに適したベースライン選択です。CPU は、リクエストスパイクに対応しながら、中レベルのアクティビティを処理できるはずです。ハードウェアパフォーマンスがプロジェクトに適していると仮定すると、最初に直面する可能性のある制限の 1 つは、2,086 Mbps のネットワークキャップであるため、決定する際にそれを念頭に置いてください。
標準的なトラフィック量のデータベースで CPU パフォーマンスを向上させたい場合は、2〜4 個の vCPU と 8〜16 GiB の RAM を備えた標準クラスのインスタンスを検討してください。m6gインスタンスは、古いm5インスタンスよりも40％優れた価格対パフォーマンス比を持つと宣伝されているため、標準インスタンスを検討する場合は、多くの場合、より良い選択肢となります。それを念頭に置いて、db.m6g.largeおよびdb.m6g.xlargeインスタンスは、このインスタンスクラスタイプに適した初期選択肢です。
メモリ最適化されたデータベースインスタンスは、大量のデータセットをメモリにロードする必要があることがわかっている場合に主に役立ちます。これは、テーブルに多数のレコードが含まれている場合や、多数の列を頻繁にクエリする場合などが該当します。PostgreSQL の JSON 列を頻繁に使用する場合は、これを検討する価値があるかもしれません。そうは言っても、より標準的な構成から始めて、これらのリソースが十分でないことが判明した場合はインスタンスクラスを変更する方が良いことがよくあります。
ストレージオプションの構成
次に、データベースインスタンスのストレージを構成する必要があります
ストレージタイプの選択
RDS は、さまざまなシナリオに適した 3 つの異なるタイプのストレージを提供します
- 汎用 SSD (gp2)：これは標準的なソリッドステートドライブの選択です。ストレージデバイスで使用可能な IOPS（1 秒あたりの入出力操作数）は、割り当てるスペースのサイズに直接結び付けられています。ベースライン IOPS は割り当てられた 1 GiB あたり 3 IOPS に設定されており、短時間で 3,000 IOPS にバーストする機能があります。
- プロビジョニングされた IOPS SSD (io1)：このオプションを使用すると、ストレージ容量をデータベースに割り当てられた IOPS から分離できます。
- 磁気：磁気ストレージは、SSD の代わりに従来の回転ディスクを使用します。
一般に、汎用 SSDオプションから始めるのがほぼ常に最善です。これにより、必要な容量を設定し、SSD にデータベースをデプロイできます。磁気オプションは速度が遅く、1000 IOPS に制限されているため、優れた選択肢となることはめったにありません。
プロビジョニングされた IOPS SSD は、アプリケーションのプロファイリングをかなり堅牢に実行し、さまざまなワークロードで環境が生成する IOPS の量を十分に把握している場合に適しています。これは、キャッシングや、ドライブに実際にヒットする操作の量を減らすことができるその他のメカニズムにより、予想よりも低い数値になる傾向もあります。一般的に、これは、時間の経過とともに正確な構成を実行した経験が得られたら適切になる可能性がある高度な選択肢と考えてください。
初期ストレージ容量の選択
ストレージタイプを選択したら、割り当てるストレージ容量を選択します。これもアプリケーションに大きく依存します。ただし、一般的に、人々は最初に必要となるスペースの量を過大評価する傾向があります。最初は低く始めて、いつでもスケールアップできることを覚えておいてください。
自動スケーリングの構成
次に、自動スケーリングを有効にするかどうかを選択します。このオプションを使用すると、ストレージ容量を使用量に応じて自動的にスケーリングできます。これは一般的に良い考えです。これにより、より手頃な価格でより小さな初期割り当てから開始し、データが増加するにつれてストレージ容量を自動的に増やすことができます。快適にスケーリングできる最大サイズを超えてスケーリングしないように、最大スケーリング量を構成できます。
一般的に、初期割り当てとして 20〜100 GiB（多くの場合、十分な IOPS を提供するものによって異なります）から始めるだけで十分であり、最大ストレージしきい値を支払う意思のある最大サイズに設定することがよくあります。
接続戦略の決定
ストレージを構成した後、次に行う必要のある重要な決定は、データベースの接続に関してです
このセクションには、AWS のセキュリティおよびネットワークモデルに精通していない場合は混乱する可能性のある多くの異なるオプションが含まれています。
本番環境に適したデプロイメントのためにここで推奨する一般的な戦略は、既存のオプションを再利用するのではなく、使用可能な各オプションの新しいインスタンスを作成することです。アプリケーションがすでに実行されている既存の環境にデータベースをデプロイする場合は、この戦略を調整する必要があるかもしれませんが、一般的なルールは、新しいデプロイメントに最も分離され安全なアプローチを提供します。
VPC の構成
データベースをデプロイするVirtual Private Cloud (VPC)を選択するよう求められた場合、通常は新しいVPC、またはデータベースにアクセスするアプリケーションを含むVPCにデプロイすることをお勧めします。デフォルトVPCへのデプロイは、デフォルトのネットワーク環境に対する変更がデータベースに影響を与える可能性があるため、通常は推奨されません。
サブネットグループの選択
次に、サブネットグループを選択する必要があります。これは、データベースをデプロイできるVPC内のIP範囲を定義します。一般的に、ここでも新しいグループを作成することをお勧めします。
パブリックアクセスを許可するかどうかの決定
最も重要な選択肢の1つは、データベースインスタンスへのパブリックアクセスを許可するかどうかです。これは主に、セキュリティ要件と、データベースへの特別なアクセスを設定する能力によって大きく左右されます。
最も安全なアプローチは、パブリックアクセスをオフにすることです。これにより、データベースと同じネットワーク環境内にデプロイされたインスタンス（またはそれらを経由するインスタンス）のみがデータベースにアクセスできるようになります。外部からデータベースにアクセスするには、ジャンプホストまたはインターネットゲートウェイを構成して、外部接続を認証し、データベースにルーティングする必要があります。インフラストラクチャの構成やネットワークルールの管理に慣れていない場合、これはかなりの作業になる可能性があります。
もう1つのアプローチは、パブリックアクセスを許可することです。これにより、データベースインスタンスはパブリックインターネットからアクセスできるようになります。誰でもデータベースへの接続を試みることができるため、セキュリティは低下しますが、外部接続からのアクセスモデルが簡素化されます。このオプションを選択する場合は、すべてのデータベースパスワードが非常に強力であり、頻繁にローテーションされていることを確認してください。ログにサービスへの外部からのアクセス試行が記録される可能性が高いため、パスワードの強度が非常に重要になります。
パブリックアクセスを有効にするかどうかの選択は、最初に思われるよりも複雑です。パブリックアクセスを有効にしても、特定の外部IPアドレスのセットへのアクセスをロックダウンし、不正な接続試行をフィルタリングするための他の構成ポイントを提供できます。一般的に、長期にわたってサポートできる最も安全な構成を選択するのが最善です。
VPCセキュリティグループの選択
VPCセキュリティグループは、内部にデプロイされたインスタンスへの接続に使用されるアクセスルールを制御します。これらは基本的にファイアウォールのようなアクセスコントロールポリシーであり、データベースインスタンスへの接続の種類を制限するのに役立ちます。
本番データベース用にすでに構成済みのものがない限り、新しいVPCセキュリティグループを作成します。AWSコンソールに表示されたときに、セキュリティグループの焦点と役割を思い出すのに役立つ名前を選択してください。
アベイラビリティーゾーンとポートの選択
データベースインスタンスをデプロイするリージョン内のアベイラビリティーゾーンを選択できます。特に希望がない場合は、「優先なし」を選択しても問題ありません。
「追加設定」オプションを開くと、PostgreSQLがリッスンするポートをオプションで変更できます。これを変更すると、オープンインスタンスの接続ログの不要なログ出力をある程度軽減できますが、セキュリティが大幅に向上するわけではなく、接続が面倒になる可能性があります。
データベース認証の設定
次に、データベースインスタンスに使用する認証のタイプを選択する必要があります。
選択肢は以下のとおりです。
- パスワード認証：PostgreSQLのネイティブ機能を使用した標準的なパスワード認証。
- パスワードおよびIAMデータベース認証：PostgreSQLのネイティブパスワード機能と、AWS IAMロールを使用した認証の両方を使用します。データベースパスワードの代替として、IAM認証トークンを使用してデータベースインスタンスを認証するオプションがあります。
- パスワードおよびKerberos認証：PostgreSQLのネイティブパスワード機能と、AWS Directory Serviceを使用して作成されたAWS Managed Microsoft Active Directoryインスタンスの両方を使用します。組織がすでにAWSマネージドADインスタンスを使用している場合、これによりチケットを通じてKerberosスタイルの認証を使用できます。
一般的に、より複雑な構成が必要な場合を除き、パスワード認証を使用するのが妥当です。AWSエコシステムと、インフラストラクチャの他の多くの部分に対するIAMベースの認証に大きく投資している場合は、IAMデータベースオプションが魅力的な場合があります。他の目的でそのサービスをすでに使用している場合を除き、Kerberosオプションを選択する価値はありません。
バックアップ、暗号化、モニタリングなどの設定
追加設定セクションを展開すると、いくつかの追加オプションを構成できます。このセクションでは、それらについて説明します。
データベースオプション
最初の追加セクションでは、PostgreSQLの追加オプションを構成できます。
必要に応じて、RDSに初期データベースをデプロイメント用に自動的に作成させることができます。通常、これは不要です。実行する移行やその他のセットアップスクリプトは、通常、インスタンス内に必要なデータベース構造を作成するためです。
また、インスタンスのDBパラメータグループを選択できる場合もあります。ここでの複数の選択肢は、以前に行った選択や、作成プロセス外でパラメータグループを構成したかどうかによって利用できない場合があります。存在する場合、これらを使用すると、このインスタンスに適用されるPostgreSQLパラメータを変更できます。
PostgreSQLはオプショングループをサポートしていないため、そのドロップダウンはアクティブになりません。
バックアップ
次に、自動データベースバックアップに関連付けられたオプションを構成できます。
自動バックアップを有効にする場合は、自動バックアップを有効にするボックスを選択します。これにより、AWSはデータベースインスタンスの毎日のポイントインタイムスナップショットを自動的に作成し、復元に使用できるようになります。このページには記載されていませんが、バックアップはAWSのSimple Storage Service（S3）に保存され、消費したスペースに対して課金されることに注意してください。
デフォルトでは、バックアップは7日間の保持期間で設定されています。つまり、過去7日間に取得されたデータベースのスナップショットを復元できます。この機能を使用している場合は、保持期間を14日に増やして、不要な変更を把握するための時間を増やすことをお勧めします。ただし、保持期間を長くすると、追加のストレージのコストが増加することに注意してください。
バックアップが発生する時間帯に希望がある場合は、適切な時間帯を選択できます。それ以外の場合は、「優先なし」のままにしても安全です。
S3内で適切なスナップショットを見つけやすくするために、「スナップショットにタグをコピー」を選択したままにします。
追加の保護が必要な場合は、バックアップレプリケーションを選択して、変更を別のAWSリージョンに自動的にレプリケートすることもできます。これにより、別のリージョンからすばやく復元できますが、S3ストレージコストとデータ転送料金が増加します。
暗号化
次に、データベースインスタンスのディスク上の暗号化を構成できます。
追加のセキュリティのために、インスタンスの暗号化を有効にすることをお勧めします。
一般的に、別のAWSアカウントで使用されているキーへの暗号化など、追加の要件がない限り、デフォルトのAWS KMSキーを使用できます。
Performance Insights
次に、インスタンスのPerformance Insightsを構成します。
Performance Insightsは、RDSインスタンスのパフォーマンス問題をデバッグするのに役立つ機能です。デフォルトでは、Insightsデータは7日間無料で保持されます。CPUインスタンスタイプに応じて、追加料金で2年間の長期ストレージを選択することもできます。
ここでも、特別な要件がない限り、この暗号化にはデフォルトのAWS KMSキーを選択したままにできます。
モニタリングとログ
次に、データベースのモニタリングとログを構成できます。
一般的に、モニタリングを有効にすると、データベースインスタンスとそのパフォーマンスをより詳細に把握できるため、役立ちます。
ログのエクスポートに関しては、通常、不要な場合はデフォルトで無効にしても安全です。アプリケーションログは通常、必要に応じてデータベース固有の情報を表面化させますが、PostgreSQLログのエクスポートが役立つ場合はいつでも有効にできます。ログはAWS CloudWatch Logsにエクスポートされます。
メンテナンスと削除保護
メンテナンスおよび削除保護セクションで、追加設定は完了です。
通常、PostgreSQLのマイナーバージョンを自動的にアップグレードしても安全であると考えられています。マイナーバージョンには破壊的な変更はなく、アップグレードは比較的シームレスに実行されるはずです。希望があれば、アップグレードウィンドウを選択してください。
本番データベースの削除保護を有効にすることをお勧めします。これにより、削除が正常に処理される前にこのオプションを元に戻す必要があるため、データベースインスタンスを誤って削除することを防ぎます。ほとんどのユースケースで、このオプションをオプトアウトする合理的な理由はありません。
完了
これで構成プロセスの最後に到達しました。ページの下部には、構成されたデータベースインスタンスの月額費用の見積もりが表示されます。
表示されるコスト計算には、バックアップストレージ、IO、またはデータ転送料金が含まれていないことを繰り返す、見積もりの下のテキストに特に注意してください。これらの追加コストは、考慮および制限されていない場合、かなりの金額になる可能性があるため、続行する前に追加料金の概念に納得していることを確認してください。
準備ができたら、ページの下部にあるデータベースの作成をクリックします。
データベースインスタンスは、構成に従ってプロビジョニングされます。選択したインスタンスのサイズと有効にしたオプションによっては、完了までに数分かかる場合があります。
インスタンスの準備が完了すると、RDSダッシュボードのデータベースセクションに表示されます。
自動生成されたパスワードの表示
AWSにパスワードを自動生成するように構成した場合、画面の上部にこのような通知が表示されます。
認証情報の詳細を表示をクリックして、パスワードを確認します。
これがこのパスワードにアクセスできる唯一の機会であり、紛失した場合は再生成する必要があることに注意してください。
その他の接続情報の表示
残りの接続情報については、インスタンス名をクリックします。
接続とセキュリティタブの左側で、データベースのエンドポイントとポート番号を確認できます。
この例では、エンドポイント名（ホストのURL）はproduction-db1.cddm7tgh3j5j.us-east-1.rds.amazonaws.comであり、データベースはPostgreSQLの標準ポートである5432でリッスンしています。
構成したマスターユーザー名（変更していない場合はpostgresになります）を見つけるには、構成タブにアクセスし、可用性見出しの下にあるマスターユーザー名フィールドを探します。
初期データベースの名前を構成した場合、同じタブの左側にも名前が表示されます。
この情報を使用して、PostgreSQLインスタンスに接続できます。例として、ここに表示されているインスタンスに接続するには、次の接続URIを使用できます。
接続の詳細から接続URIを構築する方法の詳細については、PostgreSQL接続URIに関するガイドを参照してください。
結論
このガイドでは、AmazonのRDSマネージドデータベースサービスを使用して、本番環境に適したPostgreSQLデータベースインスタンスを作成する方法について説明しました。検討すべきオプションはたくさんあり、選択はプロジェクトと環境のニーズによって異なりますが、ここでは妥当な出発点と、情報に基づいた意思決定を行うのに十分な情報を提供しようと試みました。
ニーズが変化した場合は、新しい使用パターンに対応するためにデータベースインスタンスをスケールできることを覚えておいてください。モニタリング情報とスケーリングログから収集したデータを使用して、データベースのニーズがどのように進化しているかを判断してください。
Amazon RDSでPostgreSQLインスタンスを構成したら、Prisma Clientを使用して接続および管理できます。PostgreSQLデータベースコネクタ設定のurlパラメータをRDSインスタンスを指すように設定して、データベースインスタンスへのアクセスを構成します。
