Amazon RDS for SQL Server では、プライマリボリュームに加えて最大3つの追加ストレージボリュームをアタッチできます。データファイルとトランザクションログを異なるボリュームに分散させることで I/O 競合を排除し、全ボリューム合計で最大 256 TiB という大容量のストレージを段階的に拡張できます。本記事では、追加ストレージボリューム機能の概要・技術仕様・設定手順・SQL Server での具体的な活用パターンを実践的なコードサンプルとともに解説します。
追加ストレージボリュームとは何か
従来の Amazon RDS for SQL Server では、データベースファイル(.mdf / .ndf)とトランザクションログファイル(.ldf)はすべてプライマリボリューム(Dドライブ)に格納されていました。データ量が増加するにつれてプライマリボリュームへの I/O 負荷が集中し、パフォーマンスのボトルネックになるケースが多く見られました。
追加ストレージボリューム機能を利用すると、プライマリボリュームとは独立した新しいボリュームを最大3つアタッチできます。各ボリュームはそれぞれ固有の Windows ドライブレターにマッピングされるため、SQL Server から通常のファイルパスとして扱えます。データファイルはH:ドライブ、トランザクションログはI:ドライブに配置するといった分散設計が可能になります。
この機能が特に効果を発揮するのは次のようなシナリオです。
- 大規模なデータベースを抱える本番環境でのI/Oパフォーマンス向上
- ストレージをビジネス成長に合わせて段階的に拡張したい場合
- テーブルパーティションを活用したデータアーカイブの実装
- スナップショットやポイントインタイムリカバリ(PITR)でのストレージ再構成
ストレージ要件に応じたボリュームタイプの選択が可能になり、コストとパフォーマンスのバランスを最適化できる点も大きなメリットです。
技術仕様と対応エディションの確認
追加ストレージボリュームを利用する前に、技術仕様と制約を把握しておくことが重要です。
ボリューム名とドライブレターのマッピング
追加ボリュームは以下の名前と Windows ドライブレターに対応しています。プライマリボリュームはDドライブで、追加ボリュームはH: 〜 J:に割り当てられます。
ボリューム名 | Windowsドライブ | 推奨用途例 |
|---|---|---|
rdsdbdata2 | H ドライブ | データファイル (.mdf / .ndf) |
rdsdbdata3 | I ドライブ | トランザクションログ (.ldf) |
rdsdbdata4 | J ドライブ | アーカイブデータ / 読み取り専用ファイルグループ |
ストレージタイプと容量
追加ボリュームで使用できるストレージタイプは gp3(汎用 SSD)と io2(プロビジョンド IOPS SSD)の2種類です。gp3 はスループットを個別に設定でき、io2 は IOPS を細かく制御できます。各ボリュームの最小サイズは 200 GiB で、全ボリュームの合計では最大 256 TiB まで利用できます(2025年12月のアップデートで拡張)。
対応エディション
追加ストレージボリュームを利用できるのは、次の SQL Server エディションです。
- SQL Server Standard Edition (SE)
- SQL Server Enterprise Edition (EE)
- SQL Server Developer Edition (DEV-EE)
Express Edition では利用できない点に注意が必要です。

AWS コンソールと CLI による設定手順
追加ストレージボリュームは AWS マネジメントコンソールまたは AWS CLI から設定できます。どちらの方法でも、既存のDBインスタンスを変更(Modify)する形で追加します。
AWS マネジメントコンソールからの操作
- AWS マネジメントコンソールにサインインし、Amazon RDS のページを開く
- 左のナビゲーションから「データベース」を選択
- 対象の DB インスタンスを選択し、「変更」ボタンをクリック
- 「ストレージ」セクションで「追加ストレージボリュームの追加」を選択
- ボリューム名・ストレージタイプ・割り当てストレージ・IOPS / スループットを設定
- 「続行」→「DB インスタンスの変更」をクリック
設定は即時反映される点に注意が必要です。後述しますが、追加ストレージボリュームの変更は --apply-immediately の設定に関わらず常に即時適用されます。
AWS CLI からの操作
CLI を使ってボリュームを追加する場合、modify-db-instance コマンドに --additional-storage-volumes オプションを指定します。
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--additional-storage-volumes '[
{
"VolumeName": "rdsdbdata2",
"StorageType": "gp3",
"AllocatedStorage": 5000,
"StorageThroughput": 725
},
{
"VolumeName": "rdsdbdata3",
"StorageType": "io2",
"AllocatedStorage": 2000,
"Iops": 6000
}
]'
ボリュームを削除したい場合は SetForDelete: true を指定します。
aws rds modify-db-instance \
--db-instance-identifier my-sql-server-instance \
--additional-storage-volumes '[{"VolumeName":"rdsdbdata4","SetForDelete":true}]' \
--apply-immediately
スナップショットからのリストアやポイントインタイムリカバリ(PITR)の際にも、--additional-storage-volumes オプションで追加ボリュームの構成を指定して引き継ぐことができます。
SQL Server でのデータベース作成とボリューム活用パターン
追加ボリュームをアタッチした後、SQL Server のクエリで直接ドライブレターを指定してデータベースを作成できます。
データファイルとログを別ボリュームに配置する
最も基本的なパターンは、データファイルをH:ドライブに、トランザクションログをI:ドライブに配置することです。I/O 特性が異なる2種類のファイルを分離することで、それぞれのストレージ性能を最大限に活用できます。
CREATE DATABASE MyDatabase ON (
NAME = 'MyDatabase_Data',
FILENAME = 'H:\rdsdbdata\data\MyDatabase_Data.mdf',
SIZE = 100MB,
FILEGROWTH = 10MB
) LOG ON (
NAME = 'MyDatabase_Log',
FILENAME = 'I:\rdsdbdata\data\MyDatabase_Log.ldf',
SIZE = 10MB,
FILEGROWTH = 10%
);
既存データベースを追加ボリュームに移行する
既存のデータベースを追加ボリュームへ移行する場合は、ボリューム間の直接移動はできないため、S3 を経由したバックアップとリストアを利用します。
-- 1. S3 へバックアップ
EXEC msdb.dbo.rds_backup_database
@source_db_name='MyDatabase',
@s3_arn_to_backup_to='arn:aws:s3:::my-bucket/database-backup.bak';
-- 2. ターゲットボリュームを指定してリストア
EXEC msdb.dbo.rds_restore_database
@restore_db_name='MyDatabase_New',
@s3_arn_to_restore_from='arn:aws:s3:::my-bucket/database-backup.bak',
@data_file_volume='H:',
@log_file_volume='I:';
-- 3. 元のデータベースを削除してストレージを解放
DROP DATABASE MyDatabase;
データアーカイブのパターン
パーティション化されたテーブルを利用して、アクセス頻度の低い古いデータをJ:ドライブのコスト効率の高いボリュームに配置するアーカイブ設計も実現できます。
-- アーカイブ用ファイルグループを追加
ALTER DATABASE MyDatabase ADD FILEGROUP ArchiveFileGroup;
-- J:ドライブにアーカイブデータファイルを追加
ALTER DATABASE MyDatabase ADD FILE (
NAME = 'Archive_Data',
FILENAME = 'J:\rdsdbdata\data\Archive_Data.ndf',
SIZE = 1GB,
FILEGROWTH = 100MB
) TO FILEGROUP ArchiveFileGroup;

制限事項と運用上の注意点
追加ストレージボリュームを活用するうえで、いくつかの制限事項と運用上の注意点を把握しておく必要があります。
機能制限
次の構成では追加ストレージボリューム機能を利用できません。
- リードレプリカ非対応 — リードレプリカが存在するインスタンスへの追加、およびリードレプリカインスタンスへの追加はできません
- クロスリージョン自動バックアップ非対応 — クロスリージョン自動バックアップが有効なインスタンスでは使用できません
- 直接のボリューム間ファイル移動は不可 — ファイルを別ボリュームへ直接移動することはできず、バックアップ → リストアの手順が必要です
- プライマリボリュームは削除不可 — Dドライブを削除することはできません
即時適用の仕様
追加ストレージボリュームの変更は、--no-apply-immediately オプションや API の ApplyImmediately: false を指定していても、常に即時適用されます。この仕様は他の変更(インスタンスタイプの変更など)とは異なるため、運用時に注意が必要です。追加ボリュームの変更を本番環境で行う際は、メンテナンスウィンドウを考慮した計画を立てるより、むしろ変更内容を事前に十分検証してから実施することが重要です。
ストレージタイプの選択指針
gp3 と io2 はそれぞれ異なる特性を持つため、ワークロードに合わせて選択します。データファイルへのランダム I/O が多い場合は io2 でプロビジョンド IOPS を確保し、大量データの順次読み書きが多い場合は gp3 のスループット設定を活用するという使い分けが効果的です。ストレージコストは io2 の方が高くなるため、必要な部分にのみ io2 を適用してコストを最適化する設計が推奨されます。
まとめ
Amazon RDS for SQL Server の追加ストレージボリューム機能は、データファイルとログファイルの分散配置によるI/Oパフォーマンス向上、段階的な容量拡張、データアーカイブなど、多様なシナリオに対応する柔軟なストレージ設計を可能にします。最大256 TiBの大容量に対応し、gp3とio2の組み合わせでコストとパフォーマンスを最適化できる点が大きな強みです。リードレプリカやクロスリージョン自動バックアップとの制約、即時適用の仕様を事前に把握したうえで、検証環境でのテストを経てから本番環境への適用をお勧めします。
オンプレミスの SQL Server から Amazon RDS への移行や、既存 RDS 環境のストレージ最適化を検討されている場合は、ぜひこの機能を活用してみてください。Ragate ではクラウドマイグレーション支援やAWS環境でのストレージ設計最適化を含むコンサルティングを提供しています。お気軽にご相談ください。
















