【イベントレポート】JAWS-UG東京 AWS Community Builders Night #jawsug_tokyo

いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！

今回は2025.04.15（火）に開催したJAWS-UG東京 AWS Community Builders Nightへ参加しましたので、アウトプットとしてイベントレポートを執筆しました。

初見の方でもサクッと読めるように平易な表現で執筆しておりますので、お気軽にお読みいただければ幸いです。

誤字脱字、わかりづらい表現、認識相違などは極力なくすように心がけています。そのうえで、リアルタイムで執筆しておりますので、誤字脱字、わかりづらい表現、認識相違などがあるかもしれません。

イベントページ

目次

• AWS Community Buildersの紹介
• LT
  • 40代のおじさんがAWS Community Buildersになってみた
  • フロントエンドも盛り上げたい！フロントエンドCBsとAmplifyの軌跡(仮)
  • CBになったのでEKSのこともっと知ってもらいたい！
  • AWSで作るセキュアな認証基盤 with OAuth mTLS
  • CDKとCloudFormation どちらが好み？
  • オブザーバビリティとAWS X-Ray
  • SREの視点で考えるSIEM活用術 〜AWS環境でのセキュリティ強化〜
  • 社内でブログ執筆者を増やしたい！Bedrockにネタ出し&レビューをしてもらう！
  • Amazon Polly の現状と生成エンジン登場に見た大きな可能性
  • AWSログを活用したLLMアプリのOps検討
• まとめ

AWS Community Buildersの紹介

• 自己紹介
  • AWS Japan所属のシニアコミュニティマネージャーの方
• Community Builderの比率
  • 約1万人がウェイティングリストに登録
  • 約4000人が本申請、約1000名がCBsに採択された
    • 国内では69名がなられている
  • AWS Community Programの一つ
    • JAWS-UG運営に参加すればUser Groupに所属できる
    • （個人的意見）私もJAWS-UG運営になるからそろそろメールが来るんでしょうね
• Community Builder
  • 年に1度の申請でアウトプット活動を審査
  • CB間でのやり取りはSlack・LinkedInの場合
  • Community Builder Team4名で運営している
• (補足）アウトプットとは
  • 他のAWSユーザの手助けとなるアウトプット
  • （個人的意見）ビジネス構築につながるアウトプットが少ないから今後増やしていかないとなぁ
  • パートナープログラムとは独立しているため、受賞してもなれるわけではない
• まとめ
  • グローバルチームによるケア：Slackチャネルを利用しよう
    • 日本語用のチャネルもあったりする
  • 登録したメールアドレスだけでなくLinkedInのメッセージを利用する場合も
  • （個人的意見）英語でのコミュニケーションを行うために学ばないとなぁ

LT

40代のおじさんがAWS Community Buildersになってみた

参考サイト

• 自己紹介
  • JAWS-UG名古屋運営の方
  • ハリネズミ好きのCBの方
  • AWS歴3年、コミュニティ歴1年半の方
• 前提
  • オンプレの客先常駐案件にJoinしていた
    • 案件ロックイン・顧客ロックインしていた
  • オンプレ一辺倒だったところからクラウドにチャレンジした
• はじまり
  • JAWS-UG Network支部が初参加
    • テーマとしてre:Invent勉強会
  • Network支部の後、名古屋でもre:Inventがあったため参加した
  • re:Invent参加後、Community Builderを知ったがアウトプットに注力した
    • （個人的意見）ここは私の反省点なんですよね
  • アウトプット活動後、Community Builderにチャレンジし採択された
• まとめ
  • 何事にも遅いということはない
  • AWSサービスの好きなポイントをアウトプットしていく

フロントエンドも盛り上げたい！フロントエンドCBsとAmplifyの軌跡(仮)

• 自己紹介
  • JAWS-UG大阪運営の方
• 前提
  • Frontend部門でコミュニティビルダーになったが登録人数がどのくらいいるのか気になった
  • グローバルで見ると139名、割合として6.2％だった
    • 日本国内に限定すると9名
  • 日本には唯一フロントエンドコミュニティがある
    • （個人的意見）サービス単位のコミュニティがあるのがうれしいですね
• Amplify Gen2とは
  • Typescriptでバックエンドを定義することができる
    • カスタムリソース含めCDKで定義することができる
    • （個人的意見）テンプレート化するのも楽ですね
  • ユーザごとにシークレットを管理できるため開発者体験を向上できる
    • （個人的意見）ハンズオンを学びながら簡単にツールを作ってみよう
• 直近のアップデート
  • APmplify AI Kit
    • 20行から30行ほどでアプリケーションを構築することができる
  • AmplifyへのWAF導入も簡単に行えるようになっている
    • エンタープライズ環境でもAmplifyを利用することができる
  • （個人的意見）Ampliyfyも触る触る詐欺しているので触らないとなぁ

CBになったのでEKSのこともっと知ってもらいたい！

• 自己紹介
  • KESを用いた金融機関向けサービス基盤対応を行っている方
  • dev.toブログ執筆したらマグカップをもらうことができた
• Kubernetesとは
  • コンテナオーケストレーションプラットフォーム
  • 拡張性が高く、独自定義のリソースを構築できる
  • EKSを利用すれば、IAMロールで権限管理が行える
• ECS VS EKS
  • EKSのほうが幅広いサービスを利用できるがメンテナンスがめんどくさい
• Kubernetesを勉強するとうれしいこと
  • クラウドネイティブ・OSSに関する理解を深められる
  • AWS以外の知識を得ることができる
  • ハンズオン形式の試験もあったりする
    • 初級レベルはリソース構築、クラスタ管理・セキュリティ全般
      • オンライン受験のみのため自宅環境で可能
      • （個人的意見）貸し会議室を利用するのがベターですよね
      • （個人的意見）LPIC 305/306の前準備として勉強するのがよさそうですね
• まとめ
  • AWSの勉強以外もやってみてもいいのではないか
  • （個人的意見）分かりみが深いですね～
  • （個人的意見）CiscoルータもMarket Placeでそろっているとうれしかったりする

AWSで作るセキュアな認証基盤 with OAuth mTLS

参考サイト

• 自己紹介
  • 株式会社カミナシ所属のエンジニアの方
  • 普段はOAuth関連のRFCを読んでいる
• セキュリティのむずかしさ
  • 幅広い領域の知識を求められる
    • そのうえで認証回りの知識をキャッチアップすることで活用できる場面がある
  • 工場内でのタブレット管理にRFC8705（OAuth mTLS）に利用する
    • 相互TLS認証に対応するためにアーキテクチャを検討する必要がある
• アーキテクチャ検討
  • CloudFront：TLS認証に対応していない
  • API Gateway：実装がめんどくさい
  • ALB利用：信頼ストアの実装を行える
  • （個人的意見）認証回りはきちんとキャッチあぷしたいですね

CDKとCloudFormation どちらが好み？

参考サイト

• 自己紹介
  • JAWS-UG名古屋支部運営の方
• CDKへのモチベーション
  • 名古屋はCDKの町といったポストから
  • 「IaC運用のリアルを語りたい」といったイベントから
    • コール&レスポンスからポストが生まれた
• CDKを選ぶ人が多い理由
  • CDKがデファクトスタンダードだから
  • 今後CloudFormationの普及が必要かもしれない
  • 利用者の声を拾ってみるとコード作成量の多さがネックに
    • コード数が多いのであれば分割という手も
    • コード分割しても読みやすくなるわけではない
• CloudFormationをサポートする機能も
  • IaCジェネレーターを利用すればGUIでコード作成可能
  • （個人的意見）確かにGUI操作でコード執筆できるのは入口としてはいいですね
• まとめ
  • 他のツールと併用してCloudFormationを利用すればより多くの方に利用される

オブザーバビリティとAWS X-Ray

• 自己紹介
  • スカイアーチネットワークスでインフラエンジニアをされている方
  • CloudOperationsでCommunity Builderに選出
• 前置き
  • Welcome Callのクイズ企画に当選した
  • 19％はやくコーディングできるTシャツを取得した
• モニタリングからオブザーバビリティ
  • re:Inventでは125セッション取り上げられていた
  • 従来のモニタリング手法（CPU使用率など）だと調査が必要になる
  • マイクロサービス化・複雑化するシステムだと調査に時間がかかる
    • （個人的意見）秘伝の監視ツールだと対応が厳しくなりますよね
• オブザーバビリティの考え
  • ログ・メトリクス・トレースの考え
  • X-Rayでオブザーバビリティを実現できる
  • X-Radでできること
    • アプリケーションのパフォーマンス分析ができる
    • リクエスト追跡・レイテンシーの特定・エラーの原因特定も行える
    • ボトルネックの特定を行うこともできる
  • EC2・ECS・Lambdaなど統合可能
  • Java、.Netなどの言語で測定範囲を指定することもできる
• 恩恵
  • パフォーマンスが容易になる
  • 設計図を描き起こす必要がない（=コードで管理可能）
    • （個人的意見）オブザーバビリティの入り口としてうれしいですね
  • ビジネス面ではKPIとして使うことも可能

SREの視点で考えるSIEM活用術 〜AWS環境でのセキュリティ強化〜

参考サイト

• 自己紹介
  • 株式会社ココナラ所属のEM
• 導入
  • 2024年末はDDoS攻撃による被害が多数あった
  • プロダクトセキュリティ専門組織が求められる
    • SREが兼任しているが優先度は低くなっている
  • 生産性高く行うことが求められる
• SIEM導入
  • ざっくり言えばセキュリティ領域でのログ分析
  • siem-on-amazon-opensearch-serviceを利用している
• 利用事例
  • WAFログの取得、ELBログの取得だったりを行っている
  • （個人的意見）ログをモニタリング⇒チケット化は楽しそうですね
  • （個人的意見）ビジネスへつなげていっているのはすごいですね
• まとめ
  • キャリアの掛け算からSIEMは面白い
  • 継続的なリファクタリングが必要
  • セキュリティログ分析を通じてサイトの信頼性向上を実現できる
    • （個人的意見）改善活動は本当に重要ですよね

社内でブログ執筆者を増やしたい！Bedrockにネタ出し&レビューをしてもらう！

参考サイト

• 自己紹介
  • NECソリューションイノベータ所属のエンジニアの方
  • AI EngineeringでCommunity Builderに採択された
• アウトプットは人生を変える
  • アウトプットを通じて多くのエンジニアとつながることができる
  • 社内だけでなく社外を見ていくと
• アウトプットに関する課題
  • アウトプットネタが少ない
  • 社内稟議をどうするかなど
    • とりあえずアウトプットネタの課題解決を行っていく
  • アーキテクチャとしてCloudFront⇒Lamdba⇒Bedrockといった構成
• エージェント実装
  • Mastraを利用して実装してみた
  • エージェントを利用することでアイデアだし・レビューの役割分担をできる
• アプリを通じた目指した世界
  • 社内で自発的にアウトプットする人を増やす
  • Qiitaなどのブログ執筆イベントをもっと積極的に行っていく
    • 会社のプレゼンス向上・アウトプットを行っていく
  • （個人的意見）いつ聞いてもすごすぎる方

Amazon Polly の現状と生成エンジン登場に見た大きな可能性

• 自己紹介
  • セゾンテクノロジー所属の方
  • JAWS-UG栃木運営の方
• Pollyとは
  • AWSのコミュニケーションサービスの一つ
  • 自動応答音声システムを利用した音声生成サービス
• 心が躍った理由
  • 2023年の日本語ニューラル女性音声GAされた
    • 当初はぬぐえない違和感があった
  • SSMLでチューニングすることで自然な音声を実装できる
  • プロダクションレベルではアクセント・区切りを入れることが重要
    • （個人的意見）見積標準で利用するのは知らなかったので初耳でした
  • 生成AIも方言を理解している
    • 学術研究やサービスでも利用されている
• 今後の世界
  • 消滅可能性が高い言語がAIによって復活する世界

見積標準について

見積標準についてJourneymanさんからコメント頂いたので追記しました！

Polly実装は特殊な開発工程になるため、Pollu専用の見積標準を策定して開発プロジェクトで活用している

初耳でしたので学びになりました！！

AWSログを活用したLLMアプリのOps検討

参考サイト

• 自己紹介
  • AI部門でCommunity Builderに採択された方
• LLMアプリケーション開発
  • ログを用いてLLMアプリの改善を行いたい
  • Bedrockの機能を用いれば実現できるのではないか
• Model Invocation Log
  • Bedrockの機能（Model Invocation Log）を利用することでログ取得できる
  • ロググループは1つしかないため環境ごとに分離が難しい
    • タグ設定を行えば分離できるが限界がある
  • Amazon Athenaを用いたログ分析を行うことができる
    • （個人的意見）ログ分析ができるのはうれしいですね
    • （個人的意見）メタデータが分かれば何を行っているのかわかりますね
• サーキットブレイカー
  • 閾値指定することで過剰なトークン消費を防止できる
  • CloudWatchとStep Function＋Dynamo DBを利用することで制御もできる
• まとめ
  • 今後もLLMアプリの開発運用は盛んになっていく
  • もしかしたら、環境構築しなくてもいい世界がやってくるかも
  • （個人的意見）私も個人開発してアウトプットしていかないとなぁ

まとめ

AWS Community Buildersに関しては今年チャレンジしたいと思っていましたので、
本セッションを通じてアウトプットへの意欲が高まりました。

そのうえで、資格勉強もひと段落付いたのでハンズオン・個人開発を進めていきたいと思いました。（出来れば月5本以上）

最後まで、記事をお読みいただきありがとうございました！！