どこにかいてあったんですか？誰が言ったんですか？サポートされているんですか？問題。ほんと嫌になるんだが、よくよく考えると日本の教育の被害者なんではないかと。テキストに書いてある問題をひたすらやって難関大学に合格。そういう環境だと、そうなっちゃうかもしれない。高校の同期で、あだ名が「トクさん」という奴がいたが、模試をやれば、数学の解答用紙を第一問だけで使いきる。理由は、公式とか思いつかないと、その公式を自分でまず編み出して、それから問題を解くというやり方だから。なので、よくよく聞くと、「それ公式であるじゃん」というと、「そうなん？自分で発見したものかと思ったわw」と呑気な答え。そこそこの国立大学の数学科に進学した。神なのかアホなのかと思ったが、これは結構重要で、どこに書いてあったのか、誰が言ったのか知らずとして、自分でやってみるという姿勢はとても重要。その中に実は新しい発見があるのだが。。。つまり、どこに書いてあったんですか？誰が言ったんですか？といっている限り、先頭には立てない。それどころか、それを頼りに動く、作業員にしかなれない。AIの出現で絶滅すると思われる。
閑話休題
EC2 Instance Connect Endpointをやってみた。EC2 Instance Connectと何が違うのかというと、Endpoint経由で、Private Subnetにあるインスタンスに踏み台ホストを経由しないでアクセスができる。そもそも、EC2 Instance Connect は、Public SubnetにあるインスタンスのSSHの画面がAWSのコンソール（WEB)に表示できるという、表示だけかい！という機能でそれが、Endpointかぁ、コピペできないしなぁ、ファイル転送できないしなぁ、VPN貼った方が便利だろうなぁ。。。と思っていたが。
とりあえずやってみた。
EC2 Instance Connect Endpointの設定で結構面倒なのが、Security Groupの設定。
EndpointのSecurity Group
– OutbountにRDP/SSHをEC2で使うセキュリティグループに対して送信許可
EC2のSecurity Group
-InboundにRDP/SSHをEndpointのSecurity Groupに対して送信許可
-Outboundは、全てのプロトコルで全てのアドレスに対して送信許可
という設定をする。
具体的には、
EndpointのSecurity Group
下の黒塗りになっているSSH/RDPのDestinationは、EC2で指定する予定のSecurity Group
Outboundの画面
インスタンスで使うSecurity Group
プライベートIPからの接続は全許可してある。それに加えて、SSH/RDPは、EndpointのSecurity Groupからの接続を許可してある。
Inboundの画面
ちょっとわかりにくい。これをCloudFormationで設定したのだが、循環参照の仕方が難しい。もっというと、なぜか自分のCloudFormationは、jsonで書いてしまっていて。。。やりかたがYAMLでしか調べられず。変換する羽目に。まぁ、１発で変換できたがw
Endpointの作成
EC2 Instance Connect Endpointを指定して、VPCを指定する。
さらにこのEndpointに当てるSecurity Groupは、EndpointのSecurity Groupを設定。
さらにサブネットは、Private Subnetにする。
これで設定完了。
インスタンスは、WindowsでもLinuxでも、このサブネットで、EndpointのSecurity Groupを参照しているEC2のSecurity Groupを指定して作成すればOK。
接続方法は、Linuxの場合は、Connect ボタンをクリックするとすぐに接続できる。作ったEndpointを指定するくらい。
これでブラウザ経由でLinuxインスタンスの操作ができる。。。だけ。
Windowsインスタンスの接続は、これではできない。awscli経由でトンネルを春必要がある。といってもそんな難しくはない。ただし、awscliを最新にする必要がある。具体的には、2.12.0以上にする必要がある。
awscliがインストールされていて、設定が終わっているとして、記述すると、以下のコマンドを実行する。
aws ec2-instance-connect open-tunnel --instance-id "宛先インスタンスID" --remote-port 3389 --local-port "手元の端末の任意の空きポート"
そうすると、トンネルができるので、手元のRDPクライアントで、localhost:手元の端末の任意の空きポートをホスト名にして接続をする。
Administrator/証明書で捻り出したパスワードで接続をする。RDPだと、手元のフォルダのリダ入れクションができるのでファイル転送も可能になる。
さて、この方法、Linuxでもいけるんじゃないかと。結果としていけた。
aws ec2-instance-connect open-tunnel --instance-id "宛先インスタンスID" --remote-port 22 --local-port "手元の端末の任意の空きポート"
Linuxインスタンスへの接続は
Ubuntu
ssh -i My-VPC-KeyPair.pem -p "手元の端末の任意の空きポート" ubuntu@localhost
Amazon Linux
ssh -i My-VPC-KeyPair.pem -p "手元の端末の任意の空きポート" ec2-user@localhost
さらにscpの場合は、(Ubuntuの例)
scp -i My-VPC-KeyPair.pem -P 手元の端末の任意の空きポート" <転送ファイル> ubuntu@localhost:~/
で転送できた。
ちなみにトンネルを張らない、ファイルの転送をしない場合は、以下でも接続ができる。
aws ec2-instance-connect ssh --instance-id "宛先インスタンスID" --connection-type eice --private-key-file ~/証明書.pem --os-user ubuntu
うー。awscliのコマンド補完がなかったらオプションわからずだったw aws ec2-instance-connectは結構いろいろ使えそうだなぁ。
調べてみると、いろいろ制限事項があるが、踏み台ホストはないのは便利。おまけにこのエンドポイントは無料なんですよね。使う、使わないに関わらず検証環境だったら有効にすべき。
また、EndpointをCloudFormationで作る方法はまだわからない。
この設定、
どこに書いてあったんですか？ ＝＝＞AWSのページに書いてある。結構いろいろブログでも取り上げられている。AWSのページに書いてある。
誰がいったんですか？ ＝＝＞AWSのページに書いてある。結構いろいろブログでも取り上げられている。AWSのページに書いてある。
サポートされているんですか？ ＝＝＞AWSのページに書いてある。
ここまで説明しないと使ってもらえないことも。
ただ、この設定、情報があっても、サポートされていても、一度は実際に手を動かしてやってみないとまずうまくいかない。たとえ誰かが作ったCloudFormationのファイルを使っても。。。
で、自分は使うか？というとこれまた微妙で、普段は、VPN経由なので、簡単な検証の時以外は使わないかも。