【AWS経験者向け】AWSのEFSとGCPのFilestore：共有ファイルストレージ徹底比較

はじめに：共有ファイルストレージの重要性

皆さん、こんにちは！「30日間でGCPをマスターするAWSエンジニアの挑戦」シリーズ、25日目へようこそ。

AWSでのアプリケーション開発において、複数のEC2インスタンスやコンテナでファイルを共有する場合、Amazon Elastic File System (EFS) は必須のサービスである。NFSプロトコルをサポートし、完全マネージドでスケーラブルなファイルシステムを提供する。

GCPには、EFSと同様の役割を担うCloud Filestoreがある。しかし、サービス思想、パフォーマンス特性、料金体系において、AWSとは根本的に異なるアプローチを取っている。

この記事では、AWS EFSの知識を前提に、GCP Cloud Filestoreとの詳細比較を通じて以下のポイントを明確にする：

サービス設計思想：サーバーレス vs プロビジョニング型
パフォーマンス特性：スループット・IOPS・レイテンシの違い
料金体系とコスト最適化：従量課金 vs 固定課金の影響
実装・運用のベストプラクティス：具体的な設定例と注意点

サービス設計思想の根本的違い

AWS EFS：完全サーバーレスアプローチ

EFSは「インフラを意識させない」設計思想に基づいている：

核心特徴

動的スケーリング：データ量に応じて自動的に容量が拡張・縮小
バーストスループットモデル：ファイルシステムサイズに応じてパフォーマンスが向上
ゼロ管理：プロビジョニング、パッチ適用、バックアップが全自動

技術的詳細

# EFS作成（AWS CLI例）
aws efs create-file-system \
    --performance-mode generalPurpose \
    --throughput-mode provisioned \
    --provisioned-throughput-in-mibps 1024 \
    --tags Key=Name,Value=MyEFS

パフォーマンス特性

ベースラインスループット：1TB未満で100MiB/s、以降1TBあたり100MiB/s追加
バーストスループット：最大100MiB/s（General Purpose）または500MiB/s（Max I/O）
IOPS：最大7,000（General Purpose）

GCP Cloud Filestore：プロビジョニング型アプローチ

Filestoreは「予測可能なパフォーマンス」を重視した設計：

核心特徴

事前プロビジョニング：容量とパフォーマンスティアを明示的に指定
固定パフォーマンス：プロビジョンした仕様で一貫したIOPS・スループット
明確な分離：ワークロードに応じたティア選択

技術的詳細

# Filestore作成（gcloud例）
gcloud filestore instances create my-filestore \
    --zone=us-central1-a \
    --tier=BASIC_HDD \
    --file-share=name="share1",capacity=1TB \
    --network=name="default"

パフォーマンスティア詳細比較

AWS EFS パフォーマンスクラス

パフォーマンスモード	スループット	IOPS	レイテンシ	適用場面
General Purpose	100MiB/s（1TB未満） +100MiB/s/TB	7,000	低レイテンシ	一般的用途
Max I/O	500MiB/s+	7,000+	やや高レイテンシ	高並行性

スループットモード

Bursting：クレジットシステム（50MiB/s/TBのベース + バースト）
Provisioned：固定スループット（1-1,024 MiB/s）

GCP Cloud Filestore ティア構成

ティア	容量範囲	ベーススループット	最大IOPS	レイテンシ	用途
Basic HDD	1TB-63.9TB	100MB/s + 20MB/s/TB	1,000-60,000	数ms	一般用途
Basic SSD	2.5TB-63.9TB	100MB/s + 50MB/s/TB	3,000-100,000	1ms未満	高性能
High Scale SSD	10TB-320TB	480MB/s + 100MB/s/TB	12,000-400,000	1ms未満	HPC/AI
Enterprise	1TB-10TB	100MB/s + 20MB/s/TB	1,000-10,000	数ms	高可用性

注目ポイント

Enterprise：リージョン間レプリケーション対応
High Scale SSD：AI/MLワークロード最適化
Basic：コストとパフォーマンスのバランス

料金体系とコスト分析

AWS EFS 料金構造

ストレージクラス別料金（us-east-1）

Standard: $0.30/GB/月
Standard-IA: $0.025/GB/月（アクセス料金: $0.01/GB）
One Zone: $0.16/GB/月
One Zone-IA: $0.0133/GB/月（アクセス料金: $0.01/GB）

追加料金

Provisioned Throughput：$6.00/MB/s/月
データ転送：リージョン間転送で課金

GCP Cloud Filestore 料金構造

ティア別料金（us-central1）

ティア	HDD料金	SSD料金	最小容量
Basic	$0.20/GB/月	$0.30/GB/月	1TB/2.5TB
High Scale	-	$0.36/GB/月	10TB
Enterprise	$0.35/GB/月	$0.60/GB/月	1TB

実際のコスト比較例

シナリオ1：中規模Webアプリケーション（5TB、月間アクセス頻度高）

AWS EFS Standard:
- ストレージ: 5TB × $0.30 = $1,500/月
- 合計: $1,500/月

GCP Filestore Basic HDD:
- ストレージ: 5TB × $0.20 = $1,000/月  
- 合計: $1,000/月

差額: $500/月（Filestoreが有利）

シナリオ2：AI/MLワークロード（10TB、高IOPS要求）

AWS EFS Max I/O + Provisioned:
- ストレージ: 10TB × $0.30 = $3,000/月
- Provisioned Throughput: 500MB/s × $6.00 = $3,000/月
- 合計: $6,000/月

GCP Filestore High Scale SSD:
- ストレージ: 10TB × $0.36 = $3,600/月
- 合計: $3,600/月

差額: $2,400/月（Filestoreが有利）

実装・運用のベストプラクティス

AWS EFS 実装例

基本セットアップ

# CloudFormation例
Resources:
  MyEFS:
    Type: AWS::EFS::FileSystem
    Properties:
      PerformanceMode: generalPurpose
      ThroughputMode: provisioned
      ProvisionedThroughputInMibps: 1024
      LifecyclePolicies:
        - TransitionToIA: AFTER_30_DAYS
        - TransitionToPrimaryStorageClass: AFTER_1_ACCESS

  MountTarget:
    Type: AWS::EFS::MountTarget
    Properties:
      FileSystemId: !Ref MyEFS
      SubnetId: subnet-12345678
      SecurityGroups:
        - !Ref EFSSecurityGroup

EC2からのマウント

# NFSクライアントインストール
sudo yum install -y nfs-utils

# マウント
sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576 \
  fs-12345678.efs.us-east-1.amazonaws.com:/ /mnt/efs

GCP Cloud Filestore 実装例

基本セットアップ

# Deployment Manager例
resources:
- name: my-filestore
  type: gcp-types/file-v1:projects.locations.instances
  properties:
    parent: projects/PROJECT_ID/locations/us-central1-a
    instanceId: my-filestore
    instance:
      tier: BASIC_HDD
      fileShares:
      - name: share1
        capacityGb: 1024
      networks:
      - network: projects/PROJECT_ID/global/networks/default
        modes:
        - MODE_IPV4

Compute Engineからのマウント

# NFSクライアントインストール
sudo apt-get update && sudo apt-get install -y nfs-common

# マウント
sudo mount -t nfs -o nfsvers=3 \
  FILESTORE_IP:/share1 /mnt/filestore

Kubernetes統合

AWS EFS CSI Driver

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-12345678
  directoryPerms: "0755"

GCP Filestore CSI Driver

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: filestore-csi
provisioner: filestore.csi.storage.gke.io
parameters:
  tier: basic-hdd
  network: default

ユースケース別最適選択

一般的Webアプリケーション

要件	AWS EFS	GCP Filestore
コスト重視	Standard-IA	Basic HDD
パフォーマンス重視	Provisioned	Basic SSD
高可用性	Multi-AZ	Enterprise

AI/MLワークロード

大規模データセット処理

AWS：EFS Max I/O + Provisioned Throughput
GCP：Filestore High Scale SSD

モデル訓練

# 高スループット要件の場合
AWS: 複数EFSマウントターゲット + 並列アクセス
GCP: High Scale SSDで単一インスタンス高性能

HPC（High Performance Computing）

特徴比較

項目	AWS EFS	GCP Filestore
最大スループット	10GB/s（理論値）	32GB/s（320TB High Scale）
最大IOPS	500,000+	400,000
レイテンシ	1-3ms	<1ms（SSD）

運用監視とトラブルシューティング

パフォーマンス監視

AWS EFS

# CloudWatch メトリクス例
aws cloudwatch get-metric-statistics \
  --namespace AWS/EFS \
  --metric-name TotalIOBytes \
  --dimensions Name=FileSystemId,Value=fs-12345678 \
  --statistics Sum \
  --start-time 2023-01-01T00:00:00Z \
  --end-time 2023-01-02T00:00:00Z \
  --period 3600

GCP Filestore

# Cloud Monitoring メトリクス例
gcloud logging read "resource.type=filestore_instance" \
  --format="table(timestamp,severity,textPayload)" \
  --limit=50

よくある問題と解決法

AWS EFS

問題：スループットが期待値に達しない
解決：バーストクレジット確認、Provisioned Throughput検討

GCP Filestore

問題：容量不足エラー
解決：事前容量プランニング、適切なティア選択

まとめ：戦略的選択指針

AWS EFSを選ぶべきケース

✅ 変動的なワークロード：容量やアクセスパターンが予測困難
✅ コスト最適化重視：Intelligent Tiering活用
✅ サーバーレス統合：Lambda、Fargateとの連携
✅ AWS生態系中心：他AWSサービスとの深い統合

GCP Filestoreを選ぶべきケース

✅ 予測可能なパフォーマンス：一貫したIOPS・スループット要求
✅ 高性能ワークロード：AI/ML、HPC、レンダリング
✅ GCP生態系活用：GKE、Compute Engine最適化
✅ エンタープライズ要件：高可用性、リージョン間レプリケーション

コスト効率化の指針

ワークロード特性	推奨サービス	理由
大容量・低頻度アクセス	EFS Standard-IA	自動ティアリング
中容量・高頻度アクセス	Filestore Basic	固定コスト予測性
高性能・大容量	Filestore High Scale	スループット単価優位

次回予告

Day26では、メッセージングサービスに焦点を当て、AWS SNS/SQSとGCP Pub/Subの詳細比較を行う。

イベント駆動アーキテクチャの要となるメッセージング基盤について、配信保証、順序保証、スケーリング特性の違いを徹底解析する。

共有ファイルストレージの選択は、アプリケーションアーキテクチャの基盤を決定する重要な判断である。それぞれの特性を理解し、要件に最適なサービスを選択することが、効率的なシステム構築の第一歩となる。

この記事が皆さんのクラウド戦略立案の参考になれば幸いである。「いいね」と「ストック」をお願いしたい！

シリーズ記事一覧

[【1日目】はじめの一歩！AWSエンジニアがGCPで最初にやるべきこと]
[【2日目】GCPのIAMはAWSとどう違う？「プリンシパル」と「ロール」の理解]
[【3日目】VPCとVPCネットワーク：GCPのネットワーク設計思想を理解する]
[【4日目】S3とCloud Storage：オブジェクトストレージを徹底比較]
[【5日目】RDSとCloud SQL：マネージドデータベースの運用管理の違い]
[【6日目】EC2とCompute Engine：インスタンスの起動から課金モデルまで]
[【7日目】1週間のまとめ：AWSとGCP、それぞれの得意なことと設計思想]
[【8日目】EKSとGKE：Kubernetesのマネージドサービスを比較体験！]
[【9日目】Dockerイメージをどこに置く？ECRとArtifact Registryを比較]
[【10日目】LambdaとCloud Functions：イベント駆動型サーバーレスの実装]
[【11日目】API GatewayとCloud Endpoints：API公開のベストプラクティス]
[【12日目】Cloud Run：サーバーレスでコンテナを動かすGCPの独自サービスを試してみよう]
[【13日目】AWS FargateとCloud Run：コンテナ運用モデルの根本的な違い]
[【14日目】2週間のまとめ：GCPのコンテナ・サーバーレス技術はなぜ優れているのか？]
[【15日目】RedshiftとBigQuery：データウェアハウスのアーキテクチャと料金体系]
[【16日目】BigQueryをハンズオン！クエリを書いてデータ分析を体験]
[【17日目】AthenaとBigQuery：データレイクに対するアプローチの違い]
[【18日目】SageMakerとVertex AI：機械学習プラットフォームの比較]
[【19日目】BigQuery MLでSQLだけで機械学習モデルを作ってみよう]
[【20日目】Cloud SQLのレプリカ設定とパフォーマンスチューニング]
[【21日目】GKE IngressとService Meshの比較]
[【22日目】CloudWatchとCloud Monitoring：ログとメトリクスの監視設定]
[【23日目】AWS BackupとGCPのバックアップ戦略：スナップショットとリージョン]
[【24日目】AWS CloudFormationとGCP Cloud Deployment Manager：IaCのベストプラクティス]
[【25日目】AWSのEFSとGCPのFilestore：共有ファイルストレージ徹底比較]（この記事）
[【26日目】AWSとの連携：GCPからAWSリソースを操作するハイブリッド構成]