はじめに
Amazon Web ServiceのRelational Database Service (RDS) は、その柔軟性と堅牢な機能セットにより、データベースホスティングの一般的な選択肢です。開発チームは、個人利用、ステージング環境、本番ワークロード向けに新しいデータベースをプロビジョニングし、AWSの他の製品スイートとシームレスに統合できます。
このガイドでは、Amazon RDSを使用して本番環境に対応できるPostgreSQLデータベースを構成する方法について説明します。作成プロセスにおける重要なオプション、トレードオフについて検討し、初期の本番デプロイメント向けに設計された、信頼性と堅牢性の高いデータベース設定を構成していきます。
Amazon Web ServiceのRDSを選ぶ理由
まず始める前に、AWSのRelational Database Serviceが多くのチームに適している理由について簡単に説明しましょう。
RDSはサービスとして2009年にMySQLデータベース向けの設定可能なマネージドサービスとして初めてリリースされました。PostgreSQLのサポートは2013年に追加され、新機能のリリースや追加のユースケースへの対応により、プラットフォームが安定し成熟するための十分な時間が与えられました。
RDSを魅力的な選択肢とする主な機能には、以下のものがあります。
- 物理的に離れた場所へのデプロイ（マルチアベイラビリティゾーン）: 物理的に異なるデータセンターにアクティブまたはスタンバイレプリカを作成し、地域ベースの停止が発生した場合の可用性と信頼性を向上させます。
- AWS IAMセキュリティモデルとの統合: 既存のアクセスコントロールとID機能を活用して、データベースとクライアントアプリケーション間の認証、認可、およびロールベースのアクセスポリシーを構成します。
- 設定可能なバックアップ、暗号化、モニタリング: プラットフォーム統合型のバックアップ、可観測性ツール、暗号化を利用して、データベースの維持運用コストを削減し一元化します。
- 使用量に応じたコスト: コストはデータベースの機能と使用量に直接結びついており、長期的なキャパシティプランニングにおける不確実性を軽減します。
これらのメリットを念頭に置いて、プロセスを確認するためにPostgreSQLデータベースインスタンスのセットアップを開始しましょう。
データベース作成プロセスの開始
まず、AWS認証情報を使用してAmazon Web Servicesコンソールにログインします。まだAWSにサインアップしていない場合は、サインアッププロセスに従って今すぐ行えます。
AWSコンソールホームから、サービス検索バーにrdsと入力してRDSサービスを探します。
Servicesの下にあるRDSをクリックして、Amazon RDSのメインページに移動します。
Create databaseセクションが表示されるまでスクロールし、Create databaseをクリックします。
データベース作成ページに移動し、そこで希望する設定を選択できます。
このガイドの残りの部分では、利用可能なさまざまなオプションを網羅し、本番環境対応の設定に関する提案を提供します。
標準PostgreSQLデプロイオプションの構成
RDS作成プロセスの最初の部分では、データベースエンジン、デプロイタイプ、基本構成など、新しいデータベースの基本的なプロパティだけでなく、データベースをどのように構成するかを決定します。始めましょう。
作成方法の構成
RDSで新しいデータベースをプロビジョニングする最初のステップは、作成方法を選択することです。
Easy createメソッドはいくつかの合理的なデフォルト設定を選択するのに役立ちますが、環境にとって重要なデータベースを構成する際に通常必要とされる柔軟性を提供しません。Standard createオプションは追加のオプションを提供し、それでも比較的短いプロセスです。
作成プロセスを完全に制御できるように、Standard createを選択してください。
PostgreSQLエンジンとバージョンの選択
次に、データベースエンジンを選択します。
このガイドではPostgreSQLデータベースを構成するため、PostgreSQLオプションを選択します。Amazon Auroraは、PostgreSQL互換の代替オプションであり、Amazon独自のスケーリングおよび管理機能を提供します。ただし、このガイドではPostgreSQLネイティブのデプロイに焦点を当てます。
使用したいPostgreSQLのバージョンを選択します。デフォルトで選択されているバージョンは通常安全な選択肢ですが、新しい機能のために最新リリースを選択したり、アプリケーションライブラリとの互換性に応じて古いリリースを選択したりすることもできます。
本番テンプレートの選択
次に、テンプレートを選択するよう求められます。
テンプレートは、一般的なデプロイシナリオに合わせた事前に選択されたオプションを提供することを目的としています。本番データベースをプロビジョニングするため、Productionテンプレートを選択します。
データベースの可用性の設定
次のセクションには、デプロイに関して行う必要がある最初の主要な決定事項が含まれています。それはデータベースの可用性と耐久性です。
このセクションでは、AWS環境内でデータベースがどのようにデプロイされるかを正確に決定します。これは、特定のインスタンスとAmazonインフラストラクチャにおける地域的な障害の両方に対して、セットアップがどの程度耐障害性を持つかに影響します。
利用可能なさまざまなオプション、それらが提供するもの、およびどのようなシナリオで役立つかを見てみましょう。このガイドでは、単一DBインスタンスを推奨しますので、他のオプションに興味がない場合はスキップしてください。
マルチAZ DBクラスター
最も安全で、最も堅牢で、最も高価な選択肢はMulti-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インスタンスクラスを選択するための一般的な提案
一般的に、ほとんどのリレーショナルデータベースのワークロードでは、CPUよりもRAMがより重要な要素となる傾向があります。このため、パフォーマンスが低いという懸念からバースト可能クラスを必ずしも軽視すべきではありません。これらは合理的なパフォーマンスを提供しつつ、最高の価値を提供します。
具体的には、2 vCPUと4 GiBのRAMを提供するdb.t3.mediumのようなインスタンスは、開始する多くのユースケースにとって良いベースライン選択です。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は割り当てられた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セキュリティグループがある場合を除き、新しい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キーを使用できます。
パフォーマンスインサイト
次に、インスタンスのパフォーマンスインサイトを構成します。
パフォーマンスインサイトは、RDSインスタンスのパフォーマンス問題をデバッグするのに役立つ機能です。デフォルトでは、インサイトデータは7日間無料で保持されます。代替として、CPUインスタンスタイプに応じて、追加費用で2年間の長期保存を選択することもできます。
繰り返しになりますが、特別な要件がない限り、この暗号化にはデフォルトのAWS KMSキーを選択したままで問題ありません。
モニタリングとログ
次に、データベースのモニタリングとログを構成できます。
一般的に、データベースインスタンスとそのパフォーマンスに関する可視性を高めるために、モニタリングを有効にすることをお勧めします。
ログのエクスポートについては、必要でない限りデフォルトで無効にしておくのが一般的です。アプリケーションログには通常、必要に応じてデータベース固有の情報が記録されますが、PostgreSQLのログエクスポートが役立つと感じた場合はいつでも有効にできます。ログはAWS CloudWatch Logsにエクスポートされます。
メンテナンスと削除保護
メンテナンスと削除保護セクションで追加設定が完了します。
PostgreSQLのマイナーバージョンを自動的にアップグレードすることは、通常安全であると考えられています。マイナーバージョンには破壊的変更がなく、アップグレードは比較的シームレスに行われるはずです。希望がある場合は、アップグレードウィンドウを選択してください。
本番データベースの削除保護を有効にすることは常に良いアイデアです。これにより、誤ってデータベースインスタンスを削除してしまうことを防ぎ、削除が正常に処理される前にこのオプションを元に戻す必要があります。ほとんどのユースケースにおいて、このオプションを無効にする合理的な理由はありません。
最終処理
ついに設定プロセスの終わりに到達しました。ページの下部には、設定されたデータベースインスタンスの月額コストの見積もりが表示されています。
見積もりの下にあるテキストには、表示されているコスト計算にはバックアップストレージ、I/O、またはデータ転送のコストが含まれていないことが改めて記載されていることに特に注意してください。これらの追加費用は、考慮されず制限されない場合、かなりの額になる可能性があるため、続行する前に追加料金の概念に納得していることを確認してください。
準備ができたら、ページ下部のデータベースを作成をクリックします。
データベースインスタンスは、構成に従ってプロビジョニングされます。選択したインスタンスのサイズや有効にしたオプションによっては、完了までに数分かかる場合があります。
インスタンスの準備が完了すると、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インスタンスを指すように設定することで、データベースインスタンスへのアクセスを構成します。
