Các dịch vụ chính của AWS

EC2 là viết tắt của Amazon Elastic Compute Cloud, cung cấp năng lực tính toán có thể thay đổi kích thước, tức là máy chủ ảo. S3 là Amazon Simple Storage Service, lưu trữ dữ liệu với dung lượng bất kỳ dưới dạng đối tượng (object). Việc nhầm lẫn hoán đổi hai dịch vụ này đã xảy ra từ lâu, nên cần ghi nhớ vai trò gắn liền với cách viết tên gọi. Thực thi mã của hàm là Lambda, chia sẻ tệp tin là EFS.

Lambda có thể thực thi mã mà không cần cấp phát hay quản lý máy chủ, và chỉ bị tính phí cho thời gian tính toán đã tiêu thụ. Việc không phát sinh phí trong thời gian mã không được thực thi là điểm khác biệt lớn so với EC2, vốn phát sinh chi phí chừng nào còn đang chạy. Số lượng hàm hay dung lượng mã đã tải lên tự nó không phải là đơn vị tính phí.

Serverless không có nghĩa là không có máy chủ vật lý, mà có nghĩa là người dùng không cần thực hiện việc mua sắm, cấu hình, mở rộng máy chủ. Lambda được mô tả là "có thể thực thi mã mà không cần cấp phát hay quản lý máy chủ", còn Fargate được mô tả là "không cần cấp phát, cấu hình, mở rộng máy chủ hay cụm (cluster)". Máy chủ vật lý vẫn nằm ở phía AWS, còn việc người dùng tự quyết định loại hệ điều hành và chính sách vá lỗi là hình thức như EC2.

Fargate là công cụ tính toán serverless tính phí theo mức dùng dành cho container, không cần cấp phát, cấu hình, mở rộng máy chủ hay cụm, được dùng như một loại hình khởi chạy (launch type) của ECS hoặc EKS. Việc vận hành quản lý Kubernetes là EKS; tự chọn loại instance và số lượng là loại hình khởi chạy EC2; định nghĩa trình tự dưới dạng luồng công việc là Step Functions.

Hai lựa chọn năng lực cơ bản của ECS là Fargate — serverless, AWS quản lý nền tảng — và EC2, nơi người dùng tự chọn và quản lý loại instance cùng số lượng. Ngoài ra còn có ECS Managed Instances, và ECS Anywhere dành cho on-premise. Dù chọn loại nào thì việc bố trí và mở rộng container vẫn do ECS thực hiện, điểm khác biệt duy nhất chỉ là ai chịu trách nhiệm chăm sóc nền tảng.

EKS là Amazon Elastic Kubernetes Service, một dịch vụ được quản lý cho phép chạy Kubernetes trên AWS mà không cần tự cài đặt và vận hành cụm Kubernetes, và đã được chứng nhận tuân thủ Kubernetes. Tự động hóa việc vận hành cơ sở dữ liệu là RDS; phân phối nội dung từ nơi gần là CloudFront; phân phối lưu lượng là Elastic Load Balancing.

Lambda có thể thực thi mã mà không cần quản lý máy chủ, chỉ bị tính phí cho thời gian tính toán đã tiêu thụ, và không phát sinh phí trong thời gian không được thực thi. Do đó với xử lý được gọi thưa thớt, Lambda sẽ có lợi hơn vì không tốn chi phí trong thời gian chờ. Cấu trúc chạy liên tục cụm EC2 hay EKS sẽ tiếp tục tốn chi phí trong phần lớn thời gian mà xử lý không hoạt động.

EC2 là dịch vụ cung cấp năng lực tính toán an toàn, có thể thay đổi kích thước trên đám mây, và theo mô tả chính thức thì người dùng chỉ trả tiền cho phần đã dùng, đồng thời có thể kiểm soát hoàn toàn tài nguyên tính toán. Việc chỉ tính phí thời gian thực thi và không cần chạm vào hệ điều hành là Lambda; lưu trữ theo đối tượng là S3; định nghĩa luồng công việc dưới dạng trạng thái là Step Functions. Vì phạm vi kiểm soát được rộng nên cũng cần nhớ rằng việc quản lý hệ điều hành vẫn ở lại phía người dùng.

ECS là Amazon Elastic Container Service, một dịch vụ điều phối container (container orchestration) được quản lý hoàn toàn, giúp việc triển khai, quản lý và mở rộng quy mô ứng dụng đã đóng gói container trở nên dễ dàng. Cung cấp cụm tuân theo Kubernetes là EKS; khởi động máy chủ ảo là EC2; thực thi mã theo sự kiện là Lambda. ECS và EKS đều gộp các container lại nhưng khác nhau ở việc có sử dụng Kubernetes hay không.

EKS là dịch vụ được quản lý cho phép chạy Kubernetes trên AWS mà không cần tự cài đặt và vận hành cụm Kubernetes, đã được chứng nhận tuân thủ Kubernetes. Còn ECS là dịch vụ điều phối container được quản lý hoàn toàn của AWS, không lấy Kubernetes làm tiền đề. Cả hai đều là dịch vụ xử lý container, không phải chỉ xử lý image máy chủ ảo. Về nơi khởi chạy, cả hai đều có thể chọn Fargate.

EBS là bộ nhớ lưu trữ khối (block storage) bền vững dùng cho instance EC2, được tự động nhân bản (replicate) trong phạm vi một vùng khả dụng, và về nguyên tắc chỉ gắn (attach) với một instance duy nhất. EFS là hệ thống tệp tin dành cho workload Linux, dung lượng tự động co giãn, hỗ trợ truy cập chia sẻ song song từ hàng nghìn instance EC2. Bên có thể chia sẻ là EFS, không phải cả hai đều hướng tới chia sẻ, cũng không phải cả hai đều chỉ dùng để kết nối đơn lẻ.

S3 là Amazon Simple Storage Service, một bộ nhớ lưu trữ đối tượng có khả năng mở rộng và tính khả dụng cao, có thể lưu trữ và bảo vệ dữ liệu với dung lượng bất kỳ. Bộ nhớ lưu trữ khối là EBS; hệ thống tệp tin chia sẻ dành cho Linux là EFS; bộ nhớ đệm trong bộ nhớ là ElastiCache. Sự khác biệt giữa ba cách lưu giữ đối tượng, khối, tệp tin là điểm khởi đầu khi lựa chọn bộ nhớ lưu trữ của AWS.

EFS là bộ nhớ lưu trữ tệp tin có dung lượng tự động co giãn theo số lượng tệp tăng giảm, hỗ trợ truy cập chia sẻ song song từ hàng nghìn instance EC2, nên phù hợp với mục đích cùng gắn và đọc ghi đồng thời một thư mục từ nhiều instance. EBS là bộ nhớ khối trong phạm vi một vùng khả dụng, về nguyên tắc gắn với một instance nên vùng lưu trữ của mỗi máy sẽ tách biệt. Glacier Deep Archive là lớp lưu trữ dành cho archive, mất thời gian khi lấy dữ liệu ra; ElastiCache là bộ nhớ đệm trong bộ nhớ, không phải hệ thống tệp tin.

EBS là bộ nhớ lưu trữ khối bền vững dành cho instance EC2, được tự động nhân bản trong phạm vi một vùng khả dụng, cung cấp hiệu năng độ trễ thấp ổn định. Vì tính chất chỉ trong một AZ này, nếu muốn có tính khả dụng vượt qua ranh giới AZ thì cần một cơ chế khác. Việc nhân bản trải rộng qua nhiều vùng hay phân phối tại các edge location không phải vai trò của EBS.

S3 Glacier là nhóm các lớp lưu trữ dành cho archive, gồm S3 Glacier Instant Retrieval dành cho dữ liệu cần lấy ra tức thì, S3 Glacier Flexible Retrieval dành cho dữ liệu dài hạn ít khi truy cập, và S3 Glacier Deep Archive lấy dữ liệu ra sau vài giờ với chi phí thấp nhất. Đây là thiết kế lựa chọn lớp dựa trên sự cân bằng giữa tốc độ và chi phí lấy dữ liệu, không phải thời gian lấy dữ liệu là như nhau ở mọi lớp. Không có giới hạn về loại dữ liệu có thể lưu trữ, và cũng không phải cách dùng kết nối như bộ nhớ lưu trữ khối.

S3 là bộ nhớ lưu trữ đối tượng, EBS là bộ nhớ lưu trữ khối kết nối với EC2, EFS là bộ nhớ lưu trữ tệp tin dành cho workload Linux. Nếu sắp xếp rằng đối tượng là thứ được đưa vào/lấy ra trọn vẹn qua API, khối là thứ mà hệ điều hành nhìn thấy như một ổ đĩa, còn tệp tin là thứ có thể gắn và chia sẻ từ nhiều máy chủ, thì sẽ dễ lựa chọn theo yêu cầu mà không bị lúng túng.

EBS là volume lưu trữ khối bền vững dùng cho instance EC2, cung cấp hiệu năng độ trễ thấp ổn định, nên phù hợp để dùng làm ổ đĩa cho hệ điều hành hoặc cơ sở dữ liệu. S3 là bộ nhớ lưu trữ đối tượng, không phải cơ chế kết nối bucket như thiết bị khối. Glacier là lớp dành cho archive mất thời gian khi lấy dữ liệu ra; CloudFront là CDN giúp tăng tốc việc phân phối.

S3 là bộ nhớ lưu trữ đối tượng có thể lưu trữ và bảo vệ dữ liệu với dung lượng bất kỳ, vượt trội về khả năng mở rộng, tính khả dụng, bảo mật, và hiệu năng, với các công dụng chính thức được nêu ra như Web, thiết bị di động, sao lưu, archive, IoT, phân tích dữ liệu lớn. Được hệ điều hành nhìn thấy như một ổ đĩa là EBS; nguyên tắc chỉ kết nối với một instance cũng là tính chất của EBS; đặt dữ liệu trên bộ nhớ là tính chất của ElastiCache.

EFS là hệ thống tệp tin đơn giản, có khả năng mở rộng và co giãn (elastic); khi thêm hoặc xóa tệp tin, dung lượng sẽ tự động co giãn, không cần thiết kế dung lượng trước. Việc quyết định trước và cố định dung lượng, hay phải tạo lại để mở rộng, là tư duy của bộ nhớ lưu trữ khối, và lượng bộ nhớ của instance kết nối cũng không quyết định dung lượng. Chính khả năng co giãn này là lý do khiến EFS dễ dùng làm vùng làm việc chung.

S3 Glacier Deep Archive lưu trữ dữ liệu ít khi được truy cập với chi phí thấp nhất, và là lớp lưu trữ dành cho archive chấp nhận mất vài giờ khi lấy dữ liệu ra, nên phù hợp với điều kiện này. EBS và EFS được thiết kế để duy trì tốc độ lấy dữ liệu nhanh, nên thường có chi phí cao hơn khi dùng làm nơi lưu trữ dữ liệu ngủ đông lâu dài. ElastiCache là bộ nhớ đệm trong bộ nhớ, vốn không phải cơ chế dành cho lưu trữ lâu dài. Việc quyết định trước có thể chờ đợi bao lâu khi lấy dữ liệu ra chính là hướng đi để chọn lớp lưu trữ.

RDS là dịch vụ được quản lý giúp việc thiết lập, vận hành, mở rộng quy mô cơ sở dữ liệu quan hệ trên đám mây trở nên dễ dàng, tự động hóa các công việc quản lý như cấp phát phần cứng, thiết lập cơ sở dữ liệu, áp dụng bản vá, sao lưu. Trong khi đó, việc thiết kế bảng và cột, quyết định chỉ mục, cách xây dựng ứng dụng, tính hợp lý của nội dung dữ liệu đều vẫn là công việc phía người dùng. Được quản lý (managed) nghĩa là giao phó công sức vận hành, chứ không phải giao phó cả việc thiết kế.

Aurora là một phần của Amazon RDS — dịch vụ cơ sở dữ liệu được quản lý — và dùng cùng bảng điều khiển quản lý, CLI, thao tác API để thực hiện cấp phát, vá lỗi, sao lưu, khôi phục, phát hiện sự cố. Điểm khác biệt nằm ở đơn vị quản lý: RDS tiêu chuẩn quản lý từng instance DB riêng lẻ, còn Aurora quản lý toàn bộ cụm gồm các máy chủ DB được đồng bộ qua nhân bản (replication). Aurora là cơ sở dữ liệu quan hệ tương thích MySQL và PostgreSQL, không phải dạng khóa - giá trị.

DynamoDB là cơ sở dữ liệu NoSQL hỗ trợ dạng khóa - giá trị và dạng tài liệu, cung cấp hiệu năng ở mức mili giây một chữ số ở mọi quy mô, là cơ sở dữ liệu được quản lý hoàn toàn và hỗ trợ đa vùng (multi-region). Kho dữ liệu là Redshift, cơ sở dữ liệu quan hệ tương thích MySQL và PostgreSQL là Aurora, đọc ghi trên bộ nhớ là ElastiCache.

Redshift là dịch vụ kho dữ liệu quy mô petabyte, được quản lý hoàn toàn trên đám mây, cho phép đạt hiệu năng truy vấn nhanh từ các công cụ dựa trên SQL hiện có hoặc ứng dụng BI, bất kể quy mô tập dữ liệu lớn hay nhỏ. ElastiCache là cache trong bộ nhớ, EFS là hệ thống tệp tin chia sẻ, SQS là hàng đợi tin nhắn — không cái nào trong số đó là nền tảng đảm nhận việc tổng hợp và phân tích dữ liệu lớn.

ElastiCache là dịch vụ giúp dễ dàng triển khai, vận hành, mở rộng quy mô cache trong bộ nhớ trên đám mây, cải thiện hiệu năng của ứng dụng Web bằng cách lấy thông tin từ cache trong bộ nhớ tốc độ cao thay vì phụ thuộc vào cơ sở dữ liệu dựa trên ổ đĩa. Làm nhanh các truy vấn phân tích là Redshift, giảm chi phí lưu trữ dài hạn là các lớp của S3 Glacier, chia sẻ thư mục là EFS.

Aurora là công cụ cơ sở dữ liệu quan hệ được quản lý hoàn toàn, tương thích MySQL và PostgreSQL, có hệ thống con lưu trữ chia sẻ phân tán hiệu năng cao, dung lượng lưu trữ tự động mở rộng khi cần. Không cần quyết định trước dung lượng rồi tự tay mở rộng. Lưu dưới dạng cặp khóa và giá trị là DynamoDB; mất thời gian để lấy dữ liệu ra đổi lại lưu trữ rẻ nhất là các lớp lưu trữ dành cho archive của S3 Glacier.

Redshift là dịch vụ kho dữ liệu quy mô petabyte được quản lý hoàn toàn, phù hợp với mục đích tổng hợp và phân tích lượng lớn dữ liệu từ các công cụ dựa trên SQL hoặc ứng dụng BI. RDS là dịch vụ giúp dễ dàng thiết lập, vận hành, mở rộng cơ sở dữ liệu quan hệ, phù hợp với mục đích hệ thống nghiệp vụ đọc ghi giao dịch hàng ngày. Cả hai đều dùng SQL để truy vấn nên trông có vẻ giống nhau, nhưng không phải NoSQL, và cũng không chỉ khác nhau ở lượng dữ liệu.

DynamoDB là cơ sở dữ liệu NoSQL hỗ trợ dạng khóa - giá trị và dạng tài liệu, được mô tả chính thức là cung cấp hiệu năng ở mức mili giây một chữ số ở mọi quy mô. Redshift là kho dữ liệu phù hợp cho việc tổng hợp và phân tích lượng lớn dữ liệu, RDS là dịch vụ đảm nhận việc đọc ghi theo mô hình quan hệ, EFS là bộ nhớ lưu trữ đảm nhận việc chia sẻ tệp tin — không cái nào trong số đó nhắm chính vào điều kiện này.

RDS là Amazon Relational Database Service, một dịch vụ được quản lý giúp dễ dàng thiết lập, vận hành, mở rộng quy mô cơ sở dữ liệu quan hệ trên đám mây. Lưu theo cặp khóa và giá trị là DynamoDB; cache trong bộ nhớ là ElastiCache; tổng hợp lượng lớn dữ liệu là kho dữ liệu Redshift. Ngoài ra, Aurora là một công cụ được cung cấp như một phần của RDS.

Aurora được cung cấp như một phần của RDS nên có thể thực hiện cấp phát, vá lỗi, sao lưu, khôi phục, phát hiện sự cố từ cùng bảng điều khiển quản lý, CLI, thao tác API. Không cần dựng riêng instance quản lý, cũng không cần người dùng tự xây dựng các thủ tục này. Điểm khác biệt là RDS tiêu chuẩn quản lý từng instance DB riêng lẻ, còn Aurora lấy toàn bộ cụm làm đơn vị quản lý.

SQS là dịch vụ điểm - điểm (point-to-point), giữ tin nhắn trong hàng đợi và thông thường một bên tiêu thụ (consumer) duy nhất sẽ thăm dò (poll) để lấy ra. SNS là dịch vụ xuất bản - đăng ký (pub/sub), nơi bên xuất bản gửi tin nhắn tới chủ đề, rồi được đẩy (push) đồng thời tới nhiều bên đăng ký. Việc hoán đổi hai dịch vụ này là nhầm lẫn điển hình, và cả hai cũng không phân phối theo cùng một cách. Có thể ghi nhớ theo hướng: hàng đợi là nơi chứa để bên nhận tự đến lấy, còn chủ đề là vai trò đẩy ra của bên gửi.

SQS có hàng đợi tiêu chuẩn và hàng đợi FIFO; hàng đợi tiêu chuẩn theo cơ chế phân phối at-least-once nên cùng một tin nhắn có thể đến nhiều lần. Hàng đợi FIFO có xử lý exactly-once và đảm bảo thứ tự, giữ nguyên thứ tự gửi và chỉ xử lý đúng một lần. Với các luồng công việc mà thứ tự và việc tránh mất mát là quan trọng thì nên chọn hàng đợi FIFO.

SNS đẩy tin nhắn được gửi tới chủ đề đồng thời tới nhiều bên đăng ký, và có thể chỉ định hàng đợi SQS làm bên đăng ký đó. Hình thức phân phối từ một chủ đề SNS tới nhiều hàng đợi SQS chính là mẫu hình fan-out được nêu chính thức như một mẫu hình tiêu biểu. Hàng đợi là bên nhận chứ không phải nguồn phát, nên không có chiều mà hàng đợi đọc chủ đề.

Các loại bên đăng ký của SNS được chia thành hai nhóm: A2A (application-to-application) chỉ các đích giữa ứng dụng với nhau như SQS, Lambda, HTTP(S), Data Firehose, và A2P (application-to-person) chỉ các đích đối với người như Email, thông báo đẩy trên di động, SMS. Không giới hạn chỉ một trong hai, và cũng không phải cơ chế chỉ nhắm tới instance EC2. Chính sự đa dạng này là lý do SNS được dùng cả cho thông báo tới người lẫn liên kết giữa các ứng dụng.

Step Functions là dịch vụ tạo luồng công việc, tức máy trạng thái, cho phép xây dựng ứng dụng phân tán, tự động hóa quy trình, điều phối microservice, tạo pipeline dữ liệu hoặc học máy. Mỗi bước được gọi là state, instance đang thực thi được gọi là execution. Phân chia lưu lượng là Elastic Load Balancing, lưu trữ đối tượng là S3, cache cặp khóa - giá trị là ElastiCache.

API Gateway là dịch vụ tạo, công bố, duy trì, giám sát, bảo vệ API dạng REST, HTTP, WebSocket ở mọi quy mô, hoạt động như cửa ngõ tiếp nhận cho việc truy cập tới backend như workload trên EC2, Lambda, hay bất kỳ ứng dụng Web nào. Việc thực thi chính xử lý là ở phía backend, áp dụng gộp quy tắc bảo vệ là AWS Firewall Manager, lưu cache tại edge là vai trò của CloudFront.

EventBridge là dịch vụ serverless kết nối các thành phần ứng dụng với nhau bằng sự kiện, thực hiện việc tiếp nhận, lọc, chuyển đổi, phân phối sự kiện. Event bus là bộ định tuyến phân phối sự kiện từ nhiều nguồn tới nhiều đích. Hàng đợi là mô tả của SQS, máy trạng thái là Step Functions, cửa ngõ tiếp nhận là API Gateway.

EventBridge Scheduler là cơ chế quản lý việc thực thi định kỳ và thực thi một lần bằng biểu thức cron hoặc biểu thức rate, nên việc khởi động vào thời điểm cố định thuộc phạm vi xử lý này. SQS là hàng đợi giữ tin nhắn để bên nhận lấy ra, SNS là pub/sub phân phối tới bên đăng ký, API Gateway là dịch vụ công bố API và chuyển tiếp — không cái nào trong số đó nhắm tới mục đích khởi động theo thời điểm.

SQS là dịch vụ hàng đợi được lưu trữ (hosted), an toàn, có độ bền và tính khả dụng cao, giúp tích hợp và liên kết lỏng lẻo (decouple) các hệ thống hoặc thành phần phần mềm phân tán. Phía tiếp nhận có thể phản hồi ngay khi đưa tin nhắn vào hàng đợi, còn xử lý phía sau có thể lấy ra và tiến hành theo tốc độ riêng của mình, nên sự chậm trễ của một bên khó làm dừng bên còn lại. Với cấu trúc gọi trực tiếp hoặc gộp thành một chương trình, sự chậm trễ của xử lý phía sau sẽ trực tiếp trở thành thời gian chờ của phía tiếp nhận.

SNS đẩy tin nhắn được gửi tới chủ đề đồng thời tới nhiều bên đăng ký, và có thể chỉ định hàng đợi SQS làm bên đăng ký, nên để phân phối một sự kiện tới 3 xử lý, cách làm là dùng mẫu hình fan-out với chủ đề SNS và nhiều hàng đợi SQS. Nếu 3 xử lý cùng chia sẻ 1 hàng đợi, thông thường chỉ một trong số đó lấy ra được và phần còn lại sẽ không nhận được. Cấu trúc nơi phát sinh gửi 3 lần, hay xử lý đã nhận chuyển tiếp tiếp, sẽ khiến bên gửi phải sửa mỗi khi số đích tăng lên, và không đạt được sự liên kết lỏng lẻo.