[AWS] 2022 AWS re:Invent Security 產品介紹 - AWS Security Lake [Preview] (EP2)

 在前一篇 EP1 介紹了, AWS Macie 這個服務

接下來來介紹下一個產品 AWS Security Lake ,但還在 Preview 階段

什麼是 Preview 階段,可參考這篇說明

這邊會分享當時介紹的五個 AWS Security 產品 

快速轉跳頁面至 -----> EP1 EP2 EP3 EP4 EP5

Amazon Security Lake 是一個可將組織中安全資料的來源作彙總、以及標準化和資料管理自動化，並儲存在帳戶的安全資料湖中。
安全資料湖可透過設定的安全分析解決方案來廣泛存取組織的安全資料，以支援威脅偵測、調查和事件回應等使用的情境。
Security Lake 採用開放式網路安全架構框架 (OCSF)，將AWS 安全相關的服務如AWS CloudTrail 與 Amazon GuardDuty 所記錄起來的日誌，以及其他資安合作夥伴，
如PaloAlto與IBM等所蒐集到資料，全部集中到AWS Security Lake；同時也整合分析的工具，如AWS OpenSearch、Amazon Athena等，將蒐集到的日誌資料進行資安分析，更全面地了解整個組織的安全性。

優勢

1. 自動集中來自雲、本地和跨區域自定義安全源的資安分析數據
2. 可優化和管理安全數據以獲得更高效能更高效益的存儲和查詢性能
3. 將所收集到的數據規範為做行業標準化，以便輕鬆地與多種分析工具共享和使用
4. 同時保留對安全數據的控制和所有權

Security Lake 的運作流程

Security Lake 自動將來自雲端、內部部署和自訂來源的安全資料集中儲存到帳戶中專用的資料湖。

並會將收集到的日誌儲存到您的 S3 內，讓你始終掌控並享有資料擁有權。

藉助 Security Lake，可以更全面地了解整個組織的安全資料。還可以改進對工作負載、應用程式和資料的保護。

Amazon Security Lake 的主要功能，會自動收集包括 AWS Route 53、S3 和 Lambda，以及 Security Hub 來自 GuardDuty、Macie 與 Health Dashboard 的日誌和事件來源，

另外，超過50個第三方安全調查結果，也能夠整合到 Security Lake 中，AWS安全合作夥伴可以直接將資料，透過OCSF（Open Cybersecurity Schema Framework）標準格式發送至Security Lake。

Security Lake 分析安全資料，可更全面地了解整個組織的安全性。也可以來助您改善工作負載、應用程式和資料的保護。

安全相關資料包括服務和應用程式日誌、安全提醒以及威脅情報 (例如已知的惡意 IP 地址)，

這些資料是偵測、調查和補救安全事件的真實來源。安全最佳實務需要有效的日誌和安全事件資料管理程序。

Security Lake 可將此程序自動化，並促進解決方案執行串流分析偵測、時間序列分析、使用者和實體行為分析 (UEBA)、安全協同運作和補救 (SOAR)，以及事件回應。

Amazon Security Lake預覽版已經在多個AWS地區上線，包括美東、美西、歐洲，亞太則有東京和雪梨地區。

Security Lake 可以用於你的 AWS Org 去管理你的 Account

選擇一個委託管理員帳戶來管理您的安全數據

也可以去蒐集所有的 Log 像是 CloudTrail , VPC flow log , WAF , DNS 等等的 Log 或是事件
也可以收集單一的 Region,或是多個 Region , 最後你可以選擇收整個 Org 下面的所有 Account 或是單一 Account

SecurityLake能夠自動對傳入的日誌資料建立分割區，並將其轉換成能夠高效儲存和查詢的 Parquet 或 OCSF 格式，促使資料更廣泛安全地分析。管理人員還能夠控制 Security Lake 訂閱者的資料存取層級，遵守資料留存法規要求。

目前已經整合許多第三方資料來源和訂閱服務，支援 OCSF 安全資料的第三方來源包括 Cisco、Palo Alto Networks 和 VMware 等，而支援的第三方自動化分析工具則包含 Datadog、IBM 與 Splunk等

因為支援第三方的分析工具,如畫面上的 Splunk. IBM. Datadog 等等都可以整合到 Security Lake 內做統一管理及查看對於控管上面又更為便利

補充說明:這邊如何跟第三方分析工具作整合,會在 IAM 開一個帳號給Security Lake 去抓取如 Splunk 的權限,在透過 AWS Glue 的爬蟲功能去抓取資料

在 Splunk 或是其他第三方工具中在開啟給這個 aws iam account 權限讓他可以進去撈取即可

Amazon Security Lake 採用 OCSF，這是一種開放標準，有助於從透過 AWS Security Hub 的 50 多項解決方案自動標準化安全問題清單。還有越來越多的技術解決方案可提供 OCSF 格式的資料，並與 Amazon Security Lake 整合。

什麼是 OCSF (開放式網路安全結構描述架構) (Open Cybersecurity Schema Framework)？

OSCF 是用於安全日誌和事件的協作式開放原始碼結構描述。

• OSCF 包含與廠商無關的資料分類法，可減少在各種產品、服務和開放原始碼工具之間標準化安全日誌和事件資料的需求。
• 開源項目為安全數據提供簡化且與供應商無關的分類法
• 無需耗時的前期規範化任務即可加速數據攝取和分析
• 結合來自 OCSF 兼容來源的數據，以打破阻礙安全團隊發展的數據孤島
• 可在任何環境、應用程序或解決方案提供商中採用的開放標準

[AWS] 2022 AWS re:Invent Security 產品介紹 - AWS Macie (EP1)

雖然已經 2023 年了，補一下去年的年度大事，在 AWS 全球年度最大的雲端科技發表會 re:Invent 於 2022/12/2 日在美國拉斯維加斯精彩落幕，現場和線上超過五萬人齊聚一堂 , 在這次的 re:Ivent 更發佈了 13大類以及超過 70 項新服務。

本次我代表公司(iKala)與 AWS Community Hero：Ernest Chiang 一同製作、編審此份懶人包
可參考連結免費 下載 ,也於 12/28 完成 iKala x AWS re:Cap 的活動頁面

這邊會分享當時介紹的五個 AWS Security 產品 

快速轉跳頁面至 -----> EP1 EP2 EP3 EP4 EP5

Amazon Macie 是一個數據資料安全和維護資料隱私的服務

是使用機器學習 (ML)和模式匹配所發現敏感數據、並提供對數據安全風險的可見性，並實現針對這些風險的自動保護管理服務。

Macie 採用機器學習和模式的比對，以更符合成本效益的方式進行大規模掃描敏感資料。

Macie 可自動偵測龐大的數據內容，且不斷擴展的敏感資料進行分類清單，包括個人識別資訊 (PII)，例如姓名、地址和信用卡號。

還提供 Amazon S3 中儲存資料的持續可見性和資料隱私權。

在 AWS 管理主控台中按一下滑鼠或透過單一 API 呼叫，即可輕鬆完成 Macie 的設定。

支援多帳戶支援以及與 AWS Organizations 的整合

在多帳戶組態中，單一 Macie 管理員帳戶可以管理所有成員帳戶，包括建立和管理各帳戶的敏感資料探索任務。

Macie 可透過 AWS Organizations 整合，支援多個帳戶。

安全和機敏資料探索結果會在 Macie 管理員帳戶中進行彙整，然後傳送到 Amazon CloudWatch Events。

現在只要使用一個帳戶，就能與事件管理、工作流程和票證系統整合，或者搭配使用 Macie 探索結果與 AWS Step Functions服務，自動執行修正動作。

本次 re:Ivent 推出的新功能是在，對S3 進行自動機敏數據偵測。 

借助這項新功能，Macie 可以自動且智能地對 S3 存儲桶中的對象進行採樣和分析，檢查它們是否存在敏感數據，例如個人身份信息 (PII)、財務數據和 AWS 憑證。 

然後顯示在 S3 中的所有敏感數據都會在有啟用 Macie 的帳戶中顯示，並為每個存儲桶提供敏感度分數。 

Amazon Macie 使用多種自動化技術，包括按存儲桶名稱、文件類型和前綴等屬性進行資源集群，以最大限度地減少發現 S3 存儲桶中機敏數據所需的數據掃描。 

這有助於您在無需手動配置的情況下持續識別和修復數據安全風險，並降低監控和響應數據安全風險的成本。

只需在 AWS 管理控制台中單擊一下或通過一次 API 調用，即可快速輕鬆地開始使用 Amazon Macie。 

Macie 使用 AWS Organizations 提供多賬戶支持，這讓您可以更輕鬆地跨所有 AWS 賬戶啟用 Macie。 

Macie 應用機器學習和模式匹配技術來自動識別敏感數據並提醒您注意敏感數據，例如姓名、地址、信用卡號或憑證材料。

現有 Macie 賬戶可免費使用前 30 天的自動敏感數據發現。在試用期間，可以在試用期結束後在 Macie 管理控制台中查看運行自動敏感數據發現的預估成本。

透過這項功能,就可以在 Findings 這個頁面內看到個風險等級的漏洞

會告訴你在哪一個 bucket 內的哪一個檔案有高風險都可以在 Macie 的這個新服務內一目了然

更為方便的管理,尤其是可以透過 Org 做跨帳號的統整可以看到旗下的所有bucket 內是否有風險產生

[AWS] AWS Migration Strategies (7 Rs) 7R搬遷策略

 AWS 7 Rs 遷移策略

Rehost

這種方案對於企業用戶而言是最容易實現, 利用 AWS 工具輕易遷移完成, 雖然不能完全發揮AWS雲端優勢, 能讓技術人力短缺的企業用戶快速遷移.

Replatform

這種方案需要經過一些優化或是修改套件後進行遷移, 不需要修改程式碼和開發新的程式, 例如現有的 MySQL 資料庫轉移上 RDS 或升級到 Amazon Auroea.

Repurchase

顧名思義就是重新購買, 完全捨棄舊有的軟體, 終止 license 續約, 進而使用新的軟體取代, 可能會遇到新軟體上的學習過程及費用的成長, 但以長期來看會有良好的效益.

Refactor/Re-architect

這種方案需要重新編寫程式碼, 符合雲端服務環境, 這種方案適合企業服務需要加速服務表現, 增加彈性或是地端上無法實現的新功能, 重新建構服務最企業相對有利, 但是會花費大量成本.

Retire

這種方案用來檢視所有服務, 有些古老的軟體環境不一定適合雲端平台, 或是不符使用, 可以藉此機會淘汰.

Retain

有一些服務結束後不再繼續使用, 但是目前還是需要運行, 如果決定不需要再使用這些服務, 就不需要遷移, 結束後直接停用即可.

Relocate 

不需要購買新的硬體, 修改或重寫APP即可搬遷至雲端上, 此方案限定於使用 VMware Cloud on AWS. 可以搭配使用 VMware Cloud Foundation 技術來遷移您設備. 

[1] 評估移轉至AWS雲端期間要淘汰之應用程式的最佳做法

[AWS] GWS User AD Join to Login AWS Account

最近剛好做到一個 Case,客戶是使用 GWS AD Account
有同時使用 GCP & AWS Service,但 IT 想統一 Account 去做管理

此步驟獻給類似需求情境的管理員們,同樣的 AzureAD 也是類似方法

Step1. 登入 要加入的 GWS Admin 管理介面

A. 選擇 Security > Authentication > SSO with SAML applications.

B. 拉到最下面, Download Metada

 Step2. 新增 IAM SAML Identity Provider 在 AWS Account

A. 首先登入想加入的 AWS Account 的 IAM Service

B. 並點選 IAM Service 下的 Identity Providers

C. 點選右邊 Add Provider

D. 點選 SAML

E. Provider Name (自行輸入,這邊是輸入 Join 的 GWS Domain)

F. Medata document (把剛剛在 GWS 端下載的檔案上傳上來)

G. 建置好後會取得 ARN 碼,這很重要 (複製下來貼旁邊)

Step3. 新增 AWS IAM Role 給予 透過 Identity Provider 的 GWS Account 權限 

A. 進入 IAM Console,選擇 Role > Create Role

B. 選擇 SAML 2.0 federation 下拉選單會帶出剛建立的 Provider

C. 然後點選 Allow programmatic and AWS Management Console Access

D. 點選 Next : Permissions 

E. 通過篩選把 AWS 預設 Role 帶出

F. 點選 左上方 放大鏡符號

G. 選取 Type > AWS managed – job function

H. 選擇 PowerUserAcces 後,點選下一步

I. Role details 輸入 Role 名稱 (GoogleSAMLPowerUserRole)

J. Description 輸入 Role 的大概內容 (GWS Login PowerUser Role)

K. 拉到最底,點選 Create Role

L. 建好後會看到你新建的 Role

M. 建置好後會取得 ARN 碼,這很重要 (複製下來貼旁邊)

N. 如需新增其他 Role ,重覆 Step 3 所有步驟即可即可

•  Role 1 GoogleSAMLPowerUserRole_Login
  • arn:aws:iam::174XXXXXXXXX:role/GoogleSAMLPowerUserRole_Login

 Step4. 給予 GWS User AWS IAM Role

A. 回到 GWS Admin Console

B. 點選 Directory > Users > More Option > Manage custom attributes

C. Category: AWS
        Description: Amazon Web Services Role Mapping
D. Custom fields, enter the following values:
        Name: AssumeRoleWithSaml
        Info type : Text
        Visibility : Visable to user and admin

        InNo of Values : Muti-value

        E. 回到 Users 端,選擇要加入的 User Account
        F. 點選 User > User Information

        G. 移到最下面有個 AWS 的,點選編輯

        H. 這時輸入最一開始拿到的 Identitiy Providers + IAM Role ARN

                這邊要特別注意,兩個組合再一起時,中間要用 , 分開

例如 : 

arn:aws:iam:: 174XXXXXXXXX::samlprovider/Dev.Cloud.XXX.tv ”,”arn:aws:iam:: 174XXXXXXXXX:role/GoogleSAMLPowerUserRole

I. 一行是一個 Role,假設你需要給予兩個或是更多的 Role

        請依照同樣方式 Identitiy Providers,IAM Role ARN

J. 假設你有多個 AWS Account 也可以依照前面步驟

        從 Step 2 開始,在另一個 AWS Account 用同樣步驟進行

        Step 3 在另一個 AWS Account用同樣步驟進行

        Step 4 開始,但只需要從 E 項目開始把其ARN 新增至 User Information內即可

K. 可看到我同時有兩個不同AWS Account的 Providers + Role ARN

Step 5. 在 GWS 端設定 SAML Application 給 AWS Login 

A. 進到GWS Admin 管理介面
B. 點選左邊 Apps > Web and Mobile apps 

C. 選取 Add custom SAML App 

 D. App name : 輸入 AWS Login (顯示在右上角選單內的名稱)

        APP Icon : 上傳一個圖示(顯示在右上角選單內的圖示)

E. 點選下一步

        Services Provider Details

• ACS URL : https://signin.aws.amazon.com/saml
• Entity ID : urn:amazon:webservices
• Name ID format : EMAIL
• Name ID : Basic Information > Primary email

F. 點選下一步

        在 Attributes 內新增

• 項次一 AWS 選擇 AssumeRoleWithSaml
• App attributes 輸入 https://aws.amazon.com/SAML/Attributes/Role
• 項次二 Base Information 選擇 Primary email
•  App attributes 輸入
•  https://aws.amazon.com/SAML/Attributes/RoleSessionName

    G.     按下 Finish 即完成

    H.     在來回到 Web and Mobile Apps 內,點選剛新增的 SAML APP

    I.     進入 User Access 把 Service Status 開城 ON for everyone

 J. 回到上一頁,按下 TEST SAML Login 就會出現,你配置的 Domain

或是點選右上角 APP 選單,往下滑也會有你建制的 SAML APP

K. 點選後就會出現 AWS Account and 你所賦予的 Role 權限

        此 Demo 建置了兩個 AWS Account 兩個 Role

L. 依據不同的權限,不同的帳號做登入測試

 

Step 6. 查找登入 Login Log 

A. GWS 端該如何查詢 Login Log

Console > Reporting > Audit and investigation > SAML log events

 B. AWS 端該如何查詢 Login Log

AWS Console > CloudTrail > Event history

 

 

 

[AWS] AWS Organizations 中 OU and SCP 權限配置邏輯

管理組織單位 (OU) : 可以使用組織單位 (OU) 將帳戶群組在一起，以單一單位的形式進行管理。這可大幅簡化帳戶的管理，可以將以政策為基礎的控制連接到 OU，而 OU 內的所有帳戶會自動繼承政策。您可以在單一組織內建立多個 OU，您也可以在其他 OU 內建立 OU。每個 OU 可以包含多個帳戶，而且您可以在 OU 之間移動帳戶。但是，OU 的名稱在父系 OU 或根中必須是唯一的。

服務控制政策 (SCP) : 服務控制政策 (SCP) 是一種組織政策類型，可用來管理組織中的許可。SCP 可集中控制組織中所有帳戶可用的許可上限。SCP 可協助您確保您的帳戶符合組織的存取控制指導方針。SCP 只有在啟用所有功能的組織中才能使用。

SCP 很重要的規則: 1. SCP 是定義權限的範圍並不是賦予權限 2. SCP 預設都是 Deny 的權限，除非明確 Allow 相關的權限 3. Deny 的權限高於 Allow 權限，並且 Deny 權限預設繼承到每一個 OU 和帳號上

Deny list strategy:

1. SCP 預設都是 Deny 的權限，所以在完全沒有附加任何的 SCP 時，在 root 和 OU上所有的權限都是Deny。
2. 當我們採取反向列表的方式來拒絕部分的權限時，預設都會在 root 和每一個 OU上都自動附加FullAWSAccess。
3. 因為 Deny 的權限高於 Allow 權限並且 OU 也會預設繼承 Deny 的權限，所以該 OU 的範圍內將只剩下預設 Deny 的權限和 DisableOrg，雖然有繼承 FullAWSAccess，但因為 OU 上明確的 Deny 權限將完全取代繼承下來的 FullAWSAccess。

Allow list strategy: 1. SCP 預設都是 Deny 的權限，所以在完全沒有附加任何的 SCP 時，在 root 和 OU 上所有的權限都是Deny。 2. 我們只需要允許 EC2 的權限，所以在 root 附加 FullEC2Access，這時候因為 OU 內預設是 Deny 的權限，即使 FullEC2Access 有繼承下來，但因為 OU 本身的權限優先於繼承下來的權限，所以這時候 OU 內還是Deny的狀態。 3. 當我們在 OU 上附加 FullEC2Access 後，因為明確的賦予 EC2 的權限，所以 OU 底下的帳號將可以擁有 EC2 的權限。 所以在 root 和每一個 OU 上的權限必須是明確附加的 Allow 權限，一旦沒有明確的附加 Allow 權限將會被 Deny權限給取代，所以繼承的 Allow 權限將被 OU 內預設 Deny 的權限給取代，以下是繼承的規則: 1. SCP 內如果定義 Allow 權限將需要在每一個需要這個權限的地方都附加上去。 2. SCP 內如果定義 Deny 權限，將可以發揮繼承的效果，在 OU 或子 OU 上發揮作用。

[Alibaba Cloud] Nas 介紹

阿里雲文件存儲服務 NAS

（Apsara File Storage）

是面向阿里雲 ECS 實例、E-HPC 和 容器服 務等計算節點的文件存儲服務。

是一種可共享訪問、彈性擴展、高可靠以及高性能的分佈式文件系統。

NAS 基於 POSIX 文件接口，適配原生操作系統，提供共享訪問，同時保證數據一致性。

提供了簡單的可擴展文件存儲以供與 ECS 配合使用，多個 ECS 實例可以同時訪問NAS文件系

統，並且存儲容量會隨著您添加和刪除文件而自動彈性增長和收縮，為在多個實例或服務器上運

行產生的工作負載和應用程序提供通用數據源。

NAS在成本、安全、簡單、可靠性以及性能上都具有自身的優勢。

成本

• 一個 NAS 文件系統可以同時掛載到多個計算節點上，由這些節點共享訪問，從而節約大量拷貝與同步成本。

• 單個 NAS 文件系統的性能能夠隨存儲容量線性擴展，使用戶無需購買高端的文件存儲設備，大幅降低硬件成本。

• 使用 NAS 文件存儲，您只需為文件系統使用的存儲空間付費，不需要提前配置存儲，並且不存在最低費用或設置費用。更多詳情，請參見產品定價。

• NAS的高可靠性能夠降低數據安全風險，從而大幅節約維護成本。

簡單

• 一鍵創建文件系統，無需部署維護文件系統。

安全

• 基於 RAM 實現的資源訪問控制，基於 VPC 實現的網絡訪問隔離，結合文件存儲 NAS 的傳輸加密與存儲加密特性，保障數據不被竊取或篡改。

高可靠性

• 文件存儲 NAS 的數據在後端進行多副本存儲，每份數據都有多份拷貝在故障域隔離的不同設備上存放，提供99.999999999%的數據可靠性，能夠有效降低數據安全風險。

高性能

• 基於分佈式架構文件系統，隨著容量的增長性能線性擴展，提供遠高於傳統存儲的性能。

兼容性

• NAS 文件存儲提供良好的協議兼容性，支持 NFS 和 SMB 協議方案，兼容 POSIX 文件系統訪問語義，提供強大的數據一致性和文件鎖定。
• 在 NAS 中，任何文件修改成功後，用戶都能夠立刻看到修改結果，便於用戶實時修改存儲內容。

Nas 的優勢在於他跟 SMB NFS 一樣有良好的兼容性,適合使用於 Windwos 及 Linux 系統 

下表為 ECS 雲伺服器可掛載之後端儲存空間的比較表

[Alibaba Cloud] OSS 介紹

 Object Storage Service (對象儲存服務)

阿里雲對象儲存服務（Object Storage Service，簡稱 OSS）

是阿里雲提供的海量、安全、低成本、高可靠的雲端儲存體服務。

它具有與平台無關的 RESTful API 介面

能夠提供 99.999999999%（11個9）的數據可靠性和 99.99% 的服務可用性。

可以在任何應用、任何時間、任何地點儲存和訪問任意類型的數據

儲存空間（Bucket）是用於儲存物件（Object）的容器，所有的對象都必須隸屬於某個儲存空間。你可以設定和修改儲存空間屬性用來控制地域、存取權限、生命週期等，這些屬性設定直接作用於該儲存空間內所有對象，因此可以通過靈活建立不同的儲存空間來完成不同的管理功能。

•同一個儲存空間的內部是扁平的，沒有檔案系統的目錄等概念，所有的對象都直接隸屬於其對應的儲存空間。

•每個用戶可以擁有多個儲存空間。

•儲存空間的名稱在 OSS 範圍內必須是全域唯一的，一旦建立之後無法修改名稱。

•儲存空間內部的對象數目沒有限制。

Object 對象是 OSS 儲存數據的基本單元，也被稱為 OSS 的檔案。
Object 是由元資訊（Object Meta），用戶數據（Data）和檔案名（Key）組成。
Object 由儲存空間內部唯一的 Key 來標識。 Object Meta 是一個鍵值對
表示了對象的一些屬性比如最後修改時間大小等資訊，同時也可以在元資訊中儲存一些自訂的資訊。
Object 的生命週期是從上傳成功到被刪除為止。在整個生命週期內，對象資訊不可變更。
重複上傳同名的對象會覆蓋之前的對象，因此 OSS 不支援修改檔案的部分內容等操作。
OSS 提供了追加上傳功能，用戶可以使用該功能不斷地在 Object 尾部追加寫入數據。

Region 地域是表示 OSS 的資料中心所在物理位置。

可以根據費用、請求來源等綜合選擇資料存放區的地域。

Endpoint 表示是 OSS 對外服務的訪問網域名稱。

OSS 以 HTTP RESTful API 的形式對外提供服務，當訪問不同地域的時候

需要不同的網域名稱。通過內網和外網訪問同一個地域所需要的網域名稱也是不同的。

Region 是在建立 Bucket 的時候指定的，一旦指定之後就不允許更改。

該 Bucket 下所有的 Object 都儲存在對應的資料中心

目前不支援 Object 等級的 Region 設定。

存取金鑰（AccessKey）簡稱 AK

是指的是訪問身分識別驗證中用到的 AccessKeyID 和 AccessKeySecret。

OSS 通過使用 AccessKeyID 和 AccessKeySecret 對稱式加密的方法來驗證某個請求的寄件者身份

AccessKeyID 用於標識用戶，AccessKeySecret 是用戶用於加密簽名字元串和 OSS 用來驗證簽名字元串的密鑰，其中 AccessKeySecret 必須保密。

•Bucket 的擁有者申請的 AccessKey。

•被 Bucket 的擁有者通過 RAM 授權給第三方要求者的 AccessKey。

•被 Bucket 的擁有者通過 STS 授權給第三方要求者的 AccessKey。

OSS Standard (標準存儲)

高可靠、高可用、高吞吐和低延時的對象存儲服務
支持頻繁的數據訪問，支撐各種熱點類應用的使用場景
 

OSS Infrequent Access (低頻率訪問)
適用於訪問頻度較少、長期（30天以上）的數據存儲，比標準類型更低的存儲費用。
 

OSS Archive Storage (歸檔存儲)
適合需要長期保存（建議半年以上）的歸檔數據，在儲存周期內極少被訪問，數據進入到可讀取狀態需要等待1分鐘的解凍時間。適合需要長期保存的檔案數據、醫學影像、科學資料、影視素材。

[Alibaba Cloud] ECS 介紹

阿里雲 - ECS 

下圖是 ECS 所涵蓋的服務內容

Adminstrator Access (Console or API)

ECS 配置選型

入門型： 1 vCPU 1 GB 記憶體（ecs.xn4.small），搭配40 GB 高效雲端碟和 1 Mbps 公網    頻寬，適用於訪問量較小的個人網站初級階段

基礎型： 1 vCPU 2 GB記憶體（ecs.n4.small），搭配40 GB高效雲端碟和2 Mbps公網頻寬，適用於流量適中的網站、簡單開發環境、代碼存放庫等

通用型： 2 vCPU 4 GB記憶體（ecs.n4.large），搭配40 GB高效雲端碟和2 Mbps公網頻寬，能滿足90%雲端運算初級使用者的需求，適用於企業運營活動、並行計算應用、普通資料處理。

進階型： 4 vCPU 16 GB記憶體（ecs.sn2ne.xlarge），搭配40 GB高效雲端碟和5 Mbps公網頻寬，適用於中大規模訪問量的網站、分布式分析及計算場景和Web應用程式。

ECS 執行個體的計費方式     

訂用帳戶：是一種預付費模式，即先付費再使用，按月計費，單位為USD/月。一般適用於固定的 7*24 服務，如Web服務等。

隨用隨付：是一種後付費模式，即先使用再付費，按秒計費，單位為USD/小時。執行個體從建立到釋放的生命週期內不足USD 0.01，將補齊按照USD 0.01收取。一般適用於有爆發業務量的應用或服務，例如臨時擴充、臨時測試、科學計算等。

ECS 升降配概述

你只能同時升級或降低執行個體的vCPU核心數和記憶體大小（即 執行個體規格類型系列），不能單獨調整其中一個配置。根據執行個體的計費方式，您必須使用不同的功能修改執行個體配置：

訂用帳戶：

升級執行個體配置：使用 預付費執行個體升級配置 功能隨時升級執行個體規格。操作完成後，您必須 重啟執行個體 或使用 RebootInstance 介面重啟執行個體，新配置才能生效。

降低執行個體配置：使用 續費降配 功能，在續費的同時降低執行個體規格。進入新計費周期後，您需要在7天內在控制台 重啟執行個體 使新的執行個體規格生效。

隨用隨付：

使用 隨用隨付執行個體變更執行個體規格 功能修改隨用隨付執行個體的配置。您必須先停止執行個體才能使用這個功能。

ECS 設備規格

    企業級x86運算規格類型系列，包括：

                   · 通用型執行個體規格類型系列 g5

· 通用網路增強型執行個體規格類型系列 sn2ne

· 密集計算型執行個體規格類型系列 ic5

· 計算型執行個體規格類型系列 c5

· 計算網路增強型執行個體規格類型系列 sn1ne

· 記憶體型執行個體規格類型系列 r5

· 記憶體網路增強型執行個體規格類型系列 se1ne

· 記憶體型執行個體規格類型系列 se1

· 大資料網路增強型執行個體規格類型系列 d1ne

· 大資料型執行個體規格類型系列 d1

· 本地SSD型執行個體規格類型系列 i2

· 本地SSD型執行個體規格類型系列 i1

· 高主頻計算型執行個體規格類型系列 hfc5

· 高主頻通用型執行個體規格類型系列 hfg5

· 高主頻計算型執行個體規格類型系列 ce4

    企業級異構運算規格類型系列 ，包括：

· GPU計算型執行個體規格類型系列 gn5

· GPU計算型執行個體規格類型系列 gn4

· FPGA計算型執行個體規格類型系列 f1

· FPGA計算型執行個體規格類型系列 f2

ECS Bare Metal Instance（神龍）和Super Computing Cluster（SCC）執行個體規格類型系列群，包括：

· 高主頻型ECS Bare Metal Instance執行個體規格類型系列 ebmhfg5

· 計算型ECS Bare Metal Instance執行個體規格類型系列 ebmc4

· 通用型ECS Bare Metal Instance執行個體規格類型系列 ebmg5

· 高主頻型Super Computing Cluster執行個體規格類型系列 scch5

· 通用型Super Computing Cluster執行個體規格類型系列 sccg5

入門級x86運算規格類型系列，包括：

· 突發效能執行個體規格類型系列 t5

· 上一代入門級執行個體規格類型系列 xn4/n4/mn4/e4

ECS 續費方式

        手動續費：

                    ○ 續費時不能調整執行個體配置。

                    ○ 支援的續費時長：1個月或1年。

自動續費：

                    ○ 續費時不能調整執行個體配置。

                    ○ 支援的續費時長：按執行個體當前的計費周期續費。

續費降配：

                    ○ 續費時可以調整執行個體配置。

                    ○ 支援的續費時長：1個月或1年。

   建立雲端碟只能採用 "隨用隨付",每個帳號在所有地域建立作資料盤用的隨用隨付雲端碟限額 = 該帳號在所有地域的隨用隨付執行個體數量 * 5

阿里雲ESSD（Enhanced SSD，增強型SSD）雲端硬碟結合25 GE網路和RDMA技術，為您提供單盤高達100萬的隨機讀寫能力和單路低時延效能。

ECS 雲端碟加密方式

        ECS 雲端碟加密功能依賴於同一地域的 金鑰管理服務（Key Management Service，KMS)

當你在一個地域第一次使用加密盤時，ECS 系統會為您在金鑰管理服務（KMS）中的使用地域自動建立一個專為 ECS 使用的使用者主要金鑰（Customer Master Key，CMK），這個使用者主要金鑰，您將不能刪除，您可以在金鑰管理服務控制台上查詢到該使用者主要金鑰。使用AES-256 進行加密，每個阿里雲 ECS 帳號在每個地域都具有一個唯一的使用者主要金鑰（CMK），該密鑰與資料分開，儲存在一個受嚴格的物理和邏輯安全控制保護的系統上

對加密雲端碟的管理操作包括：

                建立加密盤（CreateInstance 或 CreateDisk）

○ 掛載（AttachDisk)

○ 卸載（DetachDisk）

○ 建立快照（CreateSnapshot）

○ 回滾雲端碟（ResetDisk）

○ 重新初始化雲端碟（ReInitDisk）

ECS 雲端碟加密有如下限制：

                 只能加密雲端碟，不能加密本地碟。

○ 只能加密資料盤，不能加密系統盤。

○ 已經存在的非加密盤，不能直接轉換成加密盤。

○ 已經加密的雲端碟，也不能轉換為非加密雲端碟。

○ 已經存在的非加密盤產生的快照，不能直接轉換成加密快照。

○ 加密快照不能轉換為非加密快照。

○ 不能共用帶有加密快照的鏡像。

○ 不能跨地域複製帶有加密快照的鏡像。

○ 不能匯出帶有加密快照的鏡像。

○ 每個地域每個使用者無法自己選擇使用者主要金鑰 CMK，由系統為您生成。

○ 每個地域 ECS 系統建立的使用者主要金鑰（CMK），使用者不能刪除，但不收費用。

○ 不支援在雲端碟加密後更換該雲端碟用於加解密的關聯的使用者主要金鑰

ECS 快照 彈性區塊存放裝置保有數量 * 64

IMG 提供的公共鏡像中，僅Linux或類Unix鏡像免費。Windows鏡像則要收費

其他相關介紹

ECS 管理工具

○ ECS console

○ ECS API

○ Alibaba Cloud CLI

○ OpenAPI Explorer

○ Alibaba Cloud SDK

○ Resource Orchestration Service (ROS)

○ Terraform

Deployment suggestions

○ Region and zone

○ High availability

○ Set up network connections

○ Security solutions

Related services

○ Auto Scaling

○ Dedicated Host (DDH)

○ Container Service for Kubernetes

○ CloudMonitor

○ Server Load Balancer (SLB)

○ ApsaraDB RDS

○ Alibaba Cloud Marketplace

Benefits

○ High availability

○ Security

○ Elasticity

○ Scenarios

· Official websites and lightweight web applications

· Multimedia and high-concurrency applications or websites

· Databases with high I/O requirements

· Applications and websites with sharp traffic fluctuations

· Big data and real-time online and offline analysis

· AI applications such as machine learning and deep learning

Regions

中國境內 Region

中國境外 Region

 Alibaba Cloud regions in mainland China are almost the same. BGP networks ensure fast access to all regions in mainland China.

這邊要特別注意

· RDS instances 內的 ApsaraDB 在不同區域中創建的 OSS 存儲桶無法通過內部網絡相互通信

· SLB無法平衡來自部署在不同區域中的ECS的請求。 在不同地區購買的ECS實例無法部署在同一SLB實例下

· ECS 不能再另外虛擬化,沒辦法在裡面安裝 VMWare等虛擬化軟體

· Log Service 不支援32 bits 的 Linux ECS

· 外接 USB 等相關設備無法直接連接到 ECS 上面做使用

· ECS上部署的網站申請ICP歸檔，請確保該實例滿足ICP歸檔要求。可以為每個ECS實例申請數量有限的ICP備案服務編號

· 帳號需要實名認證