【参加レポ】AWS JumpStart 2026に参加しました!
みなさん、こんにちは!2年目エンジニアの山谷です。
先日「AWS JumpStart 2026」というAWS主催の2日間のオンラインイベントに参加してきました。
https://aws.amazon.com/jp/blogs/news/aws-jumpstart-2026/
普段の業務でAWSに触る機会はあるものの、自分の手でゼロから組み立てる経験は意外と少なく、社内の先輩から「行ってきたら?」と勧めてもらったのが参加のきっかけです。
AWS JumpStartとは
AWS JumpStartは、AWS Japanが若手エンジニア向けに開催している、無料の体験型オンラインイベントです。
特徴をざっくりまとめると、こんな感じです。
- AWSの基礎を 講義 + ハンズオン + グループワーク で学べる
- 講師はAWSのソリューションアーキテクトの方々
- 参加費は無料、オンライン開催
- 他社のエンジニアとチームを組み、ワークに取り組む
「資料を読む」「動画を観る」型のキャッチアップとは違い、 自分で実際にコンソールを触ってサービスを組み立てる ところがいちばんの売りだと感じました。
参加したきっかけ
冒頭でも触れたとおり、私は社内の先輩からの紹介で参加しました。
私自身、業務でAWSに触れたことがあるものの「ゼロから設計・構築する」ようなフェーズに本格的に関わった経験はありません。
クラウドの理解を深めたい、というのが個人的なモチベーションでした。
1日目のおおまかな流れ
1日目はだいたいこんなスケジュールでした。
- 午前前半:オープニング + 講義(AWSサービスの概要・設計の考え方)
- 午前後半:ハンズオン①②(VPC + EC2 / Amplifyでフロントエンドをデプロイ)
- お昼休憩
- 午後:ハンズオン③(VPC → Aurora マルチAZ → ALB → ECS on Fargate → 負荷テスト)
講義パート:印象に残った「アーキテクチャの答えは一つじゃない」
ハンズオンの前に、AWS側の講師の方から、AWSの代表的なサービスや設計の考え方についての講義がありました。
その中でいちばん刺さったのが、 「事業フェーズによって、求められるアーキテクチャは変わる」 という話です。
たとえば、立ち上げたばかりのサービスと、すでにユーザー数がついている安定運用フェーズのサービスでは、
- 「コストを抑えてとにかく早く出す」ことを優先するのか
- 「可用性とスケーラビリティを優先する」のか
によって、選ぶサービスも、組み方も、まったく違ってくる、という内容でした。
AWSに限らず、アーキテクチャの設計をする上で大前提になる考え方だと感じました。
ハンズオン①:VPC + EC2
午前のハンズオンは、シンプルなWebアプリをEC2で公開するというものでした。流れはこんな感じです。
- VPCを作成(パブリックサブネット / プライベートサブネットを切る)
- EC2インスタンスを起動し、セキュリティグループを設定
ここでのポイントは、 「ネットワークの土台作成 → サーバーの構築」を、一度自分の手で順番に通すこと でした。
実際にコンソールを操作して環境構築したり、構築したものを公開したりすることで体系的に学ぶことができました。
ハンズオン②:Amplify
EC2の他にも静的サイトを公開する方法としてAmplifyというサービスを使うハンズオンもありました。
- ZIPファイルにまとめられたSPAをAmplifyにデプロイ
EC2を使用したサーバーの構築に比べ、マネージドサービスであるAmplifyを使用したサイトの構築は直感的でUXが良いと感じました。
ハンズオン③:Aurora + ALB + ECS on Fargate
午後のハンズオンは、午前よりもステップアップした構成で、よりプロダクションに近い形を組みました。
- VPCを作成(今度はマルチAZを意識した構成)
- セキュリティグループを設定
- Aurora を マルチAZ構成 で作成
- Application Load Balancer(ALB)を作成
- ECS on Fargateでコンテナを起動
- ApacheBenchで負荷をかけて、CloudWatchでメトリクスを確認
資料の一部を抜粋

ECS on Fargateは初めて触りましたが「サーバーを自分たちで管理せず、コンテナを直接動かせる」体験はインパクト大です。
EC2を構築して必要な設定やソフトウェアを導入する構築フローと比べると、 「アプリを動かすために必要な作業の量」が減っている のを実感できました。
仕上げの ApacheBench での負荷テストでは、ALBがリクエストをばらまき、ECSタスクのCPU使用率がCloudWatch上で動いていくのを観察しました。
自分が組んだ箱がちゃんとリクエストを処理している という、ちょっとした達成感がありました。
2日目のおおまかな流れ
2日目は下記のスケジュールでした。
- 午前前半:オープニング + 1日目の振り返りクイズ
- 午前後半:アーキテクチャ検討(個人ワーク)
- お昼休憩
- 午後前半:アーキテクチャ検討(グループワーク)
- 午後後半:成果物発表
アーキテクチャ検討(個人ワーク)
2日目の午前後半は、 お題に対して自分一人でアーキテクチャを考える 時間でした。
提示されたお題は、
「新設するECサイトの構成図を、1日で作ってほしい」 ― ロイCEOからのお達し
というものでした。架空のCEOからの無茶振り という形でシナリオが渡されます。
要件を整理しながら、私が組んだ構成はざっくり以下のような形になりました。
- VPCをマルチAZで切り、可用性のベースを確保
- フロントエンドは CloudFront + S3 / Amplify でホスティング
- バックエンドのアプリは EC2 + ALB で受ける構成
- データベースは Aurora をマルチAZ構成で冗長化
1日目のハンズオンで触ったサービスを組み合わせるイメージで、 「動くもの」「落ちにくいもの」をまず満たす構成 にしようという方針にしました。
アーキテクトの根本的な考え方
実際に手を動かしてみて感じたのは、アーキテクトの根本的な考え方 の難しさでした。
「EC2でいいのか、ECSにすべきか」「DBはAuroraでいいのか、他にも選択肢はないか」――ハンズオンで触ったサービスをただ並べるのではなく、 要件に対する根拠を持って選ぶ ことが、アーキテクチャを考える出発点なのだと痛感しました。
そしてその根拠は、講義パートで出てきた 「事業フェーズや要件によって、答えは変わる」 という話に立ち返ります。
想定ユーザー数、リリース時期、運用にかけられる工数――そういった前提を整理してはじめて、「この構成が妥当」と言えます。
サービスを「知っている」ことと「選べる」ことのあいだには大きな差があり、その差を埋めるための 考え方の起点 を、自分ごととして体感できた気がします。
アーキテクチャ検討(グループワーク)
午後前半は、4〜5人のチームでそれぞれの個人案をもとに再度アーキテクチャを検討する時間でした。
ベースのお題は個人ワークと同じECサイトですが、ここに 「分析・BIの要件も追加してほしい」 という追加オーダーが入ります。
データを集めて後から見られるようにする部分まで含めて、チーム内で設計を組み直すことになりました。
チームでまとめた構成
各自の個人案を持ち寄ったときにネックだった部分として、メンバーごとに想定しているケースが違う ことが挙げられます。
「まずは小規模にMVPを出す」前提で組んだ人もいれば、「最初から数万ユーザー規模を捌く」前提で設計した人もいました。
午前中の講義と個人ワークで繰り返し出てきた 「事業フェーズや要件によって、答えは変わる」 という話を、 他人の考え方を通して実証する ような時間だったと思います。
最終的にチームでまとめた構成は、私の個人案と 大枠は似ているものの一部が違う 形に落ち着きました。
分析・BIの要件に対しては、データを別途集約する仕組みを追加しました。サービス選定の細部は、チーム内でより詳しい人の意見を取り入れて整理しました。
周りの意見を取り入れることで自分では考慮していなかった部分も網羅することができたと感じています。
実際の構成図

おわりに
2日間を通して、 「AWSのサービスを実際に手を動かして学べる」 という体験はもちろん、 「アーキテクチャをどう考えるか」 という設計者目線の入口に立てたことが、いちばんの収穫でした。
1日目のハンズオンでは、VPC・EC2・Amplify・ECS on Fargate・Aurora・ALBといった代表的なサービスを、自分のコンソールから順番に組み立てる体験ができ、「資料で読んで知っているつもり」から「ひとまず自分で動かせる」に一歩進めた感覚があります。
2日目の個人ワーク・グループワークでは、「知っているサービスを並べる」のではなく 「要件から逆算して選ぶ」 ことの難しさと面白さを実感しました。同じお題でもメンバーごとに前提のとらえ方が違い、その違いを擦り合わせる過程そのものが学びでした。
「AWSになんとなく触れてはいるけれど、もう一段深く理解したい」という若手エンジニアにとって、AWS JumpStartは非常におすすめのイベントだと感じました。
無料・オンラインで、AWSのソリューションアーキテクトの方々から直接学べる機会は貴重ですし、社外のエンジニアと同じお題に取り組むことで、自分の理解度や考え方の癖を客観的に振り返るきっかけにもなりました。
ここまで読んでいただきありがとうございました。ラクーンホールディングスではエンジニアを大募集中です!ご応募お待ちしております!





