プロポーザル

AWS 上でサーバーレスなデータ処理フローを設計する際、Lambda や Step Functions、Athena などの役割分担に悩むことは少なくありません。本セッションでは、Google Cloud における Cloud Run functions・BigQuery・Workflows の構成を参照点とし、これを AWS の API Gateway、Lambda、Step Functions、Athena／DynamoDB に置き換えて再構成します。なぜ AWS では API 入口、処理、状態管理、データ保存を明示的に分離する設計が求められるのか、どこで設計判断や運用負荷が発生するのかを具体例で解説します。AWS を前提としつつ、他クラウドの設計思想を取り入れることで、より納得感のあるアーキテクチャ設計を行うための視点を持ち帰ってもらうことを目的とします。

お客様との対話の中でセキュリティやコンプライアンス担当の方が出てきて商談が進まない、ということはありませんか？
本セッションは、ゲーミフィケーション的に一緒に参加者と一緒にあるある質問に対する対応や落とし穴を解決していく時間です。登壇者が架空の企業に対する商談シナリオをもとに様々な質問を提示、それに対し参加者で対応を一緒に決めていくゲームを行い、その質問の背景などを明らかにしていきます。
なお、コンプライアンスに対する深い知識やAWSの技術経験、PCなどは不要、スマホがあればどなたでも参加できます。

政府情報システムはシステムライフサイクル5年（基本）に沿ってシステム換装する必要があり、ガバメントクラウドを利用する場合は要求される、システムのモダン化を次期、次々期と中長期的な視点で検討・実装していくこととなります。

ここでのモダン化は一般的なものではなく、ガバメントクラウドで定義された特有の"モダン化"であり、当クラウドを利用する上での「制約」となります。例えばオンプレミスのWindows File Serverをガバメントクラウド（AWS）へ移行する際にマネージドサービスのAmazon FSxを単純に選定すれば"モダン化"となるのでしょうか。"モダン化"のシステム設計や顧客への説明などに苦労された方はいるのではないでしょうか。

本セッションでは、私のガバメントクラウド（AWS）へのシステムの移行事例を踏まえて要求される"モダン化"への中長期的な対応戦略をポイントで解説いたします。

生成AIの実装において、GPUコスト高騰への解として期待される「AWS Neuron（Trainium/Inferentia）」。本セッションでは、その実戦投入の可能性を徹底解説します。

本セッションでは、コスト効率に優れたこのチップを使い倒すべく、徹底的な検証結果を共有します。 単なる推論だけでなく、モデルごとのコンパイルの境界線、ファインチューニングの実践、オブザーバビリティ確保など、泥臭い検証結果を共有。さらにre:Invent 2025の最新機能も速報的に検証します。

インフラエンジニアには「コスト最適化の現実解」を、MLエンジニアには「AWS特化チップの攻略法」を。両視点からNeuronの"現在地"を解き明かします。

以下のテックブログのNeuron関連の内容を、エッセンスと最新の検証結果を凝縮してお届けする予定です。

https://zenn.dev/p/exwzd

AWSのマネージドサービスは可用性や運用負荷低減の観点から、システム開発を得意としない事業会社のシステム構築に多くのメリットをもたらしています。その一方で、近年では有用なマネージドサービスが相次いで停止し、利用していたサービスの移行に悩んでいる方も多いのではないでしょうか。
当社では事業部門が主体となったIoTプロジェクトにおいて、マネージドサービス・サーバレスサービスをフル活用していますが、停止・終了するサービスの移行判断に悩みながらDevOpsに挑戦しています。この発表では、ビジネス上の制約・チームスキルの熟達度を考慮しながら、終了停止するサービスとどう向き合い、何をしたのか（しなかったのか）を、実体験をもとにお話いたいします。

2025年のJAWS DAYS初参加から1年。
私は2025年3月のJAWS DAYS参加をきっかけにJAWSの勉強会に参加するようになりました。
当時は勉強も殆どしておらず、社外のコミュニティ活動にも一切参加していませんでした。
JAWSでの勉強会に参加するようになってから自分に起きた変化とこの1年間について振り返りたいと思います。
JAWS DAYS参加後の変化
・Qiitaに投稿開始(5月から30週連続投稿)
・LT登壇開始(登壇回数15回/毎月登壇)
・APN企業への転職
・初心者支部運営

今回のJAWS DAYSに参加される方の中にはきっと去年の私のような右も左もわからないけど、とりあえず来てみたという方もいらっしゃるかもしません。そういった方々と、そして去年の自分にこの1年の変化を伝えると共に、コミュニティ初心者の方にとってのモチベーションとなったら良いなと思います。

日経電子版は100万人以上の有料会員を持つ大規模サービスです。またニュースサービスという特性上、大規模災害時でも報道を続ける必要があります。
しかし従来のシステムは東京リージョンに構築されており、関東全域が被災すると報道を継続できない課題がありました。そこで、他リージョンに簡易電子版を構築するマルチリージョン構成へ移行しました。
本講演の前半では、バックエンドのマルチリージョン化について説明します。具体的には、Aurora・S3 のレプリケーション機能を用いたデータ転送、ALB を用いたリクエスト制御への取り組みについて紹介します。
後半ではシステムの切り替え訓練について紹介します。プランニングから訓練当日の様子、振り返りまでの流れと、訓練を実施して発覚した課題や改善点を共有します。
本講演を通じて、マルチリージョン構成の実践的な知見と、訓練の重要性について理解を深めることができます。

今さらSESと思われるかもしれませんが、改めて復習の機会にいかがでしょうか！
本セッションでは、実際にSESを運用して感じた抑えておくべきポイントについて解説していきます。

• SES API v1とv2の違い
• 設定セット（Configuration Set）で実現できる様々な機能
• クォータ管理
• Virtual Deliverability Manager
• 専用IPの使いどころ
• グローバルエンドポイントを活用した障害対策

など実運用で役立つ知見をお届けします。
実際のSESを用いたAWSアーキテクチャも合わせて紹介します。

これからSESでメール送信を始める方も、すでに運用中の方にも、今さらSES？な方にもオススメのセッションだと思います！
※メール受信には触れません

AIサービスを使ってAI-DLCを実践する際によく語られるのは「新規のプロダクトを作成」するときやプロトタイプを高速で作る事例が多くあります。ただ、実際の現場においては新しいプロダクトの作成だけでなく既存のプロダクトに対して機能の追加、改善の現場も多くあります。そういった「制約の多い」プロダクトでAI-DLCを使ってみたらどうなるでしょうか。
個別の修正課題についてAI-DLCの手法を使てみた場合、大きな機能追加などの改善タスクが発生したときの場合で実践してみた事例の紹介を行う。

生成AIの企業導入が加速する中、技術的な革新と責任ある運用のバランスが重要な課題となっています。その中、AWSは特に責任ある生成AIのサービスを多角的に提供しています。
本セッションでは、Amazon Bedrockが提供する責任あるAI機能を中心に、実践的な実装方法と活用例を紹介します。

主な内容:

• Bedrock Guardrails: フィルター基板の安全性制御の実装
• Bedrock 自動推論: ガードレールの正確性を補強するポリシー作成
• Bedrock Agent Core Policy: エージェントとツール間の動作制御とガバナンス定義
• Bedrock Evaluation・Bedrock Agent Core Evaluation:モデル・RAG・エージェントの性能とバイアス評価の自動化
• 各機能の特徴比較と適用シナリオ
• 責任あるAI運用の統合アプローチ

AWSのIAMやセキュリティ設計は、ベストプラクティスを守っていても、組織やプロダクトの成長とともに破綻することがあります。
その多くは、Cloud Infrastructureチームが「AWSセキュリティの最終責任」を一手に抱え込んでしまう組織構造に起因します。
本セッションでは、IAM設計が破綻し始める兆候や、実際に組織構造や役割分担を見直してきた事例をもとに、Cloud Infraチームと開発チームの責任分担をどのように設計すべきかを整理します。
IAMやSCPを最低限のガードレールとして活用し、役割と責任を分離した持続可能なAWS運用の考え方を共有します。

弊社はワークフローSaaSメーカーで、AWSをビジネスの中心に置いているわけではありません。
それでも過去3年連続でre:Inventにメンバーを派遣し続けています。
なぜなら、単なる技術カンファレンスを超え、人生を変えるほどの「コミュニティの価値」を体感できる場だからです。
最新技術や熱気も魅力ですが、私が投資を惜しまない最大の理由は、現地での高レイヤーのエンジニア・起業家たちとの濃密な交流です。
re:Inventでの出会いをきっかけに、コミュニティ関わり方が劇的に変わり、社内のメンバー育成にコミュニティが欠かせない存在となりました。
本セッションでは、「re:Inventがもたらしたコミュニティの魔力」とその軌跡を、エピソードとともに紹介します。
re:Invent未経験者やコミュニティに距離を感じている方にこそ聞いてほしい——「絶対行きたい！」と思えるワクワクをお届けします！

AWS re:Invent への参加を支援する All Builders Welcome Grantに採択された2人が、
・All Builders Welcome Grantに応募したきっかけ
・re:Inventを現地で体験して感じたこと（セッション／人との出会い）
・参加後に起きた変化と、コミュニティ活動への広がり
を実体験ベースでお話しします。
海外カンファレンスに興味はあるがハードルを感じている方、コミュニティ活動に一歩踏み出したいと考えている方に向けて、次の行動につながるきっかけになることをお伝えします。
もちろん次回のAll Builders Welcome Grantへの応募を検討している方にも参考になる内容です。

弊社が運営するマッチングアプリでは、2022年にAmazon EKS on EC2の導入を開始して以来、基盤構成・デプロイ戦略・運用方式を継続的に改善してきました。
本セッションでは、その3年間で取り組んだ実践内容を紹介します。

Amazon ECS on Fargateからの移行、GitOpsによる運用標準化、Argo RolloutsとIstioを用いたカナリアリリース、KEDAによるバッチ処理最適化、検証環境の自動生成、クラスタ二重化による安全なバージョン更新、OSS更新停滞による運用負債や延長サポート対応などの実運用だからこそ得た学びが主なテーマです。

大規模toCサービスにおけるEKS導入と長期運用の知見を共有します。

電話問い合わせ対応は依然として現場の大きな負荷であり、「できるところから自動化したい」「オペレーターが必要な対応に集中したい」という声が高まっています。本セッションでは、Amazon Q in Connect を軸に問合せの一次受付けを自動化するソリューションを設計・構築した事例を、構成選定の背景から整理し、設計図で全体像を解説します。さらにデモ動画で導入後の運用イメージを提示し、現場での適用ポイントも具体化します。加えて、実装時に「そのままでは要件を満たせない」壁として現れる、Contact Lens 等の日本語対応不足を Amazon Bedrock で補完した例や、応答速度・ナレッジ更新頻度などマネージド仕様で制御しづらい課題への現実的な対処と運用の落としどころを、どこまで工夫で改善できるかの観点で改めて実例ベースで丁寧に共有します。登壇時点の最新機能・仕様に基づき説明します。

登壇者は AWS パートナー企業のテクニカルサポート部門で従事しており、リセールアカウントの提供仕様の管理部門でもあります。
立場上、多くの AWS からの緊急の通知を受けており、都度お客様へご案内し、場合によってはお客様と共同で対処していますが、さまざまなケースが存在します。
EC2 インスタンスの悪用、濫用である Abuse report は古くから言われている通りですが、Amazon SES や Amazon Pinpoint などメール送信に関連するもの、アクセスキーの流出が疑われるものなど多岐にわたります。
利用サービスや AWS アカウント自体の停止措置、あるいは AWS 利用料の高騰など、正しく対処しないと起こりうる被害を含めたいくつかの事例をご紹介し、正しい運用や対処のためにどのような考え方が必要かを、昨今の AWS 自身のサービスアップデートも考慮しつつお話しします。

2025年10月、金沢で開催した「JAWS FESTA 2025」を、実行委員長として一次情報に基づきレポートします。

会場手配、チームづくり、予算、サポーター募集、プロポーザル募集、管理ツール、作成してAWS上で運用したツール、配信、導線設計、当日オペレーションとトラブル対応まで、準備・トライ・成果・成功・失敗を整理してお話しします。

特に、スタッフ募集で掲げた「未経験者優先」を、どう走り切ったか、どこがうまくいかなかったか（オンボーディング、役割分担、ドキュメント、コミュニケーション）を共有します。

開催後の参加者アンケート、スポンサー、運営側からの評価も踏まえ、開催地もチームも毎回変わる中でも、加藤が次につなげたい「哲学」と「メンタル」を抽出してお持ち帰りいただきます。次の全国イベントへ挑戦する人の背中を押せる内容にします。

「コミュニティに参加すると良いことがある」とは言われるが、具体的に何が起きるのか？
10年近くのコミュニティ活動で見えてきたのは、コミュニティが埋める3つのギャップでした。

情報・人脈・そして「経験できない世界を知る」認知のギャップ。
他人の経験と自分の経験をマッシュアップすることで、自分の視界や世界が広がり、結果としてキャリアが動きました。

今はここに生成AIとのマッシュアップが加わっています。コミュニティで得た情報や自分の経験を、生成AIの力を借りて言語化・整理し、アウトプットへ変える。このサイクルがAWSの学習と発信を加速させています。

中小企業からStripeへ移り「知らない世界は想像すらできない」と痛感した経験と、関西からリモートで、Stripe / CircleCIなどの外資も含めた複数の会社を歩んできた経験をもとに、コミュニティと生成AIのマッシュアップを紹介します。

AWS環境でInfrastructure as Code（IaC）を採用する際、どの実行基盤を選ぶかによって運用負荷と構築負荷が大きく変わるという課題があります。
本セッションでは、ローカル実行やCloudShell、CI/CDツール、自前サーバ、Terraform Cloudといった代表的な実行基盤を比較し、運用負荷・構築負荷・ユースケース別の適切な選択基準を共有します。

パブリックIPv4課金やVPCエンドポイントのコスト増は、多くの現場で切実な課題です。本セッションでは、IPv6活用を主軸に、これらレガシーなIPv4依存からの「卒業」を目指す次世代Web配信アーキテクチャを提案します。
2025年発表の「Regional NAT Gateway」や「ECS Express Mode」、CloudFrontのIPv6オリジン/VPCオリジンサポート等の最新機能をフル活用。これらを組み合わせ、自社オウンドメディアのブログ配信環境で実際に運用している"実戦投入済み"の令和最新版インフラを紹介します。
当日は、アーキテクチャの全貌に加え、VPCエンドポイント廃止によるコスト削減効果、IPv6移行における技術的ハマりどころと、現時点でのワークアラウンドなども紹介します。