この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは。大阪オフィスの林です。
2019年12月02日〜2019年12月07日で、アメリカのラスベガスにてAWS re:Invent 2019が開催されています！この記事は「Simplify your AWS Cloud scale network with VPC sharing」セッションに参加したレポートです。
セッション概要
SharedVPCは、マルチアカウントAmazon Virtual Private Cloud（Amazon VPC）管理への新しいアプローチとして2018年に開始されました。本番環境でSharedVPCを採用して以来、開発チームはこれまで以上に速く動いています。このセッションでは、いくつかのベストプラクティスについて聞いてください。アトラシアンのゲストスピーカーが、簡素化されたSharedVPCモデルによって管理作業を削減した方法について説明します。
セッションスライド・動画
セッション形式
| 時間 | 1h |
| セッションタイプ | Session |
| スピーカー |
会場の雰囲気はこんな感じです。
VPC Sharing
複数のVPCを使うメリットとデメリットは？
「VPC Sharing」を説明する前に、そもそも複数のVPCを使うメリットとデメリットを説明したいと思います。
| メリット |
|
| デメリット |
|
デメリットを解消するために
「VPC Sharing」を利用することでこれらのデメリットを解消することができます。「VPC Sharing」によってAWSアカウント間でVPCネットワークを簡単に共有することができ、ネットワークエンジニア向けに対しても集中監視と制御が提供されます。
VPC Sharingの特徴
「VPC Sharing」は、AWS組織内の複数のAWSアカウントでVPCを共有できるようにするのに加え以下のような特徴があります。
-
ネットワークエンジニア向け
ネットワークエンジニアのための中央監視と制御を提供します。
-
開発者向け
ネットワークを考慮する必要なくアプリケーション開発を行えます。
-
エッジ接続
VPNおよびDirect Connectで接続できます。
単一の大きなVPCを作成して組織全体と共有するのを避け、代わりにAWS Transit GatewayやAWS Privatelinkを使用することによってVPC Sharingを使用します。
実際どのように機能するか？
実際どのように機能するのかを示したイメージが下記となります。
今回はこの中から「Subnet Sharing」「Resource Access Manageer」「Security Group and NACLs」にスポットを当てて説明をしていきます。
Subnet Sharingの特徴
「Subnet Sharing」の特徴となります。今回は3つ特徴が挙げられていました。
- 「所有者」は、すべてのVPCレベルのリソース、ルーティング、およびNACLxを設定する責任がある。
- 「参加者」は、リソース（EC2、RDS、RLBなど）の作成、管理、および削除に責任を負う。
- 「参加者」は、別の参加者が実行するリソースを表示または変更できない。
※「所有者」「参加者」の考えかたは下記のとおりです。以降に出てくる「所有者」「参加者」の考え方も同じです。
| VPC を所有するアカウント | 所有者 |
| AWS Organizations で同じ組織に属する他のアカウント | 参加者 |
なおVPC参加者は、共有サブネット内に以下のサービスのリソースを作成できません。
- Amazon FSx
- AWS cloudHSM Classic
VPC所有者は、必要に応じてこれらのリソースを作成できるので、参加者からリクエストがあったら必要に応じて作成してあげましょう。
Resource Access Manageerの特徴
「Resource Access Manageer」の特徴となります。今回は3つ特徴が挙げられていました。
- AZアライメント：AZ IDを持つ別のアカウントのリソースを基準にして、あるアカウントのリソースの場所を決定する。
- 異なるAWSアカウント間でもAZ内データ転送は無料。
- VPCタグは共有されない。
Security Group and NACLsの特徴
「Security Group and NACLs」の特徴となります。今回は3つ特徴が挙げられていました。
- 所有者または参加者のアカウントからセキュリティグループを参照する。
- 所有していないセキュリティグループでリソースを起動できない。
- 所有者はNACLを使用して集中管理し、ネットワークセグメンテーション管理に使用できる。
請求の考え方
VPC所有者とVPC参加者とで請求される対象のリソースやサービスが異なります。
| VPC所有者に請求 |
|
| VPC参加者に請求 |
|
VPC Sharingの利点とユースケース
-
職務を分離したい場合
- ルーティング、IPアドレス、VPCフローログ、DNS設定、VPC構造の集中管理が出来る。
- 開発者は、リソース、アカウント、およびセキュリティグループを所有します。
-
未使用のリソースを減らしたい場合
- 高密度サブネット、最大5つのCIDRを追加出来る。
- VPN、TG、VPCピアリング、およびAWS Direct Connectのより効率的な使用が出来る。
-
アカウントとネットワークを分離したい場合
- 追加のインフラストラクチャなしでのアカウント保護と請求が出来る。
- ネットワークが少ない多くのアカウント（使用するIPv4 CIDRが少ない）
- 異なるアカウントからセキュリティグループを参照できます
Atlassian社のケース
今回のセッションではAtlassian社の実際の利用ケースも紹介されました。Atlassian社では、5か所に拠点があり、AWSの7つのリージョンをしているそうです。
また、下記のような規模でAWSを利用しているそうです。
- 170以上のAWSアカウントと
- 800以上のAmazon VPC
- 1000以上のVPCピアリング（同じ地域）
- 43ペタバイト以上（データ転送）
ちなみに、Atlassian社の製品プロダクトは下記のようなものがあります。耳馴染みあるものも多いのではないでしょうか？
構成例
VPC Sharingを使う前のサービス所有者チームの管轄エリア（赤点線枠）が分かります。
Shared VPCを使う前は20以上のステップを経て上記を実現していたそうです。
Shared VPCによってサービス所有者チームの管轄エリア（赤点線枠）が局所的になっていることが分かります。
これらを実現したOwnerAccountでの設定の一部がこちらです。
また、Security Segmentationについての設定例の一部も説明がありました。
まとめ
「VPC Sharing」を利用するケースや利用した場合のメリットを本セッションで学ぶことが出来ました。実際のシステムの環境に応じてVPN Sharingを適応させた方がいいケースか、複数VPCをそのまま管理させた方がいいのか状況や環境に応じて選択肢が異なるかと思います。「VPC Sharing」にも興味が出てきたので、実際のお客様のユースケースやVPC Sharingを採用したケースの背景などを勉強したいと思います！
以上、大阪オフィスの林がお送りしました！
2
