以前、チームプロジェクト（ガチャコ）に参加した際、初めてサーバーインフラの構築に触れました。当時は右も左もわからず、技術用語の羅列に圧倒される毎日でした。
「ただ動くものを作るのではなく、構造を本質的に理解したい」
そう考えた私は、複雑なインフラの流れを自分なりに噛み砕き、「探偵事務所と国境警備隊」という物語に例えて整理してみました。
名前しか知らない「未知の場所（ドメイン）」に行きたくなった私は、有名な「探偵事務所（Route 53）」を訪ねることにしました。
「あそこに行きたいんだけど、住所を教えて」と頼むと、正確な住所ではなく、その周辺の「地図（ホスティング領域）」を渡されました。詳しく知るために外の人に聞こうとすると、「そのエリアは危険だから、一度しか質問できない」と言われます。
そこで、私は2つの方法から1つを選びます。
1️⃣「住所（IPアドレス）」を特定して地図に書き込む（Aレコード作成）。
2️⃣ その場所の「別名（東京＝江戸のような）」を教えてもらう（CNAMEレコード作成）。
なんとか住所を手に入れて出発したものの、道に迷いそうになります。でも、道中の「案内板（ルーター）」が「こっちだよ」と教えてくれました（ルーティング）。
さらに進むと、「国境警備隊（ファイアウォール）」の検問がありました。幸い私は通れましたが、後ろの人は通してもらえませんでした。
いよいよ目的地である「未知の場所（ドメイン）」に到着。しかし、入り口には鍵がかかっています。門を開けるには、3つの方法があるようです。
方法1 :「受付（ALB）」を通って、「門番（Nginx）」から判子をもらい、門を開けてもらう。（自己署名証明書/手動管理）
方法2 :「使い走り（Certbot）」を雇って、代わりに「鍵発行機関（Let's Encrypt）」で鍵をもらってきてもらい、門番に見せる。
方法3 : 受付の人（ALB）と親友になり、「専用通路（ACM）」から用意された鍵（証明書）を受け取って安全に入る。
私はこの中の1つを選び、ついに目的地でやりたい作業（サーバー接続）を完了させることができました！
【技術的な振り返り】
この物語は、以下の技術スタックをイメージしています。
Route 53 (DNS) / Aレコード / CNAME
Security Group / Firewall
Nginx (Reverse Proxy)
SSL証明書の管理 (Certbot / AWS ACM)
単に「動けばいい」ではなく、ユーザーが安全にサービスにたどり着くまでの「旅路」を設計することの重要性を学びました。特に実務では、運用の効率やセキュリティを考えて「どの鍵の開け方を選ぶか」が重要であることを実感しています。
