Help us understand the problem. What is going on with this article?

10分鐘了解AWS Beanstalk/ECS/Fargate/EKS之間的差異

0. Container Orchestration on AWS

目前在AWS上提供了下面四種方式讓你可以部署你的container到AWS上提供服務,不過其實這四種方式在不同的面向上都有些細微的差異,而筆者自己在side project與工作上的部署也會隨著不同的專案規模與需求來選擇,我們將會分別比較這四種在AWS上提供的solution

  1. Beanstalk
  2. ECS
  3. ECS-Fargate
  4. EKS

1. BeansTalk

AWS Elastic Beanstalk 其實是一項我滿喜歡的服務,除了是較早期推出的服務,也是少數AWS中少數比較面向Developer導向的服務,提供開發者只需要專注在application的開發與source code的管理,一但確定要部署,後續的Auto Scaling, Load Balancer, service monitoring在預設的config下來運行web或是api service都還有可接受的結果。

如果developer有CLI的權限的話,可以搭配Elastic Beanstalk 所提供的CLI, EB CLI,便可以簡單的透過eb init來config你所使用的語言python/go等或是docker,再搭配eb deploy便可以快速的部署你的web application到AWS上。

而在與AWS其他資源的整合上,由於Beanstalk的目標對象比較偏向Web Application,因此如果需要有Database的服務(DynamoDB, RDS)或是File System/Storage(EFS, S3)的整合,基本上都是沒有問題的,詳細的說明可以參考Integrating AWS Services

如果你是個人開發的Side Project或是Start-up在人力有限的狀況下想要快速的部署你的產品或服務上cloud來問世或是做一些MVP,那我覺得Elastic Beanstalk就是你最好的選擇了!

2. ECS

Elastic Container Service(ECS),是一個base在EC2上的container服務,ECS服務本身不收費,但是架設容器服務的EC2以及儲存資源或Load Balancer等服務是要收費的。同時,因為是以EC2為基礎的服務,所以Load Balancer與auto scaling和監控等服務,也都跟使用EC2的經驗上差異不大,在部署與管理上也可以以EC2 instance的部署與管理經驗來做考量。

由於ECS預設是以EC2 instance來管裡,因此必須注意的是在Auto Scaling的設定上,ECS是以AMI來當作scaling的基礎單位,並非以Container來作scaling。

不過,ECS天生在某些地方還是天生神力的

  1. AWS Service高度整合:如果你的container Cluster需要使用到EFS等AWS所提供的File system來進行資源的共享或運算,那ECS在這方面優勢相較於Fargate大勝。
  2. Window Container:相較於Fargate,ECS對於Window container的支援性與可配置程度還是較高,因此如果你的container cluster是以window為基礎的,那還是建議擁抱ECS。
  3. Spot instance:如果你的container是某些需要大量但短期的運算資源,ECS允許使用者以EC2 Spot Instance來launch ECS,如此一來便可以有強大的運算資源但是少少的花費。

3. ECS-Fargate

ECS-Fargate是AWS所提供的全託管的Container服務,首先Fargate讓開發者只需要專注在task中定義單一container所需要的資源(CPU, Mem等),後續的Scaling都可以透過這個預先定義行的task來處理,此外,在Logging的功能上也可以透過task definition來完成,如果需要了解task的設定,可以參考Amazon ECS Task Definitions

相較於ECS,由於Fargate是全託管的服務,因此除了初期需要花點時間完成task definition或是cluster的配置,後續就只需要專注在service上的開發就好,對於小型的團隊在operation上的effort是一大優點,

使用Fargate還有一些隱性的好處,前陣子陸續把一些API的service 轉到Fargate上,而這些API大部分的user都是在亞洲,因此service request大部分會集中在12小時內,相較於原先用ECS是以EC2的instance 24小時來收費,Fargate Pricing在這種非global service的狀況下在service花費上就顯得較為經濟。

4. EKS

Elastic Kubernetes Service (EKS) 是AWS所提供的Kubernetes服務,基本上前面所提到的ECS或是Fargate的優點幾乎都集中在EKS了,可以自動處理container的scaling與load balancer,甚至也可以啟用EKS-optimized AMI with GPU Support來進行機器學習相關的運算。

EKS在安全性上也支援IAM與VPC的網路管理,較強大的應該是EKS整合了Kubernetes RBAC與IAM,可以參考Managing Users or IAM Roles for your Cluster,如果你原先就有使用ECS並且定義了許多的service role,隨著ECS上的Cluster數量漸複雜而面臨管理問題,這種情況下建議可以勇敢的擁抱EKS~

But,EKS初期的部署與後續的維運都是需要有專業的人力來進行的,雖然比起原生的K8S少了架設許多基礎環境,但是EKS內部的許多網路與安全性的設定,還是需要配給專業的工程師來處理會比較好一點。花費的部分就不多談了,理論上如果service規模夠大且需要用到EKS來管理,應該也不會care這一點instance成本了XD。

Summary

綜合來看,我們可以將上面的比較敘述簡單整理成下表,而在實務上的service環境,這四種環境各有優缺點,所以其實沒有哪一種服務是perfect的,還是需要全面性的依照團隊的需求與現況來綜合性的考量,選出最適合的service。

Beanstalk ECS Fargate EKS
Service Cost 低★
Deployment Effort 低★
Configurability 高★ 高★
Operation Effort 低★ 低★
AWS Integrability 高★ 高★
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした