はじめに
AWS CLI（awsコマンド）を普段何気なく使っているけれど、「このコマンドって内部でどこに通信してるの？」と気になったことはありませんか？
実際に strace を使ってコマンドの動きを覗いてみると、意外とシンプルな構造で動いていることが分かります。
実験してみた
例えば、以下のようにして AWS CLI を実行し、その裏側を strace で観察してみました。
strace -f -e trace=network aws s3 lsすると、以下のような出力が確認できました：
connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.255.255.254")}, 16) = 0
sendmmsg(4, [...], 2, MSG_NOSIGNAL) = 2
recvfrom(4, "...ap-northeast-1...", 2048, 0, ...) = 131
これは、AWS CLIがまずDNSを使って S3 エンドポイントの名前解決を行っている様子です。
この場合、s3.ap-northeast-1.amazonaws.com に対して Aレコードの問い合わせが送られ、IPアドレスが返ってきます。
どんな通信が行われているか？
名前解決後は、実際に HTTPS で AWS のエンドポイントと通信します。 strace を続けて観察していると、以下のような HTTPS 接続が現れました：
connect(5, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("52.219.x.x")}, 16) = 0つまり、AWS CLI を使用する際の最低限の通信要件は次のようになります：
- UDP/53 もしくは TCP/53（DNSクエリ）
- TCP/443（HTTPS通信）
また、DNSサーバーは /etc/resolv.conf に記載されたものが使われており、プロキシ環境やVPC内のカスタムDNSを利用している場合はその設定に依存します。
まとめ
AWS CLI は非常にシンプルな構成で動いており、名前解決して HTTPS 通信するだけという基本に忠実な作りになっています。 通信に失敗する場合は、まず DNS や HTTPS の通信経路が遮断されていないかを確認するのが第一歩です。
strace を使ってコマンドの内部を可視化すると、「なぜ失敗しているのか」や「どんな外部リソースに依存しているのか」が見えてくるので、トラブルシュートにも役立ちます。