【タイムスタンプ付き】JAWS-UG千葉支部 x 彩の国埼玉支部 LTバトル形式勉強会 【51歳ぼっち】後編

麻生久美子「海はあるのか？埼玉に。海はあるんかって聞いてんだよ！」（「翔んで埼玉」より）

7/9にJAWS-UGの千葉支部 x 彩の国埼玉支部 LTバトル形式勉強会が開催されました。51歳ぼっちのおじさんが初参加でJAWS-UGを見てきたぞ。今回のその後半戦！

自己紹介

群馬生まれ、埼玉在住のおじクラ＠51歳（レベル2）です。
名前の由来は「おじさんがクラウドを構築してるからおじクラ」。

本記事は全2回に分割して記載します（後半のLT3本についてのレポートです）

タイムテーブル（時刻をクリックすると該当のLTがすぐに見れます）

00:00　 OPトーク
13:00　 「マルチアカウント環境に触れて得た私の知見」
23:15　 「ムダ遣い卒業！FinOpsで始めるAWSコスト最適化の第一歩」
35:36　 「Amplify Gen2 で OpenSearch を併用したファセット検索の実現」
47:10　 「ETLに憧れて無理やりAWS Glueでデータ処理した話」
1:06:01 「mysqlコマンドを実行したいだけなのに〜AWS Step Functionsと歩んだ脱Jenkinsへの道〜」
1:27:10 「ベスプラに憧れてIAMユーザーを集約した話 -Identity Center × Jump アカウント × CDK で実現するマルチアカウントのアクセス管理-」　
1:47:30　クロージング

中堅LT (200 or 300レベル)「ETLに憧れて無理やりAWS Glueでデータ処理した話」

• 登壇者: 彩の国埼玉支部
• 概要: 顧客からの依頼を受け、DataDogの複数アカウントにあるユーザー情報をExcelで管理可能な形式に整えるための仕組みをAWS Glueを活用して構築した実録レポート。LambdaやStep Functionsと組み合わせて処理フローを実現し、S3に出力されたJSONデータをGlueでCSVに変換するまでの一連のプロセスを紹介。Glue活用におけるデータ整形の難しさと、Lambdaによる柔軟な連携の強みが語られた
• 印象に残ったポイント
  • 前職でログをETL処理するためにGlueを検討したことを思い出した（結局は人的リソースの都合で頓挫したがｗ）。この発表では、生成AIを用いてLambda関数を設計し、データ取得と加工をそれぞれ別の関数で行う構成が印象的。スマートに見えて、その裏では泥臭い試行錯誤が繰り返されており、Glueを「簡単に使えるツール」と見誤ると痛い目を見ることがよくわかる
  • 特に、Glueを活用するためには事前にデータ整形を丁寧に行わなければならず、「ただ突っ込めばなんとかなる」は通用しないことが明確になった点は、地に足のついた学びとして胸に刻みたい
    また、Lambdaを利用すればIGWなしでも外部からデータ取得が可能という点は小さな驚き。地味だが確実に役立つ知見である
  • 今回の構成図や説明は、GlueやStep Functions、Lambdaの実運用イメージを掴むのに非常に役立った。ETLというテーマに「憧れて」取り組み始めたという話からも、現場でのモチベーションの重要性と、それを支える設計・構築の積み上げの大切さを実感できる登壇だった
  • マルチアカウントのLTとは異なるが、こういった考えも大切（最終的にお客に価値が届けばよし）

大将LT (400レベル)「mysqlコマンドを実行したいだけなのに〜AWS Step Functionsと歩んだ脱Jenkinsへの道〜」

• 登壇者: 千葉支部
• 概要: Jenkinsで管理されていたレガシーなバッチ処理環境を、Step FunctionsとFargateを用いたクラウドネイティブな構成へと移行した実例。主に定時実行されるrakeコマンドやMySQLコマンドのバッチ処理が対象で、特にMySQLコマンドのコンテナ実行には接続情報の扱いや環境変数の設定など、細かい技術的工夫が求められた。ECSのスロットリング対策としてステップ関数に遅延処理を入れるなど、実運用を意識した実装も見られた
• 印象に残ったポイント

  • Jenkinsって使ったことがないので、ここまで苦労するものなんだなと驚いた。特に「おまけ作業だったはずがメインになる」という話は、現場あるある過ぎて頷かざるを得ない

  • 今回の話はまさに「バッチのクラウドネイティブ化」の好事例。LambdaではなくFargateを選択した理由や、環境変数の展開に四苦八苦するあたりは、誰もが通る道をリアルに語ってくれていて刺さった

  • 「URLを分解して環境変数に展開」するという変態的（褒めてる）アプローチや、「結局、bash -lにして展開成功」までの試行錯誤は笑いながらも勉強になる。まさに泥臭い努力の結晶

  • 生成AIとの壁打ちや、Amazon Linux 2023の仕様に振り回されるあたりも共感ポイントが多く、「どこの現場でも試行錯誤してる方がいるんだな」と実感。個人的には、通知整形の工夫やECSのスロットリング対策としてステップ関数に遅延を入れた話も地味ながら実用的で勉強になった。生成AIの使いどころや、MySQLシェルで失敗→URL分解という試行錯誤の過程も、もっと詳しく聞きたかった

大将LT (400レベル)「ベスプラに憧れてIAMユーザーを集約した話 -Identity Center × Jump アカウント × CDK で実現するマルチアカウントのアクセス管理-」　

• 登壇者: 彩の国埼玉支部

• 概要: IAMユーザーの分散管理に伴う運用課題を背景に、AWS IAM Identity Center、Jumpアカウント、およびCDKを組み合わせたマルチアカウント環境におけるアクセス管理構成の実践例
  Identity Centerを用いた一元管理の理想と、現場の制約（外部ベンダーのIDP登録不可、IAMユーザー文化の残存など）とのギャップを埋めるために、Jumpアカウントによる集中管理方式を採用。さらに、CDKとGitHub Actionsを活用し、IAMユーザー作成・AssumeRole構成の自動化とセキュリティ制御（MFA強制、IP制限等）を実現。現実の制約を踏まえた実装知見を共有。

• 資料: https://speakerdeck.com/masakiseyama/besupuranichong-reteiamyuzawoji-yue-sitahua
  https://qiita.com/pohd_ccoe/items/a3b135717e2d09bacd14

• 印象に残ったポイント

  • 「IAMユーザー非推奨」というベストプラクティスを正面から捉え、現場実装に落とし込んだ構成がとにかく実践的。Control Towerでは非推奨とされるJumpカウント方式も、運用実態とベンダー制約を考慮すれば納得のアプローチ。特に、「外部ベンダーがIDPに登録できない問題」や「40以上あるAWSアカウントの管理」の苦悩に深く共感。
  • JumpアカウントへのIAMユーザー集中管理、AssumeRole連携、MFAの強制適用といった構成は、「やるべきこと」を地道に積み上げている印象。構成管理にCDKを採用した点も、将来的な保守性・拡張性に対する誠実な向き合い方が伝わる。「使ってみたかった」と語るCDK導入動機にも共感（わかるｗ）
  • 最後のまとめスライドにもあるように、「教科書通り」だけでは運用できないのが現場のリアル。ベストプラクティスを“緩める力”を持つことの大切さを再確認させられた。Qiita記事の今後のアップデートにも期待したい

クロージング

JAWS-UGのLT大会に初めて参加。内容が翔んで埼玉を彷彿とさせるクスリとさせられる地域ネタがあって面白かった。年1回ぐらいこういうイベントがあると楽しいかも。何はともあれ、ここまで準備を進めたコミュニティスタッフの皆様お疲れ様でした！