はじめに！
こんにちは！新卒1年目のGokuと竹下です！
新人研修の一環としてニフティ2026年度新卒入社の11名が
AWS JumpStart2026に参加しました！
この記事では2日間実施されたワークショップの内容と、
グループワークで作成したアーキテクチャ設計図を紹介します！
AWS JumpStartとは？
AWS初学者のエンジニアを対象とした実践的な研修プログラムです
2日間実施され座学やサービスの学習だけでなく、実際の要件に合わせたアーキテクチャの
検討、設計まで体験できるのが特徴です！
プログラムの到達目標
この研修プログラムでは3つの到達目標があります！
１．一般的なリファレンスアーキテクチャの理解
２．AWSコアサービスの概要とその選定基準の理解
３．AWSのアーキテクチャ図を作成するまでの流れを知る
日程
6/4(木)～6/5(金)の2日間
研修内容
1日目
・AWS体験ハンズオン
簡易的なWebサーバーの構築
ToDo管理アプリの作成
2日目
・AWSのサービスの機能に関するクイズ
・アーキテクティング演習
1日目
午前
午前中はアーキテクティングのコツに関する解説や、以下の2つの構成で
Webサーバーの構築を行いました！
・VPCを作成しその中にEC2インスタンスを構築する方法
・VPCを用いずにAmplifyを利用する方法
午後
午後はチームでToDo管理アプリを動かすためのアーキテクチャの構築を行いました！
構成は以下の図の通りとなっております。
ユーザーがアクセスした際にApplication Load Balancer(アプリケーションロードバランサー)に通されその後、各プライベートサブネットに配置されたコンテナに振り分けられる構成となっております。いわゆる冗長化構成となっており、いずれかのコンテナがダウンした場合でもシステムを利用できる仕組みです。
2日目
2日目の朝は、クイズから始まりました。
出題されたのは「システムを運用していく上で〜〜という課題があり、それを解決するためにどのような構成が考えられますか？」といった形式の問題が中心で、このあとの課題に向けた、ちょうど良いウォーミングアップになりました。
ここで得た学びは、アーキテクチャの正解は一つとは限らないということです。
もちろん模範解答はあります。ですが、今回のクイズでは「これが絶対に正しい」「これが唯一の正解」といったアーキテクチャは存在しませんでした。コストや冗長性などの観点で、それぞれにメリット・デメリットがあるのだと学びました。
アーキテクチャ図を作成する
課題の内容
まず、このような課題が与えられました。
- ECサイトをローンチ予定。
- 大々的なプロモーションを実施しており、半年後にはリリースする必要があるが、残念ながら既存のチームメンバーが 全員退職 してしまった。
- AWSを中心に開発すること以外はまだ何も決まっていないが、時間がないので、皆さんには 本日中 にAWSでのアーキテクチャを考えていただきます！
チームメンバーが全員退職……？？
今日中にAWSでのアーキテクチャを考える……？？？
そんな、なかなか衝撃的な設定からのスタートでした。
検討にあたっては、以下のような前提も補足として提示されました。
現状の構成（自由に変更可能）
- バックエンド：Java / Spring Boot
- フロントエンド：TypeScript / React
- データベース：MySQL
- ローカルはDockerで開発中だが、コンテナは必須ではない
必須機能
- 商品一覧・詳細ページ
- カート機能・購入機能
- 決済・在庫管理・配送システムは外部のSaaS APIを利用する
- アカウント管理機能
検討してほしい項目
- 機能要件：検討した構成で、ECサイトの各要件を実現できるか？
- 可用性：あるコンポーネントに障害が起きても、システムを継続できるか？
- スケーラビリティとパフォーマンス：今後ユーザーが10倍になったとき、同じような構成で捌けるか？
実践
4人チームで各自がアーキテクチャ図を作成し、途中でチーム内発表を挟みながら、良いと思った案を採用してブラッシュアップしていく流れでした。
最初は、そもそもAWSのどのリソースを使えばよいのか、そしてそれらをどうつなげればよいのかが、まったく見当もつきませんでした。
そこで一度AWSのことは脇に置き、「提示された要件で、ごく普通にシステムを組むとしたら何が必要だろう？」と考えるところから始めました。
Webサーバー、データベース、アプリケーションの実行環境……。こうして洗い出した要素を、AWSのリソースに置き換えていくイメージです。
とはいえ、AWSのリソース、とくにECS on Fargate、VPC、パブリック/プライベートサブネット、ゲートウェイ周辺については理解が浅く、厳密なアーキテクチャ図を1日で描き切るのは、さすがに難しかったというのが本音です。
最終的に、私（竹下）が提案したアーキテクチャが「スケールのしやすさや冗長性の面でメリットが大きい」とチームメンバーに評価してもらい、採用されました。
竹下チームが作成したアーキテクチャ図
主なリソースは以下の3つです。
- AWS Amplify
- インフラを意識せずにWebアプリケーションをデプロイできる、フルマネージドなサービス
- GitHub等と連携し、Pushするだけで自動的にデプロイしてくれる機能などがあります
- Amazon ECS on Fargate
- サーバーの管理や構築をせずに、コンテナだけを動かせるサーバーレスの仕組み
- Amazon Aurora Serverless v2（MySQL）
- 0から数十万規模までのスケールアップに対応可能な、フルマネージドなDBサービス
バックエンドはマルチAZ構成にして冗長性を確保し、片方のAZで問題が発生してもELBが自動的に振り分けることで、安定的に稼働できるようにしました。
データ分析にはAmazon Aurora MySQL zero-ETL integration with Amazon Redshiftを活用し、Auroraに負荷をかけずにデータをRedshiftへ反映し、QuickSightで可視化できるようにしました。
全体としては、マネージドサービスやサーバーレスを中心に据え、運用負荷を抑えながら、急激なアクセス増にも対応できるように、スケーラビリティとアベイラビリティの高い構成を意識しました。
感想
Goku
今回のイベントで、初めて本格的にAWSを触りました。
特に感心したのは、EC2インスタンスを起動してWebサーバーを構築するまでが、
10分程度で完了してしまう点です。
オンプレミス環境であれば、機器の準備からOSの導入、各種設定までかなりの時間を要する作業ですが、 それがマネジメントコンソール上の操作だけで完結します。
また、保有している機器を気にすることなく大規模な構成を組んだり、
用途に合わせた小さな構成を画面上だけで組んだりできる点も印象的で、 スピードが求められる現代のプロダクト開発に適したサービスだと感じました。
EC2やS3など、名前は聞いたことがあるものの実態がわからない状態からのスタートでしたが、 主要なサービスについては、どのサービスがどのような機能を持つのかを大まかに把握できるようになりました。
今後は資格試験の学習や実務を通じて、AWSに関する知見をさらに深めていきたいです。
竹下
1日目では、EC2でWebサーバーを構築する方法と、Amplifyで同様のWebサイトを公開する方法を体験するハンズオンを行いました。
EC2もAmplifyも最終的にWebサイトを公開できる点は同じですが、公開までの工数や設定項目が異なり、EC2（IaaS）とAmplify（PaaS）の違いを実際に手を動かして理解できました。Amplifyは数回クリックするだけでWebサイトを公開することができ、あまりの手軽さに拍子抜けしてしまいました。
2日目は、チーム内で「これで合っているのかな？」「要件を満たすにはどうすればいい？」と議論するフェーズ、ドキュメントを読みながら情報を集めるフェーズ、そして実際に図を書くフェーズを行き来しました。10分に一度くらいの頻度で情報収集に立ち返り、試行錯誤を重ねながら何度もブラッシュアップしていきました。
参加時点ではアーキテクチャ図を書いた経験もなく、AWSもほとんどわからない状態でしたが、提出する頃にはFargateがどのようなものかをある程度説明できるようになっていました。
さまざまなAWSリソースを知る大きなきっかけになったと思います。
