何年か動いている業務システムの請求内訳を見ると、使われている時間が短い環境の料金が意外に大きいことがあります。アプリごとに専用の環境を立てる構成では、負荷が小さいアプリでも実行環境を1つ抱えることになるためです。
かといって、この構成をKubernetesに載せ替えるとなると、運用の担当者が別途必要になります。「今のままでは無駄が出る、動かすと運用が重くなる」という間で、判断が止まりやすいところです。
専用環境から共有インフラへ
AWSは2026年9月17日、Elastic Beanstalkにクラスターモードを追加しました。同一アカウント内の共有インフラで複数のアプリケーションを動かす新しいデプロイモードで、基盤にはAmazon EKSを使います。
従来のスタンダードモードとクラスターモードは、同じElastic Beanstalkアプリケーションの中で並存できます。1環境ずつ、自分たちのペースで移せるということです。変更の前には互換性の検証チェックが走るため、動かせない環境が強制的に移されることはありません。
料金は、クラスターモード自体に追加の課金はありません。支払うのはアプリケーションが消費するリソースの分で、ここにEKSクラスターとEKS Auto Modeの料金が含まれます。提供範囲はElastic Beanstalkが使える全ての商用リージョンです。
ただし、安くなるかどうかは規模しだいです。AWSは、アプリが1つだけの構成や、月の支出が500ドルに満たない規模では、EKSのコントロールプレーンの料金とEKS Auto Modeの割増分を、複数アプリの相乗りによる節約で吸収できないとして、スタンダードモードのほうが適するとしています。
まず問われるのは、ステートレスかどうか
新しい選択肢が増えたときに最初に確かめるべきは、自分たちのアプリがその前提に合うかです。
クラスターモードは、アプリケーションがステートレスであることを前提にしています。レプリカが互いに入れ替え可能で、ローカルストレージは一時的なもの、という作りです。裏を返せば、サーバー上のディスクにファイルを書いて後から読む作りは、外部の永続ストレージに移さない限り乗りません。リクエストは複数のレプリカに振り分けられるため、セッションをプロセス内に持つ作りも見直しが要ります。
古いシステムほど、この条件に引っかかります。アップロードされたファイルをローカルに保存している、バッチの中間ファイルを同じディスクに置いている、といった作りが残っているためです。移行の検討は、この棚卸しから始まります。
ソースコードからの構築に対応する言語は、Buildpacks経由でJava・Go・Python・.NET・Node.js・PHP・Rubyです。ソースコード、Dockerfile、Amazon ECRのコンテナイメージのいずれかを渡せば、コンテナ化と構築、その後の運用はElastic Beanstalkが受け持ちます。一方で、コンテナにできないアプリや、IIS上で動くWindowsの.NET Frameworkのアプリは、AWS自身がスタンダードモードのほうが適するとしています。
あとから変えられないもの
もう1つ、事前に決めておかないと後戻りできない項目があります。
| 項目 | 扱い |
|---|---|
| どのクラスターに入るか | 同じVPCサブネットの組を使う環境が同じクラスターを共有する。組が違えば別クラスター |
| クラスターとそのKubernetesバージョン | 利用者が選べない。バージョンはクラスターが存在する間変わらない |
| 既存環境のサブネットと、クラスター・ノード・可観測性用のIAMロール | あとから変更できない。変えるには新しい環境を作り、CNAMEを入れ替える |
クラスターは、そのサブネットの組を初めて使うときに作られ、作成に10分程度かかります。クラスターへの直接のアクセスはサービス側の管理下にあります。クラスターを直接変更すると、元の構成に戻すまでElastic Beanstalkはそのクラスターの管理を止め、載っている環境の更新も失敗します。
重要なのは1行目です。クラスターの割り当てがサブネットの組で決まるということは、「どのアプリを同じクラスターに同居させるか」をサブネット設計で表現することになります。別々の顧客に属する環境、自分たちで管理していないコードを動かす環境、インフラの分離を求める規制の対象となる環境については、AWS自身が別のサブネットの組、つまり別のクラスターに分けるよう案内しています。同居の線引きは、移行を始める前にネットワーク設計として決めておく必要があります。
共有インフラで得るもの
移行後に入ってくるものもあります。イベント駆動のオートスケール、OpenTelemetryベースの可観測性をCloudWatchやサードパーティへ送る仕組み、AWS Secrets Managerとの連携、AWS Certificate Managerによる既定でのHTTPS対応です。
このうち可観測性は、保守を外部に委託している場合に効きます。何が起きているかを同じ形で見られるかどうかで、障害時のやり取りの速さが変わります。
移行を検討する順番
検討の順序を間違えると、調査の工数だけが膨らみます。
- 対象アプリがローカルディスクとプロセス内の状態に依存していないかを確認する
- 依存している場合、その部分を外部化する工数を見積もる
- 同じクラスターに入れてよいアプリの組み合わせを、サブネットの設計として決める
- 1環境を選んで移し、料金と運用の変化を実測する
4番目まで進めてから全体の判断をするのが現実的です。アプリケーション層を移しても、データベース側の検討は別に残ります。そちらの判断軸はDBのモダナイゼーションに整理しました。実行基盤そのものを他社へ移す選択肢も含めて比べる場合はCloudflareとAWSの選定と移行を参照してください。
2026年9月25日に、AWSの2026年9月17日付のリリースノート、What’s Newの告知、AWS News Blogの記事と、Elastic Beanstalk開発者ガイドのクラスターモードの各ページ（構成、マルチテナンシー、コンテナイメージの作成）を確認しました。クラスターモードでの環境作成、既存環境の移行、料金の比較は未実施です。対応する言語や制約は変わるため、検討時にAWSの公式ドキュメントで確認してください。本記事は前提条件と検討順序の整理です。
既存システムの移行可否の調査や、保守コストの見直しは、グリームハブへご相談ください。
