案例 2:將內部部署 AD DS 延伸到 AWS (複本) - 部署的最佳做法 WorkSpaces

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

案例 2:將內部部署 AD DS 延伸到 AWS (複本)

這個案例類似於案例 1。不過,在這個案例中,客戶 AD DS 的複本會與 AD Connector 一起部署。 AWS 如此可減少在 Amazon Elastic Compute Cloud (Amazon EC2) 上執行之 AD DS 的身份驗證或查詢請求的延遲。下圖顯示每個元件和使用者驗證流程的高階檢視。

顯示客戶 AD DS 複本的範例架構與 AD Connector 一起部署。 AWS

圖 7:將客戶活動目錄域擴展到雲

與案例 1 一樣,AD Connector 用於所有使用者或 MFA 驗證,這些驗證反過來會代理客戶 AD DS (請參閱圖)。在這個案例中,客戶 AD DS 會部署到 Amazon EC2 執行個體上的 AZ,這些 AZ 在客戶的現場部署 AD 樹系中被提升為網域控制站,並在 AWS 雲端中執行。每個網域控制站都部署到 VPC 私有子網路中,以使 AD DS 在雲端中具有高可用性。 AWS 如需部署 AD DS 的最佳作法 AWS,請參閱本文件的「設計考量」一節。

WorkSpaces 執行個體部署之後,它們就可以存取雲端架構網域控制站,以取得安全、低延遲的目錄服務和 DNS。所有網路流量 (包括 AD DS 通訊、驗證要求和 AD 複寫) 都是在私有子網路內或跨客戶 VPN 通道或直 Connect 的保護。

此架構使用下列元件或建構:

AWS

  • Amazon VPC — 創建具有跨兩個 AZ 至少四個私有子網的 Amazon VPC-兩個用於客戶 AD DS,兩個用於 AD Connector 或 Amazon。 WorkSpaces

  • DHCP 選項集 — 建立一個 Amazon VPC 端 DHCP 選項集。這可讓客戶定義指定的網域名稱和 DNSS (AD DS 本機)。如需詳細資訊,請參閱 DHCP 選項集

  • Amazon 虛擬私有閘道 — 啟用透過 IPSec VPN 通道或 AWS Direct Connect 連線與客戶擁有的網路進行通訊。

  • Amazon EC2

    • 部署在專用私有 VPC 子網路中 Amazon EC2 執行個體上的客戶公司 AD DS 網域控制站。

    • 專用私有 VPC 子網路中 Amazon EC2 執行個體上 MFA 的客戶 (選用) RADIUS 伺服器。

  • AWS 目錄服務 — AD Connector 部署到一對 Amazon VPC 私有子網路中。

  • Amazon WorkSpaces — 部署到與 AD Connector 相同的私 WorkSpaces 有子網中。如需詳細資訊,請參閱本文件的 Active Directory:網站與服務一節。

客戶

  • 網路連線 — 企業 VPN 或 AWS Direct Connect 端點。

  • AD DS — 公司 AD DS (複寫所需)。

  • MFA(可選)— 公司 RADIUS 服務器。

  • 終端使用者裝置 — 用於存取 Amazon 服務的企業或 BYOL 最終使用者裝置 (例如視窗、蘋果電腦、iPads、安卓平板電腦、零用戶端和 Chromebook)。 WorkSpaces 如需支援的裝置和 Web 瀏覽器,請參閱用戶端應用程式清單。此解決方案與案例 1 沒有相同的警告。Amazon WorkSpaces 和 AWS Directory Service 不依賴於到位的連接。

  • 依賴連線 — 如果與客戶資料中心的連線中斷,使用者可以繼續工作,因為驗證和用的 MFA 是在本機處理的。

  • 延遲 — 複寫流量除外,所有驗證均為本機驗證,且延遲較低。請參閱本文件的「作用中目錄:網站與服務」一節。

  • 流量成本 — 在這個案例中,驗證是本機的,只有 AD DS 複寫必須周遊 VPN 或直 Connect 結,以減少資料傳輸。

一般而言,體 WorkSpaces 驗會增強,而且不是與內部部署網域控制站的高度相依性連線,如上圖所示。當客戶想要擴充 WorkSpaces 至數千台桌上型電腦 (特別是與 AD DS 通用類別目錄查詢有關) 時,也會發生這種情況,因為此流量仍保持在本機 WorkSpaces 環境中。