こんにちは！GAWSの島です。
先日、GAWSで「夏の自由研究発表会」を開催しました～！🌞🍉🍧
■ GAWSと「夏の自由研究発表会」
GAWSとは、ゼネックコミュニケーションのメンバーがAWSの知識や意見を持ち寄る社内コミュニティです。
今回のテーマは、その名のとおり「AWSにまつわる自由研究」です。
つまりAWSに関する内容なら何でもOK。
新しいサービスの調査、普段は見過ごしがちな仕組みの実験、日々の運用課題の整理など、それぞれが気になるテーマに取り組みました。
発表会当日の会場の様子。
「自由研究」と聞くと、子どものころの夏休みを思い出す方も多いのではないでしょうか。
今回の発表にも、「気になったから調べる」「予想を立てて試す」といった、自由研究ならではの過程が表れていました。
本ブログでは、個性豊かな発表の中から、4つのテーマをご紹介します！
■ 発表内容をご紹介
● 「S3、ついにベクトルを覚える。」／島
私が発表したAmazon S3 Vectorsについてのお話です！
Amazon S3といえば、画像や文書を置くクラウド上の保管場所として知られています。
S3 Vectorsでは、一般的なファイル保管用バケットとは別に、ベクトルの保存と検索に特化した「ベクトルバケット」と「ベクトルインデックス」を使います。
ベクトルを扱うもので注目されている技術が皆さんご存じRAG（検索拡張生成）です🤖
難しそうな名前ですが、仕組みは「AIが答える前に、用意した資料から関係する箇所をプロンプトとして加える」と考えると分かりやすくなります。
文章を意味の座標に変換し、質問と近い資料を探す。その検索結果を根拠として生成AIが回答する流れです。
文章と質問を同じ埋め込みモデルでベクトルに変換し、意味の近さで資料を探す流れ。
発表では、Amazon Bedrock Knowledge Basesを使って、原文の保管、ベクトルストア、回答生成モデルを合わせた最小構成を整理しました。
よく知っているS3から入ることで、生成AIにまだなじみがない方にもRAGの基礎知識を届けられたのではないかと思います。
Amazon S3、Bedrock Knowledge Bases、Titan Text Embeddings V2、S3 Vectors、生成モデルが連携するRAG構成図。
参考リンク
● 「きろのくらうど なかはどうなってるの？」／浮田さん
Kiroは、AIエージェントに開発作業を手伝ってもらえるツールです🌟
Cloud Sessionsでは、エージェントが管理された分離クラウド環境で動き、PCを閉じても作業を続け、別の端末から同じセッションに戻れます。
PCを閉じたあともクラウド側で作業を続け、別の端末から再開できるCloud Sessions。
そこで浮田さんは、「どこで動いているか」「AWSへ接続できるのか」「設定は引き継がれるのか」の3点について、予想を立てて検証しました。
「どこで動いているか」
ホスト名、認証情報、通信、設定ファイルを順番に調べました。
ホスト名からは、AWSの米国東部リージョンにある仮想サーバー「EC2」の手がかりが見つかり、今回の環境はEC2上のLinuxコンテナだと推測しました。
「AWSへ接続できるか」
確認した初期状態にはAWSの認証情報がなく、通信もプロキシに拒否されました。AWSに接続はできないみたいです。
「手元の設定は引き継がれるか」
プロジェクトと一緒に共有する「.kiro」の設定は引き継がれましたが、PCだけに置いた個人設定「~/.kiro」は自動では引き継がれませんでした。
三つの予想と検証結果。浮田さんが調べたセッションでの観測であり、Cloud Sessions全体の固定仕様ではありません。
予想と結果の違いから、Cloud Sessionsの境界が見えた自由研究でした。
参考リンク
- Kiro Cloud Sessions公式ドキュメント
- Kiro CLI 2.17.0 Cloud Sessionsリリースノート
- Kiro SandboxのInternet Access設定
- Kiro SandboxのEnvironment Configuration
● 「重複しているIPアドレスをマネージドプレフィックスリストで整理する」／丸山さん
丸山さんが取り上げたのは、同じIPアドレス範囲を複数のセキュリティグループへ重複登録する運用です。
セキュリティグループは、EC2などへの通信を許可・制限する仮想ファイアウォールです。
IPアドレスが変わるたびに全てを直す必要があり、更新漏れはアクセス障害や設定の不一致につながります。
そこで使うのが、AWS上の仮想ネットワーク「VPC」の設定項目として存在する「マネージドプレフィックスリスト」です。
CIDR（IPアドレスの範囲）を名前付きの「共通住所録」にまとめ、各セキュリティグループから参照させます。
リストを一度更新すれば、参照先は最新の内容を利用するため、変更箇所を一つにできます📃
利用者が自社や拠点の範囲を編集する「カスタマー管理」と、
S3やCloudFrontなどの範囲をAWSが管理する「AWS管理」の二種類があります。
利用者が管理するリストと、AWSが管理するリストの違いを整理。
注意点は、カスタマー管理リストをセキュリティグループから参照すると、実際の登録件数ではなく「最大エントリ数」がルール枠として数えられることです。
最大値を適切に設定し、元の許可範囲を広げずに共通管理することで、運用負荷と更新漏れを減らせるという学びでした。
最大エントリ数とセキュリティグループのルール枠に関する注意点。数値は資料作成時点の前提です。
参考リンク
● 「マナティの知らない世界『時刻同期の世界』」／佐野さん
佐野さんの発表は、日本標準時子午線上にある明石市立天文科学館を訪れた体験から、「AWS上のサーバーはどうやって時刻を合わせているのか」を調べた研究です🔭
EC2では、Amazon Time Sync Serviceが時計合わせを支えています。
169.254.169.123へNTP（ネットワークで時計を同期する仕組み）で問い合わせます。
EC2から直接使えるリンクローカルアドレスなので、インターネット接続用のゲートウェイは不要です。
EC2がAmazon Time Sync ServiceへNTPで問い合わせ、時刻を同期する仕組み。
今回は時刻同期を止め、EC2の時計を1時間先へ進める検証が行われました。
その結果、呼び出したAPIは、すべてエラーになりました。
AWS CLIやSDKから送る多くのリクエストは、日時を含むSignature Version 4（SigV4）で署名されます。
時計が大きくずれると、AWS側に未来または期限切れのリクエストと判断され、署名の検証に失敗することがあります。
時刻同期がログの確認や安全なAPI利用を支える「縁の下の力持ち」だと分かる発表でした。
WS APIの利用にも、正しい時刻が欠かせないことを実験から確認。
発表で扱われた内容は、佐野さんのQiita記事で、実行コマンドや結果とともに詳しく紹介されています。
時刻の復旧、高精度な同期、うるう秒への対応まで知りたい方は、ぜひ以下のリンクからご覧ください。
【ぼくのなつやすみ①】明石市立天文科学館に行ったら、AWSの「時間」が気になった話
参考リンク
- EC2の時刻同期とAmazon Time Sync Service
- ローカルAmazon Time Sync Serviceの設定
- Signature Version 4（SigV4）の署名エラーに関するトラブルシューティング
■ 開催して感じたこと
今回の発表会には、ゲームを支えるAmazon DynamoDB、コスト管理や多層セキュリティのお話など、多彩なテーマが集まり、非常に充実した発表会になりました。
今回あらためて感じたのは、手を動かした結果だけでなく、疑問の立て方や途中で迷ったことにも、共有する価値があるということです。
予想どおりだったことも、予想が外れたことも、次に試す人の手がかりになります🔍
また、短い時間で技術を伝えるには、情報を並べるだけでは足りません。
「一番届けたいことは何か」「どんな例なら初めて聞く人にも伝わるか」を考える必要があります。
発表する側と聞く側の双方にとって、技術を別の角度から見直す機会になりました。
今後も、GAWSをこうした技術交流の場として育てていきたいです。
■ まとめ
GAWS 夏の自由研究発表会には、新サービスを整理する研究、中身を確かめる実験、現場の課題を改善する工夫、そして身近な疑問から始まる探究が集まりました！
分からないことを、そのままにせず調べてみる。小さくても実際に試し、分かったことを誰かに伝える。
GAWSでは、これからもそんな挑戦と技術共有を続けていきます。
次の自由研究もお楽しみに🚀