AWS にいる間、私はいつも学生と一緒に働く機会を探していました。私は地域の大学で 50 回以上の講演を行ってきましたが、会場で可能性を観察することは常に強いモチベーションになっています。それは、なぜ私がこの仕事をしているか、また今日会う学生が明日私たちの顧客や協力者になるかもしれないということを思い出させてくれます。それが、私が 2026 年 8 月 24 日週に AWS Builder Center で学生リワードを提供できることを嬉しく思う理由です。 Rick Suttles 氏が「 AWS Builder Center での学生リワードの紹介 」を公開しました。これは、認定を受けた高等教育学生向けの新しい特典です。SheerID を通じて登録を確認し、Builder Center プロファイルを完了すると、12 か月間のプレミアム AWS Skill Builder アクセス (900 以上のコース、ハンズオンラボ、認定試験の準備、ゲームベースの学習) がロック解除されます。そこから、Builder Center でのアクション (記事の公開、コメント、エンゲージメントの維持) を通じてバッジを獲得できます。バッジが 7 個になると、10 USD の AWS クレジットをロック解除できます。バッジが 14 個になると、さらに 20 USD のクレジットが得られます。バッジが 21 個になると、AWS 基礎認定試験バウチャー (100 USD 相当) を獲得できます。 これは、この新学期シーズンに 5 億 USD 以上のリソースのコミットメントを表しており、クラウドと AI でのキャリア構築を始めるために必要なトレーニング、ツール、認定資格を学生に提供します。学生リワードは、世界中の認定高等教育機関に在籍している 18 歳以上の学生を対象としています。ただし、検証と利用規約の対象となります。 学生のステータスを確認して 、学習を開始し、バッジを獲得し、リワードをロック解除しましょう! 2026 年 8 月 17 日週のローンチ その他、8 月 24 日週に発表された事項をご紹介します。 ネバダ州ラスベガスの新しい AWS ローカルゾーン — この新しいローカルゾーンは、Amazon EC2 C7i、M7i、R7i、C8gn インスタンス、Amazon EBS、Amazon ECS、Amazon EKS、Application Load Balancer、AWS Direct Connect をサポートします。AWS ローカルゾーンは、世界中の 30 を超える大都市圏で利用できるようになりました。さらに、AWS は 欧州 (ロンドン) リージョンに 4 つ目のアベイラビリティーゾーン を追加し、汎用コンピューティングに加えて Trn3 と P6 の高速インスタンスによる次世代 AI と ML のキャパシティを提供しました。 Amazon EC2 Auto Scaling がバッチインスタンスの終了をサポートするようになりました – 最大 100 個のインスタンス ID を TerminateInstanceInAutoScalingGroup API に渡してバッチとして終了できるようになりました。これにより、自動スケーリンググループのスケールダウンに必要な API コールの数が削減されました。バッチ終了は、AI/ML トレーニングジョブ、コンテナオーケストレーター、または一時的に大規模なフリートをスピンアップするイベント駆動型アーキテクチャなど、迅速なスケールダウンが必要なワークロード向けに設計されています。 AWS CloudShell に組み込みのビジュアルファイルエディタが含まれるようになりました – CloudShell には、単一の編集コマンドを使用してシェルセッションから直接起動できるビジュアルファイルエディタが含まれるようになりました。このエディタは、シンタックスハイライト、検索と置換、複数行選択、コピーアンドペースト、元に戻す/やり直すを単一のブラウザセッションでサポートしています。デプロイスクリプトの更新、エージェントステアリングファイルの変更、CloudFormation テンプレートの編集、Lambda 関数の修正のいずれを行っている場合でも、このエディタは CloudShell から離れることなくシームレスに編集して実行できるようにします。 Amazon Bedrock がクロスリージョン推論による SpaceXAI Grok 4.6 をサポートするようになりました – コーディング、エージェントタスク、ナレッジワーク向けに構築されたフロンティアモデルである Grok 4.6 が、Amazon Bedrock 上で利用できるようになりました。 このモデルは、レスポンス、チャット完了、コンバース API をサポートする bedrock-runtime エンドポイント上で実行され、モデル呼び出しログ記録、Amazon CloudWatch メトリクス、AWS Cost Explorer のコスト項目化など、既存のアカウントレベルのコントロールと連携します。 Amazon Bedrock が API サポートを拡張し、OpenAI モデルにクロスリージョン推論を導入しました – Amazon Bedrock が、レスポンス、コンバース、チャット完了 API で OpenAI GPT-5.6 モデル (Sol、Terra、Luna) をサポートするようになり、クロスリージョン推論が追加されました。地理的クロスリージョン推論は、事前定義された地域内でリクエストをルーティングします (今回のローンチでの米国地域サポートを含む)。一方、グローバルクロスリージョン推論は、低いトークンあたりのコストで、あらゆる商用 AWS リージョンからのリクエストを処理します。 AgentCore 支払いが Amazon Bedrock AgentCore で一般的に利用できるようになりました – 一般提供時点では、AgentCore コンソール内での Coinbase 認証情報の直接プロビジョニングのためのクイック作成、AgentCore Gateway を介した従量課金型の x402 エンドポイントの厳選された Coinbase Bazar MCP サーバー、Machine Payment Protocol (MPP) のサポート、および x402 プロトコルの「upto」スキームが含まれます。推論に応じた料金とダイナミックプライシングのユースケースに対応します。詳細については、 AI ブログの記事 をご覧ください。 AWS Glue 6.0 が 30% の料金引き下げと Iceberg v3 のサポートを提供 – AWS Glue 6.0 は、完全にモダナイズされたランタイム、Apache Spark 4.1、Python 3.13、および Scala 2.13 に基づいて構築されており、以前の AWS Glue バージョンよりも 30% 低い料金を提供しています。Iceberg v3 では、Glue 6.0 には、半構造化データの読み取りを高速化する自動シュレッダー処理、高性能な行レベルの更新のための削除ベクトル、空間処理用のジオメトリおよび地理データ型、および柔軟なスキーマ展開機能を備えた VARIANT データ型が追加されました。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS ニュース お客様に役立つ可能性のある記事をさらにいくつかご紹介します。 AWS サインインエクスペリエンスの更新 – AWS では、サインインおよびサインアップエクスペリエンスの更新を徐々に導入しています。再設計されたサインインページでは、新しい E メールベースのサインイン方法を使用するルートユーザーと顧客のための統一された E メールエントリポイントが導入され、IAM ユーザーは引き続きアカウント ID、ユーザー名、およびパスワードを使用してサインインできます。このページには、サポートされている ID プロバイダー (Google、GitHub、Apple、または Amazon.com) を使用して AWS アカウントを作成した顧客向けのサインインオプションも含まれています。再設計されたセッション選択ページにより、複数のアクティブなアカウントおよびロールセッションの表示と管理が簡素化されました。サインインページを操作するブラウザ自動化またはスクリプト化されたワークフローに組織が依存している場合は、投稿を確認して、これらの変更が構成にどのように影響する可能性があるかを理解してください。 開発中: ベルリン、ハイデラバード、サンパウロの AWS Builder Loft – 私の同僚の Channy が 3 つの都市に新しい Builder Loft をオープンする計画を発表しました。2025 年 7 月にサンフランシスコに最初の Builder Loft がオープンして以来、22,500 人以上の開発者を迎えてきました。新しい場所はそれぞれ、無料のワークショップ、ネットワーキングイベント、ピッチナイト、コンテンツ制作スペース、コワーキングエリアを提供する常設コミュニティスペースになります。ベルリンはデジタル主権とセキュリティ対策に、ハイデラバードは AI とクラウドネイティブアーキテクチャに、サンパウロはラテンアメリカの開発者エコシステムのサポートに焦点を当てます。 AWS と Amazon WorkSpaces が 2026 Gartner Magic Quadrant for Desktop as a Service のリーダーとして認められました – AWS は、ビジョンの完全性と実行能力が評価され、2026 Gartner Magic Quadrant for Desktop as a Service (DaaS) で、3 年連続でリーダーに選ばれました。Gartner は、オペレーション、地理的戦略、および全体的な存続可能性に強みがあると認めました。また、人間のユーザーと同じデスクトップ環境、セキュリティ境界、および監査証跡内で AI エージェントを実行する機能である Amazon WorkSpaces for AI エージェントが評価対象になったのは今年が初めてです。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 近日開催される AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – ビルダーやイノベーターがクラウドで最新情報を学び、交流し、探求するための無料の対面イベント。開催予定: チューリッヒ (9 月 2 日)、 サンパウロ (9 月 3 日)、 テルアビブ (9 月 10 日)、 ドバイ (9 月 30 日)。また、 AWS Summits Global Livestream + On-Demand Hub で基調講演やセッションを視聴することもできます。特定の Summit のライブコンテンツやオンデマンドコンテンツにアクセスするには、そのイベントに登録する必要があります。 AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンス。今後のイベントには、 ボリビアのサンタクルス (8 月 29 日)、 カナダのトロント (8 月 29 日)、 東京の JAWS SONIC (9 月 5 日)、 ポーランドのワルシャワ (9 月 8 日) などがあります。 AWS Builder Center にアクセスして、他のビルダーと交流したり、ソリューションを提供したり、構築を継続するのに役立つリソースを見つけたりしましょう。 夏も徐々に終わりに近づいています。私は、これから雨の多い秋を乗り切るために、今後数か月のうちに数日の休みを計画しています。お客様も同じように計画していることを願っています。8 月 31 日週もまた新しいニュースをお届けしますので、お楽しみに。 – Esra 原文は こちら です。

はじめに はじめまして、 マグロ中毒 と申します。 この世のすべての食べ物の中でマグロが1番好きなエンジニアです。 日々スーパーの刺身やお寿司で自分のご機嫌を取りつつ、 CopilotやPower Platformの活用支援やセミナー登壇など情報発信の活動をしています。

はじめに こんにちは！新卒一年目の関澤と福井です。 技術研修の一環として、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構成による冗長化へと、フェーズに応じて構成を進化させていく考え方はクラウドサービスならではでした。 また、チームでの設計や他チームの成果発表では、同じような要件に対しても様々なアーキテクティングの工夫があり、参考にしたい点が数多く見つかりました。目的やフェーズによって最適な構成は変わるという考え方は、今後の実務にも活かしていきたいです。