Amazon EKS入門｜Kubernetesをオンプレ経験者向けにわかりやすく解説するクラウド移行ガイド

オンプレでKubernetesを動かしている、あるいは「これからKubernetesを使いたいけどインフラ管理が大変そう」と感じているエンジニアにとって、Amazon EKSはひとつの転換点になり得るサービスです。
コントロールプレーンの管理やバージョンアップを手動でやっていたオンプレの苦労を知っているからこそ、EKSの価値が実感できるはずです。

この記事では、Amazon EKS（Elastic Kubernetes Service）の基本をオンプレ経験者にもわかりやすく解説します。クラスターの構成・ノード管理の選択肢・料金の仕組み・実務でつまずきやすいポイントまで、現場視点で網羅します。

なぜAmazon EKSなのか？オンプレKubernetesとの違い

Kubernetesをオンプレで動かした経験がある人なら、コントロールプレーン（etcd、API Server、Scheduler、Controller Manager）の維持管理がどれほど手間かをご存知でしょう。バージョンアップひとつとっても、ノードのローリングアップデート計画から検証環境での事前テスト、本番への適用タイミング調整まで、かなりの工数がかかります。

Amazon EKSはこのコントロールプレーンをAWSが完全に管理してくれるマネージドKubernetesサービスです。etcdのバックアップやAPIサーバーの冗長化、Kubernetesバージョンの定期的なアップデートはすべてAWS側の責任範囲です。

注意点として、EKSはワーカーノード（実際にPodが動くEC2インスタンスやFargate）は自分で管理する必要があります。「フルマネージド」ではなく「コントロールプレーンのみマネージド」という点は、オンプレ経験者が最初に整理しておきたい部分です。

Amazon EKSの基本構成を理解する

EKSを使い始める前に、主要なコンポーネントを整理しておきます。

1. コントロールプレーン（EKSが管理）

etcd、Kubernetes API Server、Scheduler、Controller ManagerをAWSが管理します。ユーザーはkubectlコマンドでAPIサーバーにアクセスするだけで、コントロールプレーン自体の面倒を見る必要はありません。

コントロールプレーンは東京リージョン（ap-northeast-1）に3つのアベイラビリティゾーンにまたがって自動配置されます。

2. ワーカーノード（ユーザーが選択・管理）

ワーカーノードの管理形態には3種類あります。

・マネージドノードグループ: AWSがEC2インスタンスのプロビジョニング・ライフサイクルを管理する。ノードのローリングアップデートも自動化でき、運用負荷が低い。
・セルフマネージドノード: EC2を自分でプロビジョニングしてEKSクラスターに登録する。最大の柔軟性があるが運用コストも高い。
・AWS Fargate: Podごとにサーバーレスで実行。ノード管理が不要になる一方、DaemonSet非対応やIPアドレス消費が多いなど制約もある。

3. VPC・サブネット設計

EKSクラスターはVPC内に作成します。ワーカーノードはプライベートサブネットに配置し、インターネットからの直接アクセスはさせないのが基本設計です。Podに割り当てるIPアドレスは、Amazon VPC CNI プラグインを使うことでVPCのCIDRレンジから払い出されます。

オンプレのOverlayネットワーク（Flannel、Calicoなど）と異なり、VPC CNIではPodに直接VPCのIPが割り当てられるため、他のAWSリソースとの通信がシンプルになります。ただしIPアドレスの枯渇に注意が必要で、Podの数が多い環境ではサブネットのCIDRを広めに取る計画が重要です。

基本的な使い方（クラスター作成の手順）

1. 事前準備

EKSクラスターを作成するには、以下が必要です。

・AWS CLI（v2推奨）とeksctlのインストール
・kubectl のインストール（バージョンはクラスターのKubernetesバージョンと合わせる）
・IAMユーザーまたはロールに適切な権限付与

# AWS CLI バージョン確認
aws --version

# eksctl インストール（Linux）
curl --silent --location "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin

# kubectl インストール（Linux）
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

2. クラスターの作成

eksctlを使うと、VPC・サブネット・IAMロールなどの依存リソースをまとめて作成できます。

# AWS CLI コマンド（eksctl使用）
# 東京リージョン（ap-northeast-1）にEKSクラスターを作成する例
eksctl create cluster \
  --name my-cluster \
  --region ap-northeast-1 \
  --version 1.29 \
  --nodegroup-name standard-workers \
  --node-type t3.medium \
  --nodes 2 \
  --nodes-min 1 \
  --nodes-max 4 \
  --managed

このコマンドひとつで、以下が自動作成されます。

・EKSクラスター（コントロールプレーン）
・VPCとサブネット（パブリック・プライベート）
・マネージドノードグループ（t3.medium × 2台）
・必要なIAMロール・セキュリティグループ

3. kubeconfigの設定と動作確認

クラスター作成後、kubectlからアクセスできるようにkubeconfigを更新します。

# AWS CLI コマンド
aws eks update-kubeconfig --name my-cluster --region ap-northeast-1

# ノードの一覧確認
kubectl get nodes

# サンプルPodのデプロイ
kubectl create deployment nginx --image=nginx
kubectl get pods

`kubectl get nodes` でワーカーノードが `Ready` 状態になっていれば、クラスターは正常に動作しています。

料金の仕組み（コスト感覚）

EKSの料金は大きく2つに分かれます。

コスト試算の例: 東京リージョンで小規模な本番環境（t3.medium × 3台、クラスター1つ）を常時稼働させた場合の月額概算です。

・EKSクラスター料金: 約$73
・t3.medium × 3台 × 730時間: 約$91
・EBS（20GB × 3台）: 約$5.8
・合計: 約$170（円換算で2.5〜3万円前後、為替次第）

オンプレでマスターノードを複数台 + ワーカーノードを複数台立てる構成と比べると、コントロールプレーンの物理サーバーコスト・電力・運用工数を考えたとき、EKSのほうが総コストで有利になるケースが多いです。

注意点として、EKSはクラスターを作るだけで毎月$73かかります。「試しに動かすだけ」という場合は、使い終わったらクラスターを削除する習慣をつけておきましょう。

応用・実務Tips

【重要】IAMとKubernetes RBACの連携を理解する

EKSの認証はAWS IAMを使って行われますが、Kubernetes内の権限管理（どのPodに何ができるか）はKubernetes RBAC（Role-Based Access Control）で制御します。この2つの権限システムが組み合わさることが、EKS特有のつまずきポイントです。

クラスター作成者（IAMユーザー）は自動的にKubernetesのsystem:mastersグループに追加されますが、別のIAMユーザーがkubectlを使うためには、aws-auth ConfigMapに明示的にマッピングを追加する必要があります。

# AWS CLI コマンド
# aws-authの現在の設定を確認
kubectl describe configmap aws-auth -n kube-system

# eksctlで別のIAMユーザーをクラスター管理者として追加
eksctl create iamidentitymapping \
  --cluster my-cluster \
  --region ap-northeast-1 \
  --arn arn:aws:iam::123456789012:user/another-user \
  --group system:masters \
  --username another-user

Cluster AutoscalerとKarpenterの選択

Podの負荷に応じてワーカーノードを自動増減させるには、Cluster AutoscalerかKarpenterを導入します。

・Cluster Autoscaler: EC2 Auto Scaling Groupと連携する従来の仕組み。設定がシンプルで実績も豊富。
・Karpenter: AWSが開発したより高速なノードプロビジョニングツール。インスタンスタイプを自動選択するため、スポットインスタンス活用によるコスト削減と相性が良い。

新規構築であればKarpenterを、既存のASGベースの運用からの移行であればCluster Autoscalerから始めて徐々にKarpenterへ移行するのが現実的な選択肢です。

コントロールプレーンログの設定

EKSのコントロールプレーンログ（API Server・Audit・Authenticator・Controller Manager・Scheduler）はデフォルトで無効です。CloudWatch Logsへの出力を有効化しておくことで、トラブル時の調査が大幅に楽になります。

# AWS CLI コマンド
# コントロールプレーンログを全種類有効化
aws eks update-cluster-config \
  --region ap-northeast-1 \
  --name my-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

よくあるトラブルと対処法

【トラブル1】kubectl get nodes でノードが表示されない

クラスター作成直後に `kubectl get nodes` を実行しても何も表示されない場合、ワーカーノードがクラスターに参加できていない状態です。

確認ポイントは以下の通りです。

・ノードグループのEC2インスタンスがコントロールプレーンのAPIエンドポイントに到達できているか（セキュリティグループの設定を確認）
・ノードのIAMロールに `AmazonEKSWorkerNodePolicy`、`AmazonEKS_CNI_Policy`、`AmazonEC2ContainerRegistryReadOnly` の3つのポリシーが付与されているか
・aws-auth ConfigMapにノードのIAMロールが正しく登録されているか

【トラブル2】PodがPending状態から動かない

`kubectl get pods` で `Pending` が続く場合は、まずイベントログを確認します。

# AWS CLI コマンド
kubectl describe pod 
# Events: セクションにエラーの詳細が出力される

よくある原因は「ノードのリソース不足（CPUまたはメモリ）」「PersistentVolumeClaimが未作成」「Taint/Tolerationの不一致」の3つです。Eventsセクションの内容を見て原因を特定してください。

【トラブル3】クラスターのバージョンアップを放置してサポート期限切れになる

EKSのKubernetesバージョンには標準サポート期間（14か月）と延長サポート（追加料金あり、$0.60/クラスター時間）があります。サポート期限が切れる前に計画的にバージョンアップを実施する必要があります。

バージョンアップの順序は「コントロールプレーン → マネージドノードグループ」の順番が必須です。逆順にするとノードとAPIサーバーのバージョン不一致が発生します。

【トラブル4】ALB Ingressが動作しない

EKSでApplication Load Balancerを制御するには、AWS Load Balancer Controllerの別途インストールが必要です。コントロールプレーンには自動では含まれないため、Helmチャートでデプロイします。IAMのOIDCプロバイダー設定が抜けているケースが多いので、まずそこを確認してください。

本記事のまとめ

Amazon EKSは、オンプレでKubernetesを運用してきた経験がそのまま活かせるサービスです。コントロールプレーンの運用から解放された分、アプリケーションの設計やノードのコスト最適化に集中できるのが最大のメリットといえます。Linuxサーバーの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。