こんにちは、@ketancho です。
こちらの記事の初版は2018年に書いたのですが、ありがたいことに2025年現在も多くの方に読んでいただいています。私としてもとても気に入っている記事で、かつ「AWSを学ぶために最初に構築する」というテーマとしては、（少なくとも私は）陳腐化しておらず、今でも最初に試しておきたい構成かな？と思っています。
もちろん、他にも多々構成の選択肢を学ぶという意味で有意義な構成があると思うのですが、AWS 基本のキを抑えたい方がいたときに、私はこれらのアーキテクチャを構築してみるのはどうですか？とお伝えすると思います。
一方、AWS のアイコンが古くなっており、読みにくい部分も出てきたかなと思っており、リライトしてみることにしました。前述の通り、内容を大きくは変えていませんが、より読みやすい記事になっていればと願っております。
先日書いた AWS の勉強方法をまとめた記事（を最近リライトした記事がこちらです → AWSを学ぶ上でやってよかった勉強法６選（2025年最新版） - log4ketancho）で、「簡単な Web サービスを AWS 上で運営してみると、とてもいい勉強になる」と書きました。その記事について、
今まで経験したり今いるところはどこもオンプレばかりでAWSとかのクラウドの知識が全くつかないからどこかで勉強したいし個人サービス運用とかしたいんだけど、1年過ぎるといきなりコストがドカンとかかりそうで……
や
「２）簡単なWebサービスをAWSで運営する」は誰もが考えることだが、最初の無料期間1年間以外、AWSで個人ブログなりを運用するのはコスト悪すぎだろ…。
といった、利用料金が気になってしまう、、というコメントを幾つかいただきました。
個人で試す、という意味では、この気持ちとても分かるなーと思いながら読んでいました。業務で使う分にはインスタンスを何台立てようが気になりませんが（は言い過ぎですがｗ）、個人でサービスを運営する場合はそうはいきません。例えば、
t4g.nanoの Web サーバを2台- その 2台の Web サーバをぶら下げる ELB
- RDS は
db.t4g.microで Multi-AZ 構成 - 取得したドメインを Route 53 に登録してサービス公開だ！
とした場合、ざっくり計算で月々120ドル前後、150円ドル換算で2万円弱となります。
AWS の知識がつく、とはいえ、個人で毎月この費用を払い続けるのは（そのサービスでいい収益が生まれていれば別ですが）辛い、という方も多いでしょう。（私はそうです。）
では、先の記事で書いた「簡単なWebサービスをAWSで運営することで AWS の勉強をしよう」は難しいのでしょうか？決してそんなことはないと思います。前述の構成は、本番での可用性を意識した王道パターンです。その王道パターンを理解した上で、個人でサービスを展開する際には、特にその入口では、あえてコストを優先した構成でまずはサービス運用してみる、という選択肢もあるはずで、ほとんどお金を掛けずに AWS 上でご自身のサービスを運用も可能です。
そこでこの記事では、王道パターンからコスト優先パターンまで、5つのアーキテクチャを紹介しようと思います。また、それぞれのアーキテクチャを、私の独断と偏見で4つの軸で評価してみたいと思います。
- 技術獲得面：たくさんの技術要素を学べるかどうか。学べるものほど、★を多くします。
- 実用面：実務で使える可用性を担保したアーキテクチャかどうか。実務で採用できるものほど、★を多くします。
- 手早さ面：サービスインまでにどれくらいのリードタイムがかかるか。勉強しないといけないことが少ないほど、★を多くします。
- 費用面：月額のコストを安く抑えることができるか。安いほど、★を多くします。
こんな形で評価してみたいと思います。★が少ないからダメというわけではありません。「手早さ面」の場合は、じっくり勉強したい人にとっては★が低くても別に問題ないはずです。あくまで「自分の想いにあっているものはどれか」「初手としてまずは何をやろうかな」を考えるヒントになればという意図で、評価軸を作ってみました。
１）王道 Web パターン
まずは王道の ELB - EC2 - RDS パターンです。可用性も考えマルチ AZ にリソースをまたがって配置するなど、AWS のメリットを学ぶには基本的なアーキテクチャと言えると思います。最初にこの構成を作り、追加で静的コンテンツを S3 バケットから配信したり、ELB の前段に CloudFront を挟んでコンテンツキャッシュさせたり、NAT Gateway + Session Manager も併用することで EC2 インスタンスを Private Subnet 側に持っていったり、CI/CD パイプラインを作り Web サーバー用の EC2 に新しいソースコードをデプロイさせたりと、アドオンで様々な学びに繋げられると思います。
実務でもこのパターンが基本となるはずですので「実務に近いアーキテクチャを構築して勉強したい」という方がいたら、私はまずはこのパターンを作ってみては？と紹介すると思います。実際にサービス運用することで、運用してみて初めて得られる知見も見つかると思います。複数のサーバに分散してしまったログをどのように管理するか、サービスが正常に動いていることをどのように監視するかなど、実際に問題を経験→それをどう対応していくか、という試行錯誤自体に価値があると考えます。
コスト面については、前述の通り、それなりにかかってしまいます。このパターンを安価にするとしたら、例えば RDS の M-AZ 配置をやめて Single 構成にする、Web サーバを1台にするなどが挙げられます。可用性が下がる構成になることを受け入れた上で、まずは運用してみる、というのは実際に私も AWS を学びはじめのときのブログ運用でやった記憶がありますが、それはそれでいい勉強になりました。（よくサービスダウンしていた.. 後述します。）
手早さ面については、それなりに扱うサービスが多いので★３つとしていますが、これは技術獲得の裏返しですね。
なお、私が Udemy で講師を担当する「手を動かしながら2週間で学ぶ AWS 基本から応用まで」では、この王道 Web パターンの構成を作っていただきます。
加えて、Amazon CloudFront を使ってコンテンツキャッシュできるようにしたり、Code サービスを使った CI/CD パイプラインを作りこの王道構成にアプリケーションをデプロイしたり、といったこともお試しいただけます。もしご興味がある方は、こちらの記事もあわせてご覧ください。
２）シングル EC2 インスタンスでスモールサービス運用パターン
続いて１）の構成のミニマムパターンを紹介します。先ほど書きましたが、AWS を使い始めた頃、個人で学習するために最初に採用したアーキテクチャは、実はこれでした。サーバの上に WordPress をインストールし、MySQL を腹持ちさせ、ブログ運用していました。AWS の勉強方法記事で「簡単なWebサービスをAWSで運営するといい勉強になるよー」と書いたときも、まずはこのパターンでもいいので始めてみては？という意図でした。
当時は t2.nano がなかったため、t2.micro で運用していましたが月2,000円弱くらいの費用感だったと記憶しています。t2.nano であれば半分くらいになるでしょうか。このパターンでも十分勉強になります。何故か落ちる MySQL プロセスを監視するために CloudWatch Logs の設定をしたり、Python SDK（boto3）を使って日次で AMI を取るスクリプトを書いたりした記憶が懐かしいです。これらの経験は今でも血肉になってると思っています。
また、思い立ったらすぐに始められるのもいいと思います。なんせ EC2 と Route 53 の知識だけで（厳密には IAM や VPC などの知識も必要ですが）運用を開始できます。まずは作って、日々発生する様々な問題に対応する中でナレッジを貯め、十分収益性を得られるサービスになったら王道パターンに移るのもいいと思います。お、移行の練習もできますね。素晴らしい。
勉強にはなるものの、実務で Web サーバに DB を腹持ちさせることはまぁ少ないと思います。そういう意味で勉強できることの幅は少し狭まってしまうと言えるでしょう。（繰り返しますが、それでも勉強になることは非常に多いです。）また、費用が月1,000円から2,000円発生します。ブログを運用するだけであれば、他のサービスを使った方が安いことが多いでしょう。
３）ネイティブアプリ + サーバーレスAPIパターン
私は２）の方法で AWS を始めましたが、今はサーバーレスなアーキテクチャにチャレンジするのもいいでしょう。特に、ネイティブアプリは書けるけど、バックエンドの知見がない方にはこのパターンが向いているかもしれません。フロント部分はアプリに任せ、API 部分を AWS 側に構築するパターンです。API は API Gateway + Lambda + DynamoDB で構築し、API の利用制限をかけるために Cognito を利用します。サーバーレスな API アーキテクチャの王道パターンですので、非常に勉強になると思います。
AWS の利用料はこれまでの構成と比べると、非常に安価になると思います。リクエストの頻度やデータ量にも依存するので、特に公開直後、サービスがまだ多くの方には使われていないフェーズでは安価になることが多いでしょう。コスト面を★３つとしているのは、iOS のネイティブアプリをリリースするには年次で費用が必要だからです。
手早さ面を★２つとしているのは、冒頭に書いたようにネイティブアプリの知見がある人からすると問題ないのですが、そうでない方にとっては「AWS を使えるようになる」以上の技術取得が必要になるからです。もちろんエンジニアとして知見が増えるのは良いことですが、サービスローンチまでに時間がかかるという意味で★２つとしました。
４）サーバーレスSPAパターン + サーバーレスAPIパターン
続いて、フロントを SPA で提供するパターンです。私はこのパターンが大好きです。まさにこのパターンでプライベートでサービス開発しています。何と言っても費用面がお安いです。３）のパターンと異なり、年間の費用も発生しません。また、３）と同じ理由で実用面を★４つとしたものの、技術獲得面、実用面ともに良いナレッジが手に入ると思います。
手早さ面が少し低いのは、Vue.js や React といったフロントサイドのフレームワークの習得が必要だからです。３）と同じで、元々フロントサイドが得意で、AWS も得意になりたい方からすると、ここは問題ではないでしょう。
５）X ボット + サーバーレスパターン
最後に、X(旧 Twitter) をフロントのインターフェースとして利用するパターンです。ひとつ前の構成に書いたフロントエンドの習得（自体は素晴らしいことなのですが）にかかる工数を削減し、すぐに運用を開始することができます。
このパターンは個人的にとても好きで、下記の記事でシリーズにしているのであわせてご覧ください。
www.ketancho.net www.ketancho.net www.ketancho.net
こちらは AWS Lambda が主体となるアーキテクチャで、利用料金はほぼかかりませんし、簡単に構築することができます。他のリッチな構成と比べると、AWS サービスの一部しか触ることができませんが、例えば投稿する内容を Amazon DynamoDB に格納したり、AWS AI サービスと組み合わせてユニークな投稿にしたりと、工夫次第で様々な AWS サービスを利用いただけると思います。実務でこのような X(旧 Twitter) ボットを開発することは稀だと思いますが、この構成から得たナレッジは AWS Lambda や他の AWS サービスを使うシーンにおいて必ず役に立つと思います。（私は役立ちました！）
まとめ
「AWSを学ぶために最初に構築した」をテーマに５つアーキテクチャパターンを紹介しました。繰り返しになりますが、これらのパターンでないとダメ、というわけではなく、各パターンをベースに「勉強したいこと」「作りたいプロダクト要件」を鑑みてアレンジしていただければと思います。
例えば、最初は４）のフロント SPA パターンで安価に始め、プロダクトとして人気が出てきたり（≒インフラ投資できる収入を得られる）、現状のアーキテクチャでは作りにくい追加機能が出てきたりしたタイミングで１）の王道パターンに移行するというリアーキテクチャをしてもいいと思います。試行錯誤しながら得られた経験は、ずっと使えるスキルに繋がると考えています。
何からはじめようかな？と思われた方のアイデアの一助になっていれば幸いです。実際にものづくりする以外の AWS の勉強法については、こちらにも書いているので、あわせてご覧いただければ幸いです。
