はじめに
こんにちは!新卒1年目の高垣、なべしま、パクパクです。
新人研修の一環としてニフティ2025年度新卒入社の9名がAWS JumpStart2025に参加してきました!この記事では 2日間のプログラム内容に加えて、学んだAWSサービスやグループワークで作成したアーキテクチャ設計図を紹介します!
AWS JumpStartとは
本プログラムのゴール
- 一般的なリファレンスアーキテクチャの理解
- AWSのコアサービスの概要とその選定基準の理解
- AWSのアーキテクチャ図を作成するまでの流れを知る
実施日時
- 各回2日間(9:00~18:00)
- 2025 年 3 月 13 日（木）~ 3 月 14 日（金）
- 2025 年 5 月 27 日（火）~ 5 月 28 日（水）
- 2025 年 8 月 27 日（水）~ 8 月 28 日（木）(私たちが参加した日時)
- 2025 年 10 月 23 日（木）~ 10 月 24 日（金）
スケジュール
1日目
1日目は、Webアプリケーションについての講義と、実際にWebアプリケーションを構築する実践的なハンズオンを行いました。ハンズオンでは、午前にEC2とAmplify、午後にECS + ALB + RDSといったAWSサービスを使用し、2～4人チームでのモブプログラミング形式で取り組みました。
午前
AWS体験ハンズオン(EC2)
最初のステップとして、ユーザ数が100人以下のような小規模なサービスを構築するハンズオンを体験しました。
このフェーズの目標は、「とにかくシンプルに、そして安価に!」サービスを立ち上げることでした。ここで利用する主なサービスは以下の通りです。
- EC2 (Amazon Elastic Compute Cloud): クラウド上で仮想サーバをレンタルできるサービスです。
- VPC (Virtual Private Cloud): AWSアカウント専用の論理的に分離された仮想ネットワーク空間を提供するサービスです。サーバを直接インターネットに公開しないように、「VPC」というプライベートな「柵」を設けるイメージです。
これらのサービスを実際に使って、シンプルなWebアプリケーションを作成するハンズオンを行いました。なお、今回のハンズオンでは1つのEC2インスタンスのみを立ち上げました。そのため、もしこのEC2インスタンスに障害が発生すると、サービス全体が停止してしまうという問題があります。このような弱点のことを「単一障害点」と呼び、実際のサービスでは避けなければならない構成です。
AWS体験ハンズオン(Amplify)
EC2とVPCの構成では、仮想サーバの管理やOS・ミドルウェアの設定といった、人による「構築作業」の負荷が高いという課題があります。この課題を解決し、より手軽にサービスを立ち上げる選択肢が Amplify です。
Amplifyには、主に次のような特徴があります。
- 手軽なデプロイ
- Webサイトのソースコードなどをアップロードするだけで、デプロイから公開までが自動的に行われます。
- 高速なグローバル配信
- Amazon CloudFrontが自動で設定され、世界中のユーザへWebコンテンツを低遅延で高速に配信します。
- 自動スケーリング
- トラフィックの増減に応じてリソースが自動的に拡張・縮小されるため、急なアクセス増にも耐えられ、高い可用性を維持します。
Amplifyのハンズオンでも、シンプルなWebアプリケーションを作成しました。EC2のハンズオンとは異なり、OSやネットワークの設定をすることなくアプリケーションを立ち上げることができました。
このように、Amplifyはサーバレスでインフラ管理が不要という大きなメリットがあります。その一方で、EC2と比べてAWS構成の決定には制限があるため、用途に応じて使い分けることが重要です。
午後
AWS体験ハンズオン(ECS + ALB + RDS)
サービスが成長しユーザ数が増えてくると、次に重要になるのが「アプリケーションの可用性や拡張性」です。これを実現するための具体的な手法として、ECS+ALB+RDSといった組み合わせが考えられます。
- ECS(Elastic Container Service): Dockerなどのコンテナを簡単に実行・管理できるサービスです。
- ALB(Application Load Balancer): サーバへ来るアクセス（トラフィック）を、複数のサーバに自動で振り分けてくれるサービスです。
- RDS (Amazon Relational Database Service): クラウド上でリレーショナルデータベースを簡単にセットアップ・運用できるサービスです。
このように、3つのサービスを組み合わせることで、アクセス数の増減に柔軟に対応できる、可用性・拡張性の高いシステムを構築することができます。具体的には、ALBがトラフィックを複数のコンテナ（ECSタスク）へ自動で分散させ、障害が起きたコンテナを切り離してくれるため、サービス全体が停止するリスクを低減し、柔軟な拡張も可能になります。
1日目の午後では、この構成を目指して、チーム全員でToDoアプリを構築するハンズオンに取り組みました。構築したアプリは以下のような感じです!
2日目
アーキテクティング
2日目は、1日目の講義の復習クイズと、AWS構成図を作成する（アーキテクチャ検討）ワークショップを行いました。
復習クイズでは、1日目に学んだサービスの特徴を確認する問題や、AWS認定資格の試験の対策になるようなクイズが出題されました。クイズ後の丁寧な解説が印象的でした。
アーキテクチャ検討ワークショップでは、「AWSを使ってWebサービスをリリースしたい」という課題に沿って設計に取り組みました。AWSの社員の方が今回の要件をロールプレイングで説明してくださったので、ワークショップも楽しく和やかな雰囲気で行うことができました。午前中は個人で設計図を考え、午後はそれぞれの設計図を持ち寄り、5〜8人のグループで協力してAWSシステムの設計に取り組みました。
成果
高垣チーム
私たちのチームは、以下の構成図を作成しました。
私たちのチームでは、月間1万人程度のアクセスを想定し、可用性を最大限高めたいと考えました。そこで、ECSとRDSを使って2つのアベイラビリティーゾーン(AZ: Availability Zone)に配置する構成にしました。
ユーザからのアクセスはCloudFrontを経由し、WAFでセキュリティを高めています。フロントエンド・バックエンド層はECS上でコンテナとして稼働し、これらへのトラフィックはALBを使って分散するようにしました。認証が必要な操作については、Cognitoを使って一元的に管理しています。データベースはRDSを採用して、こちらも2AZ構成にすることでデータベースの可用性を確保しています。また、Redshiftを使って蓄積される購買データなどを分析できるようにしています。
チーム内にAWSについて詳しい方はいなかったのですが、全員で調べたり、質問したりして協力しながら構築することができました。
なべしまチーム
なべしまチームでは、複数AZにリソースを分散配置し、DBを冗長化するという高可用性の構成を基本として、次の2つの点を重視して設計を行いました。
1つ目は高いパフォーマンスです。Auroraをメインのデータベースとしながら、一時的に利用されるデータは高速なDynamoDBで管理するよう設計しました。また、Webサービスへの再アクセス時にAuroraの処理負荷を軽減するため、ElastiCacheを導入しました。
2つ目はセキュリティです。外部からのアクセスはCloudFrontを経由させ、WAFによってセキュリティを強化しました。課題のWebサービスでは、ユーザが個別アカウントを持ってサービスを利用することを想定したため、アカウント管理にはCognitoを採用し、高度なセキュリティの実現を目指しました。
「このAWSサービスで実現したいことは何か」を意識して議論することで、チームで納得できる設計ができ、理解をより深めることができました。
パクパクチーム
パクパクチームはユーザが増える場合の可用性と拡張性を意識して、以下の構成図を作成しました。
この構成図で特に工夫したポイントは下記の3つです。
1. セキュリティ（Security）
サービスで利用されるデータとリソースを保護するため、多層的なセキュリティ対策を実装しました。
- WAF: SQLインジェクションやクロスサイトスクリプティング（XSS）のような一般的なWeb攻撃の パターンをトラフィックがサーバに到達する前にフィルタリングします。
- AWS Shield: DDoS（分散型サービス妨害）攻撃からシステムを保護するマネージドサービスです。サービスを麻痺させるような悪意のある大量のトラフィックを検知します。
- Amazon Cognito: ユーザのサインアップ、サインイン、アクセスコントロールを担う認証サービスです。これにより、認証システムを自前で構築する複雑さを軽減し、セキュリティを強化することができます。
- VPC: ネットワークをパブリックサブネットとプライベートサブネットに分離しました。パブリックサブネットには、外部インターネットとの直接通信が必要なウェブサーバやロードバランサーなど、最小限のリソースのみを配置し、データベースや主要なアプリケーションサーバはプライベートサブネットに配置しました。この構成により、データベースが外部から直接アクセスされるリスクを大幅に低減し、リソースへのアクセスを厳格に制御することができます。
2. 可用性（High Availability）
ウェブサーバ、アプリケーションサーバ、データベースを含む全く同じシステムを2つのアベイラビリティーゾーンで構築しました。もし片方の「AZ1」に問題が発生しサーバダウンしても、正常に動いているもう一方の「AZ2」へ自動的にトラフィックが切り替わるように構成し、サービスが停止しない設計しました。
3. 拡張性（Scalability）
ユーザ数（トラフィック）は状況によって変わります。イベントや時間帯によって増えることもあれば、減少することもあります。このようなトラフィックの変動に効率的に対応するため「Auto Scaling」を導入しました。
これにより、トラフィックが通常時よりも増加した際には自動でECSタスクを追加してサーバの負荷を分散します。逆にトラフィックが少ない時間帯には不要なECSタスクを自動で終了させ、コストを最適化します。
感想
高垣
2日間を通して、クラウドインフラ設計の基礎から実践まで幅広く学ぶことができました。1日目の講義では、単にシステムを構築するだけでなく、安定稼働のための運用面についても詳細な解説があり、実務に直結する知識を深めることができました。2日目では、アーキテクチャを設計しつつ、これまで詳しく知らなかったAWSサービスについての理解を深めることができたのは大きな収穫だと思います。
短い期間でしたが、非常に学びが多い研修でした。
なべしま
AWS JumpStartでは、実践的なワークに取り組むことができました。「なぜこのような設定をするのか」「このサービスで実現したいことは何か」など、AWSサービスの深掘りをすることで、より理解が深まったと感じています。
グループワークでは、課題に取り組む中で社外の方との交流がありました。AWSの勉強の進め方や、クラウドサービス・AIの活用についてお話をすることができました。JumpStartのコンテンツ外でも学びを得る、貴重な機会となりました。
パクパク
学生時代は名前しか知らなかったAWSをニフティに入社してから、AWS Summit、そして今回のAWS JumpStartと、直接体験できる貴重な機会をいただきました。
前回のAWS Summitがクラウドへの興味が湧くきっかけになった時間だとしたら、今回のAWS JumpStartは、様々なサービスを組み合わせて一つのアプリケーションを構築する具体的な方法を学んだ時間でした。
特に初心者向けのイベントだったので、AWSが初めての参加者も多く、気軽な雰囲気で質問しながら協力しました。困ったことはチームメンバーと一緒に工夫しながらハンズオンを進めることができました。
以前は複雑な絵にしか見えなかったアーキテクチャ図から、今では各サービスの役割やデータの流れを読み取れるようになりました。今回のAWS JumpStartは今後の業務でAWSの技術やアーキテクチャに向き合う際に「自分も応用できる」という自信を与えてくれた、貴重な経験でした。
