トップ > Amazon MWAA > Amazon MWAA (Amazon Managed Workflows for Apache Airflow) のネットワーク構成と料金の概算。

Amazon MWAA (Amazon Managed Workflows for Apache Airflow) のネットワーク構成と料金の概算。

Amazon MWAA Amazon Managed Workflows for Apache Airflow
記事タイトルとURLをコピーする

こんにちは。
長野県の燕岳に登ったところ、親子の雷鳥に出くわした山本です。とても可愛かったです。

Amazon MWAA (Amazon Managed Workflows for Apache Airflow) のネットワーク構成と料金の概算。

Amazon MWAA の検証をしています。
Amazon MWAA のネットワーク構成がいくつかあるように見えたため、整理も兼ねて本記事を執筆しています。
この記事を読むと、Amazon MWAAのネットワーク構成を整えた上で、MWAAのサービス画面から環境を作れるようになります。

この記事に書くこと

書くこと

  • Amazon MWAA の環境を作成する際の考慮点。主にネットワーク周り。
  • Amazon MWAA の環境を維持するための料金。

書かないこと

  • Amazon MWAA を用いたジョブの実行方法。他の記事で触れる予定。

Amazon MWAA のアーキテクチャ

公式ドキュメントを見ると、Amazon MWAA は以下のアーキテクチャになるようです。

ネットワーク構成

ネットワーク構成に着目すると、VPCが2つあり、左に 「Customer VPC」、右に 「Service VPC」 があります。
両者の相違点は、以下の表の通りになるようです。

VPCの種類 説明
Customer VPC Amazon MWAA を作成するときに利用者が指定するVPCで、利用者が作成・管理します。
Service VPC Amazon管理のVPCで、利用者からは見えません。

ご参考：Amazon MWAA の作成時に Customer VPCを選択する画面

Amazon MWAA のWEB管理画面を参照するための通信経路

Amazon MWAA のWEB管理画面を参照するための通信経路を確認します。
Amazon MWAA のWEB管理画面を参照するには、「Service VPC」にある 「Airflow Web Server」にウェブブラウザから接続します。
図の該当箇所：

Amazon MWAA を作成するときに、「パブリックネットワークアクセスモード」と「プライベートネットワークアクセスモード」を選べます。
図の右側が「パブリックネットワークアクセスモード」、左側が「プライベートネットワークアクセスモード」を選んだ時の通信経路です。
以下にそれぞれの説明を記載します。

ネットワークアクセスモード 説明
パブリックネットワークアクセスモード 「Airflow Web Server」 にインターネットから接続可能な VPC エンドポイントを作成します。特定のパブリックIPアドレスからの接続のみ許可することはできないようです。アイコンがALBになっている理由は今のところ不明です。おそらくドキュメントの誤記で、VPCエンドポイントではなく、ALBなのでしょう。
プライベートネットワークアクセスモード 「Airflow Web Server」 に「Customer VPC」から接続可能な VPC エンドポイントを作成します。

公式ドキュメントの該当箇所を和訳。

パブリックネットワークアクセスモードでは、インターネット経由でアクセス可能な 「Airflow Web Server」のVPCエンドポイントを提供します。
プライベートネットワークアクセスモードは、利用者が管理する「Customer VPC」からアクセス可能な「Airflow Web Server」のVPCエンドポイントを提供します。
どちらの場合も、Apache Airflowユーザーのアクセスは、AWS Identity and Access Management（IAM）で定義したアクセスコントロールポリシーとAWSSSOによって制御されます。

Airflow Web Server の VPCエンドポイント

「パブリックネットワークアクセスモード」で作成してみたところ、以下のVPCエンドポイント？(Airflow UI)が出来ました。おそらく「VPCエンドポイント」というのはドキュメントの誤記で、筆者がDNSの逆引き等を行なって確認したところ、実態はALBだと思われます。

  • xxxxxxxx.c3.ap-northeast-1.airflow.amazonaws.com

マネジメントコンソールでの確認箇所：

「プライベートネットワークアクセスモード」で作成してみたところ、以下のVPCエンドポイント(Airflow UI)が出来ました。 「Customer VPC」内から接続可能になっていました。

  • vpce-yyyyyyyyyy-yyyyyyyyyy.vpce-svc-xxxxxxxxxx.ap-northeast-1.vpce.amazonaws.com

WEBアクセストークンを発行して接続してみると以下のような画面になります。WEBアクセストークンの発行方法は後述します。

「Customer VPC」のネットワーク構成

「Customer VPC」は、Amazon MWAA を作成するときに利用者が指定するVPCで、利用者が作成・管理します。
「Customer VPC」には Amazon MWAA のサービスが、Apache Airflow Schedulers と Airflow Worker(s) の Fargate コンテナを配置します。
利用者からは、これらのFargateコンテナ群は見えません。
図の該当箇所：

Apache Airflow Schedulers と Airflow Worker(s)の Fargate コンテナ群は、以下のAWSサービスと通信します。

  • Amazon CloudWatch
  • Amazon S3
  • Amazon SQS
  • Amazon ECR
  • AWS KMS
  • Amazon MWAA (自身のサービスエンドポイント)

上述のAWSサービスと通信するために、各AWSサービス用のVPCエンドポイント、またはNATゲートウェイをVPC内に作成する必要があります。
また、「Service VPC」にある Meta Database に、「Service VPC」の提供するVPCエンドポイントを使用して通信します。この通信は利用者が意識する必要はありません。
図の該当箇所：

「Customer VPC」を1から自分で作成する際の注意点まとめ

利用者が作成・管理する「Customer VPC」を作成する際には、いくつかの制約があります。
Create the VPC networkには「Customer VPC」作成用のCloudFormationがあります。そのため、この公式ドキュメントにある CloudFormation を流用して作成すると良さそうです。
利用者が自分で作成することも考えられますので、下に制約をまとめます。

「パブリックネットワークアクセスモード」を選ぶ時

  1. VPCの「DNSホスト名」と「DNS」解決が有効になっていること。
  2. プライベートサブネットを2つ、異なるアベイラビリティゾーンに配置していること。
  3. パブリックサブネットを2つ、プライベートサブネットと同じアベイラビリティゾーン構成で作成していること。
  4. パブリックサブネットの「パブリック IPv4 アドレスを自動割り当て」を「はい」にしていること。
  5. プライベートサブネットのルートテーブルにおいて、デフォルトルート(0.0.0.0/0)のターゲットが、同じアベイラビリティゾーンのパブリックサブネットに配置したNAT ゲートウェイになっていること。

ドキュメントでの該当箇所。 VPC ネットワークの作成 - Amazon Managed Workflows for Apache Airflow

  • 必要なCIDR
    • パブリックサブネット1つ当たりのサブネットマスク
      • /28 が妥当。NATゲートウェイのみ配置するため。
    • プライベートサブネット1つ当たりのサブネットマスク
      • /26 以上が妥当。最大31個のIPアドレスを使用するため。
        • ワーカー最大25ノード、スケジューラー最大5ノード、メタデータデータベースに接続するための VPC エンドポイント1つ

「プライベートネットワークアクセスモード」を選ぶ時

上の「パブリックネットワークアクセスモード」を選ぶ時　と同じ構成でも可能です。
ただし、NAT Gateway は VPC エンドポイントよりも データ通信料金が 6倍以上もかかるため、下の構成がお勧めです。

  1. VPCの「DNSホスト名」と「DNS」解決が有効になっていること。
  2. プライベートサブネットを2つ、異なるアベイラビリティゾーンに配置していること。
  3. プライベートサブネットに以下のVPCエンドポイント 10個を作成していること。S3 はゲートウェイ型のVPCエンドポイントです。参考
    • com.amazonaws.YOUR_REGION.s3
    • com.amazonaws.YOUR_REGION.monitoring
    • com.amazonaws.YOUR_REGION.ecr.dkr
    • com.amazonaws.YOUR_REGION.ecr.api
    • com.amazonaws.YOUR_REGION.logs
    • com.amazonaws.YOUR_REGION.sqs
    • com.amazonaws.YOUR_REGION.kms
    • com.amazonaws.YOUR_REGION.airflow.api
    • com.amazonaws.YOUR_REGION.airflow.env
    • com.amazonaws.YOUR_REGION.airflow.ops

ドキュメントでの該当箇所。 VPC ネットワークの作成 - Amazon Managed Workflows for Apache Airflow

  • 必要なCIDR
    • パブリックサブネット1つ当たりのサブネットマスク
      • /28 が妥当。NATゲートウェイのみ配置するため。カスタムドメインでアクセスするためにALBを配置する場合は /27 が妥当。
    • プライベートサブネット1つ当たりのサブネットマスク
      • /26 以上が妥当。最大41個のIPアドレスを使用するため
        • ワーカー最大25ノード、スケジューラー最大5ノード、メタデータデータベースに接続するための VPC エンドポイント1つ、Airflow Web Server に接続するための VPC エンドポイント1つ、各サービスと通信するためのVPCエンドポイント 9つ

DAGファイル配置用 S3 バケット

上記のネットワーク構成に加えて、Amazon MWAA の環境を作成するには、以下のS3バケットが必要です。
事前にご準備ください。

  • すべてのパブリックアクセスをブロック
  • バージョニングが有効

Amazon MWAA (Amazon Managed Workflows for Apache Airflow) のネットワーク構成まとめ

ここまで読んで準備すると、Amazon MWAA (Amazon Managed Workflows for Apache Airflow) のサービス画面から、環境を作成できるようになっていると思います。
環境の作成はAWSマネジメントコンソールから簡単に行えますので、方法は割愛します。
ここまでの要点は以下です。

  • VPCが２種類ある。

    • １つ目の「Customer VPC」は利用者が作成・管理するVPC。
      • 「Customer VPC」は、必要なCidrや、本記事に記載した制約事項を考慮して作成する。
      • 「プライベートネットワークアクセスモード」で「Customer VPC」を作成する場合は NATゲートウェイよりもVPC エンドポイントを配置する構成の方がコストメリットがある場合が多い。
      • 「Customer VPC」には、Apache Airflow Schedulers と Airflow Worker(s) の Fargate コンテナを配置。利用者からは、これらのFargateコンテナ群は見えない。
    • ２つ目の「Service VPC」はAmazon管理のVPCで、利用者からは見えない。
      • 「Service VPC」には、Airflow Web Server と Meta Database を配置。

  • 管理画面への接続について、「パブリックネットワークアクセスモード」と「プライベートネットワークアクセスモード」から選ぶ。

    • 「パブリックネットワークアクセスモード」は基本的にインターネット公開になる。
      • IPアドレス等で制限する場合は「プライベートネットワークアクセスモード」を選択する。

  • DAGファイル配置用 S3 バケットを作成し、パブリックアクセスは無効、バージョニングを有効にしておく。

Amazon MWAA のWEB管理画面をカスタムドメインで参照する（おまけ）

Amazon MWAA のWEB管理画面に自身の管理するドメインを用いて接続する方法です。
質問集(FAQ)にある「Amazon MWAA はカスタムドメインをサポートしていますか？」を参照すると、以下の方法があります。

ネットワークモード 方法
パブリックネットワークアクセスモード カスタムドメインへの接続をAmazon MWAA のWEB管理画面に転送するように、CloudFront を構成します。CloudFront には AWS Lambda@Edge を関連付けします。Lambda@Edge はユーザーリクエストを Amazon Cognito に転送し、ユーザー認証を行わせてから CloudFront に転送します。 サンプルコード
プライベートネットワークアクセスモード カスタムドメインへの接続をAmazon MWAA のWEB管理画面に転送するように、Application Load Balancer (ALB) を構成します。ドキュメント

プライベートネットワークアクセスモードを使用している時に、Amazon MWAA のWEB管理画面をカスタムドメインで参照する

Application Load Balancer (ALB) を使って、手軽にできそうなので、やってみました。
Application Load Balancer (ALB) を使うと、セキュリティグループで特定のパブリックIPアドレスからの接続のみ許可できます。
「Using a Load Balancer (advanced)」を参考にやってみました。
構成イメージ：
前提としまして、Customer VPC に パブリックサブネット(緑のサブネット)を ２つ作成し、Application Load Balancer (ALB)を配置することにしました。

さて、作成していきましょう。
まず、Amazon MWAA のサービス画面から、Airflow UI をメモします。

この UI の URL を nslookup コマンド等で参照すると、Airflow Web Server のIPアドレスを２つ得ることができます。
※ドキュメントでは３つほど手順を踏んで、同じ結果を得ているようでした（理由は不明）。
以下のように結果を得ることができます。

Address: 10.192.20.95
Address: 10.192.21.131

EC2 サービスの画面でターゲットグループを作成します。

  • ターゲットの種類：IP
  • プロトコル : ポート：HTTPS: 443
  • プロトコルバージョン：HTTP1

Airflow Web Server のIPアドレス２つをターゲットに登録します。

ヘルスチェックの「成功コード」に 302 を追加します。(200,302 という形。カンマ区切り。)

Application Load Balancer (ALB) を作成し、ポート番号：443のリスナールールの転送先を先ほど作成したターゲットグループにします。

Application Load Balancer (ALB) に付けたセキュリティグループのインバウンドルールに 利用者のパブリックIPアドレスからの HTTPS 接続を許可します。

EC2 サービスの画面にある「ネットワークインターフェイス」の画面に行きます。
Airflow Web Server のIPアドレス ２つに紐づくネットワークインターフェイスを探します。
そして、ネットワークインターフェイスについているセキュリティグループ を確認します。

Application Load Balancer (ALB) に上のセキュリティグループを追加します。
このセキュリティグループのインバウンドルールには、同セキュリティグループからの全てのトラフィックを許可するルールがあります。これにより、ALBとターゲットグループ内のAirflow Web Server のIPアドレス ２つとの疎通を可能にします。

最後に、Application Load Balancer (ALB) に証明書を登録し、DNSレコードを設定すると、独自ドメインでアクセスできます。
筆者は Route 53 に適当なホストゾーンを作成しました。
Aレコードのエイリアス機能で ALB をレコードに登録しました。
証明書は AWS Certificate Manager (ACM)の無料証明書を使用しました。

カスタムドメインでアクセスできました。

Amazon MWAA のWEB管理画面へのログイン

Amazon MWAA のWEB管理画面にログインするには、IAMユーザーにAmazon MWAAの操作権限が必要です。
必要なIAMポリシーの詳細については、Amazon MWAA 環境へのアクセスをご参照ください。
Amazon MWAAの操作権限を持つ IAMユーザーで、AWS CLI を実行して、WEB管理画面へのログイントークンを発行し、ログインできます。
筆者は「Apache Airflow ウェブログイントークンの作成」を参考に以下のシェルスクリプトを作成し、ログインURL を発行しました。

#!/bin/bash
ENVNAME="MyAirflowEnvironment001" #Amazon MWAAの環境名
HOST="mwaa.karukozaka46.click" #Airflow UI のカスタムドメイン名
YOUR_URL=https://$HOST/aws_mwaa/aws-console-sso?login=true#
WEB_TOKEN=$(aws mwaa create-web-login-token --name $ENVNAME --query WebToken --output text)
echo $YOUR_URL$WEB_TOKEN #ログインURL

料金

料金につきましては、以下の公式ドキュメントに記載があります。

Amazon Managed Workflows for Apache Airflow (MWAA) の料金 – アマゾン ウェブ サービス

例としまして、東京リージョンで、スモールサイズを作成し、Airflow Worker(s) 1台、 Apache Airflow Schedulers 1台を運用した場合の表を掲示します。つまり、最小構成のときです。

料金種別 計算式 月額(ドル。小数点以下を四捨五入。) 月額(円。小数点以下を四捨五入。 ※1ドル 130円で換算した時。)
環境インスタンス料金 0.49USD × 24 時間/日 × 31 日間 364.56 USドル 47,393円
Airflow Worker(s) 1台の料金 追加していないため、なし。追加すると料金が発生する。 0 USドル 0円
Apache Airflow Schedulers 1台の料金 追加していないため、なし。追加すると料金が発生する。 0 USドル 0円
合計 - - 47,393円

しかし、検証しつつ、サポート問い合わせもしながら調べてみると、上に書いてある料金の他に、以下の料金もかかってくるようでした。

  • Apache Airflow Schedulers と Airflow Worker(s)の Fargate コンテナ群が、AWSサービスと通信する際の通信料金
  • Airflow Web Server への通信料金
    • プライベートネットワークアクセスモードの場合のみ

上記がどれくらいの料金になるのか、私の検証環境で調べてみました。 後者のAirflow Web Server への通信料金はおそらく微々たるものになるので、検証は省略しました。

Apache Airflow Schedulers と Airflow Worker(s)の Fargate コンテナ群が、AWSサービスと通信する際の通信料金

上に紹介した『「パブリックネットワークアクセスモード」を選ぶ時』のネットワーク構成で、NATゲートウェイの通信料金を料金を見てみることにしました。
ネットワーク構成図：

東京リージョンで、スモールサイズを作成し、Airflow Worker(s) 1台、 Apache Airflow Schedulers 1台を動かしています。ジョブは動かしていません。
そうしたところ、NATゲートウェイの料金は以下のようになりました。

  • 通信料金(データ処理料金)が１日あたり１０ドル発生。日本円では１日あたり１,３００円。ひと月あたり、３９,０００円。通信量は１日あたり１６２GBだった。
  • NAT ゲートウェイの時間料金 が発生。ひと月当たり ９２ドル。日本円ではひと月あたり、１１,９６０円。

参考：NAT ゲートウェイの料金

上記を踏まえると、表は以下のようになります。
通信料金の割合が大きくなるのがわかります。

料金種別 計算式 月額(ドル。小数点以下を四捨五入。) 月額(円。小数点以下を四捨五入。 ※1ドル 130円で換算した時。)
環境インスタンス料金 0.49USD × 24 時間/日 × 31 日間 364.56 USドル 47,393円
Airflow Worker(s) 1台の料金 追加していないため、なし。追加すると料金が発生する。 0 USドル 0円
Apache Airflow Schedulers 1台の料金 追加していないため、なし。追加すると料金が発生する。 0 USドル 0円
Customer VPCに配置するNATゲートウェイの料金 402USドル 50,960円
合計 - - 98,353円

スモール環境の維持で、年額 120万円くらいと推定できます。

NATゲートウェイをVPCエンドポイントに置き換えると・・・。

では、上に紹介した『「プライベートネットワークアクセスモード」を選ぶ時』のネットワーク構成の場合、どうなるでしょう。
ネットワーク構成図：

NATゲートウェイの通信量は１日あたり１６２GBでしたので、同じ通信量をVPCエンドポイントが処理したとします。こちらは机上です。

内訳として、S3のVPCエンドポイントのみ、ゲートウェイ型のVPCエンドポイントになります。
ゲートウェイ型のVPCエンドポイントは、通信量や時間料金がありません。

ゲートウェイタイプの VPC エンドポイントを設定し、NAT ゲートウェイを経由せずに、VPC エンドポイントを経由して S3 との間でトラフィックをルーティングできます。ゲートウェイタイプの VPC エンドポイントの使用に対するデータ処理料金や時間単位料金は発生しません 参考：料金 - Amazon VPC | AWS

他の ９個のVPCエンドポイントには、通信量や時間料金がかかります。 参考：料金 - AWS PrivateLink | AWS
以上の前提から、以下に推算をしてみます。
９個のVPCエンドポイントは、２つのプライベートサブネットに冗長化して配置するため、実際には１８個です。

  • 仮に、インターフェイス型のVPCエンドポイントで１日あたり１６２GBを処理した場合は、１日あたり１.６２ドル発生。日本円では１日あたり２１１円。ひと月あたり、６,５４１円。
  • １８個のインターフェイス型のVPCエンドポイントの時間料金はひと月あたり１８７ドル発生。日本円ではひと月あたり、２４３７３円。

上記を踏まえると、表は以下のようになります。

料金種別 計算式 月額(ドル。小数点以下を四捨五入。) 月額(円。小数点以下を四捨五入。 ※1ドル 130円で換算した時。)
環境インスタンス料金 0.49USD × 24 時間/日 × 31 日間 364.56 USドル 47,393円
Airflow Worker(s) 1台の料金 追加していないため、なし。追加すると料金が発生する。 0 USドル 0円
Apache Airflow Schedulers 1台の料金 追加していないため、なし。追加すると料金が発生する。 0 USドル 0円
Customer VPCに配置するVPCエンドポイントの料金 237USドル 30,914円
合計 - - 78,307円

スモール環境の維持で、年額 95万円くらいと推定できます。

VPCエンドポイントを利用する方が、料金を抑えることができそうです。

まとめ。

だいぶ沢山書きましたので、簡単なまとめを作っておきます。

  1. Amazon MWAAには「Customer VPC」と「Service VPC」があり、前者は利用者が作成、管理する。
  2. Amazon MWAA の WEB管理画面 (Airflow Web Server) には、インターネット経由で接続する「パブリックネットワークアクセスモード」、「Customer VPC」経由で接続する「プライベートネットワークアクセスモード」がある。
  3. 「Customer VPC」の作成に関しては注意点があるため、本記事を参考にしてもらえると嬉しい。
  4. 「プライベートネットワークアクセスモード」を選ぶ場合のみ、「Customer VPC」のNATゲートウェイを VPCエンドポイントに置き換えることができる。
  5. Amazon MWAA のWEB管理画面をカスタムドメインで参照することもできる。
  6. 環境作成には、DAGファイル配置用 S3 バケットが必要。パブリックアクセスは無効、バージョニングを有効にしておく。
  7. Amazon MWAA のWEB管理画面へのログインはIAMユーザー／IAMロールで認証する。ログインにはWEBログイントークンが必要。IAMユーザー／IAMロールには適切な権限が必要。
  8. 料金は、公式ドキュメントに記載の料金のほか、「Customer VPC」における通信料金が発生する。「プライベートネットワークアクセスモード」の場合は、「Customer VPC」のNATゲートウェイを VPCエンドポイントに置き換える方が料金を抑えることができる。
  9. 料金は最小構成（スモールサイズを作成し、Airflow Worker(s) 1台、 Apache Airflow Schedulers 1台を運用した場合）、「パブリックネットワークアクセスモード」なら 年額120万円前後、「プライベートネットワークアクセスモード」なら年額95万円前後と推定。

書かなかったこと。

Amazon MWAA を用いたジョブ実行の方法。また別記事で書こうと考えています。
「Customer VPC」に必要な CIDR サイズ。わかり次第追記します。 →記載済み。

山本 哲也 (記事一覧)

カスタマーサクセス部のインフラエンジニア。

山を走るのが趣味です。

"; doc.innerHTML = entry_notice + doc.innerHTML; }
' } }) e.innerHTML = codeBlock; });