トップ > VPC Lattice > Amazon VPC Lattice解説（概要および構成要素編）

Amazon VPC Lattice解説（概要および構成要素編）

VPC Lattice AWS
記事タイトルとURLをコピーする

エンタープライズクラウド部の山下(祐)です。

Amazon VPC Lattice（以下、Lattice）がGAしましたので、調査・検証してみました。その内容について、何回かに分けてご紹介したいと思います。

今回は、Latticeの概要、および構成要素について説明します。

留意事項

LatticeについてはGA直後のサービスということもあり、今後頻繁にアップデートが発生する可能性があります。

本ブログは2023年4月時点の調査内容に基づき記載しておりますが、比較的早く、内容が古くなる可能性がありますので、予めご了承いただければ幸いです。

Latticeとは

アプリケーション間の接続を簡略化するためのサービス

Latticeについて、公式ドキュメントでは以下のように説明されています。

Amazon VPC Lattice は、複数のアカウントや仮想プライベートクラウド (VPC) にわたるすべてのサービスの接続、保護、監視に使用できる、完全マネージド型のアプリケーションネットワーキングサービスです。

最新のアプリケーションは、マイクロサービスと呼ばれることが多い、複数の小規模でモジュール化されたサービスで構成されます。近代化には利点がありますが、レガシーサービスに関連するネットワーキングが複雑になり、課題が生じる可能性もあります。これは多くの場合、これらのアプリケーションを構築する開発者がさまざまなコンピューティングニーズを持つさまざまなチームに分散しているためです。その結果、複数のアカウント、VPC、あるいはその両方にまたがってマイクロサービスを構築してデプロイします。

Amazon VPC Lattice は、マイクロサービスとレガシーサービスを論理的な境界内で相互接続するのに役立ち、より効率的に検出して管理できます。

docs.aws.amazon.com

つまり、VPCをまたいだアプリケーション間の接続を簡略化する、マイクロサービスアーキテクチャ向けのマネージドサービスということのようです。 上述の公式ドキュメントで「アプリケーション ネットワーキング サービス」と呼称している通り、あくまでアプリケーション間の通信をターゲットにしたサービスのようです。

その辺りは、サポートしているプロトコルからも伺えます。 下記の公式ドキュメントに記載の通り、2023年4月時点でサポートしているプロトコルは以下です。

  • HTTP
  • HTTPS
  • gRPC

VPC 内の専用データプレーンを通じて、HTTP/HTTPS および gRPC プロトコルを介した接続を提供します。

aws.amazon.com

管理通信用のTransit Gatewayを代替するサービスではない

上記の説明から分かる通り、Latticeは、「踏み台サーバから各サーバへのSSH/RDPログイン」や「監視サーバからの監視通信」などの、管理/運用通信をターゲットにしたサービスではないようです。

AWS Transit Gatewayを使用して、VPC間で上記の通信を行うための設定をしているケースは多いと思いますが、それに取って代わるものではない、とご理解いただければと思います。

Latticeの概要が掴めたので、ここからは各構成要素を見ていきます。

Latticeの構成要素

全体構成概要

Latticeは、サービス・サービスネットワーク・ターゲットグループという3つのコンポーネントにより構成されています。

個々の構成要素の説明に入る前に、ザックリと全体構成について図示します。それぞれのコンポーネントの関係性・動作イメージは下図のようになります。

何となく全体の構成が掴めたところで、各コンポーネントの説明に移ります。

Service（サービス）

※これ以降、本ブログで記述する「サービス」という単語は、全てLatticeのコンポーネントとしての「サービス」を指します。

サービスは、クライアントアプリケーションからのリクエストを認証・承認し、ターゲットアプリケーションにルーティングするためのコンポーネントです。

サービスという名称が少々分かりづらいのですが、ターゲットアプリケーションそのものを指しているわけではありません。 端的に言えば、Application Load Balancer（以下、ALB）のような役割を果たすものです。

サービスでは、主に以下の設定を行います。

名称 概要
ドメイン クライアントアプリケーションが送信先に指定するドメイン。カスタムドメインの設定も可能。
サービスアクセス クライアントアプリケーションをIAMおよび認証ポリシーで認証する。（※省略可能）
ルーティング（リスナー） リクエストを受け付けるプロトコル・ポート番号と、ルーティング先を決定する

リスナーは、ALBと同じですね。 ドメインについても、ALBが独自のDNS名を持っているのに近いイメージです。


アクセスについては、以下の2種類の認証が使用可能なようです。（※アクセスについては未検証のため、改めて検証してブログにしたいと思います。）

種別 概要
IAM クライアントアプリケーションに紐づくIAMロールまたはクレデンシャルによる認証
認証ポリシー リソースベースのポリシーによる認証


以下は、サービスの設定画面のサンプルです。リスナーによるルーティング設定は、ALBを利用している人には馴染み深いかと思います。

Service Network（サービスネットワーク）

サービスネットワークは、サービスとVPCを関連付けるためのコンポーネントです。

サービスネットワークに関連付けられたVPCは、「そのサービスネットワークに関連付けられているサービス」にリクエストを送信することが出来ます。（ただし、アクセス設定で認証・承認されなければ、サービスはリクエストを受け付けません。）

サービスネットワークでは、以下の設定を行います。

名称 概要
サービスの関連付け サービスネットワークに所属させるサービス。VPCからのリクエストを受け付ける。
VPCの関連付け サービスネットワーク内のサービスにリクエストを送信できるVPC。
セキュリティグループ VPCからサービスネットワークへのインバウンドトラフィックを制御する。
ネットワークアクセス クライアントアプリケーションをIAMおよび認証ポリシーで認証する。（※省略可能）

ネットワークアクセスの設定方法は、サービスアクセスと全く同じです。


以下は、サービスネットワークの設定画面のサンプルです。少し分かりづらいですが、VPCの関連付けの設定の中に、セキュリティグループの指定もあります。

Target Group（ターゲットグループ）

ターゲットグループも、ALBのものと同じイメージです。 サービスのルーティングで設定された、宛先となるアプリケーションインスタンスや、その前段のALB等です。

ALBのターゲットグループ設定と異なる点は、ターゲットとなるVPCを指定する点くらいでしょうか。

ターゲットグループの設定画面のサンプルを載せます。ターゲットがデプロイされているVPC・ターゲットグループを使用するサービス・ターゲットのALBが設定されていることが分かります。

全体構成図

上記の説明を踏まえて、改めて、Latticeの全体構成図を図示します。左から右に向かってリクエストが流れるイメージです。Latticeの中で、アクセス制御・認証/承認・ルーティングを一括して実施可能な事が見て取れます。

補足・注意点

ここでは、Latticeを利用するうえで個人的に少々分かりづらいと感じた箇所について、補足します。

①アクセス制御はサービスネットワークとターゲットVPCで行う

Latticeを介したアクセスを行う場合、以下のセキュリティグループでアクセス制御が行われます。

  • サービスネットワークにVPCを関連付ける際に設定するセキュリティグループ
  • ターゲットグループに設定されたALBやEC2にアタッチされたセキュリティグループ

双方のセキュリティグループで許可設定されていないとアクセスできません。

②宛先となるVPCはサービスネットワークに関連付ける必要はない

前述した通り、宛先となるVPCはターゲットグループで指定します。サービスネットワークに関連付けが必要なのは、送信元となるVPCのみで問題ありません。 ただし、相互にリクエストを送りあう場合は、双方をサービスネットワークに関連付ける必要があります。

③クライアントのリクエスト送付先は、サービスのドメインになる

クライアントがリクエストするドメインは、ターゲットのALB等のドメインではなく、サービスのドメインとなります。 デフォルトでは「xxxxx.vpc-lattice-svcs.ap-northeast-1.on.aws」といったドメイン名ですが、カスタムドメインを設定することも可能です。

④VPC内のルートテーブルに、サービスネットワーク向けのルートが自動で設定される

VPCをサービスネットワークに関連付けると、ルートテーブルに、サービスネットワーク向けのルートが自動で設定されます。 手動でルート設定を行う必要はありません。

リンクローカルアドレス、ユニークローカルアドレスが使われているようです。Latticeでは送信元と宛先のVPCでCIDRが重複していても通信が可能ですが、この辺のルーティング設定も関係していそうです。

補足・注意点まとめ

最後に、①～④をまとめて図示します。

検証してみた

ここからは、実際にLatticeを使った通信の検証をしてみたいと思います。

検証環境説明

今回は、あるVPC上のECS（Fargate）にデプロイしたWEBアプリ（前段にALBあり）に、別のVPCのEC2からアクセスしてみました。 両VPCともプライベートサブネットのみで構成し、インターネット経由でのアクセスが出来ないようにしてあります。 （EC2とSSMの通信用、ECSとECRの通信用、ECSとCloudWatchの通信用に、VPCエンドポイントも作成しています。）


サービスネットワーク（vpc-lattice-test）に、検証用のサービス（lattice-test-service）と、送信元のVPC（vpc-0cb205ae1e38a7037）を関連付けます。


ターゲットグループ（lattice-test-target-alb）に宛先VPC（vpc-022df288e77cc2f1f）のALB（lattice-test-alb）を指定します。


サービスのルーティング設定で、HTTP:80のリスナーを作成します。デフォルトアクションで、全てのトラフィックを lattice-test-target-alb に転送します。


サービス・サービスネットワークともに、アクセス設定は行いませんでした。

EC2からLattice経由でWEBサービスにアクセスしてみる

それでは、クライアントのEC2にセッションマネージャーでログインし、WEBサービスへのアクセスを試みます。 クライアントがcurlするのは、Latticeのサービスのドメインであることに注意してください。

sh-4.2$
sh-4.2$
sh-4.2$ curl -v http://lattice-test-service-xxxxxxxxxxxxxxxxx.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws/
*   Trying 169.254.171.96:80...
* Connected to lattice-test-service-xxxxxxxxxxxxxxxxx.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws (169.254.171.96) port 80 (#0)
> GET / HTTP/1.1
> Host: lattice-test-service-xxxxxxxxxxxxxxxxx.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 200 OK
< date: Fri, 07 Apr 2023 06:47:24 GMT
< content-type: text/html; charset=utf-8
< content-length: 238
< server: Werkzeug/2.2.3 Python/3.11.3
<
<!DOCTYPE html>
<html>
    <head>
        <link rel="stylesheet" href="../static/base.css">
        <title>VPC Lattice 検証</title>
    </head>
    <body>
        <h1>VPC Lattice検証用のWEBページです。</h1>
    </body>
* Connection #0 to host lattice-test-service-xxxxxxxxxxxxxxxxx.7d67968.vpc-lattice-svcs.ap-northeast-1.on.aws left intact
</html>sh-4.2$

無事にアクセスできました。

個人的に嬉しいと感じたポイント

Latticeに関する利点はいくつかあると思いますが、個人的には以下の点が特に嬉しい点と感じました。

手動でのルーティング設定が不要

上述通り、VPC内のルートテーブルの手動設定が不要となります。 「情報システム部のインフラ部門がアプリ開発部門の要望で、都度ネットワークを設定を行う。」といった運用をしているケースもあるかと思いますが、そういった運用が不要となるため、インフラ部門の負荷軽減、アプリリリースのスピード向上が期待できます。

VPCのCIDRが重複していても問題ない

Latticeでは、送信元VPCと宛先VPCのCIDRは重複していても通信が可能です。 本来であれば、VPCのCIDRは重複しないように適切に管理されることが望ましいですが、企業の買収や合併に伴い、やむを得ずCIDRが重複するケースもあるかと思います。そのような場合に、CIDRの重複を気にしなくて済むことはありがたいですね。


以上、Latticeの概要、および構成要素についてでした。 次回以降は、Latticeのログやアクセス設定について見ていきたいと思います。

このブログが少しでも参考になれば幸いです。

山下 祐樹(執筆記事の一覧)

2021年11月中途入社。前職では情シスとして社内ネットワークの更改や運用に携わっていました。 2023 Japan AWS All Certifications Engineers。