第 6 章 高パフォーマンスなアーキテクチャの設計(24%)
この章で学ぶこと
この章に出てくる用語
AWS のストレージは数が多いが、形は 3 つだ。どれを選ぶかは、アプリがデータをどう触るかで決まる。

| ブロック | ファイル | オブジェクト | |
|---|---|---|---|
| 代表 | Amazon EBS | Amazon EFS/FSx | Amazon S3 |
| 触り方 | ディスクとして OS に見える | 共有フォルダとして見える | API(HTTP)で出し入れする |
| 途中の書き換え | できる | できる | できない(まるごと置き換え) |
| 何台から使えるか | 基本 1 台(同じ AZ) | 多数から同時に | どこからでも |
| 向く用途 | OS・データベース | 複数台で共有するファイル | ログ・画像・バックアップ・データレイク |
試験では
「複数の EC2 から同じファイルを読み書きしたい」は EFS。EBS は原則 1 台にしか付かない(同じ AZ 内の Multi-Attach という例外はあるが、クラスター対応のアプリ向けで一般的な共有には使わない)。この取り違えが最も多い。

| 種別 | 形 | 性能 | 向く用途 |
|---|---|---|---|
| gp3 | SSD | 3,000 IOPS / 125MB/s が既定。容量と独立に増やせる | ふつうはこれ。汎用 |
| gp2 | SSD | 容量に比例(3 IOPS/GiB)。バースト | 旧世代。gp3 のほうが安く速い |
| io1 / io2 | SSD | 最大 64,000 IOPS(io2 Block Express はさらに上) | 高い IOPS が要る DB |
| st1 | HDD | スループット重視。ランダムに弱い | 大きなデータを順に読む(ログ処理) |
| sc1 | HDD | 最も遅く、最も安い | ほとんど読まない保管 |
試験では
HDD 系(st1・sc1)は起動ボリュームにできない。 SSD 系だけだ。また、「IOPS を上げたいが容量は増やしたくない」は gp3(容量と独立に設定できる)。gp2 では容量を増やさないと IOPS が上がらない。
補足
gp2 から gp3 への変更は停止せずにできる(ボリュームの変更)。コストの設問でも「gp2 を gp3 に替える」が答えになることが多い(第 11 章)。
もう 1 つ、EBS ではない直付けのディスクがある。インスタンスストアだ。

| インスタンスストア | EBS | |
|---|---|---|
| 場所 | ホストに物理的に付いている | ネットワーク越し |
| 速さ | 最も速い | 速い(種別による) |
| 停止・終了したら | 消える | 残る |
| 付け替え | できない | できる |
| 向く用途 | 一時的なキャッシュ・スクラッチ領域 | OS・DB・残したいデータ |

| サービス | プロトコル | 向く場面 |
|---|---|---|
| Amazon EFS | NFS(Linux) | 複数の Linux から共有。自動で伸び縮み |
| FSx for Windows File Server | SMB(Windows) | Active Directory と統合した Windows の共有 |
| FSx for Lustre | Lustre | HPC・機械学習。S3 と連携して高速に処理 |
| FSx for NetApp ONTAP | NFS / SMB / iSCSI | オンプレの ONTAP をそのまま持ってくる |
| FSx for OpenZFS | NFS | ZFS の機能(スナップショット等)が要るとき |
試験では
「Windows の共有フォルダ」「AD と統合」と書かれていたら FSx for Windows File Server。EFS は NFS なので Windows の共有には使わない。「HPC」「機械学習の学習データを S3 から読む」は FSx for Lustre。
補足
EFS には保管クラスがあり、使われないファイルを自動で低頻度アクセス(IA)へ移すライフサイクルが設定できる。1 つの AZ だけに置く One Zone もあり、こちらは安いが AZ 障害に弱い。
S3 は容量の上限が無く、置くだけで冗長化される。それでも性能の設問は出る。大きなファイルの扱い方と、遠くからの転送だ。

| やりたいこと | 使うもの | 押さえる数字 |
|---|---|---|
| 大きなファイルを速く確実に上げる | マルチパートアップロード | 100MB 以上で推奨・5GB 以上では必須。1 オブジェクトの上限は 5TB |
| 遠い国からの転送を速くする | Transfer Acceleration | エッジロケーション経由で送る |
| 読み書きの並列度を上げる | プレフィックスを分ける | プレフィックスごとに 3,500 PUT / 5,500 GET(秒) |
| 一桁ミリ秒で読みたい | S3 Express One Zone | 1 つの AZ に置く代わりに非常に速い |
補足
昔は「プレフィックスをランダムにして分散させる」という工夫が要ったが、現在は S3 が自動で分散するので、名前をわざと散らす必要はない。それでもプレフィックス単位で上限があることは変わらないので、極端に高い並列度が要るときは分ける。
「オンプレのファイルサーバーを AWS に寄せたい」「テープをやめたい」という要件には AWS Storage Gateway が出てくる。3 種類あり、役割が違う。

| 種類 | オンプレからの見え方 | AWS 側の置き場 |
|---|---|---|
| ファイルゲートウェイ | NFS / SMB の共有フォルダ | S3(オブジェクトとして見える) |
| ボリュームゲートウェイ | iSCSI のディスク | S3(スナップショットは EBS として復元できる) |
| テープゲートウェイ | 仮想テープライブラリ(VTL) | S3 Glacier 系 |
試験では
「既存のバックアップソフトを変えずにテープをやめたい」はテープゲートウェイ。「オンプレのファイル共有を S3 に置きたい」はファイルゲートウェイ。単にデータを一度だけ移すだけなら Storage Gateway ではなくDataSync(第 10 章)や Snow ファミリーが答えになる。ここを混同しない。

| 問題文に出る語 | 答えの方向 |
|---|---|
| 複数の EC2 から同時に読み書き(Linux) | Amazon EFS |
| Windows の共有・Active Directory | FSx for Windows File Server |
| HPC・機械学習・S3 のデータを高速に | FSx for Lustre |
| データベースのディスク・高い IOPS | EBS(io1 / io2、または gp3) |
| 容量と独立に IOPS を上げたい | gp3 |
| 大きなファイルを順に読む・安く | st1(スループット最適化 HDD) |
| 一時的で速い作業領域・消えてよい | インスタンスストア |
| 静的コンテンツ・ログ・バックアップ・データレイク | Amazon S3 |
| オンプレのファイル共有を S3 へ | Storage Gateway(ファイルゲートウェイ) |
10 台の Linux EC2 が、同じディレクトリのファイルを同時に読み書きする必要がある。容量は使った分だけ払いたい。
補足
答え:Amazon EFS をマウントする。
EBS は原則 1 台にしか付かないので要件を満たさない。S3 はオブジェクトなので、ファイルの途中を書き換える使い方には向かない。
動画編集のワークステーションとして使う EC2 に、一時的な作業領域として最も速いディスクを付けたい。終了時に消えてよい。
補足
答え:インスタンスストアを使う。
ホストに物理的に付いているので最も速い。「終了時に消えてよい」と明記されているので、EBS を選ぶ理由が無い。
この章のまとめ
この章の根拠
最終確認 2026-10-04 / 対応バージョン DEA 2026-05-04 改訂版