Amazon EKS が Amazon EC2 インスタンスストアを使用する AWS Outposts 上のローカルクラスターをサポート

はじめに

2026 年 6 月 11 日、AWS は Amazon EKS ローカルクラスターについて、EC2 インスタンスストアから起動する AWS Outposts ラックへの対応を発表しました。Kubernetes コントロールプレーンの管理体制が見直され、クラウド版 EKS との機能パリティが大幅に向上するアップデートです。

Outposts 上で EKS ローカルクラスターを運用している方は、etcd のバックアップ運用や、クラウド版なら当たり前に使えていた認証・アクセス制御の仕組みが使えないことに不便を感じてきたはずです。今回のアップデートは、その差分を直接埋めるものです。

本記事では「何が変わったのか」「既存クラスターはどうなるのか」「実際に使うにはどうすればよいか」「どんな場面で価値を発揮するのか」を中心に解説します。Outposts 上で EKS を運用する、またはこれから検討するインフラ・プラットフォームエンジニアの方はぜひ読んでみてください。

何が変わったのか

Outposts 上で EKS ローカルクラスターを運用したことがある方は、クラウド版 EKS と比べて「できないこと」の多さを感じてきたはずです。

項目	Before	After
コントロールプレーンの管理主体	ユーザー自身が etcd バックアップやロギングエージェントを運用	AWS のサービスオーナードアカウントが管理し、ユーザー側の運用作業は不要に
認証・アクセス制御機能	IRSA、EKS Pod Identity、OIDC 認証、アクセスエントリは利用不可	いずれも利用可能に
ワーカーノード OS の選択肢	Amazon Linux 2023 のみ	Amazon Linux 2023 に加え Bottlerocket にも対応
新バージョンの提供タイミング	ローカルクラスター独自のタイミングで提供	クラウド版 EKS と同じタイミングで提供

従来の課題

EC2 インスタンスストアから起動する Outposts ラック上の EKS ローカルクラスターは、コントロールプレーンこそ Outposts 上で稼働するものの、その運用はクラウド版ほど手厚くサポートされていませんでした。etcd のバックアップやロギングエージェントの設定・運用はユーザー自身の責任範囲であり、コントロールプレーンの可用性を維持するための作業がそのまま運用負荷として積み上がっていました。

加えて、IRSA や EKS Pod Identity といった、クラウド版 EKS では当たり前に使える認証・アクセス制御の仕組みが利用できませんでした。ワーカーノードの OS も Amazon Linux 2023 に限られており、「同じ EKS」と言いながら、Outposts 上では使える機能セットが一段落ちる状態が続いていたのです。

新アーキテクチャによる解決

今回のアップデートでは、コントロールプレーンの管理を AWS のサービスオーナードアカウントに委ねるアーキテクチャへと刷新されました。これにより、etcd バックアップやロギングエージェントの運用はユーザーの手を離れ、IRSA、EKS Pod Identity、OIDC 認証、アクセスエントリ、Bottlerocket ワーカーノードといった、クラウド版 EKS と同等の機能をそのまま利用できるようになります。

ただし、この新アーキテクチャが適用されるのは EC2 インスタンスストアから起動する Outposts ラックに限られ、EBS から起動する Outposts は引き続き従来のアーキテクチャで稼働します。対象となる条件の詳細は、後述の「対象条件・適用範囲」で解説します。

注意： 本稿執筆時点(2026 年 6 月)では、IAM Roles for Service Accounts や EKS Pod Identity の個別機能ページ(EKS ユーザーガイド)に、AWS Outposts 上のローカルクラスターでは利用できない旨の記載が残っており、今回のアップデート対象である新アーキテクチャとの区別がされていません。What's New の発表文とユーザーガイドの記載に食い違いがあるため、実際に利用する際はご自身の環境で動作を確認するか、AWS サポートにお問い合わせください。

アーキテクチャ解説

前章では「何が変わったのか」を機能単位で見てきました。ここからは、なぜこの変更が可能になったのか、アーキテクチャの観点から掘り下げます。導入手順だけ知りたい方は読み飛ばしても構いません。

コントロールプレーンの管理移譲

今回のアップデートの核心は、Kubernetes コントロールプレーンの管理主体が AWS のサービスオーナードアカウントに移ったことです。コントロールプレーンの管理が Amazon EKS によってサービスオーナードアカウント側で行われるようになったことで、etcd のバックアップやロギングエージェントの運用がユーザーの作業から外れます。

ただし、コントロールプレーンの「物理的な実行場所」までクラウド側に移るわけではありません。Kubernetes コントロールプレーン自体は引き続き Outposts ラック上の EC2 インスタンスで稼働しており、データレジデンシー要件は維持されます。変わるのは、そのコントロールプレーンを「誰が」「どのアカウントの権限で」運用・バックアップするかという管理責任の所在です。クラウド版 EKS でコントロールプレーンの内部実装をユーザーが意識しなくて済むのと同じ仕組みが、Outposts 上のローカルクラスターにも適用されました。

EC2 インスタンスストアの静的安定性

今回のアップデートのもう一つの土台が、2024 年 11 月に発表された EC2 インスタンスストアの静的安定性(static stability) です。これは、EC2 インスタンスストアを使う EC2 インスタンスが、リージョンとの接続が一時的に利用できない場合でも、電源障害やリブートから自動的に復旧できるようにする機能です。今回の発表では、この静的安定性の恩恵を EKS ローカルクラスターの利用者にも拡張するとされています。

ここで区別しておきたいのが、「ネットワーク切断への耐性」と「静的安定性」は別物だという点です。ローカルクラスターはそもそもコントロールプレーンとノードを Outpost 上で稼働させる構成であり、クラウドへの一時的なネットワーク切断時にもアプリケーションが稼働を継続できるという特性を最初から持っていました。これに対し静的安定性は、ネットワーク切断に加えて電源障害やリブートが重なった場合でも自動復旧できる、という一段踏み込んだ可用性を意味します。

なお、この静的安定性は EBS から起動する EC2 インスタンスには提供されていません。AWS は、この機能が現時点で Amazon EBS ボリュームを使う EC2 インスタンスには提供されていないと明記しています。理由は公式には説明されていませんが、EC2 インスタンスストアがホストに物理的に直結したローカルストレージであるのに対し、EBS はネットワーク経由のブロックストレージであるため、ネットワーク切断時にも自律的に動作し続けるという静的安定性の前提と相性が良くないことが背景にあると考えられます(※ここは筆者の推測です)。これが、今回のアップデートが EC2 インスタンスストアから起動する Outposts ラックに限定されている技術的な理由と見てよさそうです。

アーキテクチャ図

簡略化すると、次のような構成になります。

図中のコントロールプレーンは AWS のサービスオーナードアカウントが管理しており、Outposts ラックは EC2 インスタンスストアから起動する構成を表しています。ワーカーノードは Bottlerocket または Amazon Linux 2023 で構成されます。コントロールプレーンの管理責任は AWS 側に移りましたが、コントロールプレーン自体は引き続き Outposts ラック上で稼働し続けます。

対象条件・適用範囲

今回のアップデートの対象は明確です。第 1 世代・第 2 世代の AWS Outposts ラックで、EC2 インスタンスストアから起動する EC2 インスタンス上にローカルクラスターを構築する場合に、新アーキテクチャが適用されます。

項目	内容
対象ラック世代	第 1 世代・第 2 世代の AWS Outposts ラック
起動方式の条件	EC2 インスタンスストアから起動する EC2 インスタンス
対象外	EBS から起動する Outposts(従来アーキテクチャを継続使用)
対象リージョン	AWS Outposts ラックをサポートする全ての商用 AWS リージョン

EBS から起動する Outposts は対象外で、引き続き従来のアーキテクチャ(etcd バックアップやロギングエージェントをユーザー側で運用する構成)のままです。新規に Outposts を発注する場合は、起動方式の選択がそのままアーキテクチャの選択に直結する点を押さえておく必要があります。

既存クラスターへの影響

一方で、すでに稼働中の既存ローカルクラスターが新アーキテクチャへ自動移行するのか、再作成が必要なのかについては、AWS の発表文・ユーザーガイドのいずれにも記載がありません。

参考として、土台となる EC2 インスタンスストアの静的安定性(2024 年 11 月発表)はユーザー側の作業なしで全インスタンスに自動適用された前例がありますが、今回のローカルクラスターのアーキテクチャ変更が同じ扱いになるとは限りません。本番クラスターを運用している場合は、移行の要否を AWS サポートまたはアカウントチームに確認してから判断することをおすすめします。

導入の流れ

AWS Outposts は EC2 インスタンスのように数分で起動して試せるサービスではなく、ラックやサーバーとして物理的に発注・設置するハードウェアです。本章は、Outposts 環境を保有している方やこれから導入を検討している方に向けて、設定をコードとして残せる eksctl を使ったクラスター作成の流れを実装ガイドとして示します(AWS コンソールや AWS CLI でも同様の操作が可能です)。

事前準備として、EC2 インスタンスストアから起動する Outposts、最新版の eksctl・kubectl・AWS CLI、そして EKS クラスターの create・describe 権限を持つ IAM プリンシパルが必要です。

クラスター定義ファイルの作成

以下のような ClusterConfig を用意します。outpost.controlPlaneOutpostARN に対象 Outpost の ARN を指定するだけで、コントロールプレーンが Outpost 上に作成されます。

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-local-cluster
  region: ap-northeast-1
version: "1.33"
vpc:
  clusterEndpoints:
    privateAccess: true
  id: "vpc-xxxxxxxxxxxxxxxxx"
  subnets:
    private:
      outpost-subnet-1:
        id: "subnet-xxxxxxxxxxxxxxxxx"
outpost:
  controlPlaneOutpostARN: arn:aws:outposts:ap-northeast-1:111122223333:outpost/op-xxxxxxxxxxxxxxxxx
  controlPlaneInstanceType: m5.large

controlPlaneInstanceType は省略すると Outpost 上で利用可能な最小のインスタンスタイプが自動選択されます。なお、コントロールプレーンは常に 3 インスタンス構成で作成され、台数を変更することはできません。クォーラムを維持するには、3 インスタンスのうち 2 インスタンスが正常である必要があります。

クラスターの作成

eksctl create cluster -f my-local-cluster.yaml

作成には数分かかります。完了すると EKS cluster "my-local-cluster" ... is ready といった行が出力されます。ノードグループを同時に作成する場合の VPC・ローカルゲートウェイの設定については、公式ドキュメントの該当ページもあわせてご確認ください。

アクセスエントリの自動作成

eksctl でクラスターを作成すると、作成者の IAM プリンシパルに対するアクセスエントリが自動的に作成され、Kubernetes リソースへの管理者権限が付与されます。これは「何が変わったのか」で触れたアクセスエントリが、新アーキテクチャのローカルクラスターでも機能していることを示す例です。アクセスエントリの一覧は、コンソールの「アクセス」タブまたは aws eks list-access-entries --cluster-name my-local-cluster で確認できます。

動作確認

aws eks describe-cluster --name my-local-cluster --region ap-northeast-1 --query "cluster.status"

aws eks update-kubeconfig --name my-local-cluster --region ap-northeast-1

kubectl get nodes

status が ACTIVE になっていれば作成は完了です。kubectl get nodes でワーカーノードが認識されていることを確認しましょう。

活用シーン

ここまでの内容を踏まえて、今回のアップデートが具体的にどんな困りごとを解決するのかを整理します。

Outposts のローカルクラスター運用が重い

EC2 インスタンスストアバックの Outposts で EKS ローカルクラスターを運用していて、etcd バックアップやロギングエージェントの管理に運用工数を割いてきた方にとって、今回のアップデートはその作業をそのまま AWS に委ねられるという直接的なメリットがあります。アーキテクチャ解説で見た通り、コントロールプレーンの管理責任そのものが AWS のサービスオーナードアカウントに移るため、バックアップの取得漏れやエージェントの設定不備といった運用リスクからも解放されます。

クラウド版と同じセキュリティモデルを使いたい

クラウド版 EKS では当たり前に使っている IRSA や EKS Pod Identity、アクセスエントリといった仕組みを Outposts 上でも使いたい、というニーズに応えるアップデートでもあります。ただし前述の通り、IRSA と EKS Pod Identity については個別のユーザーガイドページに Outposts 非対応の記載がまだ残っているため、実際に利用する前にご自身の環境で動作を確認することをおすすめします。

データを外部に出せないが、ネットワーク断絶にも耐えたい

データを物理的に拠点内に留める必要がある環境では、Kubernetes コントロールプレーンを含めて全てオンプレミスで完結させられるローカルクラスターの特性自体が重要です。今回のアップデートにより、データレジデンシー要件を満たしながら、電源障害やリブートからの自動復旧という静的安定性の恩恵も新たに受けられるようになりました。リージョンとの接続が不安定になりやすい拠点でも、アプリケーションとクラスター運用の両方を止めずに継続できる点は、こうした環境を運用する上で大きな安心材料になります。

まとめ

AWS Outposts 上の EC2 インスタンスストア環境向けに刷新された、EKS ローカルクラスターの新アーキテクチャについて見てきました。

他の EKS デプロイ形態との違い

Outposts 上で Kubernetes を動かす選択肢は、ローカルクラスターだけではありません。コントロールプレーンとワーカーノードの置き場所で整理すると、立ち位置の違いが分かりやすくなります。

デプロイ形態	コントロールプレーン	ワーカーノード	主な用途
EKS ローカルクラスター(Outposts)	Outposts 上(オンプレミス)	Outposts 上(オンプレミス)	ネットワーク断絶への耐性、厳格なデータレジデンシー
EKS Hybrid Nodes	AWS リージョン(クラウド)	任意のオンプレミス・エッジ機器	既存のオンプレミス資産を EKS に統合
EKS Auto Mode	AWS リージョン(クラウド)	AWS リージョン(クラウド、AWS が管理)	クラウド上での運用負荷削減

EKS Hybrid Nodes はコントロールプレーンをクラウド側に置いたまま、手持ちのオンプレミス機器をワーカーノードとして組み込める点が特徴で、Outposts のような専用ハードウェアの調達は不要です。一方でコントロールプレーンがクラウド側にあるため、ネットワーク断絶時の継続稼働という観点では、コントロールプレーンごとオンプレミスに置けるローカルクラスターとは性質が異なります。EKS Auto Mode はそもそもクラウド上の EKS 向けの選択肢であり、Outposts とは別軸の話です。ネットワーク断絶への耐性と厳格なデータレジデンシーの両方が必要な場合に、ローカルクラスターが選択肢になります。

今回のアップデートは、対象範囲こそ限定的ですが、ローカルクラスター利用者が長年抱えてきたコントロールプレーンの運用負荷と機能差を直接解消するものです。導入にあたっての注意点はここまでで触れた通りなので、実際の環境に当てはめる際はあらためてご確認ください。

参考リンク

• Amazon EKS now supports local clusters on AWS Outposts with Amazon EC2 instance store - 今回のアップデート本体の発表(What's New、2026 年 6 月 11 日)
• Announcing static stability for Amazon EC2 instances backed by EC2 instance store on AWS Outposts - 静的安定性の発表(What's New、2024 年 11 月 22 日)
• Create local Amazon EKS clusters on AWS Outposts for high availability - ローカルクラスターの概要(EKS ユーザーガイド)
• Create a local cluster on an Outpost - クラスター作成手順(EKS ユーザーガイド)
• IAM roles for service accounts - IRSA の仕様(EKS ユーザーガイド)
• Learn how EKS Pod Identity grants pods access to AWS services - EKS Pod Identity の仕様(EKS ユーザーガイド)
• Grant users access to Kubernetes with an external OIDC provider - OIDC 認証の仕様(EKS ユーザーガイド)
• Grant IAM users access to Kubernetes with EKS access entries - アクセスエントリの仕様(EKS ユーザーガイド)
• AWS Outposts Support - eksctl での Outposts 構成方法
• Amazon EKS Hybrid Nodes - EKS Hybrid Nodes の概要
• Announcing Amazon EKS Auto Mode - EKS Auto Mode の発表(What's New、2024 年 12 月 1 日)
• Bottlerocket - ワーカーノード OS の概要