ALBのアクセスログにアベイアビリティゾーン情報を追加してみた

はじめに

AWSチームのすずきです。

ELB (Application Load Balancer:以下ALB) アクセスログは、接続元となるクライアント(ブラウザ等)と、接続先のターゲット(httpd等が稼働するEC2)のIPアドレスを確認することが可能です。

今回、アクセスログに含まれない ALBノードのIPアドレス、アベイアビリティゾーン単位での解析を実施する必要が生じたため、 アクセスログのファイル名よりALBノードのIPアドレス情報を取得し、ネットワークインターフェイス情報からアベイアビリティゾーンを求める機会がありましたので紹介します。

アクセスログ仕様

ALBのアクセスログの仕様は、2019年9月時点の公式ドキュメントを参考にしました。

• Application Load Balancer のアクセスログ

ログファイル

ログファイル名に含まれる「ip-address」より、ALBノードのIPアドレスを求めます。

ログファイル名サンプル

bucket[/prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/yyyy/mm/dd/aws-account-id_elasticloadbalancing_region_load-balancer-id_end-time_ip-address_random-string.log.gz

アクセスログファイル

CLI

CLIを利用して、ALBノードのIPアドレスがアクセスログファイル名に含まれる事、 ネットワークインターフェイス情報より、アベイアビリティゾーン、プライベートIP情報が取得出来る事を確認しました。

hosts

• ALBのDNS名より、正引きのIPアドレスを確認します。

$ host public-xx.ap-northeast-1.elb.amazonaws.com
public-xxxx.ap-northeast-1.elb.amazonaws.com has address 13.113.xx.63
public-xxxx.ap-northeast-1.elb.amazonaws.com has address 54.199.xx.110

アクセスログファイル

• ALBのログ出力先のS3、ログファイル名にALBのIPアドレスが含まれる事を確認します。

$ aws s3 ls s3://aa/AWSLogs/xx/elasticloadbalancing/ap-northeast-1/2019/09/07/ | awk '{print $4}'
xx_elasticloadbalancing_ap-northeast-1_app.pub.yy_20190907T0745Z_13.113.xx.63_zzz.log.gz
xx_elasticloadbalancing_ap-northeast-1_app.pub.yy_20190907T0745Z_54.199.xx.110_zzz.log.gz

ノードのIPアドレス

• アクセスログのキー(ファイル名)を「_」区切りの配列とし、末尾から2つ目の要素からALBノードのIPアドレスが抽出出来る事を確認します。

$  aws s3 ls s3://aa/pub/AWSLogs/xxx/elasticloadbalancing/ap-northeast-1/2019/09/07/ | awk '{print $4}' |  awk -F '_' '{print $(NF-1)}'
13.113.xx.63
54.199.xx.110

ノードのアベイアビリティゾーン

• EC2のAPI「describe-network-interfaces」を利用し、ALBノードのIPアドレスに一致するネットワークインターフェスの情報を確認します。

$ aws ec2 describe-network-interfaces --filters 'Name=addresses.association.public-ip,Values=13.113.xx.63' --query 'NetworkInterfaces[*].[NetworkInterfaceId,AvailabilityZone,PrivateIpAddress,Association.PublicIp]'
[
    [
        "eni-xxx",
        "ap-northeast-1a",
        "172.31.xx.223",
        "13.113.xx.63"
    ]
]

• 「Internal」のALBの場合、フィルタの対象を「private-ip-address」とします。

AvailabilityZone

$ aws ec2 describe-network-interfaces --filters 'Name=addresses.private-ip-address,Values=172.31.xx.29' --query 'NetworkInterfaces[*].[NetworkInterfaceId,AvailabilityZone,PrivateIpAddress]'
[
    [
        "eni-xxx",
        "ap-northeast-1a",
        "172.31.xx.29"
    ]
]

Python(Boto3)

Lambda (Python) で実装する前提で、Boto3を利用してアベイアビリティゾーンを求めてみました。

    ec2 = boto3.client('ec2')
    
    s3key='prefix/AWSLogs/xx_elasticloadbalancing_ap-northeast-1_app.pub.yy_20190907T0745Z_13.113.xx.63_zzz.log.gz'

    # elb ip
    elb_listener_ip = s3key.split('_')[-2]

    # public elb
    responce = ec2.describe_network_interfaces(
        Filters=[{'Name':'association.public-ip','Values':[elb_listener_ip]}]
    )

    # internal elb
    if not responce["NetworkInterfaces"]:
        responce = ec2.describe_network_interfaces(
        Filters=[{'Name':'private-ip-address','Values':[elb_listener_ip]}]
    ) 

    availabilityzone='none'
    privateipaddress='none'

    if responce["NetworkInterfaces"]:
        if responce["NetworkInterfaces"][0]:
            if responce["NetworkInterfaces"][0]["AvailabilityZone"]:
                availabilityzone = responce["NetworkInterfaces"][0]["AvailabilityZone"]
            if responce["NetworkInterfaces"][0]["PrivateIpAddress"]:
                privateipaddress = responce["NetworkInterfaces"][0]["PrivateIpAddress"]

    print('AvailabilityZone: ' + availabilityzone)
    print('PrivateIpAddress: '+ privateipaddress)

実行結果

AvailabilityZone: ap-northeast-1a
PrivateIpAddress: 172.31.xx.223

ALBのアクセスログのファイル名(キー)より、ノードのIPアドレスとアベイアビリティゾーンを確認できました。

まとめ

アクセスログに含まれないALBノードの情報をLambda(Python)を利用して取得できた事で、ログ項目に追加できる目処がつきました。

アベイアビリティゾーン別の解析以外にも、ALBを利用するシステムで問題が発生し、クライアントやターゲットのログとALBのログの突き合わせが必要となった場合、 ALBノードのIPアドレス情報が役立つと考えられます。

ログカラムを追加したアクセスログ、Kinesis Firehose などを利用してS3に保存する事で、Amazon Athena で解析する事が可能です。 アクセスログの追加したALBノードのIPアドレス、アベイアビリティゾーンに対応した解析の手順は追って紹介させて頂きたいと思います。

ELBとCloudFrontのアクセスログをサーバレスに集約させてみた

尚、今回紹介した方法では、ALBノードのスケールインや交換などがあった場合、削除されたノードのネットワークインターフェイス情報は取得できないため、 古いアクセスログでは結果が得られない可能性があります。

また、ALBのアクセスログファイル名に含まれる「_」、区切り文字の扱いについてはドキュメント上は明文化されておらず、今後変化する可能性もあります。 アベイアビリティゾーンやIPアドレス情報の欠落が許容できない用途には、今回の手法は適さない可能性がありますのでご留意ください。