Amazon EFS 完全ガイド 2026

初心者から実務者向けの包括的解説

ドキュメントの目的

本ガイドは以下を対象としています:

• 初心者向け: EFS とは何か、なぜ複数インスタンスで共有ストレージが必要かを学びたい方
• 開発者・SRE向け: Performance Mode、Throughput Mode、Intelligent Tiering の実装方法を習得したい方
• インフラエンジニア向け: EKS/ECS での CSI Driver 統合、Access Points、クロスリージョンレプリケーションを設計したい方
• 意思決定者向け: Intelligent Tiering で 92% コスト削減を実現したい方

2026年の EFS エコシステム

• Elastic Throughput がデフォルト: 予測困難な変動ワークロードに自動スケール。従量課金で計画立てやすい
• Intelligent Tiering: ファイルアクセスパターンを学習し、Standard/IA/Archive 間を自動遷移。最大 92% コスト削減
• Regional EFS が主流: One Zone は開発環境・テスト用途に限定。本番は複数 AZ で HA 構成
• EKS/ECS との深い統合: CSI Driver（aws-efs-csi-driver）で Kubernetes PersistentVolume として native 対応
• Access Points による多テナント分離: ルートディレクトリ・POSIX ユーザー/グループを固定して RBAC 強化

概要

Amazon EFS（Elastic File System）は、複数の EC2・コンテナ・Lambda から同時にマウント可能なマネージド NFS ファイルシステム です。POSIX セマンティクスに準拠し、自動スケーリング、複数 AZ 冗長、ライフサイクル管理（Standard/IA/Archive）により、コンテナワークロード・コラボレーション環境・大規模データセット共有に最適化されています。

初心者向けメモ: EFS は「複数の PC が共有フォルダにアクセスする」イメージです。EBS がハードディスク（単一マシン）なら、EFS はネットワークドライブ（複数マシン共有）です。

EFS が解決する課題

EFS は以下の課題に対応します:

1. 複数インスタンスのファイル共有: EBS は単一インスタンス専有。複数インスタンスが共有ストレージにアクセスしたいケースで必須
2. ストレージ容量の自動スケーリング: 事前プロビジョニング不要。ファイル追加と同時に自動拡張
3. コンテナワークロードの永続化: ECS/EKS で ステートフルなアプリケーション（WordPress、Stateful アプリ）を構築
4. マルチリージョン・ディザスタリカバリー: EFS Replication で別リージョンへの継続的複製が可能
5. コスト最適化: IA/Archive への自動遷移で、低頻度アクセスデータを 90% コスト削減

主な特徴

• ✅ 自動スケーリング: 容量の事前プロビジョニング不要
• ✅ 複数 AZ 冗長: Regional EFS なら複数 AZ で自動複製
• ✅ POSIX 準拠: Linux/Mac/Unix アプリケーション互換性 100%
• ✅ Elastic Throughput: ワークロード変動に自動適応、従量課金
• ✅ Intelligent Tiering: アクセスパターンに基づき自動コスト最適化（最大92%削減）
• ✅ EKS/ECS 統合: CSI Driver で Kubernetes native サポート
• ✅ Access Points: ルートディレクトリ・POSIX ユーザー/グループ分離で多テナント対応
• ✅ 暗号化（KMS）: 保存時・転送時を同時に保護

アーキテクチャ

graph TB
    subgraph VPC["VPC (ap-northeast-1)"]
        subgraph AZ1["Availability Zone 1a"]
            EC2A["EC2 Instance<br/>10.0.1.10"]
            MT1["Mount Target 1a<br/>10.0.1.x"]
        end
        
        subgraph AZ2["Availability Zone 1c"]
            EC2B["EC2 Instance<br/>10.0.3.10"]
            MT2["Mount Target 1c<br/>10.0.3.x"]
        end
        
        subgraph AZ3["Availability Zone 1d"]
            ECS_Task["ECS Fargate Task<br/>10.0.5.x"]
            MT3["Mount Target 1d<br/>10.0.5.x"]
        end
    end
    
    subgraph EFS_FS["EFS File System<br/>(Regional)"]
        FS_Core["Shared Storage<br/>1.5 TiB (metered)"]
        AP1["Access Point<br/>/app-a (UID:1001)"]
        AP2["Access Point<br/>/app-b (UID:1002)"]
    end
    
    subgraph Control["Control Plane & Monitoring"]
        KMS["AWS KMS<br/>Customer Managed Key"]
        IAM_POLICY["IAM Policy<br/>elasticfilesystem:ClientMount"]
        CW["CloudWatch<br/>MeteredIOBytes, PercentIOLimit"]
        DR["EFS Replication<br/>→ ap-northeast-3"]
    end
    
    EC2A -->|NFS v4.1<br/>mount| MT1
    EC2B -->|NFS v4.1<br/>mount| MT2
    ECS_Task -->|NFS v4.1<br/>via CSI Driver| MT3
    
    MT1 -->|read/write| FS_Core
    MT2 -->|read/write| FS_Core
    MT3 -->|read/write| FS_Core
    
    FS_Core --> AP1
    FS_Core --> AP2
    
    FS_Core -->|encrypt| KMS
    MT1 -->|auth| IAM_POLICY
    FS_Core -->|monitor| CW
    FS_Core -->|replicate| DR

データフロー

1. マウント: EC2/コンテナが NFS クライアント経由で EFS をマウント
2. 同時アクセス: 複数クライアントが同じファイルを同時読み取り/順序付き書き込み
3. 自動スケーリング: ファイル追加 → EFS サイズ自動拡張
4. ライフサイクル移行: 30日未アクセス → IA へ自動遷移、容量は保持
5. バックアップ・複製: EFS Replication で別リージョンへ継続同期
6. 暗号化: KMS で保存時・転送時を暗号化

コアコンポーネント詳細

1. ファイルシステム種別

Regional は本番推奨。One Zone は開発環境・バックアップ先などで検討。

2. Performance Mode（レイテンシ vs IOPS）

重要: Max I/O はレイテンシが大幅上昇。ほぼ全用途で General Purpose で十分。One Zone は General Purpose のみ対応。

3. Throughput Mode（スケーリング方式）

Elastic の利点:

• 自動スケール（学習曲線なし）
• 従量課金で計画立てやすい
• Regional Elastic なら読取最大 60 GiB/s、書込 5 GiB/s

Provisioned の利点:

• 安定した高スループット提供
• SLA 保証可能

4. ストレージクラスと Intelligent Tiering

ストレージクラス

Intelligent Tiering（2025年導入）

ファイルアクセスパターンを自動学習し、Standard/IA/Archive を自動遷移:

例: 機械学習トレーニングデータセット

Day 1-30:  全ファイル Standard（頻繁なアクセス）
           → 読取パフォーマンス優先

Day 31-90: 古いエポックのみ IA へ遷移
           → コスト 94% 削減（$0.30 → $0.016）

Day 91+:   アーカイブチェックポイント → Archive
           → さらに 60% 削減（$0.016 → $0.006）

結果: データセット全体で最大 92% コスト削減

ライフサイクル設定例:

• 0日: Standard
• 30日未アクセス: → IA
• 90日未アクセス: → Archive

5. マウントターゲット（Network Interface）

各 AZ につき 1 個のマウントターゲット（ENI）を作成:

VPC (CIDR: 10.0.0.0/16)
  ├─ AZ-1a (CIDR: 10.0.1.0/24)
  │   └─ Mount Target 1a (IP: 10.0.1.100)
  │       ← セキュリティグループ: inbound TCP/UDP 2049（NFS）
  │
  ├─ AZ-1c (CIDR: 10.0.3.0/24)
  │   └─ Mount Target 1c (IP: 10.0.3.100)
  │       ← セキュリティグループ: inbound TCP/UDP 2049
  │
  └─ AZ-1d (CIDR: 10.0.5.0/24)
      └─ Mount Target 1d (IP: 10.0.5.100)

最適化: 同一 AZ のマウントターゲント経由でアクセス → データ転送コスト ゼロ

6. Access Points（マルチテナント分離）

ルートディレクトリ・POSIX ユーザー/グループを固定し、テナント間を分離:

EFS File System
  ├─ Access Point A
  │   └─ Enforced Root Dir: /app-a
  │   └─ Enforced POSIX User: UID:1001, GID:1001
  │       → コンテナが UID:1001 で自動マウント
  │       → /app-a 配下のみアクセス可能
  │
  └─ Access Point B
      └─ Enforced Root Dir: /app-b
      └─ Enforced POSIX User: UID:1002, GID:1002
          → /app-b 配下のみアクセス可能

メリット:

• テナント A が誤って テナント B のファイルにアクセス不可
• コンテナ内部での root 権限回避
• IAM ポリシー + アクセスポイント = 強固な RBAC

7. EFS Replication（クロスリージョン・クロスアカウント）

別リージョン・別アカウントへの継続的複製:

ソース: ap-northeast-1（東京）
  ↓ 継続同期（非同期）
レプリカ: ap-northeast-3（大阪）

RTO: ~1時間（レプリケーション遅延）
RPO: ~1時間（最新状態からの差分）

主要ユースケース（12パターン）

1. WordPress マルチインスタンス（ロードバランシング）

構成:
  EC2 Instance × 3（Auto Scaling Group）
  ├─ /var/www/html → EFS マウント（共有コンテンツ）
  └─ /var/www/uploads → EFS マウント（ユーザーアップロード）
  
  RDS MySQL（別途）
  
  EFS: Regional, General Purpose, Elastic Throughput
  ストレージクラス: Standard（ホットデータ）

コスト: ストレージ $50 + Elastic スループット $10 = $60/月

メリット:
  - Auto Scaling でインスタンス増減時、ファイルシステムは共有
  - ユーザーアップロードがインスタンス 1-3 全てで同期
  - バックアップ: EFS Snapshots（フルマネージド）

2. ECS Fargate マルチタスク（ステートフル）

構成:
  ECS Service
    ├─ Fargate Task #1 (10.0.1.10)
    ├─ Fargate Task #2 (10.0.3.10)
    └─ Fargate Task #3 (10.0.5.10)
  
  共有ストレージ: EFS Access Point A（/shared）
  
  docker-compose.yml:
    volumes:
      - type: efs
        source: fs-xxxxx
        target: /mnt/efs
        efs_config:
          authorization_config:
            access_point_id: fsap-xxxxx
          transit_encryption: ENABLED

コスト: ストレージ $20 + Elastic スループット $5 = $25/月

メリット:
  - Fargate スケーリング時に EFS は自動共有
  - タスク再起動後もデータ保持
  - キャッシュ・セッションデータ共有に最適

3. EKS（Kubernetes クラスター）

構成:
  EKS Cluster × 3 ノード
  
  StatefulSet: WordPress Pod
    └─ PersistentVolume: EFS
    └─ CSI Driver: aws-efs-csi-driver
    
  StorageClass:
    provisioner: efs.aws.com
    parameters:
      fileSystemId: fs-xxxxx
      directoryPerms: "700"
      uid: "1001"
      gid: "1001"

コスト: 約 $30/月（小規模クラスター）

メリット:
  - Pod スケジュール時に EFS 自動マウント
  - DynamicProvisioning で ボリューム自動作成
  - Helm Chart で ネイティブ対応

4. CI/CD ビルドキャッシュ（CodeBuild）

構成:
  CodeBuild Project × 複数（并行実行）
  
  Buildspec.yml:
    cache:
      paths:
        - '/mnt/efs/maven-cache/**'
  
  EFS: Regional, One Zone（開発用）
  ストレージクラス: Bursting（コスト最適）

コスト: 1GB × $0.30 = $0.30/月（小規模）

メリット:
  - 複数ビルドが Maven/Gradle キャッシュを共有
  - ビルド時間短縮（キャッシュ再利用）

5. 機械学習（SageMaker Training）

構成:
  SageMaker Training Job
    ├─ 学習データセット（10GB）→ EFS マウント
    ├─ モデルチェックポイント（毎エポック） → EFS 保存
    └─ テスト結果・ログ → EFS

  EFS: Regional, Elastic Throughput
  ストレージクラス: Intelligent Tiering
    - 0-30日: Standard（頻繁なアクセス）
    - 30-90日: IA（時々参照）
    - 90日+: Archive（アーカイブ）

コスト: 初期 $100 + Intelligent Tiering で段階削減 → 3ヶ月後 $10

メリット:
  - 複数 SageMaker ジョブが同じデータセットを共有
  - チェックポイント復旧で学習時間短縮
  - Intelligent Tiering で 92% コスト削減

6. データレイク（Apache Hadoop/Spark on EMR）

構成:
  EMR Cluster（5-20 ノード自動スケーリング）
    ├─ Hadoop HDFS（キャッシュ層）
    └─ EFS（永続層）

  ジョブ: Spark DataFrame 処理
    → /mnt/efs/data/parquet/ マウント

コスト: ストレージ $200 + Elastic $50 = $250/月（100GB）

メリット:
  - ノード障害時も EFS にデータ保持
  - Spark 段階的スケーリングで効率化
  - S3 より低レイテンシでセッション処理

7. メディア共有（写真・映像編集スタジオ）

構成:
  Mac Studio × 4（オンサイト編集）
  ├─ EFS マウント（via EC2 インスタンス + NFS）
  └─ /mnt/media（素材・プロジェクト共有）

  容量: 2TB（4K 動画 × 100本）
  ストレージクラス: Standard（頻繁なアクセス）

コスト: ストレージ $600 + Provisioned Throughput $100 = $700/月

メリット:
  - スタジオ内全員が同一プロジェクトファイルに同時アクセス
  - バージョン管理: EFS スナップショット

8. エンタープライズファイルサーバー（Active Directory 連携）

構成:
  Windows Server（FSLogix 統合）
    ├─ ユーザープロフィール → EFS（Windows SMB ブリッジ経由）
    └─ グループポリシー（AD）で アクセス制御

  Access Points:
    - Sales Team: /users/sales （GID: 1001）
    - Engineering Team: /users/eng （GID: 1002）

コスト: $300/月（500GB ホットデータ）

メリット:
  - AD ユーザーが自動認証でマウント
  - Intelligent Tiering で 90日未アクセスデータを自動 IA へ

9. GIS・地理空間データ共有

構成:
  QGIS Desktop × 複数ユーザー
    └─ /mnt/gis/shapefiles（共有レイヤー）

  容量: 50GB（地図データ）
  ストレージクラス: Standard（頻繁なクエリ）

コスト: $15/月（50GB × $0.30）

メリット:
  - 同時編集で リアルタイム同期
  - レイヤーバージョン管理: スナップショット

10. インターネット無しのオンプレ拠点とのハイブリッド

構成:
  本社（AWS）: EFS Regional
  支社（オンプレ）: AWS DataSync Agent
    └─ 毎日 23:00 に EFS と同期
    └─ 帯域幅制限: 10 MB/s（夜間）

コスト: EFS $30 + DataSync 転送料金 $1.25/GB/day × 10GB = $12.50/日

メリット:
  - オンプレと AWS ファイル統合
  - リアルタイムではなく定期同期（低コスト）

11. SaaS マルチテナント（テンプレート配布）

構成:
  テンプレートストレージ: EFS
    ├─ /templates/office365
    ├─ /templates/google-workspace
    └─ /templates/custom-apps

  各テナント: Access Point で /tenant-A, /tenant-B に分離
  ストレージクラス: Intelligent Tiering（アクセスパターン変動）

コスト: $100/月（複数テンプレート・低アクセス）

メリット:
  - テンプレート更新が全テナントに自動反映
  - アクセス制御: IAM + Access Points

12. コンテナレジストリ（ローカル Docker Registry + キャッシュ）

構成:
  Docker Registry コンテナ（ECS 上）
    ├─ イメージ保存: EFS
    └─ キャッシュ: EFS

  容量: 100GB（イメージレイヤー）
  Throughput Mode: Provisioned 100 MB/s

コスト: $30 + $600（Provisioned） = $630/月

メリット:
  - キャッシュヒット率向上で ビルド時間短縮
  - 複数リージョン CDN より低遅延

設定・操作の具体例

AWS CLI で EFS 作成

# Regional EFS を作成
aws efs create-file-system \
  --performance-mode GeneralPurpose \
  --throughput-mode elastic \
  --encrypted \
  --kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/12345678-1234-1234-1234-123456789012 \
  --tags Key=Name,Value=my-app-efs Key=Environment,Value=prod

# 結果
{
  "FileSystemId": "fs-0a1b2c3d4e5f6g7h8",
  "CreationTime": "2026-04-26T10:00:00.000000+00:00",
  "LifeCycleState": "creating",
  "ThroughputMode": "elastic"
}

# マウントターゲットを各 AZ に作成
aws efs create-mount-target \
  --file-system-id fs-0a1b2c3d4e5f6g7h8 \
  --subnet-id subnet-1a \
  --security-groups sg-efssg

aws efs create-mount-target \
  --file-system-id fs-0a1b2c3d4e5f6g7h8 \
  --subnet-id subnet-1c \
  --security-groups sg-efssg

aws efs create-mount-target \
  --file-system-id fs-0a1b2c3d4e5f6g7h8 \
  --subnet-id subnet-1d \
  --security-groups sg-efssg

Access Points 作成

# Access Point A を作成（アプリ A 専用）
aws efs create-access-point \
  --file-system-id fs-0a1b2c3d4e5f6g7h8 \
  --posix-user Uid=1001,Gid=1001 \
  --root-directory Path="/app-a",CreationInfo="{OwnerUid=1001,OwnerGid=1001,Permissions=750}" \
  --tags Key=Name,Value=app-a-accesspoint

# Access Point B を作成（アプリ B 専用）
aws efs create-access-point \
  --file-system-id fs-0a1b2c3d4e5f6g7h8 \
  --posix-user Uid=1002,Gid=1002 \
  --root-directory Path="/app-b",CreationInfo="{OwnerUid=1002,OwnerGid=1002,Permissions=750}" \
  --tags Key=Name,Value=app-b-accesspoint

EC2 から EFS をマウント

# EFS mount helper をインストール
sudo apt-get install -y nfs-common
sudo apt-get install -y amazon-efs-utils

# マウント（DNS 名で）
sudo mount -t efs \
  -o tls,accesspoint=fsap-xxxxx,iam \
  fs-0a1b2c3d4e5f6g7h8:/ /mnt/efs

# または EFS マウントヘルパーを使用（推奨）
sudo mount -t efs -o tls fs-0a1b2c3d4e5f6g7h8:/ /mnt/efs

# fstab に登録（永続化）
echo "fs-0a1b2c3d4e5f6g7h8:/ /mnt/efs efs defaults,_netdev,tls 0 0" \
  | sudo tee -a /etc/fstab

# マウント確認
df -h | grep efs
# 結果: Filesystem     Size  Used Avail Use% Mounted on
#       fs-xxxxx       1.5T  10G  1.5T   1%  /mnt/efs

Intelligent Tiering を有効化

# ライフサイクルポリシーを作成
aws efs put-lifecycle-configuration \
  --file-system-id fs-0a1b2c3d4e5f6g7h8 \
  --lifecycle-policies TransitionToIA=AFTER_30_DAYS,TransitionToArchive=AFTER_90_DAYS

# 設定を確認
aws efs describe-lifecycle-configuration \
  --file-system-id fs-0a1b2c3d4e5f6g7h8

# 結果:
# {
#   "LifecyclePolicies": [
#     {
#       "TransitionToIA": "AFTER_30_DAYS",
#       "TransitionToArchive": "AFTER_90_DAYS"
#     }
#   ]
# }

EFS Replication を設定（別リージョン）

# レプリケーション設定を作成
aws efs create-replication-configuration \
  --source-file-system-id fs-0a1b2c3d4e5f6g7h8 \
  --destinations Region=ap-northeast-3 \
  --region ap-northeast-1

# レプリケーション状態を確認
aws efs describe-replication-configurations \
  --file-system-id fs-0a1b2c3d4e5f6g7h8

Terraform での EFS + Access Points 設定

# Regional EFS を作成
resource "aws_efs_file_system" "app_efs" {
  performance_mode = "GeneralPurpose"
  throughput_mode  = "elastic"
  encrypted        = true
  kms_key_id       = aws_kms_key.efs.arn

  tags = {
    Name = "app-efs"
  }
}

# ライフサイクルポリシー
resource "aws_efs_lifecycle_configuration" "example" {
  file_system_id = aws_efs_file_system.app_efs.id

  lifecycle_policy {
    transition_to_ia                  = "AFTER_30_DAYS"
    transition_to_primary_storage_class = "AFTER_1_ACCESS"
  }
}

# マウントターゲット（複数 AZ）
resource "aws_efs_mount_target" "efs_mount" {
  for_each = toset(["subnet-1a", "subnet-1c", "subnet-1d"])

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

# Access Point A
resource "aws_efs_access_point" "app_a" {
  file_system_id = aws_efs_file_system.app_efs.id

  root_directory {
    path = "/app-a"
    creation_info {
      owner_gid   = 1001
      owner_uid   = 1001
      permissions = "750"
    }
  }

  posix_user {
    uid = 1001
    gid = 1001
  }

  tags = {
    Name = "app-a-access-point"
  }
}

# Access Point B
resource "aws_efs_access_point" "app_b" {
  file_system_id = aws_efs_file_system.app_efs.id

  root_directory {
    path = "/app-b"
    creation_info {
      owner_gid   = 1002
      owner_uid   = 1002
      permissions = "750"
    }
  }

  posix_user {
    uid = 1002
    gid = 1002
  }

  tags = {
    Name = "app-b-access-point"
  }
}

# IAM ポリシー（EFS マウント許可）
resource "aws_iam_policy" "efs_mount" {
  name = "efs-mount-policy"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "elasticfilesystem:ClientMount",
          "elasticfilesystem:ClientWrite",
          "elasticfilesystem:ClientRootAccess"
        ]
        Resource = aws_efs_file_system.app_efs.arn
        Condition = {
          StringEquals = {
            "elasticfilesystem:AccessPointArn" = [
              aws_efs_access_point.app_a.arn,
              aws_efs_access_point.app_b.arn
            ]
          }
        }
      }
    ]
  })
}

他の類似ツール・サービスとの比較

ベストプラクティス（✅ / ❌）

✅ DO

• Regional EFS を本番推奨: One Zone は開発・テスト限定
• Elastic Throughput でスタート: ワークロード変動への自動適応、計画不要
• Intelligent Tiering を有効化: 自動で 92% まで コスト削減可能
• Access Points で多テナント分離: RBAC が強化され、セキュリティ向上
• EFS マウントヘルパー使用: TLS 暗号化、レイテンシ最適化を自動適用
• 同一 AZ マウント: クロス AZ アクセス時のデータ転送料金を回避
• EFS Replication で複製: 別リージョン DR 対応
• CloudWatch で監視: MeteredIOBytes, PercentIOLimit で容量・IOPS 管理

❌ DON’T

• One Zone を本番に: AZ 障害で全インスタンスから アクセス不可に
• Max I/O モード使用: 遅延 50ms 超過。一般用途では General Purpose で十分
• ライフサイクル設定なし: Standard に滞留してコスト増加
• クロス AZ アクセス常時: AZ 間データ転送料金が発生（$0.02/GB）
• Provisioned Throughput を常時: Elastic で十分なら、従量課金で低コスト
• Access Points 未設定マルチテナント: セキュリティリスク（全ファイルに アクセス可）
• マウントヘルパー未使用: TLS 暗号化されず、設定も複雑
• IAM ポリシーなし: root で全権限マウント可能（リスク）

トラブルシューティング

2025-2026 最新動向

1. Intelligent Tiering（2025年一般提供）

• ファイルアクセスパターンを自動学習
• Standard → IA → Archive への段階的遷移
• 最大 92% コスト削減 を実現

2. Elastic Throughput の拡張

• Regional Elastic で読取最大 60 GiB/s（従来は 20 GiB/s）
• 予測困難なワークロードに完全適応

3. EFS Replication

• クロスリージョン・クロスアカウント対応
• ディザスタリカバリー戦略を容易化

4. EKS CSI Driver の深化

• Kubernetes ネイティブで Access Points サポート
• StorageClass で Dynamic Provisioning 完全対応

5. AWS DataSync 統合

• オンプレミス NAS ↔ EFS の定期同期
• ハイブリッドクラウド構成を支援

学習リソース

AWS 公式

• Amazon EFS ユーザーガイド
• EFS パフォーマンス仕様
• EFS ストレージクラス
• EFS Access Points
• EFS CSI Driver for Kubernetes

テックブログ

• AWS Storage Blog - EFS 最新情報
• Sedai: EFS Cost Management Guide 2026
• Astuto: EFS Intelligent-Tiering 92% 削減

実装例

小規模（開発環境）

構成:
  EFS: One Zone（コスト 40% 割引）
  ストレージクラス: Standard
  スループットモード: Bursting
  容量: 10GB

コスト: 10GB × $0.30 × 0.6 = $1.80/月

用途: 開発チーム 5人で ソースコード・テストデータ共有

中規模（本番 SaaS）

構成:
  EFS: Regional, Elastic Throughput
  ストレージクラス: Intelligent Tiering
  容量: 500GB（ホット 100GB、ウォーム 400GB）
  
  Intelligent Tiering:
    - 0-30日: Standard（$0.30/GB）
    - 30-90日: IA（$0.016/GB）
    - 90日+: Archive（$0.006/GB）

初期コスト: 500GB × $0.30 = $150/月
3ヶ月後: 100GB Standard + 400GB IA/Archive = $30 + $2.40 = $32.40/月

削減効果: 78% コスト削減

大規模（エンタープライズ）

構成:
  EFS Primary: Regional, Elastic, 10TB
  EFS Replica: ap-northeast-3, Replication enabled
  ストレージクラス: Intelligent Tiering
  Access Points: 50個（マルチテナント）
  IAM ポリシー: 細粒度アクセス制御

コスト:
  - ストレージ（Primary）: 10TB × $0.30 = $3,000/月
  - Replication（別リージョン）: $200/月
  - Elastic Throughput: $500/月
  - 合計: $3,700/月（3ヶ月後に Intelligent Tiering で $2,000 削減可能）

用途: 500ユーザーのエンタープライズファイル共有、マルチリージョン DR

導入ロードマップ

Phase 1: 評価（1週間）

• 既存ストレージ調査（EBS, FSx, S3）
• アクセスパターン分析
• ユースケース定義

Phase 2: PoC（2週間）

• One Zone EFS で開発環境テスト
• Performance/Throughput Mode ベンチマーク
• マウント・Access Points テスト

Phase 3: 本番展開（4週間）

• Regional EFS 作成
• Intelligent Tiering 設定
• マイグレーション（既存ストレージ → EFS）

Phase 4: 最適化（継続）

• CloudWatch 監視・チューニング
• コスト削減効果測定
• DR テスト（Replication）

実装チェックリスト

• [ ] Regional EFS を選択したか（本番）
• [ ] Elastic Throughput でスタートしたか（予測困難な場合）
• [ ] Intelligent Tiering を有効化したか
• [ ] マウントターゲットを各 AZ に作成したか
• [ ] セキュリティグループで NFS（2049）ポート許可したか
• [ ] EFS マウントヘルパーをインストールしたか
• [ ] Access Points で マルチテナント分離したか
• [ ] IAM ポリシーで 細粒度アクセス制御したか
• [ ] EFS Replication で別リージョン DR 準備したか
• [ ] CloudWatch で メトリクス監視しているか
• [ ] 定期的に ファイルシステムバックアップ取得しているか
• [ ] ディザスタリカバリー テスト実施したか

まとめ

Amazon EFS は 複数インスタンス・コンテナ・Lambda が同時にアクセス可能なマネージドファイルシステム です。2026年では Intelligent Tiering で 92% コスト削減、Elastic Throughput で自動スケーリング、Regional HA で 99.99% 可用性 を実現します。

EKS/ECS での CSI Driver 統合により Kubernetes ネイティブサポートが標準化。Access Points による多テナント分離で エンタープライズグレードのセキュリティを確保。EFS Replication でクロスリージョン ディザスタリカバリー も容易に実装できます。

参考文献

AWS 公式（10+）

• Amazon EFS ユーザーガイド
• Amazon EFS パフォーマンス仕様
• Amazon EFS ストレージクラス
• Amazon EFS Access Points
• Amazon EFS Intelligent-Tiering
• Amazon EFS Replication
• AWS EFS CSI Driver
• EFS マウントヘルパー
• EFS プライシング

テックブログ・OSS（5+）

• AWS Storage Blog - EFS Updates 2025-2026
• Sedai: AWS EFS Cost Management 2026
• Astuto: EFS Intelligent-Tiering 92% 削減
• CloudFix: EFS Intelligent Tiering Optimization
• NFS Utils Documentation

最終更新: 2026-04-26
バージョン: v2.0