【勉強会レポート】JAWS-UG東京 ランチタイムLT会 #25

はじめに

2025/7/25 JAWS-UG東京 ランチタイムLT会 #25 に参加しました。

普段からJAWS-UGの勉強会には参加しており参加レポートを書いていた時期もありましたが、最近は サボって お休みしていました。久しぶりに書きますが、今回はQiitaの方に書いてみます（これまでは別のブログに書いていましたが、今回試しにということで。今後どちらに書くかは検討します。）

LT

それぞれのLTの概要と所感を書いていきます。

①AWSへの移行から安定運用までの道のり

AWSで運用しているWebアプリケーションの、オンプレからAWS（コンテナ基盤・ストレージ・DB）への移行までことを話してくださいました。

概要

• DataSync を使ってストレージ移行
  • EFSへのコピーを DataSync Agent をインストールしたEC2 が仲介
  • m5.2xlarge以上のインスタンスが必要なため、コストとの兼ね合い
• DBの移行
  • Data Migration Service は PostgreSQL 同士の移行には不向きのため不採用
    • テーブル所有者がコピーされない
    • 移行未対応のデータ型がある
  • 手作業でダンプを取得して移行
• コンテナのスケーリング
  • 日中帯と夜間で負荷の変動が大きいサービスのため、ECSオートスケーリングを採用
  • コンテナ同士の内部通信は、ECS Service Connect でモニタリングしてスケーリング
• ブルーグリーンデプロイでのリリース
  • 日中は顧客が利用しているため、切り戻しになった時の停止調整が大変
    • ブルーグリーンデプロイを採用して無停止リリース・切り戻し
• まとめ
  • オンプレで培った経験が役に立った
  • システムの特性に合わせたサービスを組み合わせるためにも事前の検証はとても重要
  • 開発者とユーザ両方が幸せになる環境を
  • AWSのサービスへの理解を深める

所感

開発者とユーザが両方とも幸せになる仕組みを作るには、AWSの各種サービスの理解、オンプレの知識、両方とも必要だなと思いました。ネットワークやデータベースなど、オンプレで培われる技術や知識は、クラウドでもオンプレであっても関係なく必要なはず。オンプレ経験が少ない私ですが、オンプレでできる経験をAWS使って勉強できるのであれば、端折らずに勉強して補おうと思いました！

②MFA必須化設定でハマった謎エラー ～内部アクションの解説も添えて～

概要

• MFA設定しようとして「Delete権限がない」「エンティティがすでに存在する」旨のエラーが出た
• MFAデバイス作成時と削除時の動作を調査
  • MFAデバイス作成時
    • デバイス作成：CreateVirtualMFADevice
    • デバイスの紐づけ：EnableMFADevice
  • MFAデバイス削除時
    • デバイス紐づけ解除：DeactiveMFADevice
    • デバイス削除：DeleteVirtualMFADevice
• アカウント内のMFAデバイス一覧を確認すると、誰にも紐づいていないデバイスが残っていた
  • MFA設定画面でデバイス名入力後次の画面に進むとデバイスが作成される
  • デバイス設定を途中でキャンセルすると、デバイス情報だけ残る
  • 同じデバイス名で作成しようとすると、残っているMFAデバイスを削除してから作成する
    • デバイス削除権限が付与されていないとエラーになる
      • デバイスの削除権限をポリシ追加すれば解決できる
• ポリシ追加することの安全性と必要性
  • 権限を追加すれば解決するがその安全性と必要性を考える
    • デバイス削除前にデバイスとユーザの紐づけが必要
      • 紐づけ解除できるのは自分のデバイスだけ
        • 紐づけされていないデバイスを削除することは問題ない（安全性）
    • デバイス作成中にキャンセルすることは今後も起こる可能性がある（必要性）

所感

MFAのデバイス設定中にキャンセルすることはよくあるので、どこの現場でも陥る可能性はあるなぁと思いました。マネジメントコンソールだけの操作に頼ると裏の処理が全く分からないままのため、MFA設定の一連の流れをログやCLIを使って調べることは本当に大切と再認識しました。MFAの一連の動作は、自分でも確認してみようと思います！また、解決方法が分かっても、権限の追加の安全性と必要性を深掘りするのは本当に大切ですね！

③Deep dive into Reachability Analyzer

VPC Reachability Analyzer について深掘りしたお話をしてくださいました。

概要

• VPC Reachability Analyzerは、VPC内外の2点間ネットワーク接続可否を静的解析で確認
• 裏側ではTirosと呼ばれる推論エンジンが使われている
  • Amazon Science に掲載されている Reachability Analyzer の論文より
    • AWSのネットワークリソースをモデル化
    • 制約条件を追加して論理式として定式化
    • SMTソルバーを利用して評価
      • MonoSATで到達経路を探索
        • MonoSATはグラフ理論を使用
• LTの内容の記事も公開されている

所感

VPC Reachability Analyzer のサービス内容は知ってましたが、裏側がどうなっているかは初めて知りました。Amazon Science もはじめて知りました。サービスの裏側の動作を知ると理解が深まりますね。見習わねば。

④AWSサミット CI/CDセッションでの学び

AWS Summit でのセッションの一つ、「モダンなCI/Cdツールボックス：一貫性と信頼性を確保するための戦略」を視聴した際の気づきを話してくださいました。

概要

• ドリフト（CI/CDパイプラインを通さない変更）の対策
  • 回避
    • 本番環境では、開発者の権限は読み取り専用権限のみにする
    • ブレークグラスオプションを設ける
      • 緊急時のみ手動操作する権限を与えること
  • 検知
    • CloudFromationのドリフト検出
    • CloudTrailのログを参照してCI/CD以外での変更をアラート
  • 依存性の軽減
    • プラットフォームにとらわれないCI/CDを実装するのが良い
      • Projen-pipelines
        • GitHub Actions など複数のCI/CDプラットフォームをサポートしている
  • 所感
    • これまで結果的に実装できていたことが分かり根拠のある提案ができる
    • 設計実装時に柔軟性と緊急性を提案できる

所感

CI/CDに関わることがほとんどなかったため、ブレークグラスオプションという言葉と意味を今日初めて知りました。ドリフト検出については認定試験でも出ますが、それ以外の対策は認定試験だけでカバーしきれないことだと思います。CI/CDについて勉強になり、これを機にもう少し深掘りしようと思いました。

最後に

今回のLT会もバラエティーに富んだ話ばかりでした。特に以下の2点は重要ポイントだと思いました。

• オンプレ経験・知識はクラウドでも必要
• サービスの裏側を熟知すること

久々の勉強会レポート執筆で時間はかかりましたが、資料や動画を見直すことで、勉強会の時は聞き漏らしていたことや重要ポイントを再確認できて、とてもよい復習になりました。

終わってからすぐでなくてもいいので、復習と自分の知識整理のためにもできる限り書こうと思いました。時間をかけて書くスタイルでやってみようと思います（もちろんかける時間にも限度はありますし、書きづらい時もあると思いますので、気負い過ぎない程度にしようかと）。

以上です。最後まで読んでいただき、ありがとうございました！