Pod の差し替えで「更新」の意味が変わる：PHP の脆弱性から考える Kubernetes の備えと、EKS の費用・Alpine による軽量化

IT関連›Kubernetes

2026年10月21日、PHP の重大な脆弱性 2 件に対する修正版が公開されました。対処の基本は「更新して、再起動する」ことです。ところが、複数のサーバーに PHP を入れている場合は、この 2 つの作業を台数分くり返すことになります。しかも、更新は「やった」つもりでも、プロセスの再起動を忘れると、修正は効いていません。

こうした作業を、もっと確実で、もっと少ない手数で終えられないかと考えて、私は Kubernetes を使っています。このサイトも、Kubernetes 上で動いています。ただ、周りの方からは、「EKS は EC2 より費用が高くなる」とも聞きました。この言葉が本当かどうかを、公式の料金データで確かめたうえで、Kubernetes がセキュリティの面でどう役立つのかを、順に整理してみます。確認日は 2026年11月2日です。

「EKS は EC2 より高い」という話を、数字で確かめました

最初に、費用の話から入ります。ここで疑問が残ったままでは、その先の話を安心して読み進められないためです。

仕組みの違いは、管理料金の有無だけです

Amazon EKS は、AWS が管理する Kubernetes のサービスです。実際にアプリケーションを動かす計算機は、通常の EC2 のインスタンスです。つまり、EKS の費用は、EC2 の料金に、クラスターごとの管理料金を足したものになります。

EKS の料金ページによると、この管理料金は 1 クラスターあたり、標準サポートの版で1 時間 0.10 ドルです。1 か月を 730 時間として計算すると、73 ドルになります。

台数ごとに、差額の割合を計算しました

EC2 の単価は、AWS の公式の価格データ（2026年10月29日公開、東京リージョン、Linux、オンデマンド、米ドル）から取りました。この単価に 730 時間をかけて、EKS の管理料金 73 ドルを足した結果が、次の表です。

単価は、t4g.small が 0.0216 ドル、t4g.medium が 0.0432 ドル、m7g.large が 0.1054 ドル（いずれも 1 時間あたり）です。ロードバランサー、通信料、ストレージなどは含めていません。それらは、EC2 でも EKS でも、同じように必要になる費用です。

結論は「小さい構成では高く、大きいほど目立たない」です

この表から言えることは、2 つあります。

1. 小さな構成では、「高い」という話は本当です。 1 台で足りるサイトに EKS を使うと、管理料金だけで、計算機の費用の 4 倍以上になります。
2. 台数が増えるほど、管理料金の割合は小さくなります。 10 台の構成では、増える割合は 1 割未満です。

つまり、「EKS は常に高い」とは言えません。使う規模によって、高くも安くも感じられます。 複数のサイトやサービスを 1 つのクラスターに集めると、1 つあたりの負担は軽くなります。

表の「台数」は、ノードの数のことです

ここで、表の「台数」の意味を補足します。これは、アプリケーションを動かす計算機の台数です。EKS では EC2 のインスタンスで、Kubernetes の用語では「ノード」と呼びます。同じ Pod の複製（レプリカ）の数や、Helm チャートの数ではありません。

管理料金は、クラスター 1 つにつき固定です。レプリカを増やしても、チャートを足しても、管理料金は変わりません。費用が増えるのは、Pod が求める CPU とメモリの合計がノードに収まらなくなり、ノードを足したときです。ノードに空きがある間は、複数のチャートやレプリカを同じノードに載せられます。

したがって、表は「サイトを増やすたびに管理料金が増える」という意味ではありません。サイトを 1 つのクラスターに集めるほど、1 つあたりの固定費は薄まります。反対に、サイトごとにクラスターを分けると、そのたびに 73 ドルが加わります。

Google の GKE では、どうなるのでしょうか

同じ観点で、Google Cloud の GKE の料金ページ（2026年11月2日に確認）も調べました。

管理手数料は、1 クラスターあたり 1 時間 0.10 ドルで、EKS と同額です。運用モード（Autopilot か Standard か）や、ゾーンかリージョンかを問わず、一律に課金されると書かれています。

違いは、無料枠です。請求先アカウントごとに月 74.40 ドル分のクレジットが付き、Autopilot クラスターまたはゾーン Standard クラスター 1 つ分の管理手数料に相当します。このクレジットは、リージョンクラスターの管理手数料や、コンピューティング料金には使えません。つまり、最初の 1 クラスターは、管理手数料がかからないことになります。

もう 1 つの違いは、Autopilot という運用モードです。ノードの台数ではなく、Pod が要求した CPU・メモリ・一時ストレージに、秒単位で課金されます。東京リージョン（asia-northeast1）の標準価格は、1 vCPU あたり 1 時間 0.0571 ドル、メモリ 1 GiB あたり 1 時間 0.0063215 ドルです。730 時間で計算すると、次のとおりです。

この方式では、レプリカの数が費用に直接影響します。同じ Pod を 3 つ動かせば、費用は 3 倍です。ノードの空きや OS のオーバーヘッドは課金対象になりません。一方で、要求量が最小値や CPU とメモリの比率の条件に満たない場合は、Autopilot が値を引き上げると、料金ページに書かれています。

この表と EKS の表を、単純には比べられません。EKS の表は、2 vCPU・2 GiB の EC2 を 1 台借りた金額で、複数の Pod が空きを分け合えます。同じ大きさで並べると、Autopilot の単価は割高です。小さなサイトを 1 つだけ動かす場合は、無料枠と使った分だけの課金が働いて、GKE が有利になることがあります。多くの Pod を詰めて動かす場合は、ノードを借りる方式の方が、1 つあたりの費用を抑えやすくなります。

なお、Standard モードのノード（Compute Engine）の単価は、今回は確認していません。

見落としやすい費用が、もう 1 つあります

EKS の料金ページには、バージョンのサポート期間も書かれています。公開から 14 か月は標準サポートで、その後の 12 か月は延長サポートです。延長サポートに入ると、管理料金は 1 時間 0.60 ドル（月に約 438 ドル） になります。

GKE でも、Extended リリースチャンネルで標準サポートが終わると、管理手数料に 1 時間 0.50 ドルが加わり、合計で 1 時間 0.60 ドルになります。EKS と同じ水準です。

更新を後回しにすると、費用が 6 倍になる仕組みです。逆に言えば、定期的にバージョンを上げる習慣は、費用を抑える手段でもあります。この点は、後の「Pod の差し替え」の話ともつながります。

費用の次に気になるのは、攻撃を防げるのかという点です

費用に見通しが立ったところで、もう 1 つの疑問に進みます。「Kubernetes は DDoS 攻撃を受けても、自動的に直る」という話を聞くことがあります。これは、半分は正しく、半分は誤解を含んでいます。ここは、正確に整理しておきたい点です。

Kubernetes は、攻撃そのものを止める仕組みではありません

Kubernetes の公式の概要には、機能として「自己修復」が書かれています。しかし、これは、失敗したコンテナを作り直すものであり、攻撃の通信を遮断するものではありません。

大量の通信そのものへの備えは、別の層が受け持ちます。AWS の場合、AWS Shield Standard が、すべての利用者に追加料金なしで自動的に適用されます。これは、ネットワーク層と転送層（レイヤー 3・4）の、よくある攻撃を防ぎます。HTTP の洪水のようなアプリケーション層（レイヤー 7）への対策は、AWS WAF や、有料の Shield Advanced といった別の仕組みの役割です。

それでも、Kubernetes に価値がある理由

では、Kubernetes は DDoS に無力なのかというと、そうではありません。攻撃を受けて、アプリケーションが応答しなくなったときの「回復の速さと確実さ」に、大きな違いが出ます。この点は、後の節で詳しく見ます。

もう 1 つ、率直に挙げておきたい点があります。Kubernetes は、仕組みを覚える負担が小さくありません。設定ファイルの書き方、Pod、Deployment といった用語など、最初は戸惑う部分が多いはずです。ただ、その負担と引き換えに得られるものが、次の節から見ていく内容です。

Kubernetes は「壊れる前提」で作られた仕組みです

ここからは、肯定的な事実を順に見ていきます。最初に、Kubernetes がどのような考え方で作られたのかを確認します。考え方を知ると、後の機能が自然に理解できます。

Kubernetes の公式の概要には、「Google は 2014 年に Kubernetes を公開した」と書かれています。また、「Google が大規模な本番環境を運用してきた 15 年以上の経験を、コミュニティの優れた考え方と組み合わせたもの」とも説明されています。

大規模な環境では、機械の故障は例外ではなく、日常的に起こります。そのため、Kubernetes は、「壊れないように守る」のではなく、「壊れたら自動で直す」ことを前提に設計されています。人が手順書を見ながら復旧するのではなく、「こうあるべき状態」を宣言しておき、現実がそこからずれたら、Kubernetes が元に戻します。

この「宣言した状態に保つ」という考え方が、次に見る Pod の差し替えの土台です。

Pod の差し替えで、バージョンアップの意味が変わります

PHP の脆弱性への対処では、更新と再起動の 2 段階が必要でした。Kubernetes では、この 2 段階が、1 つの操作にまとまります。

動いているものを直すのではなく、新しいものと入れ替えます

従来のサーバーでは、動いている PHP を更新します。つまり、「同じ機械の中身を書き換える」作業です。一方、Kubernetes では、Pod を直接書き換えません。Deployment という仕組みに、新しい版のイメージを指定すると、次のように動きます。

Kubernetes の公式の説明では、Deployment の Pod の定義を更新すると、新しい ReplicaSet が作られます。そして、新しい ReplicaSet を少しずつ増やし、古い ReplicaSet を少しずつ減らして、Pod を決められた速さで入れ替えます。

たとえば、PHP の修正版 8.5.12 に上げる操作は、イメージのタグを書き換えるだけです。

containers:
  - name: php
    image: php:8.5.12-fpm-alpine

この 1 行を変更して適用すると、古い PHP の Pod が、新しい PHP の Pod に入れ替わります。更新したことと、再起動したことが、同時に完了します。「更新したのに、プロセスが古いまま」という、見落としやすい失敗が起こりません。

失敗しても、元に戻せます

公式の説明には、Deployment の状態が安定しない場合に、以前の版に戻せることも書かれています。新しい版で問題が出たら、1 つ前の状態に戻せるので、更新に対する心理的な負担が軽くなります。

ここに、「バージョンアップの概念が変わる」ということの中身があります。これまで更新は、「うまくいくか分からない、慎重に行う作業」でした。Pod の差し替えでは、更新は、新しいものに入れ替えて、問題があれば戻す、日常的な操作になります。

先ほど見た、EKS の延長サポートの費用も、ここで効いてきます。更新が日常的な操作であれば、バージョンを遅らせる理由が減ります。結果として、延長サポートの費用を払わずに済みます。

異常があれば、自動で作り直され、初期の状態に戻ります

次に、DDoS 攻撃のような、過負荷や異常への強さを見ます。ここで、Kubernetes の自己回復が役立ちます。

応答しなくなったコンテナは、自動で再起動されます

Kubernetes の公式の概要には、自己修復について、次のように書かれています。失敗したコンテナを再起動し、コンテナを入れ替え、利用者が定めた健康確認に応答しないコンテナを停止し、準備ができるまで利用者に見せません。

健康確認（liveness probe）の仕組みでは、確認用の処理が失敗を返すと、kubelet（各サーバーで動く管理役）がコンテナを停止し、再起動します。たとえば、攻撃を受けて PHP が応答しなくなると、確認が失敗します。すると、人が気づく前に、自動で再起動されます。

再起動すると、書き換えられた中身も消えます

もう 1 つ、セキュリティの面で見逃せない点があります。Kubernetes の公式の説明では、コンテナの中のファイルは一時的なものです。コンテナが停止して再起動されると、コンテナの中で作られたり変更されたりしたファイルは、すべて失われます。再起動後は、「きれいな状態」から始まります。

これは、侵入への備えとして、意味があります。仮に、攻撃者がコンテナの中に不正なファイルを置いたとしても、Pod が作り直されれば、そのファイルは残りません。入れ替えのたびに、イメージが持つ元の状態に戻るわけです。

ただし、万能ではありません

この仕組みには、限界もあります。公平に整理します。

つまり、自己回復は「被害の拡大を抑え、元の状態に戻す」力であり、「脆弱性をなくす」力ではありません。脆弱性そのものは、先ほど見た Pod の差し替えで、イメージを更新して直します。この 2 つを組み合わせて、はじめて意味があります。

費用の話に戻ります：コアシステムを軽くするという考え方

ここまでで、Kubernetes の価値を見てきました。そこで、冒頭の費用の疑問に戻ります。小さな構成では EKS の管理料金が割高になることは、最初に確認したとおりです。この負担を和らげるために、イメージ自体を軽くする案をご提案します。

Alpine ベースのイメージは、約 5 分の 1 の大きさです

Docker Hub の公式イメージで、PHP 8.5.12 の FPM 版のサイズを比べました（2026年11月2日時点、amd64 向け、圧縮後の大きさです）。

Alpine 版は、通常版の約 22% の大きさです。Alpine Linux は、自身について「コンテナは 8 MB 以内で動く」と説明しています。また、すべての実行ファイルを、スタックの破壊を検出する保護付きの PIE 形式でビルドしている、とも述べています。

軽くすると、期待できることと、約束できないこと

軽量化で期待できる効果を、確実なものから順に整理します。

• 取得と入れ替えが速くなります。 Pod の差し替えでは、新しいイメージを取得する必要があります。サイズが小さいほど、取得は速く終わります。脆弱性への対処を急ぐときに、効いてきます。
• 含まれる部品が少なくなります。 不要なコマンドやライブラリが少ないほど、攻撃の足がかりも少なくなります。
• 保存と転送の量が減ります。 台数が多いほど、積み重ねで差が出ます。

一方で、お約束できない点もあります。PHP の処理そのものが速くなるとは、言い切れません。 Alpine は、一般的な Linux と異なる標準ライブラリ（musl libc）を使っています。PHP の公式イメージの説明にも、ソフトウェアによっては、ライブラリへの依存の深さしだいで問題が出る、という注意書きがあります。「速さ」の面では、起動と入れ替えが速くなると考えるのが、現実的です。

費用への効き方は、間接的です

「イメージを軽くすれば請求額が下がる」と、直接はつながりません。ただ、次の 2 つの経路で、費用の軽減に役立つと考えられます。

1. 更新が速く、気軽になります。 更新の負担が小さいと、バージョンを遅らせずに済みます。EKS の延長サポート（月に約 438 ドル）を避けやすくなります。
2. サーバーを減らす検討がしやすくなります。 1 つのクラスターに複数のサイトを集めれば、管理料金 73 ドルを分け合えます。軽いイメージは、同じ計算機に、より多くを載せる助けになります。

なお、サイトが 1 つだけで規模も小さい場合は、EKS の管理料金が割に合わないこともあります。その場合は、管理料金のかからない、自前のクラスターという選択肢もあります。このサイトは、自宅の Raspberry Pi で構築したクラスターで動いています。

小さく始めて、確かめる進め方をおすすめします

ここまでの内容を、実際の行動につなげます。いきなり全体を移行するのではなく、次の順に小さく始めると、負担が少なく済みます。

1. 現在の PHP の版を確認します。 php -v で、修正版（8.5.12・8.4.27・8.3.36・8.2.35 以降）になっているかを確かめます。
2. イメージを Alpine 版に替えて、動作を確かめます。 開発用の環境で、アプリケーションが問題なく動くかを試します。musl libc との相性は、ここで分かります。
3. 1 つのサイトを、Deployment で動かしてみます。 タグを書き換えて適用し、Pod が入れ替わる様子を観察します。
4. 健康確認を設定します。 応答しないときに、自動で再起動される状態を作ります。
5. 費用を見積もります。 上の表を参考に、台数と管理料金の割合を確かめます。

どの段階でも、うまくいかなければ、元に戻せます。この「戻せる」という性質が、Kubernetes の運用を始める際の、大きな安心材料になります。

更新が、特別な作業ではなくなります

最初の疑問に戻ります。「EKS は EC2 より高い」という話は、小さな構成では本当でした。1 台で足りるサイトでは、管理料金が計算機の費用の 4 倍以上になります。一方で、台数が増えるほど、その割合は小さくなります。10 台の構成では、1 割未満の増加でした。

Kubernetes は、DDoS の通信そのものを止める仕組みではありません。そこは、Shield や WAF のような別の層の役割です。ただ、応答しなくなった Pod を自動で作り直し、きれいな状態に戻す力は、昨今のセキュリティの事故への備えとして、確かな意味を持ちます。

そして、Pod の差し替えは、バージョンアップを「慎重に行う特別な作業」から「戻せる日常の操作」へと変えます。PHP の脆弱性のような緊急の更新でも、イメージのタグを書き換えるだけで、更新と再起動を同時に済ませられます。そこに Alpine ベースの軽いイメージを組み合わせれば、入れ替えはさらに速くなります。

まずは、お使いの PHP の版を確かめて、イメージを Alpine 版に替えた場合の動作を、手元の環境で試してみることをおすすめします。この記事が、構成を考える際の参考の一つになれば幸いです。