【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リソースを操作するハイブリッド構成]