📝

Elastic Beanstalk で NAT ゲートウェイを使用しない場合に必要な VPC エンドポイントを調べてみた

2022/10/09に公開約8,400字

https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/vpc.html#services-vpc-private

Elastic Beanstalk にプライベートなアプリケーションを構築する場合、NAT ゲートウェイを使用することがあると思います。

プライベートサブネット – インスタンスは NAT デバイスを使用してインターネットにアクセスします。

しかし、セキュリティ要件で直接インターネットへ接続することができない場合に、NAT ゲートウェイを使用できない場合もあると思います。
その際、アプリケーションを正常に起動するために最低限必要な VPC エンドポイントが AWS 公式ドキュメントには記載されていなかったので調べてみました。

結論

以下の 4 つの VPC エンドポイントが必要でした。

・com.amazonaws.ap-northeast-1.s3
・com.amazonaws.ap-northeast-1.sqs
・com.amazonaws.ap-northeast-1.cloudformation
・com.amazonaws.ap-northeast-1.logs

なお、最低限必要な VPC エンドポイントではありませんが、Elastic Beanstalk コンソールで環境のヘルスを表示するためには、以下の VPC エンドポイントが必要でした。

・com.amazonaws.ap-northeast-1.elasticbeanstalk-health

検証環境

  • パブリックサブネット × 2 (図では 1 つに省略)
  • プライベートサブネット × 1
    • ルートテーブル
      • VPC のローカル (10.0.0.0/16)
      • S3 の VPC エンドポイント
  • VPC エンドポイント
    • com.amazonaws.ap-northeast-1.s3 (ゲートウェイ型)
    • com.amazonaws.ap-northeast-1.sqs (インターフェイス型)
    • com.amazonaws.ap-northeast-1.cloudformation (インターフェイス型)
    • com.amazonaws.ap-northeast-1.logs (インターフェイス型)
  • VPC エンドポイントのセキュリティグループ
    • インバウンドは VPC 内からのすべてのトラフィックを許可
    • アウトバウンドはデフォルトですべてのトラフィックを許可
  • パブリック ALB
    • Elastic Beanstalk により自動作成
  • プライベート Elastic Beanstalk

Elastic Beanstalk 起動時の設定

  • ウェブサーバー環境
  • プラットフォーム
    • Node.js 16 running on 64bit Amazon Linux 2
    • 5.6.0 (Recommended)
  • サンプルアプリケーション
  • プリセット
    • カスタム設定
  • ソフトウェア
    • CloudWatch Logs へのインスタンスログのストリーミング: 有効
    • ライフサイクル: 終了時にログを削除する
  • ネットワーク
    • ロードバランサーのサブネット
      • パブリックサブネット × 2
    • インスタンスサブネット
      • プライベートサブネット × 1

上記以外はデフォルト設定です。

環境起動確認

上記の設定で Elastic Beanstalk 環境を起動すると、数分でサンプルアプリケーションに接続できました。

ALB のヘルスチェックにも合格しています。

CloudWatch Logs にもログが出力されています。

環境が起動できない場合には、VPC エンドポイントを設置するサブネットや、VPC エンドポイントのセキュリティグループの設定を見直してください。

elasticbeanstalk-health がない場合

拡張ヘルスのための VPC エンドポイントである「elasticbeanstalk-health.region.amazonaws.com」がない場合、Elastic Beanstalk コンソールでは以下のように表示されます。

また、以下のイベントも記録されていました。

Environment health has transitioned from Ok to Unknown. None of the instances are sending data.

上記の表示になる理由については、以下の AWS 公式ドキュメントに関連する情報が記載されています。

https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/vpc-vpce.html#vpc-vpce.healthd

環境の 拡張ヘルスレポート を有効にすると、拡張ヘルス情報を AWS PrivateLink 経由で送信するように設定することもできます。拡張ヘルス情報は、環境インスタンスの Elastic Beanstalk コンポーネントである healthd デーモンによって、別の Elastic Beanstalk 拡張ヘルスサービスに送信されます。VPC でこのサービスのインターフェイス VPC エンドポイントを作成するには、「インターフェイスエンドポイントの作成」の手順に従います。[サービス名] で、com.amazonaws.region.elasticbeanstalk-healthを選択します。

拡張ヘルスのための VPC エンドポイントは Elastic Beanstalk 環境の起動には必須ではありませんでしたが、環境のヘルスチェックに関する情報が必要な場合には設定すると良いと思います。

拡張ヘルスのための VPC エンドポイントを設定後の Elastic Beanstalk コンソールではヘルスが OK になりました。

VPC エンドポイントが不足している場合

先述の 4 つの VPC エンドポイントのうち、1 つでも不足している場合には、アプリケーションが正常にインストールされないようで、ALB によるヘルスチェックが失敗します。

試しに S3 のエンドポイントをルートテーブルから削除して、既存 Elastic Beanstalk 環境の EC2 をスケールアウトで新規起動するよう、最小容量を増やします。

新規に起動した EC2 インスタンスですが、ALB のヘルスチェックに失敗しています。

また、CloudWatch Logs にもログが出力されていません。

EC2 の中身までは確認していませんが、ユーザーデータには以下の設定が記載されています。

Content-Type: multipart/mixed; boundary="===============5189065377222898407=="
MIME-Version: 1.0

--===============5189065377222898407==
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
repo_upgrade: none
repo_releasever: 2.0
cloud_final_modules:
 - [scripts-user, always]

--===============5189065377222898407==
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="user-data.txt"

#!/bin/bash
exec > >(tee -a /var/log/eb-cfn-init.log|logger -t [eb-cfn-init] -s 2>/dev/console) 2>&1
echo [`date -u +"%Y-%m-%dT%H:%M:%SZ"`] Started EB User Data
set -x


function sleep_delay 
{
  if (( $SLEEP_TIME < $SLEEP_TIME_MAX )); then 
    echo Sleeping $SLEEP_TIME
    sleep $SLEEP_TIME  
    SLEEP_TIME=$(($SLEEP_TIME * 2)) 
  else 
    echo Sleeping $SLEEP_TIME_MAX  
    sleep $SLEEP_TIME_MAX  
  fi
}

# Executing bootstrap script
SLEEP_TIME=2
SLEEP_TIME_MAX=3600
while true; do 
  curl https://elasticbeanstalk-platform-assets-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/stalks/eb_nodejs16_amazon_linux_2_1.0.1696.0_20220929200609/lib/UserDataScript.sh > /tmp/ebbootstrap.sh 
  RESULT=$?
  if [[ "$RESULT" -ne 0 ]]; then 
    sleep_delay 
  else
    /bin/bash /tmp/ebbootstrap.sh     'https://cloudformation-waitcondition-ap-northeast-1.s3-ap-northeast-1.amazonaws.com/arn%3Aaws%3Acloudformation%3Aap-northeast-1%3A470745586162%3Astack/awseb-e-38amvtnyvm-stack/5df91d70-477b-11ed-ae80-0aa73405eab9/AWSEBInstanceLaunchWaitHandle?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20221009T023755Z&X-Amz-SignedHeaders=host&X-Amz-Expires=86399&X-Amz-Credential=AKIASU3QWAIZOQBBO25R%2F20221009%2Fap-northeast-1%2Fs3%2Faws4_request&X-Amz-Signature=d1fa0c3c2aef9c8e7ab0f1bbc4bc8dd69d0f40a52e4360d096c52a285e0dff2f'    'arn:aws:cloudformation:ap-northeast-1:470745586162:stack/awseb-e-38amvtnyvm-stack/5df91d70-477b-11ed-ae80-0aa73405eab9'    'a4cbe856-ff20-4927-9d2e-c69e9361562b'    'https://elasticbeanstalk-health.ap-northeast-1.amazonaws.com'    ''    'https://elasticbeanstalk-platform-assets-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/stalks/eb_nodejs16_amazon_linux_2_1.0.1696.0_20220929200609'    'ap-northeast-1'
    RESULT=$?
    if [[ "$RESULT" -ne 0 ]]; then 
      sleep_delay 
    else 
      exit 0  
    fi 
  fi 
done

--===============5189065377222898407==-- 

ユーザーデータの中で、S3 や CloudFormation のエンドポイントらしき URL が記載されているので、このあたりが必要な VPC エンドポイントと関連がありそうです。

S3 のエンドポイントを再度ルートテーブルに設定すると、正常にアプリケーションがインストールされ、CloudWatch Logs にもログが出力されます。


SQS の VPC エンドポイントの必要性

ワーカー環境であれば SQS の VPC エンドポイントの必要性が分かりやすいのですが、ウェブサーバー環境で SQS の VPC エンドポイントが必要な理由については、以下の外部サイトで記載されていました。

https://stackoverflow.com/questions/63196085/elastic-beanstalk-app-in-private-vpc-without-nat

On the following deployment I now noticed a new sqs connection error which was solved by adding the sqs endpoint.
次のデプロイで、新たにsqs接続のエラーに気づきましたが、sqsエンドポイントを追加することで解決しました。

どうやらウェブサーバー環境でも裏側で SQS との通信が行われているようです。
そのため、SQS の VPC エンドポイントが必要であることがわかりました。

EC2 のセキュリティグループで必要なアウトバウンドルール

セキュリティ要件が厳しい場合には、Elastic Beanstalk 環境内の EC2 インスタンスのセキュリティグループルールで、特定のアウトバウンドルールのみ許可するという場合もあると思います。

そこで、必要なアウトバウンドルールについても調査してみたところ、以下のようなアウトバウンドルールであればアプリケーションが正常にインストールされることが確認できました。

・すべてのトラフィック: VPC のローカル (10.0.0.0/16)
・HTTPS: S3 の VPC エンドポイントのプレフィックスリスト

HTTPS のルールがない場合、おそらくユーザーデータに記載されている S3 のエンドポイントに接続できなくなるため、アプリケーションのインストールができないものと思われます。

そのため、HTTPS で S3 へのアクセスも許可することが必要であると思われます。

まとめ

今回は Elastic Beanstalk で NAT ゲートウェイを使用しない場合に必要な VPC エンドポイントを調べてみました。
NAT ゲートウェイを使用できない要件の場合に参考になれば幸いです。

参考資料

Discussion

ログインするとコメントできます