メインコンテンツまでスキップ
最新20d ago

Amazon S3 Files — 完全セットアップ & IaC ガイド

新しい Amazon S3 Files 機能(2026年4月7日 リリース)に関するハンズオン、Notion対応のリファレンス。S3 Filesとは何か、どのように動作するのか、TerraformAWS CDK (TypeScript) を使用してプロビジョニングする方法、ターミナルからマウントされたバケットを検査する方法、およびモニタリング用のダッシュボードについてカバーしています。 ステータス: 一般利用可能 · リージョン: すべての商用AWSリージョン 最終確認: 2026年4月21日


目次

  1. Amazon S3 Filesについて

  2. 主な機能と数値

  3. 内部の動作原理

  4. アーキテクチャ図(メンタルモデル)

  5. 前提条件

  6. AWSコンソールでのセットアップ(最速パス)

  7. AWS CLIでのセットアップ(公式コマンド)

  8. Terraformでのセットアップ

  9. AWS CDK (TypeScript) でのセットアップ

  10. EC2、ECS、EKS、Lambdaからのマウント

  11. バケット-アズ-ファイルシステムを検査するターミナルコマンド

  12. ダッシュボードと可観測性(CloudWatch、CloudTrail)

  13. IAMとセキュリティモデル

  14. S3 Files vs Mountpoint vs EFS vs FSx

  15. 制限事項とよくある落とし穴

  16. 価格設定に関する注記

  17. リファレンスリンク


1. Amazon S3 Filesについて

Amazon S3 Filesは、通常のS3汎用バケットの前に置かれた共有POSIX形式ファイルシステムで、そのバケットを任意のAWSコンピュート(EC2、ECS、EKS、Fargate、Lambda、Batch)から NFS v4.1+ 経由でアクセス可能にします。データを重複させることはありません。読み取りと書き込みは高性能キャッシュレイヤー(内部的にAmazon EFSに基づいている)と基礎となるS3バケット間で流れ、ファイルシステムを通じて行われた変更は通常のS3オブジェクトとして表示され、S3で行われた変更はファイルシステムに表示されます。 実際には:

  • アプリケーションは /mnt/s3files/ のようなマウントポイントに対して open()read()write()lscprm を実行します。

  • 同じバイト列が s3://bucket-name/key とS3 API経由でアクセス可能です。

  • 最大 25,000 のコンピュートリソースが同じファイルシステムに一度にアタッチできます。

  • FUSE、カスタムコネクタ、アプリケーション用の新しいAPIを使用せず、完全な機能を備えた高性能のネイティブファイルシステムインターフェースを備えた最初のクラウドオブジェクトストアです。


2. 主な機能と数値

機能
プロトコルNFS v4.1+
バッキングストレージEFSキャッシュレイヤー + S3バケット(真実の唯一の情報源)
アクティブデータレイテンシ~1 ms
集約読み取りスループット複数TB/s(ローンチマテリアルで4 TB/s+引用)
IOPSバケットあたり10M+ファイルシステムIOPS
同時コンピュートクライアント最大25,000
キャッシュ保持ウィンドウ1~365日、デフォルト30日
大規模読み取り閾値≥1 MiBの読み取りはS3から直接ストリーミング
S3 → ファイルシステムの同期秒単位(時々~1分かかることもあり)
ファイルシステム → S3の同期~1分以内
暗号化転送中はTLS 1.3、保存時はSSE-S3またはSSE-KMS
認証IAM(常に有効、無効にできません)
リージョンすべての商用AWSリージョン

3. 内部の動作原理

内部的には、S3 FilesはAmazon EFSに基づいており、Linuxの mount コマンドが理解できる s3files という新しいNFSファイルシステムタイプを導入します(amazon-efs-utils パッケージv3.0.0+経由)。 データフロー:

  1. 読み取りパス。 アプリケーションがファイルを読み取ると、S3 FilesはファイルをS3 Filesが遅延ロードします(またはそのメタデータのみ)高性能キャッシュに。その後の読み取りはキャッシュから~1 msで実行されます。≥1 MiBの読み取りはS3から直接ストリーミングされ、標準的なS3 GET料金のみが発生します。ファイルシステムキャッシュコストはかかりません。

  2. 書き込みパス。 書き込みは高性能キャッシュに最初にヒットし、バッチ処理され、その後S3に新しいオブジェクトまたは新しいS3バージョンとしてフラッシュされます。このため、S3バケットのバージョン管理が 必須 です。

  3. 変更検出。 S3 Filesは管理されたEventBridgeルール(DO-NOT-DELETE-S3-Files* という名前)を作成して、S3 API経由で行われた変更が検出され、ファイルシステムに反映されるようにします。

  4. キャッシュ有効期限。 構成されたウィンドウ(1~365日、デフォルト30日)内でタッチされていないファイルはキャッシュから期限切れになります。S3に留まり、次のアクセス時に再フェッチされます。

  5. 一貫性モデル。 NFS close-to-open一貫性 — つまり、1つのクライアントがファイルを閉じると、他のクライアントはそれを開く際に新しいバージョンを見ます。


4. アーキテクチャ図(メンタルモデル)

         ┌────────────────────────────────────────────┐
│ Your VPC │
│ │
│ ┌───────────┐ ┌──────────────────┐ │
│ │ EC2 / │ NFS │ Mount Target │ │
│ │ ECS / ├─────▶│ (one per AZ) │ │
│ │ EKS / │ 2049 │ │ │
│ │ Lambda │ └──────┬───────────┘ │
│ └───────────┘ │ │
└─────────────────────────────┼──────────────┘


┌─────────────────────────┐
│ S3 File System │
│ (fs-xxxx, backed by │
│ EFS high-perf cache) │
└──────────┬──────────────┘
│ two-way sync

┌─────────────────────────┐
│ S3 General Purpose │
│ Bucket (versioned, │
│ SSE-S3 or SSE-KMS) │
└─────────────────────────┘

順序による3つのリソース: file system → mount target(s) → mount command


5. 前提条件

AWSの前提条件ページから直接:

  • AWSアカウント。

  • コンピュートリソース(EC2/ECS/EKS/Lambda)と同じリージョンの S3汎用バケット

  • バケットで S3バージョン管理が有効(同期に必須)。

  • バケット暗号化は SSE-S3 または SSE-KMS である必要があります。

  • EC2インスタンスにインストールされた amazon-efs-utils v3.0.0+(EFSおよびS3 Filesの共有クライアント)。

  • 2つのIAMロール:

    • S3 Filesがバケットを読み取り/書き込みし、EventBridgeルールを管理するために引き受ける サービスロール
    • AmazonS3FilesClientFullAccess または AmazonS3FilesClientReadOnlyAccess マネージドポリシーに加えて、直接的な s3:GetObject/s3:ListBucket を付与するインラインポリシーを含む コンピュートロール(EC2インスタンスプロファイルなど)。
  • コンピュートセキュリティグループとマウントターゲットセキュリティグループの間で TCP 2049 を許可するセキュリティグループ。

ヒント。 AWSコンソールを通じてファイルシステムを作成する場合、サービスIAMロール、デフォルトVPC内のAZごとに1つのマウントターゲット、およびファイルシステムの1つのアクセスポイントが自動的に作成されます。


6. AWSコンソールでのセットアップ(最速パス)

  1. S3コンソール → 汎用バケット → バケットを選択 → ファイルシステム タブ → ファイルシステムを作成

  2. VPC を確認します(テスト用のデフォルトVPCで問題ありません)。

  3. 作成 をクリックします。コンソールはファイルシステム、AZごとに1つのマウントターゲット、アクセスポイント、およびサービスIAMロールをプロビジョニングします。

  4. ファイルシステムの 概要 ページで、EC2インスタンスにアタッチ の下の アタッチ を選択し、EC2インスタンスを選択して、マウントパス(例:/mnt/s3files/)を入力し、CloudShellで生成されたマウントコマンドに従います。

  5. EC2インスタンスのIAMロールにマネージドポリシー AmazonS3FilesClientFullAccess をアタッチします。


7. AWS CLIでのセットアップ(公式コマンド)

これらは正確なAWS記載コマンドです。プレースホルダーを置き換えます。

7.1 ファイルシステムを作成する

aws s3files create-file-system \
--region <aws-region> \
--bucket <bucket-arn> \
--role-arn <iam-role-arn>

  • <bucket-arn> — 例:arn:aws:s3:::my-bucket

  • <iam-role-arn> — S3 Filesが引き受ける サービスロール(§13を参照) 応答は ファイルシステムIDfs-xxxxxxxx…)を含むJSON説明を返します。保存します。

7.2 マウントターゲットを作成する(AZごとに1つ)

マウントターゲットはVPC内に存在し、ファイルシステムをクライアントに公開するENIです。使用する各AZごとに1つ作成します。

aws s3files create-mount-target \
--region <aws-region> \
--file-system-id <fs-id> \
--subnet-id <subnet-id>

作成には最大~5分かかります。

7.3 説明/検証


# ファイルシステムを検索
aws s3files get-file-system \
--region <aws-region> \
--file-system-id <fs-id>

# リージョン内のすべてのファイルシステムをリスト表示
aws s3files list-file-systems --region <aws-region>

# ファイルシステムのマウントターゲットをリスト表示
aws s3files describe-mount-targets \
--region <aws-region> \
--file-system-id <fs-id>

7.4 EC2シェルからマウント

sudo mkdir -p /mnt/s3files
sudo mount -t s3files <fs-id>:/ /mnt/s3files

ファイルシステムチェックの完全な例は§11にあります。

7.5 削除


# 最初にアンマウント
sudo umount /mnt/s3files

# マウントターゲットを削除(fs削除前に必須)
aws s3files delete-mount-target --mount-target-id <mt-id>

# ファイルシステムを削除
aws s3files delete-file-system --file-system-id <fs-id>


8. Terraformでのセットアップ

2026年4月21日現在の重要な注意事項: HashiCorpはネイティブTerraformサポートのためのトラッキング課題(GitHub #47324)を持っています — aws_s3files_file_systemaws_s3files_mount_target リソースが追加されており、AWS provider v6.40.0 の対象とされています。そのリリースがあなたの状態に着地するまで、コミュニティ推奨パターンは terraform_data + local-exec AWS CLIを呼び出している です。以下の両方のフレーバー。

8.1 変数とプロバイダ

terraform {
required_version = ">= 1.6.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = ">= 5.80, < 7.0"
}
}
}

provider "aws" {
region = var.aws_region
}

variable "aws_region" { type = string default = "us-east-1" }
variable "bucket_name" { type = string default = "my-s3files-bucket" }
variable "subnet_ids" { type = list(string) } # カバーしたいAZごとに1つ

8.2 バケット前提条件(バージョン管理+暗号化)

resource "aws_s3_bucket" "data" {
bucket = var.bucket_name
}

resource "aws_s3_bucket_versioning" "data" {
bucket = aws_s3_bucket.data.id
versioning_configuration { status = "Enabled" }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
bucket = aws_s3_bucket.data.id
rule {
apply_server_side_encryption_by_default { sse_algorithm = "AES256" }
}
}

8.3 サービスIAMロール(S3 Filesが引き受けるもの)

data "aws_caller_identity" "current" {}

locals {
account_id = data.aws_caller_identity.current.account_id
region = var.aws_region
}

resource "aws_iam_role" "s3files_service" {
name = "S3FilesServiceRole-${var.bucket_name}"

assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Sid = "AllowS3FilesAssumeRole"
Effect = "Allow"
Principal = { Service = "elasticfilesystem.amazonaws.com" }
Action = "sts:AssumeRole"
Condition = {
StringEquals = { "aws:SourceAccount" = local.account_id }
ArnLike = { "aws:SourceArn" = "arn:aws:s3files:${local.region}:${local.account_id}:file-system/*" }
}
}]
})
}

resource "aws_iam_role_policy" "s3files_service" {
role = aws_iam_role.s3files_service.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Sid = "S3BucketPermissions"
Effect = "Allow"
Action = ["s3:ListBucket", "s3:ListBucketVersions"]
Resource = aws_s3_bucket.data.arn
Condition = { StringEquals = { "aws:ResourceAccount" = local.account_id } }
},
{
Sid = "S3ObjectPermissions"
Effect = "Allow"
Action = [
"s3:AbortMultipartUpload",
"s3:DeleteObject*",
"s3:GetObject*",
"s3:List*",
"s3:PutObject*"
]
Resource = "${aws_s3_bucket.data.arn}/*"
Condition = { StringEquals = { "aws:ResourceAccount" = local.account_id } }
},
{
Sid = "EventBridgeManage"
Effect = "Allow"
Action = [
"events:DeleteRule", "events:DisableRule", "events:EnableRule",
"events:PutRule", "events:PutTargets", "events:RemoveTargets"
]
Condition = { StringEquals = { "events:ManagedBy" = "elasticfilesystem.amazonaws.com" } }
Resource = ["arn:aws:events:*:*:rule/DO-NOT-DELETE-S3-Files*"]
},
{
Sid = "EventBridgeRead"
Effect = "Allow"
Action = [
"events:DescribeRule", "events:ListRuleNamesByTarget",
"events:ListRules", "events:ListTargetsByRule"
]
Resource = ["arn:aws:events:*:*:rule/*"]
}
]
})
}

8.4 マウントターゲット用セキュリティグループ

resource "aws_security_group" "s3files_mt" {
name = "s3files-mount-target"
description = "Allow NFS 2049 from app compute"
vpc_id = var.vpc_id
}

resource "aws_vpc_security_group_ingress_rule" "nfs_in" {
security_group_id = aws_security_group.s3files_mt.id
referenced_security_group_id = var.app_sg_id
from_port = 2049
to_port = 2049
ip_protocol = "tcp"
}

8.5 ファイルシステム+マウントターゲット — ネイティブリソース(v6.40.0がリリースされたら)


# aws_s3files_file_systemが出荷されたら予想される形状。applyする前にプロバイダCHANGELOGで引数名を確認します。
resource "aws_s3files_file_system" "this" {
bucket = aws_s3_bucket.data.arn
role_arn = aws_iam_role.s3files_service.arn
}

resource "aws_s3files_mount_target" "per_az" {
for_each = toset(var.subnet_ids)
file_system_id = aws_s3files_file_system.this.id
subnet_id = each.value
security_group_ids = [aws_security_group.s3files_mt.id]
}

output "file_system_id" {
value = aws_s3files_file_system.this.id
}

8.6 ファイルシステム+マウントターゲット — フォールバック(terraform_data + AWS CLI)

これを ~までは プロバイダv6.40.0がリリースされます。§7で設定したAWS CLIを呼び出します。

resource "terraform_data" "s3files_fs" {
input = {
region = var.aws_region
bucket_arn = aws_s3_bucket.data.arn
role_arn = aws_iam_role.s3files_service.arn
}

provisioner "local-exec" {
command = <<-EOT
set -euo pipefail
FS_ID=$(aws s3files create-file-system \
--region ${self.input.region} \
--bucket ${self.input.bucket_arn} \
--role-arn ${self.input.role_arn} \
--query FileSystemId --output text)
echo "$FS_ID" > ${path.module}/.s3files-fs-id
EOT
}

provisioner "local-exec" {
when = destroy
command = <<-EOT
FS_ID=$(cat ${path.module}/.s3files-fs-id)
# 最初にすべてのマウントターゲットを破棄し、次にfsを削除します
for MT in $(aws s3files describe-mount-targets --file-system-id $FS_ID \
--query 'MountTargets[].MountTargetId' --output text); do
aws s3files delete-mount-target --mount-target-id $MT
done
aws s3files delete-file-system --file-system-id $FS_ID
EOT
}
}

data "local_file" "fs_id" {
depends_on = [terraform_data.s3files_fs]
filename = "${path.module}/.s3files-fs-id"
}

resource "terraform_data" "mount_targets" {
for_each = toset(var.subnet_ids)
input = { fs_id = trimspace(data.local_file.fs_id.content), subnet_id = each.value }

provisioner "local-exec" {
command = <<-EOT
aws s3files create-mount-target \
--region ${var.aws_region} \
--file-system-id ${self.input.fs_id} \
--subnet-id ${self.input.subnet_id}
EOT
}
}

8.7 コンピュート側IAM(EC2インスタンスプロファイル)

resource "aws_iam_role" "app_ec2" {
name = "S3FilesEC2Role"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = { Service = "ec2.amazonaws.com" }
Action = "sts:AssumeRole"
}]
})
}

resource "aws_iam_role_policy_attachment" "client_full" {
role = aws_iam_role.app_ec2.name
policy_arn = "arn:aws:iam::aws:policy/AmazonS3FilesClientFullAccess"
}

resource "aws_iam_role_policy" "app_s3_read" {
role = aws_iam_role.app_ec2.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{ Effect = "Allow", Action = ["s3:GetObject", "s3:GetObjectVersion"], Resource = "${aws_s3_bucket.data.arn}/*" },
{ Effect = "Allow", Action = "s3:ListBucket", Resource = aws_s3_bucket.data.arn }
]
})
}

resource "aws_iam_instance_profile" "app_ec2" {
name = "S3FilesEC2Profile"
role = aws_iam_role.app_ec2.name
}


9. AWS CDK (TypeScript) でのセットアップ

S3 FilesのAWS CDK L2コンストラクトはまだ展開されています(機能は2026年4月7日にシップされました)。@aws-cdk/aws-s3files-alpha が安定するまで、AwsCustomResource が必要な場所でL1/L2コンストラクトの混合を使用します。

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as iam from 'aws-cdk-lib/aws-iam';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import { AwsCustomResource, AwsCustomResourcePolicy, PhysicalResourceId } from 'aws-cdk-lib/custom-resources';

export class S3FilesStack extends cdk.Stack {
constructor(scope: Construct, id: string, props: cdk.StackProps & { vpc: ec2.IVpc }) {
super(scope, id, props);

// 1. 必要な設定を備えたバケット
const bucket = new s3.Bucket(this, 'DataBucket', {
bucketName: 'my-s3files-bucket',
versioned: true, // S3 Filesで必須
encryption: s3.BucketEncryption.S3_MANAGED, // SSE-S3(またはKMS_MANAGED / KMS)
blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
enforceSSL: true,
});

// 2. S3 Filesが引き受けるサービスロール
const serviceRole = new iam.Role(this, 'S3FilesServiceRole', {
assumedBy: new iam.ServicePrincipal('elasticfilesystem.amazonaws.com', {
conditions: {
StringEquals: { 'aws:SourceAccount': this.account },
ArnLike: { 'aws:SourceArn': `arn:aws:s3files:${this.region}:${this.account}:file-system/*` },
},
}),
});

bucket.grantReadWrite(serviceRole);
serviceRole.addToPolicy(new iam.PolicyStatement({
actions: ['s3:ListBucket', 's3:ListBucketVersions'],
resources: [bucket.bucketArn],
conditions: { StringEquals: { 'aws:ResourceAccount': this.account } },
}));
serviceRole.addToPolicy(new iam.PolicyStatement({
actions: [
'events:PutRule', 'events:DeleteRule', 'events:EnableRule', 'events:DisableRule',
'events:PutTargets', 'events:RemoveTargets',
],
resources: ['arn:aws:events:*:*:rule/DO-NOT-DELETE-S3-Files*'],
conditions: { StringEquals: { 'events:ManagedBy': 'elasticfilesystem.amazonaws.com' } },
}));
serviceRole.addToPolicy(new iam.PolicyStatement({
actions: ['events:DescribeRule', 'events:ListRules', 'events:ListRuleNamesByTarget', 'events:ListTargetsByRule'],
resources: ['arn:aws:events:*:*:rule/*'],
}));

// 3. マウントターゲット用セキュリティグループ
const mtSg = new ec2.SecurityGroup(this, 'S3FilesMountTargetSg', {
vpc: props.vpc,
description: 'NFS 2049 inbound for S3 Files mount target',
});

// 4. AwsCustomResourceを介してファイルシステムを作成(L2が出荷されるまで)
const fileSystem = new AwsCustomResource(this, 'S3FilesFileSystem', {
onCreate: {
service: 's3files',
action: 'createFileSystem',
parameters: { Bucket: bucket.bucketArn, RoleArn: serviceRole.roleArn },
physicalResourceId: PhysicalResourceId.fromResponse('FileSystemId'),
},
onDelete: {
service: 's3files',
action: 'deleteFileSystem',
parameters: { FileSystemId: new cdk.PhysicalName('FileSystemId').toString() },
},
policy: AwsCustomResourcePolicy.fromStatements([
new iam.PolicyStatement({
actions: ['s3files:CreateFileSystem', 's3files:DeleteFileSystem', 'iam:PassRole'],
resources: ['*'],
}),
]),
});
const fsId = fileSystem.getResponseField('FileSystemId');

// 5. プライベートサブネットあたり1つのマウントターゲット
props.vpc.privateSubnets.forEach((subnet, i) => {
new AwsCustomResource(this, `S3FilesMountTarget${i}`, {
onCreate: {
service: 's3files',
action: 'createMountTarget',
parameters: {
FileSystemId: fsId,
SubnetId: subnet.subnetId,
SecurityGroups: [mtSg.securityGroupId],
},
physicalResourceId: PhysicalResourceId.fromResponse('MountTargetId'),
},
policy: AwsCustomResourcePolicy.fromStatements([
new iam.PolicyStatement({ actions: ['s3files:CreateMountTarget'], resources: ['*'] }),
]),
});
});

// 6. コンピュート側IAM:マウント+バケット読み取りできるEC2ロール
const ec2Role = new iam.Role(this, 'AppEc2Role', {
assumedBy: new iam.ServicePrincipal('ec2.amazonaws.com'),
managedPolicies: [iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonS3FilesClientFullAccess')],
});
bucket.grantRead(ec2Role);

new cdk.CfnOutput(this, 'FileSystemId', { value: fsId });
}
}

ネイティブCDK L2コンストラクトがリリースされたら(@aws-cdk/aws-s3files-alpha を追跡)、AwsCustomResource ブロックを new s3files.FileSystem(...) および fileSystem.addMountTarget(...) に折りたたみます。


10. EC2、ECS、EKS、Lambdaからのマウント

10.1 EC2 — ワンショット


# クライアントをインストール(Amazon Linux)
sudo yum -y install amazon-efs-utils

# または、他のディストロについて:
curl https://amazon-efs-utils.aws.com/efs-utils-installer.sh | sudo sh -s -- --install

# マウント
sudo mkdir -p /mnt/s3files
sudo mount -t s3files fs-0123456789abcdef0:/ /mnt/s3files

マウントヘルパーは自動的にTLS 1.2+とIAM認証を実施します。これらは無効にできません。デフォルトは nfsvers=4.2, rsize=1048576, wsize=1048576, hard, timeo=600, retrans=2, noresvport, tls, iam です。

10.2 EC2 — /etc/fstab 経由でブート時に自動マウント

fs-0123456789abcdef0:/  /mnt/s3files  s3files  _netdev,nofail  0  0

  • _netdev必須(ネットワーク依存マウント) — これなしでは、インスタンスはブート時にハング可能です。

  • nofail はマウントが失敗した場合でもインスタンスがまだブートするため推奨されます。 特定のアクセスポイントにピンするには:

fs-xxxx:/  /mnt/s3files  s3files  _netdev,accesspoint=fsap-xxxx  0  0

sudo mount -a でテストしてから findmnt -T /mnt/s3files

10.3 ECS / Fargate / EKSコンテナ

標準的なEFS/NFSボリュームの配管を使用してファイルシステムをボリュームとしてアタッチします — ECSタスク定義およびEKS PersistentVolume 仕様は、同じ方法でS3 Files fs-xxxx IDを受け入れます。タスクロールには AmazonS3FilesClientFullAccess(またはread-onlyの同等物)に加えて、同じインライン s3:GetObject/s3:ListBucket 付与が必要です。

10.4 AWS Lambda

Lambda関数は、関数のファイルシステム設定を介して /mnt/s3files などのパスにファイルシステムをマウントします。関数の実行ロールはEC2と同じコンピュート側IAMが必要です。

10.5 クロスVPC/クロスリージョンマウント

ピアリングされたVPCまたはTransit Gatewayから、DNSをバイパスしてマウントターゲットのIPを明示的に渡します:

sudo mount -t s3files \
-o mounttargetip=10.0.12.34 \
fs-0123456789abcdef0 /mnt/s3files

クロスリージョンの場合は、/etc/amazon/efs/s3files-utils.conf を編集して region = <source-region> 行をコメント解除します。

10.6 アンマウント

sudo umount /mnt/s3files
findmnt -T /mnt/s3files # クリーンの場合は出力なし


11. バケット-アズ-ファイルシステムを検査するターミナルコマンド

これはあなたが尋ねたリストです — マウントを検証しファイルシステム↔S3ビューを比較するためのすべての有用なシェルコマンド。

11.1 マウントされていますか?どのようなオプション?


# マウントはカーネルによってリストされていますか?
findmnt -T /mnt/s3files

# 空き容量/使用容量(エクサバイトスケール疑似サイズを表示)
df -h /mnt/s3files

# ボックス上のすべてのNFSマウント
mount | grep s3files

# s3filesファイルシステムタイプは利用可能ですか?
cat /proc/filesystems | grep nfs

予想される df -h 出力:

Filesystem     Size  Used Avail Use% Mounted on
fs-xxx.xxx... 8.0E 129M 8.0E 1% /mnt/s3files

11.2 ファイルシステム経由でバケットを参照

cd /mnt/s3files

# すべてをリスト表示(S3プレフィックスをディレクトリとして尊重)
ls -la

# サイズのある再帰的リスト
ls -lhR | head -n 50

# ツリービュー(treeがインストールされている場合)
sudo yum -y install tree && tree -L 3 /mnt/s3files

# 深い検索
find /mnt/s3files -type f -name "*.parquet" | head

# ファイルの行数をカウント、ログをストリーミング、その他
wc -l /mnt/s3files/logs/2026-04-21.log
tail -f /mnt/s3files/logs/app.log

11.3 ファイルを書き込んでS3に具体化することを確認

echo "Hello S3 Files" > /mnt/s3files/hello.txt

# ~1分以内に、同じキーがS3に表示されます
aws s3 ls s3://my-s3files-bucket/hello.txt
aws s3api list-object-versions \
--bucket my-s3files-bucket \
--prefix hello.txt

# S3 API経由で取得
aws s3 cp s3://my-s3files-bucket/hello.txt - | cat

11.4 相互確認:両方のインターフェース経由で同じバイト?


# ファイルシステム経由で合計
sha256sum /mnt/s3files/data/big.parquet

# S3 API経由で合計
aws s3 cp s3://my-s3files-bucket/data/big.parquet - | sha256sum

11.5 CLIからS3 Files インフラストラクチャを検査


# このリージョンのファイルシステム
aws s3files list-file-systems --region us-east-1

# 1つの詳細
aws s3files get-file-system --file-system-id fs-xxx

# マウントターゲット
aws s3files describe-mount-targets --file-system-id fs-xxx

# 指定されたマウントターゲットが使用しているIP
aws s3files describe-mount-targets \
--file-system-id fs-xxx \
--query 'MountTargets[*].[MountTargetId,SubnetId,IpAddress,AvailabilityZoneName]' \
--output table

# ファイルシステムにアタッチされたアクセスポイント
aws s3files describe-access-points --file-system-id fs-xxx

11.6 クイックヘルスチェックスクリプト

#!/usr/bin/env bash
set -euo pipefail

FS_ID="${1:?usage: $0 <fs-id> <mount-dir>}"
MNT="${2:?}"

echo "== mount status =="
findmnt -T "$MNT" || { echo "NOT MOUNTED"; exit 1; }

echo "== df =="
df -hT "$MNT"

echo "== round-trip write test =="
STAMP="health-$(date +%s).txt"
echo "ok" > "$MNT/$STAMP"
sleep 70
aws s3api head-object --bucket "$(aws s3files get-file-system \
--file-system-id "$FS_ID" --query Bucket --output text | sed 's|^arn:aws:s3:::||')" \
--key "$STAMP" && echo "✔ object visible in S3"
rm "$MNT/$STAMP"


12. ダッシュボードと可観測性

はい — マウントされたディレクトリだけでなく、実際の可観測性サーフェスを取得します。

12.1 組み込みAWSコンソールダッシュボード

S3コンソールの ファイルシステム タブにはバケットの場合:

  • AZごとのマウントターゲットステータス。

  • アタッチされたアクセスポイント。

  • 現在のクライアント接続数。

  • 高性能キャッシュレイヤーに保持されているストレージ。

  • ファイルシステムあたりのCloudWatchウィジェット。

12.2 CloudWatchメトリクス(ネームスペースヒント)

S3 FilesはCloudWatchを通じて AWS/S3Files ネームスペース(EFSアンダーピニングと共有されるメトリクス)の下でメトリクスを公開します。有用なもの:

メトリクス意味
StorageBytes高性能キャッシュレイヤーに保持されているバイト
ClientConnections現在マウントされているNFSクライアントの数
DataReadIOBytes / DataWriteIOBytesI/Oスループット
TotalIOBytes集約I/O
PercentIOLimit飽和状態にどの程度近いか
PermittedThroughput / MeteredIOBytes容量対使用
SyncErrors(カスタムディメンション)失敗したS3↔FS同期イベント

ダッシュボードを以下で構築します:

aws cloudwatch put-dashboard \
--dashboard-name S3FilesOverview \
--dashboard-body file://dashboard.json

最小 dashboard.json

{
"widgets": [
{
"type": "metric",
"properties": {
"metrics": [
[ "AWS/S3Files", "StorageBytes", "FileSystemId", "fs-xxx" ],
[ ".", "ClientConnections", ".", "." ],
[ ".", "TotalIOBytes", ".", "." ]
],
"view": "timeSeries",
"stat": "Average",
"period": 60,
"title": "S3 Files — fs-xxx"
}
}
]
}

12.3 CloudWatchアラーム

aws cloudwatch put-metric-alarm \
--alarm-name S3Files-HighClientConnections \
--metric-name ClientConnections \
--namespace AWS/S3Files \
--statistic Average --period 60 \
--threshold 20000 --comparison-operator GreaterThanThreshold \
--evaluation-periods 2 \
--dimensions Name=FileSystemId,Value=fs-xxx \
--alarm-actions arn:aws:sns:us-east-1:123456789012:oncall

12.4 CloudTrail

すべての管理プレーン呼び出し(CreateFileSystemCreateMountTargetDeleteFileSystem など)は、s3files.amazonaws.com サービスからのイベントとしてCloudTrailに着地します。Athenaまたはコンソールのイベント履歴でクエリします。

12.5 マウントヘルパーログ

各EC2クライアントでは、マウントヘルパーとそのウォッチドッグは、NFS/TLSのハングアップをデバッグするのに便利な診断ログを書き込みます:

sudo journalctl -u amazon-efs-mount-watchdog -f
sudo ls /var/log/amazon/efs/

12.6 サードパーティのダッシュボード

  • Grafana CloudWatchデータソースAWS/S3Files ネームスペースを指します。軽く再ディメンション化されたEFSダッシュボードテンプレートが機能します。

  • Datadog — その AWS統合は自動的にS3 Filesメトリクスをピックアップします。


13. IAMとセキュリティモデル

プレイ時に 2つの IAMロールが動作しています。混同しないでください。

13.1 サービスロール(S3 Files → バケット)

elasticfilesystem.amazonaws.com サービスプリンシパル(S3 Filesは内部的にEFSで階層化されている)によって消費されます。S3読み取り/書き込み、KMS使用(SSE-KMS場合)、および DO-NOT-DELETE-S3-Files* という名前のルールに限定されたEventBridge管理が必要です。 公式ポリシー(§8.3の概要として再現されるTerraform) — 概要:

  • バケットの s3:ListBuckets3:ListBucketVersions

  • オブジェクトの s3:AbortMultipartUploads3:DeleteObject*s3:GetObject*s3:List*s3:PutObject*

  • kms:ViaService = s3.\\<region>.amazonaws.com 経由でスコープされた kms:GenerateDataKeykms:Encryptkms:Decryptkms:ReEncryptFromkms:ReEncryptTo

  • スコープされたEventBridge管理+広い範囲のEventBridge読み取り。

  • 信頼ポリシー:プリンシパル elasticfilesystem.amazonaws.comaws:SourceAccount および aws:SourceArn = arn:aws:s3files:\\<region>:\\<account>:file-system/* で条件付き。

13.2 コンピュートロール(EC2/Lambda/task → S3 Files)

1つの マネージドポリシーとインラインS3読み取りポリシーをアタッチします:

  • AmazonS3FilesClientFullAccess — マウント経由の読み取り+書き込み。

  • AmazonS3FilesClientReadOnlyAccess — 読み取り専用。

  • AmazonElasticFileSystemUtils — マウントヘルパーがCloudWatchメトリクスを出力できます。 インラインS3読み取りポリシー(キャッシュをバイパスして大規模読み取りを高速化):

{
"Version": "2012-10-17",
"Statement": [
{ "Effect": "Allow",
"Action": ["s3:GetObject", "s3:GetObjectVersion"],
"Resource": "arn:aws:s3:::\\<bucket>/*" },
{ "Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::\\<bucket>" }
]
}

マネージドポリシーの代わりに細粒度IAMアクション:s3files:ClientMounts3files:ClientWrites3files:ClientRootAccess

13.3 暗号化

  • 転送中: TLS 1.3、必須。マウントヘルパーは常に tls および iam を追加します。

  • 保存時: SSE-S3またはSSE-KMS(バケットと一致)。

  • FIPSモード: /etc/amazon/efs/s3files-utils.conffips_mode_enabled = true を切り替えます。

13.4 POSIX権限

S3 FilesはUID/GIDおよびファイルモードビットをオブジェクトメタデータとしてS3に格納します。ファイルシステムはIAMの上に標準的なPOSIXアクセスチェックを実施します — 両方が合格する必要があります。


14. S3 Files vs Mountpoint vs EFS vs FSx

S3 FilesMountpoint for S3EFSFSx
アクセスパターン共有読み取り/書き込みNFSFUSEクライアント、読み取り中心共有NFS共有(Lustre/ONTAP/OpenZFS/Windows)
真実の情報源S3バケットS3バケットEFSFSx
POSIXセマンティクス完全部分的(名前変更なし、ランダム書き込みなし)完全完全
最大クライアント25,000N/A(クライアント側)数千変動
レイテンシ~1 ms(キャッシュ)ネットワーク+S3サブミリ秒サブミリ秒
S3内のデータ?はい、常にはい、常にいいえいいえ(階層化を除く)
最適用途エージェント、ML訓練、コラボレーション大規模な順序読み取り、ETL汎用NASHPC、Windows、NetApp-native
コスト構造キャッシュ+S3リクエストに対して支払いS3リクエストのみGB/月層プロビジョニング

一般的なルール: 読み取り中心でシーケンシャル → Mountpoint。インタラクティブ/共有/書き込み → S3 Files。


15. 制限事項とよくある落とし穴

  • S3汎用バケットのみ — ディレクトリバケット、ベクトルバケット、またはS3 Tablesバケットではありません。

  • バージョン管理はオンである必要があります。 必須。それ以外の場合は作成を拒否します。

  • 暗号化はSSE-S3またはSSE-KMSである必要があります。

  • AZごとにVPCごとに1つのマウントターゲット。 より多くのAZが必要な場合は、明示的にカバーします。

  • マウントヘルパーはLinuxのみです。 Windowsクライアントはサポートされていません。

  • _netdev** は /etc/fstab で必須** — これなしでは、インスタンスはブート時にハング可能です。

  • 同期は瞬時ではありません。 S3 → FSから数秒、FS → S3から~1分を期待してください。

  • DO-NOT-DELETE-S3-Files* という名前の管理されたEventBridgeルールに触れないでください — サービスはそれらを必要とします。

  • Terraformネイティブサポートは保留中です(プロバイダv6.40.0)。その後まではCLIフォールバックを使用します。

  • プロバイダ固有のAPIフィールドは、プレビューとGA CDK/Terraformリソース間でわずかにシフトする可能性があります — 本番前に常にCHANGELOGで引数名を相互確認してください。

  • すべてのエッジケースでPOSIXファイルシステムではありません — close-to-open一貫性(NFSセマンティクス)であり、厳格なロックではありません。


16. 価格設定に関する注記

使用量に応じた支払い、最小コミットメントなし:

  • 高性能キャッシュレイヤー上のアクティブワーキングセットストレージ(GB-月)。

  • 小規模ファイル読み取りおよびすべての書き込み (メーター化された操作)を通じてファイルシステム。

  • 同期中の基礎となるS3リクエスト料金(標準GET/PUT価格)。

  • 大規模読み取り(≥1 MiB) はS3から直接ストリーミングされ、S3 GET料金のみが発生します — ファイルシステム操作料金はありません。

  • キャッシュ保持 1~365日(デフォルト30)は、データが「温かい」状態を保つ期間を管理します。長い保持率=キャッシュストレージ料金が高い。 AWSからの見出しクレーム:最大 90%安い S3と独立したファイルシステム間でデータをサイクルするより。正確な地域ごとのGB-月とリクエスト料金についてはS3価格設定ページを確認してください。


17. リファレンスリンク

Related Articles