お店の成長とともに、AWS環境はどう拡大していくのか考えてみた

こんにちは！Koty-Mousa 矢坂幸太郎 です！

当記事はクラスメソッドの有志による『夏休みの自由研究リレー』 第11回のエントリです。
このブログリレーの企画は、普段からクラウドやAIを追いかけているメンバーによって、「やってみた」だけではなく「作ってみた」や「調査/研究してみた」もアウトプットしてみようという企画です。

新たな知見になることは勿論、アイデアを自社やコミュニティの発展に寄与できればと考えておりますので、お付き合い頂けますと幸いです。
今回の記事は『お店の成長とともに、AWS環境はどう拡大していくのか考えてみた』です！

まず、「AWS ビルディングブロック」とは

AWS には、ビルディングブロックという考え方があります。
ブロックを組んであそぶおもちゃのように、AWS 上の様々な機能を必要に応じて選び、組み合わせて使うことです。

AWS には、非常に多くのサービスがあります。
AWS をご利用いただくからといって、無理に全てのサービス使う必要はありません。
（正直、256個[1] のサービスを全部使う・覚えるのは無理があります）

[1] 【2026年】AWS全サービスまとめ | DevelopersIO
https://dev.classmethod.jp/articles/aws-summary-2026/

AWS を使う上で重要なことは、「必要に応じて、必要なサービスを選択する」ことです。
たくさん使ったほうが良いわけはありません。

AWS は、基本的に従量課金＝使ったぶんだけ支払いです。
EC2 は主に起動時間、 S3 は保存データ量と読み書き等に対して課金されます。
使わないサーバーのための料金を削減することができます。

一方、一部似ているような気がするサービスもあります。

例えば、S3 は便利なストレージサービスですが、EC2上の Windows/Linux がマウントして通常の SSD と同様に使用するには不向きですから、EBS を使います。
EC2 では、多様なインスタンスタイプを選択可能ですが、種類がありすぎて、簡単に選べないことがあります。

ご安心ください。AWS では、環境を作って・試して・削除する ことが極めて簡単に実施可能です！
まるで、良い形のブロックが仕上がるまで組んで外すことを繰り返すように、様々なサービスを試すことができます！

事業拡大に AWS は伴走する

そして、この「ビルディングブロック」は、組み替えることができる他にも大きな特徴があります。
それは、システム全体を大きくしたり、小さくしたりすることが簡単にできることです！

例えば、最初は単なるホームページのみを作ったとして、後から…

「問い合わせフォームを付けたい」 → Lambda と SES を足す
「商品を検索できるようにしたい」 → RDS を足す
「アクセスが100倍になった」 → ALB の後ろに EC2 を並べ、Auto Scaling を設定する
「画像の表示を速くしたい」 → CloudFront を前に置く
「海外からも見られるようになった」 → リージョンを追加する

重要な点として、これらは「作り直し」ではないということです。
既にあるブロックはそのまま残し、必要なブロックを足す・入れ替えるだけです。
ビジネスの拡大に応じて、AWS システムを拡大することができるのです！

こんな感じで拡大しそう！

今回は、架空の企業を考え、実際にどのように AWS システムが拡大できるか考え、
実際に AWS 環境にてそれを作ってみました！

今回は、架空のドーナツ店が成長する様子に合わせて、AWS がどのように使われるか考えてみましょう！

今のドーナツ店は、このような状況です

• レジはオンプレミス、A県内に本店と支店が1つある
• ポイントカードシステムとホームページは、どちらも本店内に置いてある同じコンピュータ/ワークステーションで動いている
• 最近、コンピュータがフリーズしてしまい、ポイントを後日付与対応することが増え、現場の負担になっている
• 海外の旅行サイトに掲載されたが、海外客がホームページへアクセスした際、読み込みが遅すぎると言われた
• 最近、SNS で店が人気になってきているが、アクセスが増えると同じコンピュータで動いている Webサーバーが重くなり、時折 停止することがある
• 予約注文を本店で電話を一括して受けているが、電話対応が現場の負担になっており、ドーナツは作れるが予約を受けられない状況。

まずはホームページを整えよう！

上記の状況では、本店のコンピュータが単一障害点になっています。
そのため、まずはホームページから対応しましょう！

CloudFront と S3 を利用すれば、Webページを公開できます。

CloudFront は 世界中（国内含む）のエッジロケーションを使用します。
つまり、なるべく近所のサーバーから文字や画像をダウンロードします。

近年は光回線等の通信速度が速くなっておりますが、近くからダウンロードすることは速度向上において とても重要です。

これにより、日本中はもちろん世界中のお客様が快適にホームページをチェックできるようになります。
また、S3 は「ストレージ」、つまりデータを保存しているだけなので、そもそもサーバーというものが存在せず、フリーズや再起動という概念自体がありません。
CloudFront は世界中にホームページを配信するシステムですが、AWS が管理するマネージドサービスなので、ドーナツ店がフリーズを心配する必要はありません。

設計図上は非常に簡単な構成に見えますが、これだけでも AWS のメリットを存分に享受できています！

実際にデプロイしてみました！

おいしそうなドーナツ店の ホームページ です。読み込み速度も問題ありません！

※余談ですが、右の白ドーナツ、Claude Code（Sonnet 5）から『これはドーナツ型の座布団（円座クッション）の画像で、食べ物ではありません。』と言われました。
よく気がついたなと思います。すごいです。

予約をネットで受付できるように！

お客様から「予約電話がつながらない」という意見を多くもらうようになってきています。
ドーナツ作りには十分余裕があるため、この状況は機会損失につながっています。

それでは、AWS のサーバレスサービスを組み合わせて実装してみましょう！

予約サイト自体はさきほどの　S3 に追加します。
お客様はサイトから名前やメールアドレスを入力し、「送信」ボタンを押すことで、API Gateway → Lambda が処理を行い、DynamoDB に保存されます。
注文が完了したら、入力したメールアドレスに SES を使って確認のメールを送信します。

店舗に設置したタブレットで注文状況を確認できるようにします。
今回はまだ店舗が少ないため、ポーリング方式で作ります。もしこの仕様に問題が出てきたら、AWS なら今後の店舗拡大時に仕様を変更できます。

タブレットに表示している S3 + CloudFront でのページから、API Gateway にポーリング取得を行います。
API Gateway が Lambda にアクセスし、DynamoDB の情報を読み出し、表示する内容を読み出します。

また、店舗ごとのタブレットは、Cognito によって認証を行います。

構成図が一気に増えましたね！機能はかなり拡大しましたが、ホームページだけの時と同じ AWS 環境内で実現できています！

上の通り、ホームページに予約欄が追加され、ここで予約した内容が、店舗タブレット用画面に表示されています！

※あれ？ くらにゃん が予約している...？

なぜ、Cognito を採用したのか

正直なところ、現在の店舗数だけを見れば、Cognito を使用することは過剰である可能性があります。
しかしながら、タブレット内に固定のクレデンシャル（API Key など）を保存する方式は、万が一クライアント側のコードから漏洩した場合のリスクや、店舗が増えた際のスケーラビリティの観点からも厳しい点があります。

氏名や電話番号といった個人情報を扱うシステムである以上、AWS も謳う「セキュリティは最優先事項」という考え方に倣い、多少実装の手間が増えても、Cognito によるしっかりとした認証を採用することにしました。

不正アクセスが発生？

予約サイトを公開してしばらく経つと、タブレットに数千件を超える注文が数分のうちに入ってきました。
しかも、ドーナツを数百個注文するようなものばかりです！

調査してみると、どうやら Bot による大量アクセスが原因のようです。
今回の予約フォームは、お客様が気軽に予約できるよう、あえて認証なしで誰でも送信できる作りにしていました。
そのため、悪意のある第三者が API Gateway のエンドポイントに対して大量のリクエストを送りつけ、予約データベースを不正な情報で埋め尽くしてしまったのです。

かといって、お客様向けの入り口にまで認証を必須にしてしまうと、先述の「電話が繋がらず予約しづらい」という課題の解決になりません。
そこで、「誰でも予約できる」という利便性は保ちつつ、Bot による大量アクセスだけを防ぐため、AWS WAF（Web Application Firewall）を追加します！

WAF は、API Gateway や CloudFront の手前に設置して、リクエストの中身を検査してくれる、いわば「門番」のようなサービスです。
あらかじめルールを設定しておくことで、怪しいリクエストだけを弾き、正常なお客様のアクセスはそのまま通すことができます。

今回は、以下の2つのルールを組み合わせることにしました。

• レート制限ルール：同じ IP アドレスから、短時間に大量のリクエストが来た場合にブロックする
• AWS マネージドルール（Bot Control）：AWS があらかじめ用意している、Bot 特有のアクセスパターンを検知するルールセットを利用する

自前で「怪しいアクセスとは何か」を1から定義し、新たな脅威に対応し続けることは大変ですが、マネージドルールを使えば、AWS が日々更新している知見をそのまま活用できます。
これも、AWS のビルディングブロックらしい考え方だと言えそうです。

WAF を導入した結果、Bot からの大量アクセスはブロックされるようになり、不審な予約データも収まりました。
もちろん、WAF を導入したからといって100%安心というわけではありませんが、少なくとも今回のような単純な大量アクセスに対しては、十分な効果を発揮してくれています。

WAF だけでは防げない問題

実は、WAF を導入しても解決できない問題があります。

お客様がメールアドレスを入力し間違えてしまった場合、あるいは悪意を持って第三者のメールアドレスを入力されてしまった場合、その見知らぬ方に予約確認メールが届いてしまうという問題です。

これはフォームを広く受け付ける以上、正直防ぎようがなく、それ自体は正常なリクエストのため、WAF のレート制限や Bot Control では検知できません。

繰り返し発生すると、送信先での迷惑メール判定（バウンス）が増え、最悪の場合 SES の送信自体が制限されてしまう可能性もあります。SES 自体にも、バウンスや苦情の発生を通知する仕組みはありますが、これはあくまで事後に異常へ気づくための仕組みであり、間違った宛先への送信そのものを防ぐものではありません。

この対策として、入力されたメールアドレス宛に確認リンクを送り、お客様自身がクリックするまで登録や予約を確定させない「ダブルオプトイン」という方式があります。

また、現実的にはお客様にも会員登録を求めるなどの対応も検討が必要です。
この場合は、Cognito を用いることで、「ソーシャルログイン」などを導入し、お客様の負担を減らすこともできます。

ポイントカードシステムをクラウドに！

さて、ホームページのシステムは本店のPCから AWS に移行しましたが、ポイントカードのシステムがまだ残っています。

このシステムは、各店舗のポイントカード端末（支店は本店PCにインターネット経由のVPNで接続）から、この Windows PC 上で動くソフトウェアに通信し、同じ本店 PC 上にて動作する PostgreSQL のデータを更新しています。

これも、長時間PCを起動させないといけないため、時折フリーズが発生し、現場でポイント付与ができないことが時折発生しております。
フリーズが発生したら、担当者が PC のところに行って、なんとかして動くようにしています。
IT 担当が休みの場合、他の社員が再起動なら可能ですが、無理な強制終了によってデータベースの不整合が発生した場合など、対応ができず、数日にわたりポイントカードシステムが停止してしまったこともありました。

今回は、EC2 を利用します。
これはコンピュートサービスであり、Windows や Linux 各種OS を動作させることができます。

1台の EC2 を起動して実行することも可能ですが、何らかの原因でフリーズ等が発生した場合、結局 AWS コンソールを手で操作しなければいけません。
そのため、今回は NLB + Auto Scaling の構成を導入します！

今回、各店のポイントカード端末との通信は VPN 経由で行いますので、AWS 側にも Site-to-Site VPN を設置し、VPC 内の NLB に接続できるようにします。

つまり、各店舗から見ると「本店の PC に繋がっていたのが、AWS 上の NLB に繋がるようになった」だけで、VPN 経由で接続するという操作自体は変わりません。
そのため、店舗側の運用を大きく変える必要がなく、移行の負担を抑えられます。

まとめると、今回のポイントカードシステムの構成は以下のようになります。

• 各店舗のポイントカード端末 → Site-to-Site VPN → NLB → EC2（Auto Scaling） → RDS for PostgreSQL

これにより、これまで本店の PC 1台に依存していた仕組みが、AWS のマネージドサービスと複数台構成に置き換わりました。
仮に EC2 が1台フリーズしても、NLB のヘルスチェックによって自動的に切り離され、Auto Scaling が新しいインスタンスを立ち上げてくれます。
また、データベースも RDS に切り出したことで、アプリケーションのフリーズがデータの不整合に直結する心配もなくなりました。

なお、EC2 は複数の アベイラビリティゾーン（データセンター）に分けて配置し、RDS も Multi-AZ 構成にしています。同じ場所に固めてしまうと、結局そこが単一障害点になってしまうためです。

なお、店舗ごとに VPN ルーターを用意し、AWS 側と Site-to-Site VPN で接続するこの構成は、店舗数が少ないうちは問題ありませんが、店舗数が増えるほど、VPN 機器の調達や設定の手間が増えていくという点があります。

そのため、既存の本店・支店については今回の構成のまま維持しつつ、今後新しく出店する店舗については、VPN 機器を用意せず、新しい端末から API Gateway 経由で直接通信する構成を取ると、導入が簡単になると考えました。
古い端末をすぐに入れ替える必要はなく、既存店舗のブロックはそのまま残し、新しいブロックを別の形で足すだけです。

まとめ

ここまで、架空のドーナツ店を例に、事業の成長に AWS がどう伴走できるかを見てきました。

様々な課題がありましたが、どの課題に対しても、変える必要のない部分は変えずに、必要なブロックをひとつずつ足していくことで、事業の成長スピードを止めずにシステムを拡大できることが確認できました！
また、AWS WAF のように、安全性を高める機能も数多く搭載されております。適切に利用して、よりセキュアな環境をつくりましょう！

ここまで、『夏休みの自由研究リレー』の第11回のエントリ『企業の成長とともに、AWS環境はどう拡大していくのか考えてみた』でした。

次回は千葉 幸宏（チバユキ）さんの IAM に関する記事の予定です。
どんな記事なのか、たのしみです！

そういえば、私が現在のクラスメソッドオペレーションズにやってくる前、チバユキさんの IAM 記事をよく読んでいたことを思い出しました。
そして、チバユキさんのような記事が書きたいと思っておりました。

良い記事をかけるようこれからも頑張ってまいります！

以上、Koty-Mousa 矢坂幸太郎 がお伝えしました！

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。

運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。

当社は様々な職種でメンバーを募集しています。

「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 採用サイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました