はじめに

こんにちは！新卒一年目の関澤と福井です。

技術研修の一環として、AWS JumpStart 2026に参加してきました！この記事では、2日間のプログラム内容と、グループワークで設計したECサイトのアーキテクチャ、参加した感想を紹介します。

参加目的

参加前は、EC2やRDS、S3といったAWSサービスの名前や役割は知っていても、それらを実際のシステム要件に合わせてどう組み合わせればよいのかまでは、具体的にイメージできていませんでした。可用性・スケーラビリティ・セキュリティといった非機能要件を、どのようにアーキテクチャへ落とし込むのかを学びたいと考えていました。

AWSのサービスを個別に覚えることではなく、「どのような要件に対して、なぜその構成を選ぶのか」という判断基準を身につけるために、本イベントに参加しました。

AWS JumpStartとは

AWS初学者のエンジニアを対象とした実践的な研修プログラムです。事前学習と2日間の集中的なオンラインワークショップを通じて、AWSへの理解を深めます。単なるサービスの学習にとどまらず、要件に合わせてアーキテクチャを検討・設計するところまで行います。

本プログラムのゴール

• 一般的なリファレンスアーキテクチャの理解
• AWSのコアサービスの概要とその選定基準の理解
• AWSのアーキテクチャ図を作成するまでの流れを知る

実施日時

• 2026年6月4日（木）〜 6月5日（金）の2日間

使用ツール

• Discord / Zoom / Miro / ハンズオン用AWSアカウント

スケジュール

 

1日目

1日目は、フェーズに応じたアーキテクチャ設計の講義と、Webアプリケーションを構築するハンズオンを行いました。

午前

講義：1人から1000万人までのアーキテクティング

AWSソリューションアーキテクトの方より、Webアプリケーションをスケール（拡大）させていく際のアーキテクチャ設計について講義していただきました。サービスの利用ユーザーが数十人規模のプロトタイプから1000万人規模の大規模システムまで、フェーズや目的によって目指すべき構成が全く異なることを確認しました。

講義では以下のような利用ユーザー数に合わせたフェーズごと設計のポイントを学びました。

プロトタイプ期（- 100人）：限られたユーザーの利用が想定されるフェーズです。Amazon EC2 + Amazon RDS + Amazon Route 53のようなシンプルで安価な構成になります。この時点では、可用性・拡張性は考慮しません。

成長期（- 10,000人）：サービスを一般向けに公開するフェーズです（午後のハンズオンで扱う）。「障害は起きるものと考え、起きても止まらないように設計する」という Design for Failure の思想に基づき、単一障害点を排除します。具体的には、Webサーバーとデータベースを分離し、ALBで負荷分散しながら複数のAZに冗長化します。

拡大期（- 1,000,000人）：多数のユーザーが快適に利用できるように改善するフェーズです。Auto Scalingによるコスト最適化、Amazon ElastiCacheによるキャッシュ、計測・分析・改善のサイクルなどを導入します。

成熟期（それ以上）：さらに意識して計測・分析・改善のサイクルを回すフェーズです。可用性や拡張性が強く求められるのはもちろんのこと、組織や運用もスケールする設計が求められます。非同期処理化や、NoSQLの利用、運用オペレーションの自動化などの改善をし続ける必要があります。

午後

ナビゲータとドライバーに分かれて以下の構成を目指し、コンソール上でのハンズオンに取り組みました。

単に手順通りにリソースを作成するだけでなく、AWSコンソール上での操作に慣れることと、それぞれのサービスがなぜこの構成に含まれているのかを理解することを意識しました。

1. ALB(Application Load Balancer)

• インターネットからのリクエストを受け取り、複数のアプリケーション実行環境へ分散する役割を持ちます。
• 単一のサーバーに依存せず、障害時にも正常な環境へ通信を流すための構成であることを理解しました。

2. ECS + Fargate（Amazon ECS on Fargate）

• アプリケーションをコンテナとして実行する環境です。
• サーバー自体の管理を意識しすぎずに、アプリケーションを動かす仕組みを構築できる点を学びました。

3. RDS（Relational Database Service）

• アプリケーションのデータを管理するデータベースとして利用しました。
• アプリケーション層とデータベース層を分けることで、それぞれを独立して管理・拡張しやすくなることを理解しました。

 

2日目

アーキテクティング

1日目に学習した内容を振り返るためのクイズワークショップから始まり、提示されたシステム概要からAWS構成図を作成するアーキテクチャ検討ワークショップに取り組みました。

クイズワークショップではAWSコアサービスの特徴を理解できただけでなく、”想定しているユースケースごとにアーキテクチャの最適解が変わる、複数存在する”という重要な知見を得ることが出来ました。丁寧に解説をしていただいたおかげで回答として提示されたものがより適している理由、自分の回答が最適となるユースケースを理解することができました。

アーキテクチャ検討ワークショップではクイズワークショップで理解した”ユースケースごとにアーキテクチャの最適解は変わる”ことを意識して取り組みました。言い換えればアーキテクチャを考えるにはユースケース、機能要件・非機能要件を具体的に想定することから始める必要がありました。

午前中は個人でアーキテクチャを検討し、午後はチームメンバー(各チーム5人ほど)ですり合わせて一つの構成図を作成しました。

福井チーム

想定するユースケース・要件

• 対象: 国内ユーザー
• 負荷特性: 多数の同時アクセスに耐えうるトラフィック制御とオートスケーリング
• 構成要素:
  • 商品画像等の静的ファイルを大量に配信
  • 決済・配送・在庫管理は外部サービスと連携

工夫した点

1. 高可用性・冗長性の確保

• マルチAZの構成
  • VPC内に2つのAvailability Zone（AZ）を設け、Web/App層（Amazon ECS/Fargate）およびDB層（Amazon Aurora）を双方に分散配置することで、単一障害点を排除し、高い可用性と耐障害性を実現しています。
• データベースの読み書き分離と可用性向上
  • Amazon Auroraを採用し、片方のAZにWriter（書き込み）、もう片方のAZにReader（読み込み）を配置しています。
  • データのレプリケーションによる冗長性を確保するとともに、読み込み処理を分散してデータベース全体の負荷を軽減・高速化しています。

2. パフォーマンス最適化と負荷分散

• CloudFront × S3 によるキャッシュ・静的コンテンツの配信最適化
  • 静的コンテンツは Amazon S3 に格納し、前段に Amazon CloudFront を配置することで高速配信を実現すると同時に、オリジンサーバーへの直接的な負荷を大幅に削減しています。
• ALBによるアクセス分散
  • Application Load Balancer (ALB) を導入し、各AZに展開された Amazon ECS (Fargate) タスクへトラフィックを均等に分散。突発的なアクセス増加にも耐えうる構成としています。

3. セキュリティと認証の強化

• エッジセキュリティ（AWS WAF）
  • CloudFrontの前段に AWS WAF を設置し、Webアプリケーションへの不正アクセスや悪意ある攻撃（SQLインジェクションやXSS等）を最前線で防御します。
• 認証基盤の統合（Amazon Cognito）
  • ユーザーの認証・認可処理を Amazon Cognito に委任することで、安全かつスケーラブルなユーザー管理を実現しています。
• ネットワーク分離（Public / Private Subnet）
  • コンテナ（ECS）やデータベース（Aurora）などの主要リソースはすべてプライベートサブネット内に配置。インターネットからの直接アクセスを遮断し、NAT Gateway 経由で必要な外部通信のみを許可する堅牢な構成にしています。

改善点

• 現場・実運用における問題意識

  実際の障害ではAZが完全に停止するよりも「不安定に繋がり続ける状態（部分障害）」が発生しやすく、ALBでは2AZ構成の際に手動で切り離すことが不可能であるため、2AZ構成では障害AZにアクセスの半数が流れ続けてしまうリスクがある。3AZ構成にすることで手動での切り離しを可能にすると同時に影響を1/3に抑え、より堅牢な耐障害性を確保するようにすべき。

• ログ取得・監視基盤の拡充

  アクセスログやアプリログを取得・集約し、運用監視や監査ができる仕組みを導入する。

• セキュリティ対策の高度化

  脆弱性診断の導入や脅威検知など、セキュリティリスクへの継続的な対策の組み込み。

関澤チーム

想定するユースケース・要件

私たちのチームは「ユニコーン（本物）を売るECサイト」という空想的な設定で検討を進めました。アイデアを出してくれたのは、企画が得意な非エンジニアの方で、こういう突飛な設定でアーキテクチャを設計できるのはJumpStartならではでした。

最終的には、このテーマに「特定時間にアクセスが集中するECサイトを構築する」「顧客アカウントのセキュリティを厳重にする」といった各メンバーの要件をまとめて、可用性、セキュリティ、運用面などを重視したアーキテクチャを設計しました。

どう設計したか

設計した構成は、ユーザーのリクエストが上から下へ絞り込まれていく形です。リクエストの経路を辿りながら各構成要素の役割を紹介します。

• Amazon CloudFront + AWS WAF
  • ユーザーのリクエストが最初に到達するのは CloudFront です。ここに WAF をアタッチし、明らかに不正なリクエストを入口で遮断します。当初は WAF をどこに置くべきか迷ったのですが、攻撃をできるだけ手前で落とすほど後段への負荷が減ると整理できました。
  • WAF を通過したリクエストのうち、商品画像などの静的ファイルは、アプリケーションに届く前に CloudFront のキャッシュ、あるいは Amazon S3 から直接返します。静的なデータとアプリサーバーを切り分けることで、配信をエッジに寄せてオリジンの負荷を大きく削減できると気づきました。
• Application Load Balancer（ALB）+ AWS Fargate（ECS on Fargate）
  • 動的な処理は ALB を経由し、2つのAvailability Zoneに配置した Fargate のタスクへ振り分けられます。Fargateを選んだのは、サーバー自体の管理を抱え込まずに済み、アクセス増加に合わせて台数を伸ばしやすいためです。またALBについては、単なる負荷分散としてではなく「AZ障害が起きたときトラフィックをどう逃がすか」を考える起点として捉えるようになり、1日目に学んだDesign for Failureを自分たちの構成に落とし込めた実感がありました。
• データベース
  • ECサイトのデータは「読み書きが激しく、多少の遅延や反映の遅れを許容できるデータ」と「1件のずれも許されないデータ」に分かれます。1つのDBで両方を賄うと、どちらかの要件を犠牲にするため、性質ごとにストアを分けました。
    • Amazon DynamoDB：大量・高速アクセスが求められるキーバリュー型データ（カート・商品カタログ）
    • Amazon Aurora：整合性が重要なリレーショナルデータ（ユーザー・注文・支払い・在庫）
    • Amazon ElastiCache：セッション管理とキャッシュ。Auroraの読み込み負荷を軽減

工夫した点

• 可用性
  • 1つのリージョン内にAZを2つ設けるマルチAZ構成にし、リソースを両AZに分散配置しました。片方のAZに障害が発生してももう一方のAZで処理を継続できるようにし、単一障害点を排除することを目的としています。また全世界で使われるサービスのため、リージョンは最もアクセスの多い地域に置く想定です。
• セキュリティ
  • ログインや会員情報の扱いは Amazon Cognito に委ねています。「顧客アカウントのセキュリティを厳重にする」という要件に対して、認証を自前で実装するより、実績のあるマネージドサービスに任せるほうが安全だと判断しました。
• スケーラビリティ
  • アプリケーションがステートレスであることを目指しました。セッション情報などの状態を外部（ElastiCache）に保存しておけば、1つのタスクが落ちてもALBが正常なタスクへリクエストを流せるうえ、Auto Scalingでタスクを増減させても、どのタスクでも同じリクエストを処理できます。
  • Auto ScalingによりFargateタスクを自動で増減させ、特定時間の急激なアクセス集中に対応しました。
• 運用・ログ管理
  • ログ管理は演習中に追加要件として提示されたもので、 Amazon Bedrock に質問したり、他のベストプラクティスを参考にしたりしながら、見様見真似でアーキテクチャに組み込んでいます。
  • 最終的には Amazon CloudWatch でログを収集し、Lambdaで「異なるログフォーマットの変換」と「保存するログの取捨選択」を行い、S3へ格納する形にしました。さらにAuroraから QuickSight につなぎ、マーケティングチームが分析できる基盤も構成しています。

改善点

• アクセス集中への対応強化

  Auto Scalingのスケールアウトには数分かかるため、特定時間に集中するアクセスに対してはスケジュールドスケーリングによる事前のタスク増強を組み合わせるべきでした。また、スケールするのはFargateのみでボトルネックはDB側に移るため、そちらの対策も考えられたらよかったです。

• WAF配置の見直し

  今のWAFの配置だとALBへの直接アクセスを防げないので、セキュリティを重視するならCloudFrontとALBの両方にWAFを設定する、あるいは、ALB側でCloudFront経由のリクエストのみを受け付けるよう制限するべきでした。

感想

福井

私たちのグループにはAWSに詳しい方がいなかったので、各サービスについて調べ、不明点は運営の方々に質問しながらアーキテクチャを検討しました。そのおかげで、今まで曖昧にしたままだったAWSサービスの役割や使いどころを理解し、知識を定着させることができました。

特に印象に残ったのは、アーキテクチャ設計には決まった正解が1つあるわけではなく、想定するユースケースや重視する要件によって最適な構成が変わるという点です。可用性、アクセス集中への対応、セキュリティなど、何を重視するかによって選ぶべきサービスや構成の優先度が変わるため、まずは要件を具体的に考えることが重要だと感じました。

また、ALBやマルチAZ構成、CloudFront、S3などのサービスについても、単に名前や役割を覚えるのではなく、それぞれがどの課題を解決するために使われているのかを意識できるようになりました。改善点の検討では、2AZ構成であっても部分障害時には障害のあるAZにトラフィックが流れ続ける可能性があるなど、実運用で起こり得る障害パターンまで考慮する必要があることを学びました。

2日間と短いイベントでしたが、多くの学びがありました。今後AWSを利用したシステムや構成図を見る際には、「どの要件を満たすためにその構成になっているのか」「なぜそのサービスを選んでいるのか」を意識して見ていきたいです。また、今回の構成図に入れていないサービスについても調べ、実務でも活かせる知識として深めていきたいです。

関澤

2日間を通して知らないことだらけで、まさに調査の連続でした。それでも、調べた知識をすぐにハンズオンや設計課題で試せる流れになっていたため、AWSのサービスについてインプットとアウトプットを繰り返しながら学べる非常にいい機会になりました。

特に印象に残ったのは、システム停止に直結する「単一障害点」を排除する Design for Failure の設計思想です。1台のサーバーにすべてを集約する構成から始まり、Webサーバーとデータベースの分離、マルチAZ構成による冗長化へと、フェーズに応じて構成を進化させていく考え方はクラウドサービスならではでした。

また、チームでの設計や他チームの成果発表では、同じような要件に対しても様々なアーキテクティングの工夫があり、参考にしたい点が数多く見つかりました。目的やフェーズによって最適な構成は変わるという考え方は、今後の実務にも活かしていきたいです。