1. なぜStorage本番運用 Vol1 か — 4本柱選定の現実解

1-1. 本記事のゴール

AWS の本番環境でストレージ選定に悩む場面は多い。EBS は EC2 インスタンスに直接アタッチするブロックストレージとして広く普及しているが、EBS「以外」のストレージサービスを正しく使い分けられているチームは意外と少ない。

本記事は S3・EFS・FSx・Storage Gateway の4本柱を本番運用視点で横断網羅する。各サービスの選定基準、コスト最適化の勘所、セキュリティ設定の落とし穴、Terraform による IaC 実装まで、現場で迷わない決定版ガイドを提供する。

シリーズ全体の文脈として、本軸（第15軸）は以下の位置づけだ。Container 軸・Serverless 軸でアプリケーション基盤を確立した後、そのワークロードが扱うデータをどのストレージサービスに格納・保護・最適化するか、という実装判断を扱う。

1-2. 読者像

本記事が最も価値を提供できるのは、以下のような背景を持つエンジニアだ。

• EKS・ECS・Lambda 環境で ブロックストレージ（EBS）以外の Storage 選定に迷っている
• S3 は日常的に使うが、EFS / FSx / Storage Gateway の使い分けが直感的にわからない
• Lifecycle Policy を設定したが コスト最適化の効果が出ていない
• 大規模ファイル共有基盤の設計で EFS と FSx どちらを選ぶべきか 判断できない
• Storage Gateway を勧められたが File / Volume / Tape の違いが整理できていない

特に「S3 は使えるが、それ以外で判断が止まる」層に向けて、選定フローと実装例をセットで提示する。

1-3. なぜ今これを書くか

Container・Serverless 軸では ECS/Fargate・Lambda のコンピュート基盤はカバーしてきた。しかし、それらのワークロードが依存するストレージ層を S3 以外まで横断比較した決定版ガイド は市場に少ない。

現場ではストレージ選定を誤ったことで発生するコスト爆発・性能劣化・セキュリティインシデントが後を絶たない。本記事はその判断コストを下げ、最初から正しい設計を選べるよう体系化した。

1-4. 4本柱 選定フロー — 現場の判断基準

以下の選定フローを最初の判断軸として使うことで、ほとんどのケースを網羅できる。

ファーストチョイスのルール：
1. 非構造化データ・API アクセス → S3：画像・動画・ログ・バックアップ・静的コンテンツはまず S3 を検討する
2. Linux 共有ファイルシステム（NFS）→ EFS：ECS タスク間・EKS Pod 間でファイル共有が必要な場合
3. 高性能 HPC / Windows ファイルサーバー / ONTAP → FSx：Lustre（HPC）、Windows FS（SMB）、NetApp ONTAP の要件がある場合
4. オンプレミスからクラウドへの段階移行・ハイブリッド → Storage Gateway：既存オンプレミスシステムを変更せずにクラウドストレージを活用する場合

1-5. EKS / Container / Serverless との連携ポイント

モダンなコンテナ・サーバーレス環境でのストレージ連携パターンを整理する。

EKS（Kubernetes）での利用：
– S3：AWS SDK / S3 Mountpoint を使用。Mountpoint for Amazon S3 は FUSE ベースで S3 をローカルファイルシステムとしてマウント可能
– EFS：EFS CSI Driver を使い、PersistentVolume として Pod からマウント。ReadWriteMany（RWX）が必要な場合の第一選択
– FSx for Lustre：FSx CSI Driver を使用。ML トレーニングジョブで大規模データセットを高速スキャンする用途に最適

ECS/Fargate での利用：
– EFS をタスク定義のボリュームとしてマウントし、コンテナ間でファイル共有。Fargate の場合 EBS ではなく EFS のみ共有可能（Fargate は EBS 一時ストレージのみ）

Lambda での利用：
– EFS を Lambda レイヤーとしてマウントし、大容量の ML モデルや共有ライブラリを格納。Lambda の /tmp は 10GB だが、EFS は事実上無制限

Container 基盤の詳細は Container本番運用 Vol1 を、サーバーレス基盤は Serverless本番運用 Vol1 を参照されたい。

2. S3本番運用 — Storage Class × Lifecycle × Versioning × Object Lock

S3 は AWS の中核ストレージサービスであり、単純な「オブジェクトストア」として使うだけでなく、Storage Class 戦略・Lifecycle Policy・Versioning・Object Lock を組み合わせることで、コスト最適化とデータ保護を同時に実現できる。

2-1. Storage Class 選定マトリクス — 7階層の使い分け

S3 には 7 種類の Storage Class が存在し、それぞれアクセス頻度・可用性要件・コストが異なる。

Intelligent-Tiering の本番デフォルト化： アクセスパターンが不明または変動する場合、Intelligent-Tiering を本番デフォルトとして採用することを推奨する。ただし、128KB 未満の小容量オブジェクトは監視費用がストレージ節約を上回るため、専用プレフィックスを設けて Standard か Standard-IA を使い分けるのが現実解だ。

コスト早見表（東京リージョン概算、2024年時点）：
– Standard: $0.025/GB/月
– Standard-IA: $0.019/GB/月（最低 30 日保証課金）
– Glacier Flexible: $0.005/GB/月
– Deep Archive: $0.002/GB/月

2-2. Intelligent-Tiering — コスト閾値と自動階層化の仕組み

Intelligent-Tiering は、オブジェクトのアクセス履歴を S3 が自動で監視し、アクセス頻度に応じて 4〜5 層のアクセス層を自動移行する。

アクセス層の構成：
– 頻繁アクセス層（Frequent Access）：Standard 相当のレイテンシ・コスト
– 低頻度アクセス層（Infrequent Access）：30日間アクセスなしで自動移行。Standard-IA 相当のコスト
– アーカイブインスタントアクセス層：オプション有効化で 90 日後に自動移行。Glacier Instant 相当
– アーカイブアクセス層：オプション有効化で 90 日後。Glacier Flexible 相当
– ディープアーカイブアクセス層：オプション有効化で 180 日後。Deep Archive 相当

監視費用の計算： オブジェクト 1,000 件あたり $0.0025/月（東京）。1 億件のオブジェクトを格納する場合、月 $250 の監視費用が発生する。128KB 未満のオブジェクトは監視費用がストレージ節約を確実に上回るため、Intelligent-Tiering から除外することを原則とする。

2-3. Lifecycle Policy 設計 — mermaid01: S3 Lifecycle State 遷移

S3 オブジェクトのライフサイクル遷移を状態図で表現すると、以下のようになる。

“`mermaid
stateDiagram-v2
[*] –> Standard : PUT（新規アップロード）
Standard –> IntelligentTiering : Lifecycle移行（即日可）
Standard –> StandardIA : Lifecycle移行（30日以降）
Standard –> OneZoneIA : Lifecycle移行（30日以降）
Standard –> GlacierInstant : Lifecycle移行（90日以降）
StandardIA –> GlacierInstant : Lifecycle移行（90日以降）
StandardIA –> GlacierFlexible : Lifecycle移行（90日以降）
GlacierInstant –> GlacierFlexible : Lifecycle移行（90日以降）
GlacierFlexible –> DeepArchive : Lifecycle移行（180日以降）
Standard –> Deleted : Expiration（有効期限切れ削除）
StandardIA –> Deleted : Expiration
GlacierFlexible –> Deleted : Expiration
DeepArchive –> Deleted : Expiration
IntelligentTiering –> FreqAccess : アクセス検出
IntelligentTiering –> InfreqAccess : 30日アクセスなし
InfreqAccess –> FreqAccess : アクセス復帰
InfreqAccess –> ArchiveAccess : 90日アクセスなし（オプション）

state IntelligentTiering {
 FreqAccess : 頻繁アクセス層
 InfreqAccess : 低頻度アクセス層
 ArchiveAccess : アーカイブアクセス層
}

“`text

設計の重要原則：
– 同一バケット内のオブジェクトを用途別にプレフィックスで分類し、プレフィックスごとに Lifecycle ルールを設定する
– logs/ → 30日で IA、90日で Glacier、365日で削除
– backups/ → 90日で Glacier Flexible、2555日（7年）で削除（法定保存）
– uploads/ → Intelligent-Tiering で自動最適化
– 不完全なマルチパートアップロードの削除は必ず設定する（7日が目安）。放置すると課金が蓄積する

2-4. Versioning + MFA Delete — 改ざん防止の本番構成

バージョニングを有効にすると、オブジェクトの上書き・削除操作がすべてバージョン履歴として保持される。本番バケットではバージョニングの有効化を原則とする。

MFA Delete： バージョニング状態の変更（有効→無効）やバージョンの永続削除に MFA 認証を要求する機能。ルートアカウントと MFA デバイスを紐付けた上で、CLI から設定する。コンソール操作では設定できない点に注意。

bash
aws s3api put-bucket-versioning \
--bucket my-production-bucket \
--versioning-configuration Status=Enabled,MFADelete=Enabled \
--mfa "arn:aws:iam::123456789012:mfa/root-account-mfa-device 123456"text

ライフサイクルとバージョニングの組み合わせ： バージョニング有効時は、NoncurrentVersionTransition と NoncurrentVersionExpiration で古いバージョンの移行・削除を設定する。設定しないと旧バージョンが無期限に蓄積しコスト増大を招く。

2-5. Object Lock — Compliance モードと Governance モードの使い分け

Object Lock は WORM（Write Once Read Many）モデルを実装し、指定期間内のオブジェクト削除・上書きを防止する。金融・医療・法令対応で必要となる改ざん防止要件を満たす。

2つのモード：

本番での推奨は Governance モード を日常運用に使い、法的要件のあるデータのみ Compliance モード を適用するハイブリッド構成だ。Object Lock はバケット作成時にのみ有効化できる（既存バケットへの後付け不可）。

Legal Hold： 保持期間とは独立して、Legal Hold フラグを設定したオブジェクトは Legal Hold 解除まで削除・上書き不可となる。訴訟・監査対応に活用する。

2-6. Block Public Access — 4設定の意味と本番デフォルト

Block Public Access は以下の4設定から構成される。本番環境では 全4設定を有効（true） にすることが絶対的なベストプラクティスだ。

BlockPublicAcls と IgnorePublicAcls の両方を有効にすることで、ACL によるパブリックアクセスを完全に防止できる。BlockPublicPolicy と RestrictPublicBuckets はバケットポリシーによるパブリックアクセスを防止する。4つすべてを有効にしないと意図しない隙間が生じる。

2-7. VPC Endpoint for S3 — Gateway 型 vs Interface 型

S3 への通信を VPC 内で完結させる VPC Endpoint には 2 種類がある。

本番推奨： EC2・ECS・EKS から S3 にアクセスする場合は Gateway 型を無料で使用し、NAT Gateway 経由の転送費用を回避 する。Gateway 型は同一リージョン内のみ有効で、S3 と DynamoDB にのみ対応している。

オンプレミスから Direct Connect / VPN 経由で S3 にプライベートアクセスする場合は Interface 型（PrivateLink）を使用する。Network 設計の詳細は Network本番運用 Vol1 を参照されたい。

2-8. Terraform 実装 — aws_s3_bucket 本番構成

以下は S3 バケットの本番構成を Terraform で実装した例だ。セキュリティ設定（Block Public Access・SSE-KMS・バケットキー）とバージョニングをセットで定義する。

“`hcl
resource “aws_s3_bucket” “production” {
bucket = “my-production-bucket-${var.environment}”

tags = {
Environment = var.environment
ManagedBy= “Terraform”
CostCenter = var.cost_center
}
}

resource “aws_s3_bucket_versioning” “production” {
bucket = aws_s3_bucket.production.id
versioning_configuration {
status = “Enabled”
}
}

resource “aws_s3_bucket_server_side_encryption_configuration” “production” {
bucket = aws_s3_bucket.production.id
rule {
apply_server_side_encryption_by_default {
sse_algorithm = “aws:kms”
kms_master_key_id = aws_kms_key.s3.arn
}
bucket_key_enabled = true
}
}

resource “aws_s3_bucket_public_access_block” “production” {
bucket= aws_s3_bucket.production.id
block_public_acls = true
block_public_policy = true
ignore_public_acls= true
restrict_public_buckets = true
}

resource “aws_s3_bucket_versioning” “production” {
bucket = aws_s3_bucket.production.id
versioning_configuration {
status = “Enabled”
}
}
“`text

KMS キーの Bucket Key 有効化（bucket_key_enabled = true）は必須設定だ。Bucket Key を有効にすることで、各オブジェクト暗号化時の KMS API コール数を最大 99% 削減でき、KMS 料金を大幅に抑制できる。IAM ポリシー設計については Database本番運用 Vol1 のアクセス制御パターンも参考になる。

2-9. Terraform 実装 — aws_s3_bucket_lifecycle_configuration 本番構成

Lifecycle Policy の Terraform 実装では、用途別プレフィックスに応じたルールと、不完全なマルチパートアップロードの自動クリーンアップを必ず含める。

“`hcl
resource “aws_s3_bucket_lifecycle_configuration” “production” {
bucket = aws_s3_bucket.production.id

rule {
id = “logs-tiering”
status = “Enabled”

filter {
  prefix = "logs/"
}

transition {
  days = 30
  storage_class = "STANDARD_IA"
}

transition {
  days = 90
  storage_class = "GLACIER"
}

transition {
  days = 365
  storage_class = "DEEP_ARCHIVE"
}

expiration {
  days = 2555
}

noncurrent_version_transition {
  noncurrent_days = 30
  storage_class= "STANDARD_IA"
}

noncurrent_version_expiration {
  noncurrent_days = 90
}

}

rule {
id = “uploads-intelligent-tiering”
status = “Enabled”

filter {
  prefix = "uploads/"
}

transition {
  days = 0
  storage_class = "INTELLIGENT_TIERING"
}

}

rule {
id = “multipart-cleanup”
status = “Enabled”

filter {
  prefix = ""
}

abort_incomplete_multipart_upload {
  days_after_initiation = 7
}

}
}
“`text

設計のポイント：
– noncurrent_version_transition と noncurrent_version_expiration を設定することで、バージョニング有効バケットでの旧バージョン蓄積によるコスト増大を防止
– abort_incomplete_multipart_upload はバケット全体（prefix = ""）に適用する。これを忘れると大容量ファイルのアップロード失敗時に途中データが無期限に残存し、課金が継続する
– INTELLIGENT_TIERING は days = 0（即時移行）で指定可能

3. EFS本番運用 — Performance Mode × Throughput Mode × Access Points

Amazon EFS（Elastic File System）は、複数のEC2インスタンスやコンテナから同時にマウントできるフルマネージドNFSファイルシステムだ。S3がオブジェクトストレージであるのに対し、EFSはPOSIX互換のファイルシステムとして機能し、EKSのPersistent Volume、CIビルドキャッシュ、マルチAZの共有ストレージなど、幅広いユースケースで採用されている。

本番運用において重要なのは、Performance Mode・Throughput Mode・ストレージクラス・Access Pointsの4軸を正しく組み合わせることだ。誤った選択は性能急落やコスト爆発につながる。

3-1. Performance Mode：General Purpose vs Max I/O

EFSのPerformance Modeはファイルシステム作成時にのみ選択でき、後から変更できない。最初の選択が本番運用に長期間影響するため、慎重に判断する必要がある。

General Purposeが本番デフォルトだ。Max I/Oはレイテンシが増加するため、HPC・科学計算・ゲノム解析など、超高並列かつスループット優先のワークロードに限定すべきだ。EKSのPVCや標準的なアプリケーションサーバーでMax I/Oを選ぶメリットはほぼない。

3-2. Throughput Mode：Bursting / Provisioned / Elastic の選定

Throughput Modeは後から変更可能であり、ワークロードの成長に合わせて調整できる。3種類のモードがあり、それぞれ特性が大きく異なる。

Bursting Throughput（デフォルト）

ファイルシステムのサイズに応じてベーススループットが決まり、バーストクレジットを消費してピーク性能を出す仕組みだ。

• ベーススループット: 1 TB あたり 50 MB/s
• バーストスループット: 最大 100 MB/s（ファイルシステムサイズ <1 TB の場合）または 1 TB あたり 100 MB/s
• バーストクレジット: アイドル時に蓄積、高負荷時に消費

落とし穴: ファイルシステムが小さい場合（例: 100 GB）、ベーススループットはわずか 5 MB/s だ。CIビルドで一時的に大量ファイルを書き込む場合、バーストクレジットを使い切ると 5 MB/s に落ちてビルド時間が数倍になる。BurstCreditBalance CloudWatchメトリクスが 0 に近づいたら要注意だ。

Provisioned Throughput

ファイルシステムサイズに依存せず、任意のスループットを固定でプロビジョニングできる。スパイクアクセスが予測可能で、かつ高スループットが継続的に必要な場合に適している。

• 最大 3,072 MB/s まで設定可能
• コスト: $0.06/MB/s/月（Bursting比較で高コスト）
• 用途: メディア処理、安定した高スループットが必要なデータパイプライン

Elastic Throughput（推奨）

2022年に追加された最新モード。スループットを自動スケールし、使用した分だけ課金される従量制だ。

• 読み取り: 最大 3 GB/s
• 書き込み: 最大 1 GB/s
• バースト不要・クレジット管理不要
• コスト: $0.06/GB（読み取り）/ $0.06/GB（書き込み）

新規構築は Elastic Throughput をデフォルトとすること。Burstingはレガシー構成として残っているが、Elasticの方がコスト効率・運用負担の両面で優れている。

3-3. EFS-IA（Infrequent Access）階層化とライフサイクル管理

EFSはStandardとInfrequent Access（IA）の2ストレージクラスを持ち、ライフサイクルポリシーで自動移行できる。コストはIA移行後に最大92%削減できるが、アクセス時の追加課金に注意が必要だ。

ストレージクラスの料金比較（東京リージョン）

ライフサイクルポリシーの設定

Terraformで設定する場合：

“`hcl
resource “aws_efs_file_system” “main” {
creation_token= “production-efs”
performance_mode = “generalPurpose”
throughput_mode = “elastic”
encrypted = true
kms_key_id = aws_kms_key.efs.arn

lifecycle_policy {
transition_to_ia = “AFTER_30_DAYS”
transition_to_primary_storage_class = “AFTER_1_ACCESS”
}

tags = {
Name = “production-efs”
Environment = “production”
}
}
“`text

transition_to_iaはAFTER_7_DAYSからAFTER_365_DAYSまで設定可能。transition_to_primary_storage_class = "AFTER_1_ACCESS"を設定すると、IAファイルにアクセスした際に自動でStandardに戻すRestore Storage機能が有効になる。

3-4. Access Points：マルチテナント分離とEKS連携

EFS Access Pointsは、単一のEFSファイルシステムに対して複数のアプリケーションやチームが安全に分離してアクセスするための仕組みだ。POSIX UID/GIDを強制することで、意図しないファイルアクセスを防止できる。

Access Pointの主な特徴

• ルートディレクトリの強制: アクセスポイントごとに異なるルートパスを設定（例: /app1, /app2）
• POSIX ID強制: 接続クライアントのUID/GIDを上書き（NFS mount時のUID/GIDに依存しない）
• IAM認証との組み合わせ: IAM policyでアクセスポイントを制限し、最小権限を実現

Terraform 実装（フル構成）

“`hcl
resource “aws_efs_file_system” “main” {
creation_token= “production-efs”
performance_mode = “generalPurpose”
throughput_mode = “elastic”
encrypted = true
kms_key_id = aws_kms_key.efs.arn

lifecycle_policy {
transition_to_ia = “AFTER_30_DAYS”
}

tags = {
Name = “production-efs”
Environment = “production”
}
}

resource “aws_efs_mount_target” “main” {
for_each = toset(var.private_subnet_ids)

file_system_id = aws_efs_file_system.main.id
subnet_id = each.value
security_groups = [aws_security_group.efs.id]}

resource “aws_security_group” “efs” {
name = “efs-sg”
description = “EFS mount target security group”
vpc_id= var.vpc_id

ingress {
from_port = 2049
to_port= 2049
protocol = “tcp”
security_groups = [aws_security_group.app.id] }

egress {
from_port= 0
to_port = 0
protocol = “-1”
cidr_blocks = [“0.0.0.0/0”] }
}

resource “aws_efs_access_point” “app1” {
file_system_id = aws_efs_file_system.main.id

root_directory {
path = “/app1”
creation_info {
owner_gid= 1001
owner_uid= 1001
permissions = “755”
}
}

posix_user {
gid = 1001
uid = 1001
}

tags = {
Name = “app1-access-point”
}
}

resource “aws_efs_access_point” “app2” {
file_system_id = aws_efs_file_system.main.id

root_directory {
path = “/app2”
creation_info {
owner_gid= 1002
owner_uid= 1002
permissions = “755”
}
}

posix_user {
gid = 1002
uid = 1002
}

tags = {
Name = “app2-access-point”
}
}

resource “aws_kms_key” “efs” {
description = “KMS key for EFS encryption”
deletion_window_in_days = 7
enable_key_rotation = true
}
“`text

3-5. EFS CSI Driver：EKSとのPVC/PV連携

EKS（Kubernetes）からEFSを使用する場合、Amazon EFS CSI Driverを経由してPersistentVolume（PV）としてマウントする。ReadWriteMany（RWX）をサポートするため、複数のPodから同一ボリュームへの読み書きが可能だ。これはEBSでは不可能な特性であり、CIキャッシュや共有設定ファイルの管理に有効だ。

EKS連携のアーキテクチャと詳細な設定手順については、EKS本番クラスター設計 (IRSA × ALB Ingress)も参照されたい。

EFS CSI Driver インストール（Terraform）

“`hcl
resource “aws_eks_addon” “efs_csi_driver” {
cluster_name = aws_eks_cluster.main.name
addon_name = “aws-efs-csi-driver”
addon_version = “v1.7.6-eksbuild.1”

service_account_role_arn = aws_iam_role.efs_csi_driver.arn
}

resource “aws_iam_role” “efs_csi_driver” {
name = “eks-efs-csi-driver”

assume_role_policy = jsonencode({
Version = “2012-10-17”
Statement = [{
Effect = “Allow”
Principal = {
Federated = aws_iam_openid_connect_provider.eks.arn
}
Action = “sts:AssumeRoleWithWebIdentity”
Condition = {
StringEquals = {
“${replace(aws_iam_openid_connect_provider.eks.url, “https://”, “”)}:sub” = “system:serviceaccount:kube-system:efs-csi-controller-sa”
}
}
}] })
}

resource “aws_iam_role_policy_attachment” “efs_csi_driver” {
policy_arn = “arn:aws:iam::aws:policy/service-role/AmazonEFSCSIDriverPolicy”
role = aws_iam_role.efs_csi_driver.name
}
“`text

StorageClass と PVC の定義（Kubernetes マニフェスト）

“`yaml

StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: efs-sc
provisioner: efs.csi.aws.com
parameters:
provisioningMode: efs-ap
fileSystemId: fs-xxxxxxxxxxxxxxxxx
directoryPerms: “700”
gidRangeStart: “1000”
gidRangeEnd: “2000”

PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: efs-claim
spec:
accessModes:
– ReadWriteMany
storageClassName: efs-sc
resources:
requests:
storage: 10Gi
“`text

3-6. セキュリティ設計：KMS暗号化・Security Group・VPC配置

EFSの本番セキュリティは以下の3層で構成する。

1. 保管時暗号化（KMS）

encrypted = true と kms_key_id を必ず設定する。デフォルトのAWS管理キー（aws/elasticfilesystem）でも暗号化自体は有効だが、本番環境ではカスタマー管理キー（CMK）を使用してキーポリシーを明示的に制御すること。

2. 転送中暗号化（TLS）

EFS mount helperを使用する場合、-o tls オプションでNFSトラフィックをTLS暗号化できる：

“`bash

TLS付きマウント

mount -t efs -o tls fs-xxxxxxxxx:/ /mnt/efs

/etc/fstab への記載

fs-xxxxxxxxx:/ /mnt/efs efs defaults,tls 0 0
“`text

3. Security Group設計

NFS（TCP 2049）のみを許可し、送信元をアプリケーション層のSecurity Group IDに限定する：

“`hcl

EFS側: NFS ingress をアプリSGからのみ許可

ingress {
from_port = 2049
to_port= 2049
protocol = “tcp”
security_groups = [aws_security_group.app.id]}

アプリ側: EFS SGへのegress

egress {
from_port = 2049
to_port= 2049
protocol = “tcp”
security_groups = [aws_security_group.efs.id]}
“`text

CIDRブロック（0.0.0.0/0）での許可は禁止。必ずSecurity Group IDで参照すること。

VPC配置とMount Target

各AZにMount Targetを配置することでマルチAZ耐障害性を確保する。Mount Targetはプライベートサブネットにのみデプロイし、パブリックサブネットへの配置は禁止だ。

“`bash

Mount Target の確認

aws efs describe-mount-targets \
–file-system-id fs-xxxxxxxxx \
–query ‘MountTargets[].{AZ:AvailabilityZoneName, State:LifeCycleState, IP:IpAddress}’
“`text

4. FSx本番運用 — Windows × Lustre × NetApp ONTAP × OpenZFS 4種選定

Amazon FSxはAWSが提供するフルマネージドファイルシステムサービスで、4種類のファイルシステムエンジンをサポートする。各種別はプロトコル・性能特性・連携サービスが大きく異なり、ワークロード要件に応じた選定が運用コストと性能に直結する。

4-0. FSx 4種 選定マトリクス

選定判断フロー:
– Windowsアプリ + Active Directory → FSx for Windows File Server
– HPC/ML一時ストレージ + S3連携 → FSx for Lustre
– NFS+SMB両対応 + オンプレONTAP移行 → FSx for NetApp ONTAP
– Linux高機能ファイルシステム + ZFS機能 → FSx for OpenZFS

4-1. FSx for Windows File Server

Active Directory 統合アーキテクチャ

FSx for Windows File ServerはMicrosoftのActive Directory (AD) との統合を前提に設計されており、AD連携なしでは利用できない。AWS Managed Microsoft ADまたはself-managed ADの両方をサポートする。

AD連携の仕組み:
1. FSxファイルシステム作成時にAD情報を指定する
2. FSxはADドメインに自動参加し、コンピュータオブジェクトを作成する
3. SMBプロトコル経由でADユーザー・グループの認証が有効化される
4. KerberosチケットによるSSO (シングルサインオン) が実現する

text
AWS Managed Microsoft AD ←→ FSx for Windows File Server
↕↕ SMB 3.0
EC2 (Windows) ←─────────────────── ドライブマウント
EC2 (Linux) ←─────────────────── kinit + cifs-utilstext

AWS Managed AD vs セルフマネージドAD:

DFS名前空間 (DFS Namespace)

DFS名前空間を使うと複数のFSxファイルシステムを単一の論理パスで公開できる。例えば \\corp\share という単一パスの背後に複数のFSxシステムを配置し、地域別・用途別にトラフィックを分散できる。

DFS-R (レプリケーション) との違い: FSx for Windowsは自動バックアップとマルチAZ展開を提供するため、DFS-Rによる独自レプリケーションは不要になるケースが多い。

バックアップ戦略

FSx for Windows File Serverは2種類のバックアップをサポートする:

1. 自動バックアップ: 毎日自動実行。保持期間0〜90日で設定可能。デフォルト30日
2. 手動バックアップ: コンソール/CLI/API経由で任意のタイミングで実行
3. AWS Backupとの統合: 集中管理・クロスリージョンコピーに対応

バックアップはVSSを使用するため、Windowsアプリケーション整合性が保証される。

4-2. FSx for Lustre

Lustre ファイルシステムの特性

FSx for LustreはオープンソースのLustreファイルシステムをAWSがマネージドサービスとして提供したもの。数百万IOPS・数TB/sのスループットを実現し、科学技術計算・機械学習・大規模データ処理に特化している。

デプロイメントタイプ:

SCRATCH vs PERSISTENT の使い分け:
– ジョブ実行中のみデータが必要 → SCRATCH (コスト最安)
– 計算結果を長期保持 → PERSISTENT + 定期S3エクスポート
– HA要件あり → PERSISTENT (自動レプリケーション)

S3 連携 (Data Repository)

FSx for LustreはS3バケットとのデータリポジトリ連携が可能で、S3上のデータを透過的にLustreファイルシステム経由でアクセスできる。

データフロー:
text
S3バケット (ソース)
↓ インポート (遅延読み込み / 事前ロード)
FSx for Lustre (高速ストレージ)
↓ 計算処理
↓ エクスポート (書き戻し)
S3バケット (結果保存)text

インポート設定:
– --import-path s3://bucket/prefix : S3からLustreへの自動インポートパスを設定
– --auto-import-policy: NEW / CHANGED / DELETED イベントで自動同期
– 遅延読み込み: ファイルアクセス時にS3から自動ダウンロード (コスト節約)

エクスポート設定:
– --export-path s3://bucket/results : 結果データの書き戻し先
– create-data-repository-task コマンドで手動エクスポートも可能

4-3. FSx for NetApp ONTAP

マルチプロトコル対応の優位性

FSx for NetApp ONTAPは同一ファイルシステムを複数プロトコルで同時アクセスできる唯一のFSx種別。NFS・SMB・iSCSIを同時使用でき、LinuxサーバーとWindowsサーバーが同じストレージを共有できる。

マルチプロトコル同時アクセス:
text
Linux ─── NFS v4.1 ──────┐
Windows ── SMB 3.0 ───────┼── FSx for NetApp ONTAP (SVM)
VMware ─── iSCSI ─────────┘↕ SnapMirror
オンプレ ONTAP (DR/移行)text

Storage Virtual Machine (SVM) アーキテクチャ

FSx ONTAPの最大の特徴はSVM (Storage Virtual Machine) によるマルチテナント対応。1つのFSxファイルシステム内に複数のSVMを作成でき、各SVMが独立したネームスペース・プロトコル・セキュリティポリシーを持つ。

SVM活用パターン:
– 本番/ステージング/開発で別SVMを作成し同一FSxを共有
– 部門別に別SVMを作成してアクセス制御を分離
– DR用SVMをセカンダリリージョンに作成してSnapMirrorで複製

FlexClone と SnapMirror

FlexClone: ボリュームのゼロコピークローンを瞬時作成。100GBのボリュームを追加コストゼロで複製でき、開発・テスト環境のデータ準備に強力。実際の差分データのみストレージを消費する。

SnapMirror: ブロックレベルの非同期レプリケーション。オンプレのNetApp ONTAPからFSx ONTAPへのクラウド移行に最適で、初回フル転送後は差分のみ転送するため帯域効率が高い。

AWS Backup統合:
FSx ONTAPはAWS Backupと統合されており、バックアップ・DR戦略の詳細で説明したクロスリージョンバックアップポリシーをそのまま適用できる。

4-4. FSx for OpenZFS

ZFS の主要機能

FSx for OpenZFSはオープンソースのZFSファイルシステムエンジンをベースとし、データ整合性・高圧縮・高速スナップショットをクラウドで提供する。

ZFSの特徴的な機能:

デプロイメントタイプ:
– Single-AZ: 単一AZに配置。低レイテンシ・低コスト。開発/テスト向け
– Multi-AZ (PERSISTENT_2): 2AZ間でデータを同期。本番環境向け

Linux HPC ワークロードへの適用

FSx for OpenZFSはNFS v4.1対応で、LinuxのHPCクラスターに直接マウントできる。Lustreほどの超高スループットは不要だが、ZFSの高圧縮によりストレージコストを抑えつつ高性能が必要なワークロードに向く。

Linux マウント設定 (NFS):
bash
sudo mount -t nfs \
-o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600 \
fs-xxxxxxxxx.fsx.ap-northeast-1.amazonaws.com:/fsx \
/mnt/fsxtext

/etc/fstab 永続化:
text
fs-xxxxxxxxx.fsx.ap-northeast-1.amazonaws.com:/fsx /mnt/fsx nfs nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600 0 0text

ZFS スナップショット活用

FSx OpenZFSのスナップショットはボリューム変更の瞬時コピーで、容量は差分データのみ消費する。AWS Backupとの統合により定期スナップショット→S3アーカイブのパイプラインを自動化できる。

4-5. Terraform実装: FSx for Windows File Server (AD統合・Multi-AZ)

“`hcl
resource “aws_directory_service_directory” “main” {
name = “corp.example.com”
password = var.ad_admin_password
type = “MicrosoftAD”
edition = “Standard”

vpc_settings {
vpc_id = aws_vpc.main.id
subnet_ids = [
aws_subnet.private_a.id,
aws_subnet.private_c.id,
] }

tags = {
Name = “corp-ad”
Environment = “production”
}
}

resource “aws_fsx_windows_file_system” “main” {
active_directory_id = aws_directory_service_directory.main.id
storage_capacity = 300
storage_type = “SSD”
throughput_capacity = 512
automatic_backup_retention_days = 30

deployment_type = “MULTI_AZ_1”
preferred_subnet_id = aws_subnet.private_a.id
subnet_ids = [
aws_subnet.private_a.id,
aws_subnet.private_c.id,
]

security_group_ids = [aws_security_group.fsx_windows.id]

self_managed_active_directory {
dns_ips = var.self_managed_ad_dns_ips
domain_name = var.self_managed_ad_domain
username = var.self_managed_ad_username
password = var.self_managed_ad_password
organizational_unit_distinguished_name = var.self_managed_ad_ou
}

audit_log_configuration {
file_access_audit_log_level = “SUCCESS_AND_FAILURE”
file_share_access_audit_log_level = “SUCCESS_AND_FAILURE”
audit_log_destination = aws_cloudwatch_log_group.fsx_audit.arn
}

tags = {
Name = “corp-fsx-windows”
Environment = “production”
Tier = “storage”
}
}

resource “aws_security_group” “fsx_windows” {
name = “fsx-windows-sg”
description = “Security group for FSx Windows File Server”
vpc_id= aws_vpc.main.id

ingress {
description = “SMB from internal”
from_port= 445
to_port = 445
protocol = “tcp”
cidr_blocks = [aws_vpc.main.cidr_block] }

ingress {
description = “SMB over UDP”
from_port= 445
to_port = 445
protocol = “udp”
cidr_blocks = [aws_vpc.main.cidr_block] }

ingress {
description = “RPC endpoint mapper”
from_port= 135
to_port = 135
protocol = “tcp”
cidr_blocks = [aws_vpc.main.cidr_block] }

ingress {
description = “DFS replication”
from_port= 5985
to_port = 5985
protocol = “tcp”
cidr_blocks = [aws_vpc.main.cidr_block] }

egress {
from_port= 0
to_port = 0
protocol = “-1”
cidr_blocks = [“0.0.0.0/0”] }

tags = {
Name = “fsx-windows-sg”
}
}

resource “aws_cloudwatch_log_group” “fsx_audit” {
name = “/aws/fsx/windows/audit”
retention_in_days = 90

tags = {
Name = “fsx-windows-audit-logs”
}
}
“`text

Terraform実装ポイント:
– MULTI_AZ_1 指定で2AZ間の冗長構成が有効化される
– audit_log_configuration でファイルアクセス監査ログをCloudWatch Logsに送信
– セキュリティグループでSMB (445/TCP+UDP)・RPC (135) を内部VPC CIDRに限定
– self_managed_active_directory ブロックはセルフマネージドAD使用時のみ記述 (AWS Managed ADの場合は active_directory_id のみ)

4-6. FSx パフォーマンス最適化

スループットキャパシティの選定

スループットはCPU・ネットワーク帯域と連動するため、EC2インスタンスタイプとのバランスも考慮する。FSx WindowsはSSD vs HDDでもスループット上限が異なる。

Direct Connect 連携

オンプレミスからFSxへのアクセスにはAWS Direct Connectの活用が推奨される。パブリックインターネット経由ではレイテンシが不安定になり、SMBプロトコルの性能が著しく低下する。

• プライベートVIF: VPC内のFSxエンドポイントに直接アクセス
• 推奨帯域: FSxスループットキャパシティの2倍以上のDX帯域を確保
• フォールバック: Site-to-Site VPNをバックアップ回線として構成

関連記事:
– AWSバックアップ・DR本番運用: FSx自動バックアップとAWS Backupを使ったクロスリージョンDR設計
– AWS Direct Connect・VPN ハイブリッド接続: オンプレ-FSx間の安定した接続設計

5. Storage Gateway本番運用 — File × Volume × Tape Gateway 用途別

Storage Gateway はオンプレミスとAWSクラウドを透過的に接続するハイブリッドストレージサービスだ。File / Volume / Tape の3種別がある。用途を誤ると性能劣化・コスト超過・DR失敗の3拍子が揃う。本章では用途別の正しい選定と本番設計の勘所を解説する。Gateway 選定フローは本章末尾の §5-5 (mermaid02) を参照されたい。

5-1. File Gateway (NFS/SMB → S3 バックアップ)

File Gateway はオンプレのファイルサーバが NFS または SMB でアクセスできるインターフェースを提供し、バックグラウンドで S3 にデータを保存する。バックアップ・アーカイブ・コンテンツ配信の起点として最適だ。

アーキテクチャ概要

• オンプレのアプリケーションサーバは NFS (Linux) または SMB (Windows) で File Gateway にマウント
• File Gateway はローカルキャッシュに書き込み → 非同期で S3 へアップロード
• S3 上のオブジェクトはネイティブS3オブジェクトとして扱えるため、Lambda/Athena との連携も容易

キャッシュサイズ設計

キャッシュが枯渇すると S3 へのリード時にレイテンシが増大する。CachePercentUsed CloudWatch メトリクスを監視し、80% 超でアラートを設定せよ。

S3 File Gateway — ユースケース別設定

“`hcl

Terraform: S3 File Gateway ファイル共有作成

resource “aws_storagegateway_nfs_file_share” “backup” {
client_list = [“10.0.0.0/8”] gateway_arn = aws_storagegateway_gateway.main.arn
location_arn = “arn:aws:s3:::${aws_s3_bucket.backup.id}”
role_arn = aws_iam_role.storage_gateway_s3.arn

nfs_file_share_defaults {
directory_mode = “0755”
file_mode= “0644”
group_id = 65534
owner_id = 65534
}

cache_attributes {
cache_stale_timeout_in_seconds = 300
}

tags = {
Environment = “production”
Purpose = “backup”
}
}

resource “aws_storagegateway_gateway” “main” {
gateway_ip_address = “10.0.1.50”
gateway_name = “prod-file-gateway”
gateway_timezone= “GMT+9:00”
gateway_type = “FILE_S3”

smb_active_directory_settings {
domain_name = “corp.example.com”
password = var.ad_password
username = “svc_storage_gw”
}

tags = {
Environment = “production”
}
}
“`text

5-2. Volume Gateway (iSCSI → S3 スナップショット / DR)

Volume Gateway は iSCSI ブロックデバイスをオンプレに提示し、バックグラウンドで S3 にスナップショットを保存する。DR (災害復旧) とオンプレブロックボリュームのS3バックアップが主用途だ。

Cached モード vs Stored モード

DR フロー: EBS ボリューム復元

1. Volume Gateway が S3 に EBS スナップショットを定期作成
2. 障害発生 → AWS コンソールで S3 スナップショットから EBS ボリューム作成
3. EC2 インスタンスにアタッチして本番復旧

RTO (Recovery Time Objective) を最短化するには、スナップショット頻度を高め (1時間ごと)、かつ復元手順を Runbook として自動化しておくことが重要だ。

5-3. Tape Gateway (VTL — バックアップソフト連携)

Tape Gateway は仮想テープライブラリ (VTL) として振る舞い、既存バックアップソフトウェアの物理テープをS3・Glacier に置き換える。テープインフラの維持コスト削減と長期保存コスト最適化が目的だ。

対応バックアップソフトウェア

• Veritas NetBackup / Backup Exec
• Veeam Backup & Replication
• Commvault
• Dell EMC NetWorker

テープライフサイクル

text
バックアップソフト → VTL (S3) → Tape Gateway → アーカイブ → S3 Glacier / Glacier Deep Archive
↑
仮想テープスロット (最大1,500本)text

アーカイブタイムアウトを設定すると、未使用の仮想テープを自動的に Glacier へ移動できる。1TB あたり月額 $0.004 (Glacier Deep Archive) と、S3 Standard の 1/25 以下のコストで長期保存が実現する。

5-4. Direct Connect 連携とキャッシュ設計

Storage Gateway をオンプレミスで運用する際、インターネット経由では帯域不足と遅延が問題になる。本番環境では Direct Connect + Private Virtual Interface の組み合わせが標準だ。

Direct Connect + Storage Gateway 構成

text
オンプレミス DC
└─ ルーター
└─ Direct Connect (1Gbps / 10Gbps)
└─ Private Virtual Interface (VIF)
└─ VGW / Transit Gateway
└─ VPC
└─ Storage Gateway (VMware / EC2)
└─ S3 / EFS / Glaciertext

帯域計算式

text
必要帯域 (Mbps) = (日次バックアップデータ量 GB × 8) ÷ (バックアップウィンドウ 秒)
例: 500GB / 8時間 = (500 × 8) ÷ 28800 ≈ 139 Mbps → 1Gbps DX 推奨text

Direct Connect は複数の仮想インターフェース (VIF) を1本の物理回線で共有できる。Storage Gateway 専用 VIF を作成し、QoS で業務トラフィックと分離することで安定した転送帯域を確保せよ。

キャッシュサイズ設計の実践

1. 過去30日間のアクセスログから「頻繁アクセスファイル」の総サイズを算出
2. その1.2〜1.5倍をキャッシュディスクに割り当て
3. CloudWatch → CachePercentUsed を1週間監視して調整

5-5. Gateway 選定フロー (mermaid02)

mermaid
flowchart TD
A[オンプレ Storage をAWS連携] --> B{主なワークロードは?}
B -->|ファイル共有 / バックアップ| C{プロトコルは?}
B -->|ブロックボリューム DR| D[Volume Gateway] B -->|既存バックアップソフト| E[Tape Gateway → S3 Glacier] C -->|NFS / SMB| F[File Gateway → S3] C -->|iSCSI| D
F --> G{接続方式は?}
G -->|Direct Connect| H[低レイテンシ + 帯域保証<br/>キャッシュ最小化可能] G -->|インターネット| I[キャッシュ増設必須<br/>BandwidthThrottleSchedule 設定] D --> J{モード選択}
J -->|クラウドファースト| K[Cached モード<br/>S3 プライマリ] J -->|低レイテンシ必須| L[Stored モード<br/>ローカルプライマリ + S3 DR] E --> M[アーカイブタイムアウト設定<br/>Glacier Deep Archive 自動移行]text

5-6. Storage Gateway Terraform 実装全体像

下記は File Gateway + S3 バケット + IAM ロールの最小構成だ。Volume Gateway は gateway_type = "STORED" または "CACHED" に変えるだけで同様に管理できる。

“`hcl
resource “aws_s3_bucket” “gateway_backup” {
bucket = “prod-storage-gateway-backup-${data.aws_caller_identity.current.account_id}”

tags = {
Environment = “production”
ManagedBy= “terraform”
}
}

resource “aws_s3_bucket_versioning” “gateway_backup” {
bucket = aws_s3_bucket.gateway_backup.id

versioning_configuration {
status = “Enabled”
}
}

resource “aws_s3_bucket_lifecycle_configuration” “gateway_backup” {
bucket = aws_s3_bucket.gateway_backup.id

rule {
id = “transition-to-ia”
status = “Enabled”

transition {
  days = 30
  storage_class = "STANDARD_IA"
}

transition {
  days = 90
  storage_class = "GLACIER"
}

noncurrent_version_expiration {
  noncurrent_days = 90
}

abort_incomplete_multipart_upload {
  days_after_initiation = 7
}

}
}

resource “aws_iam_role” “storage_gateway_s3” {
name = “prod-storage-gateway-s3-role”

assume_role_policy = jsonencode({
Version = “2012-10-17”
Statement = [{
Action = “sts:AssumeRole”
Effect = “Allow”
Principal = { Service = “storagegateway.amazonaws.com” }
}] })
}

resource “aws_iam_role_policy” “storage_gateway_s3” {
name = “storage-gateway-s3-access”
role = aws_iam_role.storage_gateway_s3.id

policy = jsonencode({
Version = “2012-10-17”
Statement = [
{
Effect = “Allow”
Action = [
“s3:GetObject”, “s3:PutObject”, “s3:DeleteObject”,
“s3:ListBucket”, “s3:GetBucketLocation”,
“s3:GetBucketVersioning”, “s3:ListBucketMultipartUploads”,
“s3:ListMultipartUploadParts”, “s3:AbortMultipartUpload”
] Resource = [
aws_s3_bucket.gateway_backup.arn,
“${aws_s3_bucket.gateway_backup.arn}/*”
]}
] })
}
“`text

6. 詰まりポイント7選

本章は S3・EFS・FSx・Storage Gateway を本番運用する際に頻発するトラブルを7項目に絞った。いずれも「設定は通ったのになぜ」と後から気づくパターンだ。

6-1. S3 Lifecycle Rule 設定ミス — Incomplete Multipart Upload 未設定でコスト爆発

症状: S3 ストレージコストが毎月増加し続ける。オブジェクト一覧に __multipart_upload_ プレフィックスのゴミデータが大量に存在する。

原因: マルチパートアップロードが中断・失敗した際、アップロード済みのパーツが S3 に残留し続ける。これらは通常の LIST 操作では見えないが課金対象だ。大容量ファイルの転送やログ集約パイプラインで発生しやすい。

影響規模: 本番環境で数百GBのデータ転送が日次で走る場合、未完了パーツだけで月数万円の無駄コストが発生した事例がある。

正解パターン: Lifecycle Rule に AbortIncompleteMultipartUpload を設定する。

“`hcl
resource “aws_s3_bucket_lifecycle_configuration” “example” {
bucket = aws_s3_bucket.example.id

rule {
id = “abort-incomplete-multipart”
status = “Enabled”

abort_incomplete_multipart_upload {
  days_after_initiation = 7
}

}
}
“`text

CloudWatch 監視: AWS/S3 → NumberOfObjects (StorageType: AllStorageTypes) の急増を検知すること。S3 Storage Lens を有効化すると不完全マルチパートの詳細が可視化できる。

6-2. EFS Throughput Mode 誤選択 — Bursting Credit 枯渇でスロットリング

症状: 平常時は問題ないが、月次バッチ処理や深夜の大量書き込み後に急激にパフォーマンスが低下する。BurstCreditBalance が0に近づくとスループットが数十 MB/s まで制限される。

原因: Bursting モードは BurstCreditBalance を消費してスループットを一時的に向上させる仕組みだ。クレジットの補充速度はファイルシステムサイズに比例するため、小規模 EFS で大量IOを行うとクレジットが枯渇する。

正解パターン: 定常的に高スループットが必要なら Provisioned Throughput モードに切り替える。

“`hcl
resource “aws_efs_file_system” “production” {
throughput_mode = “provisioned”
provisioned_throughput_in_mibps = 256

lifecycle_policy {
transition_to_ia = “AFTER_30_DAYS”
}

tags = {
Environment = “production”
}
}
“`text

CloudWatch アラート設定: BurstCreditBalance が 10% 未満になったらアラートを発砲し、Provisioned Throughput への切り替えを検討する。

コスト注意: Provisioned Throughput は 1 MB/s あたり月額 $6.00。ワークロードを分析し、必要最小限の値を設定すること。

6-3. FSx for Windows — AD連携失敗 (DNS解決 / Security Group設定不備)

症状: FSx for Windows File Server を作成できたが、Windows クライアントからマウントできない。イベントビューアに「The network path was not found」または「Access denied」エラーが表示される。

原因の9割はDNSとSecurity Group: FSx for Windows は Active Directory 参加が必須であり、DNS 解決と Security Group の設定ミスが原因の大半を占める。

必須ポート一覧

トラブルシューティング手順

“`bash

1. DNS解決確認 (FSx エンドポイントが解決できるか)

nslookup fs-xxxxxxxxxxxxxxxxx.corp.example.com

2. SMBポート疎通確認

Test-NetConnection -ComputerName fs-xxxxxxxxxxxxxxxxx.corp.example.com -Port 445

3. AD参加確認

nltest /sc_query:corp.example.com
“`text

Terraform Security Group の正解

hcl
resource "aws_security_group_rule" "fsx_windows_smb" {
type = "ingress"
from_port= 445
to_port = 445
protocol = "tcp"
cidr_blocks = ["10.0.0.0/8"] security_group_id = aws_security_group.fsx.id
}text

VPC の DNS サーバ設定 (enableDnsSupport = true、enableDnsHostnames = true) と、AD の DNS を VPC の DHCP オプションセットに設定することが前提だ。

6-4. Storage Gateway 帯域不足 — キャッシュ枯渇と Direct Connect 未使用

症状: オンプレのアプリケーションから S3 へのファイル書き込みが業務時間帯に数分から数十分かかる。File Gateway のキャッシュが常に 90% 以上を示している。

原因の複合構造

1. キャッシュサイズ不足: ワーキングセットよりキャッシュが小さく、常にフラッシュが発生
2. インターネット回線の輻輳: S3 へのアップロードがインターネット帯域を逼迫
3. Direct Connect 未使用または設定不備: 専用線を引いているのに Storage Gateway が PublicIF 経由で通信

Direct Connect 経由に切り替える手順

Storage Gateway の Endpoint type を VPC に変更し、Private Endpoint を使用する。すでに動作中の Gateway の場合は再作成が必要なため、移行ウィンドウを計画的に設けよ。

関連: Network本番運用 Vol1 — Direct Connect 帯域設計と Private VIF 構成

6-5. S3 Versioning コスト爆発 — 削除マーカー蓄積と Lifecycle 未設定

症状: Versioning を有効化してから数ヶ月後に S3 コストが想定の5〜10倍に膨れ上がる。不要な旧バージョンと削除マーカーが大量に蓄積している。

コスト計算例

text
日次更新ファイル: 10,000件 × 平均 1MB = 10GB/日
Versioning 有効時 (90日保持): 10GB × 90日 = 900GB の旧バージョン
S3 Standard 料金: 900GB × $0.023/GB = 月額 $20.7 の追加コスト
(本来のコスト: 10GB × $0.023/GB = $0.23/月)text

正解パターン: NoncurrentVersionExpiration + ExpiredObjectDeleteMarker を Lifecycle に追加する。

“`hcl
rule {
id = “cleanup-old-versions”
status = “Enabled”

noncurrent_version_expiration {
noncurrent_days = 30
}

expiration {
expired_object_delete_marker = true
}
}
“`text

S3 Batch Operations 活用: 過去に蓄積した削除マーカーは S3 Batch Operations で一括削除できる。S3 Inventory で実態を把握してから実施せよ。

6-6. S3 Object Lock 誤設定 — Compliance モードで削除不能

症状: コンプライアンス要件でファイルの改ざん防止を設定したが、誤ったオブジェクトを Compliance モードで長期ロックしてしまい、削除できない。AWS サポートに問い合わせても削除不可と回答される。

Governance モードと Compliance モードの違い

誤設定防止の設計原則

1. 最初は必ず Governance モードで動作確認
2. Compliance モードへの切り替えは変更管理プロセスで承認取得後
3. 保持期間は最短設定から始め、必要に応じて延長
4. 誤ロック防止: aws s3api put-object-retention の実行権限を最小化

“`hcl
resource “aws_s3_bucket_object_lock_configuration” “compliance” {
bucket = aws_s3_bucket.compliance.id

rule {
default_retention {
mode = “GOVERNANCE”
days = 90
}
}
}
“`text

関連: Database本番運用 Vol1 — データ保護とコンプライアンス設計

6-7. EFS-IA Restore Storage 料金 — 取り出し時の二重課金見落とし

症状: EFS の Lifecycle Policy で 30日後に IA へ移行する設定を入れたところ、翌月から請求が増加した。IA に移行しているはずなのにコスト削減効果が薄い。

料金構造の落とし穴

アクセス頻度が低いと思っていたファイルが実は週次バッチで読み取られており、IA から取り出すたびに課金が発生するパターンが典型的だ。

コスト最適化の判定式

“`text
月次コストがトントンになる月間アクセス回数 N:
Standard コスト = IA 保存コスト + IA 取り出しコスト
$0.30 × GB = $0.025 × GB + $0.01 × N × GB
N = ($0.30 – $0.025) / $0.01 = 27.5 回/月

→ 月27回以上アクセスするなら Standard のほうが安い
“`text

正解パターン: EFS Access Log と CloudWatch の MeteredIOBytes (StorageClass: InfrequentAccessStorage) で実際のアクセス頻度を計測してから Lifecycle Policy を設定する。

関連: Container本番運用 Vol1 — EFS を使うコンテナのストレージコスト最適化

7. アンチパターン → 正解パターン変換演習 5問

本章では、S3・EFS・FSx・Storage Gateway 導入時に現場でよく見られるアンチパターンを提示し、正解パターンへの変換方法を演習形式で解説する。読みながら自分の環境に照らし合わせ、該当項目がないか確認してほしい。

Q1. S3 Lifecycle Rule 未設定 + Incomplete Multipart Upload 放置

アンチパターン

json
{
"BucketLifecycleConfiguration": {
"Rules": [] }
}text

S3 バケットに Lifecycle Rule を設定せず、全オブジェクトを Standard ストレージクラスのまま放置するケースは非常に多い。さらに深刻なのが Incomplete Multipart Upload の放置だ。大容量ファイルを分割アップロード中に失敗した場合、パーツデータが残留し続け、ストレージコストが継続発生する。バケット容量の数十%がこの残骸で埋まっている事例も珍しくない。

正解パターン

json
{
"Rules": [
{
"ID": "transition-to-intelligent-tiering",
"Status": "Enabled",
"Filter": { "Prefix": "" },
"Transitions": [
{ "Days": 30, "StorageClass": "INTELLIGENT_TIERING" }
] },
{
"ID": "abort-incomplete-multipart",
"Status": "Enabled",
"Filter": { "Prefix": "" },
"AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
},
{
"ID": "expire-old-versions",
"Status": "Enabled",
"Filter": { "Prefix": "" },
"NoncurrentVersionExpiration": { "NoncurrentDays": 90 }
}
]}text

Lifecycle Rule で 30日後に Intelligent-Tiering へ自動移行し、Incomplete Multipart Upload を 7日で自動削除する。コスト最適化の詳細はコスト最適化 Vol1 で詳述している。バケットポリシーと組み合わせた最小権限設計はIAM Vol1 も参照されたい。

Q2. EFS Throughput Mode を Bursting のまま大量並列ワークロードに適用

アンチパターン

EFS を作成時のデフォルト設定（Throughput Mode: Bursting）のまま、数十台の EC2 が同時アクセスするバッチワークロードに使い続けるケースだ。

Bursting モードは蓄積した「バーストクレジット」を消費して高スループットを出す仕組みで、データ量が少ないうちはクレジットが尽きてベースライン（1 MiB/s per TiB）まで激減する。大量並列ジョブが走ると、クレジット枯渇 → スロットリング → ジョブ失敗という連鎖が発生する。

正解パターン

“`bash

Elastic Throughput に変更（既存ファイルシステムでも変更可能）

aws efs update-file-system \
–file-system-id fs-12345678 \
–throughput-mode elastic

BurstCreditBalance のアラーム設定

aws cloudwatch put-metric-alarm \
–alarm-name “EFS-BurstCredit-Low” \
–metric-name BurstCreditBalance \
–namespace AWS/EFS \
–statistic Minimum \
–period 300 \
–threshold 1073741824 \
–comparison-operator LessThanThreshold \
–evaluation-periods 3 \
–alarm-actions arn:aws:sns:ap-northeast-1:123456789012:ops-alert
“`text

EFS の監視設計はObservability Vol1 で詳述している。EFS を ECS タスクにマウントする構成はContainer Vol1 を参照。高 IOPS 要求で EFS が限界の場合は FSx for Lustre やDatabase Vol1 の RDS との組み合わせも検討されたい。

Q3. FSx for Windows File Server の Security Group / AD 連携 設定不備

アンチパターン

FSx for Windows は Active Directory 連携が必須だが、設定を急いで以下のミスを犯しやすい。

• Security Group で必要なポートを開けていない（TCP 445、UDP 389 など）
• Self-managed AD の DNS サーバー IP アドレスを誤入力
• AWS Managed Microsoft AD との VPC Peering を忘れる
• FSx サブネット ↔ AD ドメインコントローラー間のルーティング未設定
• FSx 作成後に AD 連携設定を変更しようとして「変更不可」に気づく

正解パターン

“`hcl

Terraform: FSx for Windows 用 Security Group

resource “aws_security_group” “fsx_windows” {
name= “fsx-windows-sg”
vpc_id = var.vpc_id

ingress {
from_port= 445
to_port = 445
protocol = “tcp”
cidr_blocks = [var.vpc_cidr] description = “SMB from VPC”
}

ingress {
from_port= 389
to_port = 389
protocol = “tcp”
cidr_blocks = [var.ad_subnet_cidrs] description = “LDAP from AD subnets”
}

ingress {
from_port= 88
to_port = 88
protocol = “tcp”
cidr_blocks = [var.ad_subnet_cidrs] description = “Kerberos from AD subnets”
}

ingress {
from_port= 49152
to_port = 65535
protocol = “tcp”
cidr_blocks = [var.vpc_cidr] description = “RPC dynamic ports”
}

egress {
from_port= 0
to_port = 0
protocol = “-1”
cidr_blocks = [“0.0.0.0/0”] }
}
“`text

Terraform による IaC 管理はIaC Vol1 とIaC Vol2 で詳述している。FSx の AD 連携に必要な IAM 権限設計はIAM Vol1 も参照されたい。マルチアカウント環境での FSx 共有はマルチアカウント Vol1 で解説している。

Q4. Storage Gateway — キャッシュ不足 + Direct Connect 未活用

アンチパターン

Storage Gateway はオンプレミス ↔ AWS 間のハイブリッドストレージを実現するが、キャッシュ設定のミスで期待した性能が出ないケースが多い。

• キャッシュディスクを最小構成（150 GiB）のまま大量データを扱う → キャッシュヒット率が低下し、S3 からの頻繁なフェッチで高レイテンシになる
• インターネット VPN 経由でバックアップ転送 → 帯域不足・不安定 → バックアップが失敗・再試行ループ
• CloudWatch メトリクス CacheHitPercent を監視していない → 問題を事後にしか検知できない
• アップロードバッファが不足し、転送キューが詰まってタイムアウトが頻発する

正解パターン

“`bash

Storage Gateway のキャッシュヒット率を週次で確認

aws cloudwatch get-metric-statistics \
–namespace “StorageGateway” \
–metric-name “CacheHitPercent” \
–dimensions Name=GatewayId,Value=sgw-12345678 \
–start-time “$(date -u -v-7d ‘+%Y-%m-%dT%H:%M:%SZ’)” \
–end-time “$(date -u ‘+%Y-%m-%dT%H:%M:%SZ’)” \
–period 3600 \
–statistics Average \
–output table

アップロードバッファ使用率の確認

aws cloudwatch get-metric-statistics \
–namespace “StorageGateway” \
–metric-name “UploadBufferUsed” \
–dimensions Name=GatewayId,Value=sgw-12345678 \
–start-time “$(date -u -v-1d ‘+%Y-%m-%dT%H:%M:%SZ’)” \
–end-time “$(date -u ‘+%Y-%m-%dT%H:%M:%SZ’)” \
–period 300 \
–statistics Maximum
“`text

Direct Connect の設計と帯域計算はNetwork Vol1 で詳述している。Storage Gateway を含めたバックアップ・復旧設計は復旧 Vol1 も参照されたい。コスト観点の Volume Type 選択はコスト最適化 Vol1 で解説している。

Q5. S3 Object Lock Compliance mode を事前テストなしで本番適用

アンチパターン

WORM（Write Once Read Many）要件のために S3 Object Lock を Compliance mode で設定したが、保持期間の設定ミスで削除も変更も不可能になるケースだ。

• Retention Period を 10年に設定したが、法令要件は 7年だった → 変更不可、3年分の余分なコストが確定
• バケット全体に Object Lock を有効化したが、一部のオブジェクトは法令適用外だった → 不必要なロック
• Compliance mode では AWS サポートも削除できない → 保持期間終了まで完全にロック

正解パターン

“`bash

Step1: Governance mode でテスト（まず 30日間）

aws s3api put-object-retention \
–bucket my-compliance-bucket \
–key “test-object.txt” \
–retention ‘{“Mode”:”GOVERNANCE”,”RetainUntilDate”:”2026-06-20T00:00:00Z”}’

Step2: Governance mode で削除できることを確認（s3:BypassGovernanceRetention 権限で）

aws s3api delete-object \
–bucket my-compliance-bucket \
–key “test-object.txt” \
–bypass-governance-retention

Step3: 法令要件確認後、本番バケットに Compliance mode を設定

aws s3api put-object-lock-configuration \
–bucket my-compliance-bucket \
–object-lock-configuration ‘{
“ObjectLockEnabled”: “Enabled”,
“Rule”: {
“DefaultRetention”: {
“Mode”: “COMPLIANCE”,
“Years”: 7
}
}
}’
“`text

Compliance mode 適用前は必ず Governance mode で 30日以上テストし、保持期間・対象オブジェクト範囲を確認する。コンプライアンス設計全体はセキュリティ Vol1 を参照。マルチアカウント環境での Object Lock 管理はマルチアカウント Vol1、Bedrock との組み合わせで機密データ管理をする場合はAI Vol1 も参照されたい。

8. まとめ — Vol2予告 + 落とし穴10選 + 全14軸クロスリンク

8-1. Vol1 まとめ — S3・EFS・FSx・Storage Gateway 4本柱の現実解

コスト最適化の観点ではコスト最適化 Vol1、セキュリティ設計はセキュリティ Vol1 とセキュリティ Vol2 を合わせて参照されたい。データベース連携（S3 + Aurora の Export/Import 等）はDatabase Vol1 とDatabase Vol2 で解説している。サーバーレス連携（Lambda + S3 イベント駆動）はServerless Vol1 とServerless Vol2 が参考になる。

8-2. Vol2 予告 — EBS・DataSync・Transfer Family・Backup 完全解説

Vol2 では本 Vol1 では扱えなかった以下のテーマを詳説する。

→ Storage 本番運用 Vol2: EBS×DataSync×Transfer Family×Backup（近日公開）

8-3. Storage 本番運用 落とし穴10選

1. S3 バケットポリシーと ACL の競合 — 両方有効にすると意図しないアクセス許可が生まれる。Block Public Access を常に有効化すること。→ IAM Vol1
2. EFS 暗号化の後付け不可 — 作成時に有効化しないと後から変更できない。IaC 定義時に encrypted = true を必須化すること。
3. FSx バックアップの無効化 — デフォルト有効だが、コスト削減目的で無効化するとリストア不能になる。→ 復旧 Vol1
4. S3 Cross-Region Replication の片方向設定 — 両リージョンでルールを設定しないと単方向になる。→ マルチアカウント Vol1
5. EFS マウントポイントへの過剰な書き込み権限付与 — /mnt/efs に書き込み権限を与えすぎると全データ消失リスク。IAM リソースポリシーで最小権限を徹底すること。
6. Storage Gateway のアップロードバッファタイムアウト — デフォルト設定が短く、大容量転送が途中で失敗する。GatewayTimeBetweenLogUploads を調整し、監視アラームを設定すること。
7. S3 Intelligent-Tiering の小オブジェクト問題 — 128 KB 未満のオブジェクトは Intelligent-Tiering 適用外でモニタリング費用が上乗せになる場合がある。→ コスト最適化 Vol1
8. FSx for Lustre と S3 データリポジトリの同期遅延 — AutoImportPolicy を設定しないと S3 変更が FSx に自動反映されない。→ DevOps Vol1
9. EFS One Zone の可用性リスク — コスト削減目的で One Zone を選ぶと AZ 障害時に全データがアクセス不能になる。本番環境では Standard（マルチ AZ）を推奨。→ Observability Vol1
10. VPC Endpoint 未設定の S3 アクセス — インターネット経由で S3 にアクセスするとデータ転送費用が発生しセキュリティリスクも高まる。Gateway VPC Endpoint を必ず設定すること。→ Network Vol1

8-4. AWS 本番運用 全14軸 双方向ハブナビゲーション

→ Container 本番運用 Vol1: ECS×Fargate×ECR 完全ガイド