Tìm hiểu Amazon EC2, cách cấu hình và bảo mật một máy chủ ảo bằng Security Group, và cách chọn phương án mua EC2 (On-Demand, Reserved, Spot, Dedicated...) để tối ưu chi phí.
EC2 là viết tắt của Elastic Compute Cloud, và đây là một trong những dịch vụ nổi tiếng nhất, lâu đời nhất của AWS. Nói đơn giản, EC2 cho bạn thuê một máy chủ ảo chạy trên hạ tầng của AWS — thay vì bạn phải mua một cái máy chủ vật lý, đặt nó trong phòng máy, cắm điện, cắm mạng, cài hệ điều hành... thì AWS đã dựng sẵn hàng triệu máy chủ vật lý trong các trung tâm dữ liệu của họ, và bạn chỉ cần "thuê" một phần năng lực tính toán trên đó theo nhu cầu, trả tiền theo thời gian sử dụng.
Đây chính là mô hình Infrastructure as a Service (IaaS) — AWS cung cấp hạ tầng (máy chủ, mạng, lưu trữ), còn bạn tự quản lý hệ điều hành, phần mềm, ứng dụng bên trên. So với PaaS hay SaaS (những mô hình mà AWS quản lý nhiều hơn), IaaS cho bạn quyền kiểm soát sâu nhất, nhưng cũng đòi hỏi bạn tự chịu trách nhiệm nhiều hơn (patch hệ điều hành, cấu hình bảo mật...).
Xoay quanh EC2 có một "họ" các dịch vụ liên quan mà gần như mọi kiến trúc AWS đều dùng tới:
Vì EC2 là nền tảng của rất nhiều dịch vụ khác trong AWS, và cũng là dịch vụ mà hầu như ai học Cloud cũng phải đụng tới đầu tiên, hiểu rõ EC2 chính là chìa khóa để hiểu cách hoạt động của toàn bộ Cloud nói chung, không chỉ riêng AWS.
Khi bạn "đặt hàng" một máy chủ EC2, bạn phải chọn khá nhiều thông số, giống như khi mua một chiếc máy tính thật vậy — chọn hệ điều hành nào, CPU bao nhiêu lõi, RAM bao nhiêu, ổ cứng loại gì. Các tùy chọn chính gồm:
Tất cả các tùy chọn này sẽ được nhắc lại và mở rộng chi tiết ở các phần tiếp theo trong chương này, và cả ở Chương 4 (lưu trữ cho EC2).
Hãy tưởng tượng: bạn cần tạo ra 50 máy chủ web giống nhau, mỗi máy đều cần cài Apache, tải file cấu hình, cập nhật hệ điều hành... Nếu phải SSH vào từng máy để làm tay thì rất mất thời gian. Đây là lúc EC2 User Data phát huy tác dụng.
Bootstrapping nghĩa là chạy các lệnh ngay khi máy khởi động — giống như khi bạn mới mua một chiếc điện thoại mới và nó tự động chạy một loạt thiết lập ban đầu trước khi bạn dùng được. Với EC2, bạn có thể cung cấp một đoạn script (User Data) khi khởi tạo instance, và AWS sẽ tự động chạy script đó ngay khi máy bật lên lần đầu.
AWS cung cấp rất nhiều "loại" máy chủ (instance type) khác nhau, mỗi loại được tối ưu cho một kiểu công việc riêng — giống như bạn mua ô tô: có xe tải chở hàng, xe đua tốc độ cao, xe gia đình chở người... Tên của một instance type tuân theo một quy tắc đặt tên, ví dụ m5.2xlarge:
Bốn nhóm instance chính mà bạn cần nắm ở trình độ Cloud Practitioner:
Phù hợp cho nhiều loại tải công việc khác nhau vì có sự cân bằng tốt giữa CPU, RAM và khả năng mạng — không quá mạnh về mặt nào nhưng đáp ứng tốt hầu hết nhu cầu cơ bản, ví dụ web server, code repository. Loại instance t2.micro mà rất nhiều khóa học AWS hay dùng để demo (và cũng nằm trong AWS Free Tier) chính là một General Purpose instance.
Dành cho các tác vụ cần CPU mạnh, xử lý tính toán nặng: xử lý theo lô (batch processing), chuyển đổi định dạng media (media transcoding), web server hiệu năng cao, tính toán hiệu năng cao (HPC), mô hình hóa khoa học & machine learning, hoặc máy chủ game chuyên dụng.
Dành cho các tải công việc cần xử lý tập dữ liệu lớn ngay trong RAM để đạt hiệu năng cao: cơ sở dữ liệu quan hệ/phi quan hệ hiệu năng cao, hệ thống cache phân tán quy mô lớn, cơ sở dữ liệu trong bộ nhớ (in-memory) cho business intelligence, hoặc xử lý thời gian thực dữ liệu phi cấu trúc khối lượng lớn.
Dành cho các tác vụ cần đọc/ghi tuần tự với tốc độ cao trên tập dữ liệu lớn ngay trên ổ đĩa cục bộ: hệ thống giao dịch trực tuyến tần suất cao (OLTP), cơ sở dữ liệu quan hệ và NoSQL, cache cho cơ sở dữ liệu trong bộ nhớ (như Redis), kho dữ liệu (data warehousing), hoặc hệ thống file phân tán.
Bảng dưới đây minh họa một vài instance type cụ thể và cấu hình của chúng:
| Instance | vCPU | RAM | Lưu trữ | Băng thông mạng |
|---|---|---|---|---|
| t2.micro | 1 | 1 GiB | Chỉ dùng EBS | Thấp đến trung bình |
| t2.xlarge | 4 | 16 GiB | Chỉ dùng EBS | Trung bình |
| c5d.4xlarge | 16 | 32 GiB | 1×400 GB NVMe SSD | Lên tới 10 Gbps, băng thông EBS 4750 Mbps |
| r5.16xlarge | 64 | 512 GiB | Chỉ dùng EBS | 20 Gbps, băng thông EBS 13600 Mbps |
| m5.8xlarge | 32 | 128 GiB | Chỉ dùng EBS | 10 Gbps, băng thông EBS 6800 Mbps |
Nếu muốn xem đầy đủ và so sánh trực quan tất cả các loại instance hiện có của AWS (rất nhiều!), có một trang web cộng đồng khá nổi tiếng và tiện dụng là instances.vantage.sh.
Security Group là một trong những khái niệm nền tảng nhất của bảo mật mạng trên AWS, và chắc chắn sẽ xuất hiện trong đề thi. Hãy hiểu nó đơn giản như một bức tường lửa (firewall) được gắn trực tiếp vào một hoặc nhiều EC2 instance, kiểm soát traffic nào được phép đi vào (inbound) và đi ra (outbound) khỏi máy.
Security Group chỉ chứa các rule (quy tắc) cho phép — không có rule "chặn" (deny) như một số firewall khác. Mỗi rule quy định: traffic ở cổng (port) nào, giao thức nào, và đến từ nguồn nào thì được cho qua. Nguồn ở đây có thể là:
Security Group giúp bạn kiểm soát:
Một điểm rất hay và hay bị bỏ qua: rule của Security Group không chỉ cho phép theo IP, mà còn có thể cho phép theo một Security Group khác làm nguồn. Ví dụ: Security Group SG1 có rule inbound cho phép traffic vào cổng 123, nhưng nguồn được phép không phải là một dải IP mà là "bất kỳ instance nào đang gắn SG2 hoặc SG3". Cách này rất hữu ích khi bạn có các nhóm máy chủ động (auto scaling), IP thay đổi liên tục, nhưng bạn vẫn muốn kiểm soát chặt việc "máy nào được nói chuyện với máy nào" dựa trên vai trò (role) của chúng thay vì địa chỉ IP cụ thể.
Khi cấu hình Security Group, bạn cần biết ứng dụng của mình sử dụng cổng nào để mở đúng rule. Dưới đây là những cổng "kinh điển" xuất hiện thường xuyên trong các bài thi và trong thực tế vận hành:
| Port | Giao thức / Mục đích |
|---|---|
| 21 | FTP – tải file lên server |
| 22 | SSH – đăng nhập vào máy Linux (dòng lệnh) |
| 22 | SFTP – tải file lên server, sử dụng qua kênh SSH |
| 80 | HTTP – truy cập web không mã hóa |
| 443 | HTTPS – truy cập web có mã hóa (SSL/TLS) |
| 3389 | RDP (Remote Desktop Protocol) – đăng nhập vào máy Windows (giao diện đồ họa) |
Sau khi khởi tạo một EC2 instance chạy Linux, bạn cần một cách để "vào" bên trong máy đó để cài đặt, kiểm tra, gỡ lỗi. Cách truyền thống là dùng SSH (Secure Shell) — một giao thức kết nối terminal được mã hóa, chạy qua cổng 22.
Việc SSH vào máy đôi khi gây khó khăn cho người mới (do file key, quyền truy cập file, firewall công ty...). Nếu gặp lỗi, hãy kiểm tra lại các bước hướng dẫn kỹ, thử phương án khác (ví dụ EC2 Instance Connect). Nếu vẫn không kết nối được bằng bất kỳ cách nào, cũng không phải vấn đề lớn — quan trọng là hiểu khái niệm, thi CLF-C02 sẽ không yêu cầu thực hành SSH nhiều.
EC2 Instance Connect là cách kết nối vào EC2 instance ngay trong trình duyệt web, không cần bạn tự quản lý file khóa (key file) private key. Cách hoạt động: khi bạn bấm "Connect" trên Console, AWS sẽ tự động tải lên một khóa tạm thời vào instance của bạn để xác thực, rồi mở một cửa sổ terminal ngay trên trình duyệt.
Một trong những điểm mạnh nhất của Cloud so với hạ tầng truyền thống là bạn có rất nhiều cách để trả tiền cho cùng một loại máy chủ, tùy vào việc bạn dùng nó ổn định hay chỉ tạm thời, dùng liên tục hay ngắt quãng. AWS gọi các cách trả tiền này là Purchasing Options. Có 6 phương án chính:
Việc chọn đúng phương án mua có thể giúp bạn tiết kiệm rất nhiều chi phí — đây cũng là lý do câu hỏi về Purchasing Options xuất hiện rất nhiều trong đề thi CLF-C02.
Đây là cách đơn giản nhất: bạn trả tiền cho đúng thời gian sử dụng. Với các instance chạy Linux/Windows, tiền được tính theo giây (sau phút đầu tiên); với các hệ điều hành khác, tính theo giờ. On-Demand có chi phí cao nhất trong tất cả các phương án, nhưng đổi lại không cần trả trước, không có ràng buộc dài hạn. Phù hợp cho tải công việc ngắn hạn, không liên tục, khó dự đoán trước — ví dụ chạy thử nghiệm, dev/test môi trường tạm thời.
Bạn "đặt trước" (reserve) và cam kết sử dụng trong 1 năm hoặc 3 năm, đổi lại được giảm giá tới 72% so với On-Demand. Khi đặt Reserved, bạn phải cố định một số thuộc tính: loại instance, region, tenancy (dùng chung hay riêng phần cứng), hệ điều hành. Thời gian cam kết dài hơn (3 năm) thì mức giảm giá cao hơn. Có 3 cách trả tiền:
Reserved Instance có thể áp dụng ở phạm vi Regional (linh hoạt hơn về AZ) hoặc Zonal (cố định một AZ, đảm bảo có capacity tại AZ đó). Phương án này rất phù hợp cho các tải công việc ổn định lâu dài, ví dụ một cơ sở dữ liệu chạy 24/7 suốt nhiều năm. Một điểm hay: bạn có thể bán lại Reserved Instance mà mình không dùng hết trên "Reserved Instance Marketplace".
Có một biến thể là Convertible Reserved Instance: cho phép bạn đổi loại instance, họ instance, hệ điều hành, phạm vi hay tenancy trong thời gian cam kết — đánh đổi lại mức giảm giá thấp hơn một chút (tới 66%) so với Standard RI, nhưng linh hoạt hơn nhiều.
Savings Plans hoạt động khác Reserved Instance một chút: thay vì cam kết một loại instance cụ thể, bạn cam kết một mức chi tiêu ($/giờ) trong 1 hoặc 3 năm, và được giảm giá tương đương RI (tới 72%). Nếu bạn dùng vượt mức đã cam kết, phần vượt sẽ tính theo giá On-Demand. Savings Plans bị khóa vào một họ instance cụ thể và một region cụ thể (ví dụ họ M5 tại us-east-1), nhưng linh hoạt về kích thước instance, hệ điều hành, và tenancy trong phạm vi đó.
Đây là phương án rẻ nhất trong tất cả — có thể giảm tới 90% so với giá On-Demand! Cơ chế: AWS bán "công suất dư" (spare capacity) theo kiểu đấu giá. Bạn đặt một mức giá tối đa bạn chấp nhận trả; nếu giá Spot hiện tại vượt quá mức bạn đặt, AWS có thể lấy lại máy của bạn ngay lập tức (chỉ báo trước 2 phút). Vì vậy Spot chỉ phù hợp cho các tải công việc chịu được gián đoạn: xử lý theo lô (batch job), phân tích dữ liệu, xử lý ảnh, hệ thống tính toán phân tán, hoặc bất kỳ việc gì có thể linh hoạt về thời gian bắt đầu/kết thúc. Spot không phù hợp cho các công việc quan trọng liên tục (critical) hoặc chạy database — vì bạn không thể chấp nhận việc database bị tắt bất ngờ.
Đây là khi bạn thuê nguyên một máy chủ vật lý, và toàn bộ năng lực tính toán của máy đó chỉ dành riêng cho bạn — không chia sẻ với ai khác. Phương án này giải quyết được các yêu cầu về tuân thủ (compliance) nghiêm ngặt, hoặc khi bạn có giấy phép phần mềm ràng buộc với phần cứng cụ thể (mô hình BYOL – Bring Your Own License). Dedicated Host có hai kiểu thanh toán: On-Demand (trả theo giây) hoặc Reserved (1/3 năm, các mức trả trước khác nhau). Đây là phương án đắt nhất, nên chỉ dùng khi có yêu cầu bắt buộc về license hoặc quy định pháp lý/compliance.
Khác với Dedicated Host, Dedicated Instance chạy trên phần cứng dành riêng cho tài khoản của bạn — nhưng phần cứng đó vẫn có thể được chia sẻ với các instance khác trong cùng tài khoản. Điểm khác biệt lớn: bạn không kiểm soát được vị trí instance được đặt trên phần cứng nào (chỉ có thể thay đổi bằng cách Stop rồi Start lại instance).
Đây là cách giữ chỗ năng lực tính toán On-Demand tại một Availability Zone cụ thể, trong bất kỳ khoảng thời gian nào bạn muốn. Lợi ích chính là đảm bảo bạn luôn có capacity khi cần, dù không có cam kết thời gian và không có giảm giá nào cả — bạn vẫn bị tính tiền theo giá On-Demand cho dù có chạy instance hay không. Có thể kết hợp Capacity Reservation với Regional Reserved Instance hoặc Savings Plans để vừa đảm bảo có chỗ, vừa được giảm giá. Phù hợp cho các tải công việc ngắn hạn nhưng cần chắc chắn có capacity tại một AZ cụ thể.
Một cách tuyệt vời để nhớ sự khác biệt giữa các phương án là liên tưởng tới việc đặt phòng khách sạn:
Bảng dưới đây minh họa mức chênh lệch giá thực tế cho instance m4.large tại vùng us-east-1 (số liệu minh họa, mang tính tương đối để so sánh xu hướng):
| Phương án | Giá tham khảo / giờ |
|---|---|
| On-Demand | $0.10 |
| Spot | $0.038 – $0.039 (giảm tới 61%) |
| Reserved 1 năm | $0.058 (All Upfront) – $0.062 (No Upfront) |
| Reserved 3 năm | $0.037 – $0.043 |
| Savings Plan 1 năm | Tương đương Reserved 1 năm |
| Convertible RI 1 năm | $0.066 – $0.071 |
| Dedicated Host | Giá On-Demand; nếu đặt trước (reservation) có thể giảm tới 70% |
| Capacity Reservation | Bằng giá On-Demand |
Giống như mọi dịch vụ AWS khác, EC2 cũng tuân theo Shared Responsibility Model đã học ở Chương 1, nhưng áp dụng cụ thể cho compute:
Nói ngắn gọn: AWS chăm sóc "phần cứng và hạ tầng bên dưới", còn bạn chăm sóc "mọi thứ chạy bên trong máy chủ ảo của mình" — đúng với tinh thần của mô hình IaaS.