AWS網路規劃系列 — 使用Amazon WorkSpaces連接VPC內的Private EC2 Instances

Tony Lin
10 min readMay 21, 2018

--

希望能利用工作之餘,分享使用AWS的心得,由於服務的多是B2B的案例,所以整體的Use Cases會從帶領開發團隊進行中大型專案的角度介紹,此系列網路規劃文章的目標,是透過說明如何使用AWS服務規劃解決方案的網路架構及開發團隊如何Access所部署的Instance 及服務,來解釋IT架構師從傳統On-premise應用專案轉型雲端應用專案可能面臨的問題及解法。

從開發團隊的角度出發,若要進行開發與部署的工作,最基本的要求就是: 如何Access到部署在AWS VPC (Private Subnet)裡的EC2 Instances。在此提醒,此篇文章的前提是所有的EC2 Instances皆部署於VPC內Private Subnet當中,也就是說,如果沒有特別的設定,所有的資源都是私有的而且無法從Internet直接Access.

在提出對應的網路規劃之前,要先考量開發團隊的角色或客戶的安全政策為何?如果你是甲方的IT或開發團隊,通常你可以拿到足夠的權限,例如有PEM的Key並且直接透過Site-to-Site VPN,SSH到VPC的Private Subnet中的Instance. 但如果你是乙方的開發團隊,或公司有較嚴格的權限控管需求,要求開發人員的環境也是納管環境的話,Amazon WorkSpaces全代管服務可以滿足你的需求。

以下將介紹如何配置Amazon WorkSpaces來Access到部署在AWS VPC (Private Subnet)裡的EC2 Instances。

首先,Amazon WorkSpace (開發人員工作的節點 )需要有幾項功能:
1. 可以Access到部署在AWS VPC (Private Subnet)裡的EC2 Instances
2. Developer可以從Internet以安全的方式存取此節點
3. Amazon WorkSpace必須可以Access Internet,安裝必要的軟體及環境

在使用AWS時,對AWS的網路規劃有更深一層的認識是相當重要的,能夠在Provision Computing Resource前,預先規劃好整體的網路架構及High Availability的需求,才能確保未來運行環境的可擴充性及SLA,未來會再以專文介紹更深入的HA主題。

在本文的範例中,需要事先準備的Provision AWS Networking Resources元件,請參考本系列的另一篇文章 AWS網路規劃系列 — 如何建立安全的VPC環境( https://medium.com/@1000lin/aws-network-planning-d1424e171846 ),Provision完成AWS Network Resource 後,再繼續往下。

在Provision Amazon WorkSpaces時,有二個主要元件需要明暸:
WorkSpaces 元件1 : Directory Service(包含AD Server及WorkSpace會部署的位置)
WorkSpace 元件2 : WorkSpace (可以給Developer使用的Windows VM)

請參考以下的部署圖,所使用的資源將以在US West (Oregon) Region,於vpc-workspace (CIDR 為 9.0.10.0/24) 中,分別於二個Availability Zone建立2個subnet (其一為public subnet,其二為private subnet); 在Public Subnet中將會建立(1) NAT Gateway , (2) Directory Service; 在Private Subnet中會建立一個WorkSpace節點。

AWS 部署架構圖

在此海爸用Simple AD做為範例來說明,Directory Service的資訊如下圖,請注意VPC和Subnets欄位的內容,因為接下來Provision的Amazon WorkSpace節點的位置,會受Directory Service的設定所影響。

Sample Directory Service

可以開始建立WorkSpace了,Let’s Go!

選擇Directory
建立你的User Entry
Select Bundle
WorkSpaces Configuration
Review and Launch
稍候等待AWS準備WorkSpace,Application Manager的部分海爸目前還未使用到,暫不介紹
刷新後,會看到目前處理Pending State,等到變成Active之後,就能Login了!

等待的時間會久到你覺得是不是Something Wrong,但通常都沒問題,利用等待時,連線到https://clients.amazonworkspaces.com/並下載你適合的Client。海爸用的是Mac,安裝下去不多說。同時,檢查你的email信箱,你應該會收到一封主旨是”Your Amazon WorkSpace”的信件,裡面鏈結點開可以設定密碼。

Notification email from Amazon

設好密碼後,就來使用Amazon WorkSpaces吧!

打開Amazon WorkSpaces Client 並輸入Registration Code
接著輸入你的帳密
登入後就可以看到屬於自己的WorkSpace

安裝必要的軟體,例如telnet、putty或者任何你需要的東西,就可以開始使用了。

重點來了,這時候我們其實是在vpc-workspace中,建立了一個自己的Windows Desktop環境(也就是WorkSpace節點),但這個環境和我們位於其它VPC的EC2 Instances仍然是獨立的網段,無法Access。建議讀者可以實際試試,舉例你可以輸入指令telnet 9.0.3.100 6379:

海爸有一個ElastiCache的Cluster位於9.0.3.0/24的vpc內,因此可以輸入此指令測試是否連通

如果你看到Connect Failed的錯誤,在請參考本系列的另一篇文章 AWS網路規劃系列 — 如何建立安全的VPC環境( https://medium.com/@1000lin/aws-network-planning-d1424e171846 )中之Peering Connection、Security Group及Network ACL小節。

海爸的潛水時間,深度1米 : 關於ElastiCache Security GroupOpening up the ElastiCache cluster to 0.0.0.0/0 (Step 4.e.) does not expose the cluster to the Internet because it has no public IP address and therefore cannot be accessed from outside the VPC. However, the default security group may be applied to other Amazon EC2 instances in the customer’s account, and those instances may have a public IP address. If they happen to be running something on port 6379, then that service could be exposed unintentionally. Therefore, we recommend creating a VPC Security Group that will be used exclusively by ElastiCache. For more information, see Custom Security Groups.建立另外新增一個Security Group專給ElastiCache Cluster使用,若直接修改該VPC的Default Security Group將會額外開啟不需要的存取權限.
independent security group for redis : security-group-sit-redis
security-group-sit-redis inbound rules

設定完成後,再試一次就能夠成功Telnet連線了,話說Telnet過去看到一片漆黑的Terminal就是代表成功了,有點不是很方便。讓我們在Amazon Workspace上安裝 redis desktop,用GUI畫面來看Redis Cluster。請前往https://redisdesktop.com/下載並安裝後,新增一個Connection來試試。

Redis Desktop — Create Connection and Test it
Redis Desktop Screenshots

--

--

Tony Lin

Enterprise Architecture | Application Architecture | Data Architecture