Simpline Blog[画像つき]WorkSpacesをひとまずQuick Setupで構築してアーキテクチャをざっくり理解する【アーキテクチャ編】

2019.04.20

  • ホーム
  • 過去ブログ
  • [画像つき]WorkSpacesをひとまずQuick Setupで構築してアーキテクチャをざっくり理解する【アーキテクチャ編】

はじめに

過去に別の場所で投稿した内容を再編集したものです。（2016年10月！）

なるべく本記事投稿の時点の最新の情報を取り込み、軽く手を動かして状況が変わっていないことは確認済みですが、マネジメントコンソールのデザインなど、細かい部分は最新でないことをご留意ください。

本記事について

以下の記事とセットになっています。
[画像つき]WorkSpacesをひとまずQuick Setupで構築してアーキテクチャをざっくり理解する【構築編】

当初はまとめて1つの記事にしていたのですが、長くなり過ぎたのと、構築手順の確認とアーキテクチャの理解という論点がぶれた気がするので、分けることにしました。

全体として以下の構成となっています。

  1. WorkSpacesを高速セットアップで立ち上げる　⇒　構築編
  2. 一緒に作られるものを確認する　⇒　アーキテクチャ編
  3. クライアントから接続する　⇒　構築編

本記事では2.としてWorkSpacesの高速セットアップで作成されたものを確認しながら、アーキテクチャを理解することを目的に記していきます。

2.Quick Setup（高速セットアップ）が作成してくれるもの

以下にもさらっと書かれていますが、細かく触れられていない部分もあるので、順番に見ていきます。

[Amazon WorkSpaces 高速セットアップを開始する]『高速セットアップ』部
https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/getting-started.html#quick-setup-launch-workspace

2.1.IAMロール

ロール「workspaces_DefaultRole」が作成されていました。
インラインポリシー（管理ポリシーではない）として、カッコいい名前のポリシーが設定されていました。

  • SkyLightSelfServiceAccess
  • SkyLightServiceAccess
SkyLightSelfServiceAccess
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "workspaces:RebootWorkspaces",
                "workspaces:RebuildWorkspaces",
                "workspaces:ModifyWorkspaceProperties"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

WorkSpacesの再起動、再作成、プロパティ編集を許可するもの。

SkyLightServiceAccess
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:CreateNetworkInterface",
        "ec2:DeleteNetworkInterface",
        "ec2:DescribeNetworkInterfaces",
        "galaxy:DescribeDomains"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

WorkSpacesによるENIの作成/削除と、WorkSpacesディレクトリのリスト表示を許可するもの。

信頼関係のポリシーは以下のようになっており、
信頼されたエンティティ「ID プロバイダー workspaces.amazonaws.com」です。

アクセスコントロールポリシー
{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "workspaces.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

2.2.VPC

VPCを作成してくれていますが、果たしてどれがそのVPCなの？というのを、WorkSpacesの画面から一発でリンクで飛んでいけたりはしないようでした。

▼Workspacesインスタンスの詳細画面
WorkSpaces画面

2.3.Elastic Network Interface

というわけなので、VPCはENIからさかのぼって確認することにします。

▼作成されたENIは3つ。
WorkSpacesENI

  • Ⅰ.WorkSpacesインスタンス用
    • 各WorkSpacesインスタンス用に作成されたもの
      • 今回はインスタンス1つしか作成していないため1つ
      • 初回作成時にユーザを複数選択すればその分インスタンスが作成されるので、このENIもその数だけ増える
    • 高速セットアップだとパブリックIPが割り当てられる
    • 説明：Created By Amazon Workspaces for AWS Account ID <カスタマーのアカウント番号>
  • Ⅱ.Directory用
    • Directoryサービス用に作成されたもの
      • 高速セットアップだとSimpleADなので、それ用。
      • WorkSpacesインスタンスの数が増えようとDirectoryサービスの足が増えるわけではないので、ここのENI数は一定
      • マルチAZ構成のため、2つ
    • 説明：AWS created network interface for directory <ディレクトリサービスのid>

ENIの所有者が自分自身のAWSアカウント番号ではないのは、EC2とか触ってるだけだと珍しいですね。
（後で出てきますが、カスタマー(AWSユーザ)側からは見えないENIも一緒に作成されています。）

ENIのコンソール画面から、所属するVPCのコンソール画面へリンクで飛んでいきましょう。

2.2(#2)さかのぼってVPC

今回リージョンをシドニーにして作成したのですが、172.16.0.0/16で作成されていました。
VPC上ではサブネットが2つ作成済み。それぞれ違うアベイラビリティゾーンに作成されています。
そして上記のサブネットには同じルートテーブルが関連付けられています。

▼ルートテーブルの情報はlocalとインターネット向けの2種類のみです。
WorkSpacesルートテーブル

いわずもがなですが、インターネットゲートウェイも同時に作成されてアタッチ済みです。

▼VPCにはこんな感じのタグが。
15.jpg
「AWSServiceAccount」というキーはあまり見ない気がしますね。

作成されるVPCのレンジは何を基準に選択されているのか？

当時の自分は『シドニーだったら172.31.0.0/16か192.168.0.0/16かと思った』という記載をしているのですが、その根拠として見ていたであろうドキュメントの記述が以下となります。

[Amazon WorkSpaces のポート要件]「ネットワークインタフェース」部
https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/workspaces-port-requirements.html#network-interfaces

管理インタフェース.PNG

結果から言うと、上記で記載されているIPレンジは「管理インタフェースが取りうるもの」を表しており、高速セットアップで作成されるVPCのIPレンジは別物です。「管理インタフェースが取りうるIPを避けて、空いているレンジの中から自動で採番する」という挙動だと推測します。高速セットアップを開始する時点で条件に合致するIPレンジに空きが無いと、エラーになる気がします。

公式ドキュメントのアーキテクチャ図を拝借してもう少し掘ります。
https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/amazon-workspaces.html#architecture

管理インタフェース (2).PNG
今回の構成に当てはめると、以下のようになります。

  • 赤枠部:
    • 管理インタフェースのIPレンジ
    • AWSマネージドなVPC（に属する）
    • (172.31.0.0/16、192.168.0.0/16、198.19.0.0/16)
  • 青枠部:
    • 高速セットアップにより作成されたVPC
    • カスタマーが管理するVPC
    • (172.16.0.0/16)

ENIのところで言及した「カスタマーに見えないENI」というのは、赤枠部に存在する「管理インタフェース」というENIのことを指していました。ひとまずカスタマーの目に見えないVPCもあるのだと認識したところで、次に進みます。アーキテクチャ図はまた出てきます。

2.4.セキュリティグループ

それぞれのENIからリンクで飛んで確認できます。

  • ①WorkSpacesインスタンス用セキュリティグループ

    • グループ名「d-xxxxxxxx_workspacesMembers」
    • インバウンド：ルールなし(※2)
    • アウトバウンド：すべて許可
    • Ⅰ.WorkSpacesインスタンス用ENIにアタッチされている

  • ②Directory用セキュリティグループ

    • グループ名「d-xxxxxxxx_controllers」
    • インバウンド：すごくいっぱい（下画像参照）
    • アウトバウンド：すべてのトラフィックを自分と同一のセキュリティグループに許可
    • Ⅱ.Directory用ENIにアタッチされている

▼②のインバウンドはこんな感じ。編集しないことを推奨されてます。
workspacesセキュリティグループ
ソースIPとして指定されているIPレンジは、WorkSpacesがセットアップされているVPCのCIDRです。
（2019年4月にTokyoリージョンで高速セットアップしてみたら、0.0.0.0/0で開いてました。攻めすぎてない？？）

(※2)本当にインバウンドなし？クライアントから接続どうしてるの？

ここで、①にも②にもパブリックな環境からのインバウンドルールが無いことに違和感を覚えませんか？（②を2019年に改めて試した時に0.0.0.0/0で開いていたのが話をややこしくしますが…）
私は覚えました。それは、①のSGを適用しているⅠ.のENIがパブリックIPを持っていることから、このENIがクライアントからの接続を受けつけるのかと考えたためです。（もしその通りなら①のSGに何かしら開いてないとおかしい。）

WorkSpacesインスタンスとEC2インスタンスを同じアーキテクチャで考えてはいけない

ここで登場するのがまたアーキテクチャ図です。囲むところを追加してみました。
アーキテクチャ２.PNG

クライアントが接続する先は緑で囲っている部分であり、AWSマネージドなVPCに含まれています。以下2種のゲートウェイが存在しています。

  • a.認証ゲートウェイ
  • b.ストリーミングゲートウェイ

a.認証ゲートウェイ

クライアントは認証ゲートウェイ宛にHTTPS443で接続し、WorkSpacesが連携しているDirectoryサービスと連携して認証を行います。認証のたびに通信が発生するかは調べきれませんでしたが、DirectoryサービスとWorkSpacesインスタンスの間の通信は、Ⅱ.Directory用ENI(黄色枠部)とⅠ.WorkSpacesインスタンス用ENI(紫枠部)によって行われています。

b.ストリーミングゲートウェイ

ストリーミングゲートウェイ宛にはTCP/UDPの4172ポートで接続し、そこを経由してWorkSpacesインスタンス上のデスクトップ環境がストリーミングされて来ます。ストリーミングゲートウェイとWorkSpacesインスタンスの接続を担っているのが、先述の「カスタマーには見えないENI」こと管理インタフェースです。

各 WorkSpace には、管理およびストリーミング用の ENI（eth0）とプライマリ ENI（eth1）という 2 つの ENI（Elastic Network Interface）が関連付けられています。

（https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/amazon-workspaces.html#architecture）

プライマリネットワークインターフェイスは、VPC 内だけでなくインターネットでのリソースへの接続を可能にし、WorkSpaces ディレクトリとの結合に使用されます。
管理ネットワークインターフェイスは、セキュアな Amazon WorkSpaces 管理ネットワークに接続します。Amazon WorkSpaces クライアントへの WorkSpace デスクトップのインタラクティブなストリーミングと､Amazon WorkSpaces が WorkSpace を管理するために使用されます。

（https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/workspaces-port-requirements.html#network-interfaces）

ちなみに、ゲートウェイ宛の通信を許可する接続元を制限したい場合は、WorkSpacesに「IPアクセスコントロール」という機能が用意されており、それを使用することになります。

ENIのおさらいのようなもの

  • WorkSpaces用
    • 管理インタフェース
      • eth0
      • ENIとしてはカスタマーには見えない
      • こいつにアタッチされているSecurityGroupも見えない
    • プライマリインタフェース
      • eth1
      • この記事ではⅠ.のENIとして記載
      • カスタマー管理のVPC内での通信に用いる
      • 高速セットアップではパブックIPを持っていたが、他のセットアップ方法ではそうとは限らない
        • パブリックIPを持っていたとしても、それはWorkSpacesインスタンスからインターネットへの疎通用であり、インバウンドを受け付けることは無い
        • パブリックIPを持たない場合は、インターネットに疎通するためにはNAT Gatewayなどを経由する必要あり
  • Directory用
    • この記事ではⅡ.のENIとして記載
    • DirectoryサービスそのものはAWSマネージドなVPCに立っているんだな、という発見
    • AWSマネージドなVPCにある実体にアクセスするためのENIがカスタマー管理のVPCに足を延ばしているイメージ

（※2）の『①にインバウンドなくてOKなの？』に戻ると、『大丈夫、AWSが裏側でうまいことやってくれてるから（カスタマーに見えないENIがあってそちらで実現しているから）』になります。

管理インタフェースについて、SecurityGroupの設定をカスタマーがいじることはできませんが、WorkSpacesインスタンスのOSから見てeth0として認識されているNICをいじったり(できるかわかりませんが)、OSのファイアウォールをいじったり、セキュリティソフトウェアによってポートがブロックされたりすると、ストリーミングの動作に支障が出る場合があります。

この記事も大詰めです。

2.5.Simple AD

WorkSpacesのダッシュボードからでも、Directory Serviceのダッシュボードからでも確認できます。

▼前者ではこのような感じ
WorkSpacesDirectory<br>

▼後者ではこのような感じ。ここから作成されたVPCを判断することもできますね。
WorkspacesSimpleAD<br>

ここでの[DNS Addres]として表示されているIPが、Ⅱ.Directory用のENIが持つIPです。

おわりに

結論としては、「WorkSpacesインスタンスとEC2インスタンスを同じアーキテクチャで考えてはいけない」につきます。カスタマーから見えないリソースがあり、そこで通信が実現されているというのは、なかなか面白いですね。どんどんカスタマーが意識しない領域というのが増えていくのでしょう。

元ネタ

WorkSpacesをQuick Setupで構築してみた①
WorkSpacesをQuick Setupで構築してみた②
WorkSpacesをQuick Setupで構築してみた③

一覧

関連コンテンツ

EC2Configの機能を利用したカスタムメトリクスを試してみました①
  • 2015.10.30
  • エンジニアブログ

EC2Configの機能を利用したカスタムメトリクスを試してみました①

GlusterFSとNFS-Ganeshaを連携する
  • 2014.12.24
  • エンジニアブログ

GlusterFSとNFS-Ganeshaを連携する

S3のバージョニングとライフサイクルについて③
  • 2016.02.19
  • エンジニアブログ

S3のバージョニングとライフサイクルについて③

Auto ScalingによりローンチされたEC2インスタンスに紐づくEBSに自動でタグをつけたい
  • 2017.08.18
  • エンジニアブログ

Auto ScalingによりローンチされたEC2インスタンスに紐づくEBS…

年別アーカイブ

リンク

どうすればできるか、
とことん一緒に考えます。
まずはシンプラインにご相談ください。
TOP