本記事は 2026 年 4 月 7 日 に公開された「 Launching S3 Files, making S3 buckets accessible as file systems 」を翻訳したものです。 Amazon S3 Files の提供開始をお知らせします。S3 Files は、あらゆる AWS コンピューティングリソースと Amazon Simple Storage Service (Amazon S3) をつなぐ新しいファイルシステムです。 10 年以上前、私がAWS トレーナーだった頃、オブジェクトストレージとファイルシステムの基本的な違いを説明するのに多くの時間を費やしました。よく使ったたとえ話は、S3 オブジェクトを図書館の本に見立てるものでした (1 ページだけ編集することはできず、本ごと差し替える必要がある)。一方、コンピュータ上のファイルはページ単位で変更できます。図を描き、比喩を考え、ワークロードごとに異なるストレージタイプが必要な理由をお客様に説明してきました。そして今日、オブジェクトストレージとファイルシステムの境界がより柔軟になります。 S3 Files により、Amazon S3 はクラウドオブジェクトストアとして唯一、高性能なファイルシステムアクセスを提供します。バケットをファイルシステムとしてアクセスでき、ファイルシステム上のデータ変更は自動的に S3 バケットに反映されます。同期もきめ細かく制御できます。S3 Files は複数のコンピューティングリソースにアタッチでき、データを複製せずにクラスター間で共有できます。 これまでは、Amazon S3 のコスト効率、耐久性、S3 からネイティブにデータを利用できるサービス群と、ファイルシステムの対話的な操作性のどちらかを選ぶ必要がありました。S3 Files でこのトレードオフは不要になります。S3 が組織のデータ基盤となり、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、関数など、あらゆる AWS コンピューティングリソースから直接アクセスできます。本番アプリケーションの実行、ML モデルのトレーニング、エージェント型 AI システムの構築など、用途を問いません。 汎用バケットを、EC2 インスタンス、 Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS) 上のコンテナ、 AWS Lambda 関数からネイティブファイルシステムとしてアクセスできます。ファイルシステムは S3 オブジェクトをファイルやディレクトリとして表示し、 Network File System (NFS) v4.1 以降のすべての操作 (ファイルの作成、読み取り、更新、削除) をサポートします。 ファイルシステムで特定のファイルやディレクトリを操作すると、関連するメタデータとコンテンツが高性能ストレージに配置されます。デフォルトでは、低レイテンシーアクセスの恩恵を受けるファイルは高性能ストレージに保存され、そこから提供されます。大規模なシーケンシャル読み取りが必要なファイルなど、高性能ストレージに保存されていないファイルについては、S3 Files がスループットを最大化するため Amazon S3 から直接提供します。バイト範囲読み取りでは、要求されたバイトのみが転送されるため、データ移動とコストを最小限に抑えられます。 データアクセスパターンを予測する的確なプリフェッチにも対応しています。高性能ストレージに保存する内容もきめ細かく制御でき、ファイルデータ全体を読み込むか、メタデータのみを読み込むかを選択して、アクセスパターンに応じた最適化が可能です。 仕組みとしては、S3 Files は Amazon Elastic File System (Amazon EFS) を基盤とし、アクティブなデータに対して約 1 ミリ秒のレイテンシーを実現します。NFS の close-to-open 整合性で複数のコンピューティングリソースからの同時アクセスをサポートするため、データを変更する対話的な共有ワークロードに最適です。ファイルベースのツールで連携する AI エージェントや、データセットを処理する ML トレーニングパイプラインなどが該当します。 使い方を紹介します 初めての Amazon S3 ファイルシステムの作成、マウント、EC2 インスタンスからの利用は簡単です。 EC2 インスタンスと汎用バケットを用意しています。以下のデモでは、S3 ファイルシステムを設定し、通常のファイルシステムコマンドで EC2 インスタンスからバケットにアクセスします。 デモでは AWS マネジメントコンソール を使用します。 AWS Command Line Interface (AWS CLI) や Infrastructure as Code (IaC) も利用できます。 デモのアーキテクチャ図は以下のとおりです。 ステップ 1: S3 ファイルシステムを作成します。 コンソールの Amazon S3 セクションで File systems を選択し、 Create file system を選択します。 ファイルシステムとして公開するバケット名を入力し、 Create file system を選択します。 ステップ 2: マウントターゲットを確認します。 マウントターゲットは、仮想プライベートクラウド (VPC) 内に配置されるネットワークエンドポイントです。EC2 インスタンスから S3 ファイルシステムにアクセスするために使用します。 コンソールではマウントターゲットが自動的に作成されます。 Mount targets タブで Mount target ID を確認します。 CLI を使用する場合は、ファイルシステムとマウントターゲットの作成に 2 つのコマンドが必要です。まず create-file-system で S3 ファイルシステムを作成し、次に create-mount target でマウントターゲットを作成します。 ステップ 3: EC2 インスタンスにファイルシステムをマウントします。 EC2 インスタンスに接続し、以下のコマンドを実行します。 sudo mkdir /home/ec2-user/s3files sudo mount -t s3files fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files ~/s3files にマウントされたファイルシステムで、標準的なファイル操作を使って S3 データを直接操作できます。 ファイルシステム上でファイルを更新すると、S3 が自動的にすべての更新を管理し、数分以内に S3 バケット内の新しいオブジェクトまたは既存オブジェクトの新しいバージョンとしてエクスポートします。 S3 バケット上のオブジェクトに加えた変更は、数秒以内にファイルシステムに反映されますが、1 分以上かかる場合もあります。 # Create a file on the EC2 file system echo "Hello S3 Files" > s3files/hello.txt # and verify it's here ls -al s3files/hello.txt -rw-r--r--. 1 ec2-user ec2-user 15 Oct 22 13:03 s3files/hello.txt # See? the file is also on S3 aws s3 ls s3://s3files-aws-news-blog/hello.txt 2025-10-22 13:04:04 15 hello.txt # And the content is identical! aws s3 cp s3://s3files-aws-news-blog/hello.txt . && cat hello.txt Hello S3 Files 知っておくべきこと 技術的な詳細をいくつか紹介します。 S3 Files は AWS Identity and Access Management (IAM) と統合されており、アクセス制御と暗号化に対応しています。 ID ベースのポリシーとリソースポリシーで、ファイルシステムレベルとオブジェクトレベルの両方で権限を管理 できます。 データは TLS 1.3 による転送中の暗号化と、Amazon S3 マネージドキー (SSE-S3) または AWS Key Management Service (AWS KMS) のカスタマーマネージドキーによる保管時の暗号化で常に保護されます。 S3 Files は POSIX パーミッションを使用し、S3 バケットにオブジェクトメタデータとして保存されたファイルパーミッションに対してユーザー ID (UID) とグループ ID (GID) を照合します。 S3 Files の監視には、ドライブのパフォーマンスと更新に関する Amazon CloudWatch メトリクスと、管理イベントのログ記録に AWS CloudTrail を使用できます。 EC2 インスタンスに最新バージョンの EFS ドライバー ( amazon-efs-utils パッケージ ) がインストールされていることを確認してください。AWS が提供する Amazon Machine Image (AMI) にはプリインストールされています。執筆時点では、最新バージョンに更新できます。 本記事では EC2 インスタンスからの S3 Files の使用方法を紹介しました。ECS や EKS のコンテナ ( AWS Fargate の有無を問わず)、Lambda 関数からも S3 バケットをファイルシステムとしてマウントできます。 お客様からよく聞かれるのが、ワークロードに適したファイルサービスの選び方です。AWS のサービスは一見重複しているように見え、アーキテクチャレビュー会議でクラウドアーキテクトを悩ませることもあります。ファイルサービスの使い分けを整理しましょう。 S3 Files は、Amazon S3 に保存されたデータに高性能なファイルシステムインターフェースで対話的に共有アクセスする必要がある場合に最適です。本番アプリケーション、Python ライブラリや CLI ツールを使用する AI エージェント、ML トレーニングパイプラインなど、複数のコンピューティングリソースがデータを読み書きし、共同で変更するワークロードに適しています。データを複製せずにコンピューティングクラスター間で共有アクセスでき、サブミリ秒のレイテンシーと S3 バケットとの自動同期を実現します。 オンプレミスの NAS 環境から移行するワークロードには、 Amazon FSx が使い慣れた機能と互換性を提供します。Amazon FSx は、 Amazon FSx for Lustre によるハイパフォーマンスコンピューティング (HPC) や GPU クラスターストレージにも最適です。 Amazon FSx for NetApp ONTAP 、 Amazon FSx for OpenZFS 、 Amazon FSx for Windows File Server など、特定のファイルシステム機能が必要なアプリケーションに特に有効です。 料金と利用可能リージョン S3 Files は、すべての商用 AWS リージョン で利用できます。 S3 ファイルシステムに保存されたデータの容量、小さなファイルの読み取りとすべての書き込み操作、ファイルシステムと S3 バケット間のデータ同期時の S3 リクエストに対して課金されます。 Amazon S3 の料金ページに詳細 があります。 お客様との対話を通じて、S3 Files はデータサイロ、同期の複雑さ、オブジェクトとファイル間の手動データ移動を排除し、クラウドアーキテクチャの簡素化に役立つと考えています。ファイルシステムで動作する本番ツールの実行、ファイルベースの Python ライブラリやシェルスクリプトに依存するエージェント型 AI システムの構築、ML トレーニング用データセットの準備など、S3 Files を使えば Amazon S3 の耐久性とコストメリットを犠牲にすることなく、対話的な共有ワークロードから S3 データに直接アクセスできます。Amazon S3 を組織のデータ保管場所として使用でき、あらゆる AWS コンピューティングインスタンス、コンテナ、関数からデータに直接アクセスできます。 詳細と使い方については、 S3 Files のドキュメント をご覧ください。 S3 Files をどのように活用されるか、ぜひお聞かせください。フィードバックをお待ちしています。 — seb 著者について Sébastien Stormacq 80 年代半ばに Commodore 64 に触れて以来コードを書き続けている。情熱、好奇心、創造性を武器に、AWS クラウドの価値を引き出すビルダーを支援している。ソフトウェアアーキテクチャ、開発者ツール、モバイルコンピューティングに関心がある。Bluesky、X、Mastodon などで @sebsto をフォローできる。 この記事はVisual Compute Specialist Solutions Architect の森が翻訳を担当しました。

2026 年 4 月 1 日、 Amazon Elastic Container Service (Amazon ECS) マネージドインスタンス のマネージドデーモンサポートを発表いたしました。この新機能により、 2025 年 9 月に導入 したマネージドインスタンスのエクスペリエンスが拡張されます。プラットフォームエンジニアは、アプリケーション開発チームとの調整を必要とせずに、モニタリング、ログ記録、トレースツールなどのソフトウェアエージェントを独立して制御できるようになります。また、すべてのインスタンスで必要なデーモンを常に実行し、包括的なホストレベルのモニタリングを実現できるため、信頼性も向上します。 コンテナ化されたワークロードを大規模に実行する場合、プラットフォームエンジニアは、インフラストラクチャのスケーリングやパッチ適用から、アプリケーションの確実な実行の維持、それらのアプリケーションをサポートする運用エージェントの保守まで、幅広い責任を管理します。これまで、こうした懸念事項の多くは密接に結びついていました。モニタリングエージェントを更新するということは、アプリケーションチームとの調整、タスク定義の変更、アプリケーション全体の再デプロイを意味します。数百、数千のサービスを管理している場合、これは運用上の大きな負担となります。 デーモンの分離型ライフサイクル管理 Amazon ECS では、プラットフォームチームが運用ツールを一元管理できるようにする、専用のマネージドデーモンコンストラクトが導入されました。このように懸念事項を分離することで、プラットフォームエンジニアは、アプリケーションチームによるサービスの再デプロイを必要とせずに、すべてのインスタンスで必要なツールを一貫して使用できるようにしつつ、モニタリング、ログ記録、トレースの各エージェントをインフラストラクチャに個別にデプロイして更新できます。デーモンはアプリケーションタスクの前に起動し、最後にドレインすることが保証されているため、アプリケーションで必要なときにいつでもログ記録、トレース、モニタリングを利用できます。 プラットフォームエンジニアは、マネージドデーモンを複数のキャパシティプロバイダーにデプロイしたり、特定のキャパシティプロバイダーをターゲットにしたりできるため、インフラストラクチャ全体でエージェントを柔軟に展開できます。リソース管理も一元化されており、各インスタンスが複数のアプリケーションタスクで共有されるデーモンコピーを 1 つだけ実行するため、チームはリソース使用率を最適化しながら、AMI を再構築したりタスク定義を更新したりすることなくデーモン CPU とメモリのパラメータをアプリケーション設定とは別に定義できます。 試してみましょう ECS マネージドデーモンを試すために、最初のマネージドデーモンとして Amazon CloudWatch エージェント を使用して開始することにしました。私は以前、 ドキュメント を使用してマネージドインスタンスのキャパシティプロバイダーで Amazon ECS クラスターをセットアップしていました。 Amazon Elastic Container Service コンソールで、ナビゲーションペインに新しい [デーモンタスク定義] オプションがあることに気付きました。このオプションで、マネージドデーモンを定義できます。 [新しいデーモンタスク定義を作成] を選択して開始します。この例では、CloudWatch エージェントに 1 つの vCPU と 0.5 GB のメモリを設定しました。 [デーモンタスク定義ファミリー] フィールドに、後で識別できる名前を入力しました。 [タスク実行ロール] では、ドロップダウンから [ECSTaskExecutionRole] を選択しました。 [コンテナ] セクションで、コンテナにわかりやすい名前を付け、イメージ URI に public.ecr.aws/cloudwatch-agent/cloudwatch-agent/cloudwatch-agent:latest といくつかの詳細を貼り付けました。 すべてを確認したあと、 [作成] を選択しました。 デーモンタスク定義が作成されたら、 クラスター ページに移動し、以前作成したクラスターを選択すると、新しい [デーモン] タブが見つかりました。 ここで [デーモンを作成] ボタンをクリックし、フォームに記入してデーモンを設定するだけです。 [デーモン設定] で、新しく作成したデーモンタスク定義ファミリーを選択してから、デーモンに名前を割り当てました。 [環境設定] では、前に設定した ECS マネージドインスタンスのキャパシティプロバイダーを選択しました。設定を確認したあと、 [作成] を選択しました。 これで、ECS は、選択したキャパシティプロバイダーのプロビジョニングされたすべての ECS マネージドインスタンスでデーモンタスクが最初に起動することを自動的に確認します。実際の動作を確認するために、サンプルの nginx ウェブサービスをテストワークロードとしてデプロイしました。ワークロードがデプロイされると、コンソールで ECS マネージドデーモンが CloudWatch エージェントデーモンをアプリケーションとともに自動的にデプロイしたことを確認できました。手動による操作は必要ありません。 後でデーモンを更新すると、ECS は更新されたデーモンを使用して新しいインスタンスをプロビジョニングして、まずデーモンを起動し、次にアプリケーションタスクを新しいインスタンスに移行してから古いインスタンスを終了することで、ローリングデプロイを自動的に処理しました。この「停止前に開始する」アプローチにより、デーモンを継続的にカバーできます。ログ記録、モニタリング、トレースの各エージェントは、データ収集においてギャップがなく、更新中ずっと動作し続けます。設定したドレイン率によってこの置き換えのペースが制御され、アプリケーションのダウンタイムなしでアドオンの更新を完全に制御できるようになりました。 仕組み マネージドデーモンエクスペリエンスでは、独自のパラメータと検証スキームを備えた、タスク定義とは別の新しいデーモンタスク定義が導入されています。新しい daemon_bridge ネットワークモードにより、デーモンはアプリケーションネットワーク設定から切り離されたまま、アプリケーションタスクと通信できます。 マネージドデーモンは、運用ツールに不可欠である高度なホストレベルのアクセス機能をサポートします。プラットフォームエンジニアは、デーモンタスクを特権コンテナとして設定したり、Linux 機能を追加したり、基盤となるホストファイルシステムからパスをマウントしたりできます。これらの機能は、ホストレベルのメトリクス、プロセス、システムコールを詳細に可視化する必要があるモニタリングおよびセキュリティエージェントにとって特に役立ちます。 デーモンがデプロイされると、ECS はアプリケーションタスクを配置する前に、コンテナインスタンスごとにデーモンプロセスを 1 つだけ起動します。これにより、アプリケーションがトラフィックの受信を開始する前に、運用ツールの準備ができていることが保証されます。ECS は自動ロールバックを使用したローリングデプロイもサポートしているため、安心してエージェントを更新できます。 今すぐご利用いただけます Amazon ECS マネージドインスタンスのマネージドデーモンサポートは、現在 すべての AWS リージョン でご利用いただけます。開始するには、Amazon ECS コンソールにアクセスするか、 Amazon ECS ドキュメント を確認してください。また、 このウェブサイト にアクセスして、新しいマネージドデーモンのアプリケーションプログラミングインターフェイス (API) を確認することもできます。 マネージデーモンを使用するための追加コストはありません。お支払いいただくのは、デーモンタスクによって消費された標準コンピューティングリソースに対してのみです。 原文は こちら です。

2024年度にAWS認定資格をすべて取得し、 2025 ALL AWS Certifications Engineers として表彰していただきました！ 振り返ってみると、当初の予定を大幅に前倒しした 資格取得RTA のような怒涛のスケジュールでした。 今回は、なぜ実務経験が断片的だった私が全冠を目指したのか、そしてどうやって駆け抜けたのか、その記録を公開します。 挑戦前のスペック：AWS経験は「点」でした 「全冠」と聞くと、さぞかしAWSを使いこなしている人を想像されるかもしれませんが、当時の私の状況はこんな感じでした。 仕事：クラウドネイティブな開発基盤構築チームで、いわゆる「何でも屋」をしているエンジニア 主戦場： Azure、GoogleCloud（仕事の比率はこちらが高め） AWS実務経験： 特定サービスのアプリ部品を1つ作成。あとは、炎上プロジェクトでの技術支援（火消し）にスポット参戦 得意なこと： プログラミング、DevOps関連技術、アプリ開発周り 保有資格： 高度情報（システムアーキテクト、データベーススペシャリスト）、Java資格など AWSに関しては「広く浅く」どころか、特定のスポットだけ激しく触ったことがあるという、非常に偏った知識状態からのスタートでした。 取得動機：あふれるAWSへの想いを形にしたかった 理由はシンプルです。AWSが好きだから。 しかし、世の中はAWSエンジニア戦国時代。人気すぎて競争率が高く、インフラ専任ではない私には、なかなかAWSメインの案件が回ってきませんでした。 「好きなのに、触れない……。この熱意をどうにかして証明したい！」 そう思い立った結果が、「資格で可視化すること」でした。当初は「年2個くらいずつ、ゆっくり取ろうかな」と考えていたのですが、いざ始めると火がついてしまいました。 得意なDevOps分野が意外とスルスル取れたことで弾みがつき、1資格2週間（1・2月は月3個ペース）という怒涛の短期集中モードに突入してしまったのです。 （※よい子の皆さんは、無理のないスケジュールを立ててくださいね！） 攻略ルート：得意を固めてから「専門領域」に挑む 一般的にはSAA（Associate）からSAP（Professional）へ進むのが王道ですが、 私は知識のオーバーラップを意識して、得意な領域からグルーピングして攻略しました。 実際に進んだ順番 1. 基礎・開発系（足場固め） CLF → SAA → DVA → DOP → SOA まずは得意なDevOps周りを固め、勢いをつけました。 2. トレンド・データ系（攻めの姿勢） DEA → AIF → MLS → MLA 新設されたデータ・AI系資格を一気に攻略。 3. インフラ・専門系（最難関の壁） ANS → SCS → SAP 最難関のネットワーク（ANS）をあえて後半に。 最後は集大成としてラスボス的存在のSAPで締めました。 実際に駆け抜けたロードマップ コード 正式名称 レベル 初回取得日 コメント CLF-C01 AWS Certified Cloud Practitioner Foundational 2023-01-28 AWSはじめ SAA-C03 AWS Certified Solutions Architect Associate 2024-02-12 穏やかに取得 DVA-C02 AWS Certified Developer Associate 2024-06-26 ウォーミングアップ期間 DOP-C02 AWS Certified DevOps Engineer Professional 2024-12-20 覚醒 SOA-C02 AWS Certified SysOps Administrator Associate 2025-01-10 ここからRTAスタート DEA-C01 AWS Certified Data Engineer Associate 2025-01-25 　↓ AIF-C01 AWS Certified AI Practitioner Foundational 2025-01-29 　↓ MLS-C01 AWS Certified Machine Learning Specialty 2025-02-06 　↓ MLA-C01 AWS Certified Machine Learning Engineer Associate 2025-02-13 　↓ ANS-C01 AWS Certified Advanced Networking  Specialty 2025-02-26 　↓ SCS-C02 AWS Certified Security Specialty 2025-03-05 　↓ SAP-C02 AWS Certified Solutions Architect Professional 2025-03-17 ゴール！！ 勉強方法：三種の神器 短期集中を成功させるために、効率を最優先しました。 1. AWS Black Belt (動画/資料) 知らないサービスは、まずこれ。公式の「正解」を脳に叩き込みます。 2. Udemy (動画教材) 特に未知の領域（AI、ネットワーク）は、ハンズオン付きの教材で「触った感触」を擬似体験しました。 3. オンライン問題集 「試験の勘」を養うために、仕上げとして数周。間違えた部分は公式ドキュメントに戻って徹底的に潰しました。 挑戦中に感じた「光と影」 苦しかったこと：最難関ネットワークの壁 一番しんどかったのは、やはりANS（ネットワーク）です。 開発をしていると不具合の原因として立ちはだかることもあるネットワークですが、実務で使ったことのない細かいサービス仕様には本当に苦戦しました。 また、MLA（機械学習エンジニア）も普段の業務と距離があったため、根気強く動画と問題集を往復する日々でした。 楽しかったこと：アーキテクチャの万華鏡 逆に一番楽しかったのは、試験を通じて膨大なアーキテクチャ事例に触れられたことです。 普段は特定の基幹システムを見ることが多いのですが、多種多様な構成を学ぶのは新鮮で、「AWSならこんな解決策があるのか！」と、ただただワクワクしました。余計にAWSが好きになりました。 おまけ 最後にちょっとだけ自慢させてください！ 12回もの試験を乗り越えたご褒美に、AWS Summit2025で取得した資格のシールをいただいてきました！（デザイン好きすぎて額縁に入れました。） 某RPGが大好きでたくさんのシリーズをやっているのですが、まさかAWSの資格シールがRPG風なんて…！！ドット絵のキャラクターが並んでいるのを見るだけで、テンションが上がります。こうして物理的な形になると、頑張ってよかったな～と改めて実感します。  総評：全冠を取得して変わったこと 2月から3月のラストスパートは、正直くじけそうになる瞬間もありました。 ですが、1つ合格するたびに「自分でもできるんだ」という自信が積み重なり、最後は 早く次の試験を受けたい！ というランナーズハイに近い状態になっていました（笑）。 全冠を達成して得られたのは、単なる称号だけではありません。 AWSという巨大なパズルの全体像 が見えるようになったことで、アーキテクトとして自信を持って提案ができるようになりました。   もし、「実務経験が少ないから」と迷っている方がいたら、ぜひ一歩踏み出してみてください。資格取得の過程で得られる知識は、必ず現場でのあなたの武器になります。 最後まで読んでいただきありがとうございました！ 2025 ALL AWS Certifications Engineers の名に恥じぬよう、これからも精進します！ P.S.勢いそのままに、実は「AWS Certified Generative AI Developer – Professional」のベータ版も突撃し、Early Adopterバッジをもらってきました。気力が湧いたら、そちらの記事も書く…かもしれません。