2026年4月、Amazon S3 Filesが一般提供開始されました。
S3の汎用バケットを、EC2やコンテナ、LambdaなどのAWS コンピューティングリソースからファイルシステムとして扱えるようになったのが大きな特徴です。
これまでS3はオブジェクトストレージとして利用するのが前提でしたが、S3 Filesによって、標準的なLinuxのファイル操作でS3上のデータを扱えるようになりました。
一方で、運用現場の観点では、
- 本当に既存の仕組みを変える価値があるのか
- EFSや従来のS3利用とどう違うのか
は、実際に触ってみないと判断しにくいところです。
そこで今回の記事では、S3 Filesの概要を整理したうえで、EC2インスタンスにマウントし、ファイル作成時の同期挙動や自動マウント設定まで確認した結果をまとめます。
Amazon S3 Filesとは
■概要
S3 Filesは、S3の汎用バケットをファイルシステムとして公開し、NFS v4.1以降の操作でアクセスできる機能です。EC2だけでなく、ECS、EKS、LambdaなどのAWSコンピューティングリソースから利用できます。S3オブジェクトはファイルやディレクトリとして見え、ファイルの作成、読み取り、更新、削除といった標準的な Linux ファイル操作で扱えます。
また、S3 FilesはS3バケットとファイルシステムを自動同期します。ファイルシステム上で更新した内容は、S3バケット側では新しいオブジェクト、または既存オブジェクトの新しいバージョンとして反映されます。
逆に、S3バケット側で追加・更新・削除されたオブジェクトも、ファイルシステム側へ自動反映されます。競合が発生した場合は、S3バケットが正となります。
●参考: https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/s3-files-synchronization.html
運用者目線では、「S3の耐久性や既存の保管先を維持したまま、ファイルシステムとして扱える」という点が大きな特徴です。
一方で、ファイルシステム上の変更がS3に即時反映されるわけではなく、同期にタイムラグがあるため、即時整合性が必要な用途では挙動を理解したうえで使う必要があります。
●参考:https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/s3-files-synchronization.html
ハンズオン
■事前準備
事前に以下の準備を実施した前提で、進めていきます。
- パブリックサブネットを持つ、Amazon VPC構築済み
- 自身の環境からEC2インスタンスに接続可能となるセキュリティグループ作成済み
- S3 Filesで利用するS3バケットではVersioningを有効化
■マウントターゲット用セキュリティグループ作成
S3 FilesをEC2から利用するには、VPC 内に作成されるマウントターゲットとの通信が必要です。マウントターゲットはVPC内のネットワークエンドポイントであり、EC2インスタンスからS3ファイルシステムへアクセスする際の接続先になります。
セキュリティグループでは、EC2インスタンスからマウントターゲットに対するTCP 2049のアウトバウンド、およびマウントターゲット側でEC2インスタンスからのTCP 2049のインバウンドを許可しておく必要があります。
↓ソースは、EC2インスタンスにアタッチするセキュリティグループです。
[Create security group]をクリックします。
マウントターゲット用セキュリティグループ作成は以上です。
■S3バケット作成
EC2インスタンスにアタッチするためのS3バケットを作成します。バージョニング有効化が必要ですので、設定しておきましょう。
↓[Bucket Versioning]から[Enable]を選択し、[Save changes]をクリック。
↓
S3バケットの作成は以上です。
■S3 ファイルシステム作成
新たに追加されたS3 Filesの機能"ファイルシステム"を作成していきます。
↓作成したS3バケットの詳細画面より、[File systems]をクリックし、[Create file system]をクリックします。
↓[General configuration]から[General purpose bucket or prefix]の値として、バケット名を入力します。[Virtual private cloud (VPC)]には、S3 ファイルシステムを利用するためのマウントターゲットを配置するVPCを選択します。EC2インスタンスをデプロイするVPCを選択しておきましょう。
[Create file system]をクリックし、完了です。
↓[File system creation is in progress. This can take a few minutes. Once your file system is created, you can attach it to any AWS compute resource.]というメッセージが出力されます。
↓続いて、[You can now navigate away from this page and you can view the details of your file system.]と、[Mount target creation is in progress. This can take a few minutes.]というメッセージが出力されます。
7分後
↓[Successfully created file system "fs-04fee52874124eef4" and sub-resources.]というメッセージが出力されました。
初めての画面なので、色々みておきます。
↓まずは、ファイルシステム作成時に、ファイルシステム用のサービスロールが作成されたようです。
↓続いて、マウントターゲットを見ると、EFSと変わらなさそうですね。
↓マウントターゲットにはセキュリティグループがすでにアタッチされていますが、VPC内にあるデフォルトのセキュリティグループがアタッチされます。作成したセキュリティグループに変更します。[Edit]をクリックしましょう。
↓
マウントターゲットは2つ作成されているので、両方とも変更しました。
↓他にも、[File system policy]というタブもあります。バケットポリシーとは別にあるんですね。
↓最初の画面に戻ると、[Attach to an EC2 instance]という項目がありました。
↓クリックしてみると、EC2にアタッチするための方法が詳しく載っています。AWS CloudShellを利用して、マネコン上からマウントの操作をするみたいですね。今回はEC2インスタンスに接続して、マウント操作を実施しますので、スキップします。
S3 ファイルシステムの作成は以上です。
■IAMロール作成
EC2インスタンスからS3 Filesをマウントするには、EC2にアタッチするIAMロールが必要です。公式ドキュメントでは、S3 Filesへの接続権限としてAmazonS3FilesClientFullAccessまたはAmazonS3FilesClientReadOnlyAccessの利用が案内されています。
加えて、リンク先S3バケットのオブジェクトを直接参照して読み取り性能を最適化するため、s3:GetObject、s3:GetObjectVersion、s3:ListBucketを許可するインラインポリシーも必要です。
なお、S3 Filesの作成時には、S3 Files自身がバケットを同期するためのサービスロール も必要です。マネジメントコンソールから作成する場合、このロールは自動作成されます。
IAMロールのダッシュボードから[Create role]をクリックします。
- Trusted entity type: AWS service
- Use case: EC2
↓
↓続いて、下記のポリシーを追加します。
- AmazonS3FilesClientFullAccess
- AmazonSSMManagedInstanceCore
↓
↓[Create role]をクリックします。
↓
作成したIAMロールにインラインポリシーを作成します。
↓[Add permissions]から[Create inline policy]をクリックします。
↓次のポリシーを貼り付け、[Next]をクリックします。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3ObjectReadAccess",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*"
},
{
"Sid": "S3BucketListAccess",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::YOUR_BUCKET_NAME"
}
]
}
↓任意で名前を付け、[Create policy]をクリックします。
IAMロール作成は以上です。
■EC2インスタンス作成
今回は EC2インスタンスからS3 Filesを利用します。EC2側では、S3 Filesクライアントとして amazon-efs-utils 3.0.0以上が必要です。
公式ドキュメントでは Amazon Linuxではパッケージ導入、それ以外の対応Linux ディストリビューションではインストーラスクリプトを用いた導入方法が案内されています。
今回確認したところ、RHEL 9.7では問題なく導入できましたが、RHEL 10では執筆時点でインストーラスクリプトが未対応でした。後者は公式ドキュメントの要件そのものではなく、今回の検証環境で確認した結果として補足しておきます。
●参考: https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/s3-files-prereq-policies.html
↓2026/04/26時点でamazon-efs-utils 3.0.0はRHEL10を未サポート
[root@ip-10-0-15-207 ~]# curl https://amazon-efs-utils.aws.com/efs-utils-installer.sh | sudo sh -s -- --install
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 6527 100 6527 0 0 168k 0 --:--:-- --:--:-- --:--:-- 172k
ERROR: Unsupported operating system version 'redhat/10.*'
それでは、EC2インスタンスを起動していきます。
↓[Launch instance]をクリックし、AMIを選択します。
- AMI: Red Hat Enterprise Linux version 9 (HVM), EBS General Purpose (SSD) Volume Type(ami-0fbbafe729d214f98)
↓その他の設定に関して、[File systems]という項目があり、[S3 Files]が選択可能です。おそらく自動でマウントしてくれるものではなく、画像内の下側にある[Mount command]を表示させるための選択かと思われます。ここで選択しなくても影響はありません。
↓続いて、[IAM instance profile]で作成したIAMロールを選択。
また、RHEL9ではSSMエージェントがプリインストールされているかわからないので、[User data]に以下を入力。
#!/bin/bash
sudo dnf install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent
echo "amazon-ssm-agent started"
[Launch instance]をクリックし、EC2インスタンス作成は以上です。
■マウント準備
EC2にS3 Filesをアタッチしていきましょう。作成したEC2インスタンスに接続してください。
念のため、私が利用しているOSの情報を載せてきます。
[root@ip-10-0-12-6 ~]# cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="9.7 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.7"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.7 (Plow)"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9"
BUG_REPORT_URL="https://issues.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 9"
REDHAT_BUGZILLA_PRODUCT_VERSION=9.7
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.7"
作成したファイルシステムをマウントするには、EFSでも利用する"amazon-efs-utils"が必要になります。以下のコマンドを実行します。
curl https://amazon-efs-utils.aws.com/efs-utils-installer.sh | sudo sh -s -- --install
【実行結果】
[root@ip-10-0-12-6 ~]# curl https://amazon-efs-utils.aws.com/efs-utils-installer.sh | sudo sh -s -- --install
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 6527 100 6527 0 0 187k 0 --:--:-- --:--:-- --:--:-- 187k
Supported operating system - redhat/9.*
Updating Subscription Management repositories.
Unable to read consumer identity
This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.
efs-utils repository 10 kB/s | 863 B 00:00
efs-utils repository 1.6 MB/s | 1.6 kB 00:00
Importing GPG key 0x7CB82846:
Userid : "efs-utils <efs-utils@amazon.com>"
Fingerprint: 2FC3 E4FE 359B 2599 6166 5C00 09C2 854A 7CB8 2846
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-efs-utils.gpg
efs-utils repository 3.0 kB/s | 3.7 kB 00:01
Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs) 119 kB/s | 4.5 kB 00:00
Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs) 104 kB/s | 4.1 kB 00:00
Red Hat Enterprise Linux 9 Client Configuration 43 kB/s | 1.5 kB 00:00
Metadata cache created.
Installed:
amazon-efs-utils-3.1.0-1.el9.x86_64 gssproxy-0.8.4-7.el9.x86_64 libev-4.33-6.el9.x86_64 libnfsidmap-1:2.5.4-38.el9_7.3.x86_64
libtirpc-1.3.3-9.el9.x86_64 libverto-libev-0.3.2-3.el9.x86_64 nfs-utils-1:2.5.4-38.el9_7.3.x86_64 quota-1:4.09-4.el9.x86_64
quota-nls-1:4.09-4.el9.noarch rpcbind-1.2.6-7.el9.x86_64 sssd-nfs-idmap-2.9.7-4.el9_7.1.x86_64 stunnel-5.71-2.el9.x86_64
[root@ip-10-0-12-6 ~]#インストールされました。
[root@ip-10-0-12-6 ~]# rpm -qa | grep amazon-efs-utils
amazon-efs-utils-3.1.0-1.el9.x86_64
続いて、botocoreをインストールします。詳しいインストール手順は、こちら
amazon-efs-utilsを使ってマウントするだけであれば、まずはクライアント導入で利用できます。
一方、公式ドキュメントでは、botocoreはamazon-efs-utilsが他のAWSサービスと連携する際に使用し、たとえばAmazon CloudWatchを利用してファイルシステムのマウント状態を監視する場合に必要なようです。
The amazon-efs-utils client uses botocore to interact with other AWS services. For example, you need to install botocore to use Amazon CloudWatch to monitor your file system.
●参考: https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/s3-files-prereq-policies.html
以下のコマンドを実行します。
sudo yum -y install wget
sudo wget https://bootstrap.pypa.io/get-pip.py -O /tmp/get-pip.py
sudo python3 /tmp/get-pip.py
sudo pip3 install botocore || sudo /usr/local/bin/pip3 install botocore
python3 -c "import botocore; print(botocore.__version__)"
【実行結果】
[root@ip-10-0-12-6 ~]# sudo yum -y install wget
Updating Subscription Management repositories.
Unable to read consumer identity
This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.
Last metadata expiration check: 0:04:27 ago on Sat 25 Apr 2026 06:26:17 AM UTC.
Dependencies resolved.
=============================================================================================================================================================
Package Architecture Version Repository Size
=============================================================================================================================================================
Installing:
wget x86_64 1.21.1-8.el9_4 rhel-9-appstream-rhui-rpms 789 k
Transaction Summary
=============================================================================================================================================================
Install 1 Package
Total download size: 789 k
Installed size: 3.1 M
Downloading Packages:
wget-1.21.1-8.el9_4.x86_64.rpm 21 MB/s | 789 kB 00:00
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 14 MB/s | 789 kB 00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : wget-1.21.1-8.el9_4.x86_64 1/1
Running scriptlet: wget-1.21.1-8.el9_4.x86_64 1/1
Verifying : wget-1.21.1-8.el9_4.x86_64 1/1
Installed products updated.
Installed:
wget-1.21.1-8.el9_4.x86_64
Complete!
[root@ip-10-0-12-6 ~]# sudo wget https://bootstrap.pypa.io/get-pip.py -O /tmp/get-pip.py
--2026-04-25 06:34:45-- https://bootstrap.pypa.io/get-pip.py
Resolving bootstrap.pypa.io (bootstrap.pypa.io)... 140.248.128.175, 2a04:4e42:90::175
Connecting to bootstrap.pypa.io (bootstrap.pypa.io)|140.248.128.175|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2193439 (2.1M) [text/x-python]
Saving to: ‘/tmp/get-pip.py’
/tmp/get-pip.py 100%[============================================================================>] 2.09M --.-KB/s in 0.01s
2026-04-25 06:34:46 (182 MB/s) - ‘/tmp/get-pip.py’ saved [2193439/2193439]
[root@ip-10-0-12-6 ~]# sudo python3 /tmp/get-pip.py
Collecting pip
Downloading pip-26.0.1-py3-none-any.whl.metadata (4.7 kB)
Collecting wheel
Downloading wheel-0.47.0-py3-none-any.whl.metadata (2.3 kB)
Collecting packaging>=24.0 (from wheel)
Downloading packaging-26.2-py3-none-any.whl.metadata (3.5 kB)
Downloading pip-26.0.1-py3-none-any.whl (1.8 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.8/1.8 MB 100.7 MB/s 0:00:00
Downloading wheel-0.47.0-py3-none-any.whl (32 kB)
Downloading packaging-26.2-py3-none-any.whl (100 kB)
Installing collected packages: pip, packaging, wheel
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0/3 [pip] WARNING: The scripts pip, pip3 and pip3.9 are installed in '/usr/local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0/3 [pip] WARNING: The script wheel is installed in '/usr/local/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed packaging-26.2 pip-26.0.1 wheel-0.47.0
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager, possibly rendering your system unusable. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv. Use the --root-user-action option if you know what you are doing and want to suppress this warning.
[root@ip-10-0-12-6 ~]# sudo pip3 install botocore || sudo /usr/local/bin/pip3 install botocore
sudo: pip3: command not found
Collecting botocore
Downloading botocore-1.42.96-py3-none-any.whl.metadata (5.9 kB)
Collecting jmespath<2.0.0,>=0.7.1 (from botocore)
Downloading jmespath-1.1.0-py3-none-any.whl.metadata (7.6 kB)
Requirement already satisfied: python-dateutil<3.0.0,>=2.1 in /usr/lib/python3.9/site-packages (from botocore) (2.9.0.post0)
Requirement already satisfied: urllib3<1.27,>=1.25.4 in /usr/lib/python3.9/site-packages (from botocore) (1.26.5)
Requirement already satisfied: six>=1.5 in /usr/lib/python3.9/site-packages (from python-dateutil<3.0.0,>=2.1->botocore) (1.15.0)
Downloading botocore-1.42.96-py3-none-any.whl (14.9 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 14.9/14.9 MB 167.4 MB/s 0:00:00
Downloading jmespath-1.1.0-py3-none-any.whl (20 kB)
Installing collected packages: jmespath, botocore
Successfully installed botocore-1.42.96 jmespath-1.1.0
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager, possibly rendering your system unusable. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv. Use the --root-user-action option if you know what you are doing and want to suppress this warning.
[root@ip-10-0-12-6 ~]# python3 -c "import botocore; print(botocore.__version__)"
1.42.96
マウント準備は以上です。
■マウント
ファイルシステムをマウントする準備が整いましたので、マウントしていきます。
以下のコマンドを実行します。
sudo mkdir /mnt/s3files
sudo mount -t s3files ＜YOUR FILE SYSTEM ID＞ /mnt/s3files
ls /mnt/s3files
【実行結果】
[root@ip-10-0-12-6 ~]# mkdir /mnt/s3files
[root@ip-10-0-12-6 ~]# ls /mnt/
s3files
[root@ip-10-0-12-6 ~]# mount -t s3files fs-04fee52874124eef4 /mnt/s3files
[root@ip-10-0-12-6 ~]# mount | grep s3
127.0.0.1:/ on /mnt/s3files type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,noresvport,proto=tcp,port=20324,timeo=600,retrans=2,s
ec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1)
[root@ip-10-0-12-6 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 3.7G 0 3.7G 0% /dev/shm
tmpfs 1.5G 8.6M 1.5G 1% /run
efivarfs 128K 3.1K 120K 3% /sys/firmware/efi/efivars
/dev/nvme0n1p4 29G 2.8G 26G 10% //dev/nvme0n1p3 960M 189M 772M 20% /boot/dev/nvme0n1p2 200M 7.4M 193M 4% /boot/efi
tmpfs 748M 0 748M 0% /run/user/0
127.0.0.1:/ 8.0E 0 8.0E 0% /mnt/s3files
[root@ip-10-0-12-6 ~]# findmnt
TARGET SOURCE FSTYPE OPTIONS
/ /dev/nvme0n1p4 xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota
├─/proc proc proc rw,nosuid,nodev,noexec,relatime
│ └─/proc/sys/fs/binfmt_misc systemd-1 autofs rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=21079
├─/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime,seclabel
│ ├─/sys/kernel/security securityfs securityfs rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/cgroup cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate,memory_recursiveprot
│ ├─/sys/fs/pstore pstore pstore rw,nosuid,nodev,noexec,relatime,seclabel
│ ├─/sys/firmware/efi/efivars efivarfs efivarfs rw,nosuid,nodev,noexec,relatime│ ├─/sys/fs/bpf bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700│ ├─/sys/fs/selinux selinuxfs selinuxfs rw,nosuid,noexec,relatime
│ ├─/sys/kernel/debug debugfs debugfs rw,nosuid,nodev,noexec,relatime,seclabel
│ ├─/sys/kernel/tracing tracefs tracefs rw,nosuid,nodev,noexec,relatime,seclabel
│ ├─/sys/fs/fuse/connections fusectl fusectl rw,nosuid,nodev,noexec,relatime
│ └─/sys/kernel/config configfs configfs rw,nosuid,nodev,noexec,relatime
├─/dev devtmpfs devtmpfs rw,nosuid,seclabel,size=4096k,nr_inodes=945079,mode=755,inode64
│ ├─/dev/shm tmpfs tmpfs rw,nosuid,nodev,seclabel,inode64
│ ├─/dev/pts devpts devpts rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000
│ ├─/dev/hugepages hugetlbfs hugetlbfs rw,relatime,seclabel,pagesize=2M
│ └─/dev/mqueue mqueue mqueue rw,nosuid,nodev,noexec,relatime,seclabel
├─/run tmpfs tmpfs rw,nosuid,nodev,seclabel,size=1531032k,nr_inodes=819200,mode=755,inode64
│ ├─/run/credentials/systemd-tmpfiles-setup-dev.service
│ │ none ramfs ro,nosuid,nodev,noexec,relatime,seclabel,mode=700
│ ├─/run/credentials/systemd-sysctl.service
│ │ none ramfs ro,nosuid,nodev,noexec,relatime,seclabel,mode=700
│ ├─/run/credentials/systemd-sysusers.service
│ │ none ramfs ro,nosuid,nodev,noexec,relatime,seclabel,mode=700
│ ├─/run/credentials/systemd-tmpfiles-setup.service
│ │ none ramfs ro,nosuid,nodev,noexec,relatime,seclabel,mode=700
│ └─/run/user/0 tmpfs tmpfs rw,nosuid,nodev,relatime,seclabel,size=765512k,nr_inodes=191378,mode=700,inode64
├─/boot /dev/nvme0n1p3 xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota
│ └─/boot/efi /dev/nvme0n1p2 vfat rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro
├─/mnt/s3files 127.0.0.1:/ nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,noresvport,proto=tcp,port=20324,time
└─/var/lib/nfs/rpc_pipefs sunrpc rpc_pipefs rw,relatime
マウントは以上です。
■動作確認
動作確認では、まずマウント済みの/mnt/s3files配下にファイルを作成し、その後S3バケット側へ反映されるまでの時間を確認します。
以下のコマンドを実行します。
echo "Hello S3 Files" > /mnt/s3files/hello.txt
ls -l --full-time /mnt/s3files/hello.txt
aws s3 ls s3://＜YOUR BUCKET NAME＞/
【実行結果】
[root@ip-10-0-12-6 ~]# aws s3 ls s3://saito-test-s3bucket/
[root@ip-10-0-12-6 ~]#
[root@ip-10-0-12-6 ~]#
[root@ip-10-0-12-6 ~]#
[root@ip-10-0-12-6 ~]# echo "Hello S3 Files" > /mnt/s3files/hello.txt
[root@ip-10-0-12-6 ~]#
[root@ip-10-0-12-6 ~]# ls -l --full-time /mnt/s3files/hello.txt
-rw-r--r--. 1 root root 15 2026-04-25 06:45:34.959000000 +0000 /mnt/s3files/hello.txt
[root@ip-10-0-12-6 ~]#
[root@ip-10-0-12-6 ~]#
[root@ip-10-0-12-6 ~]# aws s3 ls s3://saito-test-s3bucket/
2026-04-25 06:46:39 15 hello.txt
[root@ip-10-0-12-6 ~]#
マウントした[/mnt/s3files/]配下にテストファイルを作成しました。今回の検証では、ファイルシステム上でhello.txtを作成してから、S3 バケット上に同名オブジェクトが確認できるまで約65秒でした。
これは異常ではなく、公式ブログでも、ファイルシステム上の更新は数分以内に S3 バケットへエクスポートされると案内されています。
ファイルシステム上でファイルを更新すると、S3 が自動的にすべての更新を管理し、数分以内に S3 バケット内の新しいオブジェクトまたは既存オブジェクトの新しいバージョンとしてエクスポートします。
●参考: https://aws.amazon.com/jp/blogs/news/launching-s3-files-making-s3-buckets-accessible-as-file-systems/
競合発生を回避するためでしょうか。ファイルシステム上で変更し、S3オブジェクトでも変更が行われ、競合が発生した場合、S3 FilesはS3バケットを真の情報源とするようです。
●参考: https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/s3-files-synchronization.html#s3-files-sync-source-of-truth
逆もやってみます。S3バケットに直接テストファイルをアップロードしてみましょう。
時間を見てみると、今回はファイルシステム側ではラグなく反映されていますね。
[root@ip-10-0-12-6 ~]# aws s3 ls s3://saito-test-s3bucket/
2026-04-25 07:12:29 0 S3toEC2.txt
2026-04-25 06:46:39 15 hello.txt
[root@ip-10-0-12-6 ~]# ls -l --full-time /mnt/s3files/
total 8
-rw-r--r--. 1 root root 15 2026-04-25 06:45:34.959000000 +0000 hello.txt
-rw-r--r--. 1 root root 0 2026-04-25 07:12:29.000000000 +0000 S3toEC2.txt
動作確認は以上です。
■補足: 自動マウント設定
自動マウント設定もしておきましょう。
以下のコマンドを実行します。
sudo vi /etc/fstab
＜YOUR FILE SYSTEM ID＞ /mnt/s3files s3files _netdev,nofail 0 0
mount -a
【実行結果】
[root@ip-10-0-12-6 ~]# cat /etc/fstab
UUID=f57d3f61-a8f6-43ff-8d44-70368420eb5f / xfs defaults 0 0
UUID=1988965c-4bfa-4cdf-9a76-018f655e996a /boot xfs defaults 0 0
UUID=9C60-9938 /boot/efi vfat defaults,uid=0,gid=0,umask=077,shortname=winnt 0 2
fs-04fee52874124eef4 /mnt/s3files s3files _netdev,nofail 0 0
[root@ip-10-0-12-6 ~]# mount -a
/mnt/s3files is already mounted, please run 'mount' command to verify mount: (hint) your fstab has been modified, but systemd still uses the old version; use 'systemctl daemon-reload' to reload.
再起動後、問題なく自動マウントされています。
Last login: Sat Apr 25 07:08:17 UTC 2026 on pts/0
[root@ip-10-0-12-6 ~]#
[root@ip-10-0-12-6 ~]# mount | grep s3
127.0.0.1:/ on /mnt/s3files type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,noresvport,proto=tcp,port=20564,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1,_netdev)
[root@ip-10-0-12-6 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 3.7G 0 3.7G 0% /dev/shm
tmpfs 1.5G 8.6M 1.5G 1% /run
efivarfs 128K 3.3K 120K 3% /sys/firmware/efi/efivars
/dev/nvme0n1p4 29G 2.8G 26G 10% /
/dev/nvme0n1p3 960M 189M 772M 20% /boot
/dev/nvme0n1p2 200M 7.4M 193M 4% /boot/efi
127.0.0.1:/ 8.0E 0 8.0E 0% /mnt/s3files
tmpfs 748M 0 748M 0% /run/user/0
自動マウント設定は以上です。
まとめ
S3 Filesを実際に試してみた結果、S3をファイルシステムとして扱える体験は非常に分かりやすく、EC2からの利用もamazon-efs-utilsを使えば比較的容易に構成できました。
特に、既存のS3バケットを活かしながら、標準的なLinuxのファイル操作でデータを扱える点は、運用スクリプトやファイルベースの処理との親和性が高いと感じます。
一方で、S3 FilesはあくまでS3バケットとの自動同期を行う仕組みであり、即時同期ではありません。
ファイルシステムからS3への反映にはタイムラグがあり、競合時はS3バケットが正となります。そのため、「S3上のデータをファイルシステム的に扱いたい」用途には有力ですが、厳密な即時整合性が必要な用途では挙動を理解したうえで採用判断するのがよさそうです。
参考リンク:AWS公式ドキュメント
↓ほかの協栄情報メンバーのAmazon S3についての記事を公開しています。ぜひ参考にしてみてください。
■Amazon S3のアーカイブされたオブジェクトの復元で勘違いしていた話(齊藤弘樹)
■Amazon S3のオブジェクトのストレージクラスを知りたかっただけなのに、、、(齊藤弘樹)
■KMSキー暗号化バケットでのS3レプリケーション設定の解決方法(齊藤弘樹)