はじめに
オンプレミスのRHELサーバ運用経験を持つエンジニアがAWSへ移行する際、最初につまずきやすい領域のひとつがストレージである。
fdisk によるパーティション設計、mount によるマウント管理、NFS構築といったオンプレの知識はAWSにおいても対応する概念が存在する。しかし、「どのAWSサービスが既存の概念に対応するのか」を整理しないまま作業を進めると、設計ミスやコスト過多に陥りやすい。
本記事では、以下の2軸でAWSストレージを整理する。
- 各サービス（EBS / EFS / S3 / FSx / Instance Store）の特性と選択基準
- オンプレの概念とAWSサービスの1対1マッピング
1. まず「ストレージの分類」を頭に入れる
AWSのストレージサービスは大きく3種類のインターフェースで分類できる。まずはオンプレとの対応関係を俯瞰する。
| オンプレの概念 | AWSサービス | I/F | 主な用途 |
|---|---|---|---|
| ローカルディスク (SAN/iSCSI) | EBS | Block | OS・DB・アプリ |
| NFSサーバ (共有ストレージ) | EFS / FSx | File | 共有ファイル |
| オブジェクトストレージ | S3 | HTTP API | 静的資産・バックアップ |
| インスタンス直付けSSD | Instance Store | Block | 一時キャッシュ |
RHELで
/dev/xvdaにマウントしていたのが EBS、/mnt/shareでNFSマウントしていたのが EFS という対応関係で整理できる。
2. EBS (Elastic Block Store) — サーバの「ディスク」
基本特性
EBSはEC2インスタンスにアタッチするブロックストレージだ。最も重要な制約は以下の2点である。
オンプレと同様、mkfs・mount・/etc/fstab の設定はEC2上でそのまま使用できる。OS側の作業は変わらない。AWSが提供するのは「マネージドなブロックデバイス」である。
ボリュームタイプの選択
| タイプ | 用途 | 最大IOPS | 備考 |
|---|---|---|---|
| gp3 | 汎用（推奨） | 16,000 | IOPS・スループットを独立設定可。コスト効率◎ |
| gp2 | 汎用（旧世代） | 16,000 | 容量に比例してIOPSが変動 ← 設計の落とし穴 |
| io2 Block Express | 高性能DB | 256,000 | Oracle/SQL Server等のミッションクリティカルDB向け |
| st1 | スループット重視 | - | ログ収集・Hadoopなどシーケンシャルアクセス向け |
| sc1 | コールドデータ | - | アクセス頻度が低いアーカイブ向け |
設計基準: 新規構築では gp3 を選択する。gp2 は容量に比例してIOPSが増加する仕様のため、必要以上のコストが発生しやすい点に注意が必要だ。
スナップショット
EBSスナップショットはRHELでのddバックアップやLVMスナップショットに相当するが、I/Oへの影響なしに取得できる点がクラウドの強みだ。
RAIDを自前で組む必要はない
オンプレではRAID5/6でディスク障害を吸収していたが、AWSでは不要だ。
これはクラウドネイティブ設計における最大のパラダイムシフトのひとつである。
3. EFS (Elastic File System) — 共有ファイルシステム
オンプレとの対比
マウント方法もNFSv4.1に準拠しており、mount -t nfs4 コマンドがそのまま使える。
EBSとの決定的な違い
| EBS | EFS | |
|---|---|---|
| 同時アクセス | 原則1台 | 数千台まで |
| AZ跨ぎ | 不可（同一AZのみ） | 可（リージョン全体） |
| 容量管理 | 固定（要拡張作業） | 自動スケール |
| 単体コスト | GB単価が安い | GB単価が高い |
選択基準: 複数のEC2から同じファイルを読み書きする要件（Webサーバのコンテンツ共有、バッチ処理の共有ワークスペース等）があればEFSを選ぶ。それ以外はEBSが基本だ。
パフォーマンス・スループットモード
| 設定 | 選択肢 | 推奨 |
|---|---|---|
| パフォーマンスモード | General Purpose / Max I/O | General Purpose（レイテンシ優先） |
| スループットモード | Elastic / Provisioned | Elastic（自動スケールでコスト効率◎） |
4. S3 (Simple Storage Service) — AWSの中核
「ファイルシステムではない」という認識の転換
S3を扱う上で最も重要な概念の転換がこれだ。
これを理解していないと、大量小ファイル処理やパーティション設計で問題が生じる。
ストレージクラスの選択（コスト最適化の核心）
S3はデータのアクセス頻度に応じてストレージクラスを選択することで、コストを大幅に最適化できる。
| クラス | 用途 | 取り出しコスト | 特徴 |
|---|---|---|---|
| S3 Standard | 頻繁アクセス | 無料 | デフォルト |
| S3 Standard-IA | 月1回程度 | 有料 | 保管コスト↓・取り出しコスト↑ |
| S3 Glacier Instant Retrieval | 四半期に1回 | 有料・即時取り出し | アーカイブだが即時参照が必要な場合 |
| S3 Glacier Flexible Retrieval | 年1回・DR | 有料・数分〜数時間 | コスト重視のアーカイブ |
| S3 Glacier Deep Archive | 7年保管等 | 有料・最大12時間 | 最安。コンプライアンス保管向け |
オンプレでテープ媒体にアーカイブしていた運用が Glacier に相当する。ライフサイクルポリシーで自動移行を設定するのが実践的な設計だ（例: 90日後にIA、1年後にGlacier）。
セキュリティ設計（必須知識）
S3の情報漏洩事故のほとんどは設定ミスが原因だ。以下を徹底することが基本となる。
1. Block Public Access : 全プロジェクトでデフォルトON（オフにする場合は意図を文書化）
2. バケットポリシー : リソースベースのアクセス制御
3. IAMポリシー : アイデンティティベースの制御
4. ACL : 旧世代につき原則使用しない
5. 暗号化（SSE-KMS） : 保存データの暗号化をデフォルト化
オブジェクトロック（WORM）
一度書いたら変更・削除不可にできる機能。金融・医療等のコンプライアンス要件に対応する。
- Governance mode: 特定権限を持つユーザは解除可能
- Compliance mode: 誰も解除できない（保持期間の短縮・削除不可）
5. FSx — 特定ユースケース向けマネージドファイルシステム
EFSはLinuxのNFSに特化しているが、FSxはより多様なプロトコルに対応したマネージドファイルシステム群だ。
| サービス | 対応プロトコル | 主な用途 |
|---|---|---|
| FSx for Windows File Server | SMB | Active Directory連携、Windowsアプリ |
| FSx for Lustre | Lustre | HPC、機械学習、大規模並列処理 |
| FSx for NetApp ONTAP | NFS / SMB / iSCSI | オンプレNetAppからの移行 |
| FSx for OpenZFS | NFS | ZFSからの移行 |
RHEL環境からの移行では、FSx for NetApp ONTAP が既存のNFSマウント構成をほぼそのまま移行できる選択肢として有力だ。マルチプロトコル対応でWindowsとLinuxの混在環境にも対応できる。
6. Instance Store — 落とし穴に注意
物理ホストに直付けされたNVMe SSDで、超高速・低レイテンシが特徴だ。しかし致命的な制約がある。
用途は一時ファイル・キャッシュ・バッファに限定する。永続データを絶対に置かないことが鉄則だ。この特性を知らずにデータを保存すると、インスタンス停止時にデータが消える事故につながる。
7. オンプレ概念 × AWSサービス 1対1マッピング
ここからが本記事の核心だ。RHELで「当たり前にやっていたこと」がAWSではどのサービス・機能で実現されるかを整理する。
ストレージ操作
| オンプレでやっていたこと | AWSでの実現方法 | ポイント |
|---|---|---|
fdisk / parted でパーティション作成 |
EBSボリューム作成・アタッチ | サイズ変更はオンラインで可能 |
mkfs.xfs でフォーマット |
EC2上で同じコマンドを実行 | OS側の作業は変わらない |
mount /dev/sdb /data |
EBSアタッチ後、同じコマンド |
/etc/fstab も従来通り |
LVMでオンライン拡張（lvextend） |
EBSサイズ変更 → growpart + resize2fs
|
手順は微増するが考え方は同じ |
| NFSサーバ構築・クライアントマウント | EFS（マウントターゲット経由） |
mount -t nfs4 で同様にマウント |
| SAN / iSCSI | EBS or FSx for ONTAP | ほぼ同等の体験 |
| テープバックアップ | S3 Glacier Deep Archive | コスト・保管期間の考え方が同じ |
rsync でバックアップ転送 |
AWS DataSync | ネットワーク最適化・差分転送対応 |
dd / tar でフルバックアップ |
EBSスナップショット | 増分・整合性保証・I/O影響なし |
| RAID1（ミラーリング） | マルチAZ構成で担保 | AWSではRAIDが不要なケースがほとんど |
| RAID5/6（冗長化） | EBS内部で3重冗長済 | 自前でRAIDを組む必要なし |
| ファイルサーバ（Windows SMB） | FSx for Windows File Server | AD連携もそのまま移行可能 |
df -h でディスク監視 |
CloudWatch メトリクス | アラームで自動通知も可能 |
OS・サーバ管理
| オンプレでやっていたこと | AWSでの実現方法 | ポイント |
|---|---|---|
| 物理サーバの電源ON/OFF | EC2の起動・停止 | APIまたはマネジメントコンソールで操作 |
| サーバのハードウェア増強 | インスタンスタイプ変更 | 停止→タイプ変更→起動 |
| OSインストール + キックスタート | AMI（Amazon Machine Image） | カスタムAMIで何度でも同一環境を展開 |
| ゴールデンイメージの保管 | AMI | スナップショットベースで保存・共有 |
yum update / パッチ管理 |
AWS Systems Manager Patch Manager | 複数台を一括スケジュール管理 |
cron でバッチ処理 |
EventBridge + Lambda / SSM | サーバレスで実行可能 |
| 内部DNSサーバ | Route 53 プライベートホストゾーン |
/etc/hosts の一元管理代替 |
firewalld / iptables
|
セキュリティグループ + NACL | ステートフル vs ステートレスの違いに注意 |
| SSHログイン | Systems Manager Session Manager | ポート22開放不要・セキュリティ向上 |
| ジャンプサーバ（踏み台） | Session Manager or Bastion Host | Session Manager推奨 |
| Zabbix等による監視 | CloudWatch + CloudWatch Agent | メトリクス・ログを一元収集 |
| rsyslog / syslog | CloudWatch Logs |
/var/log のログをリアルタイム転送 |
セキュリティ・権限管理
| オンプレでやっていたこと | AWSでの実現方法 | ポイント |
|---|---|---|
| Linuxユーザ・グループ管理 | IAM ユーザ・グループ | AWSリソースへのアクセス制御 |
visudo でsudo権限管理 |
IAMポリシー | 操作単位でAllow/Denyを設定 |
| Active Directory認証 | IAM Identity Center（SSO） | 組織全体のシングルサインオン |
chmod / chown でACL管理 |
S3バケットポリシー / IAMポリシー | リソース単位の細粒度制御 |
| ディスク暗号化（LUKS） | EBS暗号化（KMS） | キー管理はAWS KMSに委譲 |
| SSL証明書の管理・更新 | ACM（AWS Certificate Manager） | 自動更新・無料 |
| 秘密情報の管理 | Secrets Manager / SSM Parameter Store | 認証情報のハードコーディングを撲滅 |
| 監査ログ | AWS CloudTrail | 誰がいつ何の操作をしたか全記録 |
8. ストレージ選択の判断フロー
設計時の判断を整理すると以下のようになる。
9. 移行設計で意識すべき思想の転換
① 「サーバは使い捨て」設計（Immutable Infrastructure）
② 容量を「事前確保」しない
③ ネットワークはソフトウェア定義
④ 移行期間中は Storage Gateway を活用する
オンプレとAWSを同時並行で運用する移行期間中は、AWS Storage Gateway がオンプレのファイルシステムとS3を橋渡しする。既存アプリに変更を加えずにバックアップ先をS3へ切り替える、といった段階的移行が可能だ。
10. 設計・移行で特に重要なポイント
| テーマ | 押さえるべき内容 |
|---|---|
| gp2 vs gp3 | IOPSの計算方式の違い・コスト比較 |
| S3ストレージクラス | ライフサイクルポリシーの設計、移行コストとトレードオフ |
| EFS vs FSx for ONTAP | マルチプロトコル要件時の選択基準 |
| スナップショットのクロスリージョンコピー | DR設計のコスト・RPO/RTO |
| S3 Transfer Acceleration | グローバル展開時の転送速度最適化 |
| Storage Gateway | オンプレとAWSの橋渡し、移行期間中の役割 |
| AWS DataSync | 大量データ移行・差分同期 |
おわりに
オンプレミスからAWSへ移行する際、ストレージの選択判断は設計品質とコストに直結する。本記事で整理した各サービスの特性を以下にまとめる。
| サービス | 用途 | 主な特性 |
|---|---|---|
| EBS | 単一EC2のブロックストレージ | gp3推奨・内部3重冗長で自前RAID不要 |
| EFS | 複数EC2の共有ファイルシステム | マネージドNFS・自動スケール |
| S3 | オブジェクトストレージ | ライフサイクルポリシーによるコスト最適化 |
| FSx | 特定プロトコル対応ファイルシステム | SMB / Lustre / iSCSI等に対応 |
| Instance Store | 一時データ専用 | 高速だが永続性なし |
移行設計においては、データの永続化先を明確に分離し、EC2インスタンス自体はステートレスに設計することがクラウドネイティブな運用の基本原則となる。オンプレとAWSの概念は多くの部分で1対1にマッピングできるため、既存の運用知識を土台としてAWSサービスへ置き換えていくアプローチが有効である。