8月 2020年

今回は「Session Manager (SSM) を使って EC2 へアクセスする方法 （privateサブネットでパブリックIPを持たないEC2へアクセスする方法）」についてまとめます。

概要

Systems Manager にある Session Manager を利用して EC2 へアクセスするための準備から接続方法についてまとめてみます。

Session Manager を使ってEC2へアクセスできるようになると、これまで 22ポート (SSH) を開放していたものが解放しなくてよくなります。 また、実質的な踏み台サーバーを AWS が提供していることになるので、踏み台も準備不要になってちょっと便利になります。

今回まとめとして取り上げるのは以下のような「プライベートサブネットにたてたパブリックIPを持たないEC2に対してアクセスするようなケース」で見ていきます。 EC2にはパブリックIPが付与されずプライベートIPのみとなります。 そのままではアクセスできないのでVPCエンドポイント（VPCピアリング）を付けて、AWS内の経路でアクセスしていきます。

サーバー準備

VPC

SSMを利用しようとすると、VPCのDNS解決が有効でないとアクセスできません。 またプライベートサブネットでアクセスするために設定するVPCエンドポイントでDNSを有効にしようとすると「DNSホスト名」も「有効」にしておく必要があります。 「DNSホスト名」も「有効」である必要がある点はパブリックな場合と異なる点です。

VPC

DNS解決	有効
DNSホスト名	有効

サブネット

ルートテーブル	外界とつながらないので特に指定なし

VPCエンドポイント

サービス名	エンドポイント準備が必要なのは以下3種類 com.amazonaws.ap-northeast-1.ssm com.amazonaws.ap-northeast-1.ec2messages com.amazonaws.ap-northeast-1.ssmmessages
サブネット	（接続したいEC2があるプライベートサブネットを指定）
プライベートDNS名	有効
セキュリティグループ	HTTPS(443)のEC2からのインバウンドを許可

Systems Manager

初期化がまだであれば「高速セットアップ」から初期化を行います。 一度初期化を行っていたとしても、「高速セットアップ」はダッシュボードとして状況が見えるので再設定する際もこちらから行うと便利です。

基本的にはデフォルトのままでOKですが、Configuration Options に関してはチェックなしでも問題ありません。 Targetsに関してはさすがに「Choose all instances in the current AWS account and Region」か「Specify instance tags」でないとEC2が増減したとき毎回対応になって面倒になります。

高速セットアップ

Permissions	Instance profile role Use the default role を選択。 Use the default role を選択すると AmazonSSMRoleForInstancesQuickSetup ロールが作成されます。 独自のロールを指定したい場合 Choose an existing role を選択しますが、 AmazonSSMManagedInstanceCore ポリシーを含んでいる必要があります。 Assume role for Systems Manager こちらは関係ないので Use the default role (AmazonSSMRoleForAutomationAssumeQuickSetup) を指定しておきます。
Configuration options	内容は定期的なシステムチェックをするかどうか、なので全部チェックを外しても問題ありません。 更新や状況を確認したいものがあればチェックを入れておきます。
Targets	内容は定期的なシステムチェックをするかどうか、なので全部チェックを外しても問題ありません。 更新や状況を確認したいものがあればチェックを入れておきます。

IAM

EC2に設定が必要なアクセス権は AmazonSSMManagedInstanceCore ポリシーになります。 AWS EC2 向けロールに対してあらかじめ追加しておきます。

Sysmtes Manager で初期設定している場合、 AmazonSSMRoleForInstanceQuickSetup ロールが追加されています。 このロールにはあらかじめ AmazonSSMManagedInstanceCore が追加されているので、このロールを活用してもOKです。

ロール

ロール名	AmazonSSMRoleForInstancesQuickSetup
信頼されたエンティティ	AWS サービス：ec2
アクセス権	AmazonSSMManagedInstanceCore

Security Group

「EC2に付与するもの」と「VPCエンドポイントに付与するもの」の2種類が必要になります。

EC2に付与するセキュリティグループ

EC2に付与するセキュリティグループは「VPCエンドポイント」に向かって「アウトバウンドHTTPS(443)」が通信許可されていることです。

• インバウンドルール

  （なし）

• アウトバウンドルール

  タイプ	プロトコル	ポート範囲	送信先
  HTTPS	TCP	443	(VPCエンドポイント向けのセキュリティグループ)

VPCエンドポイントに付与するセキュリティグループ

VPCエンドポイントには逆にEC2からHTTPSが入ってくるので「インバウンド HTTPS 」を許可します。

• インバウンドルール

  タイプ	プロトコル	ポート範囲	ソース
  HTTPS	TCP	443	(EC2向けのセキュリティグループ)

• アウトバウンドルール

  （なし）

EC2

Amazon Linux を使わない場合、独自に Session Manager Plugin をインストールする必要があります。 Amazon Linux は最初から入っているので特に気にする必要はありません。 今回は Amazon Linux 前提で進めていきます。

必要なセキュリティグループ、IAMロールは準備できているので、 EC2作成時には以下のような設定を行っていきます。

Step3: インスタンスの詳細の設定

ネットワーク	（作成したVPCを設定します。このVPCは「DNS解決が有効」である必要があります。）
サブネット	（作成した privateサブネット を指定します。 このサブネットは VPCエンドポイント 経由でAWSのSSMと通信できる必要があります）
自動割り当てパブリックIP	無効
IAMロール	AmazonSSMManagedInstanceCore ポリシーを含むロールを指定します。 Systems Manager の高速セットアップをデフォルト設定で利用した場合 AmazonSSMRoleForInstancesQuickSetup ロールになります。

Step6: セキュリティグループの設定

セキュリティグループ	HTTPS(443) でVPCエンドポイントへ通信できるようにしておきます。

接続確認

接続方法もいくつかありますが、今回は単純にマネジメントコンソールから接続する方法を見ておきます。 他の方法については別途記事を書こうと思います…。

Session Manager から接続

今回はSystemsManagerのセッションマネージャーから接続してみます。 もちろん、EC2のページから接続することもできます。 この方法で接続すると ssm-user をいうユーザーで接続します。

1. 「Systems Manager」へ遷移

2. 左メニューから「Session Manager」を開く

3. 「セッションの開始」を選択

4. 接続したいインスタンスを選択して「セッションを開始する」を選択

今回は「SSM を使って EC2 へアクセスする方法 （privateサブネットの場合）」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

今回は「Session Manager (SSM) を使って EC2 へアクセスする方法 （publicサブネットの場合）」についてまとめます。

この Session Manager を使ってEC2へアクセスできるようになると、これまで 22ポート (SSH) を開放していたものが解放しなくてよくなります。 また、実質的な踏み台サーバーを AWS が提供していることになるので、踏み台も準備不要になってちょっと便利になります。

概要

Systems Manager にある Session Manager (SSM) を利用して EC2 へアクセスするための準備から接続方法についてまとめてみます。

さて、今回まとめとして取り上げるのは以下のような「EC2にパブリックIPを付与する環境構成に対してアクセスするケース」で見ていきます。 EC2にパブリックIPが付与されているので、外回りでEC2へアクセスするようなケースになります。

サーバー準備

VPC

SSMを利用しようとすると、VPCのDNS解決が有効でないとアクセスできません。 デフォルトで有効になるはずですが…作成する際は「DNS解決」が「有効」であることを確認してください。

パブリックIPを利用してSSMによるEC2アクセスを行おうとすると、VPCには Internet Gateway が設定されており、 Internet Gateway へのルーティングが設定されている必要もあります。 Internet Gateway とそこへのルーティングがないと外との通信はできません。

VPC

DNS解決	有効

サブネット

ルートテーブル	以下の設定が入っていること 送信先： 0.0.0.0/0 ターゲット：（作成したインターネットゲートウェイ）

インターネットゲートウェイ

状態	Attached。新規作成して、作成済VPCにアタッチされていること

Systems Manager

初期化がまだであれば「高速セットアップ」から初期化を行います。 一度初期化を行っていたとしても、「高速セットアップ」はダッシュボードとして状況が見えるので再設定する際もこちらから行うと便利です。

基本的にはデフォルトのままでOKですが、Configuration Options に関してはチェックなしでも問題ありません。 Targetsに関してはさすがに「Choose all instances in the current AWS account and Region」か「Specify instance tags」でないとEC2が増減したとき毎回対応になって面倒になります。

高速セットアップ

Permissions	Instance profile role Use the default role を選択。 Use the default role を選択すると AmazonSSMRoleForInstancesQuickSetup ロールが作成されます。 独自のロールを指定したい場合 Choose an existing role を選択しますが、 AmazonSSMManagedInstanceCore ポリシーを含んでいる必要があります。 Assume role for Systems Manager こちらは関係ないので Use the default role (AmazonSSMRoleForAutomationAssumeQuickSetup) を指定しておきます。
Configuration options	内容は定期的なシステムチェックをするかどうか、なので全部チェックを外しても問題ありません。 更新や状況を確認したいものがあればチェックを入れておきます。
Targets	内容は定期的なシステムチェックをするかどうか、なので全部チェックを外しても問題ありません。 更新や状況を確認したいものがあればチェックを入れておきます。

IAM

EC2に設定が必要なアクセス権は AmazonSSMManagedInstanceCore ポリシーになります。 AWS EC2 向けロールに対してあらかじめ追加しておきます。

Sysmtes Manager で初期設定している場合、 AmazonSSMRoleForInstanceQuickSetup ロールが追加されています。 このロールにはあらかじめ AmazonSSMManagedInstanceCore が追加されているので、このロールを活用してもOKです。

ロール

ロール名	AmazonSSMRoleForInstancesQuickSetup
信頼されたエンティティ	AWS サービス：ec2
アクセス権	AmazonSSMManagedInstanceCore

Security Group

EC2に付与するセキュリティグループにはHTTPSで外へ出られる設定をしておく必要があります。 あらかじめ「アウトバウンド433（HTTPS）で送信先 0.0.0.0/0 」設定があるセキュリティグループを準備しておきます。

アウトバウンドルール

タイプ	プロトコル	ポート範囲	送信先
HTTPS	TCP	443	0.0.0.0/0

EC2

Amazon Linux を使わない場合、独自に Session Manager Plugin をインストールする必要があります。 Amazon Linux は最初から入っているので特に気にする必要はありません。 今回は Amazon Linux 前提で進めていきます。

とはいえ、すでに必要な準備は終わっているはずなので、あとは組み合わせてEC2を起動するだけです。 EC2作成時には以下のような設定を行います。

Step3: インスタンスの詳細の設定

ネットワーク	（作成したVPCを設定します。このVPCは「DNS解決が有効」である必要があります。）
サブネット	（作成した publicサブネット を指定します。 このサブネットは Internet Gateway 経由で外へアクセスできる必要があります）
自動割り当てパブリックIP	有効
IAMロール	AmazonSSMManagedInstanceCore ポリシーを含むロールを指定します。 Systems Manager の高速セットアップをデフォルト設定で利用した場合 AmazonSSMRoleForInstancesQuickSetup ロールになります。

Step6: セキュリティグループの設定

セキュリティグループ	https(443) が外へ出られるようにしておきます。

接続確認

接続方法もいくつかありますが、今回は単純にマネジメントコンソールから接続する方法を見ておきます。 他の方法については別途記事を書こうと思います…。

EC2のマネジメントコンソールから接続

SystemsManagerのセッションマネージャーからも接続できますが…今回はEC2のページから接続する方法を見ていきます。 この方法で接続すると ssm-user をいうユーザーで接続します。

1. 「EC2」へ遷移

2. 「インスタンス」を開く

3. 接続したいインスタンスを選択

4. 「接続」を選択

5. 「セッションマネージャー」を選択して、「接続」を押下

今回は「SSM を使って EC2 へアクセスする方法 （publicサブネットの場合）」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

今回は「AWS EC2起動時に パラメータストアの値 を 環境変数 に 設定する 方法」についてまとめます。

起動時にパラメータストアから値とってきて環境変数に設定なんてよく聞きますが…調べても自分が欲しい情報がストレートになかったので、今回まとめてみました。

概要

EC2起動時にパラメータストアの値を取りに行き、EC2の環境変数へマッピングしていくような仕組みを作っていきます（以下の図のイメージ）。 今回は「VPC」や「EC2」につけられたタグ名をキーに「パラメータストア」の値を探してくるようなものを作ります。

「VPC」のタグには「Project」「Env」を、「EC2」のタグには「Type」を定義しておきます。 これらタグを利用して、「パラメータストア」では「/{Project}/{Env}/{Type}/*」の環境変数を取得、設定するような仕組みです。

パラメータストア

今回は以下のようなパラメータを用意するものとします。

名前	種類
/sample-project/stg/app/MYSQL_HOST	String
/sample-project/stg/app/MYSQL_PORT	String
/sample-project/stg/app/MYSQL_DATABASE	String
/sample-project/stg/app/MYSQL_USERNAME	String
/sample-project/stg/app/MYSQL_PASSWORD	SecureString

"/"(バックスラッシュ) で分類するとよいようなので、この方法を採用しました。 今回は以下のような階層構造を前提として設計しています。

/{VPCのProjectタグ}/{VPCのEnvタグ}/{EC2のTypeタグ}/{環境変数名}

それぞれ以下のような想定で階層をきっています。

VPCのProjectタグ

プロジェクト名を想定。

VPCのEnvタグ

リリース環境を想定。dev, stg, prod など。

EC2のTypeタグ

サーバー種別を想定。web, app, batch, db など。

これを元にパスを書き直すと以下のようになります。

/{プロジェクト名}/{リリース環境名}/{サーバー種別}/{環境変数名}

VPC

タグ

おそらくVPCの名前には「プロジェクト名+環境」で設定することが多い気がします。 今回はそれを分解して以下2つのタグを設定しておきます。

Project

プロジェクト名。今回の例だと sample-project 。 パラメータストアにおける第1階層。

Env

リリース環境。dev, stg, prod など。 パラメータストアにおける第2階層。

EC2

EC2は「Amazon Linux」前提で記載しています。 今回設定するのは以下3か所です。

• どのパラメータストアを取り出すか指定するためのタグ
• パラメータストアなどにアクセスするための権限設定
• 起動時にパラメータストアから値をとってきて環境変数に設定するスクリプト（ユーザーデータ）

タグ

EC2は個別サーバーになります。 実際はいくつかの種類に応じて分類されると思いますので、今回は「サーバー種別」として「Type」を設定しておきこれを取得するようなサンプルにしました。

Type

サーバー種別。web, app, batch, db など。 パラメータストアにおける第3階層。

IAMロール

ユーザーデータで実行するスクリプトでは以下の機能を利用します。 以下の機能が利用可能なポリシーをロールに与え、そのロールをEC2に与えておきます。

• ec2:DescribeInstances
• ec2:DescribeVpcs
• ssm:GetParametersByPath

個別に組み込んでも良いのですが、とりあえず使うのであれば以下の組み込みポリシーが使えそうでした。

• AmazonEC2ReadOnlyAccess
• AmazonSSMReadOnlyAccess

パラメータストアから情報を取ってくる際、環境ごとにアクセスできるかどうか制御したい場合、個別ポリシーとして以下のような設定を行うとさらに制限ができます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:GetParametersByPath"
      ],
      "Resource": "arn:aws:ssm:{region}:{account-id}:parameter/{project}/{env}/{type}/*"
    }
  ]
}

ユーザーデータ

お待たせしました…今回のメインのスクリプトです。 作成時に「ユーザーデータ」として以下のシェルスクリプトを「ファイルとして」選択、登録します。

user_data.sh

#!/bin/bash

#
# Install required modules.
#
curl -o /usr/local/bin/jq -L https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64
chmod +x /usr/local/bin/jq

#
# Initialize environment variables
#
INITENV_SHELL="/etc/rc.d/initenv.sh"
SETENV_SHELL="/etc/profile.d/setenv.sh"

# Create initenv.sh
# initialize environment variable script -START-----------------------
cat >> "$INITENV_SHELL" <<"__EOS__"
#!/bin/bash

# Environment variables file name
SETENV_SHELL="/etc/profile.d/setenv.sh"

# Load environmental variables
INSTANCE_ID=$(curl 169.254.169.254/latest/meta-data/instance-id)
REGION=$(curl 169.254.169.254/latest/meta-data/placement/region)
ZONE=$(curl 169.254.169.254/latest/meta-data/placement/availability-zone)

VPC_ID=$(aws ec2 describe-instances --region ${REGION} --instance-ids ${INSTANCE_ID} --query "Reservations[0].Instances[0].NetworkInterfaces[0].VpcId" --output text)
VPC_NAME=$(aws ec2 describe-vpcs --region ${REGION} --vpc-ids ${VPC_ID} --query "Vpcs[0].Tags[?Key=='Name'].Value" --output text)
VPC_PROJECT=$(aws ec2 describe-vpcs --region ${REGION} --vpc-ids ${VPC_ID} --query "Vpcs[0].Tags[?Key=='Project'].Value" --output text)
VPC_ENV=$(aws ec2 describe-vpcs --region ${REGION} --vpc-ids ${VPC_ID} --query "Vpcs[0].Tags[?Key=='Env'].Value" --output text)

EC2_NAME=$(aws ec2 describe-instances --region ${REGION} --instance-ids ${INSTANCE_ID} --query "Reservations[0].Instances[0].Tags[?Key=='Name'].Value" --output text)
EC2_TYPE=$(aws ec2 describe-instances --region ${REGION} --instance-ids ${INSTANCE_ID} --query "Reservations[0].Instances[0].Tags[?Key=='Type'].Value" --output text)

SSM_PARAMETER_STORE=$(aws ssm get-parameters-by-path --region ${REGION} --path "/${VPC_PROJECT}/${VPC_ENV}/${EC2_TYPE}" --with-decryption)

# Output environment initialize scripts.
cat > "${SETENV_SHELL}" <<EOF
#
# [$(date '+%Y-%m-%dT%H:%M:%S+09:00' -d '9 hour')] Initialized scripts.
#
export INSTANCE_ID=${INSTANCE_ID}
export REGION=${REGION}
export ZONE=${ZONE}
export VPC_ID=${VPC_ID}
export VPC_NAME="${VPC_NAME}"
export VPC_PROJECT="${VPC_PROJECT}"
export VPC_ENV="${VPC_ENV}"
export EC2_NAME="${EC2_NAME}"
export EC2_TYPE="${EC2_TYPE}"
EOF

for PARAMS in $(echo ${SSM_PARAMETER_STORE} | /usr/local/bin/jq -r '.Parameters[] | .Name + "=" + .Value'); do
  echo "export ${PARAMS##*/}"
done >> "${SETENV_SHELL}"

chmod +x "$SETENV_SHELL"
source "$SETENV_SHELL"
__EOS__
# initialize environment variable script -END-------------------------

# Modify initenv.sh access control.
chmod +x "$INITENV_SHELL"

# Add startup service
cat > "/etc/systemd/system/initenv.service" <<EOF
[Unit]
Description=Initialize environment variables.
After=network.target

[Service]
Type=oneshot
User=root
Group=root
ExecStart="$INITENV_SHELL"

[Install]
WantedBy=default.target
EOF
systemctl daemon-reload
systemctl enable initenv

# Load environment variables.
bash "$INITENV_SHELL"
source "$SETENV_SHELL"

大まかには「initenv.sh で AWS から必要な環境変数を取得して setenv.sh を作成、作成された setenv.sh を読み込むことで環境変数に埋め込みを行う」という仕組みになっています。 initenv.sh は サービス 登録しておくことで再起動した際、読み込みなおすような仕組みになっています。

今回は「AWS EC2起動時に パラメータストアの値 を 環境変数 に 設定する 方法」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

参考記事

• Qiita - パラメータストアからEC2に環境変数を設定する
• aws - IAM ポリシーを使用して Systems Manager パラメータへのアクセスを制限する
• aws - インスタンスメタデータの取得
• Qiita - Systemd メモ書き
• 学生たちの技術ブログ - Systemdで起動時にスクリプトを実行する