AWSに関するお問い合わせ：https://www.serverworks.co.jp/contact/ サーバーワークスエンジニアブログ：http://blog.serverworks.co.jp/tech/ AWS Systems manager 入門 Amazon EC2とオンプレミスシステムの設定と管理

1. Amazon EC2 Systems Manager
Amazon EC2 とオンプレミスシステムの設定と管理
サーバーワークス プライベートセミナー
クラウドインテグレーション部
カスタマーサポート課
伊藤 覚宏
2017/06

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

3. 一般的なシステム運用

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

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

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

7. Amazon EC2 Systems Managerとは

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

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

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

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

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

13. ステートマネージャー
13

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

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

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

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

18. メンテナンスウィンドウ
18

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

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

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

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

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

24. メンテナンスウィンドウ
ターゲットの登録
タグ指定もしくは、インスタンス指定で登録ができます
24

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

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

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

28. パッチマネージャー
28

29. パッチマネージャー
29

30. パッチマネージャー
30

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

32. オートメーション
32

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

34. パラメータストア
34

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

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

37. パラメータストア
パラメータストアからのデータ取得
パラメータストアへのアクセスは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.*"
]
}
]
37

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

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

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

41. Amazon EC2 Systems Managerの前提条件

42. 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
42

43. 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 以降
43

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

45. EC2 Systems Managerの前提環境条件
SSMエージェントの実行ユーザ
SSMエージェントは以下のユーザとしてコマンドを実行します。
2017/06/23現在実行ユーザを変更することはできません。
45
OS 実行ユーザ
Windows system
Linux root

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

47. 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/
47

48. Amazon EC2 Systems Managerの利用設定
（EC2）

49. 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を実行
49

50. SSM Agentのインストール(Windows on EC2)
50

51. SSM Agentのインストール(Windows on EC2)
Windows Server 2016の場合はAWS-UpdateSSMAgent
Windows Server 2012以前の場合はAWS-UpdateEC2Config を選択しま
す
51

52. SSM Agentのインストール(Windows on EC2)
コマンド実行対象のインスタンスを選択します
52

53. SSM Agentのインストール(Windows on EC2)
Runボタンをクリックします
53

54. SSM Agentのインストール(Windows on EC2)
54

55. SSM Agentのインストール(Windows on EC2)
55

56. SSM Agentのインストール(Windows on EC2)
56

57. SSM Agentのインストール(Windows on EC2)
57

58. SSM Agentのインストール(Windows on EC2)
58

59. 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
59

60. 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 ビット:
https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-
1/latest/linux_386/amazon-ssm-agent.rpm
Ubuntu Server 64 ビット:
https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-
1/latest/debian_amd64/amazon-ssm-agent.deb
Ubuntu Server 32 ビット:
https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-
1/latest/debian_386/amazon-ssm-agent.deb
60

61. Amazon EC2 Systems Managerの利用設定
（オンプレミス）

62. アクティベーション
オンプレミスのサーバーにSystems Managerを利用する場合、アクティ
ベージョンを行う必要があります
62

63. アクティベーション
63

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

65. アクティベーション
65

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

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

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

69. アクティベーション
[Amazon EC2 Role for Simple Systems Manager]を選択します。
69

70. アクティベーション
AmazonEC2RoleforSSMポリシーを選択します
70

71. アクティベーション
作成したサービスロールで[信頼関係の編集]をクリックします
71

72. アクティベーション
信頼関係を以下の通りに書き換えます
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"Service": "ssm.amazonaws.com"},
"Action": "sts:AssumeRole"
}
}
72

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

74. アクティベーション（Windows）
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"
74

75. アクティベーション（Windows）
75

76. アクティベーション
マネージドインスタンスとしてインスタンスID:[mi-]で
オンプレミスのサーバが登録されます
76

77. アクティベーション
登録済みインスタンスの数が表示されます
77

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

79. アクティベーション（Linux）
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
79

80. アクティベーション（Linux）
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 amazon-ssm-agent -register -code "code" -id "id" -region "region"
sudo systemctl start amazon-ssm-agent
80

81. アクティベーション（Linux）
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 amazon-ssm-agent -register -code "code" -id "id" -region "region"
sudo service amazon-ssm-agent start
81

82. アクティベーション（Linux）
実行例(RHEL7.3)
82

83. アクティベーション
マネージドインスタンスとしてインスタンスID:mi-で
オンプレミスのサーバが登録されます
83

84. Amazon EC2 Systems Managerの利用例

85. Amazon EC2 Systems Managerの利用例
Windowsのパッチ管理
ITシステムの構成管理
AMI管理の自動化
85

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

87. Windowsのパッチ管理
Systems Manager[メンテナンスウィンドウ]用のIAMロールを作成します。
87

88. Windowsのパッチ管理
[AWS サービスロール]-[Amazon EC2]を選択します
88

89. Windowsのパッチ管理
管理ポリシー[AmazonSSMMaintenanceWindowRole]をアタッチします。
89

90. Windowsのパッチ管理
メンテナンスウィンドウ用とわかる名前を付けてポリシーを作成します。
90

91. Windowsのパッチ管理
[メンテナンスウィンドウ]用に作成したIAMロールの信頼関係を編集します
91

92. Windowsのパッチ管理
以下の通り信頼関係に[ssm.amazonaws.com]を追加します
92
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com",
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}

93. Windowsのパッチ管理
IAMロールに信頼関係に[ssm.amazonaws.com]を追加します
93

94. Windowsのパッチ管理
パッチベースラインを作成します
94

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

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

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

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

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

100. Windowsのパッチ管理
メンテナンスウィンドウに対してターゲットを登録します
10

101. Windowsのパッチ管理
メンテナンスウィンドウのターゲットで対象のインスタンス、
Patch Groupを指定します
10

102. Windowsのパッチ管理
メンテナンスウィンドウに対してタスクを登録します
10

103. Windowsのパッチ管理
ドキュメント[AWS-ApplyPatchBaseline]を選択します
10

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

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

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

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

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

109. ITシステムの構成管理
Systems Managerを利用して、インスタンスのインベントリ情報を収集す
る方法を紹介します
109

110. ITシステムの構成管理
110
[マネージメントインスタンス]を選択し[セットアップインベントリ]をク
リックします

111. ITシステムの構成管理
111

112. ITシステムの構成管理
[ターゲット]でインベントリ情報を収集するインスタンスを個別またはタグ
で指定します
112

113. ITシステムの構成管理
インベントリ情報の収集頻度を指定します
30分周期、指定時間周期、指定曜日の指定時間のいずれかが選べます
113

114. ITシステムの構成管理
収集する項目を選択します
114

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

116. ITシステムの構成管理
[セットアップインベントリ]をクリックし、設定を保存します
116

117. ITシステムの構成管理
インスタンスおよびマネージドインスタンス（オンプレミス）のインベント
リ情報は[インベントリ]タブで[inventory Type]を選択することで確認がで
きます
117

118. ITシステムの構成管理
AWS Configを有効にしている場合、インベントリの変更履歴を管理するこ
とが出来ます
118

119. ITシステムの構成管理
119

120. ITシステムの構成管理
120

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

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

123. AMI更新の自動化
[オートメーション]で利用するIAMロールを作成します
123

124. AMI更新の自動化
[AWS サービスロール]-[Amazon EC2]を選択します
124

125. AMI更新の自動化
[AmazonSSMAutomationRole]ポリシーをアタッチします
125

126. AMI更新の自動化
Automationで利用すると分かりやすい名前を付けてロールを作成します
126

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

128. AMI更新の自動化
[Automation]用に作成したIAMロールの信頼関係を編集します
128

129. AMI更新の自動化
以下の通り信頼関係に[ssm.amazonaws.com]を追加します
129
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com",
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}

130. AMI更新の自動化
IAMロールに信頼関係に[ssm.amazonaws.com]を追加します
130

131. AMI更新の自動化
EC2インスタンスにアタッチするIAMを作成します。
131

132. AMI更新の自動化
[AWS サービスロール]-[Amazon EC2]を選択します
132

133. AMI更新の自動化
[AmazonEC2RolesorSSM]ポリシーをアタッチします
133

134. AMI更新の自動化
EC2インスタンス用とわかる名前を付けてロールを作成します。
134

135. AMI更新の自動化
以下の通り信頼関係に[ssm.amazonaws.com]を追加します
135
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com",
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}

136. AMI更新の自動化
IAMロールに信頼関係に[ssm.amazonaws.com]を追加します
136

137. AMI更新の自動化
[EC2インスタンス]用に作成したIAMロールの信頼関係を編集します
137

138. AMI更新の自動化
以下の通り信頼関係に[ssm.amazonaws.com]を追加します
138
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com",
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}

139. AMI更新の自動化
IAMロールに信頼関係に[ssm.amazonaws.com]を追加します
139

140. AMI更新の自動化
[Automation]用に作成した作成したIAMロールにインラインポリシーを追
加します
140

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

142. AMI更新の自動化
AMI更新のベースとするAMIのAMI IDをコピーしておきます
142

143. AMI更新の自動化
[自動化][自動化ドキュメントの実行]をクリックします
143

144. AMI更新の自動化
[AWS-UpdateLinuxAmi]ドキュメントを選択し、バージョン [1]を選択し
ます
144

145. AMI更新の自動化
パラメータを入力し、[自動化を実行]をクリックします
145

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

147. AMI更新の自動化
[オートメーション]が実行されたら[閉じる]をクリックします
147

148. AMI更新の自動化
[オートメーション]実行中は[InProgress]となります
148

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

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

151. まとめ

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

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

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

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

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