雨の関係で実家の買い出しの予定が夕方にずれて、無事参加できるようになったのでオンライン参加しました。
といっても地元愛知では大して降っていなかったのですが、
昨日は関東から家に帰れないかと思いましたが、九州から東の方面へ帰れなかった方々もたくさんいたようで
— hmatsu47(まつ) (@hmatsu47) 2025年8月11日
今日はさすがに佐賀でもオフライン開催は難しそうですね#jawsugsaga
前日から九州など各地で大雨、静岡でも雨量規制で各地の鉄道・新幹線や高速道路が止まったりして大変な状況で。
予想どおりこのイベントもオンラインのみの開催に変更されました。
なお例年この時期には地元周辺で FOSS4G TOKAI というジオ関連のコミュニティイベントが開催されるのですが、今年は FOSS4G KYUSHU 2025 として地元を離れて福岡で開催されました。
こちらに地元東海地区や関西以東から参加されている方が多数いらっしゃって、山陽新幹線の運休で九州に足止めされてしまったようですね。
JAWS-UG 佐賀への参加は
前年 3 月の現地開催回以来、久々の参加となりました。
翌日のイベントにも参加しました。この日も雨でしたね。
今回は、お盆休み期間だったり運営のスギミスさんが体調を崩されて不参加となってしまったりで LT 発表者が少なくなってしまったので、資料を作らないまま飛び入りで LT を行いました（後述）。
各 LT
というわけで順に。
Fusic 槇原さんのデータ移行手段のお話でした。
私が業務でオンプレ→ AWS 移行した頃と比べると手段が増えましたね。
（当時は Snowball はありましたが（今は亡き）Snowmobile は出る前だったと思います。もっとも Snowmobile は日本で提供されないまま終了しましたが）
とりあえず定点のデータを何らかの方法で AWS 上に送り込みつつ、S3 バケットを（当時は Mountpoint for Amazon S3 が存在しなかったので Goofys などを使って）EC2（Linux）からマウントしてファイルの差分をオンプレ Linux マシンから CLI でバッチ転送したり、オンプレ MySQL から Aurora へ binlog レプリケーションで DB 差分転送したりしました（DMS は機能的に要件に合わず）。
いちどAWSじゃなくて某社のプライベートクラウドへの移行話があったけどメンテナンス回線が貧弱すぎて自社側のDCのサービスへの影響を与えるほどのスループットが出なかった（結局立ち消えになったけど回線で転送してたら何日かかっても終わらなかったはず）
— hmatsu47(まつ) (@hmatsu47) 2025年8月11日
#jawsugsaga #jawsug
当時は（クラウド側どうこう以前に）オンプレ側にあるのがベストエフォート回線だと、伝送量規制で帯域制限を食らってしまったりして大変でしたね。
今はサービスが増え回線もいろいろ選択できるようになって一見便利になったものの、どのサービスを使うか？の選択など、難しさの本質はあまり変わりがなさそうです。
そしてクラスメソッド George Yoshida さんの S3 Vectors のお話。
RAG やベクトルストアの話が出てきましたが、最近の生成 AI 関連技術の移り変わりの早さから、
ベクトルストア（ベクトルDB）についてはことしの2月にBuriKaigi2025で話しましたが遠い昔のようです
— hmatsu47(まつ) (@hmatsu47) 2025年8月11日
（もうRAGとかベクトルストアとかの話題を話す人がほとんどいなくなってしまった感。S3 Vectorsで少し復活したけど）https://t.co/P2UTO3UjmS
#jawsugsaga#jawsug
という印象です。
とはいえ、RAG にしてもベクトルストアにしても不要な技術になったわけではなく、表の話に出にくくなっただけで裏側では確実に使われる技術ではあります。
（一部の人たちが「RAG は過去のもの」とか「MCP で代用できる」「自然言語で検索できるようになったからもう要らない」みたいな話をしているようですが、検索対象の DB にかかる負荷など考慮が必要な点はいろいろあるので話はそんなに簡単ではありません。ただ選択肢が増えただけです）
Fusic 勢 2 人目、佐藤さんからは最近特に話題（？）の「Amazon Bedrock で Too Many Requests が出るときの対策」のお話が。
LLM への分間リクエスト数あるいはトークン数がクォータ上限を超えるか、上限を超えなくても AWS ユーザー全体のリクエストが AWS が持つリソース総量を超えてしまうと出てくる問題ですね（エラーメッセージはそれぞれ多少違いがあるようですが）。
対策としては、
がありますが、クォータ緩和申請は
さいきん払いだされるAWSアカウントのBedrock LLM関連のクォータのデフォルト値が厳しすぎるしなかなか上限緩和リクエストが通らないからなあ
— hmatsu47(まつ) (@hmatsu47) 2025年8月11日
#jawsugsaga#jawsug
という問題があってなかなか厳しく、クロスリージョン推論についても（新しい AWS アカウントでは）それ自体のクォータ上限の初期値が厳しく設定されていてダメだったり。
複数リージョンをアプリケーション側でうまく使い分ける方法も、（新しい AWS アカウントでは）リソースが比較的潤沢なオレゴンリージョンなどでさえもクォータの初期値がかなり厳しくて、まあまあ難しいですね。
そしてリトライについては、そもそも「一時的なスパイクでリクエスト数・トークン数が過多になるのか、普通に使っているだけでもリクエスト数・トークン数が多すぎるのか」によって対策として有効かどうかが変わってきます（もちろん Too Many Requests 対策が目的かどうかは別としてリトライ実装は必要）。
妄信的に「リトライを実装すれば大丈夫」と思い込まないことが大事ですね。
（もちろん今回の佐藤さんの発表は「妄信的にリトライを実装すれば大丈夫」という趣旨ではないです）
ここまでが前半でした。
そしてここから後半。
Fusic 3 人目、宮崎さんから Inspector のコードセキュリティのお話。
Inspector の機能強化で色々と便利になりましたよね。
「セキュリティチェックをコードで実装できる（CI に組み込める）」のも（特に）クラウドの強みですね。
しかし、Inspector のみならず各 AWS のセキュリティ機能がそれぞれ守備範囲を広げた結果、
CSPMの本来の守備範囲とライブラリやアプリケーションの脆弱性検知サービスの守備範囲の違い、たしかにクラウドから始めた人にはわかりづらいかも
— hmatsu47(まつ) (@hmatsu47) 2025年8月11日
#jawsugsaga#jawsug
こういう印象がさらに強くなりました。
（その後 AWS は Security Hub のリブランドと再構成を進めることになったようですが）
セキュリティについては、SAST とか SCA とか 3 〜 4 文字の略語がどんどん増えて何が何やら…という感もあり、シフトレフトがあって（限定的にシフトライトもあって）そこにシフトダウンまで出てきて…。
一般の、セキュリティ業界の動向に詳しくないソフトウェアエンジニアやクラウド上にリソースを構築するエンジニアから見て、すごくとっつきにくい状況になってしまっているように感じるのは私だけでしょうか？
本来の最後の LT は、運営の柴尾さんからの AWS Summit Japan 2025 に参加した感想や 2026 に向けて備えておくと良いこと、などのお話でした。
結局私は去年少し参加しただけでほとんど参加できていません（参加を予定すると毎回なぜか難聴が…）。
来年のAPAすでに予約している人多数
— s.hiruta (@web_se) 2025年8月11日
#jawsugsaga
地方民からすると「千葉は東京のすぐそば」というイメージがあるのですが、実際は遠いですからね。
最後に飛び入りでこの Qiita 記事の話をしました。
スライドは俺の勉強会 #3 で話したときのものを改変して用意しようと思ったのですが、多分分かりづらいのでやめて、Qiita 記事を見せながら話すことにしました。
「ゲームで体感！Aurora DSQL の OCC（楽観的同時実行制御）」は JAWS ミート 2025 の LT で開催したゲームで、Aurora DSQL の OCC の動作を理解してもらいやすいように作りました（Amazon Q CLI が作ってくれました）。
結局、理解は難しかったみたいですが。
PostgreSQLだとロックできるが、OCCはロックがないので先勝ちなので注意。
— s.hiruta (@web_se) 2025年8月11日
#jawsugsaga
一般的な PCC（悲観的同時実行制御）は「先にロックを取った者勝ち」、OCC は「先にコミットした者勝ち」ですね。
来年（？）は
また色々と企画されているようなので、久々に現地参加もしたいですね。
