在安全性群組的使用過程中，通常會將所有的雲端服務器放置在同一個安全性群組中，從而可以減少初期配置的工作量。但從長遠來看，業務系統網路的互動將變得複雜和不可控。在執行安全性群組變更時，您將無法明確添加和刪除規則的影響範圍。合理規劃和區分不同的安全性群組將使您的系統更加便於調整，梳理應用提供的服務並對不同應用進行分層。本文推薦您對不同的業務規劃不同的安全性群組，並設定不同的安全性群組規則。
區分不同的安全性群組
公網服務的雲端服務器和內網伺服器盡量屬於不同的安全性群組
是否對外提供公網服務，包括主動暴露某些連接埠對外訪問（例如80、443 等），被動地提供連接埠轉寄規則（例如雲端服務器具有公網IP、EIP、NAT連接埠轉寄規則等），都會導致自己的應用可能被公網訪問到。
2種情境的雲端服務器所屬的安全性群組規則要採用最嚴格的規則，建議拒絕優先，預設情況下應當關閉所有的連接埠和協議，僅僅暴露對外提供需要服務的連接埠，例如80、443。由於僅對屬於對外公網訪問的伺服器編組，調整安全性群組規則時也比較容易控制。
對於對外提供伺服器編組的職責應該比較清晰和簡單，避免在同樣的伺服器上對外提供其他的服務。例如MySQL、Redis等，建議將這些服務安裝在沒有公網存取權限的雲端服務器上，然後通過安全性群組的組組授權來訪問。
如果當前有公網雲端服務器已經和其他的應用在同一個安全性群組SG_CURRENT。您可以通過下面的方法來進行變更。
梳理當前提供的公網服務暴露的連接埠和協議，例如80、443。
建立一個安全性群組，例如SG_WEB， 然後添加相應的連接埠和規則。具體操作，請參見建立安全性群組。
授權策略：允許
協議類型：ALL
連接埠：80/80和443/443
授權對象：0.0.0.0/0
選擇安全性群組SG_CURRENT， 然後添加一條安全性群組規則，組組授權，允許SG_WEB中的資源訪問SG_CURRENT。具體操作，請參見添加安全性群組規則。
授權策略：允許
協議類型：ALL
連接埠：-1/-1
授權對象：SG_WEB
優先順序：按照實際情況自訂[1-100]
將一台需要切換安全性群組的執行個體ECS_WEB_1添加到新的安全性群組中。
登入ECS管理主控台。
在左側導覽列，選擇。
找到安全性群組SG_WEB，在操作列中選擇
> 管理執行個體。在Elastic Compute Service執行個體頁簽中，單擊執行個體加入安全性群組。
在彈出的對話方塊中，選擇執行個體ECS_WEB_1加入到新的安全性群組SG_WEB中，並單擊確定。確認ECS_WEB_1執行個體的流量和網路工作正常。
將ECS_WEB_1從原來的安全性群組中移出。
登入ECS管理主控台。
在左側導覽列，選擇。
找到安全性群組SG_CURRENT，在操作列中選擇
> 管理執行個體。在Elastic Compute Service執行個體頁簽中，選中需要移出安全性群組的執行個體ECS_WEB_1，然後單擊列表下方的移出安全性群組。
在彈出的對話方塊中，單擊確定。
測試網路連通性，確認流量和網路工作正常。
如果工作不正常，將ECS_WEB_1仍然加回到安全性群組SG_CURRENT中，檢查設定的SG_WEB暴露的連接埠是否符合預期，然後繼續變更。
執行其他的伺服器安全性群組變更。
不同的應用使用不同的安全性群組
在生產環境中，不同的作業系統大多數情況下不會屬於同一個應用分組來提供負載平衡服務。提供不同的服務意味著需要暴露的連接埠和拒絕的連接埠是不同的，建議不同的作業系統盡量歸屬於不同的安全性群組。
例如，對於Linux作業系統，可能需要暴露TCP（22）連接埠來實現SSH，對Windows可能需要開通TCP（3389）遠端桌面連線。
除了不同的作業系統歸屬不同的安全性群組，即便同一個鏡像類型，提供不同的服務，如果之間不需要通過內網進行訪問，建議也劃歸不同的安全性群組。這樣方便解耦，並對未來的安全性群組規則進行變更，做到職責單一。
在規劃和新增應用時，除了考慮劃分不同的虛擬交換器配置子網外，同時也應該合理地規劃安全性群組。使用網段+安全性群組約束自己作為服務提供者和消費者的邊界。
具體的變更流程請參見上面的操作步驟。
生產環境和測試環境使用不同的安全性群組
為了更好地進行系統的隔離，在實際開發過程中，您可能會構建多套的測試環境和一套線上環境。為了更合理地進行網路隔離，您需要對不同的環境配置使用不同的安全性原則，避免因為測試環境的變更重新整理到線上，從而影響線上的穩定性。
通過建立不同的安全性群組，限制應用的訪問域，避免生產環境和測試環境連通。同時也可以對不同的測試環境分配不同的安全性群組，避免多套測試環境之間互相干擾，提升開發效率。
僅對需要公網訪問的雲端服務器分配公網IP
不論是傳統網路還是Virtual Private Cloud中，合理地分配公網IP可以讓系統更加方便地進行公網管理，同時減少系統受攻擊的風險。在專用網路的情境下，建立虛擬交換器時，建議您盡量將需要公網訪問的服務區的IP區間放在固定的幾個交換器（子網CIDR）中，方便審計和區分，避免不小心暴露公網訪問。
在分布式應用中，大多數應用都有不同的分層和分組，對於不提供公網訪問的雲端服務器盡量不提供公網IP，如果有多台伺服器提供公網訪問，建議您配置公網流量分發的負載平衡服務來提供公網服務，提升系統的可用性，避免單點故障。詳情請參見負載平衡服務。
對於不需要公網訪問的雲端服務器盡量不要分配公網IP。專用網路中當您的雲端服務器需要訪問公網的時候，優先建議您使用NAT Gateway，用於為VPC內無公網IP的ECS執行個體提供訪問互連網的代理服務，您只需要配置相應的SNAT規則即可為具體的CIDR網段或者子網提供公網訪問能力，避免因為只需要訪問公網的能力而在分配了公網IP（EIP）之後也向公網暴露了服務。具體配置，請參見建立和管理SNAT條目。
最小原則
安全性群組應該是白名單性質的，所以需盡量開放和暴露最少的連接埠，同時儘可能少地分配公網IP。若想訪問線上機器進行任務日誌或錯誤排查的時候直接分配公網IP，掛載EIP雖然簡便，但是會將整個機器暴露在公網之上，更安全的策略是通過跳板機來管理。
使用跳板機
跳板機由於其自身的許可權巨大，除了通過工具做好審計記錄外。在專用網路中，建議將跳板機分配在專有的虛擬交換器之中，對其提供相應的EIP或者NAT連接埠轉寄表。
首先建立專有的安全性群組SG_BRIDGE，例如開放相應的連接埠，如 Linux TCP（22）或者Windows RDP（3389）。為了限制安全性群組的入網規則，可以將能登入的授權對象限制為企業的公網出口範圍，減少被登入和掃描的機率。
然後將作為跳板機的雲端服務器加入到該安全性群組中。為了讓該機器能訪問相應的雲端服務器，可以配置相應的組授權。例如在SG_CURRENT添加一條規則允許SG_BRIDGE訪問某些連接埠和協議。
使用跳板機SSH時，建議您優先使用SSH金鑰組登入。詳情請參見SSH金鑰組。
總之，合理的安全性群組規劃使您在擴容應用時更加遊刃有餘，同時讓您的系統更加安全。