常時稼働のサーバーをやめて、クラウド費用を約 70% 削減（月換算の見込み）した話：自社 Web サービスの Cloud Run 移行記録

ソラナリンク株式会社では 2026 年 10 月初旬、自社のコーポレートサイトを含む数個の Web サービスを、AWS の常時稼働サーバー（EC2）から Google Cloud の Cloud Run（東京リージョン）へ移行しました。あわせてデータベースも、サーバーレス型の TiDB Cloud Starter に切り替えています。

この記事では、移行をどう評価し、どうリスクを抑え、費用がおよそどれだけ下がったのかを、できるだけ具体的に書きます。ご自身の会社に合う話かどうかを判断する材料にしていただければ幸いです。

1. 背景：中小企業が EC2 を常時稼働させるコスト構造の問題

EC2 は、AWS が提供する仮想サーバーです。自分専用のパソコンをクラウド上に借りているようなもので、電源を入れている間はアクセスがあってもなくても料金が発生します。

中小企業の Web サービスでは、次のような状況がよくあります。

• アクセスは営業時間帯に集中し、夜間や休日はほとんどない。それでもサーバーは 24 時間動いている。
• サーバー本体の費用に加えて、ロードバランサー（アクセスを振り分ける装置）、ストレージ、ネットワーク、ログの費用が毎月ほぼ固定でかかる。
• OS の更新、セキュリティパッチ、ディスク容量の管理、データベースの運用といった保守作業が、ひとり情シスや開発担当者に集中する。
• 1 台のサーバーに複数のサービスを同居させるため、どのサービスがいくら使っているのか分かりにくい。

当社も同じ構造でした。結論を先に書くと、自社サービス分の費用は、月換算で約 70% 下がる見込みです。Google Cloud の実際の請求データが届くまで、移行後側の一部は見積りを含みます。特に、1 台のサーバーに複数のサービスが同居していたため、一部だけを移しても AWS の請求はほとんど減りません。サーバーとロードバランサーを止められて初めて、費用が大きく下がります。事前の評価でもこの点を確認し、「最終的にサーバーを止める」ことを目標に置きました。

2. 棚卸しと技術評価：Cloud Run への適合チェック

Cloud Run は、コンテナ（アプリケーションと実行環境をひとまとめにした箱）を、リクエストが来たときだけ動かすサービスです。アクセスがなければ 0 台まで縮み、使った分だけ課金されます（使った分だけ払う、いわゆる従量課金です）。ただし、どんなアプリでもそのまま動くわけではないため、まず次の観点で一つずつ確認しました。

もう一つ、見落としがちな点がありました。棚卸しの過程で、以前の構成で定期実行になっていたはずの処理が、設定の不備により実際には動いていなかったことが分かりました。移行は、こうした「動いているつもりの処理」を洗い出す良い機会にもなります。

移行しなかったもの、その理由

すべてを Google Cloud に寄せたわけではありません。次のものは AWS に残しました。

• DNS（Route 53）：ドメインの名前解決です。移すメリットが小さい一方、誤ると会社のサイトとメールが同時に止まるため、触らない判断をしました。
• メール送信（SES）：送信実績に基づく信頼性（送信元としての評判）が蓄積されており、認証の設定も済んでいます。移す理由がありませんでした。
• 画像などの静的ファイルの保管と配信：すでに安定して動いており、移しても費用の削減につながらないため、そのままにしています。
• CDN（配信の高速化の仕組み）：今回の移行では、Cloud Run の前段に置く構成にしました。HTTPS の証明書を事前に発行でき、切り替え時の中断を避けられるためです。

また、データベースについては当初、Cloud SQL（Google Cloud のマネージド MySQL）を選ぶ予定でした。しかし月額の固定費が発生することから、費用を優先して TiDB Cloud Starter を検証し、採用しました。一部の機能（日本語を含む全文検索）は MySQL と方式が異なるため、検索処理を書き換える必要がありました。検証では、MySQL と同じデータを両方に読み込ませて比較しました。調べた記事のタイトルやキーワードで検索して、結果に正しく出るかどうかは同等でした。順位づけは一致しないため、切り替え後に実際の問い合わせ内容で確認するとしています。

3. 移行後のアーキテクチャ

Before（移行前）

移行前の構成：24 時間稼働の EC2 サーバー 1 台に、複数のサービスが同居

After（移行後）

移行後の構成：アプリは Cloud Run、DB は TiDB Cloud Starter。DNS とメールは AWS に残す

「適材適所」で分担した理由

今回の構成は、Google Cloud と AWS のどちらかを選んだ結果ではなく、役割ごとに最適な場所に置いた結果です。

• アプリの実行は Cloud Run：使った分だけの課金で、アクセスが少ないサービスと相性が良いからです。
• DNS は Route 53：安定して動いており、長年の運用実績があります。切り替えの手順（TTL の調整やロールバック）も、レコードを書き換えるだけで済みます。
• メールは SES：送信の設定と評判をそのまま引き継げます。

AWS が高いから移した、という話ではありません。EC2 を「24 時間止めずに借り続ける」使い方が、当社のアクセス量に合っていなかったのです。AWS には、今回のように必要な部分を使い続けられる強みがあります。クラウドを一つに統一することよりも、役割ごとに分けるほうが、費用と安全性の両面で有利でした。

4. データのバックアップ

何を、どうバックアップしたか

• 移行前：切り替えの直前に、本番データベースのダンプ（全データを書き出したファイル）を取得しました。データ量は小さく、圧縮後で数 MB 程度です。
• 移行時の確認：ダンプを TiDB に読み込み、全テーブルの行数が元と一致することを確認しました。切り替え直前にもう一度、最新データを取り直して読み込み、同じ確認をしました。主要なテーブルの内容照合（チェックサム）でも一致を確認しています。このとき、新旧のあいだに入った閲覧記録が 1 件だけ差異として出ましたが、想定内の差です。
• 移行後：TiDB Cloud Starter の自動バックアップ（1 日 1 回）を使います。保持期間は管理画面で 14 日と確認しました。
• 旧環境のデータ：旧環境が停止するまでのあいだ、データベースのデータを残して保管しました。さらに、切り替え前に取得したダンプを手元にも保管しています。

リストア検証をしたか

• 切り替え前のダンプを、別のデータベース（検証用）に読み込んで内容を確認する「ダンプからの復元」は実施済みです。上記の行数照合と検索結果の比較が、その記録です。
• 一方、TiDB の自動バックアップから実際に復元する演習は、まだ実施していません。

また、次の制約も把握しています。

• Starter には時点指定の復元（特定の時刻に巻き戻す機能）がなく、復元すると新しいクラスターが作られます。
• 別の保管先に毎晩エクスポートする案もありましたが、費用を抑えるため見送りました。自動バックアップが唯一のバックアップです。
• 旧環境を停止したあとは、旧環境に戻る手段がなくなります。バックアップの重要性は、移行後にむしろ高まります。

自社の事例からの教訓として、「バックアップは、復元して初めて使えるものになる」という点を挙げておきます。移行後の復元演習の実施は、今後の課題です。

5. 並行稼働

旧環境（EC2）と新環境（Cloud Run）を、切り替えの前後で同時に動かしました。期間は 2026 年 10 月 3 日から 4 日までです。旧環境のサーバーは 10 月 4 日の夜に停止しました。AWS の日次の請求データでも、5 日以降はサーバーとロードバランサーの費用が発生していないことを確認しています。

この期間にやったことは次のとおりです。

1. 切り替え前の事前検証：公開用の DNS を変えないまま、新環境に直接アクセスさせて動作を確認しました（手元の端末だけ、名前解決を新環境に向けて確認する方法です）。
2. データの最終同期：切り替えの直前に、旧データベースの最新の内容を新環境に取り込みました。取り込みは数十秒で終わり、全テーブルの行数が一致することを確認しています。
3. 切り替え後の確認：公開 URL の全ページが正常に応答するか、ログインの戻り先アドレスが正しいか、HTTP から HTTPS への転送、サーバーエラーの有無などを、複数回繰り返して確認しました。新環境に入った直後は、旧データベースに新しい書き込みがないことも確認しています。
4. 書き込みの空白への備え：データの同期から DNS の切り替えが全員に行き渡るまでの 1〜2 分程度は、旧環境に書き込まれる可能性があります。件数が少ないことは事前に確認し、切り替え後に旧データベースを見て、あれば手で入力し直す手順にしました。
5. 利用者としての確認：担当者が本番環境で実際に操作して確認しました。
   • ログイン：切り替え当日の朝、Google アカウントでのログインと 2 段階認証が正常に動くことを確認しました。
   • 問い合わせフォーム：確認の過程で、移行前からあった不具合が見つかり、当日中に修正しました。切り替え後の確認は、移行そのものの検証だけでなく、以前からある問題を見つける機会にもなります。

旧環境は切り替え後およそ 1 日待機させ、いつでも戻せる状態にしておきました。なお、実際にユーザーのアクセスを両方の環境で同時に受け付けた期間はなく、「新環境で検証してから切り替え、旧環境を待機させる」形です。

6. DNS 切り替え

DNS は「ドメイン名とサーバーの住所を対応づける仕組み」です。切り替えでは、住所の書き換えが世界中に行き渡るまでの時間をどう短くするかが焦点になります。

1. TTL を事前に下げる：TTL は、DNS の回答を他のサーバーが覚えておく時間です。切り替えの 1 時間以上前に、www のレコードの TTL を 3,600 秒から 60 秒に下げました。ルートドメイン（www なし）は Route 53 のエイリアスレコードで、TTL はもともと 60 秒に固定されています。古い回答の保持期限がすべて切れる時刻を計算してから切り替えたので、切り替え後の反映は数分で済みました。
2. 証明書を先に発行する：HTTPS の証明書は、切り替えの前に発行を済ませました。そのため、HTTPS が使えない時間はありません。別のサービスで試した「Cloud Run のドメインマッピング」という方法では、証明書の発行と伝播で約 25 分の中断が出たため、正式サイトではこの方法を選びませんでした。
3. CAA レコードの確認：CAA は、どの認証局に証明書の発行を許可するかを示す DNS レコードです。当社のドメインには CAA レコードを設定していないため、証明書の発行が CAA で止められることはありません。CAA を設定している場合は、新しい環境で使う認証局を許可リストに加えておく必要があります。
4. メール関連のレコードには触れない：MX、SPF、DKIM、DMARC などのメール関連と、各種ドメイン所有の確認用レコードは、いっさい変更しませんでした。変更するのは、Web サイトの表示に使う 2 つのレコードだけです。これにより、メールの送受信への影響を避けました。
5. ロールバック手順：問題があれば、2 つのレコードを元の宛先に戻します。TTL が 60 秒なので、およそ 1 分で反映されます。Cloud Run 側だけの問題であれば、直前の版（リビジョン）にトラフィックを戻すコマンド 1 つで済みます。ただし、切り替え後に新しいデータベースへ書き込まれたデータは旧データベースにはないため、実際の利用者がついた後で戻す場合は、先にデータを書き出す必要があります。
6. 切り替え後：安定して 1 日ほど経ったら、TTL を元の値に戻し、旧環境を停止します。共用していたロードバランサーなどは、その時点では削除せず、対象のサービスの分だけを外す計画でした。現在、www の TTL は元の値（3,600 秒）に戻っています。

7. 結果

費用

自社サービス分で 約 70% 削減（月換算の見込み） でした。Google Cloud の実際の請求データで確定するまで、移行後側の一部は見積りを含みます。

比較の条件は次のとおりです。

• 移行前：移行前で最後のまる 1 か月分の請求である 2026 年 9 月の、AWS の請求のうち、計算資源・ロードバランサー・ストレージ・通信・ログに当たる費用のうち、自社サービス分。
• 移行後：2026 年 10 月の実績ペースを 1 か月に換算した金額のうち、自社サービス分。Google Cloud の費用と、マネージドデータベースの費用を含めています。AWS では動いていなかった自社サービスの費用も入れているため、あえて厳しめの比較です。
• Route 53 と SES は AWS に残したので、移行前・移行後のどちらにも含めていません。
• 通貨と為替レートは、全体を通じて 1 つに統一しています。
• 自社サービス分の出し方：移行前は 1 台のサーバーとロードバランサーを複数のサービスで共有しており、請求をサービスごとに分けられません。そのため、移行前の費用はサービスの数で均等に按分しました。各サービスが実際にどれだけ使っていたかは分からないため、この按分は仮定であり、削減率は按分の仕方によって上下します。

移行後はまだ満 1 か月の請求がそろっていないため、「月換算の見込み」としています。まる 1 か月分の数字が出た時点で、この記事を更新します。

Cloud Run には無料枠があり、移行後の費用を押し下げています。無料枠がなかったと仮定すると、削減率は数ポイント下がり、7 割弱になる見込みです。

月額費用の指数（自社サービス分）：移行前 100、移行後 30（月換算の見込み）

運用面の変化

• OS のパッチ当てが不要になった：サーバーの OS やミドルウェアの更新は、Google 側が担当します。
• デプロイ（公開）がやさしくなった：以前は本番サーバー上でビルドしていたため、ビルド中に応答が数秒遅くなり、公開のたびに 9 秒ほど中断がありました。移行後は、新しい版を起動してから切り替えるので、中断がありません。
• ロールバックが 1 コマンドになった。
• 定期実行が、決めた時間どおりに動くようになった。
• サーバーの台数管理がなくなった。ディスク容量の監視や増設も不要です。
• 機密情報を専用の保管庫（Secret Manager）で管理できるようになりました。

トレードオフ

• コールドスタート：しばらくアクセスがないと台数が 0 になるため、その後の最初のアクセスは遅くなります。当社の計測では、アイドル後の初回表示で約 5 秒、その後は 0.2 秒前後でした。サービスによっては 10 秒を超える見込みのものもありました。ほとんどの時間は、データベースへの最初の接続（暗号化の手続き）に使われています。対策として、常に 1 台を待機させる設定があり、固定費が追加で発生します。審査や商談のデモの日だけ一時的に使う運用もあります。
• 従量課金の読みにくさ：サーバーレス型のデータベースは、読み書きの量に応じて課金されます。当社では、死活監視のアクセスが想定以上にデータベースへの問い合わせを増やし、利用量の大半を占めていました。月額の上限を設定しておくことは重要ですが、上限に達するとそのデータベースは新しい接続を受け付けなくなるため、上限の値と監視の方法は、セットで設計する必要があります。
• 単一インスタンスへの制約：当社は、キャッシュ用のサーバーを使わずにプロセス内で代替し、最大 1 台で動かす構成を選びました。流量が少ないサービスなら問題ありませんが、台数を増やして対応する形には向きません。
• 移行作業そのもの：コードの修正（応答後の処理、ログの形式、データベースの接続設定、検索処理の書き換え）が必要でした。
• 旧環境に戻れなくなる：旧環境を止めたあとは、バックアップが頼りです。

8. セルフチェックリスト：この移行は自社に向いているか

向いている企業

• アクセス量が少ない、または時間帯・曜日による波が大きい。
• いまのサーバー（EC2 など）の費用の大半が、固定的な費用である。
• 1 台のサーバーに同居するサービスを、まとめて移して旧サーバーを止められる。
• アプリがコンテナ化できる、またはすでにコンテナで動いている。
• パスワードや API キーなどの機密情報を、コンテナイメージに含めず、専用の保管庫から実行時に渡す形にできる。
• 自社に保守担当者が少なく、OS の更新やサーバー監視の手間を減らしたい。
• 数秒のコールドスタートが許容できる、または常時 1 台を待機させる費用を払える。
• 切り替え後にデータをバックアップし、復元を試すところまで運用に組み込める。

向いていない（または慎重に検討したほうがよい）企業

• 常時つながる通信（WebSocket など）が中心で、接続時間に応じて課金が膨らむ。
• 24 時間安定して大量のアクセスがある。常時稼働のほうが割安になることがある。
• アプリがサーバー内のファイルやメモリに状態を持っていて、作り直しが難しい。
• 応答後に続く処理や、常駐プログラムに依存している。
• データベースが特定の MySQL 機能に強く依存している（TiDB では互換性の確認が必要）。
• 切り替え後に旧環境へ戻る手段を残せない、かつバックアップの運用も整っていない。
• 使っている AWS のサービス同士の結びつきが強く、1 つだけ切り出せない。

1 つでも不安な項目があれば、移行の前に費用診断で全体像を整理することをおすすめします。

9. 次回予告

次回は、複数の TiDB インスタンスを 1 つの Cloud SQL に統合すべきかを評価し、実践した内容をお伝えします。インスタンスを減らすと、管理の手間は減る可能性があります。一方で、料金体系が変わり、障害時の影響範囲が広がることもあります。統合が正解とは限りません。メリットとデメリットを中立に整理し、結果をそのまま書く予定です。なお、費用が下がることをお約束するものではありません。

10. お問い合わせ

ソラナリンク株式会社では、中小企業向けに「クラウド費用診断」をご提供する準備を進めています。現在の構成と請求の内訳を整理し、移行が向くか、どこまで移すか、リスクはどこにあるかを、一緒に確認します。

ご相談は、公式サイトのお問い合わせページからどうぞ。

• お問い合わせページ

---

ソラナリンク株式会社（執筆：Tony Cai）

免責：本記事の数値は当社の事例であり、効果は環境により異なります。費用の削減率は自社サービス分の数値で、2026 年 10 月時点の実績ペースを月換算した見込みです。移行前の費用はサービスの数で按分しています。満 1 か月分の請求が確定した時点で更新します。