Systems manager 入門 ops jaws

Amazon EC2 Systems Manager
Amazon EC2 とオンプレミスシステムの設定と管理
OpsJaws #12
株式会社サーバーワークス
クラウドインテグレーション部
カスタマーサポート課
伊藤覚宏
2017/07/19

目次
一般的なシステム運用
Amazon EC2 Systems Managerとは
Amazon EC2 Systems Managerの前提条件
Amazon EC2 Systems Managerの利用設定
Amazon EC2 Systems Managerの利用例
2

システム監視
システムが正常に稼働しているか
ソースに過不足が発生していないか
証跡管理
問題はいつ誰がどのように修正したか
ルールに従った作業実施、記録されているか
認証管理
権限は適切に設定されているか
セキュリティの問題は発生していないか
構成管理
意図した構成が保たれているか
4

監視ツール
構成管理ドキュメント
ユーザー、権限管理ドキュメント
変更管理ドキュメント
セキュリティパッチングツール、スクリプト
リモートアクセス用の踏み台サーバー
5

AWSでも同様にシステム管理を行う事は可能
Excelなどで構成管理することも可能
ただしAWSでは構成変更が簡単に行えるため、手動記録では追従が困難
クラウドの旨味が活かせない
6

ソフトウェアインベントリの収集や OS パッチの適用、システムイメージの
作成、そして Windows や Linux のオペレーティングシステム設定などの
プロセスを自動化する管理サービス
AWS ConfigはAWSの構成を管理
Systems ManagerはOS内部の構成を管理
8

Amazon EC2 Systems Managerの構成要素
Systems Managerは複数の要素で構成されます
Run Command ステートマネージャーインベントリメンテナンスウィンドウ
パッチマネージャーオートメーションパラメータストア
9

Run Command
管理作業をリモートから実行
リモートから任意のコマンド実行が可能
ソフトウェアのインストール、パッチング、アップデート
ユーザーの追加・削除、サービスの起動・停止、状態取得
JSONベースのドキュメントでコマンド、タスクを定義
定義済みのドキュメントも提供、コミュニティ版もあり
実行結果はS3に保存可能、実行状態に合わせてSNSを使って通知
SSH、RDPの接続ポートを閉じる事でセキュアに運用
Cloud Automator でも対応
10

Run Command
マネージメントコンソールでは [コマンドの実行] となります
11

ステートマネージャー
OSとアプリケーションの設定を定義、状態を維持する
事前に定義しておいた状態にOSを設定
JSONベースのドキュメントを使用してポリシーを定義
構成を適用するEC2・オンプレサーバーを個別、タグで管理
企業全体の構成ポリシーへの準拠を支援
例：ウィルス対策ソフト、マルウェア対策ソフトの定義ファイル更新
12

13

インベントリ
ソフトウェアインベントリの情報収集
EC2・オンプレミスの各種インベントリ情報を収集、管理
AWSが定義する収集テンプレートを利用可能
JSON形式で取得したいデータを定義する事でカスタマイズも可能
AWS Configを有効にする事でインベントリ情報の変更履歴を追跡
ソフトウェアのライセンス使用状況確認、ソフトウェアバージョンの管理が
簡素化される事でのセキュリティ脆弱性の早期発見が可能
定期的な収集自体はステートマネージャーで設定を行う
14

インベントリ
マネージドインスタンスの[インベントリ]タブから確認することができます
15

インベントリ
AWS ConfigのSSM インベントリ情報として履歴を管理することが可能
16

メンテナンスウィンドウ
事前に設定した時間でメンテナンスを実施
システムの中断を許容できる時間を指定
OSのアップデート、各種ドライバの更新、ソフトウェアのインストール etc…
組み込み済みのコマンド、Run Commandの実行が可能
メンテナンス実行の時間を明確に決めておく事で可用性と信頼性向上
考え方はRDSのMaintenance Windowと同様
許容期間内での実行はメンテナンスウィンドウ
時間指定はCloud Automatorなどの使い分けが可能
17

18

設定は3ステップ
Maintenance Windowで実行する繰り返し日時を指定する
メンテナンス対象のターゲットを指定する
実行するタスクを指定する
19

メンテナンスウィンドウはスケジュール指定もしくはCron書式で登録する
ことが可能
20

メンテナンスウィンドウはスケジュール指定もしくはCron書式で登録する
ことが可能
21

メンテナンスウィンドウでは次の内容を指定します
スケジュール: 開始時刻や繰り返し周期など
期間: タスク実行を許可する期間
タスクの開始を停止: 期間の終了から逆算した新規タスクのスタートを停止する
時間
22

定義したメンテナンスウィンドウに対して対象を登録することで、定期的な
タスクを実行します
ターゲットの登録: タスクを実行するインスタンスを登録します
タスクの登録: 実行するタスクが定義されたドキュメントを指定します
23

ターゲットの登録
タグ指定もしくは、インスタンス指定で登録ができます
24

タスクの登録
実行するドキュメントを選択します
25

パッチマネージャー
ベースラインを定義してWindows/Linuxのパッチを適用
Patch Baselineを使ってカスタムパッチポリシーを定義
例：クリティカルなパッチが提供された場合には1日後に適用
パッチ適用は指定したMaintenance Window内で実施
実施されたパッチングの結果はレポートされる
インストールされたパッチ、スキップ、失敗したパッチ等
重要なアップデートやゼロデイ脆弱性への対応を自動化、時間を短縮
※2017/07/07からLinuxにも対応！
26

パッチマネージャーは[パッチコンプライアンス],[パッチベースライ
ン],[パッチ]（リスト）から構成されます
27

28

29

30

31

32

33

34

オートメーション
シンプルなワークフローを使って一般的なタスクを自動化
Amazon Machine Images(AMI)の作成と管理に最適化
AMIからEC2を起動 →パッチ適用 →更新されたAMIを作成
JSONベースのドキュメントでワークフローを定義
企業で管理する「ゴールデンイメージ」管理をサポート
35

パラメータストア
IT資産の集中管理
ログイン、DB接続情報などを一元管理
Run Commnad、State Manager、Automation 等から参照可能
Management Consoleからも参照、更新が可能
AWS CLI、各種SDKからも参照、更新が可能
細かい権限管理で必要な人に必要な情報を提供
Parameter Storeに格納した情報はKMSで暗号化
企業の機密情報の分散管理、メンテナンスを簡素化
37

パラメータストアにはパラメータを保存することが出来ます
文字列
リスト
KMSで暗号化された文字列
39

パラメータストアからのデータ取得
Run Command、Automation、State Managerで参照可能
例：AWS CLIから参照する場合(赤字部分は編集)
aws ssm get-parameters --name パラメータ名
KMSで暗号化していた値を参照する場合
例：AWS CLIから参照する場合(赤字部分は編集)
aws ssm get-parameters --names パラメータ名 --with-decryption
40

パラメータストアからのデータ取得
パラメータストアへのアクセスはIAMで制御が出来るため、パラメータ名の
命名規則を整備することで、環境毎やユーザ毎に特定の情報のみにアクセス可能
にすることが可能です
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:Describe*",
"ssm:Get*",
"ssm:List*"
],
"Resource": [
"arn:aws:ssm:ap-northeast-1:123456789123:parameter/prd.*"
]
}
]
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:Describe*",
"ssm:Get*",
"ssm:List*"
],
"Resource": [
"arn:aws:ssm:ap-northeast-1:123456789123:parameter/test.*"
]
}
]
41

ドキュメント
Systems Managerで実行する各種動作は[ドキュメント]として動作します
AWSの定義済みドキュメントと、カスタムドキュメントが利用出来ます
42

ドキュメント
ドキュメントには[Command],[Policy],[Automation]の3タイプがありま
す
43

ドキュメント
ドキュメントのタイプ毎に、利用されるサービスが異なります
タイプサービス
Command Run Command
Policy ステートマネージャー
Automation オートメーション
44

Amazon EC2 Systems Managerの前提条件

SSM Agent
Systems Managerの利用にはSSM Agentのインストールが必要です
管理対象に常駐し、各種サービスからの要求を実行
インストールタイプのエージェント
AWSの各種サービスAPIと通信が発生
AWSから提供している以下のAMIにはインストール済み
2016年11月以降に提供しているWindows AMI(2003-2012R2、2016)
Amazon Linuxは別途インストールが必要
Source CodeはGithubで公開
https://github.com/aws/amazon-ssm-agent
46

EC2 Systems Managerの前提環境条件
サポートされているOS
Windows(32bit、64bit)
Windows Server 2003〜2016(R2含む)
Linux(32bit)
Amazon Linux 2014.09、2014.03 以降
Ubuntu Server 16.0.4 LTS、14.04 LTS、または 12.04 LTS
Red Hat Enterprise Linux (RHEL) 6.5 以降
CentOS 6.3 以降
Linux(64bit)
Amazon Linux 2015.09、2015.03 以降
Red Hat Enterprise Linux (RHEL) 7.x 以降
CentOS 7.1 以降
47

インターネットへのアクセスが出来る事
SSM Agentが各種APIへアクセスするため
APIアクセスのためport 80,443 アウトバウンドを許可してください
NAT-Gatewayでも可
インターネットからの接続は不要
48

SSMエージェントの実行ユーザ
SSMエージェントは以下のユーザとしてコマンドを実行します。
2017/06/23現在実行ユーザを変更することはできません。
OS 実行ユーザ
Windows system
Linux root
49

IAM Roleの作成（EC2の場合）
IAM Roleを作成して権限を付与
SSM Agentが各種APIをコールする権限
例：Automationであれば ec2:CreateImage 等
用途によって権限を分ける
AWS管理ポリシーを活用
AmazonSSMFullAccess、AmazonSSMReadOnlyAccess等
カスタムポリシーも作成可能
50

IAM Roleの作成（EC2の場合）
IAM Roleが付与されていないEC2に対しても、2017/02/12からアタッチが
可能になりました
https://aws.amazon.com/jp/blogs/news/new-attach-an-aws-iam-role-to-an-existing-amazon-ec2-instance-by-using-the-aws-cli/
51

（EC2）

SSM Agentのインストール(Windows on EC2)
AWS提供のWindows AMIはインストール済み
2016年11月以降のAMIから起動したWindowsは導入済み
2016年11月以前のAMIから起動したWindowsは更新が必要
SSM Agentを更新する
EC2Configでの更新を推奨
Run CommandでAWS-UpdateEC2Configを実行
Windows Server 2016の場合はAWS-UpdateSSMAgentを実行
53

54

Windows Server 2016の場合はAWS-UpdateSSMAgent
Windows Server 2012以前の場合はAWS-UpdateEC2Config を選択しま
す
55

コマンド実行対象のインスタンスを選択します
56

Runボタンをクリックします
57

58

59

60

61

62

SSM Agentのインストール(Linux on EC2)
SSM Agentをダウンロード、インストール
リポジトリ(S3)からダウンロード
https://amazon-ssm-region.s3.amazonaws.com/latest/$arch/amazon-ssm-
agent.rpm
region部分は利用するRegionに置き換える
$arch部分もディストリビューションに合わせて置き換える
各種パッケージコマンドでインストール
sudo yum install -y amazon-ssm-agent.rpm
sudo dpkg -i amazon-ssm-agent.deb
コマンド詳細は以下のURLを確認
http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/ssm-
agent.html
63

SSM Agentのインストール(Linux on EC2)
SSM Agentをダウンロード、インストール
リポジトリ(S3)からダウンロード
東京リージョンの場合
Amazon Linux、RHEL、および CentOS 64 ビット:
https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-
1/latest/linux_amd64/amazon-ssm-agent.rpm
Amazon Linux、RHEL、および CentOS 32 ビット:
1/latest/linux_386/amazon-ssm-agent.rpm
Ubuntu Server 64 ビット:
1/latest/debian_amd64/amazon-ssm-agent.deb
Ubuntu Server 32 ビット:
1/latest/debian_386/amazon-ssm-agent.deb
64

（オンプレミス）

アクティベーション
オンプレミスもしくは別クラウド別アカウントのサーバーにSystems
Managerを利用する場合、アクティベージョンを行う必要があります
66

67

アクティベーションには以下の内容を入力します
アクティベーションの名前
アクティベーションを許可するサーバ数
使用するIAMロール
アクティベーションの有効期間
サーバに付与する名前
68

69

アクティベーションコードは再表示、ファイルダウンロードなどが出来ない
ので、忘れずにコピーしてください
70

サービスロールを作成します
サービスロールの作成はSystems Managerを利用するAWSアカウントで一度実
行するだけで、サーバ毎に行う必要はありません
71

サービスロールを作成します
サービスroleの作成はSystems Managerを利用するAWSアカウントで一度実行
するだけで、サーバ毎に行う必要はありません
IAMで[新しいロールの作成]を行います。
72

[Amazon EC2 Role for Simple Systems Manager]を選択します。
73

AmazonEC2RoleforSSMポリシーを選択します
74

作成したサービスロールで[信頼関係の編集]をクリックします
75

信頼関係を以下の通りに書き換えます
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"Service": "ssm.amazonaws.com"},
"Action": "sts:AssumeRole"
}
}
76

アクティベーション（Windows）
オンプレミスのWindowsに[AWS Tools for Windows PowerShell]をイン
ストールします
https://aws.amazon.com/jp/powershell/
77

Windows PowerShell for AWSを起動し以下のコマンドを入力します
赤文字の部分は次の通り書き換えてください
code:アクティベーションコード
id:アクティベーションID
region: Systems Managerを設定しているリージョン
$dir = $env:TEMP + "¥ssm"
New-Item -ItemType directory -Path $dir
cd $dir
(New-Object System.Net.WebClient).DownloadFile("https://amazon-ssm-
region.s3.amazonaws.com/latest/windows_amd64/AmazonSSMAgentSetup.exe", $dir +
"¥AmazonSSMAgentSetup.exe")
Start-Process .¥AmazonSSMAgentSetup.exe -ArgumentList @("/q", "/log", "install.log", "CODE=code",
"ID=id", "REGION=region") -Wait
Get-Content ($env:ProgramData + "¥Amazon¥SSM¥InstanceData¥registration")
Get-Service -Name "AmazonSSMAgent"
78

79

マネージドインスタンスとしてインスタンスID:[mi-]で
オンプレミスのサーバが登録されます
80

登録済みインスタンスの数が表示されます
81

アクティベーション（Linux）
ディストリビューション毎にそれぞれコマンドを実行します
赤文字の部分は次の通り書き換えてください
code: アクティベーションコード
id: アクティベーションID
region: Systems Managerを設定しているリージョン
82

Amazon Linux、RHEL 6.x、CentOS 6.x
mkdir /tmp/ssm
sudo curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-
agent.rpm -o /tmp/ssm/amazon-ssm-agent.rpm
sudo yum install -y /tmp/ssm/amazon-ssm-agent.rpm
sudo stop amazon-ssm-agent
sudo amazon-ssm-agent -register -code "code" -id "id" -region "region"
sudo start amazon-ssm-agent
83

RHEL 7.x および CentOS 7.x
mkdir /tmp/ssm
sudo curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-
agent.rpm -o /tmp/ssm/amazon-ssm-agent.rpm
sudo yum install -y /tmp/ssm/amazon-ssm-agent.rpm
sudo systemctl stop amazon-ssm-agent
sudo systemctl start amazon-ssm-agent
84

Ubuntu
mkdir /tmp/ssm
sudo curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/debian_amd64/amazon-ssm-
agent.deb -o /tmp/ssm/amazon-ssm-agent.deb
sudo dpkg -i /tmp/ssm/amazon-ssm-agent.deb
sudo service amazon-ssm-agent stop
sudo service amazon-ssm-agent start
85

実行例(RHEL7.3)
86

マネージドインスタンスとしてインスタンスID:mi-で
オンプレミスのサーバが登録されます
87

Windowsのパッチ管理
ITシステムの構成管理
AMI管理の自動化
89

Systems Managerの[パッチベースライン]、[メンテナンスウィンドウ]を
利用して、Windowsに定期的にパッチを適用する方法を紹介します
90

Systems Manager[メンテナンスウィンドウ]用のIAMロールを作成します。
91

[AWS サービスロール]-[Amazon EC2]を選択します
92

管理ポリシー[AmazonSSMMaintenanceWindowRole]をアタッチします。
93

メンテナンスウィンドウ用とわかる名前を付けてポリシーを作成します。
94

[メンテナンスウィンドウ]用に作成したIAMロールの信頼関係を編集します
95

以下の通り信頼関係に[ssm.amazonaws.com]を追加します
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com",
"Service": "ssm.amazonaws.com"
},
}
]
}
96

IAMロールに信頼関係に[ssm.amazonaws.com]を追加します
97

パッチベースラインを作成します
98

パッチベースラインで適用するパッチのベースを指定します
Product: OSバージョン
Classification: パッチ分類
Severity: 重要度
Auto Approval Delay: 遅延日数
99

パッチベースラインで適用するパッチのベースを指定します
例外設定を行うことで、特定のパッチだけを分類や重要度を無視して適用、非適
用を指定することが可能です
100

EC2インスタンスの場合 [Patch Group]というタグキーを指定することに
より、パッチ適用対象をグループ化して管理することができます
マネージドインスタンスにはタグを付与する事が出来ないため[Patch Group]
は利用出来ません。インスタンス単位で指定を行います
101

作成したベースラインはデフォルトにするか、適用先の [Patch Group]を
指定することで利用されます
102

パッチの適用スケジュールはメンテナンスウィンドウを利用して指定します
103

メンテナンスウィンドウに対してターゲットを登録します
104

メンテナンスウィンドウのターゲットで対象のインスタンス、
Patch Groupを指定します
105

メンテナンスウィンドウに対してタスクを登録します
106

ドキュメント[AWS-ApplyPatchBaseline]を選択します
107

パラメータで[Scan]か[Install]を選択します
Scan: インスタンスをスキャンして欠落しているパッチを確認できるリストを
生成します
Install: インスタンスをスキャンし、ベースラインの承認済みパッチのリスト
とインストールされたパッチのリストを照合します
Patch Manager は、欠落しているパッチを確認すると、すべての欠落している
パッチをダウンロードしてインストールします。パッチをインストールすると、
Systems Manager によってインスタンスが再起動されます
108

ロール欄にプルダウンでIAMロールが表示されるので、
[メンテナンスウィンドウ]用に作成したIAMロールを選択します。
同時実行インスタンス数
パッチ適用を中止するエラーインスタンス数を指定します。
109

パッチの適用状態は[パッチコンプライアンス]で確認することができます
110

定期的な実行でなく、即座に適用したい/チェックしたい場合は
[コマンドを実行]から[AWS-ApplyPatchBaseline]ドキュメントを実行する
こともできます
111

パッチ適用前にAMIを取得するような機能はありません。
試験環境と本番環境で猶予期間の異なるベースラインを適用するなど計画的な
パッチ適用を設定します。
パッチ適用前にバックアップ用のAMIが必要な場合などはCloud Automatorを
組み合わせた運用設計をお進めします。
112

Systems Managerを利用して、インスタンスのインベントリ情報を収集す
る方法を紹介します
113

[マネージメントインスタンス]を選択し[セットアップインベントリ]をク
リックします
114

115

[ターゲット]でインベントリ情報を収集するインスタンスを個別またはタグ
で指定します
116

インベントリ情報の収集頻度を指定します
30分周期、指定時間周期、指定曜日の指定時間のいずれかが選べます
117

収集する項目を選択します
118

インベントリ収集の履歴を記録する場合は[実行履歴をS3に書き込む]に
チェックを付け、バケット名、リージョン、プレフィックスを指定します
119

[セットアップインベントリ]をクリックし、設定を保存します
120

インスタンスおよびマネージドインスタンス（オンプレミス）のインベント
リ情報は[インベントリ]タブで[inventory Type]を選択することで確認がで
きます
121

AWS Configを有効にしている場合、インベントリの変更履歴を管理するこ
とが出来ます
122

123

124

AMI更新の自動化
[オートメーション]を利用し、AMIから自動的にインスタンスを生成し、
アップデートを適用後、新たなAMIを作成し使用したインスタンスを削除す
る手順を紹介します
この手順はオートメーションのチュートリアルとして公式ドキュメントでも公開されています
http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/sysman-ami-consolewalk.html
125

[オートメーション]ではSysytems Manager Automationが利用するIAMと
AutomationからEC2インスタンスに渡されるIAMの2つが必要となります。
この手順はオートメーションのチュートリアルとして公式ドキュメントでも公開されています
http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/sysman-ami-consolewalk.html
126

[オートメーション]で利用するIAMロールを作成します
127

128

[AmazonSSMAutomationRole]ポリシーをアタッチします
129

Automationで利用すると分かりやすい名前を付けてロールを作成します
130

[自動化]のパラメーターに必要になるためロールARNをコピーして記録して
おきます
131

[Automation]用に作成したIAMロールの信頼関係を編集します
132

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
},
}
]
}
133

134

EC2インスタンスにアタッチするIAMを作成します。
135

136

[AmazonEC2RolesorSSM]ポリシーをアタッチします
137

EC2インスタンス用とわかる名前を付けてロールを作成します。
138

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
},
}
]
}
139

140

141

[Automation]用に作成した作成したIAMロールにインラインポリシーを追
加します
142

PassRoleの権限を付与し、EC2インスタンス用のIAM にPassRoleできるよ
うにします
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
" arn:aws:iam::xxxxxxxxxxx:role/AmazonEC2RoleforSSM"
]
}
]
}
143

AMI更新のベースとするAMIのAMI IDをコピーしておきます
144

[自動化][自動化ドキュメントの実行]をクリックします
145

[AWS-UpdateLinuxAmi]ドキュメントを選択し、バージョン [1]を選択し
ます
146

パラメータを入力し、[自動化を実行]をクリックします
147

パラメーターの内容は以下の通り
パラメーター入力内容
SourceAmiId 更新元となるAMI ID
InstanceIamRole EC2インスタン用IAMロール名
AutomationAssumeRole Automation用IAMロールARN
TargetAmiName 作成するAMI名
InstanceType 途中に生成するインスタンスタイプ
PreUpdateScript 更新を適用する前に実行するスクリプトのURL
PostUpdateScript 更新を適用した後に実行するスクリプトのURL
IncludePackages 更新する特定のパッケージ名
デフォルトではすべてのパッケージが更新されます
ExcludePackages 更新から除外する特定のパッケージ名
148

[オートメーション]が実行されたら[閉じる]をクリックします
149

[オートメーション]実行中は[InProgress]となります
150

[ステップ]タブで[オートメーション]の進捗を確認することができます
ベースAMIが古い場合、長い時間がかかる場合があります
151

[オートメーション]を利用することで、インスタンスの稼働時間を最小にし
ながら、AMIを最新の状態に保つことが可能です
この方法では、手動でAMI IDを指定する必要があります
Lambdaとパラメータストアを利用することで、最新のAMI IDを自動的に
設定することも可能です
Automation、Lambda、および Parameter Store を使用した AMI へのパッチ適用の簡素化
AMI にパッチを適用し、Auto Scaling グループを更新する
152

まとめ
Systems Managerを利用することで、AWSだけではなく、オンプレミス/
他のクラウドなどを含めたOSの構成管理が可能となります
Systems Managerの各動作はJSON形式の[ドキュメント]で定義されます
154

まとめ
プリセットのドキュメントがあるため、簡単な操作であれば既存ドキュメン
トの選択で実現できます
複雑な動作を実現する場合はJSONドキュメントを作成する必要があります
155

まとめ
Systems ManagerとCloud Automatorの比較
Systems Managerでは、IAMロールとJSONを利用することで複雑な処理を
行う事が可能です
Cloud Automatorの場合わかりやすいGUIにより簡単に設定を行うことが
可能です
機能 Systems Manager Cloud Automator
ステップ処理オートメーションで設定 SQSによる連携
OS内部処理 SSMエージェントにより実行 SSMエージェントにより実行
定期実行メンテナンスウィンドウで設定タイマートリガー
156

免責事項
 本書の情報・資料の掲載には注意を払っておりますが、掲載された情報の内容が正確であるか、更新
時期が適切かどうかなどについて一切保証するものではありません。また、掲載された情報またはそ
の誤りなど、本書に関連して生じた損害または障害などに関しては、その理由の如何に関わらず、当
社は一切責任を負うものではありません。
157

Systems Managerを利用することでオンプレミスを含めた
構成管理や定型運用の自動化が可能です。
Systems Managerの利点を活かすために、ツール利用だけではなく
運用見直しを行う事が重要となります。
クラウド時代の運用改善に是非ご検討ください。

Systems manager 入門 ops jaws

More Related Content

What's hot

Similar to Systems manager 入門 ops jaws

More from 真乙 九龍

Systems manager 入門 ops jaws

More from 真乙九龍