Why using AWS?

其實用雲端平台都可以拉，只是AWS 在亞太地區的用戶其實比較多，印象中是超過50%，換句話說網路上 User and Community 也比較活躍，資源也比較豐盛，討論的次數也相較比較多，更白話一點 「你碰到的問題別人一定也有碰過，除非你的技術太新」

另外，基本上雲端需要的東西AWS 支援完整度很高，所以就以AWS 的來做這次是的主要示範，當然如果有人想要跨雲的話也可以透過 Terraform 來達到，但是這部分就自己在研究研究

事先打預防針：

這系列文是真的會燒錢的，所以如果想要動手做的話，請先確定信用卡是否能支援AWS 帳單！

這系列文是真的會燒錢的，所以如果想要動手做的話，請先確定信用卡是否能支援AWS 帳單！

這系列文是真的會燒錢的，所以如果想要動手做的話，請先確定信用卡是否能支援AWS 帳單！

不過要不要實作看個人，這系列文只會列出遇到的問題而已，大概這樣！

Which Service must be used?

• EC2 : 簡單來講就是computing resource，提供記憶體跟 cpu / gpu 的東西，當然後有儲存空間EBS 的設定 (Note 1 , 2 and 3)
• VPC : VPC 這我就不說了，還有重要的Available Zone and Subnet setting ，這些很重要的原因是因為可能會影響到EKS是否能找到對應的 ClusterIP
• EKS : 就是AWS 上面 k8s 的平台，一個 EKS可以管理很多個 k8s ，但是這邊主要還是會用EKS 因為整合了AWS 上面其他的service ，所以使用上就不用設定太多，就是我們後面會提到的 eks-bluepint
• ECR : AWS 上面放置 Docker Images 的地方，也可以自己花錢放在 Docker Hub上面，但是我覺得都用AWS的在 docker pull 的話可能比較快？畢竟 一個 PyTorch Iamge 都特別肥大，所以會有傳輸檔案的議題跟部署速度的快慢
• IAM : 也很重要的一個服務，因為考慮到你的service 是否能被pod存取，或者執行者是誰，因為有時候使用 Terraform 的事後會建立其他的 resource 所以這邊 service must be using IAM Role/ Policy to access resource
• S3 : 顧名思義就是放東西的地方，在這邊會放 Model Artifact 等等的東西，當然還有 terraform 的 state 的部分
• DynamoDB : DynamoDB 是負責做 Terraform state control, 因為state 可能被改或者調整，因次這邊會做第二次的檢查機制
• RDS : Just for MLFlow to record some metrics and params.
• Security Group: 基本防火牆的概念，主要是限制不要讓別人可以存取你的 Endpoint，畢竟Endpoint 被入侵的話可能會開啟不必要的AWS 支援，但是重要資料被竊取也是很頭痛的議題。
• Application LoadBalancer : Expose Service for internet access.
• Promethus or Grafana ：這部分看使用情況斟酌使用 (Note 3, Note 4)

最後

因為這系列文不是要介紹AWS 的，所以這些基本的service 要對應的東西我就不多說了，大概簡單的說明使用的情境，因此如果不熟悉的話可以選擇 跳過離開或 Dislike

Notes:

1. EC2 大家都知道除了 on-demand 之外，另外一個比較客家的使用方式就是 spot instants
2. GPU 需要另外開 tickets 去申請使用，因為 Account 預設是不給使用的，所以如果有需要的話就是要另外寫信請 support 來開啟
3. EBS 的部分其實AWS 已經支援的很強大了， Mount Volumes is very easy on AWS, 但是這部分如果沒忘記的話，會在 CDK8s 那邊補充說明。
4. Grafana 在AWS 上的計費方式是看建立多少個 Admin/Editor/Viewer，雖然 terraform 可以把建立 user 這件事情寫在 tf 裡面，但是如果你再從重複部署的狀況下，就會多次建立，就會被多次收費⋯⋯ 我就因為這樣被收了75 USD, shit!
5. AWS Promethus 的收費是看logs 的筆數，因此在 k8s 裡面的 prometheus server 不要產生太多 information. 出來就會比較便宜 … XD