プライベートサブネットのWindows Server 2016インスタンスからCloudWatchにカスタムメトリクスを送る方法
まいど、大阪の市田です。
今回はインターネットに直接アクセスできないWindows Serverからカスタムメトリクスを送る方法をご紹介します。
構成
想定する構成は下記のようになります。
構成図にあるように、パブリックサブネットにあるproxyサーバをフォワードプロキシとして、カスタムメトリクスを送ります。
また、プライベートサブネットにあるインスタンスは、デフォルトゲートウェイがVPN側(VGW)に向いているものとします。今回はこのプライベートサブネットにあるインスタンスのカスタムメトリクスを送ってみたいと思います。
補足
社内向けシステムとして利用する場合、このように直接インターネットには接続しない形で利用されることもあるかと思いますが、WindowsUpdateや時刻同期は、オンプレミス側のWSUSサーバやNTPサーバで行う形を想定しています。
その為、オンプレ側のルータ設定などの変更は行わずに、AWS側だけで対処する場合というのが今回の想定です。
概要
作業の概要は以下の通りです。既にVPCの設定やプライベートサブネットのインスタンスは作成済みとします。プライベートサブネットのインスタンスはAmazon Linuxにしています。
- パブリックサブネットにsquidサーバを作成
- カスタムメトリクスの送信設定
尚、プライベートサブネットのインスタンスは下記AMIの「Windows Server 2016」としています。
- Windows_Server-2016-Japanese-Full-Base-2017.05.10 (ami-a2f1cdc5)
やってみる
それでは実際の作業を見ていきます。
squidサーバの作成
パブリックサブネットにAmazon LinuxでEC2インスタンスを作成します。
インスタンスが作成できたらElastic IPを付けておきます。
次に、squidをインストールします。
$ sudo yum -y install squid $ sudo chkconfig squid on
今回は同じVPC(192.168.0.0/16)内からのみアクセスを許可するようにしました。
# # Recommended minimum configuration: # acl manager proto cache_object acl localhost src 127.0.0.1/32 ::1 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1 # Example rule allowing access from your local networks. # Adapt to list your (internal) IP networks from where browsing # should be allowed acl myvpc src 192.168.0.0/16 # VPC vpc-xxxxxxxx CIDR (中略) # # Recommended minimum Access Permission configuration: # # Only allow cachemgr access from localhost http_access allow myvpc (以下略)
設定が完了したらsquidを起動します。
$ sudo service squid start
後、squidサーバのセキュリティグループにて、プライベートサブネットからのアクセス許可を忘れないようにしましょう。(デフォルトでTCP 3128ポートです。)
カスタムメトリクスの送信設定
Windows Server 2016の場合は、SSM(Amazon EC2 Systems Manager)エージェントを利用してメトリクスを送ります。これはプライベートでもパブリックでもどちらのサブネットの場合でも同じです。
カスタムメトリクスの送信についてですが、今回は簡単に設定する為に、Run Commandを利用して設定しています。その為、一時的にインターネットにアクセスできるようにVPCの設定を変更しています。
尚、本番稼働しているシステムの場合は、ルーティングが一時的に変更になるので、メンテナンス時間などを設けて実施するようにして下さい。
変更内容
- Elasitc IPの付与
- 対象インスタンスのあるプライベートサブネットのルーティングの修正
- デフォルトゲートウェイをバーチャルプライベートゲートウェイからインターネットゲートウェイへ変更
Elastic IPの付与
ルートテーブルの変更
この状態で、プライベートサブネットのインスタンスに対して、下記の手順を実行しています。
設定ができたらVPCの設定を元に戻します。
修正内容
- Elasit IPの削除
- 対象インスタンスのあるプライベートサブネットのルーティングの修正
- デフォルトゲートウェイをインターネットゲートウェイからバーチャルプライベートゲートウェイへ変更
Elastic IPの削除
ルートテーブルの修正
プロキシ経由で送信する設定
次に、プロキシ経由でメトリクスを送る設定を行います。
既に対象のインスタンスは、プライベートサブネットに閉じていますので、踏み台サーバ経由か、VPN経由などで対象のサーバにRDPログインします。
対象サーバのセキュリティグループにて、RDP接続の許可ポリシーを入れておくことを忘れないようにしましょう。
SSMエージェントがプロキシを利用するためには、下記のドキュメントにあるコマンドをPowerShellで実行します。
PowerShellは管理者として起動します。
SSM エージェントのインストール - Amazon EC2 Systems Manager
http_proxy=hostname:port
の部分は、プロキシサーバのプライベートIPを指定します。ポートはsquidのポートです。
> $serviceKey = "HKLM:\SYSTEM\CurrentControlSet\Services\AmazonSSMAgent" > $proxyVariables = @("http_proxy=hostname:port", "no_proxy=169.254.169.254") > New-ItemProperty -Path $serviceKey -Name Environment -Value $proxyVariables -PropertyType MultiString > Restart-Service AmazonSSMAgent
私が試した環境では、3つ目のNew-ItemProperty
コマンドレットを実行した時にエラーとなりました。
その為、下記でプロキシ設定を一旦リセットしてから、やり直しを行いました。もし同様のエラーが発生した場合は、一度リセットしてみてから再度お試しください。
> Remove-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\AmazonSSMAgent -Name Environment > Restart-Service AmazonSSMAgent
再度実行して正常に完了すると、下記のように新しいレジストリエントリを作成できた結果が表示されます。
最後に、SSMエージェントを再起動して完了です。
これで、プロキシサーバ経由でCloudWatch側にカスタムメトリクスが送ることが出来ました。
実際にsquidにも下記のようなログが出ていることを確認できました。(192.168.4.98はWindows ServerのIPアドレスです。)
1495708622.726 20000 192.168.4.98 TCP_MISS/200 3431 CONNECT ec2messages.ap-northeast-1.amazonaws.com:443 - DIRECT/54.xx.xx.xx - 1495708642.727 20000 192.168.4.98 TCP_MISS/200 3431 CONNECT ec2messages.ap-northeast-1.amazonaws.com:443 - DIRECT/54.xx.xx.xx -
また、試しにWindows ServerをStop/Startしても問題なく送信できることも確認出来ました。
最後に
今回のような閉じたネットワークにあるWindows Serverに対して、カスタムメトリクスを取りたいと言うニーズはあるのかなと感じます。
この記事がお役に立てれば幸いです。
以上です。