はじめに
2026年6月4日〜5日に開催された AWS JumpStart 2026 に参加しました。
AWS JumpStart は、AWS が主催する初学者向けの実践的な研修プログラムで、クラウドの基礎知識から主要サービス、アーキテクチャ設計までを短期間で学ぶことができます。
私は普段クラウド基盤を扱う業務を行っているわけではなく、AWSについても基礎レベルの知識しかありませんでした。そこで今回の研修を通して、
- AWSサービスの概要を理解する
- システム規模に応じたアーキテクチャ設計を学ぶ
- AWS環境を実際に操作してみる
ことを目的に参加しました。
1日目：AWSサービスと設計の考え方を学ぶ
まずは主要サービスを理解する
1日目はAWSの主要サービスについて学習しました。
代表的なサービスとして、
- EC2（仮想サーバー）
- RDS（リレーショナルデータベース）
- Route53（DNS）
- CloudWatch（監視）
- CloudFront（CDN）
- ElastiCache（キャッシュ）
などが紹介されました。
サービス単体の説明だけではなく、「なぜそのサービスを使うのか」という観点で説明されていたため、実際のシステム構成をイメージしながら理解を深めることができました。
ユーザー数によって構成は変わる
特に印象的だったのが、ユーザー数の増加に応じてアーキテクチャが段階的に進化していく考え方です。
小規模なシステムでは、
EC2 + RDS
のようなシンプルな構成で十分です。
しかし利用者が増えるにつれて、
- ALBによる負荷分散
- Multi-AZ構成
- Auto Scaling
- CloudFront
- ElastiCache
- リードレプリカ
などを導入し、可用性やスケーラビリティを高める必要があります。
これまで私は「最初から完璧な構成を作るべき」と考えていましたが、
まずはシンプルに作り、必要に応じて拡張する
という考え方が非常に重要であることを学びました。
Design for Failure
研修の中で何度も登場した考え方が「Design for Failure」です。
これは、
障害は必ず発生するものとして設計する
という考え方です。
単一障害点（SPOF）を排除し、どこかのサーバーやサービスが停止してもシステム全体は動き続ける構成を目指します。
クラウドらしい設計思想を感じる部分でした。
AWSを都市に例えた説明が分かりやすかった
AWSの全体像について、
- AWS = 都市
- VPC = 建物
- EC2 = 店舗
- データベース = 倉庫
という例えで説明がありました。
サービス名だけを見ると難しく感じますが、この例えによって各サービスの役割を直感的に理解することができました。
ハンズオン：実際にAWSを触る
午前中は、
- VPC作成
- セキュリティグループ設定
- EC2起動
を実施しました。
実際にAWSコンソールを操作することで、ネットワークやサーバー構築の基本的な流れを体験できました。
午後は、
- ECS
- Aurora MySQL
- ALB
を利用したToDoアプリの構築を行いました。
さらに障害試験も実施し、コンテナの一部が停止してもサービスを継続できることを確認しました。
講義だけでは理解しにくい「高可用性」の考え方を体験できたのが印象的でした。
2日目：アーキテクチャ設計に挑戦
2日目はワーク中心でした。
ECサイトを題材として、
- 商品一覧
- 商品詳細
- カート
- 購入
- アカウント管理
を実現するAWSアーキテクチャをグループで設計しました。
機能要件だけでは設計できない
設計時に考慮したのは、
- 可用性
- スケーラビリティ
- セキュリティ
- コスト
といった非機能要件です。
単純に「動くシステム」を考えるだけではなく、
- 障害に強いか
- ユーザー増加に耐えられるか
- 運用コストは妥当か
まで考える必要がありました。
普段はアプリケーション側の視点で考えることが多いため、インフラ設計の難しさを実感しました。
アーキテクチャ図作成の流れ
設計は次のような流れで進めました。
- 前提条件整理
- 機能要件整理
- 非機能要件整理
- AWSサービス選定
- サービス間連携検討
- アーキテクチャ図作成
特に重要だと感じたのは、
AWSサービスを選ぶ前に要件を整理すること
です。
AWSには非常に多くのサービスがありますが、要件が曖昧なままでは適切な選定はできません。
まとめ
今回のAWS JumpStartを通して、AWSサービスの知識だけでなく、システム設計そのものの考え方を学ぶことができました。
特に印象に残ったのは以下の3点です。
- Design for Failure の考え方
- ステートレス設計の重要性
- 要件からアーキテクチャへ落とし込むプロセス
AWSを学ぶ前はサービス名を覚えることが重要だと思っていましたが、実際には
「なぜそのサービスを選ぶのか」
を理解することの方が重要だと感じました。
今後は実際にAWS環境を構築しながら理解を深め、アーキテクチャ設計の経験も積んでいきたいと思います。