プロキシサーバを経由して AWS Systems Manager 利用する際の設定をやってみた

2020.09.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

今では プライベートサブネットに配置された EC2 インスタンスを AWS Systems Manager(以降 SSM) でマネージドインスタンスとして利用する方法としては、以下のどちらかがスタンダードとなっています。

  • Nat Gateway や Nat インスタンスを用意する
  • VPC エンドポイントを利用する

上記を採用出来ないケース(業務要件であったり)では、以下のようなプロキシサーバを経由して利用する方法が用意されています。

このプロキシサーバを利用する環境は、普段あまりお目にかかる機会がないので、今回やってみました。

やってみた

前提

マネージドインスタンス

  • プライベートサブネット
  • SSM に必要な IAM ロールは付与済み
  • ssm-agent( v 2.3.842.0 )
  • OS
    • Windows 2019(ami-0e9015afafe841ca7)
    • Amazon Linux2(ami-0cc75a8978fbbc969)

プロキシサーバ

  • パブリックサブネット
  • Amazon Linux2(ami-0cc75a8978fbbc969)
  • ミドルウェア
    • Squid

プロキシなし

SSM との通信経路がないため SSM マネージドインスタンスとしては登録されていません。

EC2 インスタンスが正常に起動しています。

マネージドインスタンスが一つもないので、サービス紹介ページが表示されます。

プロキシサーバ用意

今回、プロキシには Squid を利用します。インストール方法は先人の記事を参考にさせていただき、ここでは割愛します。(Client 側の設定は今回は不要です)

用意が完了すると以下の構成となります。

プロキシ利用設定

次に SSM 利用時に用意した プロキシサーバを利用する設定をマネージドインスタンスにしたい EC2 インスタンスへ設定をしていきます。 今回は別途用意してある踏み台を経由して設定を行います。

Amazon Linux2

以下のドキュメントに沿って設定を進めます。

Configure SSM エージェント to use a proxy (systemd)

対象インスタンスへログインします。以下のコマンドで設定画面を表示します。

$ sudo systemctl edit amazon-ssm-agent

編集画面が表示されます。

次に、http と https プロキシに用意した プロキシサーバの IP アドレスとポート番号を入力します。

[Service]
Environment="http_proxy=http://192.168.0.200:3128"
Environment="https_proxy=http://192.168.0.200:3128"
Environment="no_proxy=169.254.169.254"

終了( Ctrl + x )して、 以下の名前を入力して保存します。

/etc/systemd/system/amazon-ssm-agent.service.d/amazon-ssm-agent.override.conf

無事設定が完了したら SSM Agent を再起動します。

$ sudo systemctl stop amazon-ssm-agent
$ sudo systemctl daemon-reload
$ sudo systemctl start amazon-ssm-agent

しばらくすると、 マネージドインスタンスに登録されました!

Session Manager も利用可能です。

Windows2019

Windows でも同様にドキュメントが用意されているため、内容に沿って設定を進めます。

Windows Serverインスタンスのプロキシを使用するようにSSMエージェントを構成する

対象インスタンスへログインします。 PowerShell を起動して設定を行います。

こちら先ほどと同様に用意した プロキシサーバの IP アドレスとポート番号を指定します。

$serviceKey = "HKLM:\SYSTEM\CurrentControlSet\Services\AmazonSSMAgent"
$keyInfo = (Get-Item -Path $serviceKey).GetValue("Environment")
$proxyVariables = @("http_proxy=192.168.0.200:3128", "no_proxy=169.254.169.254")

If($keyInfo -eq $null)
{
New-ItemProperty -Path $serviceKey -Name Environment -Value $proxyVariables -PropertyType MultiString -Force
} else {
Set-ItemProperty -Path $serviceKey -Name Environment -Value $proxyVariables
}
Restart-Service AmazonSSMAgent

しばらくすると、 マネージドインスタンスに登録されました!

Windows ではログ上でも設定状況を確認することが可能です。

2020-09-01 03:03:08 INFO Windows Only: Job object creation on SSM agent successful
2020-09-01 03:03:08 INFO Getting IE proxy configuration for current user: The operation completed successfully.
2020-09-01 03:03:08 INFO Getting WinHTTP proxy default configuration: The operation completed successfully.
2020-09-01 03:03:08 INFO Proxy environment variables:
2020-09-01 03:03:08 INFO http_proxy: 192.168.0.200:3128
2020-09-01 03:03:08 INFO https_proxy: 
2020-09-01 03:03:08 INFO no_proxy: 169.254.169.254
2020-09-01 03:03:08 INFO Create new startup processor

注意点

実際に本番導入させるには、構成の詳細な検討事項はあるかと思いますが、プロキシサーバがあれば比較的簡単に プロキシを経由した環境を準備することが可能です。ただし、それぞれの OS で注意事項や SSM の各機能を利用するために一手間かけてあげる必要があります。

また Windows では多様なプロキシ利用方法があるため,その点にも注意が必要です。

SSMエージェントプロキシ設定の優先順位

この辺りは弊社のメンバーが紹介してくれている記事がありますので、あわせてご確認ください。

個人的には 要件が許されるなら Nat や VPC エンドポイントを活用する構成を推奨いたします。。

さいごに

SSM を利用したいと検討されている方が少しずつ増えている印象を受けます。 はじめの障壁として現れるのがマネージドインスタンスとして登録できない事象です。ここでトラブルが発生すると導入担当者のモチベーションも落ちるのではないかと思います。(少なくとも私なら...)

また、より具体的なシーンを想定した記事も弊社メンバーが先日記事にしてくれていたので、是非お困りの際はご活用ください。