Skip to content

ymd65536/AWSDevOpsAgent

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
.devcontainer
.devcontainer
 
 
img
img
 
 
.gitignore
.gitignore
 
 
LICENSE
LICENSE
 
 
README.md
README.md
 
 

Repository files navigation

【AWS】手を動かして学ぶ

この記事のポイント

  • AWS DevOps Agentを実際に使ってみて、いろんな質問をしてみる
  • AWS DevOps Agentの回答内容の正確性や有用性について確認する

はじめに

この記事ではAWS DevOps Agent(以下、DevOps Agent)でいろんな質問をしてみて、どんな動きをしたかなど具体的な動きについて書きます。主な内容としては実践したときのメモを中心に書きます。（忘れやすいことなど）誤りなどがあれば修正していく想定です。

AWS DevOps AgentがGAした

2026年4月1日にXでアナウンスがありました。

https://x.com/awscloud/status/2039089661453255106?s=20

※whats-newでは2026年3月31日にアナウンスされていました。 AWS DevOps Agent is now generally available

※日本語ブログでは4月3日です。 リンク

AWS DevOps Agentとは

ということで今回紹介するAWS DevOps Agentについてまずは公式の説明をもとにどんなものかを見てみましょう。

日本語公式ブログでは以下のように説明されています。

AWS DevOps Agent は、いつでも対応可能な運用チームメイトです。インシデントの解決とプロアクティブな予防を行い、アプリケーションの信頼性とパフォーマンスを最適化し、そして AWS、マルチクラウド、オンプレミス環境をまたいでオンデマンドの SRE タスクをこなします。 引用：リンク

つまりはエンジニアと並走してAWSのリソースの状態を確認したり、設定を確認したり、ログを確認したり、料金を確認したりなどいろんな質問に答えてくれるエージェントです。

そもそもDevOpsってなんだっけ

サービス名の一部となっているDevOpsについても簡単に触れておきましょう。結論から先に説明するとdeveloperとoperationsの組み合わせで、開発者と運用者が協力してソフトウェアを開発・運用するための文化やプラクティスのことを指します。

ちなみにAWSの公式サイトでは以下のように説明されています。

DevOps モデルでは、開発とオペレーションが「サイロ化」されることはありません。 場合によっては、開発チームとオペレーションチームを 1 つのチームに統合することが行われます。エンジニアは、開発とデプロイのテストからオペレーションに至るアプリケーションのライフサイクル全体にわたって作業するため、1 つの職務にとどまらず、幅広くスキルを磨くことができます。 引用：DevOps とは? - DevOps と AWS

いわゆる自分で作ったら運用もしていこうぜという文化であり、考え方です。DevOps Agentはこの文化を支援するあるいは実践するためサービスといえるでしょう。

事前準備

なんとなく理解できたところで、DevOps Agentを実際に使ってみましょう。 おおまかな手順としては以下のとおりです。

  • DevOps AgentのHomeを開く
  • Agent Spaceの名前を決める
  • DevOps Agent roleを作成する（Agent Space用のResource アクセス）
  • DevOps Agent roleを作成する（Enable web App）
  • Operator Access をクリック

では、実際に準備をしてみましょう。 まずはAWSマネジメントコンソールでDevOps AgentのHomeを開きます。

img/devops0.png

DevOps AgentのHomeでBegin setupをクリックします。

img/devops1.png

Agent Spaceを設定します。今回は以下のとおりに設定しました。

項目 値
Agent Space Name DevOpsSpace
Description test
Agent response language Japanese(Japan)

img/devops4.png

次にIAMロールを作成します。今回は変にカスタムせず、自動作成を選択します。

img/devops5.png

次にWeb App用のIAMロールを作成します。こちらも自動作成を選択します。

img/devops6.png

最後にAdvanced configurationはAWS owned keyとし、Createをクリックします。

Operator Access

Operator Accessをクリックすると、DevOps Agentと対話するための画面が表示されます。 画面右上のOperator Accessをクリックします。

img/devops7.png

本日はどのようなサポートをご希望ですかという画面が表示されます。ここで質問を入力してみましょう。

img/devops8.png

いろいろな質問をしてみよう

今回はこれまでのQiita記事作成でやってきた内容も含めこれまでに触ったAWSサービスについて質問してみます。 具体的には以下のとおりです。

  • LINE botで使ったLambdaについて聞く
  • ロググループについて聞く
  • LINE bot統合確認: API認証情報やチャネル設定について教えてください。
  • AWSリソースの状態を確認する

LINE botで使ったLambdaについて聞く

東京リージョンのAWS LambdaにはLinebotという関数があります。
Lambda関数の設定や状態を確認してください。

出力結果としては以下のとおりです。※{account_id}は実際のAWSアカウントIDが入ります。

img/devops9.png

基本設定

・関数名: Linebot
・ランタイム: Python 3.12
・ハンドラー: lambda_function.lambda_handler
・最終更新: 2024年10月11日 08:01:12 UTC
・ARN: arn:aws:lambda:ap-northeast-1:{account_id}:function:Linebot

リソース設定
・メモリサイズ: 128 MB
・タイムアウト: 15秒
・ストレージ: 512 MB (Ephemeral)
・アーキテクチャ: x86_64

実行環境

・IAMロール: arn:aws:iam::{account_id}:role/service-role/Linebot-XXXXXX
・環境変数: LINE_CHANNEL_ACCESS_TOKEN が設定されています
・VPC: VPC接続なし
・トレーシング: PassThrough (無効)

ログとモニタリング
・ロググループ: /aws/lambda/Linebot
・ログ形式: Text

その他
・コードサイズ: 713バイト
・パッケージタイプ: Zip
・レイヤー: なし

ロググループについて聞く

ロググループ: /aws/lambda/Linebot から最近の記録を調査して内容を要約してください。

出力結果は以下のとおりです。

img/devops10.png

実行状況
パフォーマンス:

平均実行時間: 670ms
最大メモリ使用量: 48MB（割当128MBの37.5%）
実行パターン:

2024年10月11日 07:00-08:00に29回（開発/テスト期間）
2024年10月11日 08:00-09:00に4回
2024年10月30日に最終実行1回
それ以降は実行記録なし
~以下略~

他、検出されたエラーや重要なパターンを見つけて要約してくれます。

おまけ：LINE botの統合確認

次のステップが表示されました。

img/devops12.png

次のステップには、LINE botの統合確認が含まれていますので質問してみましょう。

LINE bot統合確認: API認証情報やチャネル設定について教えてください。

出力結果としては以下のとおりです。

✅ Webhook URL（利用可能）
・URL: https://{XXXXX}.lambda-url.ap-northeast-1.on.aws/
・認証: NONE（パブリックアクセス許可）
・作成日: 2024年10月11日 07:03:41 UTC
・状態: 技術的には利用可能

✅ 設定済みの項目
・環境変数: LINE_CHANNEL_ACCESS_TOKEN 設定済み
・IAMロール: 最小権限設定（CloudWatch Logsのみ）
・ネットワーク: パブリックアクセス可能
・リソースポリシー: インターネットからの呼び出し許可済み

❌ 不足している設定
・API Gateway統合: なし（Function URLのみ使用）
・その他のトリガー: なし
・LINE Platform側の設定: Webhook URLが未設定または無効化されている可能性

📊 アクティビティ状況
~以下略~

また、LINE bot統合を再開する手順についても出力されました。

img/devops15.png

内容を読んでみたところ、おおむね合っていました。 LINE Developers ConsoleでWebhookを利用する場合はWebhook利用を「オン」にしたのち、接続確認を行う必要があります。

加えて、推奨される改善点ではAWSのベストプラクティスに基づいて指摘がされていました。

img/devops16.png

AWSのベストプラクティスとしては環境変数にシークレットを直接保存するのは推奨されていません。AWS Secrets ManagerやAWS Systems Manager Parameter Storeを使用して安全に管理することが推奨されます。

AWSリソースの状態を確認する

AWSリソースの状態を確認するような質問もしてみましょう。

今回は以下のような質問をしてみます。

  • S3に関する質問
  • EC2インスタンスに関する質問
  • 利用料金に関する質問
  • CodeBuildに関する質問

順番に質問してみましょう。

S3に関する質問

東京リージョンにあるS3バケット一覧を表示してください。

出力結果は以下のとおりです。

img/devops18.png

S3バケットの一覧については特に指示はしていないですが、名前だけでなく作成日も表示されていました。

EC2インスタンスに関する質問

次にEC2インスタンスの状態を確認するような質問をしてみましょう。なお、当該アカウントにはEC2インスタンスは存在しません。さてどうなるでしょうか。

東京リージョンにあるEC2インスタンスの状態を確認してください。

出力結果は以下のとおりです。

img/devops19.png

利用料金に関する質問

次に利用料金に関する質問をしてみましょう。これは実際の利用料金やクレジットの使用状況を確認するような質問です。 当該アカウントでは利用料金が発生していることとクレジットが使用されていることがわかっています。さて、どのような回答が得られるでしょうか。

今月の利用料金とクレジットの使用状況を教えてください。

出力結果は以下のとおりです。

img/devops20.png

Cost ExplorerのAPI レート制限により取得ができませんという回答が得られましたが 特に制限を設けていないはずなので、これは設定を見直す必要があるかもしれません。

CodeBuildに関する質問

最後にBuildに関する質問をしてみましょう。CodeBuildのビルドプロジェクトの設定と最近のビルド履歴を確認するような質問です。

CodeBuildのビルドプロジェクトの設定と最近のビルド履歴を確認してください。

当該アカウントではCodeBuildのビルドプロジェクトは存在しており、過去のQiitaではビルドキャッシュを利用するような設定を行っています。

参考：【AWS】検証！Amazon ECRをCodeBuildのリモートキャッシュとして利用する

さて、どのような回答が得られるでしょうか。

出力結果は以下のとおりです。

img/devops21.png

BuildKitを使ったことやビルドキャッシュの利用、Amazon Linux 2023を使ったことなどがわかるような回答が得られました。 たしかに、以前の操作ではBuildKitを有効にしてビルドキャッシュを利用するような設定を行っていましたので、これらの情報が回答に含まれているのは正しいといえるでしょう。

まとめ

今回はAWS DevOps Agentを実際に使ってみて、いろんな質問をしてみました。質問の内容としてはこれまでのQiita記事作成で触ったAWSサービスについての質問を中心に行いました。質問に対してはAWS DevOps AgentがAWSリソースの状態や設定、利用状況などを確認して回答してくれました。

とはいえ、回答内容の正確性については確かなことを確認できていない部分もありました。たとえば、EC2のインスタンスが存在しないことを確認する場面ではEC2が存在しないことを事前に知っていたため、回答の正確性を確認することができませんでした。

また、利用料金に関する質問ではCost ExplorerのAPI レート制限により取得ができないという回答が得られましたが、特に制限を設けていないはずなので、これは設定を見直す必要があるかもしれません。

Buildに関する質問では、BuildKitを使ったことやビルドキャッシュの利用、Amazon Linux 2023を使ったことなどがわかるような回答が得られました。これらの情報は以前の操作で行った設定や操作内容と一致しているため、ある程度正確な回答が得られているといえるでしょう。

今後も引き続き質問をしてみて、回答内容の正確性や有用性について確認していきたいと思います。

AWS CLI インストールと SSO ログイン手順 (Linux環境)

このガイドでは、Linux環境でAWS CLIをインストールし、AWS SSOを使用してログインするまでの手順を説明します。

前提条件

  • Linux環境（Ubuntu、CentOS、Amazon Linux等）
  • インターネット接続
  • 管理者権限（sudoが使用可能）
  • AWS SSO が組織で設定済み
  • Python 3.12.1

AWS CLI のインストール

公式インストーラーを使用（推奨）

最新版のAWS CLI v2を公式インストーラーでインストールします。

# 1. インストーラーをダウンロード
curl "https://awscli.amazonaws.com/awscli-exe-linux-$(uname -m).zip" -o "awscliv2.zip"

# 2. unzipがインストールされていない場合はインストール
sudo apt update && sudo apt install unzip -y  # Ubuntu/Debian系
# または
sudo yum install unzip -y                     # CentOS/RHEL系

# 3. ダウンロードしたファイルを展開
unzip awscliv2.zip

# 4. インストール実行
sudo ./aws/install

# 5. インストール確認
aws --version

# ダウンロードしたzipファイルと展開したディレクトリを削除してクリーンアップします。
rm  "awscliv2.zip"

# 解凍したディレクトリを削除
rm -rf aws

AWS SSO の設定とログイン

1. AWS SSO の設定

AWS SSOを使用するための初期設定を行います。

aws configure sso

設定時に以下の情報の入力が求められます：

  • SSO start URL: 組織のSSO開始URL（例：https://my-company.awsapps.com/start）
  • SSO Region: SSOが設定されているリージョン（例：us-east-1）
  • アカウント選択: 利用可能なAWSアカウントから選択
  • ロール選択: 選択したアカウントで利用可能なロールから選択
  • CLI default client Region: デフォルトのAWSリージョン（例：ap-northeast-1）
  • CLI default output format: 出力形式（json、text、tableのいずれか）
  • CLI profile name: プロファイル名（defaultとします。）

2. AWS SSO ログイン

設定完了後、以下のコマンドでログインを実行します。

aws sso login

ログイン時の流れ：

  1. コマンド実行後、ブラウザが自動的に開きます
  2. AWS SSOのログインページが表示されます
  3. 組織のIDプロバイダー（例：Active Directory、Okta等）でログイン
  4. 認証が成功すると、ターミナルに成功メッセージが表示されます

3. ログイン状態の確認

認証情報を確認します。

aws sts get-caller-identity

正常にログインできている場合、以下のような情報が表示されます：

{
    "UserId": "AROAXXXXXXXXXXXXXX:username@company.com",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/RoleName/username@company.com"
}

トラブルシューティング

よくある問題と解決方法

1. ブラウザが開かない場合

# 手動でブラウザを開く場合のURL確認
aws sso login --no-browser

表示されたURLを手動でブラウザで開いてください。

2. セッションが期限切れの場合

# 再ログイン
aws sso login

4. プロキシ環境での設定

プロキシ環境の場合、以下の環境変数を設定してください：

export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,.company.com

セキュリティのベストプラクティス

  1. 定期的な認証情報の更新: SSOセッションには有効期限があります。定期的に再ログインを行ってください。

  2. 最小権限の原則: 必要最小限の権限を持つロールを使用してください。

  3. プロファイルの分離: 本番環境と開発環境で異なるプロファイルを使用してください。

  4. ログアウト: 作業終了時は適切にログアウトしてください：

    aws sso logout --profile <プロファイル名>

参考リンク

About

AWS DevOps Agentにハンズオン

qiita.com/ymd65536/items/8ed688d541ed9d53a55f

Topics

aws devops devops-agent

Resources

Readme

License

MIT license
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Contributors

Languages