はじめに
2026 年 4 月 30 日、AWS は Amazon EKS において AWS CloudShell を通じたワンクリッククラスターアクセスのサポートを発表しました。EKS コンソールから直接 CloudShell を起動し、ローカル環境の設定なしにクラスターを操作できるようになります。
EKS クラスターを操作するとき、最初にやることを思い出してみてください。kubectl のインストール、AWS CLI の設定、そして aws eks update-kubeconfig の実行。初めて触る環境では必ずこの儀式が発生します。今回のアップデートはこの「始めるまでの手間」に直接応えるものです。
本記事では何が変わったのかを整理したうえで、実際にどんな場面で役立つのか、また使う上で知っておきたい注意点についても解説します。EKS クラスターを日常的に操作しているエンジニアはもちろん、チームのオンボーディングや運用効率を改善したいと考えている方もぜひ読んでみてください。
何が変わったのか
EKS クラスターを操作するには、これまでローカル環境への各種ツールのインストールと設定が必須でした。今回のアップデートにより、その前提が大きく変わります。
| 項目 | Before | After |
|---|---|---|
| kubectl の用意 | ローカルへのインストールが必要 | 不要（CloudShell に同梱） |
| kubeconfig の設定 |
aws eks update-kubeconfig の実行が必要 |
不要（自動設定） |
| プライベートエンドポイントへのアクセス | VPN やバスティオンホストの準備が必要な場合あり | CloudShell の VPC 環境経由で接続可能 |
| 追加コスト | — | なし |
従来の課題
EKS クラスターに初めてアクセスするまでには、複数のステップを踏む必要がありました。kubectl と AWS CLI のインストール、IAM 権限の確認、そして aws eks update-kubeconfig による kubeconfig の生成。これらはいずれも一度きりの作業ではなく、新しい環境・新しいメンバー・新しいクラスターのたびに繰り返されます。
複数のクラスター（開発・ステージング・本番）を管理している場合は、コンテキストの切り替えミスというリスクも生まれます。プライベート API エンドポイントのみを持つクラスターでは、VPN 接続やバスティオンホストの整備まで求められるケースもありました。
今回の解決
EKS コンソールの対象クラスター画面右上にある Connect ボタンをクリックするだけで、そのクラスター向けに kubectl が設定済みの CloudShell セッションが即座に起動します。セッション内には AWS CLI と標準的な Linux ユーティリティも含まれており、起動直後から kubectl コマンドを実行できます。
# セッション起動後、すぐに実行できる例
kubectl get nodes
kubectl get pods -A
kubectl describe pod <pod-name> -n <namespace>
パブリック・プライベート両方の API サーバーエンドポイントに対応しています。ただしプライベートエンドポイントのクラスターに接続する場合は、CloudShell が自動的に VPC 環境を起動してクラスターのプライベート API サーバーへ到達する仕組みになっており、接続時に環境名の入力が求められます。この VPC 環境には通常の CloudShell とは異なる制約がある点は注意が必要です（詳細は後述）。
活用シーン
ゼロセットアップでクラスターにアクセスできるという特性上、この機能が特に効果を発揮するシーンは「すぐに動ける状態でない」ときです。代表的なケースを紹介します。
緊急トラブルシューティング
本番環境で障害が発生した際、手元にセットアップ済みの端末がない状況はよくあります。出先・別端末・共有 PC のどれであっても、ブラウザで AWS コンソールにサインインさえできれば即座にクラスターの状態を確認できます。
# Pod の状態を一覧確認
kubectl get pods -A
# 異常な Pod の詳細を確認
kubectl describe pod <pod-name> -n <namespace>
# コンテナログを確認
kubectl logs <pod-name> -n <namespace> --tail=100
# 直近の Pod の再起動履歴を確認
kubectl get pods -n <namespace> --sort-by='.status.containerStatuses[0].restartCount'
新規メンバーのオンボーディング
チームに参加したばかりのメンバーがクラスターの構成や稼働状況を確認したいとき、これまではローカル環境の構築が終わるまで待つ必要がありました。AWS アカウントへのアクセス権さえあれば、環境構築と並行してクラスターの状態を確認・学習できるようになります。
# クラスター内のノード構成を確認
kubectl get nodes -o wide
# デプロイされているワークロードを把握
kubectl get deployments -A
# Namespace 一覧を確認
kubectl get namespaces
マルチクラスター管理
開発・ステージング・本番など複数のクラスターを管理している場合、ローカルでのコンテキスト切り替えはミスの温床になります。本機能ではコンソール上で対象クラスターを選んで Connect するだけなので、kubectl のコンテキストを誤って操作するリスクがありません。
# 現在接続しているクラスターを確認（意図したクラスターかの確認習慣として）
kubectl config current-context
# リソースの状態確認
kubectl get all -n <namespace>
監査・レビュー作業
セキュリティ担当者やアーキテクトがクラスターリソースの状態を確認・レビューする際、専用のツール環境を用意せずに実施できます。CloudShell セッションの開始・終了といった API 操作は CloudTrail に記録されるため、誰がいつアクセスしたかの証跡は残ります。
# RBAC 設定の確認
kubectl get clusterrolebindings
kubectl get rolebindings -A
# リソースの設定内容を確認
kubectl get configmap -A
kubectl describe secret <secret-name> -n <namespace>
注意点とベストプラクティス
便利な反面、CloudShell の動作特性を理解せずに使うと想定外の挙動に遭遇することがあります。利用前に把握しておくべき点をまとめます。
セッションの自動終了
CloudShell セッションは一定時間の非アクティブ状態が続くと自動的に停止・破棄されます。長時間にわたる継続的な作業には向いていないため、本機能は一時的なアクセスや確認作業に限定して使うのが適切です。CI/CD パイプラインや定期的な自動化処理には、IAM ロールベースの専用環境を引き続き使用してください。
プライベートエンドポイント接続時の注意
2章で触れた通り、プライベートエンドポイントのクラスターに接続する場合は通常の CloudShell とは異なる VPC 環境が起動します。この VPC 環境には以下の制約があります。
| 項目 | 通常の CloudShell | VPC 環境（プライベートエンドポイント時） |
|---|---|---|
| 永続ストレージ | 1 GB（$HOME に保持） | なし（タイムアウト・再起動時に $HOME ごと削除） |
| タイムアウト | セッション非アクティブ時に停止 | 非アクティブ 20〜30 分で環境ごと削除 |
プライベートエンドポイント経由で作業する場合、VPC 環境上に作成したファイルやスクリプトは環境の終了と同時に消えます。必要なデータは S3 や他のストレージへ都度保存する運用を心がけてください。
永続ストレージと機密情報の扱い
通常の CloudShell には 1 GB の永続ストレージ（$HOME）がありますが、ここに kubeconfig やクレデンシャルなどの機密情報を長期保存することは推奨されません。CloudShell は複数のセッションをまたいでストレージが維持されるため、意図せず認証情報が残留するリスクがあります。本機能で自動設定される kubeconfig はセッション内で完結するものとして扱い、手動でファイルを残さない運用が安全です。
IAM 権限と Kubernetes RBAC
CloudShell セッションは、AWS コンソールにサインインしている IAM ユーザー・ロールの権限をそのまま継承します。クラスターへのアクセス制御は IAM ポリシーと Kubernetes RBAC の両方に依存するため、どちらか一方が緩いと意図しない操作が可能になります。最小権限の原則に基づいた設計は、本機能の導入後も変わらず重要です。
# 自分に割り当てられている権限を確認する
kubectl auth can-i --list
# 特定の操作が許可されているかを確認する
kubectl auth can-i delete pods -n <namespace>
EKS 運用簡素化の流れ
今回のアップデートは単独の機能改善ではなく、AWS が数年にわたって進めてきた EKS の運用簡素化という一貫した流れの延長線上にあります。
これまでの主なアップデート
EKS Cluster Access Management（2023年12月）
これまで EKS へのアクセス権限管理は aws-auth ConfigMap を直接編集する方法が主流でした。設定ミスがクラスターへのアクセス不能につながるリスクもあり、扱いに慎重さが求められる領域でした。
EKS Cluster Access Management（Access Entries）の登場により、IAM プリンシパルとクラスターアクセス権限の紐付けを EKS API 経由で管理できるようになりました。ConfigMap の手動編集が不要になり、IaC ツール（Terraform・CloudFormation・CDK）による宣言的な管理も可能になっています。なお現在、aws-auth ConfigMap ベースのアクセス管理は非推奨となっており、Cluster Access Management API への移行が推奨されています。
EKS Auto Mode（2024年12月 re:Invent）
クラスター上で動かすワークロードの土台となるコンピューティング・ネットワーキング・ストレージの管理は、従来ユーザー側の責務でした。Karpenter の設定、EBS CSI ドライバーの導入、kube-proxy や CoreDNS の管理。これらをすべて手がける必要がありました。
EKS Auto Mode ではこれらを AWS 側がフルマネージドで提供します。ロードバランシング・EBS による永続ストレージ・Karpenter ベースのオートスケーリングなどが標準で組み込まれており、単一の API 呼び出しまたはコンソール操作でクラスターに適用できます。
今回のアップデートの位置づけ
| 時期 | アップデート | 簡素化した領域 |
|---|---|---|
| 2023年12月 | EKS Cluster Access Management | 誰がアクセスできるかの管理 |
| 2024年12月 | EKS Auto Mode | クラスター上で何が動くかの管理 |
| 2026年4月 | CloudShell ワンクリックアクセス | どうやってアクセスするかの操作 |
アクセス権限の管理・クラスター基盤の管理・日常的なアクセス操作と、EKS 運用の各レイヤーが段階的に整理されてきました。今回のアップデートはその「アクセス操作」層に相当します。
まとめ
Connect ボタン一つで kubectl が使える状態になります。設定ゼロ、追加料金ゼロ、全 EKS リージョン対応です。緊急時の初動対応からオンボーディングまで、「環境がない」という状況での選択肢が増えました。
プライベートエンドポイントのクラスターでは VPC 環境が別途起動する点、CI/CD や自動化には IAM ロールベースの専用環境を使う点は押さえておいてください（詳細は 4 章参照）。
参考リンク
- Amazon EKS now supports one-click cluster access through CloudShell（What's New）
- Connect kubectl to an EKS cluster by creating a kubeconfig file（公式ドキュメント）
- What is AWS CloudShell（公式ドキュメント）
- Grant IAM users access to Kubernetes with EKS access entries（公式ドキュメント）
- EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する（公式ドキュメント）