「S3 のバケットに置いた資料を、社外の取引先に一時的に渡したいです。バケットを公開すればよいですか」
「S3 は耐久性がイレブンナインだと聞きました。それならバックアップは要りませんよね」
第3回と第4回では、EC2 を中心にコンピューティングのサービスを見ました。EC2 のディスクも含め、データを置く場所がストレージのサービスです。AWS には、オンプレの SAN に当たる EBS、NAS に当たる EFS・FSx、テープに当たる S3 Glacier、そしてオンプレではあまりなじみのないオブジェクトストレージの S3 があります。名前が違っても、オンプレのブロック・ファイル・オブジェクトの区別を知っていれば、選び方の判断ができます。
第5回では、ストレージの全体像、S3 の基本・データ保護・ストレージクラス・アクセス制御・利用パターン、EBS のボリュームタイプとスナップショット、EFS、FSx、AWS Backup、データ移行のサービス、Azure との対応を扱います。
AWS のストレージ全体像
AWS のストレージを、アクセスの方法とオンプレの対応で並べます。ブロック・ファイル・オブジェクトの違いは、連載「ストレージ入門」第4回「ブロック・ファイル・オブジェクト」で詳しく扱います。
| 種別 | サービス | アクセスの方法 | オンプレの対応 | 接続の範囲 |
|---|---|---|---|---|
| ブロック | EBS | OS がディスクとして認識 | SAN（FC／iSCSI）の LUN | 同じ AZ の 1 インスタンス（io2 はマルチアタッチ可） |
| ブロック（内蔵） | インスタンスストア | 同上 | DAS | そのホストのみ。揮発 |
| ファイル | EFS（NFS）、FSx for Windows（SMB）、FSx for ONTAP／OpenZFS／Lustre | マウント | NAS（NFS、SMB） | VPC の中の多数のクライアント |
| オブジェクト | S3 | HTTPS の API（PUT/GET） | （オンプレでは MinIO など） | どこからでも（インターネット／VPC エンドポイント） |
| アーカイブ | S3 Glacier の各クラス | S3 の API＋取り出しの要求 | テープ | 同上 |
迷ったら「OS にマウントしたい→EBS/EFS」「アプリが HTTP で読み書きする、または保管が目的→S3」で考えます。S3 は NAS ではないので、既存のアプリのファイル共有をそのまま置き換えるものではありません（後の「データ移行・ハイブリッド接続のサービス」の節の File Gateway で橋渡しはできます）。オンプレとクラウドのストレージの対応は、連載「ストレージ入門」第11回「オンプレとクラウドの対応表」でも扱います。
S3（Simple Storage Service）の基本
S3 は 2006 年に AWS が最初に公開したサービスの一つで、「バケット」という入れ物に「オブジェクト」（データ本体＋メタデータ）を「キー」（logs/2026/09/app.log のような文字列）で格納します。フォルダーに見えるのはキーの / を表示の上で区切っているだけで、実体は平坦なキーバリューストアです。
バケット名はすべての AWS アカウントを通じて一意で、3〜63 文字の小文字・数字・ハイフンで付けます（ピリオドも使えますが、HTTPS の証明書と合わなくなるため避けます）。1 つのオブジェクトは最大 50 TB（2025年12月に 5 TB から拡張）で、1 回の PUT で送れるのは 5 GB までです。100 MB を超える場合はマルチパートアップロードで分割して転送します（5 GB を超えると必須）。バケットはリージョンに属し、データは指定したリージョンから出ません（規制への対応の根拠になります）。
アクセスは HTTPS の REST API で、aws s3 cp、SDK、または署名付き URL で行います。2020 年 12 月以降は強い整合性（書いた直後の読み取りで必ず最新が返る）が保証されており、それ以前の「結果整合性」を前提にした古い解説は、今では誤りです。
- バケット（全体で一意の名前）＋キー＋オブジェクト。フォルダーは表示の上のもの
- 1 つのオブジェクトは最大 50 TB（2025-12 に 5 TB から拡張）。100 MB 超はマルチパート
- 2020-12 から強い整合性。データはリージョンから出ない
オブジェクトストレージの仕組みそのものは、連載「ストレージ入門」第4回「オブジェクトストレージの仕組み」で扱います。
S3 の耐久性・可用性・データ保護機能
S3 の数字と、データを守る機能です。
- 耐久性 99.999999999%（イレブンナイン）：1 つのリージョンの中で、最低 3 つの AZ に自動で複製する（One Zone 系のクラスを除く）。「1,000 万個のオブジェクトを置いて、1 万年に 1 つ失う」水準。ただし利用者の誤削除は防げない
- 可用性：Standard で 99.99% の設計、SLA は 99.9%
- バージョニング：上書き・削除の履歴を保持する。削除は「削除マーカー」が付くだけで、元に戻せる。誤削除・ランサムウェア対策の第一歩
- オブジェクトロック（WORM）：指定した期間は誰も削除・上書きできない。ガバナンスモード／コンプライアンスモード（ルートでも解除できない）。監査のログや、バックアップの「改変できない世代」に当たる
- レプリケーション：別のリージョン（CRR）／同じリージョン（SRR）の別のバケットへ自動で複製する。DR、別のアカウントへの隔離したバックアップに使う
- 暗号化：2023 年 1 月以降、新しいオブジェクトは既定で SSE-S3（AWS が管理する鍵）で暗号化される。鍵を自分で管理したい場合は SSE-KMS を使う（第9回）
- MFA Delete：バージョンの削除に、ルートの MFA を要求する設定
冒頭の2つ目の相談がこれです。イレブンナインは「AWS 側の故障でデータを失わない」という意味で、利用者の操作ミスやランサムウェアによる削除・上書きは防ぎません。バージョニング＋MFA Delete＋オブジェクトロックで守り、別のアカウントやリージョンへの複製で隔離します。オブジェクトロックの2つのモードは、連載「バックアップ入門」第8回「S3 Object Lock の2つのモード」で詳しく扱います。
S3 のストレージクラス
S3 は、アクセスの頻度に合わせてクラス（保存の料金と取り出しの条件）を選びます。値は2026年9月時点のものです。
| クラス | 想定するアクセス | 最低保存期間 | 取り出し | 特徴 |
|---|---|---|---|---|
| Standard | 頻繁 | なし | 即時 | 既定。ミリ秒 |
| Intelligent-Tiering | 不明・変動 | なし | 即時 | アクセスの頻度を監視して自動で階層を移す。監視の料金が少しかかる |
| Standard-IA | 月 1 回程度 | 30 日 | 即時（GB 単位の取り出しの料金） | 保存の料金は Standard の約半分 |
| One Zone-IA | 同上、作り直せるデータ | 30 日 | 即時 | 単一の AZ。AZ が失われるとデータも失われる |
| Express One Zone | 超高頻度・低遅延 | なし | 即時（1 桁 ms） | 2023 年に追加。専用の「ディレクトリバケット」。ML・分析向け |
| Glacier Instant Retrieval | 四半期に 1 回程度 | 90 日 | 即時（ms） | アーカイブだが即時に取り出せる |
| Glacier Flexible Retrieval | 年 1〜2 回 | 90 日 | 数分〜12 時間 | 旧「Glacier」。取り出しの速さを 3 段階で選ぶ |
| Glacier Deep Archive | 年 1 回未満・法定の保存 | 180 日 | 12〜48 時間 | 最安（東京リージョンで約 0.002 USD/GB・月）。テープの代わり |
ライフサイクルルールで「30 日後に IA、90 日後に Glacier、7 年後に削除」を自動にできます。最低保存期間より前に削除すると、残りの日数分が課金されるので、短命なデータを IA に置くと逆に高くなります。バックアップの保存先としてのクラスの選び方は、連載「バックアップ入門」第7回「クラウドの保存先①：S3のストレージクラス」で扱います。
S3 のアクセス制御
S3 のアクセス制御は複数の仕組みが重なるため、事故（意図しない公開）が最も起きやすい領域です。
まずブロックパブリックアクセスは、バケット・アカウントの単位で「公開の設定を一切許さない」安全装置で、2023 年 4 月以降の新しいバケットでは既定で有効になっています。次にバケットポリシーは、バケット側に付けるリソースベースの IAM ポリシー（JSON）で、「特定の IAM ロールからのみ」「特定の VPC エンドポイントを経由した場合のみ（aws:SourceVpce）」「TLS 必須（aws:SecureTransport）」のような条件を書きます。
IAM ポリシー（利用者の側）との評価は、同じアカウントの中では「どちらかで明示的な拒否があれば拒否、どちらかで許可があれば許可」です。別のアカウントからのアクセス（クロスアカウント）では、両方に許可が必要です。古い ACL は、2023 年以降の新しいバケットでは既定で無効（オブジェクト所有者の強制）で、使わないのが原則です。
一時的に第三者へ渡すには署名付き URL（有効期限付き）を使い、バケットを公開してはいけません。冒頭の1つ目の相談の答えはこれです。Web サイトとして公開する場合も、S3 を直接公開するのではなく、CloudFront（第7回）の OAC を経由する形に限るのが今の標準です。
- ブロックパブリックアクセスは原則オン（新しいバケットは既定で有効）
- 制御はバケットポリシー（リソースの側）＋IAM ポリシー（利用者の側）。ACL は使わない
- 第三者との共有は署名付き URL、Web の公開は CloudFront 経由
S3 の典型的な利用パターン
S3 がよく使われる場面です。
- ログ・バックアップの保管先：CloudTrail、ELB のアクセスログ、VPC Flow Logs、RDS のスナップショットのエクスポート先として使う。ライフサイクルで Glacier へ移す
- 静的な Web サイト：HTML/JS/画像を置き、CloudFront から配信する。サーバーが要らない（Web サーバーと CDN で行っていた静的なコンテンツの配信を、サーバーレスにした形。CDN は連載「HTTP入門」第5回「CDNの仕組み」で扱います）
- データレイク：CSV/Parquet を置き、Athena（SQL で直接検索）、Glue、Redshift Spectrum から参照する。「まず S3 に置く」が AWS の分析基盤の出発点
- アプリのファイル置き場：利用者がアップロードした画像などに使う。EC2 のローカルのディスクに置くとスケールアウトできないので、S3 に逃がす
- VPC からの接続：ゲートウェイ型の VPC エンドポイント（第7回）を使えば、NAT ゲートウェイを経由せず無料で S3 に届く。NAT 経由で S3 に大量に転送すると、NAT の処理の料金で高く付く
CLI の例です（いずれも実行の例です）。
$ aws s3 sync ./backup s3://my-bucket/backup/ --storage-class STANDARD_IA
$ aws s3 presign s3://my-bucket/report.pdf --expires-in 36001 行目はローカルの ./backup を Standard-IA のクラスで同期し、2 行目は 1 時間（3600 秒）有効な署名付き URL を作ります。
EBS のボリュームタイプ
EBS は、性能と料金でボリュームのタイプを選びます。値は2026年9月時点の公式の値です。
| タイプ | 媒体 | 性能（目安） | サイズ | 用途 |
|---|---|---|---|---|
| gp3 | SSD | ベースライン 3,000 IOPS／125 MiB/s を容量に関係なく保証。追加の料金で最大 80,000 IOPS／2,000 MiB/s（2025 年 9 月に 16,000 IOPS／1,000 MiB/s から拡張） | 1 GiB〜64 TiB（2025 年 9 月に 16 TiB から拡張） | 既定。OS、一般的な DB |
| gp2 | SSD | 3 IOPS/GiB（最低 100）、バースト 3,000 | 1 GiB〜16 TiB | 旧世代。gp3 の方が 2 割安く速いので移行する |
| io2 Block Express | SSD | 最大 256,000 IOPS、4,000 MiB/s、レイテンシー 1 ms 未満。耐久性 99.999% | 4 GiB〜64 TiB | 高負荷の DB（Oracle、SAP HANA）。マルチアタッチ可 |
| st1 | HDD | スループット最適化 500 MiB/s | 125 GiB〜16 TiB | ログ、ビッグデータ。ブートには使えない |
| sc1 | HDD | コールド 250 MiB/s。最安 | 同上 | アクセスの少ない大容量 |
IOPS とスループットは別の上限で、ボリュームの側だけでなく、インスタンスタイプの側（EBS の帯域）にも上限があります。「ディスクが遅い」の原因が、インスタンスの側の EBS の帯域の上限であることは珍しくありません。容量・タイプ・IOPS はオンラインで変更できます（Elastic Volumes）。クラウドのストレージの性能の決まり方は、連載「ストレージ入門」第11回「クラウドの性能の決まり方」でも扱います。
EBS スナップショット
スナップショットは EBS のボリュームのある時点のコピーで、S3 に（利用者からは見えない形で）保存されます。初回はフルコピーですが、2 回目以降は前回との差分のブロックだけを保存するため、毎日取得しても容量は差分の分しか増えません。それでいて、途中のスナップショットを削除しても、ほかのスナップショットから復元できるように参照が管理されます（バックアップの「合成フル」に近い動きです。連載「バックアップ入門」第3回「合成フルと永久増分」で扱います）。
スナップショットからは、新しいボリュームを任意の AZ に作れ、これが「別の AZ へのボリュームの移動」や「AMI の作成」（AMI はルートボリュームのスナップショット＋起動の情報）の実体です。
取得はオンラインでできますが、取得した時点で OS が書き込み中のデータの整合性は保証されないため、DB のあるボリュームは静止点を取るか（DB の停止、fsfreeze、Windows の VSS との連携）、RDS のようなマネージドの側の仕組みを使います（静止点は連載「バックアップ入門」第4回「静止点の作り方と開いているファイル」で扱います）。定期的な取得は Data Lifecycle Manager か AWS Backup（後の節）で自動にし、ほかのリージョン・ほかのアカウントへのコピーで DR と隔離を実現します。
- 差分（増分）で保存。途中を削除してもほかの世代から復元できる
- 別の AZ への移動・AMI の作成の実体はスナップショット
- 整合性は OS の側で確保（静止点）。自動化は DLM か AWS Backup
EFS（Elastic File System）
EFS は、AWS のマネージドの NFS です。
- NFSv4.1 のマネージドの共有ファイルシステム。VPC の中の複数の EC2・ECS・Lambda から同時にマウントできる（連載「NFS入門」第11回「クラウドの NFS と Amazon EFS」で詳しく扱います）
- 容量は前もって確保する必要がなく自動で伸び縮みし、課金は使用量（GB・月）。EBS のように「足りなくなる」ことがない
- リージョナル（複数の AZ に複製、既定）と One Zone（単一の AZ、安価）
- ストレージクラス：Standard／Infrequent Access／Archive。ライフサイクルで自動で移す
- スループットモード：Elastic（自動、既定）／Provisioned／Bursting
- 各 AZ に「マウントターゲット」（ENI）が作られ、SG で 2049/tcp を許可する
- Windows からは使えない（NFS クライアントは非対応の扱い）。Windows の共有は FSx for Windows を使う（次の節）
- 1 ファイルあたりの性能は EBS より低く、小さいファイルを大量に扱うと遅くなる。Web のコンテンツの共有やホームディレクトリに向き、DB の置き場には向かない
マウントの例です（amazon-efs-utils を使い、TLS で暗号化します）。
$ sudo mount -t efs -o tls fs-0123abcd:/ /mnt/efs
FSx ファミリー
FSx は、既存のファイルサーバー製品をマネージドで提供するサービス群です。
| サービス | プロトコル | 特徴 | オンプレの対応 |
|---|---|---|---|
| FSx for Windows File Server | SMB | Windows Server ベース。AD との統合（ACL、DFS 名前空間）、シャドウコピー、重複排除。AWS Managed Microsoft AD かオンプレの AD に参加 | Windows のファイルサーバー（SMB、AD。連載「Active Directory入門」第13回、連載「SMB入門」第16回） |
| FSx for NetApp ONTAP | NFS／SMB／iSCSI | ONTAP そのもの。SnapMirror でオンプレの NetApp と複製、マルチプロトコル | NetApp FAS/AFF |
| FSx for OpenZFS | NFS | ZFS。スナップショット・クローンが軽い。低遅延 | ZFS ベースの NAS |
| FSx for Lustre | Lustre | HPC 向けの並列 FS。S3 と連携 | HPC のスクラッチ領域 |
既存の Windows のファイルサーバーを移行する場合は、EFS ではなく FSx for Windows を選びます。AD の ACL がそのまま使え、\\fs-xxxx\share の UNC パスで参照できます。FSx の NFS と Azure の NFS の比較は、連載「NFS入門」第11回「FSx と Azure の NFS」でも扱います。SMB の側から見た FSx for Windows・Azure Files とファイルサーバーの移行の進め方は、このブログの連載「SMB入門」第16回（クラウド・NAS・移行）で扱います。
AWS Backup
AWS Backup は、AWS の複数のサービスのバックアップをまとめて管理するサービスです。
- EBS・EC2（AMI 込み）・EFS・FSx・RDS・Aurora・DynamoDB・S3・Storage Gateway など、複数のサービスのバックアップを 1 つのポリシーで一元管理できる
- バックアッププラン：スケジュール（cron）＋保持期間（日数／世代）＋コールドストレージへの移行＋コピー先（別のリージョン・別のアカウント）を定義し、タグでリソースを自動で割り当てる（
Backup: dailyのタグを付けたら対象になる） - バックアップボールト：保存先。Vault Lock で WORM にすると、管理者でも保持期間の中は削除できない（ランサムウェア対策）
- Organizations と組み合わせて、全アカウントに共通のバックアップのポリシーを強制できる
- 復元のテストを自動で行う機能（Restore testing）もある。「バックアップは復元して初めて価値がある」を、サービスとして実装したもの（連載「バックアップ入門」第11回「復旧テスト」で扱います）
- 費用は保存の容量と復元の量で決まる。EBS のスナップショットを個別に管理するより、まず AWS Backup で統一するのが今の推奨
AWS Backup の構成と Vault Lock の2つのモードは、連載「バックアップ入門」第9回「AWS Backup の構成」「Vault Lock の2つのモード」で詳しく扱います。
データ移行・ハイブリッド接続のサービス
オンプレのデータをクラウドへ移したり、オンプレからクラウドのストレージを使ったりするサービスです。
| サービス | 内容 | 用途 |
|---|---|---|
| AWS DataSync | エージェントを経由して、オンプレの NAS（NFS/SMB）⇄ S3/EFS/FSx をネットワーク経由で高速に同期 | ファイルサーバーの移行、定期的な同期 |
| AWS Transfer Family | マネージドの SFTP／FTPS／FTP／AS2 のサーバー。裏は S3 か EFS | 取引先とのファイルの受け渡し（FTP・SFTP のサーバーをサーバーレスに） |
| Storage Gateway（File） | オンプレに VM を置き、NFS/SMB で見せて実体は S3 に置く | 既存の AP を変えずに S3 を使う |
| Storage Gateway（Volume／Tape） | iSCSI のボリューム／仮想テープライブラリとして見せる | バックアップソフトの保存先をクラウドへ |
| AWS Snow ファミリー | 物理的なデバイスを郵送して、数十 TB〜PB を移送 | 回線では現実的でない大容量の初回の移行（2025年11月7日から新しい顧客は注文できず、2026年12月31日でサポートが終わる。新規は DataSync か Data Transfer Terminal） |
| S3 Transfer Acceleration | エッジを経由して、遠隔地から S3 へ高速にアップロード | 海外の拠点からの転送 |
「オンプレから 100 TB を回線で送ると何日かかるか」は、帯域の計算どおりです。1 Gbps で理論値は約 10 日、実効はその倍以上かかります。DataSync＋Direct Connect か、Data Transfer Terminal（AWS の拠点へストレージを持ち込んで高速に転送する）を検討します。Snowball Edge（Snow ファミリーのデバイス）は、2025 年 11 月 7 日から新しい顧客は使えなくなり、既存の利用者も 2026 年 12 月 31 日でサポートが終わります（その後は Snow のコンソールも使えません。2026年10月時点）。転送の時間と帯域・遅延の関係は、連載「TCP/IP入門」第11回「性能の考え方（RTTと帯域幅遅延積）」と、連載「バックアップ入門」第6回「時間の見積もり①データ量÷実効スループット」で扱います。
Transfer Family は、連載「FTP入門」第11回「AWS Transfer Family」で詳しく扱います。SFTP そのものは同じ連載の第7回「SFTP は SSH の上の別のプロトコル」で扱います。
Azure との対応（ストレージ）
この回のサービスを、Azure の名前と対応させます（2026年9月時点）。
| AWS | Azure | 補足 |
|---|---|---|
| S3 | Blob Storage | Azure は「ストレージアカウント」の中に Blob／Files／Queue／Table がまとまる。アクセス層は Hot／Cool／Cold／Archive |
| S3 のストレージクラス | Blob のアクセス層 | Cold（2023 年に追加）は Standard-IA と Glacier IR の中間 |
| EBS | Managed Disks | Standard HDD／Standard SSD／Premium SSD／Premium SSD v2／Ultra Disk |
| EBS スナップショット | ディスクスナップショット | 増分スナップショットに対応 |
| EFS | Azure Files（NFS 4.1）／Azure NetApp Files | Azure Files は SMB もサポート（AD と統合可） |
| FSx for Windows | Azure Files（SMB、Premium） | ― |
| FSx for ONTAP | Azure NetApp Files | ― |
| AWS Backup | Azure Backup（Recovery Services コンテナー） | ― |
| DataSync／Storage Gateway | Azure File Sync／Data Box Gateway | ― |
| Snow ファミリー | Azure Data Box | ― |
| Transfer Family | Blob Storage の SFTP サポート | ― |
Azure Blob のアクセス層は、連載「バックアップ入門」第7回「クラウドの保存先②：Azure Blobのアクセス層」でも扱います。
考えてみよう
- 冒頭の1つ目の相談で、取引先に 3 日間だけ資料を渡すとします。署名付き URL を使うとき、有効期限と、URL を作る側の権限について何に気を付けますか。
- 冒頭の2つ目の相談のように「S3 にあるからバックアップは要らない」と言われたら、バージョニング・オブジェクトロック・別アカウントへの複製のうち、どれを組み合わせて説明しますか。
- 毎日 50 GB 増え、30 日だけ参照し、7 年保存が必要なログがあります。どのクラスとライフサイクルルールにしますか。最低保存期間に注意してください。
- 「DB のディスクが遅い」と言われました。EBS のボリュームの側と、インスタンスタイプの側で、確かめる上限はそれぞれ何ですか。
- 手元の Windows のファイルサーバーと Linux の NFS サーバーを AWS へ移すとき、それぞれ EFS・FSx のどれを選び、何を使ってデータを移しますか。
ヒント：1 と 2 は「S3 のアクセス制御」「S3 の耐久性・可用性・データ保護機能」、3 は「S3 のストレージクラス」、4 は「EBS のボリュームタイプ」、5 は「FSx ファミリー」「データ移行・ハイブリッド接続のサービス」の節を見直してください。
まとめ
- AWS のストレージは、ブロック（EBS）・ファイル（EFS・FSx）・オブジェクト（S3）・アーカイブ（Glacier）に分けて考える
- S3 はバケット＋キー＋オブジェクトの平坦なキーバリューストア。NAS ではなく HTTP で読み書きする
- イレブンナインは誤削除を防がない。バージョニング・MFA Delete・オブジェクトロック・複製で守る
- アクセスはブロックパブリックアクセスを原則オン、第三者には署名付き URL、Web は CloudFront＋OAC
- EBS は gp3 が既定。IOPS とスループットはボリュームとインスタンスの両方に上限がある
- スナップショットは差分で保存。整合性は静止点で確保し、自動化は AWS Backup に統一する
- Linux の共有は EFS、Windows の共有は FSx for Windows。移行は DataSync・Transfer Family・Storage Gateway
次回は、VPC・サブネット・ルートテーブル・セキュリティグループ・NACL など、ネットワーキングの前編を扱います。
連載「クラウド入門」全14回
- クラウドとは（定義・歴史・責任分界）
- AWSの全体像
- コンピューティング 前編（EC2・Nitro・インスタンスタイプ・AMI・IMDS）
- コンピューティング 後編（課金と購入オプション・Auto Scaling・ELB・コンテナ・Lambda）
- ストレージ（この記事）
- ネットワーキング 前編（VPC・サブネット・SG・NACL）
- ネットワーキング 後編（DNS・接続・Route 53・CloudFront）
- IAMとセキュリティ 前編（IAM・ポリシー・STS・ID連携・Organizations）
- IAMとセキュリティ 後編（KMS・シークレット・ACM・検知と防御）
- データベース
- 運用・監視・コスト 前編（CloudWatch・CloudTrail・Config・SSM）
- 運用・監視・コスト 後編（タグ・転送料金・コスト管理・Control Tower・IaC）
- Well-Architectedフレームワーク
- これまでのテーマとAWSの対応・まとめ
コメント