AWS DevOps AgentのAzure接続機能を検証して見えた活用法／Use Cases Verified for the AWS DevOps Agent's Azure Connectivity Feature

2026.7.28
JAWS-UG千葉支部#43 AWS DevOps Agent 祭り登壇資料
https://jawsug-chiba.connpass.com/event/398349/

Transcript

1. マスター タイトルの書式設定 AWS DevOps AgentのAzure 接続機能を検証して⾒えた活⽤法 2026.7.28（火） JAWS-UG千葉⽀部#43 AWS DevOps Agent 祭り モブエンジニア（@mob_engineer） 1
2. マスター タイトルの書式設定 対象者／得られる学び • 対象者 1. AWS DevOps AgentのAzure接続機能を知りたい方 2. Azure接続機能を⽤いたメリット／考慮事項を知りたい方 • 得られる学び 1. Azure接続機能を活⽤することで管理する領域を広げられる 2. Azureリソースの障害調査を⾏う場合、Skillsは必須 2 2
3. マスター タイトルの書式設定 お話すること／お話しないこと • お話すること 1. Azure接続機能の紹介／Azure+αでの検証結果 2. 検証結果を踏まえたメリット／考慮事項 • お話しないこと 1. Azure SREとの機能比較 2. サードパーティ統合（Dynatraceなど）による比較 3. その他他クラウドサービスに関する情報 3 3
4. マスター タイトルの書式設定 自己紹介 • ペンネーム︓モブエンジニア • コミュニティ活動︓ JAWS-UG 彩の国埼玉⽀部運営 JAWS SONIC 2026 実⾏委員（広報班） • 好きなAWSサービス︓ AWS DevOps Agent／AWS FinOps Agent AWS Cloud WAN／AWS Transit Gateway AWS Direct Connect • ⼀⾔︓ AWSとコミュニティを愛する⼀般的な技術者です 4 4
5. マスター タイトルの書式設定 アジェンダ 1.AWS DevOps Agent／Azure接続機能について 2. Azure環境での機能検証（+GC／OCIでの機能検証） 3. 実務を踏まえた活⽤方法 4. まとめ／今後の展望 5 5
6. マスター タイトルの書式設定 AWS DevOps Agent／ Azure接続機能について 6 6
7. マスター AWS DevOps タイトルの書式設定 Agentについて • 2026年4月に⼀般提供されたフロンティアエージェン トサービスの⼀種です。 • 紐づけたAWSアカウントに構築されているリソースをモ ニタリングし、⾃律的なインシデント管理／予防保全 の提案を⾏う。 • GitHubとの統合／PagerDutyなどのサードパーティ 統合／Slackなどのコミュニティケーションツールとの連 携も可能。 • エージェント実⾏時間に対して利⽤料がかかる（1秒 あたり0.0083ドル（秒））。※サポートプランによる 割引あり AWS DevOps Agent の一般提供開始のお知らせ | Amazon Web Services ブログをもとに執筆。 7 7
8. マスター タイトルの書式設定 （補足）プレビュー時とGA時のUI変更 プレビュー時 GA時 8 8
9. マスター タイトルの書式設定 Azure接続機能とは • 指定したAzureサブスクリプションを登録することでAWS DevOps Agentの調査対象に含めることが出来る。 • 設定⾃体は数クリックで完了する+AWS上のIAMポリシー変更を⾏ わなくてよいため、導入にかかる工数は少ない。 • リソースグループ単位での管理はできないため注意が必要。 →リソースグループで「開発」「テスト」「本番」を分けている場合、 AWS DevOps Agentとしては「開発／テスト／本番」すべてに アクセスすることが出来る。 9 9
10. マスター タイトルの書式設定 （補足）AWS DevOps AgentとAzure接続する方法 • 作業として以下3つの作業を実施する 1. 機能プロバイダーに利⽤するAzureを設定する →Entra IDに登録されているAdminメールアドレスで登録 2. Azure側のAdminユーザにAgent利⽤権限を付与する 3. エージェントスペースにAzureをセカンダリとして紐づける 10 10
11. マスター タイトルの書式設定 （補足）接続手順（１） 11 11
12. マスター タイトルの書式設定 （補足）接続手順（２） 12 12
13. マスター タイトルの書式設定 （補足）接続手順（３） 13 13
14. マスター タイトルの書式設定 （補足）接続手順（４） 14 14
15. マスター タイトルの書式設定 （補足）接続手順（５） 15 15
16. マスター タイトルの書式設定 （補足）接続手順（６） 16 16
17. マスター タイトルの書式設定 （補足）接続手順（７） 17 17
18. マスター タイトルの書式設定 （補足）接続手順（８） 18 18
19. マスター タイトルの書式設定 （補足）接続手順（９） 19 19
20. マスター タイトルの書式設定 （補足）どうやってAzure接続を実現しているのか︖ • 組織に所属しているユーザがAzureを利⽤するために利⽤するエンタープライズアプリケー ション経由でAWS DevOps Agent Azure間の接続を実現している。 https://learn.microsoft.com/ja-jp/archive/blogs/jpazureid/enterpriseapplications-app-registrations 20 20
21. マスター タイトルの書式設定 Azure環境での機能検証 （+GC／OCIでの機能検証） 21 21
22. マスター タイトルの書式設定 検証時利⽤したリソースについて • GitHub上で公開しているため皆さんの環境で試してみてください。 • （AWS⽤）︓https://github.com/MASAKIOKUDA-eng/DevOpsAgent-AWS • （Azure⽤）︓https://github.com/MASAKIOKUDA-eng/DevOpsAgent-Azure • （Google Cloud⽤）︓https://github.com/MASAKIOKUDA-eng/DevOpsAgent-GC • （OCI⽤）︓https://github.com/MASAKIOKUDA-eng/DevOpsAgent-OCI 22 22
23. マスター タイトルの書式設定 検証モチベーション • 検証を⾏おうと思ったモチベーションとして以下の通りです。 1. Azureリソースに対してもAWSと同等の検証能⼒を発揮すること が出来るのか確認したかった。 2. Azureリソース／AWSリソースでの調査にかかる時間が どのくらいかかるのか知りたかった。 3. 「AWS DevOps Agentを⽤いたソリューション」を考えるうえで、 フックとなるポイントがあるのか確認したかった。 23 23
24. マスター タイトルの書式設定 検証観点について • 検証観点として「ソースコードを対象にした検証」と「リソースを対象 にした検証」という視点で4つ⾏う予定です。 • なお、Skills／MCPサーバーの設定は入れずに検証します。 項番 パターン 検証内容 理由 1. パターン１ AWS環境のソースコードを対象 Azureとの比較のため 2. パターン２ Azure環境のソースコードを対象 リリース管理機能での チェック機能を把握するため 3. パターン３ AWS環境のリソースを対象 Azureとの比較のため 4. パターン４ Azure環境のリソースを対象 Azureリソースに対してもAWSリソース同様の調 査性能を発揮できるか把握するため。 24 24
25. マスター タイトルの書式設定 検証内容一覧 25 25
26. マスター タイトルの書式設定 （補足）GitHubとの連携について • GitHub初回紐づけ時に特定のリポジトリのみ指定して紐づけた場 合、他のリポジトリを接続する場合、GitHubのアプリを削除する必 要があります。 26 26
27. マスター タイトルの書式設定 （補足）AWS DevOps Agentが最初に⾒るブランチ • 「main」ブランチが存在しない場合、「リポジトリが存在しません」と 表⽰されるため、ブランチ戦略を考える必要がある。 27 27
28. マスター タイトルの書式設定 検証結果について（１） 項番 障害内容 パターン１ パターン２ パターン３ パターン４ 1. ALB SGが全ポート・全プロトコル許可 × × 2. ECS SGポート不一致（80 vs 8080） 3. RDS SGが0.0.0.0/0からDB接続許可 4. RDS SGにECSからの知識の許可なし 5. ヘルスチェックパス不正 （/api/healthcheck） 6. TGポート不一致（8080 vs 80） ◦ ◦ ◦ × ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ × × × × × × × 7. NATゲートウェイなし（イメージプル不可） 8. HTTPS未対応（HTTPのみ） 9. desired_count=1 ◦ × × 10. コンテナポート不統合（全体） ◦ × × × × × × × ◦ × ◦ ◦ ◦ 28 28
29. マスター タイトルの書式設定 検証結果について（２） 項番 障害内容 パターン１ パターン２ パターン３ パターン４ 11. ログ設定なし ◦ 12. IAMポリシー未タッチ 13. デプロイタイムminimum_healthy=0 14. マルチ AZ 無効 × × ◦ ◦ × ◦ ◦ ◦ × × × × × × 15. 公開アクセス可能 16. 削除保護なし+最終スナップショットス キップ 17. パスワードが状態に平文保存 ◦ ◦ ◦ 14/17 × ◦ ◦ 11/16 × × × 7/17 × × × 0/16 約2分 約2分 約3分 約4分 検知数 時間 パターン4についてはTerraformの構築失敗→再構築について言及していた 29 29
30. マスター タイトルの書式設定 検証を通じて⾒えたこと 30 30
31. マスター タイトルの書式設定 検証を通じて⾒えたこと • Azure接続⾃体は楽に⾏えるがEntra IDが必要。 →プロジェクトによってはAWS環境への接続が出来ない場合もある • GitHub上のソースコードを対象にした検証はそこそこの精度を上げ ることが出来るが、リソースを対象とした場合、Skillsを設定しないと 求めている精度を上げづらい。 →サードパーティツール利⽤の前提︖ • Azure接続機能があることで「ソースコードでは⾒えない運⽤時の 障害（⼀時的なDB高付加など）」を検知することが出来る。 31 31
32. マスター SRE Azure タイトルの書式設定 AgentがAzureで提供されている https://learn.microsoft.com/ja-jp/azure/sre-agent/overview?tabs=task 32 32
33. マスター タイトルの書式設定 深く知りたい方向けに • Microsoftの坂部さんから公開されている資料が全体像を 把握できると思います。 https://speakerdeck.com/koudaiii/azure-sre-agent-yonayona-azure-club 33 33
34. マスター タイトルの書式設定 実務で活⽤する場合 • 「クラウドリソースの比率」によって使い分けを考えてみた方が 良いと思います。 1. Azure環境のリソースはあくまでサブの場合︓ AWS DevOps Agentを利⽤した方が効果的 2. Azure環境をメインで利⽤している場合︓ Azure SRE Agentを利⽤した方が効果的 ※サードパーティツールの利⽤可否も判断軸に置いた方が良い ※Azure SRE Agentは東京リージョン未対応・・・ 34 34
35. マスター タイトルの書式設定 まとめ／今後の展望 35 35
36. マスター タイトルの書式設定 まとめ • Azure接続⾃体は楽に⾏えるため個⼈での導入はそこまで難しくない印象。 ただし、Entra IDでの管理が必要なため、 企業の場合導入ハードルがやや高い印象。 • AWS DevOps Agentで⼀元管理したい場合、Azure接続は活⽤できる シーンはあるが、クラウドリソースの比率によっては検討が必要。 • Google Cloud／OCIについても接続方法はほぼ同じ（アプリケーションユー ザ経由）なため今後のリリースに期待。 • MCPサーバー経由でAWS DevOps Agentでの調査は⾏えそう︖ 36 36
37. マスター タイトルの書式設定 今後の展望 • Google Cloud／OCIでの検証 • Azure SRE Agentとの比較検討 • ネットワーク（AWS Cloud WANなど）含む環境での障害調査 • サードパーティ統合での比較検討 37 37
38. マスター タイトルの書式設定 （宣伝）JAWS SONIC 2026開催します︕︕ 38 38