WorkSpaces設計時に検討する認証に関する構成３パターン
ご機嫌いかがでしょうか、豊崎です。
WorkSpacesを利用する際、DirectoryServiceの設計パターンがいくつかあるので、認証を継続して行えることに着目して３つのパターンについて整理してみることにします。とはいえ、WorkSpacesだけに限ったことではなく、一般的なDirectoryServiceの設計にも当てはまることだと思います。
その１：VPC内完結パターン
まずはVPC内だけで認証を完結させるパターンです。オンプレミスとの連携が一切必要ない場合にこの構成になります。
ActiveDirectory以外はマネージドサービスでAZレベルでの冗長構成になりますが、EC2上に作成したActiveDirectoryは必要に応じて利用者によって冗長構成をとる必要があります。他のマネージドサービスに揃える形でAZを分けて冗長化するのが望ましいです。
また、WorkSpacesの認証が同一VPCで完結するため、認証においては以降でご紹介するパターンのようにオンプレミスとの通信部分で考慮する必要はありません。
その２：オンプレAD＋AD Connectorパターン
次にAWS上にはAD Connectorを構築し、認証時にオンプレミスのActiceDirectoryを参照するパターンです。 AD Connector自体はAZレベルで冗長化されますが、AD Connector自体は認証情報をキャッシュしないため、DirectConnectまたはVPNに障害が発生した場合、WorkSpacesにログインできなくなります。
AD Connector は、クラウドの情報をキャッシュせずにディレクトリリクエストをオンプレミスの Microsoft Active Directory へリダイレクトするのに使用するディレクトリゲートウェイです。
https://docs.aws.amazon.com/ja_jp/directoryservice/latest/admin-guide/directory_ad_connector.html
DirectConnectを2本引いたり、DirectConectとVPNを両方引いて通信経路の冗長化で対応することなどを検討する必要があります。
その３：オンプレのAD DSをAWS上に拡張パターン
さいごにAWS上でEC2上にActiveDirectoryを構築し、オンプレミスのActiveDirectoryのドメインサービスを拡張するパターンです。 ドメインコントローラーをAWS上に追加することで、万が一オンプレミスとの接続ができなくなった場合でもAWS上で認証が完結します。 やはりAWS上のドメインコントローラーも冗長構成になっていることが望ましいです。
また、オンプレミスで東京本社と大阪支社のドメインコントローラーのサイトを分けるように、オンプレミスとAWSにおいてもサイトを分けることを検討してみると良いかもしれません。サイトを分けることでActiveDirectoryデータベース変更時の複製頻度が下がり、複製データが圧縮されて通信されるため通信されるデータ量を少なくすることができます。
さいごに
WorkSpacesを利用する観点からDirectoryServiceの設計パターンについてご紹介させていただきました。要件、規模感、リスクを判断して適切な設計をしたいですね。この記事が誰かのお役に経てば幸いです。
