Session Manager で EC2 に接続する(SSH 不要)
Systems Manager の Session Manager を使い、SSH キーも踏み台サーバーもポート 22 の開放も不要な状態で EC2 インスタンスにシェルアクセスする方法。
Systems Manager - Session Manager を使うと、SSH を使わずに EC2 インスタンスへシェルアクセスできます。
- SSH キー不要: SSH キーの管理やセキュリティ確保が不要になります。
- 踏み台ホスト不要: EC2 インスタンスへアクセスするための中継サーバーが不要になります。
- ポート 22 のインバウンドルール不要: セキュリティグループでポートを開放する必要がなくなり、セキュリティが向上します。
構築
Session Manager を利用するには、EC2 インスタンスに AmazonSSMManagedInstanceCore ポリシーをアタッチした IAM ロールが必要です(30 行目)。
AWSTemplateFormatVersion: 2010-09-09Resources: EC2: Type: AWS::EC2::Instance Properties: IamInstanceProfile: !Ref InstanceProfile ImageId: ami-0f310fced6141e627 InstanceType: t3.small SecurityGroups: - !Ref SecurityGroup
InstanceProfile: Type: AWS::IAM::InstanceProfile Properties: Path: / Roles: - !Ref IamRole
IamRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: ec2.amazonaws.com Action: sts:AssumeRole ManagedPolicyArns: - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore RoleName: ec2-role
SecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: Example GroupName: ec2-security-group SecurityGroupIngress: - CidrIp: 0.0.0.0/0 FromPort: 443 IpProtocol: tcp ToPort: 443EC2 インスタンスがプライベートサブネットにある場合は、以下の VPC エンドポイントを設定してください。
com.amazonaws.region.ssmcom.amazonaws.region.ec2messagescom.amazonaws.region.ssmmessages
詳細は公式のナレッジを参照してください。
スタックをデプロイします。
aws cloudformation deploy \ --template-file template.yaml \ --stack-name ec2-session-manager \ --capabilities CAPABILITY_NAMED_IAMテスト
インスタンスとのセッションは、以下のコマンドで開始できます。
aws ssm start-session --target i-xxxxxxxxxxxxxxxxx以下のような出力が表示されればログイン成功です。
Starting session with SessionId: your-session-idsh-4.2$後片付け
作成したリソースを削除するには、スタックを削除します。
aws cloudformation delete-stack --stack-name ec2-session-managerまとめ
EC2 インスタンスロールに AmazonSSMManagedInstanceCore マネージドポリシーをアタッチするだけで、SSH キーペアも踏み台ホストも介さずに aws ssm start-session でシェルセッションを開けるようになりました。実質的にはこのポリシーのアタッチだけで設定は完了しており、この例のセキュリティグループもアウトバウンドの HTTPS を許可するだけで、ポート 22 へのインバウンドルールは一切不要です。従来の SSH ベースのアクセス方式と比べると、管理・保護しなければならない対象がそれだけ大きく減ることになります。事前に計画しておくべき唯一の前提は、ssm、ec2messages、ssmmessages の各エンドポイントへのネットワーク到達性です。パブリックサブネットであれば追加設定なしに到達できますが、プライベートサブネットの場合は、セッションが成立する前に対応する VPC エンドポイントを用意しておく必要があります。
Related posts
PhpStormとXdebugでAWS EC2上のPHPをリモートデバッグする
PhpStormとXdebugを使ってEC2上のPHPアプリケーションをリモートデバッグする方法。サーバー側のini設定からIDEのパスマッピングまでを解説。
SSHポートフォワーディングでEC2 Windowsインスタンスに安全にアクセスする
プライベートサブネット内のEC2 WindowsインスタンスにSSH踏み台ホスト経由でアクセスし、RDPを一切パブリックインターネットに晒さない方法。
EC2上でProxy.pyを軽量HTTPプロキシとして動かす
Proxy.pyにはそれ自体の認証機構がないため、EC2インスタンス上で動かしつつSSHトンネル経由で安全にアクセスする方法です。
Cognito User PoolsとOIDCでSlackサインインを実装する
Cognito user poolをOIDC経由でSlackと連携させ、"Sign in with Slack"をAmplifyでNext.jsアプリに組み込みます。
Lambda Web AdapterでFastAPIをAWS Lambdaにデプロイする
Lambda Web Adapterを使うと、FastAPIで書いたAPIバックエンドをコンテナのまま単一のLambda関数にデプロイできます。
