2025/12/1~12/5に開催されたAWS re:InventでもAWS DevOps AgentなどAIサービスが発表され、AIエージェントが引き続き注目されています。本セッションではAWS Well-Architected フレームワーク（以下W-F）からAIエージェント時代のアーキテクチャ設計方法、実務での活用ポイントを紹介します。

対象者

1.W-Fを用いた設計方法についてキャッチアップしたい方
2.AIエージェントを活用した設計を考えている方
3.運用を見据えた設計を実現したいと考えている方

持ち帰って頂くこと

1.AIエージェントは今後も過熱していくと予想
2.AIエージェントとともにW-Fも進化している
3.AIエージェントによってW-Fを取り入れやすくなった
4.運用者視点でアーキテクチャ設計を考える
5.AIエージェントを活用した設計はこれからも進化する

昨今話題のランサムウエア被害。本番環境を外部に公開している以上は他人ごとではありません。
ＡＷＳは責任共有モデルであり、ランサムウエア被害にあえば、その責任は企業側にあります。
入口対策、出口対策をしただけで満足していませんか？
ＡＷＳ独特のリスクとはなにか？リスクに関する備えはなにをすべきか？いざやられたときの対応はどうすべきか？
実際はＡＷＳのサービスだけでは防御もできなければ、実際に被害にあったときの対策もできません。
被害にどう向き合い、解決できるかは日頃のＡＷＳインフラエンジニアの準備にかかっているといっても過言ではないです。
今回は、実際にランサムウエア被害にあった際、どう対応するかを時間軸で整理し、必要な対応策をお伝えできればと思います。

ゲーミフィケーション形式のセキュリティインシデント机上訓練（テーブルトップエクササイズ/TTX）です。PCを使わず、チームで進めるワークショップとなります。
本ワークショップでは、ランサムウェア攻撃の発生を想定したシナリオをもとに、参加者が話し合いながら対応の計画や意思決定のプロセスをシミュレーションします。
参加者は数人でグループを作成し、グループ内で相談しながらシナリオの各フェーズで取るべきアクションを決定します。選択したアクションによってポイントが付与されるゲーム形式となっており、楽しみながら机上演習を進めていきます。
チーム内での議論を通じて、組織としての意思決定プロセスや関係者とのコミュニケーションについても体験的に学んでいただけます。

【背景・課題】
生成AIブームの中、LLMでは導けない「厳密な最適解」が求められるシーンが増加。配送計画やシフト最適化など、推論ベースでは不十分な業務課題に数理最適化が注目されています。

【解決策・技術選定】
数理最適化アプリケーションをECS Fargate上でコンテナ化し、クラウドネイティブな数理最適化基盤を構築。Lambda関数からAPI経由で呼び出す疎結合アーキテクチャを採用し、スケーラビリティを確保しました。

【成果・学び】
数理最適化とLLMでのカバー範囲の理解とともに、その実装方法や実務適用まで

【聴衆へのメリット】
ハンズオン形式で実際に数理最適化アプリケーションのコンテナをデプロイし、簡単な最適化問題を解くまでを体験。LLMと数理最適化を組み合わせたAIエージェントの設計パターンも紹介します。

フィーチャーフラグとは、コードを変更せずに特定の機能の有効/無効を制御する仕組みです。機能ロールバックにかかる時間や影響範囲を抑えることができたり、Pull Requestを小さく保てるトランクベース開発を実現できたりします。

AWS AppConfig機能フラグを利用することで、自前で機能フラグを実装したり外部のFFSaaSを利用することなく手軽にフィーチャーフラグを用意できます。

また、フィーチャーフラグの標準化を図るOpenFeatureというプロジェクトがあります。ベンダーに依存しないインタフェースでフラグの評価ができるクライアントSDKを提供しています。

本セッションでは、AWS AppConfig機能フラグをOpenFeature Clientを介して利用する手法を紹介します。手軽に用意でき、かつ標準化にも則ったフィーチャーフラグの運用方法を知ってもらうことが目的です。

現在PoCの機会をいただいて取り組んでいる、Generative AI Use Cases (GenU)による社内生成AI導入について、失敗談も含めてお伝えします。

GenUはOSS (オープンソースソフトウェア)でソースコードが公開されており、カスタマイズ開発が出来ます。
AIエージェント型IDE「Kiro」を活用する事で、普段AWSを業務で触らないエンジニアである私でも気軽に、取り組めています。

※ 3/7時点でPoC判定結果が出ており本採用かどうかも含めてお話できればと思っております。

こんな問いかけ、やっていませんか？「EC2が応答を返しません」「通信ができません」「なるはやで回答ください」などなど。

AWSサポートへの問い合わせは、技術的な「ラブレター」です。
サポートエンジニアがほしい情報を知り、正しく愛（情報）を伝えれば、想いと熱意のある回答が返ってきます。
逆に、情報不足で愛のない起票は解決を遠ざけ、 いつまで経っても解決しません。

本セッションでは、AWSサポートという最強のパートナーと共に、システムの問題を解決するための心構えと実践テクニックを解説します。

本セッションでは、プロダクト開発に携わるようになって見えてきた知見をもとに「SREだった頃の自分ができていなかったオブザーバビリティの取り組み」を率直に振り返ります。

長らくインフラ寄りのSREとして運用に携わってきましたが、現在はバックエンド開発を担当しており、SREと開発では同じテレメトリーデータの見方・活かし方が異なることに気づきました。
この二つの視点からオブザーバビリティの理想像を再構築し、具体的な失敗や気づきを通じて「ドメインにダイブする」ことの重要性と、明日から試せる改善のヒントを共有します。

聴講対象

• オブザーバビリティに興味がある方
• テレメトリーデータは取得しているけれど、うまく活用できていない方
• もっとオブザーバビリティを高めていきたいSREの方
• プロダクト開発の現場で、SREと開発の視点のギャップにモヤモヤしているバックエンドエンジニアの方​

re:Invent 2024で登場したEKS Auto Modeは、ワーカーノードや一部Controllerの管理から解放され、構成とコストを自動で最適化してくれる“次世代のEKS運用モデル”です。

しかし、ノードが21日以内で停止する、稼働状況に従ってノードが統合される、などAuto Mode特有の仕様も多く、導入には慎重なインフラ設計が求められます。

本セッションでは、24時間365日稼働、かつエラーが許されない金融ミッションクリティカルシステムでEKS Auto Modeをどの様に導入したのか、その裏側をリアルに公開します。

設計の工夫、想定外の落とし穴、チューニングのコツなど、“本番導入したからこそ語れる知見”を余すことなくシェアします!
ECSを使っているけどEKSが気になっている方、Auto Mode導入を検討している方などに必見の内容です!

僕は、2018年のJAWS FESTA OsakaでJAWS-UGに出会って以来、コミュニティに魅了されてきました。
JAWS DAYS 2020から始まった大型イベントのクリエイティブ制作は、毎年の経験を経て、最近では、インフラエンジニアながら、AWS Summit のブースデザインや 自社のイベントノベルティ制作もやっています。
前半10分は、ポートフォリオを用いて、YouTube動画配信、RPGツクールによるドット絵マップ、立体造形などをご紹介します。
後半10分では、これまで携わった大型 12 イベント、11 支部のロゴ制作支援、計 16 ロゴ制作、30 以上のノベルティ発注で培ったベクターロゴ制作手法や、ノベルティ発注のハマりどころ、大判プリントのコツなど、大型イベントだけなく、ちょっとしたイベントでも使えるデザイン寄りのイベント運営ノウハウを共有します。

Amazon Quick SuiteのAIエージェント、Flows、Automate機能を使ってBIに関わる業務を促進させるための案を発表します。

AWS Security Hub CSPM どこから始めて良いのかわからない、運用しているけれど findings が多すぎてどうしたら良いかわからない
そんな方々にこのセッションを捧げます。

Security Hub CSPM のそれぞれの機能説明をするとともに Security Hub CSPM 未設定の AWS アカウント を用意し、一から設定手順や機能ごとの特徴を実際に手を動かしながら説明していきます。
長年 Security Hub CSPM を運用してきた中で、設定する/しないの考え方や組織規模やアカウント数に応じた考え方や、適用すべきセキュリティ基準やバージョンアップ時の注意点など AWS Security Hub CSPM を運用するために必要なことを一通り学ぶためのワークショップです。