TL

Cloud Service

Amazon EKS Anywhere

オンプレミスや自社データセンターの自前インフラ上に、EKS と一貫した Kubernetes クラスタを構築・運用できるデプロイオプション。Google の Anthos や Azure Arc に近い位置づけ。

中級SAA-C03DOP-C02運用上の優秀性信頼性セキュリティ
最終更新: 2026-06-28公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.AWS のクラウド外(オンプレミスやベアメタル、仮想化基盤)に、EKS と整合した Kubernetes クラスタを自分で構築・運用するためのオプション。
  • 2.EKS Distro と呼ばれる AWS が検証した Kubernetes ディストリビューションを基盤とし、クラスタの作成やアップグレードを宣言的に管理する。
  • 3.コントロールプレーンも含めて自社環境内で動くため接続不要のオフライン運用が可能で、AWS 上のクラスタ管理機能とは任意で接続できる。

Amazon EKS Anywhere は、AWS クラウドの外、つまりオンプレミスや自社データセンターの自前インフラ上に、Amazon EKS と整合した Kubernetes クラスタを構築・運用するためのデプロイオプションです。AWS が検証・配布する Kubernetes ディストリビューションをベースに、クラスタのライフサイクル管理をオンプレミスで完結させつつ、必要に応じてクラウド側の管理機能と連携させられます。

解決する課題

規制やデータ所在地、低レイテンシ、既存設備の活用といった理由で、ワークロードを自社のデータセンターやエッジに置き続けたいケースは少なくありません。一方で、オンプレミスに自前の Kubernetes を構築すると、ディストリビューションの選定、バージョンの追従、コントロールプレーンの冗長化、アップグレードの手順整備といった運用がすべて自社の責任になり、クラウドの EKS とは別物の運用知識が必要になりがちです。

EKS Anywhere は、AWS が検証した Kubernetes ディストリビューション(EKS Distro)と、クラスタを宣言的に作成・アップグレードするためのツール群を提供することで、この負担を軽減します。クラウドの EKS と整合したコンポーネント構成を自社インフラ上で再現できるため、クラウドとオンプレミスで運用モデルを近づけやすく、Kubernetes の標準的なエコシステムもそのまま活用できます。

主要概念と用語

  • EKS Anywhere: 自社インフラ上に Kubernetes クラスタを構築・運用するためのデプロイオプション。クラスタ自体は利用者の環境内で動作する。
  • EKS Distro(EKS-D): AWS が EKS と同じソースからビルドし検証した Kubernetes ディストリビューション。EKS Anywhere の基盤となる。
  • 管理クラスタ: 他のワークロードクラスタの作成やアップグレードといったライフサイクルを司る役割を持つクラスタ。
  • ワークロードクラスタ: 実際のアプリケーションを稼働させるクラスタ。管理クラスタから宣言的に作成・管理される。
  • プロバイダ: クラスタを構築する先のインフラ基盤の種類。仮想化基盤やベアメタルなど、対応するプロバイダの中から選ぶ。
  • クラスタ仕様(クラスタ設定): ノード構成やネットワーク、Kubernetes バージョンなどを記述した宣言的な定義ファイル。これを適用してクラスタを構成する。
  • キュレーテッドパッケージ: AWS が提供・検証する、クラスタに追加できる付帯ソフトウェアのカタログ。
  • 接続(コネクテッド)/ 切断(エアギャップ): クラウドへ接続して運用する形態と、外部接続を持たないオフライン環境で運用する形態の両方に対応する。

仕様・制限・クォータ

EKS Anywhere のクラスタは利用者の自社インフラ上で動作し、コントロールプレーンも含めて利用者の環境内に存在します。対応するインフラ基盤(プロバイダ)はバージョンによって追加・変更されるため、仮想化基盤やベアメタルといった自分の環境に合うプロバイダがサポートされているかは、最新の公式ドキュメントで確認してください。

Kubernetes のバージョンは EKS Distro に追従する形で提供され、一定期間ごとに新しいバージョンがサポートされます。クラスタあたりのノード数のような上限は、実質的には利用者が用意した物理・仮想リソースの量に依存します。クラウドの EKS のようなサービスクォータとは性質が異なり、自社インフラのキャパシティ計画が制約の中心になる点を意識してください。具体的な対応バージョンやサポート期間は変動するため、断定せず最新情報を参照する運用が安全です。

自社インフラの責任範囲が広い

EKS Anywhere ではコントロールプレーンも自社環境で動くため、ハードウェアの可用性、ネットワーク、ストレージ、バックアップといった基盤の責任は利用者側にあります。クラウドの EKS よりも運用の守備範囲が広くなる点に注意してください。

内部の仕組み

EKS Anywhere は、Kubernetes のクラスタライフサイクルを宣言的に管理する仕組みを使ってクラスタを構築します。まず初期構築用の一時的な環境を起点に管理クラスタを作成し、その管理クラスタが配下のワークロードクラスタを宣言に基づいて生成・調整します。クラスタの構成はノード数や Kubernetes バージョンなどを記述した設定ファイルとして表現され、これを適用するとコントローラが望ましい状態へ収束させます。

基盤となる Kubernetes コンポーネントは EKS Distro として AWS が検証したものが使われ、コンテナランタイムやネットワーク、付帯コンポーネントの組み合わせも検証済みの構成として提供されます。アップグレードも宣言的に行われ、設定ファイルの Kubernetes バージョンを引き上げて適用すると、コントロールプレーンとワーカーノードが順次入れ替わる流れで更新されます。クラウドへの接続は必須ではなく、外部接続を持たないエアギャップ環境でも、必要なイメージやアーティファクトを事前に取り込んでおけば運用できます。

設計パターン / ベストプラクティス

  • 管理クラスタとワークロードクラスタを分離し、ライフサイクル管理の責務とアプリ実行の責務を切り分ける。多数のクラスタを扱う場合に運用が整理しやすくなる。
  • コントロールプレーンとワーカーのノードを複数の物理ホストに分散配置し、単一ホスト障害でクラスタ全体が止まらないようにする。冗長化は自社インフラ側で確保する必要がある。
  • クラスタ設定ファイルをバージョン管理し、GitOps のように宣言的な構成をソース管理下に置いて、変更の追跡とレビューを行う。
  • バックアップとリストアの手順、特にコントロールプレーンの状態を保持するデータストアの保護を明確に設計しておく。クラウドのようにマネージドではない点を補う。
  • クラウドの EKS とハイブリッドに運用する場合は、Kubernetes バージョンやアドオン構成をできるだけ揃え、運用手順を共通化する。
クラスタ設定を Git で管理

クラスタの構成を宣言的なファイルとして Git に置くと、変更履歴の追跡やレビュー、再現が容易になります。オンプレミスでも GitOps の運用モデルを取り入れると属人化を避けられます。

運用・監視

可観測性は、クラスタ内にモニタリングやログ収集のスタックを導入して実現するのが基本です。EKS Anywhere ではキュレーテッドパッケージとして検証済みの付帯ソフトウェアが提供されるため、これらを利用してメトリクスやログの収集基盤を整えられます。クラウドへ接続できる環境であれば、AWS 側のモニタリングやログのサービスへ送る構成も選べます。

アップグレード運用では、まず検証環境のクラスタで新しい Kubernetes バージョンを試し、問題がなければ本番のクラスタへ宣言的に適用していく流れが安全です。ノードの入れ替えではポッドの退避と再スケジュールが発生するため、レプリカ数や PodDisruptionBudget を適切に設定して可用性を保ちます。エアギャップ環境では、新バージョンに必要なイメージやアーティファクトを事前にローカルレジストリへ取り込んでおくことが運用上の重要なステップになります。

コスト

EKS Anywhere そのものは、自社インフラ上で動かす分には基盤のソフトウェアとして利用できますが、本番運用に向けたサポートを受けるためのサブスクリプション(有償サポート)が別途用意されています。最大のコスト要素は、クラスタを動かす自社のハードウェア、データセンター設備、電力、運用人件費といったオンプレミス側のコストです。クラウドの EKS のようなコントロールプレーンの時間課金という形ではなく、自前の設備投資と運用コストが中心になります。

クラウド側の管理機能やキュレーテッドパッケージ、AWS の関連サービスと連携させる場合は、それぞれの利用に応じた料金が別途かかります。サポートの料金体系や対象範囲は変動し得るため、見積もりは公式の料金ページとサポートの案内で確認してください。

セキュリティ

EKS Anywhere ではクラスタ全体が自社環境内で動くため、物理セキュリティ、ネットワーク分離、ノード OS の堅牢化、コントロールプレーンの保護まで、責任の多くが利用者側にあります。クラウドのマネージドサービスのように基盤を AWS が保護してくれる範囲は限定的であり、自社のセキュリティ運用が前提になります。

認可は Kubernetes の RBAC で制御し、クラスタ管理者相当の権限は厳しく絞ります。コンテナイメージは信頼できるレジストリから取得し、脆弱性スキャンを通すべきです。エアギャップ環境では、外部から取り込むアーティファクトの完全性を検証し、ローカルレジストリを安全に管理することが重要になります。シークレットの保護やノード・付帯コンポーネントを最新に保つことも、オンプレミスならではの運用として確実に行う必要があります。

基盤の保護は自社責任

コントロールプレーンを含むすべてが自社環境で動くため、ハードウェアやネットワークの侵害がクラスタ全体の危殆化に直結します。物理・ネットワーク・OS の各層で多層防御を確実に実装してください。

関連サービス・比較

同じく Kubernetes を扱う Amazon EKS(クラウド版)とよく対比されます。EKS はコントロールプレーンを AWS がマネージドに運用するのに対し、EKS Anywhere はコントロールプレーンも含めて自社インフラ上で利用者が運用します。

観点Amazon EKSAmazon EKS Anywhere
実行場所AWS クラウド上オンプレミスや自社インフラ上
コントロールプレーン運用AWS がマネージドに運用利用者が自社環境で運用
可用性の確保AWS が複数ゾーンで冗長化利用者が自社インフラで冗長化
オフライン運用クラウド接続が前提エアギャップでの運用に対応

ハンズオン / CLI例

EKS Anywhere のクラスタ構築は専用の eksctl anywhere コマンドで行います。以下は設定ファイルのひな形を生成し、それを適用してクラスタを作成する典型的な流れの例です(プロバイダ名やクラスタ名は環境に合わせて置き換えてください)。

# クラスタ設定ファイルのひな形を生成する
eksctl anywhere generate clusterconfig my-cluster \
  --provider vsphere > my-cluster.yaml

# 生成した設定ファイルを編集した後、クラスタを作成する
eksctl anywhere create cluster -f my-cluster.yaml

# 作成したクラスタへ kubectl で接続できるか確認する
export KUBECONFIG=./my-cluster/my-cluster-eks-a-cluster.kubeconfig
kubectl get nodes

AWS Service

Amazon EKS Anywhereを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

コンテナ

比較で見る軸

クラウド: AWS / カテゴリ: コンテナ / 難易度: intermediate

導入後に効く点

EKS Distro と呼ばれる AWS が検証した Kubernetes ディストリビューションを基盤とし、クラスタの作成やアップグレードを宣言的に管理する。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
AWS
カテゴリ
コンテナ
難易度
intermediate
関連資格
SAA-C03 / DOP-C02
設計柱
operational / reliability / security

判断チェックリスト

  • 自社の用途が「コンテナ / operational」に近いか確認する。
  • 強みである「AWS のクラウド外(オンプレミスやベアメタル、仮想化基盤)に、EKS と整合した Kubernetes クラスタを自分で構築・運用するためのオプション。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

コンテナoperationalreliabilitysecuritySAA-C03