トップ > AWS > Amazon VPC Lattice解説②（通信ログ編）

Amazon VPC Lattice解説②（通信ログ編）

AWS VPC Lattice VPC Flow Logs
記事タイトルとURLをコピーする

エンタープライズクラウド部の山下(祐)です。

本ブログは、Amazon VPC Lattice（以下、Lattice）の解説シリーズ第2回となります。 （前回から大幅に時間が経過してしまいました。。申し訳ありません。）
第1回では、Latticeの概要、および構成要素について解説しました。

blog.serverworks.co.jp

第2回となる今回は、Latticeを介した通信のログを見ていきたいと思います。

今回の検証環境の構成

クライアントとなるEC2を格納する「client-VPC」と、ターゲットとなるEC2を格納する「target-vpc」を用意し、Latticeで接続します。両VPCのCIDRは同一とし（10.0.0.0/24）、クライアントEC2とターゲットEC2のIPアドレスも同一とします（10.0.0.140）。 EC2にセッションマネージャーで接続するためのVPCエンドポイント、リポジトリ用のS3ゲートウェイエンドポイントも作成していますが、ここでは省略します。

今回確認するログ

Latticeサービスネットワークおよびサービスのアクセスログ

Latticeでは、サービスおよびサービスネットワークでアクセスログを取得できます。 モニタリングの設定でアクセスログを有効化し、配信先を決定します。2023年7月現在、以下の配信先が選択可能です。

  • CloudWatch ロググループ
  • S3
  • Kinesis Data Firehose ストリーム

今回は、サービスおよびサービスネットワークの両方でアクセスログを有効にし、CloudWatch ロググループに配信します。

VPCフローログ

今回は、Latticeのログの他に、送信元VPC・ターゲットVPCのVPCフローログも取得し、CloudWatch ロググループに配信します。 VPCフローログのログフォーマットはカスタム形式とし、以下の項目を取得します。

${pkt-src-aws-service} ${pkt-srcaddr} ${srcaddr} ${pkt-dst-aws-service} ${pkt-dstaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${log-status}

pkt-src-aws-service・pkt-dst-aws-serviceの値にLatticeの情報が記録されるのか確認します。 また、pkt-srcaddr/pkt-dstaddrと、srcaddr/dstaddrで値が変わるかどうかについても見てみたいと思います。

各項目の詳細は以下の公式ドキュメントを参照してください。

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/flow-logs.html#flow-logs-fields

クライアントEC2からターゲットEC2への接続

クライアントEC2にて、Latticeサービスドメイン宛てにcurlを実行し、Lattice経由でターゲットEC2に接続します。

sh-4.2$ curl -v http://log-test-087181cb8d65d7263.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws
*   Trying 169.254.171.96:80...
* Connected to log-test-087181cb8d65d7263.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws (169.254.171.96) port 80 (#0)
> GET / HTTP/1.1
> Host: log-test-087181cb8d65d7263.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 200 OK
< date: Thu, 06 Jul 2023 04:26:21 GMT
< server: Apache/2.4.57 ()
< last-modified: Thu, 06 Jul 2023 03:07:30 GMT
< etag: "1a-5ffc8d118da21"
< accept-ranges: bytes
< content-length: 26
< content-type: text/html; charset=UTF-8
<
"Welcom to target-ec2 !!"
* Connection #0 to host log-test-087181cb8d65d7263.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws left intact
sh-4.2$
sh-4.2$

同コマンドを時間を置いて繰り返し、ターゲットEC2に何度か接続します。

ログ確認

接続が問題なく出来たら、各種ログを確認します。

Latticeサービスネットワークのアクセスログ

サービスネットワークのログのサンプルを記載します。

{
    "startTime": "2023-07-06T03:58:37Z",
    "requestMethod": "GET",
    "requestPath": "/",
    "protocol": "HTTP/1.1",
    "responseCode": 200,
    "bytesReceived": 199,
    "bytesSent": 228,
    "duration": 3,
    "userAgent": "curl/8.0.1",
    "hostHeader": "log-test-087181cb8d65d7263.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws",
    "targetIpPort": "10.0.0.140:80",
    "targetGroupArn": "arn:aws:vpc-lattice:ap-northeast-1:xxxxxxxxxxxx:targetgroup/tg-02a22e35e4684b926",
    "sourceIpPort": "10.0.0.140:42460",
    "serverNameIndication": "-",
    "sourceVpcId": "vpc-04f2e96095a225c8c",
    "destinationVpcId": "vpc-083c5ac3d4e2a378b",
    "serviceArn": "arn:aws:vpc-lattice:ap-northeast-1:xxxxxxxxxxxx:service/svc-087181cb8d65d7263",
    "serviceNetworkArn": "arn:aws:vpc-lattice:ap-northeast-1:xxxxxxxxxxxx:servicenetwork/sn-0378d8efb324015d5",
    "requestToTargetDuration": 2,
    "responseFromTargetDuration": 0,
    "sslCipher": "-",
    "tlsVersion": "-",
    "resolvedUser": "-",
    "authDeniedReason": "-"
}

sourceIpPort・targetIpPortは、どちらも同じIPアドレス（10.0.0.140）になっています。 ただし、sourceVpcId・destinationVpcIdの記載があるため、送信元ノード・宛先ノードが不明になることはなさそうです。

アクセスログの各項目の詳細は、以下の公式ドキュメントを参照してください。

docs.aws.amazon.com

Latticeサービスのアクセスログ

サービスで取得したアクセスログについても、サービスネットワークで取得したアクセスログと同等の内容でした。

Latticeアクセスログ

client-vpcのVPCフローログ

client-vpcのVPCフローログにて、クライアントEC2からLatticeへのHTTPアクセスを抜粋し、表形式にしたものが下図です。


pkt-src-aws-service・pkt-dst-aws-serviceは空でした。2023年7月現在、Latticeはこの項目の値として指定されないようです。 pkt-src-aws-service・pkt-dst-aws-serviceに指定可能な値については、下記公式ドキュメントに記載があります。

docs.aws.amazon.com


pkt-srcaddr/pkt-dstaddrと、srcaddr/dstaddrの値は同じでした。

また、ターゲットEC2のIPアドレス（10.0.0.140）は記録されず、リンクローカルアドレス（169.254.171.96）が記録されています。 クライアントEC2はターゲットEC2のIPアドレスを意識する必要がないため、IPが重複しても通信が可能となっていることが分かります。

client-vpcのVPCフローログ

実際、クライアントEC2でLatticeサービスドメインへの名前解決を実施すると、リンクローカルアドレスが返されます。

sh-4.2$ dig log-test-087181cb8d65d7263.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws A

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.13 <<>> log-test-087181cb8d65d7263.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47395
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;log-test-087181cb8d65d7263.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws. IN A

;; ANSWER SECTION:
log-test-087181cb8d65d7263.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws. 60 IN A 169.254.171.96

;; Query time: 2 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Thu Jul 06 08:26:17 UTC 2023
;; MSG SIZE  rcvd: 118

sh-4.2$

target-vpcのVPCフローログ

target-vpcのVPCフローログにて、LatticeからターゲットEC2へのHTTPアクセスを抜粋し、表形式にしたものが下表です。


pkt-srcaddr/pkt-dstaddrと、srcaddr/dstaddrの値は同じでした。 また、クライアントEC2のIPアドレスは記録されず、リンクローカルアドレスが記録されています。 ただし、client-vpcとは異なり、3つのリンクローカルアドレス（169.254.171.192・169.254.171.193・169.254.171.194）からターゲットEC2へのHTTPアクセスがあります。

targe-vpcのVPCフローログ

確認結果まとめ

ここまでの確認結果をまとめると以下のようになりました。

  • Latticeのアクセスログでは、送信元IP・宛先IPにはクライアント・ターゲットのIPが記録された。
  • client-vpcのフローログでは、宛先IPには固定のリンクローカルアドレスが記録された。
  • target-vpcのフローログでは、送信元IPには3つのリンクローカルアドレスが記録された。

確認結果まとめ

VPCフローログだけでは、クライアント・ターゲット双方のIPを確認することは出来ないため、運用時、Latticeのアクセスログ有効化は必須と言えそうです。 ただし、Latticeのアクセスログだけでは、リンクローカルアドレスと適切に通信できているか確認することが出来ないため、 トラブルシュートのためには、VPCフローログも合わせて有効化しておくことが望ましいかと思います。

（おまけ）Latticeのネットワークインタフェースについて

ここで、target-vpcのネットワークインタフェースと、target-vpc-flowlogsのログストリームを比較してみます。 すると、ネットワークインタフェースの画面で確認できないENI IDで、3件のログストリームが存在していることが確認できました。


各ログストリームの中身を確認すると、pkt-srcaddr/pkt-dstaddrが、ターゲットEC2へアクセスしていたリンクローカルアドレスと紐づいていました。


これらのENI IDの正体は、Latticeのネットワークインタフェースです。 AWSサポートに確認したところ、以下の回答が得られました。

  • ターゲットグループを設定すると、ターゲットと通信するために、Latticeによってネットワークインタフェースが作成される。
  • ネットワークインタフェースはターゲットグループのVPC上に作成される。ただし、コンソールのネットワークインタフェースの画面では、存在を確認することができない。
  • Latticeによって作成されるネットワークインタフェースの数は増減する。必ず3つとは限らない。

また、これらのENI IDのログのみ、pkt-srcaddr/pkt-dstaddrとsrcaddr/dstaddrに差分がありました。 pkt-srcaddr/pkt-dstaddrはリンクローカルアドレスですが、srcaddr/dstaddrは「0.0.0.0」になっていました。

pkt-srcaddr/pkt-dstaddrを取得することでリンクローカルアドレスが表示され、Latticeのインタフェースであることが推測できました。 本来利用者から見えないインタフェースが、VPCフローログで炙り出されたのは面白かったです。


以上、Latticeの通信ログに関する解説でした。 このブログが少しでもご参考になれば幸いです。

山下 祐樹(執筆記事の一覧)

2021年11月中途入社。前職では情シスとして社内ネットワークの更改や運用に携わっていました。 2023 Japan AWS All Certifications Engineers。