こんにちは！
BFT名古屋支店の佐野です。
とある案件において「DirectConnectで社内ネットワークと接続しているVPC(VPC A)に、VPC Aを持つアカウントとは異なるAWSアカウントが持つ別のVPC(VPC B)をピアリングし、社内ネットワーク内にあるZabbixにVPC BのCloudWatchログ情報を送ることはできないか」という質問をお受けしました。
具体的に図にすると、以下のような経路でネットワークを構築できないか、VPC AとVPC Bの監視を一本化できないか、というのが要件でした。
この質問に対して行った回答とその解説、そしてそれを踏まえてBFTが提示した案について、お送りしたいと思います。
はじめに：VPCピアリングの制限
まずVPCピアリングにはいくらかの制限があり、そのひとつに「ゲートウェイまたはプライベート接続経由のエッジツーエッジルーティングはできない」というものがあります。
簡単に言えば、VPC Bとピアリングした関係にあるVPC Aに接続できる外部の端末から、VPC Aに直接接続するということはAWSの仕様上できないのです。
以下のVPCピアリングの制限に関するAWS公式ドキュメントには、今回のようにDirectConnectを使用する場合の他、インターネットゲートウェイなどを使用した場合にも同様に制限される旨が記載されています。
これは逆の通信経路でも同じことが言えるため、以下のように「VPC BからVPCAを経由して、直接外部の端末と通信する」というのも、現状のAWSの仕様では不可能ということになります。
このため、VPCピアリングではお客様が想像していた「VPCピアリングによって各VPCのCloudWatchログの監視をZabbixにまとめる」という方法はできないという答えを出さざるを得ませんでした。
ただ、今回の要件はあくまで「各VPCの監視をZabbixにまとめる」ことです。
であれば、VPCピアリングを使わずとも実現することは可能であるため、お客様にはその方向で２つの提案をすることになりました。
プランA：Amazon Kinesisを使ってVPC BのログをVPC Aに共有する
こちらは「VPC BとVPC Aの監視をひとつのVPCに一本化したい」場合に有用なパターンになります。
VPC Bで取得したCloudWatchログをKinesis Data StreamsでVPC AのCloudWatchに送り、VPC Aで出力されたログと一括してVPC Aにて監視を行ないます。
このパターンの構成図は以下の通りです。
またVPC Aのログについても同様となりますが、Kinesis Data StreamsでVPC Bから送られたログの中にエラーログや監視対象となるログが出力された場合、
CloudWatchのサブスクリプションフィルターやメトリクスフィルターによって検知し、それをトリガーとしてLambdaによってZabbixに送信する形を取っています。
このパターンではDirectConnectだけでなく、VPNを用いる場合においても１つのVPCで監視を行なえます。
ただしVPC Bで管理することになるKinesis Data Streamsから、異なるアカウントに存在するVPC Aにログを送信するための設定がAB双方のVPCで必要となるため、作業数はやや多めとなります。
もし今回のようにDirectConnectを使う前提であるならば、後述する「ひとつのDirectConnectを複数のVPCで共用する」方法がおすすめです。
プランB：ひとつのDirectConnectを複数のVPCで共用する
こちらはZabbixを擁する閉域網に繋がるDirectConnectを、複数のVPCと関連付けることで実質的な監視の一本化を実現するパターンになります。
DirectConnectの利用が前提ですが、「各VPCのCloudWatchログの監視をZabbixにまとめる」という目的を達成するなら一番簡便な方法となります。
この場合、ログをZabbixに送信するためのLambdaをVPC A、VPC Bの双方で用意します。
DirectConnectに関連付けられるVPC、ひいては仮想インターフェイスの数には制限がありますが、最大数が50となっている為、よほど大規模なシステムでなければひとつのDirectConnectで賄うことができるかと思います。
またAmazon Kinesisを使う場合と比べ、VPCひとつ分のLambdaを増やすことになりますが、Lambdaは実行時に課金される仕組みであり、あまりにも実行回数が多くない限りコスト的にも優位と言えます。
お客様には双方のプランを提示し、今回の案件に適するのはプランBであること説明し、結果的プランBを採用して頂きました。
さいごに
今回はVPCピアリングを使うことなく、今回の要件たる「監視の一本化」を実現するという方向で事を進めていきました。
しかし、もしVPCピアリングを行なうことが必須の環境で、同様の要件を満たさなければならない場合は、VPCピアリングの制限事項である「直接外部の端末と通信する」を回避しつつ、エッジツーエッジルーティングのような通信を実現する必要があります。
その一例として、ピアリング先となるVPCに中間マネージャや中継用プロキシーサーバを建て、データ送信時にそれらを介して閉域網への通信を行なうという方法があります。
具体的な構成例は以下になります。
この構成であれば閉域網に直接通じていないVPCからピアリングしたVPCを通じて閉域網に疎通することができますが、Zabbixの仕様を考慮してLambdaと中継用のサーバーを構築する必要があり、また中継サーバーを建てる際にEC2インスタンスを使用する必要があります。
その場合、当然ながらEC2インスタンスのスペックと起動時間に応じた料金が発生し、監視を担うものである都合上、常時起動が前提となります。
コストも開発工数も、この記事で挙げたどのプランよりも高騰するため、オススメはしにくい方法となります。
もしも同じような要件で複数のVPCの監視を一本化したいような場合に、今回の記事で紹介した情報がお役に立てば幸いです。
