プロポーザル

本セッションでは、100近いマルチアカウント環境でSecurity Hubを導入・運用する際に遭遇した課題と、その解決のために実施した工夫についてお話しします。複数のAWS Organizationsにまたがる環境では、設定統一化の必要性という課題があります。また、高頻度のセキュリティ検知通知が一つのSNSトピックに集中し、配信レート制限超過で自動停止する問題にも遭遇しました。その課題に対し、配信ポリシーの最適化やサービス別の通知設計による工夫でSNSトピックの問題を解決し、運用にあたり現場とのコミュニケーションでの取り組みにより課題を乗り越えた手法をお話しします。

AWSを使ったシステム開発・運用が当たり前になる中で、サービスの追加や構成変更を重ねるうちに、「なぜこの金額になっているのか分からないAWSコスト」を抱えたまま運用を続けている現場も少なくありません。
本セッションでは、AWS Billing and Cost Management MCP Server を実務で活用したことをきっかけに、自分たちのAWS環境とあらためて向き合い、コスト構造を一から整理・見直した実体験を共有します。
日々の運用の中で見落とされがちなコストポイントについて、なぜ気づきにくかったのか、どのように把握・整理していったのかを現場視点で解説します。
公式なベストプラクティスの紹介ではなく、実際の運用を通じて得られた気づきをもとに、AWSをこれからも安心して使い続けるためのヒントを持ち帰っていただけるセッションです。

S3のストレージクラスは、仕様差分を十分に理解しないまま運用へ組み込むと、設計や自動化に影響を及ぼすことがあります。本セッションでは、S3の各ストレージクラスを実運用で扱う際に押さえておくべき仕様と、運用設計・自動化における注意点を深掘りします。
特にGlacier系クラスでは、復元処理を伴うことでオブジェクトの扱いが段階的に変化し、API応答やツール連携時の挙動に差分が生じます。こうした状態遷移は、実装時に見落とされがちなポイントです。
さらに、ライフサイクルによるクラス移行のタイミングや、Intelligent-Tieringのアーカイブ層を含めた挙動差分、SFTP経由でのクラス別の振る舞いなど、運用や自動化に直結する仕様も取り上げます。
参加者は「見える」「ある」「使える」の違いを整理し、S3ストレージクラスを正しく扱うための設計指針を持ち帰ることができます。

私たちはAWS公式サンプル『MediaLake』を社内のメディア運用に合わせて日々拡張しています。本セッションでは、機能が『どのAWSリソースの組み合わせ』で実現されているかを実装目線で読み解きつつ、機能拡張を進める上での判断軸（責務の境界、データフロー、権限、運用）と、既存の繋がりを壊さずに変更を閉じ込める進め方を紹介します。CDK定義を起点に、VPC/CloudFront+WAF、API Gateway+Lambda、Cognito+Verified Permissions、DynamoDB→OpenSearch、EventBridge/Step Functionsが認証・検索・処理パイプラインをどう支えるかを追跡します。

「これ本当に必要？」と聞いても、答えはだいたい「必要です」。
そんな状態でコスト削減が進むわけもなく、気づけば請求額だけが増えていきます。
本セッションでは、RI/SP の話を含めた“現場あるある”を題材に、
エンジニア視点で FinOps の現実的な使いどころや、AWS におけるコストと向き合うためのサービスの使い方を考えていきます。

AWSの継続的なアップデートにより、要件に応じてさまざまな構成ができるようになってきています。
その中で今回は、Amazon VPCでパブリックサブネットを無くすことができるのかということを考えてみます。
パブリックサブネットはインターネットと直接通信できるため、これを無くすことによってセキュリティを向上させることができます。
リージョナルNATゲートウェイ、CloudFront VPCオリジンなど、これらのサービスを組み合わせるとどのような構成をとることができるのかについてお話します。

以下のブログの内容をベースにお話する予定です。
https://blog.serverworks.co.jp/no-public-subnet

Platform Engineeringの使命の一つは、開発者チームの認知負荷を軽減することです。この使命の実現に、AIエージェントは大きな役割を果たします。
直近ではAWS Security AgentやAWS DevOps Agentといったマネージドエージェントによって、運用やセキュリティの問題を解決しやすくなりました。またBedrock AgentCoreやStrands Agentsによって、マネージドエージェントでカバーしきれないニーズに応えるカスタムエージェントも構築できます。

本セッションでは、開発者チームがこれらのAIエージェントを活用して認知負荷を軽減する方法を紹介します。そしてPlatform Engineeringの視点から、マネージドエージェントの活用知見の共有や、カスタムエージェントのセルフサービス提供を通じて、開発者チームをどのように支援できるかを探ります。

2025年はAWSで多くのベストプラクティスが変わった激動の年でした。
Regional NAT Gatewayの登場やDynamoDBの複合キーサポートなど、従来のアーキテクチャ設計を根本から見直すアップデートが相次ぎました。

「あれ？今までのやり方で大丈夫？」と感じている方も多いのではないでしょうか。

本セッションでは、2025年の主要アップデートを振り返り、「何がどう変わったのか」をまとめます。
従来のベストプラクティスと新しいベストプラクティスを比較しながら、変更の背景を知ることで自社環境の改善ポイントが見えてきます。
このセッションを皆さんのAWS環境改善のスタート地点にしていただければと思います。

AWSが提供するBottlerocket OSをご存知でしょうか？
BottlerocketはAWSが開発し、セキュリティ標準にも適応したセキュアなコンテナホスティング用OSです。
2025/10に発表され、盛り上がったアップデート「ECS Managed Instances」の裏側でもBottlerocketが採用されています。

金融関連のシステムを運用しているとセキュリティ脆弱性への対応は必須です。
我々が現在運用しているシステムでは脆弱性対応の負荷を下げるために、ECS標準AMIからBottlerocketに乗り換えたという経緯があります。

実際にBottlerocketをドキュメント・ソースコードレベルで精査した上でプロダクション導入し、
運用を行っている経験から、Bottlerocketの設計思想やECS環境でのBottlerocket導入ノウハウについて語りたいと思います。

Step Functionsの開発において、各ステート(Ex. Lambda関数のUT)は書けても、ワークフローとしての結合テストは「デプロイして手動確認」になりがちではありませんか？

2025年11月の「TestState API」アップデートで、この手動作業から解放されます。 これまで自動化が困難だったASLのロジック検証ができるようになるに加えて、 デプロイ不要での即時実行やモック機能により、これまで手動確認に頼らざるを得なかった範囲を、コードベースでの担保ができるようになりました。

本セッションでは、TestState APIの基本的な使い方に加えて、サンプルアーキテクチャでのデモを交えて解説し、既存手法との比較を通して、Step Functionsの新しいテスト戦略についてお話しします。

3年前の異動でそれまで関わって来なかったクラウド基盤を利用したシステムの開発維持を担当するようになりました。初めてAWS認定を取得し、その年のFestaで5分だけの登壇を果たしました。その頃から、地元にJAWS-UGがないことは知っていました。そもそもJAWS-UG以前に地元はコミュニティ過疎県でした。数ヶ月で片手で数えるほどしか勉強会がなく、同じ関東の東京の100分の1の規模でした。「なければ自分で地元に作る」そう決めてから、全国イベントにとどまらず日本全国の各支部を飛び回り、登壇し、運営メンバーと夜な夜な密な議論を重ね、つながりを作り、地域支部運営の勘所を学びました。そして、今年、ついに立ち上げの日を迎えました。泥臭いリアルな取り組みとこれからについてご紹介し、地域支部運営のみなさんとともに学びながら、新たな運営者の背中を押すセッションを目指します。

2025年、初心者支部のコンセプトである他支部への橋渡しをするため、
JAWSUG紹介本企画を立ち上げさせて頂きました。
https://sites.google.com/view/2025jawsbeginner/%E3%83%9B%E3%83%BC%E3%83%A0
認知度の向上のため実施した告知や、実際の同人誌作成に関するノウハウ、実際の費用感も全て含め作り方と、
作った反響(2025コミックマーケット、DL数など)をオープンにお話し、2026年以降にも参加してみたい!
知らなかったから読んでみたいなど、改めて本企画に対して思っていただけるような話をさせていただければと思います。

負荷試験の実行環境をサクッと立てられるDLT。構築が手軽で、実行時にしか費用がかからない点や、JMeterとの互換性がある点が魅力的です。
しかし、JMeterで作ったテスト計画をいざ実行してみると、「一部のパラメータが無視される」「タイマーの挙動が違う」「読み込ませたCSVを最後まで完走してくれない」といったトラブルがありました。

このセッションでは、30万人の異なるユーザーのアクセス集中をDLTで再現し、実際にリリース前のプロダクトに対して負荷試験を行った手法をお話しします。

2025 年 12 月 2 日、Amazon Nova Act の一般公開が発表されました。人間向けのマニュアル作成・共有システム『Teachme Biz』を提供する者として、Nova Act が人間の代わりにマニュアルに沿って仕事をしてもらえると非常に嬉しいです。

しかし、私が Nova Act で人間の代わりにマニュアルに仕事を実際にさせてみようとしたところ、様々な課題に直面しました。

・日本語の読み取り精度が不十分
・UIの変更によわい
・勝手に開始される無料トライアル

本セッションでは、前半に「Nova Act とはなにか」「どう利用を開始し、一体、何が便利なのか」を紹介した後、後半では人間向けのマニュアルどおりに仕事ができるのかを実演し、現時点での課題、乗り越えるべきポイントや Tips を解説します。

シフトレフトという概念をご存知でしょうか？
シフトレフトは、テストを開発プロセスの早期に移し、問題を早期発見することを重視する考え方です。

IaC（Infrastructure as Code）の文脈においても、問題をデプロイ前に検知したいという動機から、いわゆる「シフトレフト」を目指し、静的解析ツールの導入に取り組みました。

しかし実際には、要求をすべて満たす静的解析ツールが存在しなかったり、ルールや設定をチーム全体に配布・運用する難しさがあったりと、単純にツールを導入すれば解決する話ではありませんでした。

本セッションでは、CloudFormationを利用するチームで静的解析を導入した背景と狙い、直面した課題、そして最終的にどこを落としどころとしたのかを共有します。

弊社が運営するサービスは日本だけでなく、韓国・台湾にも展開しています。本セッションでは、AWSだからこそ実現できたグローバル展開を実現する設計や知見を紹介します。
・マルチリージョン戦略：JP/KR/TWの分割理由
・アプリケーション設計：バイナリ、コンテナ戦略
・データ設計：データ分離・共有戦略、DynamoDB/RDS/Redis 設計
・デプロイ戦略：複数リージョンへの安全なデプロイ
・国際化：i18n対応の実現方法
・レイテンシ・UX：CDN戦略、キャッシュ最適化
・コスト最適化：運用コストの課題と対策

AIエージェントを設計する中で、「記憶をどう持たせるか」は必ず直面する悩みです。
実際に Amazon Bedrock AgentCore を使って検証を進めると、短期的な会話履歴と長期的に保持すべき情報の切り分けや、保存先の選択によって挙動や運用性が大きく変わることが分かりました。
本セッションでは AgentCore の Memory 機能を題材に、短期・長期メモリをどのように分離し、どこに配置すべきかを設計視点で整理します。S3、マネージドメモリ、外部データストアといった選択肢を比較し、それぞれのメリット・デメリットや、実際に試して分かった失敗しやすいポイントを紹介します。
機能紹介に留まらず、「何を覚えさせ、何を忘れさせるか」を判断するための考え方を持ち帰ってもらうことを目的としたセッションです。

私はJAWS-UGの勉強会に初めて参加・登壇したのが2年前であり、そこから2年間様々な勉強会・カンファレンスに参加してきました。

その過程で様々な人と出会い、AWS Community Builders等の素晴らしい表彰をいただきました。

AWS DevDay, AWS CDK Conferenceなどの比較的大きなカンファレンスで登壇することもありました。

2年間マイペースにJAWS-UGと関わり続けた中で感じたコミュニティの良さと、コミュニティとの距離感について自分なりの考えをお話しします。

AWS Digital Innovation Program（DIP）に参加した、地方にこだわる某金融機関の情報システム部員が登壇。
「Working backwards（顧客中心に考える）」（WB）との出会いで、仕事の向き合い方や考え方（人生）がどう変わったのか。
お客さま視点をとことん突き詰めた結果、どうして、個人として地方の農業系中小企業向けにAWSでシステムを作ることになったのか。
なぜ、AWSの力が必要だったのか。
個人としての限界を感じ、その後にとった行動はなにか。
地方の農業系中小企業、金融情シス、AWSといった全く異なる背景を持った企業、サービス、人がどのよう混ざり合い、どのような結果を起こしたのか。
その先の目指す姿は何か。
今回のテーマである「Mashup for the Future」でなければ話す意味がないリアルな話をお届けします。

AWSには様々な目的別のデータベースサービスが存在しますが、企業の基幹業務やWebアプリケーションの中核を担うのは、依然としてRDBMSが中心になります。
本講演では、利用頻度の高いRDSとAmazon Auroraに焦点を当て、PostgreSQL/MySQL等のOSSエンジンから、Oracle/SQL Server等の商用エンジンまで、その特性と使い分けを網羅的に解説します。

「Aurora独自のアーキテクチャが活きる場面とは？」「クラウド移行におけるDBaaSの役割は？」など、コスト・性能・可用性の観点から各選択肢を徹底比較。
NoSQLとの適切な役割分担にも触れつつ、現代のシステム要件に即した「失敗しないRDBMSアーキテクチャ」を設計するための決定版ガイドを提供します。