LT 枠が空いていそうな雰囲気を感じたので勢いで入れてみました。
先月は、申し込んでいた LT 大会が延期された結果登壇 0 だったので、1 月以来の LT でした。
といっても決めたのが開催 2 日前、その時点で社内勉強会の資料作成などがまだ残っていたため、実は準備が大変でした。
当日まで残り日数少ないのにうっかり（？）LT枠で申し込んでしまった。
— hmatsu47(まつ) (@hmatsu47) 2024年3月12日
#22 JAWS-UG主催 週刊AWSキャッチアップ（2024/03/04週）に申し込みました! https://t.co/Ta37wHeoLd #jawsug @jawsdaysより
2024/3/4 週の主要アップデート
やはりメインの話題は Bedrock の Claude 3 Sonnet でしょうか。
最上位の Opus は未サポート、軽量モデルの Haiku はちょうど当日の 3/15 に Bedrock でサポートされたところですが、Bedrock では Claude 3 Sonnet がサポートされた直後から GPT-4 との比較で盛り上がっていましたね。
ただ、この週間 AWS キャッチアップでは、参加メンバーの顔ぶれの関係（？）か、
といったストレージ寄りの話題で盛り上がっていました。
また、
に絡んで、IPv6 のアドレスについても話題になりました。
IPv6 はどうしても
- グローバルアドレスがメインで使われる
- 通常は NAT を使わない
- セキュリティ的にちょっと心配では？
あたりが話題になることが多いのですが、実は
して、
- 同一ノードの同一物理インターフェースが同時に複数の種類の IPv6 アドレスを持っている状態
が普通なんですよね。
（むかしお世話になったサイトのリンクをあげておきます）
2024/4/10 追記：
AWS の VPC（IPv6）はユニークローカルアドレスが使えない仕様になってます。
あと、配信アーカイブの中で（わたしが）リンクローカルアドレスと DHCPv6 の関連に言及している部分が残っているかもしれませんが内容が間違っていて、そもそも同一 L2 セグメントの外に漏れないリンクローカルアドレスに対して DHCPv6 のような「仕掛け」自体が不要でした（自動生成されるものをそのまま使えば問題がない。ついでに言うと AWS の VPC では各ノードが持つリンクローカルアドレスをユーザーが意識する必要がない）。
自分の LT
こちら絡みのネタです。
本編でもみなさん「何に使うの？」と首を傾げていらっしゃいましたが、その点は同意です。
Qiita の元記事を書いているときは「1 回の Claude 2.1 への問い合わせに 7 〜 8 秒」で安定していたのですが、LT 当日にデモをしようと一度に 2 つの問い合わせを連続で行うようにしたところ（プロンプト用のテーブルに 2 行目を挿入しただけ）、それだけで問い合わせからの回答が 16 秒から 1 分 45 秒までばらつきが出るという不安定さ。
また、Aurora ML の機能のうち、SageMaker への接続は（接続先の使い分けが必要なので当然ですが）SageMaker のエンドポイントが指定できるものの、今回追加された Bedrock については最初にサポートされた Comprehend と同様、設定でエンドポイントが指定できないので、VPC エンドポイントで呼び出すことができませんでした（NAT ゲートウェイ／インスタンスかパブリックアクセス可能な Aurora クラスタが必要）。
（過去に Comprehend 感情分析を試したときの Qiita 記事はこちら↓）
このあたりも仕様的に中途半端ですよね。
特に Aurora MySQL の場合は Aurora PostgreSQL とは違ってベクトルデータの保存や検索ができないので（今回の ML Bedrock でも埋め込み用モデルはサポート外）、RAG を内包した Bedrock への問い合わせができず、用途がかなり限られる印象です。
