こんにちは、エデュケーショナルサービス課の小倉です。
久しぶりの30分AWSハンズオンシリーズです。
サーバーワークスでは、自由に勉強会を開催してスキルアップをしています。その中で私は毎週火曜日の朝、「30分AWSハンズオン」という30分でできるAWSハンズオンを2021年9月から継続して開催しています。その内容をブログで定期的に紹介していきます。AWSをご利用のみなさまのスキルアップにお役立ていただければと考えています。
8回目は、「DevOps Agentを使ってみよう」をやります。一点注意としては、DevOps Agentは2026/3/13現在、パブリックプレビューとなっており、まだ正式にリリースされていないサービスとなっています。
DevOps Agentについては別のブログでも紹介されていますので、確認してみてください。
ハンズオンは、以下の流れで実施します。
1．DevOps Agentのエージェントスペースの作成
2．CloudFormationで調査対象の環境構築
3．DevOps Agentで調査
4．後片付け
使用するAWSサービス
AWS DevOps Agent
AWS DevOps Agent とは、なにかトラブルが起きたときにログなどを調査して原因を突き止めるサービスです。今までであれば、人がログや設定変更履歴などをチェックしてトラブルの原因を調査し、かなりの時間がかかっていたと思いますが、DevOps Agent で指示をするだけで、短時間で原因を突き止めることができます。
現在、バージニア北部リージョンでのみで利用することができますが、バージニア北部から別のリージョンのリソースの原因調査は可能です。また、プレビュー期間中は利用時間の制限や、DevOps Agent自体は無料で利用できますが、他の AWS サービスおよび AWS 以外のサービスへのクエリや API 呼び出しは、料金が発生する場合があります。
参考サイト:
AWS DevOps Agent はインシデント対応の迅速化とシステム信頼性の向上に役立ちます (プレビュー) | Amazon Web Services ブログ
Public preview pricing and limits - AWS DevOps Agent
構成図
今回の構成図です。
VPC内にEC2を作ります。その後、EC2に負荷をかけ、CloudWatch Alarmでアラーム状態にします。DevOps Agentでアラーム状態になった原因を調査して、原因を突き止めます。
ハンズオン手順
1．DevOps Agentのエージェントスペースの作成
DevOps Agentを使うためにエージェントスペースを作成します。エージェントスペースとは、DevOps AgentがIAMロールとツール統合を通じてタスクを実行するときのアクセスできる範囲(原因調査の範囲)を定義しています。
画面上の検索窓で DevOps Agent と入力し、サービスの下に表示された [DevOps Agent] をクリックし DevOps Agent のコンソール画面を開きます。
もし、選択しているリージョンがバージニア北部でなければ以下の画面が表示されるので、[米国(バージニア北部)] をクリックします。
DevOps Agent のコンソール画面の [セットアップを開始] をクリックします。
エージェントスペースを作成の画面で、以下を入力し、[作成] をクリックします。
・Agent Space Name: yyyymmdd-handson (yyyymmdd は年月日で、例えば2023年12月10日なら 20231210 となります)
今回、IAMロールは自動作成されるロールを使用します。
以下の画面が表示されればOKです。
これで DevOps Agent の設定は終わりです。
2．CloudFormationで調査対象の環境構築
環境構築はAWSドキュメントを参考にしていますが、以下の部分のテンプレートを変更して実施をします。
- デフォルトVPCの利用ではなく、VPCを作成するように変更
- EC2へのログイン経路がインターネット経由のため、Systems MangerのSession Manger経由でのログインに変更
- EC2作成後に自動で負荷がかからなかったので、作成してから5分後に負荷がかかるようにコマンドを追加
参考サイト: Creating a test environment - AWS DevOps Agent
調査対象の環境をCloudFormationを使って構築します。CloudFormationとはコードでインフラを管理できるAWSサービスです。以下のコードをコピーしてローカルのメモ帳などのテキストエディタに貼りつけて、ファイル名 handson8.yml で保存します。このコードを利用するとVPC、サブネット、EC2、CloudWatch Alarmを作成してくれます。
AWSTemplateFormatVersion: 2010-09-09
#Description: 'AWS DevOps Agent EC2 CPU Test Stack'
Resources:
# VPC
TestVPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 10.0.0.0/16
EnableDnsHostnames: true
EnableDnsSupport: true
Tags:
- Key: Name
Value: AWS-DevOpsAgent-Test-VPC
# Internet Gateway
TestIGW:
Type: AWS::EC2::InternetGateway
Properties:
Tags:
- Key: Name
Value: AWS-DevOpsAgent-Test-IGW
AttachGateway:
Type: AWS::EC2::VPCGatewayAttachment
Properties:
VpcId: !Ref TestVPC
InternetGatewayId: !Ref TestIGW
# Public Subnet
PublicSubnet:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref TestVPC
CidrBlock: 10.0.1.0/24
MapPublicIpOnLaunch: true
AvailabilityZone: !Select [0, !GetAZs '']
Tags:
- Key: Name
Value: AWS-DevOpsAgent-Test-Public-Subnet
# Route Table
PublicRouteTable:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref TestVPC
Tags:
- Key: Name
Value: AWS-DevOpsAgent-Test-Public-RT
PublicRoute:
Type: AWS::EC2::Route
DependsOn: AttachGateway
Properties:
RouteTableId: !Ref PublicRouteTable
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref TestIGW
SubnetRouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref PublicSubnet
RouteTableId: !Ref PublicRouteTable
# Security Group (Session Manager doesn't require inbound rules)
TestSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupName: AWS-DevOpsAgent-test-sg
GroupDescription: AWS DevOps Agent beta testing security group
VpcId: !Ref TestVPC
Tags:
- Key: Name
Value: AWS-DevOpsAgent-Test-SG
- Key: Purpose
Value: AWS-DevOpsAgent-Testing
# IAM Role for Session Manager
EC2Role:
Type: AWS::IAM::Role
Properties:
RoleName: AWS-DevOpsAgent-SSM-Role
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service: ec2.amazonaws.com
Action: sts:AssumeRole
ManagedPolicyArns:
- arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
Tags:
- Key: Name
Value: AWS-DevOpsAgent-SSM-Role
# Instance Profile
EC2InstanceProfile:
Type: AWS::IAM::InstanceProfile
Properties:
InstanceProfileName: AWS-DevOpsAgent-SSM-Profile
Roles:
- !Ref EC2Role
# EC2 Instance for CPU testing
TestInstance:
Type: AWS::EC2::Instance
Properties:
InstanceType: t3.micro
ImageId: '{{resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-6.1-x86_64}}'
IamInstanceProfile: !Ref EC2InstanceProfile
SubnetId: !Ref PublicSubnet
SecurityGroupIds:
- !Ref TestSecurityGroup
UserData:
Fn::Base64: !Sub |
#!/bin/bash
yum update -y
yum install -y htop
# Create the CPU stress test script
cat > /home/ec2-user/cpu-stress-test.sh << 'EOF'
#!/bin/bash
echo "Starting AWS DevOpsAgent CPU Stress Test"
echo "Time: $(date)"
echo "Instance: $(curl -s http://169.254.169.254/latest/meta-data/instance-id)"
echo ""
# Get number of CPU cores
CORES=$(nproc)
echo "CPU Cores: $CORES"
echo ""
echo "Starting stress test (5 minutes)..."
echo "This will generate >70% CPU usage to trigger CloudWatch alarm"
echo ""
# Create CPU load using yes command
echo "Starting CPU load processes..."
for i in $(seq 1 $CORES); do
(yes > /dev/null) &
CPU_PID=$!
echo "Started CPU load process $i (PID: $CPU_PID)"
echo $CPU_PID >> /tmp/cpu_test_pids
done
# Auto-cleanup after 5 minutes
(sleep 300 && echo "Stopping CPU load processes..." && kill $(cat /tmp/cpu_test_pids 2>/dev/null) 2>/dev/null && rm -f /tmp/cpu_test_pids) &
echo ""
echo "CPU load processes started for 5 minutes"
echo "Check CloudWatch for alarm trigger in 3-5 minutes"
EOF
chmod +x /home/ec2-user/cpu-stress-test.sh
chown ec2-user:ec2-user /home/ec2-user/cpu-stress-test.sh
# Create auto-shutdown script (safety mechanism)
cat > /home/ec2-user/auto-shutdown.sh << 'SHUTDOWN_EOF'
#!/bin/bash
echo "Auto-shutdown scheduled for 2 hours from now: $(date)"
sleep 7200
echo "Auto-shutdown executing at: $(date)"
sudo shutdown -h now
SHUTDOWN_EOF
chmod +x /home/ec2-user/auto-shutdown.sh
nohup /home/ec2-user/auto-shutdown.sh > /home/ec2-user/auto-shutdown.log 2>&1 &
nohup sleep 300 && /home/ec2-user/cpu-stress-test.sh > /home/ec2-user/cpu-stress-test.log 2>&1 &
echo "AWS DevOpsAgent test setup completed at $(date)" > /home/ec2-user/setup-complete.txt
Tags:
- Key: Name
Value: AWS-DevOpsAgent-Test-Instance
- Key: Purpose
Value: AWS-DevOpsAgent-Testing
# CloudWatch Alarm for CPU utilization
CPUAlarm:
Type: AWS::CloudWatch::Alarm
Properties:
AlarmName: AWS-DevOpsAgent-EC2-CPU-Test
AlarmDescription: AWS-DevOpsAgent beta test - EC2 CPU utilization alarm
MetricName: CPUUtilization
Namespace: AWS/EC2
Statistic: Average
Period: 60
EvaluationPeriods: 1
Threshold: 50
ComparisonOperator: GreaterThanThreshold
Dimensions:
- Name: InstanceId
Value: !Ref TestInstance
TreatMissingData: notBreaching
CloudFormationで上記のコードを実行すると以下の構成ができあがります。
AWSマネジメントコンソールにログインし、画面上の検索窓で「CloudFormation」と入力し、サービスの下に表示された [CloudFormation] をクリックし、CloudFormationのコンソール画面を開きます。また今回のハンズオンは東京リージョンで実施しますので、右上のリージョンが東京になっていない場合は東京に変更しておきましょう。
スタック一覧の画面が表示されるので、右上の [スタックの作成] - [新しいリソースを使用 (標準)] をクリックします。
もしスタック一覧が表示されない場合は、左上のハンバーガーメニュー(三本線のアイコン)をクリックし、ナビゲーションペイン(左メニュー)を表示し、スタックをクリックしてスタック一覧を表示します。
スタックの作成画面が表示されるので、以下を設定して [次へ] をクリックします。
・テンプレートソース: テンプレートファイルのアップロード
・テンプレートファイルのアップロード: ファイルの選択をクリックし、先ほどローカルに保管した handson8.yml を選択
スタックの詳細を指定の画面で、スタック名に DevOpsAgent-handson と入力して、右下の [次へ] をクリックします。
スタックオプションの設定画面が表示されるので、一番下にスクロールして、AWS CloudFormation によって IAM リソースが～にチェックを入れ、右下の [次へ] をクリックします。
:
レビューの画面が表示されるので、下にスクロールして右下の [送信] をクリックします。
:
[送信] をクリックすると、CloudFormationによって、AWSリソースの作成が始まります。ステータスが CREATE_IN_PROGRESS から CREATE_COMPLETE になったら作成完了です。5分ほどかかりますので、作成完了まで待ちます。
【作成中】
【作成完了】
構成ができあがってから5分後に自動で負荷がかかるようにしていますので、10分後くらいにはCloudWatch AlarmでCPU使用率がアラーム状態(閾値越え)が起きます。このアラーム状態が起きた原因をDevOps Agentで調査を行います。
3．DevOps Agentで調査
DevOps Agent で調査を行っていきます。
手順1．で用意したDevOps Agentのエージェントスペースを開きます。
画面右上の [オペレーターアクセス] をクリックします。
インシデントレスポンスダッシュボードが開くので、[調査を開始] をクリックします。
今回は 調査の詳細 に「直近のAWS-DevOpsAgent-EC2-CPU-Testがアラーム状態になった原因を教えてください。」とだけ入力し、右下の [調査を開始中…] をクリックします。ほかにも入力項目がありますが、情報を入力すると調査の精度が上がります。
言語は一部日本語がサポートされていますが、基本は英語です。指示は日本語で大丈夫ですが、結果は英語で返ってきます。
クリックすると、あとは自動でいろいろな調査項目を並列で処理してくれますので、しばらく待ちます。
しばらく待っていると Root Cause (根本原因) が表示されます。[Go to root cause] をクリックすると、根本原因タブを表示します。
根本原因タブでも同じ内容を確認することができます。[Generate mitigation plan] (緩和計画) をクリックすると対策を確認することができます。ただ、今回は一時的に意図的に負荷をかけているので、緩和計画はないという結果になります。
日本語訳 1. EC2 UserData内の意図的なCPUストレステストスクリプトがアラームをトリガーしました CloudWatch アラーム「AWS-DevOpsAgent-EC2-CPU-Test」は、EC2 インスタンス UserData で設定された意図的な CPU ストレス テストによってトリガーされました。 UserData スクリプトは、インスタンス起動後 5 分 (2026-03-10T04:43:42Z) に自動的に実行され、各 CPU コア (t3.micro では 2 コア) に対して「yes > /dev/null」プロセスを生成し、意図的に 70% を超える CPU 使用率を発生させます。 このスクリプトは、自動クリーンアップ付きで正確に 5 分間実行されるように設計されています。 タイムライン：インスタンスが04:38:42Zに起動 → UserDataスクリプトが04:43:42Zに開始（5分間のスリープ後） → CPU使用率が04:45:00Zに99.99%に達する → アラームが04:46:12Zにトリガーされる → スクリプトの自動クリーンアップが04:48:42Zに実行される → CPU使用率が04:50:00Zに0.56%まで低下 → アラームが04:52:12Zに復旧。 これは運用上の問題ではなく、CloudWatchアラーム機能の意図的なテストです。
Generate mitigation plan (緩和計画) をクリックした後の画面です。
日本語訳 緩和策は特定できない。 AWS アカウント xxxxxxxxxxxx の EC2 インスタンス i-xxxxxxxxxxxxx (arn:aws:ec2:xxxxxxxxx) は、設計どおりに動作しています。 CloudWatch アラーム「AWS-DevOpsAgent-EC2-CPU-Test」は、アラーム機能の検証を目的として EC2 UserData スクリプトで設定された意図的な CPU ストレス テストによってトリガーされました。 ストレス テストはインスタンス起動後 5 分後に自動的に実行され、意図どおり 99.99% の CPU 使用率を生成し、設定された 70% のしきい値でアラームをトリガーし、5 分後に自動的にクリーンアップされました。 システムは通常の CPU レベル (0.56%) に回復し、アラームは OK 状態に戻りました。 これは、設計どおりに動作する意図的なテスト メカニズムであり、修復を必要とする運用上のインシデントではありません。 観測された動作から、ストレステストスクリプトとCloudWatchアラーム監視の両方が正しく機能していることが確認されました。
調査は以上になります。
DevOps Agentを使うことでなにか起きたときの調査を楽に行うことができることが理解できたと思います。
4．後片付け
AWSのリソースは従量課金のため、作ったまま放置しておくとお金がかかってしまいます。そのため、ハンズオンが終わったら不要なリソースは削除しておきましょう。
まず、CloudFormationでスタックの削除をします。
CloudFormationでまとめて作成したリソース(VPC、EC2)は、まとめて削除できます。
CloudFormationのコンソール画面を開き、ナビゲーションペイン(左メニュー)の [スタック] をクリックしてスタック一覧を開きます。ハンズオン環境構築のスタック(DevOpsAgent-handson) を選択し、 [スタックを削除] をクリックします。
確認画面が表示されますので、DevOpsAgent-handson と入力し、右下の [スタックを削除] をクリックします。
5分ほど経つと削除が完了します。
次に DevOps Agentのエージェントスペースの [アクション] - [エージェントスペースを削除] をクリックします。
確認画面が表示されるので、[確認] をクリックします。
DevOps Agentのエージェントスペースの削除が終わりました。
これで今回のハンズオンは以上となります。
まとめ
今回はDevOps Agentを基本的な使い方を確認しました。なにか問題が起きたときに、今まで人がログや通信状況などをそれぞれ確認していましたが、DevOps Agentを利用すると並列に確認を行っていきますので、人が確認するよりも早く原因を特定することができます。
まだパブリックプレビューのため、正式リリース時には動作などが変わる可能性がありますので、正式リリース後にもう一度動作確認をしたほうがよいと考えています。
小倉 大(記事一覧)
アプリケーションサービス部エデュケーショナルサービス課 札幌在住
AWSトレーニングの講師をしています。
最近は7歳の息子と遊ぶのが楽しいです！
Twitter: @MasaruOgura
