💡
AWS学びなおし(+TF)_RDS

2025/02/25に公開
AWS RDS (Relational Database Service) とは
AWS RDSは、クラウド上でリレーショナルデータベース (RDB) を簡単にセットアップ、運用、スケールできるマネージドサービスです。従来のオンプレミス環境でRDBを運用する場合に必要となる、サーバーの調達、OSやDBソフトウェアのインストール、バックアップ、パッチ適用、監視などの煩雑な作業をAWSが代行してくれます。ユーザーは、アプリケーション開発やデータ分析といった本来の業務に集中できます。
RDSの主なメリット

運用管理の簡素化:  DBのインストール、設定、バックアップ、パッチ適用、監視などの運用タスクをAWSが自動化します。これにより、運用コストと手間を大幅に削減できます。

高い可用性と耐久性:  Multi-AZ構成 (可用性ゾーンを跨いだ冗長構成) を容易に構築でき、計画停止や障害発生時にもサービスを継続できます。バックアップ機能と組み合わせることで、データの耐久性も向上します。

容易なスケーラビリティ:  数クリックでDBインスタンスのスペック (CPU、メモリ、ストレージ) をスケールアップ/ダウンできます。リードレプリカ (読み取り専用のDBインスタンス) を作成することで、読み取り処理の負荷分散とスケーラビリティ向上が可能です。

多様なDBエンジンに対応:  MySQL、PostgreSQL、SQL Server、Oracle、MariaDB、Aurora (MySQL/PostgreSQL互換) といった主要なRDBエンジンをサポートしており、要件に合わせて最適なエンジンを選択できます。

セキュリティ機能:  VPC (Virtual Private Cloud) 内での隔離、セキュリティグループによるアクセス制御、保存時/転送時の暗号化、IAM (Identity and Access Management) によるアクセス管理など、多層的なセキュリティ機能を提供します。

コスト効率:  従量課金制で、使用した分だけ料金が発生します。長期利用の場合は、リザーブドインスタンス (RI) や Savings Plans を利用することで大幅な割引が適用されます。
RDSで利用できるDBエンジン

MySQL: オープンソースで最も人気のあるRDBの一つ。Webアプリケーションなどで幅広く利用されています。

PostgreSQL: オープンソースで高機能なRDB。拡張性が高く、複雑なデータ型や高度な機能が利用できます。

SQL Server: Microsoft社が提供する商用RDB。Windows環境との親和性が高く、エンタープライズ用途で広く利用されています。

Oracle: Oracle社が提供する高性能な商用RDB。大規模システムやミッションクリティカルなシステムで利用されています。

MariaDB: MySQLから派生したオープンソースRDB。MySQLとの互換性が高く、性能や機能が向上しています。

Aurora (MySQL/PostgreSQL互換): AWSが開発したMySQLおよびPostgreSQL互換の高性能RDB。標準的なMySQL/PostgreSQLと比較して、パフォーマンス、可用性、耐久性が大幅に向上しています。
RDSの主要機能

ストレージ:  汎用SSD (gp2/gp3)、プロビジョンドIOPS SSD (io1/io2)、マグネティック (standard) のストレージタイプを選択できます。用途に合わせて最適なストレージを選択することで、パフォーマンスとコストを最適化できます。ストレージの自動拡張機能も利用可能です。

バックアップ:  自動バックアップ (指定した期間内のポイントインタイムリカバリが可能) と手動バックアップ (スナップショット) が利用できます。バックアップデータはS3に安全に保管され、災害対策としても有効です。

可用性:  Multi-AZ構成を有効にすることで、プライマリDBインスタンスに障害が発生した場合でも、自動的にスタンバイDBインスタンスにフェイルオーバーし、サービスを継続できます。

セキュリティ:  VPC、セキュリティグループ、IAM、暗号化 (保存時/転送時)、監査ログなど、多岐にわたるセキュリティ機能を提供します。

監視:  CloudWatchメトリクス、Performance Insights、拡張モニタリングなどの機能を利用して、DBインスタンスのパフォーマンスや状態を詳細に監視できます。

メンテナンス:  定期的なメンテナンス (パッチ適用、マイナーバージョンアップグレードなど) は、ユーザーが指定したメンテナンスウィンドウ内で行われます。

スケーリング:  インスタンスタイプ (CPU、メモリ)、ストレージ、リードレプリカなどを容易にスケールアップ/ダウン/アウトできます。

パラメータグループ:  DBエンジンの設定パラメータを管理するパラメータグループを利用して、DBインスタンスの動作を細かく制御できます。

オプショングループ:  DBエンジンに追加機能 (拡張機能やユーティリティ) を提供するオプショングループを利用できます。
RDSの料金体系
RDSの料金は、主に以下の要素で構成されます。

DBインスタンス時間:  DBインスタンスの実行時間に応じて課金されます。インスタンスタイプによって料金が異なります。

ストレージ:  使用したストレージ容量に応じて課金されます。ストレージタイプによって料金が異なります。

IOリクエスト:  プロビジョンドIOPS SSD (io1/io2) ストレージの場合、IOリクエスト数に応じて課金されます。

バックアップストレージ:  自動バックアップおよび手動バックアップのストレージ容量に応じて課金されます (無料枠あり)。

データ転送料金:  リージョンを跨いだデータ転送や、インターネットへのデータ転送に対して課金されます。
リザーブドインスタンス (RI) や Savings Plans を利用することで、DBインスタンスの利用料金を大幅に削減できます。
RDSのユースケース
RDSは、リレーショナルデータベースを必要とする幅広いアプリケーションで利用できます。

Webアプリケーション:  ECサイト、ブログ、SNSなど、多くのWebアプリケーションのバックエンドDBとして利用されています。

モバイルアプリケーション:  モバイルアプリのユーザーデータやアプリ設定などを保存するDBとして利用されています。

業務システム:  顧客管理システム (CRM)、販売管理システム、人事管理システムなど、企業の基幹業務システムで利用されています。

コンテンツ管理システム (CMS):  WordPress、DrupalなどのCMSのバックエンドDBとして利用されています。

分析/レポート:  BIツールやレポーティングツールからアクセスするデータウェアハウスやデータマートとして利用されています。
RDS導入から運用までの流れ (概要)

要件定義:  必要なDBエンジン、スペック、ストレージ容量、可用性、セキュリティ要件などを明確にします。

設計:  VPC、サブネット、セキュリティグループ、パラメータグループ、オプショングループなどのネットワーク構成やDB設定を設計します。

構築:  AWSマネジメントコンソール、AWS CLI、TerraformなどのIaCツールを利用してRDSインスタンスを構築します。

テスト:  構築したRDSインスタンスに対して、性能テスト、負荷テスト、フェイルオーバーテストなどを実施し、要件を満たしているか確認します。

移行 (既存システムからの移行の場合):  データ移行ツール (AWS DMSなど) や手動でデータを移行します。

運用:  監視、バックアップ、パッチ適用、パフォーマンスチューニングなどの運用タスクを実施します。

改善:  運用状況やビジネス要件の変化に合わせて、RDSインスタンスの構成や設定を見直し、最適化します。
他のDBサービスとの比較 (EC2上のDB, Aurora, DynamoDBなど)

EC2上のDB:  OSやDBソフトウェアのインストールから運用まで全てをユーザー自身で行う必要があります。柔軟性は高いですが、運用負荷も大きくなります。

Aurora:  RDSの一種ですが、MySQL/PostgreSQL互換で、パフォーマンス、可用性、耐久性が大幅に向上しています。高パフォーマンスを求めるシステムに適しています。

DynamoDB:  NoSQLデータベースサービス。RDBとは異なり、スキーマレスで柔軟なデータモデルを持ち、高速な読み書き性能が特徴です。大量のアクセスを処理するWebアプリケーションやモバイルアプリに適しています。

ElastiCache:  インメモリキャッシュサービス。頻繁にアクセスされるデータをキャッシュすることで、アプリケーションのパフォーマンスを向上させます。RDSと組み合わせて利用されることが多いです。
RDSは、RDBをマネージドサービスとして利用したい場合に最適な選択肢です。運用負荷を軽減し、可用性、スケーラビリティ、セキュリティを確保しながら、RDBのメリットを最大限に活用できます。

 【実務レベルの内容と重要事項】運用・保守

監視:  CloudWatchメトリクス、Performance Insights、拡張モニタリングなどを活用し、CPU使用率、メモリ使用率、ストレージ使用率、IOPS、レイテンシ、接続数、エラーログなどを継続的に監視します。異常を検知したら、アラート通知を設定し、迅速に対応できるようにします。

バックアップ・リストア:  自動バックアップ設定を確認し、リストアに必要な期間 (バックアップ保持期間) を適切に設定します。定期的に手動バックアップ (スナップショット) を取得し、リストア手順を検証します。災害対策として、クロスリージョンバックアップも検討します。

パフォーマンスチューニング:  ス slow query log などを分析し、実行計画の見直し、インデックスの最適化、クエリの書き換えなどを行います。Performance Insights を活用して、ボトルネックとなっているクエリや処理を特定し、改善します。パラメータグループを調整することで、DBインスタンスの動作をチューニングできます。

障害対応:  障害発生時の対応手順 (フェイルオーバー確認、ログ調査、原因特定、復旧作業など) を事前に定義し、訓練を実施します。AWSサポートとの連携体制も構築しておきます。

アップグレード/パッチ適用:  DBエンジンのバージョンアップグレードやパッチ適用は、計画的に実施します。事前に検証環境で動作確認を行い、問題がないことを確認してから本番環境に適用します。メンテナンスウィンドウを考慮し、サービス影響を最小限に抑えるようにします。

キャパシティプランニング:  DBのデータ量増加、トランザクション数増加などを予測し、将来のDBリソース (インスタンスタイプ、ストレージ) の増強計画を立てます。
セキュリティ

VPC:  RDSインスタンスはVPC内に作成し、インターネットからの直接アクセスを遮断します。パブリックサブネットではなく、プライベートサブネットに配置します。

セキュリティグループ:  RDSインスタンスへのアクセスを許可するIPアドレス範囲やポート番号をセキュリティグループで厳密に制御します。不要なポートは閉じ、最小限のアクセス許可のみを設定します。

IAM:  IAMロールを利用して、RDSインスタンスへのアクセス権限をユーザーやアプリケーションに付与します。最小権限の原則に従い、必要な権限のみを付与します。

暗号化:  保存時の暗号化 (Storage Encryption) と転送時の暗号化 (SSL/TLS) を有効にします。機密データを扱う場合は、AWS KMS (Key Management Service) で暗号化キーを管理することを検討します。

監査ログ:  監査ログ (SQL Server Audit Log, Oracle Audit Trail, MySQL/PostgreSQL Audit Log) を有効にし、DB操作の証跡を記録します。CloudWatch Logs や S3 にエクスポートし、長期保管と分析を行います。
可用性・冗長性

Multi-AZ構成:  本番環境では、必ず Multi-AZ 構成を有効にし、可用性を高めます。計画停止や障害発生時にもサービスを継続できるようにします。

リードレプリカ:  読み取り負荷が高いシステムでは、リードレプリカを作成し、負荷分散を行います。リードレプリカは、災害対策としても利用できます (クロスリージョンリードレプリカ)。

フェイルオーバーテスト:  定期的にフェイルオーバーテストを実施し、Multi-AZ 構成が正常に機能することを確認します。
パフォーマンス

インスタンスタイプ選定:  ワークロードに合わせて適切なインスタンスタイプ (CPU、メモリ) を選択します。最初は小さめのインスタンスタイプから始め、必要に応じてスケールアップすることを検討します。

ストレージタイプ選定:  ワークロードのIO特性に合わせて、汎用SSD (gp2/gp3)、プロビジョンドIOPS SSD (io1/io2) などのストレージタイプを選択します。IOPS性能が求められる場合は、プロビジョンドIOPS SSD を検討します。

パラメータグループ:  ワークロードに合わせてパラメータグループをチューニングします。バッファサイズ、キャッシュサイズ、コネクション数などを調整することで、パフォーマンスを改善できます。

クエリチューニング:  実行時間の長いクエリや負荷の高いクエリを特定し、インデックスの最適化、クエリの書き換えなどを行います。

コネクションプーリング:  アプリケーション側でコネクションプーリングを実装し、DBへのコネクション確立/切断のオーバーヘッドを削減します。
拡張性・スケーラビリティ

リードレプリカ:  読み取り負荷の増大に対応するために、リードレプリカを追加します。

垂直スケーリング (スケールアップ/ダウン):  DBインスタンスのスペック (インスタンスタイプ) を変更することで、CPU、メモリを増強/削減します。

水平スケーリング (シャーディング):  大規模なデータやトランザクションを処理する必要がある場合は、DBシャーディング (パーティショニング) を検討します (アプリケーション側の対応が必要)。
DR/BCP (災害復旧/事業継続計画)

バックアップ:  定期的なバックアップ (自動バックアップ、手動バックアップ) を取得し、S3 に安全に保管します。クロスリージョンバックアップも検討します。

Multi-AZ構成:  Multi-AZ 構成により、リージョン内のAZ障害に対する耐性を高めます。

リードレプリカ (クロスリージョン):  クロスリージョンリードレプリカを作成することで、リージョン全体の災害に対する耐性を高めます。

DR訓練:  定期的にDR訓練を実施し、災害発生時の復旧手順を確認します。
コスト最適化

リザーブドインスタンス (RI)/Savings Plans:  長期利用が前提の場合は、リザーブドインスタンス (RI) や Savings Plans を利用することで、DBインスタンスの利用料金を大幅に削減できます。

適切なインスタンスタイプ選定:  ワークロードに対して過剰なスペックのインスタンスタイプを使用しないように、適切なインスタンスタイプを選択します。

不要なインスタンスの停止:  開発環境やステージング環境など、常時稼働させる必要のないインスタンスは、使用しない時間帯は停止することでコストを削減できます。

ストレージの最適化:  不要なデータを削除したり、アーカイブしたりすることで、ストレージ使用量を削減します。ストレージタイプをワークロードに合わせて最適化します。

リードレプリカの活用:  読み取り専用の処理をリードレプリカにオフロードすることで、プライマリDBインスタンスの負荷を軽減し、インスタンスタイプをスケールダウンできる可能性があります。
監視・モニタリング

CloudWatchメトリクス:  基本的なDBインスタンスのメトリクス (CPU使用率、メモリ使用率、ストレージ使用率、IOPS、レイテンシなど) を監視します。

Performance Insights:  DBの負荷状況を詳細に分析し、ボトルネックとなっているクエリや処理を特定します。

拡張モニタリング:  OSレベルのメトリクス (CPU負荷、メモリ使用量、ディスクI/Oなど) を収集し、より詳細なパフォーマンス分析を行います。

CloudWatch Logs:  DBログ (エラーログ、スロークエリログ、監査ログなど) を CloudWatch Logs にエクスポートし、ログの監視、分析、長期保管を行います。

アラート設定:  CloudWatchアラームを設定し、異常が発生した場合に通知を受け取れるようにします (例: CPU使用率が一定値を超えた場合、ストレージ使用率が閾値を超えた場合など)。
実務レベルでは、これらの項目を総合的に考慮し、システムの要件、可用性、パフォーマンス、セキュリティ、コストなどをバランス良く最適化していくことが重要です。

 【実務でどの程度使用されるのか】AWS RDS は、実務で非常に広く利用されています。 多くの企業や組織が、Webアプリケーション、モバイルアプリケーション、業務システムなど、様々なシステムのデータベースとして RDS を採用しています。
利用頻度:
RDS は、AWS のマネージドサービスの中でも、EC2 (仮想サーバー) や S3 (オブジェクトストレージ) と並んで、最も利用頻度の高いサービスの一つと言えます。特に、リレーショナルデータベースを必要とするシステムにおいては、RDS が第一の選択肢となることが多く、新規システムの構築だけでなく、既存システムのクラウド移行においても RDS が積極的に採用されています。
どのような場面で使用されるか:
RDS は、以下のような様々な場面で利用されています。

WebサービスのバックエンドDB:  ECサイト、ブログ、SNS、メディアサイト、予約システムなど、多くのWebサービスのユーザーデータ、商品情報、コンテンツ情報などを格納するDBとして利用されています。

モバイルアプリのバックエンドDB:  モバイルアプリのユーザー認証情報、アプリ設定、ゲームデータなどを保存するDBとして利用されています。

業務システム (基幹システム含む):  顧客管理システム (CRM)、販売管理システム、在庫管理システム、人事管理システム、会計システムなど、企業の基幹業務を支えるDBとして利用されています。

コンテンツ管理システム (CMS) のバックエンドDB:  WordPress、Drupal、Contentful などの CMS のコンテンツデータ、ユーザーデータ、設定情報などを格納するDBとして利用されています。

分析基盤/データウェアハウス (DWH):  RDS をデータマートとして利用したり、Aurora PostgreSQL を DWH として利用したりするケースもあります。大規模な DWH には、Amazon Redshift などの専用サービスがより適している場合があります。

開発/テスト環境:  開発環境やテスト環境のDBとして、RDS を迅速かつ容易に構築できます。必要な時だけ起動し、不要になったら停止することで、コストを抑えることも可能です。
なぜRDSが選ばれるのか:
RDS が実務で広く利用される理由は、主に以下の点が挙げられます。

マネージドサービスであることのメリット:  DBの運用管理 (インストール、設定、バックアップ、パッチ適用、監視など) をAWSに任せられるため、運用負荷を大幅に削減できます。人的リソースをアプリケーション開発など、より重要な業務に集中させることができます。

高い可用性と信頼性:  Multi-AZ 構成や自動バックアップ機能により、高い可用性とデータ耐久性を実現できます。ビジネス継続性を重視するシステムにとって、重要なメリットです。

容易なスケーラビリティ:  数クリックでDBインスタンスのスペックやストレージをスケールアップ/ダウンでき、リードレプリカによる読み取り負荷分散も容易です。ビジネスの成長やトラフィックの変動に柔軟に対応できます。

多様なDBエンジンに対応:  MySQL、PostgreSQL、SQL Server、Oracle、MariaDB、Aurora といった主要なRDBエンジンをサポートしており、既存システムからの移行や、新規システム構築において、最適なエンジンを選択できます。

AWSの他のサービスとの連携:  EC2、S3、Lambda、ECS/EKS など、AWS の他のサービスとの連携が容易であり、AWS 環境全体でのシステム構築をスムーズに行えます。

コスト効率:  従量課金制であり、初期費用を抑えて利用を開始できます。リザーブドインスタンスや Savings Plans を活用することで、長期的なコストを最適化できます。
他の選択肢との比較 (EC2上のDB, Aurora, DynamoDBなど):

EC2上のDB:  柔軟性は高いですが、運用負荷が大きくなります。RDS は、運用負荷を軽減したい場合に最適な選択肢です。

Aurora:  RDS の高性能版であり、特にパフォーマンスを重視するシステムに適しています。標準的な MySQL/PostgreSQL よりも高価になるため、コストとパフォーマンスのバランスを考慮して選択します。

DynamoDB:  NoSQLデータベースであり、RDBとは異なる特性を持ちます。大量のアクセスを処理するWebアプリケーションや、スキーマレスなデータモデルに適しています。RDB の特性が必要な場合は、RDS を選択します。
総合的に見て、RDS は、運用負荷を軽減し、可用性、スケーラビリティ、セキュリティを確保しながら、リレーショナルデータベースをクラウドで利用したい というニーズに最適なサービスであり、実務で非常に広く活用されています。

 【terraformのコードで記述する場合の基本的内容と実務レベルの内容】基本的な記述 (aws_db_instance リソース)
Terraform で RDS インスタンスを記述する場合、aws_db_instance リソースを使用します。以下は基本的な構成例です。
resource "aws_db_instance" "example" {
  allocated_storage    = 20
  engine               = "mysql"
  engine_version       = "5.7"
  instance_class       = "db.t2.micro"
  name                 = "mydb"
  username             = "admin"
  password             = "password1234" # 実務では Secrets Manager などで管理
  skip_final_snapshot  = true # 削除時の最終スナップショットをスキップ (開発環境向け)
}
基本的な属性の説明:

allocated_storage:  割り当てるストレージサイズ (GB)。

engine:  DBエンジン (mysql, postgres, sqlserver, oracle, mariadb, aurora)。

engine_version:  DBエンジンのバージョン。

instance_class:  DBインスタンスのタイプ (CPU、メモリのスペック)。db.t2.micro, db.m5.large など。

name:  初期データベース名 (DBエンジンによって必須/オプション)。

username:  マスターユーザー名。

password:  マスターユーザーパスワード。実務ではハードコードせず、Secrets Manager などのシークレット管理サービスを利用すべきです。

skip_final_snapshot:  インスタンス削除時に最終スナップショットを作成するかどうか。true (スキップ) は開発環境向け。本番環境では false に設定することを推奨。
VPC 関連の設定 (必須):
RDS インスタンスは VPC 内に作成する必要があるため、以下の属性も通常は必須となります。
resource "aws_db_instance" "example" {
  # ... (上記属性) ...

  vpc_security_group_ids = [aws_security_group.rds_sg.id]
  db_subnet_group_name   = aws_db_subnet_group.rds_subnet_group.name
}

resource "aws_security_group" "rds_sg" {
  name        = "rds-sg"
  description = "セキュリティグループ for RDS"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 3306 # MySQL のデフォルトポート
    to_port     = 3306
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/16"] # VPC CIDR など、アクセスを許可するIP範囲
  }
}

resource "aws_db_subnet_group" "rds_subnet_group" {
  name       = "rds-subnet-group"
  subnet_ids = [aws_subnet.private_subnet_az1.id, aws_subnet.private_subnet_az2.id] # 複数のAZのプライベートサブネットを指定
}

vpc_security_group_ids:  適用するセキュリティグループのIDリスト。

db_subnet_group_name:  使用する DB サブネットグループ名。

aws_security_group:  RDS 用のセキュリティグループ定義。インバウンドルールでDBポートへのアクセスを許可します。

aws_db_subnet_group:  DBサブネットグループ定義。複数のAZのプライベートサブネットを指定することで、Multi-AZ 構成の準備となります。
実務レベルの記述と考慮事項:
実務レベルでは、上記の基本的な記述に加えて、可用性、セキュリティ、運用性、パフォーマンス、コストなどを考慮した設定が必要になります。
可用性:

multi_az = true:  Multi-AZ 構成を有効にします。本番環境では必須の設定です。
resource "aws_db_instance" "example" {
  # ... (上記属性) ...
  multi_az = true
}

availability_zone:  プライマリDBインスタンスを配置するAZを指定できます (通常はAWSに自動選択させる)。

リードレプリカ:  aws_db_instance リソースとは別に、aws_db_instance リソースの replicate_source_db 引数を使用してリードレプリカを作成できます。
セキュリティ:

password:  パスワードはハードコードせず、AWS Secrets Manager などのシークレット管理サービスで安全に管理します。 Terraform の data "aws_secretsmanager_secret_version" データソースなどを利用して Secrets Manager からパスワードを取得し、password 属性に渡します。

storage_encrypted = true:  ストレージ暗号化を有効にします。保存時のデータを暗号化します。

kms_key_id:  ストレージ暗号化に使用する KMS キーを指定できます (デフォルトはAWS管理キー)。

publicly_accessible = false:  パブリックアクセスを無効にします。VPC 内からのみアクセス可能にします (デフォルトは false)。

IAM 認証:  aws_iam_auth_enabled = true を設定し、IAM データベース認証を有効にすることを検討します (DBエンジンが対応している場合)。
運用性:

backup_retention_period:  自動バックアップの保持期間 (日数) を設定します。

backup_window:  自動バックアップを実行する時間帯 (UTC) を指定します。

maintenance_window:  メンテナンス (パッチ適用など) を実行する時間帯 (UTC) を指定します。

monitoring_interval / enhanced_monitoring_role_arn:  拡張モニタリングを有効にし、詳細なOSメトリクスを CloudWatch に送信します。

deletion_protection = true:  意図しない削除を防ぐために、削除保護を有効にします。本番環境では必須の設定です。

tags:  リソースにタグを付与し、コスト管理やリソース管理を容易にします。
パフォーマンス:

instance_class:  ワークロードに合わせて適切なインスタンスタイプを選択します。

allocated_storage / max_allocated_storage:  ストレージサイズを適切に設定します。max_allocated_storage を設定することで、ストレージ自動拡張を有効にできます。

storage_type:  ストレージタイプ (gp2/gp3, io1/io2, standard) をワークロードに合わせて選択します。

iops / throughput:  プロビジョンドIOPS SSD (io1/io2) を使用する場合、IOPS またはスループットをプロビジョニングできます。

parameter_group_name / option_group_name:  パラメータグループやオプショングループをカスタム設定することで、DBエンジンの動作を細かく制御できます。
モジュール化:
Terraform コードをモジュール化することで、再利用性と可読性を高めることができます。RDS インスタンスの設定をモジュール化し、環境 (開発、ステージング、本番など) やDBエンジンごとにモジュールを使い分けることができます。
ステート管理:
Terraform のステートファイルは、S3 バケットと DynamoDB を使用してリモートで管理することを推奨します。これにより、複数人での共同作業や、CI/CD パイプラインでの利用が容易になります。
バージョン管理:
Terraform コードは Git などのバージョン管理システムで管理し、変更履歴を追跡できるようにします。
実務レベルのTerraformコード例 (一部抜粋):
resource "aws_db_instance" "example" {
  identifier             = "my-rds-instance"
  allocated_storage    = 100
  max_allocated_storage = 200 # ストレージ自動拡張を有効化
  engine               = "aurora-mysql"
  engine_version       = "5.7.mysql_aurora.2.09.2"
  instance_class       = "db.r5.large"
  db_name              = "mydb"
  username             = "admin"
  password             = data.aws_secretsmanager_secret_version.rds_password.secret_string # Secrets Manager から取得
  vpc_security_group_ids = [aws_security_group.rds_sg.id]
  db_subnet_group_name   = aws_db_subnet_group.rds_subnet_group.name
  multi_az               = true
  storage_encrypted      = true
  kms_key_id             = "arn:aws:kms:..." # KMS キーを指定 (オプション)
  backup_retention_period = 7
  backup_window          = "03:00-04:00"
  maintenance_window     = "09:00-10:00"
  deletion_protection    = true
  tags = {
    Name        = "my-rds-instance"
    Environment = "Production"
  }
}

data "aws_secretsmanager_secret_version" "rds_password" {
  secret_id = "arn:aws:secretsmanager:..." # Secrets Manager のシークレット ARN
}
上記はあくまで例であり、実際にはシステムの要件に合わせて様々な設定が必要になります。実務では、AWS Well-Architected Framework やベストプラクティスを参考に、より堅牢で効率的な RDS 環境を Terraform で構築することが求められます。
【実務レベルの内容と重要事項】

【実務でどの程度使用されるのか】

【terraformのコードで記述する場合の基本的内容と実務レベルの内容】

Discussion
