いちはじCDK第１４回　EC2 SSM編

Contents

やってみましょうSSM
アーキテクト図
パブリックIP接続と違う所
やってみたら・・・
VPC
VPCエンドポイント
EC2インスタンス
デプロイと出来たもの確認
- まずはVPCエンドポイント
- EC2インスタンス
接続してみる～AWSコンソール編～
接続してみる～IAM Identity Center経由編～
最後に～

やってみましょうSSM

お金がかかるとは言え、やってみましょうSSMです！
VPCエンドポイントを作りっぱなしにしないことに注意です！知らない間に毎月5000円程度の出費をすることになりますので・・・使い終わったら壊す！忘れないように～

アーキテクト図

さて、アーキテクト図を描いてみようを思ったら・・・ん？良くわからんなぁ？って思いました。
ネット上を探ってみた感じでは、以下のサイトで書いてあるものが参考になるのかと・・・
「どうしても語りたい AWS Systems Manager の魅力 ! ~ 第 2 回こんなに簡単にサーバー接続できるなんて !」
(´・ω・)長いな・・・最近のラノベ並みのネーミングだな
参考にして書いたのが以下の絵

今回は、少し大きく書いてみました！っていうのとフォントを変えてみました。
SSM接続するときは、AWSコンソールからのEC２→SSM接続って感じで接続することが多いです。
その他には、IAM Identity Center経由で接続する方法があるかと思います。この他にも方法があるかもしれないですが、私が良く使うのは上記の２つです。
間違っている部分があったらごめんなさい。

パブリックIP接続と違う所

上記のアーキテクト図がパブリックIP編と違うところですけど、まず、publicサブネットが書いてないです。あと、Internet Gatewayがないですね。
SSM接続では共に不要で、いきなりprivateサブネットに接続するわけです。
いきなりっていっても間に、Session Managerが入って中継してくれる感じです。

SSMを使うにあたっては、いくつか前提条件があります。
詳しくは以下のサイトに記載があります。
「ステップ 1: Session Manager の前提条件を満たす」
細かいところは、上記サイト見てもらうとして、ザックリ比較しておきます。

項目	パブリックIP接続	SSM接続
セキュリティグループ	インバウンドルールでいずれかのポートの許可が必要(80/22/443等)	インバウンドルールは不要。アウトバンドルールで443ポート許可必要
IAMロール	なし	AmazonSSMManagedInstanceCore
キーペア	必要	不要
インターネットゲートウェイ	必要	不要
VPCエンドポイント	不要	必要
ネットワークインタフェース	必要	不要

privateサブネットでも接続可能なSSMは不要な部分が多く、セキュリティレベルが高いと感じます。
SSM接続のデメリットはVPCエンドポイントが必要ってことですかね。ただ、何かしら接続するための仕組みが必要なので、VPCエンドポイントが必要という事実は否定できないんですけど、料金が常時発生する仕組みが良くないですね。
できれば使ってない時に無効にできるような料金体系に改善してもらえると嬉しい限りです。

やってみたら・・・

さて、ここまで書いたところで一旦色々試してみたんですが、まぁ上手く行かない！と言う訳で色々ネット上で調べてたら、以下のページにたどり着きました。
「VPCエンドポイント経由でのSSMを用いたEC2への接続を図で整理する」
解りやすいです。是非このページを参考にしたら良いかと思います。

私は何が上手くできてなかったのか？と言うとVPCエンドポイント側のインバウンドルールで443ポートを許可していなかったのが原因でした。

AWSの公式サイトだとそこんとこハッキリ書いてない気がするんですけどね・・・（解りやすく書いてよ！って常々思います。）
愚痴的な意味も込めて本家AWS公式サイトの書き方だとこうです。（あえて原文のまま画像で！）

ここにはインバウンドという文字は一言も書いてないんです。
ただ、

AWS re:Post ナレッジセンターの「Systems Manager を使用してインターネットアクセスなしでプライベート EC2 インスタンスを管理できるように、VPC エンドポイントを作成するにはどうすればよいですか?」。

この部分…英語ですが、ここに書いてあるよう…
(´・ω・)え？ここに！

Create or modify a security group
Create one security group, or modify an existing security group for the inbound and outbound rules. The security group must allow outbound traffic on port 443 to the VPC endpoints. The security group must also allow inbound HTTPS (port 443) traffic from the resources in your VPC that communicate with the service. For the Inbound rules, choose HTTPS for type. For Source, select your VPC’s CIDR block. For an advanced configuration, allow the CIDR block for specific subnets in the VPC or a security group that your instances use.

インバウンドルールとアウトバウンドルールのセキュリティグループを1つ作成するか、既存のセキュリティグループを変更します。

セキュリティグループは、VPCエンドポイントへのポート443でのアウトバウンドトラフィックを許可する必要があります。

また、サービスと通信するVPC内のリソースからのインバウンドHTTPS（ポート443）トラフィックも許可する必要があります。

インバウンドルールのタイプにはHTTPSを選択します。ソースには、VPCのCIDRブロックを選択します。

高度な設定を行うには、VPC内の特定のサブネット、またはインスタンスが使用するセキュリティグループのCIDRブロックを許可します。

この翻訳した内容を見る限り、「どこの」が解り難いです！誰に対して設定したら良いのかわかりやすく書いて欲しい！（単なる愚痴です！）

VPC

VPCは過去に作ったものを使い廻します。今回は「いちはじCDK第９回　API GateWay②」で作ったインターネットゲートウェイが無いバージョン（pworkvpc）を使います。
説明は割愛します。

VPCエンドポイント

上記AWS公式サイトに書いてある必要なVPCエンドポイントを改めて記載します。
・ec2messages.region.amazonaws.com
・ssm.region.amazonaws.com
・ssmmessages.region.amazonaws.com※EC2のベースOSによっては不要
でも@takeITeasy7さんのサイトには、EC2インスタンスがAmazonLinuxの最近のバージョンであれば、「ec2messages.region.amazonaws.com」は不要と書いてありました！
助かりますね。VPCエンドポイントは１つ月1500円はかかるので、1500円削減できます。

ポイントを整理するために、VPCエンドポイントとEC2の接続のところをもう少し詳しく図にしてみました。

VPCエンドポイントは、インバウンドルールでポート443の許可が必要です。
インバウンドルールのフルオープンは良くないんで、ある程度絞る必要あると思います。
今回は接続先のサブネット（pwork_pri_subnet_az1）からのみ許可したいと思います。

EC2側はアウトバウンドルールでポート443の許可が必要です。ただ、アウトバウンドルールはフルオープンでも良いかと思いますね！でも、今回はSSMの仕様も含め確認するため、443だけ開けます！

上記をパラメータリストにしたのが、以下になります。

---
PWorkSSMEndpoint:
  securitygrps:★セキュリティグループ
    pwork_endpoint_sg:
      id: "pwork_endpoint_sg"
      group_description: "PWork VPC Endpoint SecurityGroup"
      group_name: "pwork_endpoint_sg"
      security_group_ingress:
        - ip_protocol: "tcp"
          cidr_ip: "{{pwork.vpcs.pworkvpc.cidr_block}}"★サブネットのCIDRのみに絞ってます
          from_port: 443
          to_port: 443
          description: "Allow HTTPS traffic."
      vpc_id: "{{pwork.vpcs.pworkvpc.vpc_id}}"
      tags:
        - key: "module"
          value: "PWorkInstSSM"

  vpcendpoints:
    ssm:
      id: "pwork_endpoint_ssm"
      vpc_id: "{{pwork.vpcs.pworkvpc.vpc_id}}"
      private_dns_enabled: True
      service_name: "com.amazonaws.{{common.region}}.ssm"
      security_group_ids:
        - "{{PWorkSSMEndpoint.securitygrps.pwork_endpoint_sg.attr_group_id}}"
      subnet_ids:
        - "{{pwork.subnets.pwork_pri_subnet_az1.attr_subnet_id}}"
        - "{{pwork.subnets.pwork_pri_subnet_az3.attr_subnet_id}}"
      vpc_endpoint_type: "Interface"

    ssmmessages:
      id: "pwork_endpoint_ssmmessages"
      vpc_id: "{{pwork.vpcs.pworkvpc.vpc_id}}"
      private_dns_enabled: True
      service_name: "com.amazonaws.{{common.region}}.ssmmessages"
      security_group_ids:
        - "{{PWorkSSMEndpoint.securitygrps.pwork_endpoint_sg.attr_group_id}}"
      subnet_ids:
        - "{{pwork.subnets.pwork_pri_subnet_az1.attr_subnet_id}}"
        - "{{pwork.subnets.pwork_pri_subnet_az3.attr_subnet_id}}"
      vpc_endpoint_type: "Interface"

VPCエンドポイントをCDKで作るときと壊すときは、結構時間がかかります。（１つ10分くらい）
私のように作ったり、壊したりする人は、これが、他のリソースと同じスタックに入っていると、作業効率が落ちるので、別スタックで実装しておくと良いです。
今回はVPCエンドポイントで１つのスタックにしています。

EC2インスタンス

EC2インスタンスのポイントは、IAMロールにAmazonSSMManagedInstanceCoreが必要なところです。
あとは、パブリックIPで作ったキーペア不要、ネットワークインタフェース不要ってあたりですかね。
パラメータリストは以下になります。

PWorkInstSSM:
  securitygrps:★セキュリティグループ
    pwork_instance_ssm_sg:
      id: "pwork_instance_ssm_sg"
      group_description: "PWork Instance SSM OutPut SecurityGroup"
      group_name: "pwork_instance_ssm_sg"
      security_group_egress:
        - ip_protocol: "tcp"
          destination_security_group_id: "{{PWorkSSMEndpoint.securitygrps.pwork_endpoint_sg.attr_group_id}}"
          ↑★VPCエンドポイント向けはセキュリティグループIDで指定してあげる。
              ただアウトバウンドルールは緩くてもよいのでここまですることはないかもしれない
          from_port: 443
          to_port: 443
          description: "Allow all traffic."
      vpc_id: "{{pwork.vpcs.pworkvpc.vpc_id}}"
      tags:
        - key: "module"
          value: "PWorkInstSSM"

  roles:
    pwork_instance_ssm_role:
      id: "pwork_instance_ssm_role"
      role_name: "pwork_instance_ssm_role"
      description: "PWork Instance SSM Role"
      assume_role_policy_document:
         "Version": "2012-10-17"
         "Statement":
           - "Effect": "Allow"
             "Action": "sts:AssumeRole"
             "Principal":
               "Service": "ec2.amazonaws.com"
      managed_policy_arns:
        - "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"★ポイント

  instanceprofiles:
    pwork_instance_ssm_prof:
      id: "pwork_instance_ssm_prof"
      roles:
        - "{{PWorkInstSSM.roles.pwork_instance_ssm_role.ref}}"
      instance_profile_name: "pwork_instance_ssm_prof"

  instances:
    pwork_instance_ssm:
      id: "pwork_instance_ssm"
      availability_zone: "ap-northeast-1a"
      block_device_mappings:
        - device_name: "/dev/xvda"
          ebs:
            delete_on_termination: true
            encrypted: false
            iops: 3000
            volume_size: 8
            volume_type: "gp3"
      iam_instance_profile: "{{PWorkInstSSM.instanceprofiles.pwork_instance_ssm_prof.ref}}"
      image_id: "ami-09cd9fdbf26acc6b4"
      instance_type: "t2.micro"
      security_group_ids:
        - "{{PWorkInstSSM.securitygrps.pwork_instance_ssm_sg.attr_group_id}}"
      subnet_id: "{{pwork.subnets.pwork_pri_subnet_az1.attr_subnet_id}}"
      tags:
        - key: "module"
          value: "PWorkInstSSM"
        - key: "Name"
          value: "PWorkInstSSM"

デプロイと出来たもの確認

まずはVPCエンドポイント

まずは一覧から、こんな感じ程度ですけどね・・・

特に説明すべきことがないですね。
次は、詳細画面ですが、まぁこっちも雰囲気だけですかね。こんな感じです～

EC2インスタンス

一覧は特にこんな感じ。
詳細画面もまぁこんな感じですね。

接続してみる～AWSコンソール編～

では接続してみましょう～。まずは「接続」をクリックですね。

接続画面です。でここで「接続」をクリックです。

でEC2インスタンスの接続後の画面です。接続は簡単ですね～（真っ黒ですね～）

接続してみる～IAM Identity Center経由編～

IAM Identity CenterはAWS Single Sign-onの後継サービスってことですけど、AWS SSOの方が浸透率が高いと感じますね。
ここでIAM Identity Center経由でのログインを書こうかなと思ったけど書くことが多かったので次回「いちはじCDK第１５回　AWS SSO接続」で説明します～

最後に～

最後に、今回の全コードはGITの方を参照して下さい～。
次回は「いちはじCDK第１５回　AWS SSO接続」になります～