【導入文】
こんにちは。社内システムのクラウド化を支援している「僕」です。
ハードウェアの制約を知り尽くす半導体エンジニアの「妻」に、AWSの仕組みを語るこのシリーズ。今回は、AWSのロードバランサー（ALB）の便利機能と、便利ゆえに陥りやすい「恐怖のループ処理」について検証した日の会話をお届けします。

1. 【プロローグ】高給取りのLambda@Edgeをリストラだ！

僕：「ねえ聞いて！最近、Application Load Balancer（ALB）の標準機能だけで、ターゲットにリクエストを送る前に『URLのパスやホストヘッダーを書き換える（トランスフォーム）』ことができるようになったんだ！」

妻：「へえ。今までわざわざプログラムを書いてパスを変換してたって言ってたわよね？」

僕：「そう！ Lambda@EdgeとかCloudFront Functionsっていう機能を使ってたんだけど、地味にお金もかかるし、コードの管理も面倒だったんだよね。これからはALBの標準機能だけでタダで書き換えできる！さっそくLambda@Edgeはリストラだ！」

妻：「インフラのルーティング層だけで完結するのは良いわね。でも、中継機（ALB）が勝手にデータの宛先ラベルを書き換えて、受け取り側の演算ユニット（サーバー）に渡したら、認識の不整合が起きないの？」

僕：「えっ？ ALBが宛先を綺麗に整えてから渡してあげるんだから、サーバー側もすんなり処理できて喜ぶに決まってるでしょ！」

妻：「……その浅はかな考え、絶対に痛い目を見るわよ。ちょっと検証してみましょ」

2. 【Tipsのタネ明かし】新機能「ALBのパス書き換え（トランスフォーム）」

僕：「検証の前に、まずは新機能の仕組みを解説するね。これまでのALBは、受け取ったURLのパス（例：/api/users）を、そのまま裏側のサーバー（EC2やECS）に流すことしかできなかったんだ。」

妻：「入力された信号をそのままスルーするだけの素直なインターフェースだったのね。」

僕：「そう。でも新機能により、ALBのリスナールールで**『バックエンドのサーバーに渡す前に、指定したパスの形に書き換える（Transform）』**ことが可能になったんだ。例えば /app/ 宛てに来たものを / に変換して裏に流す、みたいなことができる。」

3. 【実践Tips】恐怖の「無限リダイレクト」を発生させる手順

僕：「では、この便利機能を使って、ブラウザが悲鳴を上げる『無限リダイレクト（ERR_TOO_MANY_REDIRECTS）』を意図的に引き起こしてみるよ。」

お節介なバックエンドサーバーを用意する
EC2にWebサーバーを立て、「/（ルート）」にアクセスが来たら、強制的に「/app/」へリダイレクト（301応答）するような設定にしておく。
ALBのトランスフォームルールを設定する（罠の発動）
ALBのリスナールールで、「もしリクエストが /app/* に来たら、パスを /* に 書き換えて（トランスフォームして） からサーバーに送る」という設定をする。
ブラウザからアクセスする
ブラウザに http://[ALBのURL]/app/ と入力してエンターキーをターンッ！

僕：「すると、画面が真っ白なまましばらく読み込み中になり……ほら！見事に**『リダイレクトが繰り返し行われました』**というエラーが表示されて機能停止した！」

4. 【解説と解決策】なぜ無限ループしたのか？

妻：「ほらね。見事に論理回路がショートして、無限に発振（ループ）してるじゃない。」

僕：「うわっ、ほんとに画面が開かない！裏側で一体何が起きてるんだ？」

僕：「ええと、通信の流れを追ってみると……

ブラウザが /app/ にアクセスする。
ALBがルールに従って、パスを / に**書き換えて（隠蔽して）**裏のサーバーに渡す。
サーバーは / を受け取って、『ここは違う！ /app/ に行きなさい！』とブラウザに**リダイレクト（301）**を返す。
ブラウザは言われた通り、再度 /app/ にアクセスする。
（2に戻る）……あっ！！」

妻：「気づいた？ ALBがよかれと思って『/app/』というラベルを剥がして『/』として工場に搬入する。でも工場（サーバー）側は『/』の荷物を見ると『これは違うラインだ、/app/ に回せ！』って搬送先変更（リダイレクト）の指示を出す。それを真面目な搬送ロボット（ブラウザ）が再度ALBに持ち込んで……永遠にウェハーが工場内をぐるぐる回り続けるわけね。」

僕：「なるほど！ ALBがよかれと思ってURLを書き換えたせいで、サーバー側の『正しいURLに転送する機能』と完全に衝突しちゃったのか！」

解決策のTips：
ALBでの「URL書き換え（トランスフォーム）」は、ブラウザには見えない裏側の処理です。
利用する際は、バックエンドのアプリケーション（WordPressなどのCMSや、Webフレームワーク）が、「書き換えられた後のパス」を正しく受け入れられる設定になっているか（勝手にリダイレクトを返さないか）を必ずセットで確認しましょう。

5. 【お片付け】アクセスログの肥大化による課金に注意

僕：「いやー、ALBとサーバーの連携ミスって怖いね。Lambda@Edgeをリストラする前に気づいてよかったよ。」

妻：「感心してる場合じゃないわ。物理的な半導体回路なら、こんな無限ループの発振を起こしたら熱暴走（サーマルランナウェイ）でチップが焼け焦げるわよ。クラウドの場合はどうなるの？ただ通信がぐるぐる回ってるだけ？」

僕：「あ、いや……実はALBを通った通信って、全部S3っていうストレージに『アクセスログ』として記録される仕様になってるんだ。そして、S3のストレージ代は『保存されたデータ量』に対する従量課金……」

妻：「ちょっと待って。さっきの無限リダイレクト、エラーで止まるまでの数秒間で何百回もALBとサーバーを往復してるのよね？ってことは、あなたが呑気に『ループした〜』って笑ってる間、無駄なアクセスログがものすごい勢いでS3に書き込まれ続けてるってことじゃない！！」

僕：「あ……！！」

妻：「クラウドでの熱暴走は、インフラの炎上じゃなくて『請求書の炎上』よ！！すぐにALBを止めて、無駄なログを消してきなさい！」

僕：「ひえっ！！す、すぐにお片付けしてきます！！」

【結びの文】
ALB単体でURL書き換えができるようになり、インフラ構築は格段にシンプルになりました。
しかし、妻の言う通り、バックエンドのルーティング仕様との「衝突（無限リダイレクト）」と、ループによって引き起こされる「アクセスログの熱暴走（課金）」には十分ご注意ください！