本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# AD DS 部署案例
支援 Amazon WorkSpaces 是 AWS Directory Service，目錄服務的正確設計和部署至關重要。以下六個案例建立在* AWS 快速入門指南中的* [Active Directory 網域服務](https://docs.aws.amazon.com/quickstart/latest/active-directory-ds/architecture.html)上，並說明與 Amazon 搭配使用時 AD DS 的最佳實務部署選項 WorkSpaces。本文件的「[設計考量](using-multi-region-aws-managed-active-directory-with-amazon-workspaces.md)」一節詳細說明使用 AD Connector 的特定需求和最佳作法 WorkSpaces，這是整體 WorkSpaces設計概念中不可或缺的一部分。
+ **案例 1：使用 AD Connector 將驗證代理至內部部署 AD DS** — 在這個案例中，網路連線 (VPN/Direct Connect) 會提供給客戶，並透過 AWS Directory Service (AD Connector) 代理至客戶內部部署 AD DS 的所有驗證。
+ **案例 2：將內部部署 AD DS 延伸至 AWS (複本)** — 這個案例類似於案例 1，但是這裡的客戶 AD DS 複本會與 AD 連接器搭配部署，以減少 AD DS 和 AD DS 通用類別目錄的驗證/查詢要求的延遲。 AWS
+ **案例 3：在 AWS 雲端中使用 AWS Directory Service 的獨立隔離部署** — 這是一個隔離的案例，不包括回傳給客戶進行驗證的連線。這種方法使用 AWS Directory Service（Microsoft AD）和 AD Connector。雖然這個案例並不依賴客戶的連線來進行驗證，但它確實會在需要透過 VPN 或直 Connect 線時佈建應用程式流量。
+ **案例 4： AWS Microsoft AD 和內部部署的雙向傳遞信任 — 這個**案例包括 AWS 受管理的 Microsoft AD 服務 (MAD) 與內部部署 Microsoft AD 樹系的雙向傳遞信任。
+ **案例 5：使用共用服務 VPC 的 AWS Microsoft AD** — 此案例在使用 AD 連接器將輕量型目錄存取通訊協定 (LDAP) 代 AWS 理輕量型目錄存取通訊協定 (LDAP) 使用者驗證請求時，使用受管 Microsoft AD 作為多個 AWS 服務 (Amazon EC2 WorkSpaces、Amazon 等) 的身分識別網域使用。
+ **案例 6： AWS Microsoft AD、共用服務 VPC 和單向信任內部部署 AD** — 此案例類似於案例 5，但包含使用內部部署單向信任的不同身分識別和資源網域。
當您選取使用中目錄網域服務 (ADDS) 的部署案例時，您需要考量一些事項。本節說明 AD Connector 與 Amazon 的角色 WorkSpaces，並涵蓋選取 ADDS 部署案例時的一些重要考量事項。有關 ADDS 的設計和規劃的進一步指導 AWS，請參閱 [Active Directory 域名服務的 AWS 設計和規劃指南](https://d1.awsstatic.com/whitepapers/adds-on-aws.pdf)。
# AWS AD Connector 與 Amazon 的作用 WorkSpaces
[AWS AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html) 是一種 AWS Directory Service，可做為「作用中目錄」的代理服務。它不會儲存或快取任何使用者認證，但會將驗證或查閱要求轉送至您的 Active Directory (內部部署或上)。 AWS除非您正在使用 AWS Managed Microsoft AD，否則它也是註冊您的 Active Directory（現場部署或擴展到 AWS）以與 Amazon WorkSpaces （WorkSpaces）一起使用的唯一方法。
AD Connector 器可以指向您的現場部署作用中目錄、延伸至 AWS (Amazon EC2 上的 AD 網域控制站) 的作用中目錄，或指向 AWS Managed Microsoft AD.
AD Connector 在以下各節中涵蓋的大多數部署案例中扮演著重要的角色。搭配使用 AD Connector 可 WorkSpaces 提供許多好處：
+ 當指向您的公司 Active Directory 時，它允許您的使用者使用其現有的企業登入資料登入 WorkSpaces 和其他服務，例如 [Amazon WorkDocs](https://aws.amazon.com/workdocs/)。
+ 您可以持續套用現有的安全性原則 (密碼到期、帳戶鎖定等)，無論您的使用者正在存取內部部署基礎結構中的資源，或是存取中的資源 AWS 雲端，例如 WorkSpaces.
+ AD Connector 可與您現有的 Radius-based MFA 基礎架構進行簡單整合，以提供額外的安全性層。
+ 它可以讓您的使用者隔離。例如，它允許設定每個業務單位或角色的數個 WorkSpaces 選項，因為多個 AD 連接器可以指向 Active Directory 的相同網域控制站 (DNS 伺服器)，以進行使用者驗證：
+ 作用中目錄群組原則物件 (GPO) 之目標應用程式的目標網域或組織單位
+ 不同的安全群組來控制流量往返 WorkSpaces
+ 不同的存取控制選項 (允許的用戶端裝置) 和 IP 存取控制群組 (限制對 IP 範圍的存取)
+ 選擇性啟用本機管理員權限
+ 不同的自助權限
+ 選擇性強制執行 Multi-Factor Authentication (MFA)
+ 將您的 WorkSpaces 彈性網路介面 (ENI) 放置到不同的 VPC 或子網路中以進行隔離
如果您達到單一小型或大型 AD 連接器的效能限制，則多個 AD Connector 器也可以支援更多使用者。請參閱[的尺寸 AWS Managed Microsoft AD](#sizing-aws-managed-microsoft-ad)部分以獲取更多詳細信息。
使用 AD 連接器 WorkSpaces 是免費的，只要您在小型 AD 連接器中至少有一個作用中使用 WorkSpaces 者，大型 AD Connector 器中至少有 100 個作用中使用 WorkSpaces 者即可。如需詳細資訊，請參閱目[AWS 錄服務定價](https://aws.amazon.com/directoryservice/pricing/)頁面。
## AWS 使用內部部署作用中目錄的網路連結的重要性
WorkSpaces 依賴於連接到您的活動目錄。因此，您的活動目錄的網絡鏈接的可用性是至關重要的。例如，如果您在[案例 1](scenario-1-using-ad-connector-to-proxy-authentication-to-on-premises-active-directory-service.md) 中的網路連結關閉，您的使用者將無法進行驗證，因此將無法使用他們的 WorkSpaces.
如果要使用內部部署 Active Directory 做為案例的一部分，您必須考慮網路連結的復原能力、延遲和流量成本。 AWS在多地區 WorkSpaces 部署中，這可能涉及不同區 AWS 域中的多個網路連結，或是在它們之間建立了多個 AWS Transit Gateway對等連結，以便將 AD 流量路由到 VPC，並連線到內部部署 AD。這些網路連結考量適用於下列各節中所述的大部分案例，但對於 AD 連接器的 AD 流量，而且 WorkSpaces 需要周遊網路連結才能到達內部部署 Active Directory 的那些案例尤其重要。 [情況 1](scenario-1-using-ad-connector-to-proxy-authentication-to-on-premises-active-directory-service.md) 突出顯示了一些警告。
## 使用多因素身份驗證 WorkSpaces
如果您打算搭配使用 Multi-Factor Authentication (MFA) WorkSpaces，則必須使用 AWS AD Connector 或 AWS Managed Microsoft AD，因為只有這些服務允許註冊目錄以與 RADIUS 搭配使用 WorkSpaces 和設定。若要放置 RADIUS 伺服器，則適用[AWS 使用內部部署作用中目錄的網路連結的重要性](#network-link-to-aws-with-on-premises-ad)本節中涵蓋的網路連結考量。
## 分隔帳號和資源網域
基於安全性考量或為了更好的管理性，您可能需要將帳號網域與資源網域分開。例如，將 [ WorkSpaces 電腦物件] 放入個別的 [資源網域] 中，而 [使用者] 則是 [帳號網域] 的一部分。這樣的實作可用於允許合作夥伴組織管理資源網域中 WorkSpaces使用 AD 群組原則，同時不會放棄控制權或授與帳戶網域的存取權。這可以通過使用兩個活動目錄與配置的活動目錄信任來完成。以下各節將更詳細地介紹這一點：
+ [案例 4： AWS Microsoft AD 和內部部署的雙向傳遞信任](scenario-4-aws-microsoft-ad-and-a-two-way-transitive-trust-to-on-premises.md)
+ [案例 6： AWS Microsoft AD、共用服務 VPC，以及內部部署的單向信任](scenario-6-aws-microsoft-ad-shared-services-vpc-and-a-one-way-trust-to-on-premises.md)
## 大型作用中目錄部署
您必須確保活動目錄站點和服務相應地配置。如果您的 Active Directory 包含大量位於不同地理位置的網域控制站，這一點尤其重要。您的 Windows WorkSpaces 使用[標準的 Microsoft 機制](https://social.technet.microsoft.com/wiki/contents/articles/24457.how-domain-controllers-are-located-in-windows.aspx)來探索他們的網域控制站的作用中目錄網站，它們被指派到。這個 DC 定位器處理程序依賴於 DNS，如果冗長的網域控制站清單具有不特定的優先順序和權重在 DC 定位器處理序的早期階段傳回，可能會顯著延長。更重要的是，如果您「固定」 WorkSpaces 到次最佳的網域控制站，所有後續與此網域控制站的通訊可能會遭受增加的網路延遲和減少頻寬的周遊廣域網路連結時。這會減慢與網域控制站的任何通訊速度，包括處理可能大量的群組原則物件 (GPO)，以及從網域控制站傳輸檔案。視網路拓撲而定，也可能會增加您的網路成本，因為 WorkSpaces 和網域控制站之間交換的資料可能會不必要地周遊較昂貴的網路路徑。如需有關您 VPC 設計的 DHCP 和 DNS 以及使用中目錄網站與服務的指引，請參閱和[設計考量](design-considerations.md)章節。[VPC 設計](design-considerations.md)
## 使用 Microsoft Azure 活動目錄或活動目錄域服務 WorkSpaces
如果您打算使用 Microsoft Azure 活動目錄 WorkSpaces，您可以使用 Azure 的 AD Connect 與您的現場部署活動目錄或與您的活動目錄 AWS （在 Amazon EC2 上的域控制器 AWS Managed Microsoft AD）同步您的身份。但是，這將不允許您加入 WorkSpaces 到您的 Azure 活動目錄。如需詳細資訊，請參閱 [Microsoft Azure 文件中的 Microsoft 混合身分識別](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/)*文件*。
如果你想要加入您 WorkSpaces 的 Azure 活動目錄，您將需要部署 Microsoft Azure 活動目錄域服務（Azure AD DS），建立 AWS 和 Azure 之間的連接，並使用 AWS AD Connector 器指向您的 Azure AD DS 域控制器。如需有關如何設定此項目的詳細資訊，請參閱使用 [Azure 作用中目錄網域服務將您新增 WorkSpaces 至 Azure AD](https://aws.amazon.com/blogs/desktop-and-application-streaming/add-your-workspaces-to-azure-ad-using-azure-active-directory-domain-services/) 部落格文章。
搭配使用 AWS Directory Service s 時 WorkSpaces，您必須考慮 WorkSpaces部署的大小及其預期成長，才能 AWS Directory Service 適當地調整大小。本節提供調整大小以搭配使 AWS Directory Service 用的指南 WorkSpaces。我們也建議您檢閱 [AD Connector 的最佳做法](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_best_practices.html)，以及《*AWS Directory Service 管理指南》 AWS Managed Microsoft AD*各節的最[佳做](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_best_practices.html)法。
## AD Connector 尺寸 WorkSpaces
作用中目錄連接器 (AD Connector) 有兩種大小：小型和大型。雖然沒有強制使用者或連線限制，但我們建議您使用小型 AD Connector，最多可容納 500 WorkSpaces 名授權的使用者，以及最多可容納 5000 WorkSpaces 名獲權使用者的大型 AD Connector。您可以將應用程式負載分散到多個 AD Connector，以根據效能需求進行擴充。例如，如果您需要支援 1500 個 WorkSpaces 使用者，您可以將您的 WorkSpaces 平均分散到三個小型 AD 連接器，每個連接器都支援 500 位使用者。如果所有使用者都位於相同的網域中，AD Connector 器可以全部指向解析您 Active Directory 網域的同一組 DNS 伺服器。
請注意，如果您開始使用小型 AD Connector，且 WorkSpaces 部署隨著時間的推移而成長，您可以提出支援票證，讓 AD Connector 的大小從小變更為大，以處理更多有 WorkSpaces 權使用者。
## 的尺寸 AWS Managed Microsoft AD
[AWS Managed Microsoft AD](https://aws.amazon.com/directoryservice/active-directory/)可讓您以受管理服務的形式執行 Microsoft 活動目錄。啟動服務時，您可以選擇標準版和企業版。標準版適用於擁有最多 5,000 名使用者的中小型企業，最多可支援 30,000 個目錄物件，例如使用者、群組和電腦。企業版最多可支援 500,000 個目錄物件，並提供額外的功能，例如[多區域複寫](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_configure_multi_region_replication.html)。
如果您需要支援超過 500,000 個目錄物件，請考慮在 Amazon EC2 上部署 Microsoft 活動目錄網域控制器。如需這些網域控制站的大小，請參閱 Microsoft 的[使用中目錄網域服務的容量規劃](https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services)文件。
# 案例 1 ︰使用 AD 連接器對內部部署作用中 Directory Service 的代理驗證
這個案例適用於不想要擴充其內部部署 AD 服務 AWS，或 AD DS 的新部署不是選項的客戶。下圖顯示了高級別，每個組件和用戶身份驗證流程。
![\[在每個元件和使用者驗證流程中顯示的高階架構範例。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/ad-connector-to-onprem.png)
在這個案例中， AWS Directory Service (AD Connector) 會用於透過 AD 連接器代理至客戶內部部署 AD DS 的所有使用者或 MFA 驗證 (如下圖所示)。如需有關驗證程序所使用之通訊協定或加密的詳細資訊，請參閱本文件的[安全](security.md)章節。
![\[範例架構顯示如何將 AD Connector 用於透過 AD 連接器代理至客戶內部部署 AD DS 的所有使用者或 MFA 驗證。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/user-authentication-auth-gateway.png)
案例 1 顯示客戶可能已經擁有資源的混合式架構 AWS，以及可透過 Amazon 存取的現場部署資料中心中的資源 WorkSpaces。客戶可以利用現有的內部部署 AD DS 和 RADIUS 伺服器進行使用者和 MFA 驗證。
此架構使用下列元件或建構：
## AWS
+ **Amazon VPC** — 建立具有跨兩個 AZ 的至少兩個私有子網路的 Amazon VPC。
+ **DHCP 選項集** — 建立一個 Amazon VPC 端 DHCP 選項集。這可讓您定義客戶指定的網域名稱和網域名稱伺服器 (DNS) (內部部署服務)。如需詳細資訊，請參閱 [DHCP 選項集](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html)。
+ **Amazon 虛擬私有閘**道 — 啟用透過 IPSec VPN 通道或 AWS Direct Connect 連線與您自己的網路通訊。
+ **AWS Directory Service** — AD Connector 部署到一對 Amazon VPC 私有子網路中。
+ **Amazon WorkSpaces** — 部署 WorkSpaces 在與 AD Connector 相同的私有子網中。如需詳細資訊，請參閱本文件的 [Active Directory：網站與服務](design-considerations.md#active-directory-sites-and-services)一節。
## 客戶
+ **網路連線** — 企業 VPN 或直 Connect 線端點。
+ **廣告 DS** — 企業廣告 DS.
+ **MFA（可選）**— 公司 RADIUS 服務器。
+ **終端使用者裝置** — 用於存取 Amazon 服務的企業或自攜授權 (BYOL) 使用者裝置 (例如 Windows、Mac、iPads、安卓平板電腦、零用戶端和 Chromebook)。 WorkSpaces 如需[支援的裝置和 Web 瀏覽器，請參閱此用戶端應用程式清](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client)單。
雖然此解決方案對於不想將 AD DS 部署到雲端的客戶來說非常有用，但確實有一些警告：
+ **依賴連**線 — 如果與資料中心的連線中斷，使用者將無法登入各自的連線 WorkSpaces，而且在 Kerberos /票證授權票證 (TGT) 期間，現有的連線將保持作用中。
+ **延遲** — 如果透過連線存在延遲 (VPN 比直 Connect 線更多)，則 WorkSpaces 驗證和任何 AD DS 相關活動 (例如群組原則 (GPO) 強制執行，將會花費更多時間。
+ **流量成本** — 所有驗證都必須遍歷 VPN 或直接 Connect 鏈接，因此它取決於連接類型。這可能是從 Amazon EC2 傳出到網際網路的資料傳輸，也可以是資料傳出 (直 Connect)。
**注意**
AD Connector 是代理服務。它不存儲或緩存用戶憑據。相反地，所有驗證、查詢和管理要求都會由 AD 處理。目錄服務中需要具有委派權限的帳戶，並具有讀取所有使用者資訊並將電腦加入網域的權限。
一般而言，體 WorkSpaces 驗高度依賴於上圖所示的 Active Directory 驗證程序。在此案例中，驗 WorkSpaces 證體驗高度依賴於客戶 AD 和 WorkSpaces VPC 之間的網路連結。客戶應確保鏈接具有高可用性。
# 案例 2：將內部部署 AD DS 延伸到 AWS (複本)
這個案例類似於案例 1。不過，在這個案例中，客戶 AD DS 的複本會與 AD Connector 一起部署。 AWS 如此可減少在 Amazon Elastic Compute Cloud (Amazon EC2) 上執行之 AD DS 的身份驗證或查詢請求的延遲。下圖顯示每個元件和使用者驗證流程的高階檢視。
![\[顯示客戶 AD DS 複本的範例架構與 AD Connector 一起部署。 AWS\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/extend-customer-ad-cloud.png)
與案例 1 一樣，AD Connector 用於所有使用者或 MFA 驗證，這些驗證反過來會代理客戶 AD DS (請參閱[上](scenario-1-using-ad-connector-to-proxy-authentication-to-on-premises-active-directory-service.md#fig5)圖)。在這個案例中，客戶 AD DS 會部署到 Amazon EC2 執行個體上的 AZ，這些 AZ 在客戶的現場部署 [AD 樹系](https://ipwithease.com/what-is-a-forest-in-active-directory/)中被提升為網域控制站，並在 AWS 雲端中執行。每個網域控制站都部署到 VPC 私有子網路中，以使 AD DS 在雲端中具有高可用性。 AWS 如需部署 AD DS 的最佳作法 AWS，請參閱本文件的「[設計考量](using-multi-region-aws-managed-active-directory-with-amazon-workspaces.md)」一節。
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 選項集](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html)。
+ **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：網站與服務](design-considerations.md#active-directory-sites-and-services)一節。
## 客戶
+ **網路連線** — 企業 VPN 或 AWS Direct Connect 端點。
+ **AD DS** — 公司 AD DS (複寫所需)。
+ **MFA（可選）**— 公司 RADIUS 服務器。
+ **終端使用者裝置** — 用於存取 Amazon 服務的企業或 BYOL 最終使用者裝置 (例如視窗、蘋果電腦、iPads、安卓平板電腦、零用戶端和 Chromebook)。 WorkSpaces 如需[支援的裝置和 Web 瀏覽器，請參閱用戶端應用程式清](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client)單。此解決方案與案例 1 沒有相同的警告。Amazon WorkSpaces 和 AWS Directory Service 不依賴於到位的連接。
+ **依賴連線** — 如果與客戶資料中心的連線中斷，使用者可以繼續工作，因為驗證和*選*用的 MFA 是在本機處理的。
+ **延遲** — 複寫流量除外，所有驗證均為本機驗證，且延遲較低。請參閱本文件的「[作用中目錄：網站與服務](design-considerations.md#active-directory-sites-and-services)」一節。
+ **流量成本** — 在這個案例中，驗證是本機的，只有 AD DS 複寫必須周遊 VPN 或直 Connect 結，以減少資料傳輸。
一般而言，體 WorkSpaces 驗會增強，而且不是與內部部署網域控制站的高度相依性連線，如上圖所示。當客戶想要擴充 WorkSpaces 至數千台桌上型電腦 (特別是與 AD DS 通用類別目錄查詢有關) 時，也會發生這種情況，因為此流量仍保持在本機 WorkSpaces 環境中。
# 案例 3：在 AWS 雲端中使用 AWS Directory Service 的獨立隔離部署
這個案例 (如下圖所示) 已在獨立隔離環境中的 AWS 雲端中部署 AD DS。 AWS Directory Service 僅在此案例中使用。客戶可以仰賴 AWS Directory Service 來執行諸如建置高可用性目錄拓撲、監視網域控制站以及設定備份和快照集等工作，而不需要完全管理 AD DS。
![\[架構範例，顯示在獨立隔離環境中部署在 AWS 雲端中的 AD DS。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/cloud-only-ad-microsoft.png)
與案例 2 一樣，AD DS (Microsoft AD) 會部署到跨越兩個 AZ 的專用子網路中，讓 AD DS 在雲端中具有高度可用性。 AWS 除了 Microsoft AD，AD Connector（在所有三種情況下）部署用於 WorkSpaces 身份驗證或 MFA。這可確保 Amazon VPC 內的角色或功能分離，這是標準的最佳實務。如需詳細資訊，請參閱本文件的「[設計考量](using-multi-region-aws-managed-active-directory-with-amazon-workspaces.md)」一節。
案例 3 是標準的全包組態，適用於希望 AWS 管理 AWS Directory Service 的部署、修補、高可用性及監視的客戶。由於其隔離模式，該案例也適用於概念驗證、實驗室和生產環境。
除了「 AWS Directory Service」的放置位置之外，此圖還顯示使用者到工作區的流量，以及工作區與 AD 伺服器和 MFA 伺服器的互動方式。
此架構使用下列元件或建構。
## AWS
+ **Amazon VPC** — 創建具有跨兩個 AZ 的至少四個私有子網的 Amazon VPC-兩個用於 AD DS [Microsoft AD，兩個用於 AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) Connector 或. WorkSpaces
+ **DHCP 選項集** — 建立一個 Amazon VPC 端 DHCP 選項集。這可讓客戶定義指定的網域名稱和 DNS (Microsoft AD)。如需詳細資訊，請參閱 [DHCP 選項集](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html)。
+ **選用：Amazon 虛擬私有閘**道 — 啟用透過 IPSec VPN 通道 (VPN) 或 AWS Direct Connect 連線與客戶擁有的網路進行通訊。用於存取內部部署後端系統。
+ **AWS Directory Service** — Microsoft AD 部署到一對專用的 VPC 子網路 (AD DS 受管理服務) 中。
+ **Amazon EC2** — MFA 的客戶「可選」半徑伺服器。
+ **AWS 目錄服務** — AD Connector 部署到一對 Amazon VPC 私有子網路中。
+ **Amazon WorkSpaces** — 部署到與 AD Connector 相同的私 WorkSpaces 有子網中。如需詳細資訊，請參閱本文件的 [Active Directory：網站與服務](design-considerations.md#active-directory-sites-and-services)一節。
## 客戶
+ **選用：網路連線** — 企業 VPN 或 AWS Direct Connect 端點。
+ 終**端使用者裝置** — 用於存取 Amazon 服務的企業或 BYOL 終端使用者裝置 (例如視窗、Mac、iPads、安卓平板電腦、零用戶端和 Chromebook)。 WorkSpaces 如需[支援的裝置和 Web 瀏覽器，請參閱此用戶端應用程式清](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client)單。
就像案例 2 一樣，這個案例不會有依賴客戶內部部署資料中心的連線、延遲或資料傳出成本的問題 (除非在 VPC WorkSpaces 內啟用網際網路存取)，因為根據設計，這是隔離或僅限雲端的案例。
# 案例 4： AWS Microsoft AD 和內部部署的雙向傳遞信任
這個案例 (如下圖所示) 已在 AWS 雲端部署 AWS Managed AD，其具有對客戶內部部署 AD 的雙向傳遞信任。使用者和 WorkSpaces 在受管理 AD 中建立，並具有 AD 信任，可在內部部署環境中存取資源。
![\[範例架構顯示部署在 AWS 雲端中的 AWS 受管理 AD，這對客戶內部部署 AD 具有雙向傳遞信任。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/cloud-only-transitive-trust.png)
與案例 3 一樣，AD DS (Microsoft AD) 會部署到跨越兩個 AZ 的專用子網路中，讓 AD DS 在雲端中具有高度可用性。 AWS
此案例適用於希望擁有完全受控 AWS Directory Service (包括部署、修補、高可用性及監視其 AWS 雲端) 的客戶。這種情況也允許 WorkSpaces 用戶訪問其現有網絡上的 AD 加入資源。這個案例需要有網域信任。安全群組和防火牆規則必須允許兩個作用中目錄之間的通訊。
除了「 AWS Directory Service」的放置之外，上一個圖顯示了從使用者到工作區的流量，以及工作區與 AD 伺服器和 MFA 伺服器的互動方式。
此架構使用下列元件或建構。
## AWS
+ **Amazon VPC** — 創建具有跨兩個 AZ 的至少四個私有子網的 Amazon VPC-兩個用於 AD DS [Microsoft AD，兩個用於 AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) Connector 或. WorkSpaces
+ **DHCP 選項集** — 建立一個 Amazon VPC 端 DHCP 選項集。這可讓客戶定義指定的網域名稱和 DNS (Microsoft AD)。如需詳細資訊，請參閱 [DHCP 選項集](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html)。
+ **選用：Amazon 虛擬私有閘**道 — 啟用透過 IPSec VPN 通道 (VPN) 或 AWS Direct Connect 連線與客戶擁有的網路進行通訊。用於存取內部部署後端系統。
+ **AWS Directory Service** — Microsoft AD 部署到一對專用的 VPC 子網路 (AD DS 受管理服務) 中。
+ **Amazon EC2** — 客戶*可選購* MFA 的半徑伺服器。
+ **Amazon WorkSpaces** — 部署到與 AD Connector 相同的私 WorkSpaces 有子網中。如需詳細資訊，請參閱本文件的 [Active Directory：網站與服務](design-considerations.md#active-directory-sites-and-services)一節。
## 客戶
+ **網路連線** — 企業 VPN 或 AWS Direct Connect 端點。
+ 終**端使用者裝置** — 用於存取 Amazon 服務的企業或 BYOL 終端使用者裝置 (例如視窗、Mac、iPads、安卓平板電腦、零用戶端和 Chromebook)。 WorkSpaces 如需[支援的裝置和 Web 瀏覽器，請參閱用戶端應用程式清](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client)單。
此解決方案需要連線至客戶內部部署資料中心，才能執行信任程序。如果使用 WorkSpaces者正在使用內部部署網路上的資源，則需要考慮延遲和輸出資料傳輸費用。
# 案例 5： AWS Microsoft AD 使用共用服務 Virtual Private Cloud (VPC) (VPC)
此案例如下圖所示，已在 AWS 雲端部署 AWS Managed AD，為已在中託管 AWS 或計劃作為更廣泛移轉一部分的工作負載提供驗證服務。最佳做法建議是將 Amazon 放 WorkSpaces 在專用 VPC 中。客戶也應該建立特定的 AD OU 來組織 WorkSpaces 電腦物件。
若要 WorkSpaces 使用主控受管理 AD 的共用服務 VPC 進行部署，請使用在受管理 AD 中建立的 ADC 服務帳戶部署 AD 連接器 (ADC)。服務帳戶需要權限，才能在共用服務受管理 AD 中的 WorkSpaces指定 OU 中建立電腦物件。
![\[示例架構顯示共享服務 VPC 託管託管 AD，部署 AD Connector。 WorkSpaces\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/microsoft-ad-shared-services-vpc.png)
此架構使用下列元件或建構。
## AWS
+ **Amazon VPC** — 建立具有跨兩個 AZ 的至少兩個私有子網路的 Amazon VPC (兩個用於 AD Connector 和)。 WorkSpaces
+ **DHCP 選項集** — 建立一個 Amazon VPC 端 DHCP 選項集。這可讓客戶定義指定的網域名稱和 DNS (Microsoft AD)。如需詳細資訊，請參閱 [DHCP 選項集](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html)。
+ **選用：Amazon 虛擬私有閘**道 — 啟用透過 IPSec VPN 通道 (VPN) 或 AWS Direct Connect 連線與客戶擁有的網路進行通訊。用於存取內部部署後端系統。
+ **AWS Directory Service** — Microsoft AD 部署到一對專用的 VPC 子網路 (AD DS 受管理服務)、AD Connector
+ AWS 傳@@ **輸道/VPC 對等** — 啟用工作區 VPC 與共用服務 VPC 之間的連線
+ **Amazon EC2** — 客戶*可選購* MFA 的半徑伺服器。
+ **Amazon WorkSpaces** — 部署到與 AD Connector 相同的私 WorkSpaces 有子網中。如需詳細資訊，請參閱本文件的 [Active Directory：網站與服務](design-considerations.md#active-directory-sites-and-services)一節。
## 客戶
+ **網路連線** — 企業 VPN 或 AWS Direct Connect 端點。
+ 終**端使用者裝置** — 用於存取 Amazon 服務的企業或 BYOL 終端使用者裝置 (例如視窗、Mac、iPads、安卓平板電腦、零用戶端和 Chromebook)。 WorkSpaces 如需[支援的裝置和 Web 瀏覽器，請參閱用戶端應用程式清](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client)單。
# 案例 6： AWS Microsoft AD、共用服務 VPC，以及內部部署的單向信任
這個案例 (如下圖所示) 會針對使用者使用現有的內部部署 Active Directory，並在 AWS 雲端中引入個別的受管理 Active Directory 來裝載與 WorkSpaces. 這個案例可讓電腦物件和使用中目錄群組原則獨立於公司的使用中目錄進行管理。
當第三方想要代表客戶管理 Windows WorkSpaces 時，這個案例非常有用，因為它允許協力廠商定義和控制與他們相關聯的 WorkSpaces 和政策，而不需要授予第三方對客戶 AD 的存取權。在這個案例中，會建立特定的使用中目錄組織單位 (OU) 來組織共用服務 AD 中的 WorkSpaces 電腦物件。
**注意**
Amazon Linux WorkSpaces 需要雙向信任才能建立它們。
若要使 WorkSpaces 用來自客戶識別網域的使用者，將 Windows 部署在主控受管理 Active Directory 的共用服務 VPC 中建立的電腦物件，請部署參照公司 AD 的作用中目錄連接器 (ADC)。使用在企業 AD (身分識別網域) 中建立的 ADC 服務帳戶，該帳戶具有委派權限，在組織單位 (OU) 中建立電腦物件，該帳戶是 WorkSpaces 在共用服務受管理 AD 中針對 Windows 設定，且具有公司 Active Directory (身分識別網域) 的讀取權限。
若要確保網域定位器功能能夠驗證身分網域所需 AD 網站中的 WorkSpaces 使用者，請依照 [Microsoft](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/domain-locator-across-a-forest-trust/ba-p/395689) 的說明文件，將兩個網域的 Amazon WorkSpaces 子網路 AD 網站命名為相同。最佳做法是將身分識別網域和共用服務網域 AD 網域控制站與 Amazon 位於相同的 AWS 區域 WorkSpaces。
如需設定此案例的詳細指示，請參閱實作指南，以[ WorkSpaces 使用 AWS 目錄服務為 Amazon 設定單向信任](https://d1.awsstatic.com/Projects/deploy-amazon-workspaces-one-way-trust-with-aws-directory-service.pdf)
在這個案例中，我們會在共用服務 VPC 和內部部署 AD 之間建立單向傳遞信任。 AWS Managed Microsoft AD 圖 11 顯示信任和存取的方向，以及 AWS AD Connector 器如何使用 AD Connector 服務帳戶在資源網域中建立電腦物件。
系統會根據 Microsoft 建議使用樹系信任，以確保盡可能使用 Kerberos 驗證。您從中的資源網域 WorkSpaces 接收群組原則物件 (GPO)。 AWS Managed Microsoft AD此外，您還可以使用您的身份識別域 WorkSpaces 執行 Kerberos 身份驗證。為了可靠地工作，最佳做法是將您的身份域擴展到上面已經解釋的那 AWS 樣。我們建議您查看[ WorkSpaces 使用單向信任資源域與 Directory Service實施指南部署 Amazon](https://aws.amazon.com/getting-started/hands-on/deploy-workspaces-one-way-trust/) 以獲取更多詳細信息。
AD Connector 器和您的 WorkSpaces，都必須能夠與您的身分識別網域和資源網域的網域控制站通訊。如需詳細資訊，請參閱《*Amazon WorkSpaces 管理指南》 WorkSpaces中[的《IP 位址和連接埠需求](https://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html)》*。
如果您使用多個 AD 連接器，最佳做法是讓每個 AD 連接器使用自己的 AD Connector 器服務帳戶。
![\[A 範例架構顯示 Windows，其中 WorkSpaces 包含使用客戶識別網域中的使用者在主控受管理的 Active Directory 中建立的共用服務 VPC 中建立的電腦物件。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/one-way-trust-ad-onprem.png)
此架構使用下列元件或建構：
## AWS
+ **Amazon VPC** — 建立具有跨兩個 AZ 至少兩個私有子網路的 Amazon VPC — 兩個用於 AD Connector 和. WorkSpaces
+ **DHCP 選項集** — 建立一個 Amazon VPC DHCP 選項集。這可讓客戶定義指定的網域名稱和 DNS (Microsoft AD)。如需詳細資訊，請參閱 [DHCP 選項集](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html)。
+ **選用：Amazon 虛擬私有閘**道 — 啟用透過 IPSec VPN 通道 (VPN) 或 AWS Direct Connect 連線與客戶擁有的網路進行通訊。用於存取內部部署後端系統。
+ **AWS Directory Service** — Microsoft AD 部署到一對專用的 VPC 子網路 (AD DS 受管理服務)、AD Connector 中。
+ 傳@@ **輸道/VPC 對等** — 啟用 Workspace VPC 與共用服務 VPC 之間的連線。
+ **Amazon EC2** — MFA 的客戶「可選」半徑伺服器。
+ **Amazon WorkSpaces** — 部署到與 AD Connector 相同的私 WorkSpaces 有子網中。如需詳細資訊，請參閱本文件的 [Active Directory：網站與服務](design-considerations.md#active-directory-sites-and-services)一節。
## 客戶
+ **網路連線** — 企業 VPN 或 AWS Direct Connect 端點。
+ 終**端使用者裝置** — 用於存取 Amazon 服務的企業或 BYOL 終端使用者裝置 (例如視窗、Mac、iPads、安卓平板電腦、零用戶端和 Chromebook)。 WorkSpaces 如需[支援的裝置和 Web 瀏覽器，請參閱此用戶端應用程式清](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client)單。
# 在 Amazon 使用多區域 AWS 託管活動目錄 WorkSpaces
[AWS Directory Service Microsoft 活動目錄](https://aws.amazon.com/directoryservice/active-directory/)（MAD）是一個完全受管的 Microsoft 活動目錄（AD），可以與 Amazon 配對 WorkSpaces。客戶選擇 AWS 受管理的 Microsoft AD，因為它具有內建的高可用性、監控和備份功能。 AWS 管理 Microsoft AD 企業版增加了配置[多區域複製](https://aws.amazon.com/blogs/aws/multi-region-replication-now-enabled-for-aws-managed-microsoft-active-directory/)的功能。此功能會自動設定區域間的網路連線、部署網域控制站，以及跨多個區域複寫所有 Active Directory 資料，確保駐留在這些區域的 Windows 和 Linux 工作負載能夠以低延遲和高效能連線至 AWS MAD 並使用。複寫的 MAD 區域無法[直接註冊 WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/register-deregister-directory.html)，但是複寫的 MAD 目錄可以透 WorkSpaces 過將 AD Connector 器 (ADC) 設定為指向複寫的網域控制站來註冊。
使用 MAD 部署 AD 連接器時，最佳做法是為 WorkSpaces 環境中的每個業務單位建立 AD 連接器。這可讓您將每個業務單位與 Active Directory 中的特定組織單位對齊。然後，您可以在組織單位層級指派 AD 群組原則物件，直接與有問題的業務單位一致。
## 架構
![\[使用 MAD 顯示 AD 連接器的架構範例是為 WorkSpaces 環境中的每個業務單位建立 AD 連接器。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/registering-replicated-mad-region.png)
## 實作
若要註冊複寫的 MAD 區域 WorkSpaces，您必須建立指向您的 MAD 網域控制站 IP 的 AD Connector 器。您可以移至 [[AWS Directory Service] 主控台瀏覽窗格，選取 [目錄](https://console.aws.amazon.com/directoryservicev2/)]，然後選擇正確的目錄識別碼，以尋找您的 MAD 網域控制站 IP 位址。若要建立這些 AD 連接器，請遵循本[指南](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_getting_started.html)。一旦他們被創建，你可以[註冊它們 WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/register-deregister-directory.html)。在新區域 WorkSpaces 中部署之前，請確定您已更新 VPC [DHCP 選項集](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/dhcp_options_set.html)。