本番前総復習
Direct Connect
DirectConnectのインターフェースを整理する。
DirectConnectLocation
DirectConnectと顧客側の回線が接続される物理インターフェース部分。世界中のあらゆる箇所にある。各DirectConnectLocationは特定のリージョンが担当を受け持つが、そのリージョン専用の窓口ではないことに注意する(後述)。
AWS Direct Connect | Find Locations | Amazon Web Services (AWS)
DirectConnectGateway(DXGT)
DirectConnectLocationは物理インターフェースであるのに対して、各リージョン/AZへの論理インターフェースとなるのがDirectConnectGatewayである。
DXGTはリージョンに属さないグローバルリソースであり、DirectConnectLocationで受け付けた接続はDXGTにてあらゆるリージョン/AZへとルーティングされる。東京のDirectConnectLocationで受け付けた接続も、シンガポールリージョンのVPCにルーティング出来る。
DXGT↔VPC間の通信は閉域なので、インターネットを経由してはならないといった要件にも十分に対応できる。 ただしDXGTを介したVPC↔VPC間の接続は出来ない。これに関してはVPC-Peering、より複雑なVPC間通信にはTransitGatewayを利用することになる。
プライベート仮想インターフェース(Private-VIF)
VGWと比べるとさして重要なインターフェースではないが、言葉が似ているため注意を要する。DXGTにせよDirectConnectLocationにせよ、ここまでは物理インターフェースについてみてきた。物理インターフェースは接続を確立するための接結点であり、これを介して論理接続を確立する。
Private-VIFはオンプレミス-DirectConnectiLocation-DXGTの接結点を通して確立されるVLANのことを指す。特にDXGTを経由してその先のVPCにPrivate-IpAddressで接続するときのVLANをPrivate-VIFと呼ぶ。 オンプレミス-DirectConnectLocation-DXGTの物理接続の間にはいくつものVLANを通すことが出来る。つまｒPrivateVIFは複数成立し、部署ごとに使い分けることが出来る。
パブリック仮想インターフェース(Public-VIF)
Private-VIFでは接続先のIp-AddressがVPCのPrivateである場合を想定したが、S3やDynamoDBといったAWSのパブリックサービスに対して接続するときは、宛先側にPublic-IpAddressを指定すればよい。これがPublic-VIFである。
この場合DXGTは不要となり、DirectConnectLocationに到達したパケットはAWS側が用意したAWS各サービスへのフォワーディング用ルーターを通って各サービスに到達する。
仮想プライベートゲートウェイ(VGW)
DirectConnectからの通信をVPC内に引き込むためのインターフェース。Virtual Private Gatewayなのになぜか略称がVGWになっているのでややこしい。名前の通りInternet-Gateway(IGW)などと対になる機能で、VPCにアタッチしてDirectConnectとの接続のインターフェースとなる。
DXGTからの接続はここが受付になる。プライベート仮想ゲートウェイへのルート伝搬(自分自身のアドバタイズ)を有効にしてやることで、顧客側のルータとDXGTがこのゲートウェイを認識し、VPCへのルーティングテーブルが作成されることになる。
VPC自体のルートテーブルにも、オンプレ宛てへの通信のFirst HopとしてVGWを指定してやる必要がある。VGWを設置しても自動的に顧客側へのルートが設定される訳ではない。
仮想パブリックゲートウェイ
ありません。
VPN接続
Clitent-VPNについて言及している問題がほとんどないので省略。 Site-to-Site VPNについてのみ言及する。
CustomerGateway
VPN接続の顧客(オンプレ)側の拠点。DirectConnectでこれを用意する必要はないので注意する。
仮想プライベートゲートウェイ(VGW)
Site-to-Site VPNのAWS側のインターフェース。DirectConnectと異なり、DXGTなどの拠点を通らず直接VPCにアタッチするインターフェースに接続が出来る。
後述するようにSite-to-SiteVPNで複数のVPCに対して接続したいときは、下記のTransitGatewayを利用する。
Transit Gateway
これはCustomerGatewayに限った機能ではない。但し、DirectConnectではDirectConnectGateway(DXGT)を利用して複数のVPCへのルーティングが出来たのに対しSite-toSite Gatewayにはそのような機能がない。
その代わりVPN接続のAWS側のインターフェースにTransitGatewayを指定する。TransitGatewayはVPCのハブアンドスポーク接続を可能にするもの。 なお、TransitGatewayは従来利用されていた非マネージドなTransitVPCを代替するもの。
ActiveDirectlyとの統合
非常にドンピシャのBlackBeltセミナーがあったのでリンクを貼っておく。 www.youtube.com
ID Federation
AWSでID Federationを行う場合、IdPとSP(サービスプロバイダ≒ここではAWSサービス)の間では事前に初期設定として信頼関係を結ぶ必要がある。メタデータドキュメントというものをエクスポートし、AWS側に読み込ませることでAWS側はIdPを信頼することが出来る。
AWSでID Federationを利用する場合、利用者はIAMユーザーに紐付けられる訳ではないことにも注意する。AWSがIdPから発行されたアサーションを読み込んで利用可能なユーザーで(フェデレ―テッドユーザと呼ぶ)あると判断した場合、そのユーザーには(STSによる一時的なログイン許可とともに)IAMロールが割り当てられる。
そのため、AWSでID Federationを実現する場合はIAMロールを事前に作成することが求められる。IAMロールのプリンシパルには、PrincipalとしてIdPのARN(Amazon Resource Name)を設定してやる必要がある。
AWS SSO
ここまではAWSのリソースへのアクセスを可能にすることを見てきた。AWSには(AWS側で認証を実施することで)外部のアプリケーションに対するID Federationを実現することも出来る(つまりAWS側がIdPとして機能する)AWS SSOが備わっている。また単なるIdpとして機能する際はDirectory Serviceとの連携が前提となるが、SSO自身でDirectoryを持つことも出来る。
AWS SSOはOrganizationのマスターアカウントに対して有効化する。マスターアカウントでログインされたユーザーにどんな権限を与えるのか[アクセス権限セット]という(クロスアカウントの)IAMポリシーのようなものを作成する。すると各アカウントに対して、フェデレ―テッドユーザー向けのロールが自動で作成される。
これらのロールは特別に[AWS_ReservedSSO_XXX]という名前がついている。
Id Federationの方法の選択
AWSリソースへのId Federationの方法としては下記の3つに分類される。
- オンプレミスのDirectory Serviceを参照しAD Connectorが承認することでロールを与える。
AWSのＭicrosoft ADを参照し
オンプレミスのDirectory ServiceからIdpを利用し、AWSでそれを許可してロールを与える。
3rd PartyのDirectory ServiceがIdpを利用し、AWSでFederationしてロールを与える。
- AWSのMicrosoft AD(MSAD)からIdPを利用し、AWSでそれを許可してロールを与える。
AWS SSOはSSOといいつつ、SSO(シングルサインオン)に必須な機能ではない。(Organizationを利用するような場面で便利なAWSマネージドな)Directory Serviceと考えることも出来る。
