しばらくぶりにApache Airflowについての調べ物です。
今回はAmazon Managed Workflows for Apache Airflow、略してMWAAの公式リファレンス原文にあたりました。
かなり端折ったかたちですが抄訳を載せておきます（末尾に「そもそもなんで原文にあたるんだ」の説明アリ）。

MWAAとは？

Apache Airflowを自動で構築・運用するマネージド・サービス。
大規模なエンドツーエンドのデータパイプラインを構築し運用するのを容易化。
MWAAを使用することで、ユーザー開発者はスケーラビリティや可用性、セキュリティのためにインフラストラクチャの管理をすることなしに、AirflowとPythonによりワークフローを作成できる。
MWAAはワークフロー実行に必要なキャパシティに合わせて自動的にスケール、ワークフローをAWSの提供するセキュリティ・サービスと統合、それにより迅速かつ安全な方法でデータにアクセスする手助けを提供。

MWAAの機能／特徴

Airflowワークロードを自動構築 – サポートしている複数のAirflowバージョンが1つを選択、速やかに環境構築をすることができる。Amazon MWAAは画面もその裏側も使い慣れたApache Airflowそのまま。
自動スケーリング – ワーカー数の最小と最大を設定することでワーカーノードを自動スケール。
組み込みの認証 – IAMでアクセス制御ポリシーを定義、Apache AirflowのWebサーバー（WebUIを提供）に関してロールに基づく認証認可。
組み込みのセキュリティ – ワーカーとスケジューラーはAmazon MWAAのVPC内で稼働。データはKMSを用いて自動的に暗号化。デフォルトでセキュアな環境となる。
パブリックもしくはプライベートなアクセスを選択可能 – Apache AirflowのWebサーバーへのアクセス方法は二択。Public networkアクセス・モードはインターネットを経由してアクセス可能なエンドポイントを提供。Private networkアクセス・モードはVPC内でのみアクセス可能なVPCエンドポイントを提供（推奨）。どちらの場合も、接続はIAMとAWS SSOで定義されたアクセス制御ポリシーにより制限される。
アップグレードとパッチ適用の効率化 – Amazon MWAAは定期的にApache Airflowの新バージョンを提供。Amazon MWAAチームがアップデートとパッチの適用を担う。
ワークフロー監視 – CloudWatchでApache Airflowのログとメトリクスを閲覧し、タスクの遅延やワークフローのエラーを特定できる。
AWSとの統合 – Amazon Athena、AWS Batch、Amazon EKS、Amazon Kinesis Data Firehose、AWS Glue、AWS Lambda、Amazon Redshift、Amazon SQS、Amazon SNS、Amazpn SageMaker、そしてS3のほか、オープンソース・コミュニティが提供する多数のオペレーターとセンサーを組み込みで提供。
ワーカー・フリート – Amazon ECS on AWS Fargateを使用し、ワーカー・フリートをスケーリング。ECSのコンテナでタスクを実行するオペレーターだけでなく、KubernetesクラスターのPods上でタスクを実行するオペレーターもサポート。

MWAAのアーキテクチャ

下図において多数のコンポーネントを内包する外側の枠囲いがAmazon MWAAの1環境に対応。
Apache Airflow のスケジューラーとワーカーはプライベート・サブネット内のAWS Fargateコンテナとして稼働。
各環境はAWSにより管理されるメタデータのDBを持ち、スケジューラーとワーカーはプライベートなVPCエンドポイント経由でそこにアクセス。

（リファレンスよりそのまま転載）

利用可能なリージョン、サポートされるバージョン

東京リージョン（ap-northeast-1）を含む15リージョンで提供。大阪は含まれない。
MWAAで利用できるApache Airflowバージョンは v2.2.2 が最新（2021年11月リリース）。
v1 系サポートもあるが、「マルチスケジューラの利用には v2 系を利用すべし」と可用性に関する注釈あり。

所感

AWS上で動かすならばAWSのサービスとの統合は（あって当たり前だが）うれしい要素。
推奨構成のPrivate networkアクセスモードで利用するVPCエンドポイントはおそらくIF型だろうからDXやVPNで接続した社内NWからもそのままアクセス可能なはず？
構築時のウィザードでMWAA用のVPCを作成することになる（既存利用もできはするみたい）が、そのようにあえて内部実装的なものを露出させている理由はどこにあるのか？ S3やDynamoDBのような完全にクローズドな形でもよかったのでは？
v2.2.2 が最新というのが少し気になっていて、最新の v2.5 はさすがにないとしても v2.4 くらいはサポートしていてくれるとうれしいのだが。。（思わず資料でなく管理コンソール側を確認してしまった）
日本語ドキュメントもひどいが英語（原文）ドキュメントもひどい。いったいどうしたの？という気分。

　　＊＊＊

よだん─MWAAのリファレンス原文にたどり着くまで

これまでいくつかの記事でも紹介してきたAirflowはオープンソースのワークフローエンジンです。
Pythonでコードされており、ワークフローとその内部で実行するタスクもPythonコードで記述します。
Airflowを構成する各コンポーネントを独自にデプロイしてもよいのですが、Dockerコンテナによる構築と運用、そしてとくにKubernetesクラスタ上での構築と運用がサポートされており、公式リファレンスでも推奨されています。

K8sのためのパッケージ管理システムHelmChartを使えば構築も楽々、ワークロードの弾力性とコスト効率化のためにもK8sは優れた選択肢。
しかしKubernetesクラスタはその運用のしんどさ（頻繁なアップグレードに耐えうる体制構築と維持、そしてオペレーションを遂行できるスキルレベルの維持の大変さ）が有名。
であるならばEKSやGKEのような製品を選びたい。
そしてもし可能ならばAirflow自体マネージド・サービスとして提供されているものを選びたい。
そこで、MWAA、Amazon Managed Workflows for Apache Airflowです。

原文にあたったのは、AWS公式リファレンスの日本語が崩壊しているからです（2022/12/05現在）。
冒頭からこの調子です：

Amazon Managed Workflows for Apache Airflow (MWAA) は、Apache Airflowこれにより、セットアップと操作が簡単になります end-to-end クラウド内の大規模なデータパイプライン。

そこで、原文です。
読んでみて分かったのは、原文の英語もそうとうな「難文」であること。機械翻訳がうまくいかないのもうなずける内容。英語は苦手なので上手下手は云々しませんが。。

かくして、こうして抄訳を載せておくのも悪くなかろうと思った次第です。