迷宮インフラを整理してAWSコストを66%削減した話
こんにちは、私は普段SREエンジニアをしています。
今年の11月から、友人がテックリードを務めるスタートアップで、副業としてお手伝いをさせていただいています。少数精鋭の体制で、スピード感を持って新規開発に取り組んでいるチームです。その中で私は、主にインフラ領域全般を担当しています。
勤務開始！困った困った
勤務開始後、困ったことがありました。システムに関するまとまったドキュメントがなかったのです。断片的な情報は落ちていますが、システム全体を俯瞰できる資料がないため、現在どのように動いているのか把握できませんでした。
これはいかんということで、まずは現状のシステムの整理及びドキュメントの作成に取り掛かりました。幸い、使用しているリソースの数もそれほど多くありませんでした。
システム全体の確認
どのようにしてシステム全体を把握しましょうか。私はまず以下に取り組みました。
- AWS Cost Explorerからどのサービスを使っているのかを確認
- GitHubの主要なリポジトリをCopilotに分析させて仕様書を作成してもらう
AWS Cost Explorerからはなんとなくの情報が見えてきます。EC2やECS、ELBにコストが発生していれば、よくあるAWSの構成が想像できます。なんとなくの構成が見えてきたら、あとはAWSのコンソールとにらめっこです。各リソースを見に行ってネットワークや設定を確認し、メモしながらdrawioで図に起こしていきます。システムのコードについては、Copilotで全体の構成を分析してもらいました。どのサービスと連携しているか、どんなアーキテクチャで動いているかを把握するのが目的です。
最後に、集められたすべての情報をまとめ、ドキュメントを作成し、認識と相違ないかチームメンバーに確認します。ここで注意したいのは、集められた情報についてメンバーが合意したとしても、すべてを鵜呑みにしないことです。なぜなら、全体を見渡すドキュメントがないくらいにはインフラが管理されていなかったため、メンバーも全て把握しているとは限らないからです。ここでは全体像を把握するにとどめます。
見えてきた課題
システムを確認していく中で以下の課題が見えてきました。
- リソースの残骸が多い
- 単一アカウントに本番と検証のリソースが混在
- インフラをコード管理していない
リソースの残骸が多い件に関しては、スタートアップということもあり、開発のサイクルが早く、どんどん新しいソフトウェアを開発してきた背景があるのでしょう。新規開発に注力するばかりにリソースが置き去りになっていました。
単一アカウントに本番と検証のリソースが混在している問題に関しては、単に管理が楽だったのだと思います。ただ、これは早いうちに解消しておかないと、将来とても面倒なことになるのは目に見えています。検証に使っているサーバーのすぐ隣に本番サーバーが稼働している状況はとても怖いです。
他にもいくつかあり、以下の記事に出てくるアンチパターンをことごとく踏んでいました。
対応
こういった課題は今は問題ないかもしれませんが、事業規模が大きくなるにつれて苦しくなっていきます。基本的なインフラは早めに整えておくに越したことはありません。むしろ今が一番楽に対応できるタイミングです。判明した課題について、以下の対応を実施しました。
- コストインパクトの大きい不要リソースの削除
- 環境別にAWSアカウントを作成 & IAM Identity Centerの有効化
- インフラのTerraform管理
取り組みと成果
コストインパクトの大きい不要リソースの削除
不要なリソースが多いことは最初の調査でわかっていたので、リソースを整理し、メンバーと合意の上で削除していきました。ここでは不要なリソースをすべて削除することにはこだわりませんでした。あくまでコストインパクトの大きいものに絞って削除していきました。
コスト管理については、私なりのやり方を以下の記事で紹介しているのでぜひ。
環境別にAWSアカウントを分離
私は本業ではメンバーの立ち位置でAWSを触ってきました。そのため、AWS OrganizationsやIAM Identity Centerの存在は知っていましたが、自分で使ったことがなかったので良い機会でした。
既にアカウントではAWS Organizationsが有効になっていたので、そこから新しくメンバーアカウントを作成しました。どのようにして環境別にリソースを分けるかを考え、以下の計画を立てました。
- 管理アカウント：既存のアカウントをそのまま流用。
- PRDアカウント：リソースを新しく構築する
- STGアカウント：リソースを新しく構築する
このアカウント分離で得られるメリットは主に2つです（細かく挙げればもっとありますが）。
- 検証時に本番環境に影響を与えない
- 管理アカウントにある不要なリソースを一掃できる
新しいアカウントですべてのシステムを一から構築することで、現行システムがどのように動いているかが明確になり、かつ管理アカウントにあるほぼすべてのリソースを一掃できると考えました。構築の際に不具合が出れば、それはシステムの考慮が漏れていたということで、むしろ良いことです。新しい環境ですべての機能を検証できれば、特に問題ないと判断しました。この移行についてはコンテナ技術の恩恵を大いに受けています。便利な世の中になりました、ありがとう。
リソースは現行のシステムを解析しながらTerraformで作成していきました。ほぼ全て順調にいっていましたが、一つ問題にぶつかりました。
AWS Amplifyのカスタムドメイン登録に敗北
移行に当たって、管理アカウントにあるドメインの移管も計画しました。DNS周りは不勉強だったため、調べながら進めていきました。移行先で新しくホストゾーンを作成し、DNSキャッシュのTTLに気をつけながら検証を実施しました。ALBでルーティングしているシステムについては問題なく移行できましたが、Amplifyのアプリケーションの再構築で失敗しました。
Amplifyについて軽く説明しておくと、Webやモバイルアプリを簡単に作ってAWS上で公開・運用できるフルスタック開発プラットフォームです。とても便利で、Amplify上でデプロイすると簡単にサイトを公開できます。デフォルトではAmplifyのドメインで公開されるため、カスタムドメインを追加することで自社のドメインでサイトを公開することができます。
このカスタムドメインの追加に問題がありました。移行元アカウントで設定が残っていると、移行先で同じドメインを追加できないのです。これにより、ドメイン及びホストゾーンを移管したとしても、移行先のAmplifyにルーティングすることができないので、サービスがダウンしてしまいます。
移行元アカウントで設定を消せば良いじゃないかという話になると思いますが、試みたものの解決しませんでした。どうやら、Amplifyは内部的にCloudFrontやS3を使っているらしく、そちらで設定が残っているのではないかと推測しています。一応、AWSサポートには問い合わせを行い、AWS側で対応していただくことで解消しました（対応内容は不明）。ベーシックプランのためか問い合わせから解消するまでに5日ほどかかりました。このあたりの移管をもし実施する場合は、AWSの担当の方に連絡を取ったほうが良いかもしれません。
正直、私はAmplifyの仕様をそこまで把握しきれていないため、理解に誤りがある可能性があります。その仕様についても改めて調査した上で、別の記事で詳しくまとめようと思います。
私は副業という関わり方のため、ここに多くの時間を割くことができませんでした。そこで今回は、当初の目的を優先して計画を変更することで対応しました。
計画変更
管理アカウントとPRDアカウントは統合し、STG環境の分だけアカウントを分けることにしました。AWS Organizationで組織の構成を変更すれば、当初の計画も遂行できたと思いますが、今回は工数の都合上見送りました。一部諦めてしまいましたが、当初の目的はある程度達成しました。
- 環境別にAWSアカウントを作成
- IAM Identity Centerの有効化
- インフラのTerraform管理
システムについては既存の構成に一部問題もあったため、やはり一から作り直すことにしました。システム移行は簡単で、新しくシステムを構築し、ルーティング先を切り替えるだけです。問題があれば向き先を戻すだけなので、切り戻しが可能です。
技術的な取り組み
Terraformで管理するなら、既存の環境をそのまま再現しても良かったのですが、設定が古かったり、ネットワークに問題がありました。せっかく再構築するなら、新機能やよくあるプラクティスを採用しようと考えました。
Regional NAT Gatewayを導入してみた
2025年11月19日、RegionalなNAT Gatewayがサポートされました。
従来はZonalなNATしかサポートしておらず、NAT Gateway用のパブリックサブネットを用意し、各AZごとにNAT Gatewayを作成する必要がありました。Regional NAT Gatewayはパブリックサブネットが不要で、リージョンレベルで可用性を持ちます。
注意点として、Internet Gatewayは作成する必要があります。また、紐づいたAZごとに課金されるため、Zonalな構成のときとコスト自体は変わりません。AWSリソースとして管理が簡単になったことと、AZ障害時の可用性が上がったことがメリットかなと思います。
また、執筆時点では、リリースしたばかりのためかコンソールからは設定できませんでした。AWS CLIやAWS SDK、AWS APIでしか作成できないようです。Terraform管理にしたことで、また一つ恩恵を受けることができました。
成果
まず単純にコストを大幅に削減することができました。詳細な数値は控えますが、コストを三分の一以下にし、私の時給分以上のコストを削減しています。
また、インフラをほぼ全てコード化し、IAM Identity Centerの権限設定により、このようなことが今後発生しないような再発防止策を実施できました。さらに、検証環境のアカウントを分離できたため、安心して開発することができるようになりました。
今回の経験を通じて考えたこと
ここまで技術的な取り組みを中心に書いてきましたが、今回の経験を通じて、スタートアップにおけるインフラのあり方について感じたことがあります。私は組織経営の経験はありませんが、一人のエンジニアとして、少しだけ考えを共有させてください。
スピードが命だ
スタートアップにとって最大の武器はスピードです。価値ある機能をいち早く形にし、顧客に届け、反応を得る。このサイクルをどれだけ速く回せるかが勝負になります。もっとも、開発の進め方を巡っては、経営の視点とエンジニアの考えがぶつかる場面も少なくありません。
エンジニアはどうしても技術的な完成度を追求したくなるものです。今回の取り組みにも、そうした私自身のこだわりが反映されている部分はあるでしょう。一方で経営層から見れば、「それよりもまずは機能を早く出してほしい」と感じるのも自然なことですし、その意見に私自身が同意する場面もあります。
それでも私は、インフラの整備とサービス開発のスピードはトレードオフではなく、両立できるものだと考えています。場当たり的に機能を継ぎ足していくやり方は、短期的には速く見えても、いずれ必ず足かせになります。トイルや技術的負債が積み重なり、気づいたときには、少し手を入れただけで思わぬところが壊れるシステムになってしまう。そうなれば、新しい価値を生み出すどころではありません。
だからこそ、開発の初期段階から、インフラやコードの土台をある程度整えておくことが重要です。完璧を目指す必要はありません。少ない労力で効果が大きいものから手を付ければよいのです。たとえば、環境ごとにAWSアカウントを分けるといった対応は、比較的簡単に導入できるうえ、ヒューマンエラーによる事故を大きく減らしてくれます。
こうした準備は、最初に少し手間をかけるだけで、その後の技術的負債の増加を抑え、結果として開発スピードを守ることにつながります。最初から“負債を生みにくいレール”を敷いておくことこそが、長く速く走り続けるための鍵なのだと考えます。
スタートアップは「とにかく安いシステム」を選ぶべきか？
企業ごとに事情は異なりますが、多くのスタートアップが資金面に制約を抱えているのは事実でしょう。AWSなどのクラウドでシステムを構築する際も、規模に関わらずコストは必ず検討事項になります。
クラウドの費用を考えると、「どの構成が安いのか」という議論になりがちです。大抵のサービスでは、マネージドサービスよりもセルフマネージドの方が、単純な利用料金は低く抑えられるケースが多いでしょう。では、コストだけを理由にセルフマネージドを選ぶのが正解でしょうか。
答えは組織の状況次第ですが、少人数のチームであれば、むしろマネージドサービスの方が適していると私は考えます。料金表だけを見ると割高に見えても、セルフマネージドを選べば、その運用・保守に人の時間と労力が必要になります。人員に余裕のある組織なら専任チームで対応できますが、スタートアップではその分だけ新しい機能開発や改善に使える時間が削られてしまいます。
目に見える月額コストだけでなく、運用にかかる人的コストや機会損失まで含めて考えたとき、本当に「安い」のはどちらでしょうか。総合的な視点で判断することが重要です。
さらに言えば、細かなサービス間の料金差を議論する前に、そもそも使われていないリソースが残っていないかを見直すべきです。不要なものを削除するだけで、大きくコストが下がることも少なくありません。数十ドルの差に頭を悩ませるより、「不要なリソースは消す」という基本を徹底することこそ、まず取り組むべきことだと私は思います。
今後
この取り組みを一過性のものにせず、将来にわたって価値あるものとして残していきたいと考えています。たとえ私自身が関わらなくなる時が来ても、周囲と力を合わせ、組織として自走できる体制と仕組みを築いていきます。経営視点と開発現場の双方を意識しながら、スピード感ある開発を継続し、必要なインフラを整備することで、事業の成長に貢献していく所存です。
Discussion