話題の記事

Amazon Linux 2 のインスタンスを作成する時に必ずやっておきたい事

2020.07.07

はじめに

こんばんは、菅野です。 Amazon Linux 2 への移行は終わりましたか? Amazon Linux 2 へ移行するには新しいインスタンスを作成する必要がありますが、その時におすすめしたい設定があります。

※2020-07-08に「注意点 その2」を追記しました。

おすすめの設定

  • セッションマネージャーを利用できるようにすること
  • メモリ使用率とディスク使用率を CloudWatch で見れるようにすること

これらを設定しておくと、今後の運用が楽になります。

セッションマネージャーを使うメリット

メリットとしては、SSH 接続をしなくても EC2 のコマンドが実行できるようになりますので、セキュリティグループで SSH を解放する必要が無くなりセキュリティの向上につながります。

この画像はマネジメントコンソールから EC2 にログインした時のものですが、AWS Systems Manager のセッションマネージャーページで「セッションの開始」ボタンをクリックして EC2 インスタンスを選ぶだけです。

また、マネジメントコンソールだけじゃなく、クライアント PC からログインする方法もあります。 設定方法はこちらをご覧ください AWS Systems Manager セッションマネージャーでSSH・SCPできるようになりました | Developers.IO

接続した結果はご覧の通り、普通に SSH で接続した時と全く変わりません。

$ ssh -i /Users/sugano.masataka/pems/sugano-test.pem ec2-user@i-021bcb409cd96f76c
Warning: Permanently added 'i-021bcb409cd96f76c' (ECDSA) to the list of known hosts.

__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|

https://aws.amazon.com/amazon-linux-2/
9 package(s) needed for security, out of 16 available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-172-31-253-106 ~]$ curl http://169.254.169.254/latest/meta-data/instance-id
i-021bcb409cd96f76c

カスタムメトリクスを設定する意味

こちらの設定はメリットというよりも、運用する上で EC2 のメモリ使用率とディスク使用率の状態を収集しておくことでサービス障害の前触れをキャッチしたり、障害発生時の調査に役立ちます。 この設定は障害に気づいた後で設定しても遅いので、常に CloudWatch に情報を蓄えておきましょう。

設定(1/2) - EC2 用ロールの用意

EC2 には SSM とやり取りするための許可と、CloudWatch へメトリクスを送信するための許可が必要になります。 EC2 へアタッチする Role には以下の IAM ポリシーを含めておいてください。

  • CloudWatchAgentServerPolicy
  • AmazonSSMManagedInstanceCore

設定(2/2) - ユーザーデータを使う

Amazon Linux 2 は標準で SSM エージェントがインストールされていますが、カスタムメトリクスを送信する設定は自分で行う必要があります。

そのカスタムメトリクスを送信する設定が意外と面倒なのと、SSM エージェントのアップデートもついでに行いたいので、それらを簡単に行うためにユーザーデータを用意しました。これなら EC2 インスタンスを作成する時にテキストを1回貼り付けるだけで設定が完了します。

#!/bin/sh -ex
yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
yum install -y perl-Switch perl-DateTime perl-Sys-Syslog perl-LWP-Protocol-https perl-Digest-SHA.x86_64
cd /opt
curl https://aws-cloudwatch.s3.amazonaws.com/downloads/CloudWatchMonitoringScripts-1.2.2.zip -O
unzip /opt/CloudWatchMonitoringScripts-1.2.2.zip
rm -rf /opt/CloudWatchMonitoringScripts-1.2.2.zip
echo "*/5 * * * * root /opt/aws-scripts-mon/mon-put-instance-data.pl --mem-util --disk-space-util --disk-path=/" >> /etc/crontab

ユーザーデータの内容は以下となります。

  • SSM エージェントのアップデート
  • カスタムメトリクス送信に必要な Perl モジュールのインストール
  • 送信スクリプトを /opt にインストール
  • cron で5分に1回コマンドを実行して自動送信するように設定

注意点

SSM エージェントをインストールしているコマンドは CPU 毎に異なります。 ARM (arm64) 64 ビットインスタンスの場合は以下のコマンドへ変更してください。

yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_arm64/amazon-ssm-agent.rpm

注意点 その2(2020-07-08追記)

今回 CloudWatch への情報送信に使ったのは「CloudWatch モニタリングスクリプト」なのですが、こちらは今後サポートされません。
Amazon EC2 Linux インスタンスのメモリとディスクのメトリクスのモニタリング - Amazon Elastic Compute Cloud

現在 AWS が推奨しているのは「CloudWatch エージェント」を利用した方法となります。
CloudWatch エージェントを使用して Amazon EC2 インスタンスとオンプレミスサーバーからメトリクスとログを収集する - Amazon CloudWatch

今後「CloudWatch モニタリングスクリプト」が使えなくなった時には、スクリプトを自分で修正して使い続けるか、「CloudWatch エージェント」へ切り替えるかを検討し対応する必要があります。

最後に

いかがでしたでしょうか。 セッションマネージャーを使えば SSH ポートを外部に公開が不要になってセキュリティが向上するだけじゃなく、現在踏み台サーバーを利用しているのならそれが不要になるので利用料金も下げる事が可能です。

また、メモリ使用率は障害調査においてかなり重要な情報です。日頃から情報を収集しておくことで異常を見つけやすくなりますし、EC2 のスケールアップの際の指標にもなります。

今回用意したユーザーデータを使えばお手軽に設定できますので、今後作成する全ての EC2 インスタンスへの設定をご検討ください。

参考ページ

以下のページを参考にさせていただきました。ありがとうございました。