「システムの構成図なら読める。AWSも、図を見れば言っていることは理解できる」——私自身、転職してクラウドに入ったとき、そう感じていました。前職はオンプレ環境のシステムエンジニアで、インフラそのものを本格的に触ったのは転職後です。それでも、システムの構成を読む土台は前職で身についていたので、AWSの構成理解は思ったよりスムーズでした。
ところが、EKSを新規で構築する段になって、まったく別のところで足をすくわれました。ネットワークの疎通とコストの見積もりです。どちらも「構成は分かっている」はずの私が、もっとも時間を溶かしたポイントでした。
この記事は、ある金融系システムをEKSで新規構築したときに、私が実際に詰まった落とし穴を、オンプレ出身者の視点で言語化したものです。これからAWSで本番環境を組む人——とくにオンプレの土台がある人ほど、同じ穴に落ちやすいはずです。
なぜ「構成は分かるのに詰まる」のか
先に結論を言うと、オンプレ出身者がEKS新規構築でつまずくのは、知識が足りないからではありません。オンプレで染みついた「当たり前」が、クラウドではそのまま通用しないからです。
- オンプレのファイアウォールは「行きも帰りも両方ルールを書く」——でもAWSのセキュリティグループは違う
- オンプレのサーバは「固定IPで、立てたら立てっぱなし」——でもクラウドはIPも料金も動く
この「染みついた前提」とのギャップが、そのまま落とし穴になります。順に見ていきます。
落とし穴① ネットワーク疎通——「トラフィックが来ない」の正体
一番時間を溶かしたのがここです。トラフィックがなかなか来ない、来ても接続が安定しない。原因は1つではなく、3つの要因が重なっていました。
セキュリティグループとNACLの「戻り通信」
最初に混乱したのが、セキュリティグループ(SG)とネットワークACL(NACL)の挙動の違いです。
- セキュリティグループはステートフル:インバウンドを許可すれば、その戻りのアウトバウンドは自動的に許可されます。行きだけ書けば帰りは通ります。
- NACLはステートレス:行きと帰りを別々に許可する必要があります。戻りの通信はエフェメラルポート(1024-65535)を使うため、ここを開け忘れると「行きは通るのに、応答が返ってこない」が起きます。
オンプレのファイアウォールは行き帰り両方のルールを書くのが当たり前だったので、SGの「行きだけでいい」感覚とNACLの「両方書く」感覚が頭の中で混ざり、どちらで何を許可しているのか分からなくなりました。
教訓は、まずSGで通信を組み立て、NACLは原則デフォルト(全許可)のまま触らないこと。両方で絞ると、繋がらないときの切り分けが一気に難しくなります。
ターゲットグループのヘルスチェックが通らない
次に詰まったのが、ロードバランサー(ALB)のターゲットグループのヘルスチェックです。アプリ(Pod)は動いているのに、ALBから見ると「unhealthy」と判定され、トラフィックが流れてこない。
原因は定番の2つでした。
- ALBからターゲットへのヘルスチェック用ポートを、セキュリティグループで許可していなかった
- ヘルスチェックのパスが200を返していなかった(アプリ起動前、あるいはパス指定違い)
「アプリは起動しているのに繋がらない」ときは、まずターゲットグループのヘルス状態を見る——これがクラウドでの第一手だと、ここで体に叩き込まれました。
ALBのIPは動く × DNSキャッシュで接続が安定しない
そして、一番「オンプレ脳」を裏切られたのがこれです。接続が、繋がったり切れたりして安定しない。
原因は、ALBのIPアドレスは固定ではなく、動的に変わるという事実でした。ALBは内部でスケールするたびにIPが入れ替わります。にもかかわらず、クライアント側が古いIPをキャッシュし続けると、ALBのIPが切り替わった瞬間に、もう存在しない宛先へ繋ぎにいって接続が不安定になります。
オンプレの「サーバ＝固定IP」という前提が骨の髄まで染みていたので、「IPが動く」こと自体が発想になく、原因の特定に時間がかかりました。
対策は、IPを直に掴ませず、必ずDNS名(ALBのドメイン)で名前解決させ、クライアント側のDNSキャッシュのTTLを過信しないこと。クラウドでは「宛先は動くもの」という前提に、頭を切り替える必要がありました。
落とし穴② コスト見積もり——オンプレ感覚の見積もりが当たらない
もう一つ溶かしたのが、コストの見積もりです。オンプレの感覚で「サーバ何台ぶん」とざっくり積もったら、実際の請求はまったく違う形で積み上がっていきました。クラウドは請求の単位がサービスごとにバラバラで、オンプレの「ハードを買えば終わり」とは構造が根本から違います。
EKSコントロールプレーンの定額課金
見落としやすいのが、EKSのコントロールプレーンは、クラスターを立てているだけで時間課金される点です。Podを1つも動かしていなくても、クラスターが存在する限り課金が続きます。
オンプレなら「サーバを置いただけで、使っていなければほぼタダ」の感覚ですが、クラウドでは"存在しているだけでお金がかかる"リソースがある。検証用に立てたクラスターを消し忘れて、地味に課金が続く——これは典型的なやらかしです。
CloudWatch Logsの蓄積課金
もう一つがCloudWatch Logsです。ログは取り込み量と保存量の両方で課金され、しかも放っておくと溜まり続けます。最初は微々たる額でも、本番で出力が増え、保持期間を設定していないと、知らないうちに無視できない金額に育ちます。
対策はシンプルで、ロググループごとに保持期間(リテンション)を最初に設定しておくこと。「あとで設定しよう」が一番危ないパターンです。
オンプレ見積もりとの一番のズレは、「使った量」だけでなく「置いてあるだけ」「溜めているだけ」でも課金されるという発想の差でした。見積もり段階で、各サービスの課金単位(時間あたり/データ量/転送量)を一つずつ確認するクセが必要です。
まとめ:オンプレ出身がEKS新規構築で最初に潰すべき2点
オンプレ環境でシステムに向き合ってきた経験は、AWSの構成理解では確実に武器になります。実際、私もそこはスムーズでした。だからこそ、油断したネットワークとコストで足をすくわれた——というのが正直なところです。
オンプレ出身者がEKS新規構築で最初に潰しておくべきは、この2点です。
- ネットワーク:SG(ステートフル)とNACL(ステートレス)の違いを切り分け、繋がらないときはヘルスチェックをまず疑い、「宛先IPは動く」前提に頭を切り替える
- コスト:「置いてあるだけ」「溜めているだけ」で課金されるリソースを把握し、課金単位をサービスごとに確認する
「構成は分かる」と「本番が動く・コストが読める」の間には、オンプレ経験者ほど気づきにくい谷があります。この記事が、その谷を先回りして埋める助けになれば幸いです。
関連記事
AWSキャッチアップ全体でつまずきやすいポイントは、オンプレ出身がAWSをキャッチアップ｜実務で詰まった4つの壁に概観としてまとめています。本記事は、そのうちネットワークとコストを深掘りした続編です。
こうした実務の穴を体系的に埋めたいなら、AWS SAAに一度落ちた私が2回目で合格して実務で分かった本音もあわせてどうぞ。
そもそも私がどうやってオンプレからクラウドへ移ったのかは、オンプレからクラウドへ転職した実体験に書いています。