FileStackからS3へ: 大したことのない移行がもたらしたもの

FileStackに依存していた会社ロゴ／プロフィール画像のアップロードをS3に統合しながら経験した問題と、その解決過程をまとめた記事です。

導入背景

• 初期にはFileStackが「コアではないアップロード機能」の実装時間を大幅に短縮してくれ、プロダクションでも長い間問題なく使えていた
• 時間が経ってS3インフラが整ったが、ロゴ／プロフィールだけが外部サービスに残っている構成が気になり始めた
• Dev／テスト環境ではFileStackのRate Limitにより画像が壊れることが頻繁に起きた

問題

• ローカルでAWS S3向けに開発しようとすると、STS一時トークンの期限切れ、ネットワーク依存、オンボーディングのハードルが煩わしかった
• 移行中に見落としかけた落とし穴: メールのロゴがpresigned URLのTTL切れで後から壊れる可能性がある

解決

• ローカル開発はMinIOで単純化（S3 API互換、Dockerで簡単に構築）
• メールのロゴはバケットをprivateのまま維持しつつ、CloudFrontでpublic/*パスだけを公開する形で分離

なぜ今回はやったのか

• 「レガシー改善」は常にROIの問題で先送りしやすいが、今回はAIコーディングツールのおかげで試行錯誤のコストが減り、「やってみる価値がある」と判断できた
• 正直、AIがなければ試さなかったと思う

学んだこと

• FileStackは悪い選択ではなく、当時は最善であり、「いつ撤去するか」のほうがより重要な問題だった
• 状況が変われば取り除けばよく、AIツールがその「後で」をより容易にしてくれている