Amazon RDS入門 クラウドDB移行の基礎知識

「オンプレのMySQLをAWSに移行したいけれど、RDSを使うべきか、EC2にデータベースを入れるべきか判断がつかない」——クラウド移行プロジェクトで、データベース担当者がまず直面する悩みです。

オンプレ環境では、物理サーバーにMySQLやPostgreSQLをインストールし、バックアップスクリプトを組み、パッチ適用日を調整し、レプリケーションの監視を続けてきたはずです。こうした運用の重さを知っているからこそ、「マネージドサービスに任せる」という選択肢の意味が実感できます。

この記事では、Amazon RDSの基本概念からインスタンス作成手順、バックアップとレプリケーション、料金体系まで、オンプレ経験者が押さえるべきポイントを体系的に解説します。

なぜRDSなのか？EC2にデータベースを入れる場合との違い

EC2インスタンスにMySQLをインストールすれば、オンプレと同じ感覚でデータベースを運用できます。設定ファイルを自由にいじれるし、OSレベルのチューニングも可能です。

ただし、それは「運用の重さもそのまま引き継ぐ」ことを意味します。パッチ適用、バックアップの自動化、フェイルオーバーの仕組み、ストレージの拡張——すべて自分で面倒を見る必要があります。

Amazon RDSは、この運用負荷を大幅に軽減するマネージドデータベースサービスです。主な違いを整理します。

オンプレでデータベース運用を経験した人なら、バックアップとフェイルオーバーの自動化だけでもRDSを選ぶ理由として十分でしょう。逆に、OSレベルのカスタマイズが必須の場合はEC2上での構築を検討する必要があります。

RDSの対応エンジンと選び方

Amazon RDSは6種類のデータベースエンジンに対応しています（2026年3月時点）。

・MySQL: オンプレで最も広く使われているOSSデータベース。移行のハードルが最も低い
・PostgreSQL: 高度なSQL機能とJSON対応が強み。GIS系の処理にも対応
・MariaDB: MySQLのフォーク。MySQLとの互換性が高く、追加機能がある
・Oracle: 商用ライセンスをBYOL（持ち込み）またはAWS提供のライセンスで利用可能
・SQL Server: Windows系のシステムからの移行に適している
・Amazon Aurora: AWSが独自開発したMySQL/PostgreSQL互換エンジン。RDSのMySQLと比較して最大5倍のスループットを謳っている

選定の基本方針はシンプルです。オンプレで使っているエンジンと同じものをRDSで選ぶのが最もリスクが低い。アプリケーション側のSQLやドライバ設定をほぼそのまま流用できます。

新規構築であれば、Amazon Auroraを検討する価値があります。ストレージが自動で拡張し、レプリケーション遅延も小さい。ただし、Aurora固有の仕様（クラスターエンドポイントなど）を理解する学習コストが発生する点は考慮してください。

RDSインスタンスの作成手順

1. マネジメントコンソールでの基本操作

1. AWSマネジメントコンソールにログインし、サービス一覧から「RDS」を選択
2. 「データベースの作成」をクリック
3. 作成方法は「標準作成」を選ぶ。「かんたん作成」はデフォルト値が固定されるため、本番用途には向かない
4. エンジンタイプを選択（例: MySQL 8.0）
5. テンプレートを選択。検証用途なら「無料利用枠」、本番なら「本番稼働用」を選ぶ

2. インスタンスサイズとストレージの設定

インスタンスクラスはオンプレのデータベースサーバーのスペックに相当します。

・db.t3.micro: 検証・開発用途。vCPU 2、メモリ1GiB。無料利用枠の対象
・db.t3.medium: 小規模本番向け。vCPU 2、メモリ4GiB
・db.r6g.large: メモリ最適化。vCPU 2、メモリ16GiB。読み取り負荷の高いワークロード向け

ストレージタイプは以下の3種類です。

・gp3（汎用SSD）: 大半のワークロードに適合。IOPS 3,000がベースライン
・io2（プロビジョンドIOPS）: 高いI/O性能が必要な大規模OLTP向け
・magnetic: 旧世代。新規での利用は推奨されない

オンプレでRAID10を組んでいたような環境であれば、gp3で十分対応できるケースが大半です。IOPS要件が明確な場合はio2を選択してください。

3. ネットワークとセキュリティの設定

RDSインスタンスはVPC内に配置します。オンプレでいえば「データベースサーバーをどのネットワークセグメントに置くか」を決める工程です。

1. VPCを選択（既存のVPCを使用するのが一般的）
2. サブネットグループを指定。RDSは最低2つの異なるアベイラビリティゾーンのサブネットを必要とする
3. パブリックアクセスは「なし」を選択。データベースをインターネットに直接公開するのはセキュリティ上の大きなリスク
4. セキュリティグループで、アプリケーションサーバーのIPレンジまたはセキュリティグループからの3306番ポート（MySQLの場合）のみ許可

オンプレでデータベースサーバーをDMZに置かないのと同じ考え方です。プライベートサブネットに配置し、アプリケーション層からの接続のみ許可する設計が基本です。

バックアップとリストアの仕組み

1. 自動バックアップ

RDSの自動バックアップは、オンプレでcron + mysqldumpを組んでいた運用を完全に置き換えます。

・バックアップウィンドウで指定した時間帯に、自動でスナップショットを取得
・保持期間は1〜35日。本番環境では7日以上を推奨
・バックアップ中もデータベースは稼働し続ける。ただし、シングルAZ構成の場合はI/O遅延が発生する可能性がある

オンプレでは「バックアップ中にサービスを止めるか、スレーブから取るか」で悩む場面がありましたが、RDSではマルチAZ構成にしておけばスタンバイ側からバックアップが取得されるため、本番への影響を最小限に抑えられます。

2. ポイントインタイムリカバリ

RDSは5分ごとにトランザクションログをS3に保存しています。これにより、保持期間内の任意の時点にデータベースを復元できます。

「今朝9時の状態に戻したい」といったリクエストに対応できるのは、オンプレではバイナリログを手動でリプレイする必要があった作業と比べて圧倒的に楽です。

注意点として、ポイントインタイムリカバリは新しいRDSインスタンスとして復元されます。既存のインスタンスに上書きされるわけではありません。復元後にアプリケーションの接続先エンドポイントを切り替える作業が必要です。

3. 手動スナップショット

大きな変更作業の前には、手動スナップショットを取得しておくのが安全です。自動バックアップと異なり、手動スナップショットは明示的に削除するまで保持されます。

# AWS CLIで手動スナップショットを取得
aws rds create-db-snapshot \
  --db-instance-identifier mydb-production \
  --db-snapshot-identifier mydb-before-migration-20260330

マルチAZ構成で可用性を確保する

オンプレでデータベースの冗長化といえば、MySQLのレプリケーションやOracle RACを構築し、Pacemakerでフェイルオーバーを制御するのが定番でした。構築にも運用にもそれなりの工数がかかります。

RDSのマルチAZ配置は、これをチェックボックス1つで実現します。

・プライマリインスタンスとは別のアベイラビリティゾーンにスタンバイが自動作成される
・プライマリに障害が発生すると、通常60〜120秒でスタンバイに自動切り替え
・切り替え後もエンドポイント（接続先のDNS名）は変わらない。アプリケーション側の設定変更は不要

「フェイルオーバーのテストを年1回やっていたけれど、毎回ヒヤヒヤした」という経験がある方には、RDSのマルチAZがどれだけ安心感をもたらすかわかるはずです。

ただし、マルチAZはあくまで可用性のための仕組みであり、読み取り負荷の分散には使えません。読み取りスケーリングが必要な場合は、リードレプリカを別途作成します。

料金の仕組みとコスト最適化

RDSの料金は大きく4つの要素で構成されます（2026年3月時点、東京リージョン）。

・インスタンス料金: 選択したインスタンスクラスの時間課金。db.t3.microで約$0.026/時間、db.r6g.largeで約$0.288/時間
・ストレージ料金: gp3で$0.138/GB/月。プロビジョンドIOPSの場合はIOPS数に応じた追加課金
・バックアップストレージ: 割り当てストレージと同量までは無料。超過分は$0.095/GB/月
・データ転送: 同一リージョン内のAWSサービス間は無料。インターネットへのアウトバウンドは$0.114/GBから

オンプレと比較する際の注意点として、RDSの料金にはOS、データベースエンジンのライセンス（MySQL/PostgreSQLの場合）、バックアップ、監視の基盤コストが含まれています。単純な「サーバー費用」の比較では正確な判断ができません。

コストを抑えるポイントは以下の通りです。

・リザーブドインスタンス: 1年または3年の利用をコミットすることで、オンデマンド料金と比較して最大60%程度の割引
・インスタンスの適正サイジング: CloudWatchでCPU使用率・メモリ使用率を監視し、過剰スペックなら縮小する
・開発環境の停止: 開発・検証用のRDSは業務時間外に停止する。停止中はインスタンス料金が発生しない（最大7日間で自動再起動される点に注意）

よくあるトラブルと対処法

1. 接続できない

RDS作成直後に「接続がタイムアウトする」というトラブルは非常に多いです。ほとんどの場合、セキュリティグループの設定が原因です。

・セキュリティグループのインバウンドルールで、アプリケーションサーバーからのポート（MySQL: 3306、PostgreSQL: 5432）が許可されているか確認
・パブリックアクセスを「なし」にした場合、同一VPC内からしか接続できない。踏み台サーバー経由かVPN接続が必要
・サブネットのルートテーブルが正しく設定されているか確認

2. ストレージが満杯になる

ストレージの自動スケーリングを有効にしていない場合、ディスクが満杯になるとデータベースが書き込み不能になります。

# AWS CLIでストレージ自動スケーリングを有効化
aws rds modify-db-instance \
  --db-instance-identifier mydb-production \
  --max-allocated-storage 200 \
  --apply-immediately

上記の例では、最大200GBまで自動拡張されます。オンプレで「ディスク使用率のアラートが鳴って深夜に対応」という経験がある方は、この設定を忘れずに入れておきましょう。

3. メンテナンスウィンドウによる意図しない再起動

RDSはメンテナンスウィンドウで自動的にパッチ適用を行います。マルチAZ構成の場合、スタンバイ→プライマリの順にパッチが適用されるため、ダウンタイムはフェイルオーバーの数十秒で済みます。

シングルAZ構成では数分間のダウンタイムが発生するため、メンテナンスウィンドウをアクセスが少ない時間帯に設定してください。日本のサービスであれば、火曜日〜木曜日の午前3時〜5時（JST）あたりが無難です。

なお、RDSで稼働するLinuxベースのDBエンジンについて、OSレベルの基礎知識を固めたい方は、姉妹サイトLinuxMaster.JPも参考にしてください。また、セキュリティグループやIAMポリシーの設計をさらに深掘りしたい方には、SecurityMasters.TOKYOでクラウドセキュリティの実践的な解説を掲載しています。

本記事のまとめ

Amazon RDSは、オンプレのデータベース運用で多くの時間を費やしてきた「バックアップ・冗長化・パッチ適用」を自動化するサービスです。OSレベルのアクセスを手放す代わりに、運用の負荷を大幅に下げられます。

まずは無料利用枠のdb.t3.microで検証環境を作り、オンプレとの操作感の違いを体験してみてください。マネジメントコンソールからの操作に慣れたら、AWS CLIやCloudFormationでの構築も試すことで、インフラのコード化への第一歩になります。