Tổng quan về AWS Cloud Practitioner

Bài viết này tổng hợp những kiến thức căn bản liên quan đến AWS Cloud Practitioner. Mục tiêu là xây dựng một bức tranh toàn cảnh về dịch vụ đám mây của AWS, giải thích động lực (motivation) của từng phần và cách các thành phần liên kết với nhau. Bài viết chỉ mang mục đích giới thiệu giúp các bạn học có cái nhìn tổng quan nhất về nội dung chủ đề này, nếu bạn đọc muốn tìm hiểu sâu và kĩ hơn thì hãy trực tiếp tham gia lớp AWS đang diễn ra ở trên lớp.

I. Khái niệm Cloud

1.1. Cloud computing là gì?

• Điện toán đám mây (cloud computing) cho phép chúng ta sử dụng hạ tầng và dịch vụ qua internet. Thay vì phải mua máy chủ vật lý, doanh nghiệp có thể thuê tài nguyên máy tính, lưu trữ, cơ sở dữ liệu v.v. khi cần và trả tiền theo mức sử dụng. AWS là một trong những nhà cung cấp đám mây lớn nhất thế giới.

1.2. Năm đặc trưng của AWS Cloud ?

1. On-demand self-service → Tự tạo tài nguyên khi cần, không cần hỏi ai
2. Broad network access → Truy cập qua internet từ mọi nơi
3. Resource pooling → Tài nguyên được dùng chung (multi-tenant)
4. Rapid elasticity → Mở rộng / thu nhỏ cực nhanh
5. Measured service → Trả tiền theo mức sử dụng (pay-as-you-go)

1.3. Từ những đặc trưng trên thì ta được hưởng lợi gì từ Cloud ?

• On-demand self-service → khách hàng tự tạo server, database, storage ngay khi cần nên ra sản phẩm nhanh hơn, không phải chờ mua máy hay chờ IT cấp phát, chuyển chi phí CAPEX ( Capital Expenditure - vốn đầu tư) thành OPEX ( Operating Expenditure - chi phí vận hành).
• Broad network access → có thể dùng dịch vụ ở mọi nơi, nhiều thiết bị, hỗ trợ làm việc từ xa và phục vụ người dùng toàn cầu dễ hơn
• Resource pooling → AWS gom tài nguyên lớn để nhiều khách hàng cùng dùng nên chi phí rẻ hơn, khách hàng không phải tự xây cả hạ tầng riêng
• Rapid elasticity → khi traffic tăng thì mở rộng rất nhanh, khi ít người dùng thì thu nhỏ lại nên vừa ổn định vừa tránh lãng phí
• Measured service → đo đếm đúng mức sử dụng nên khách hàng trả tiền theo nhu cầu thực tế, dễ kiểm soát chi phí và tối ưu ngân sách.
• Go global in minutes →Triển khai toàn cầu trong vài phút.

Hình 1: Mối liên hệ giữa những đặc trưng của AWS và lợi ích khách hàng (Made with AI)

1.4. Mô hình dịch vụ (IaaS/PaaS/SaaS) và triển khai

• IaaS (Infrastructure as a Service) thuê “máy móc hạ tầng” như server, ổ cứng, mạng, rồi tự cài mọi thứ lên trên cung cấp hạ tầng ảo như dịch vụ EC2, EBS.
  Ví dụ: Netflix, BBC, Facebook, Spotify, LinkedIn

• PaaS (Platform as a Service) thuê sẵn “môi trường chạy app”, đỡ phải lo nhiều về server (Elastic Beanstalk, AWS Fargate).

• SaaS (Software as a Service) cung cấp ứng dụng hoàn chỉnh cho người dùng cuối xài luôn. Người dùng không quan tâm server hay deploy gì cả, chỉ đăng ký tài khoản và dùng.(Amazon Chime, QuickSight).
  Ví dụ: Gmail, Google Docs, Notion, Slack, Zoom, Canva, Trello

Triển khai có thể là Public (dịch vụ công cộng trên AWS), Private (đám mây riêng), Hybrid (kết hợp on‑premises và cloud) hoặc Multi‑cloud (sử dụng nhiều nhà cung cấp).

II. Hạ tầng toàn cầu của AWS

2.1. Availability Zone, Region và Edge Location

• Region là khu vực địa lý lớn mà AWS đặt hạ tầng, dùng khi bạn cần chọn nơi triển khai hệ thống sao cho gần người dùng, đúng yêu cầu pháp lý dữ liệu, và hỗ trợ disaster recovery.
• Bên trong mỗi Region có nhiều Availability Zone (AZ); mỗi AZ là một hoặc nhiều data center tách biệt về điện, mạng, làm mát nhưng kết nối rất nhanh với nhau, mục đích là tăng high availability — tức nếu một AZ lỗi thì AZ khác vẫn chạy.
• Còn Edge Location không phải nơi chính để deploy ứng dụng, mà là các điểm hiện diện gần người dùng để cache nội dung, đưa nội dung đến gần user để giảm độ trễ tăng tốc truy cập, xử lý DNS/CDN, thường gắn với CloudFront và Route 53

Hình 2: Mối liên hệ cấp bậc của từ Sever -> Region của hạ tầng AWS (Made with AI)

2.2. High Availability (HA) trong AWS thực chất là gì?

High Availability nghĩa là thiết kế hệ thống sao cho khi một hoặc nhiều thành phần bị lỗi thì hệ thống vẫn tiếp tục hoạt động. Ý tưởng đằng sau HA đơn giản là bạn không cố làm cho từng thành phần “không bao giờ hỏng”, mà bạn chấp nhận là có thể hỏng, rồi thiết kế sao cho hỏng một chỗ vẫn không làm sập toàn bộ dịch vụ.

• Ví dụ: nếu một ứng dụng ngân hàng chạy trên hai AZ, khi một AZ bị sự cố, lưu lượng có thể được chuyển sang AZ còn lại.

2.3. Multi-AZ và Multi-Region khác nhau như thế nào?

Multi-AZ là triển khai trên nhiều Availability Zone trong cùng một Region. Mục tiêu chính của nó là high availability. Nó giúp hệ thống sống sót khi một data center hoặc một AZ bị lỗi.

Multi-Region là triển khai trên nhiều Region khác nhau. Mục tiêu chính của nó là disaster recovery và phục vụ người dùng toàn cầu tốt hơn. Nếu một sự cố quá lớn ảnh hưởng đến cả một Region, hệ thống ở Region khác vẫn có thể tiếp tục hoạt động.

💡 Multi-AZ = High Availability
💡Multi-Region = Disaster Recovery + Global Users

Hình 3: Multi- AZ và Multi- Region (Made with AI)

2.4. Global Services và Regional Services

Global services là các dịch vụ không gắn với một Region duy nhất mà hoạt động trên phạm vi toàn cầu. Ví dụ điển hình là IAM, Route 53, và CloudFront. IAM quản lý người dùng và quyền truy cập tập trung trên AWS; Route 53 định tuyến lưu lượng toàn cầu; CloudFront phân phối nội dung qua mạng edge.

Ngược lại, Regional services là các dịch vụ hoạt động trong một Region cụ thể và cần được triển khai hoặc quản lý riêng theo từng Region. Những ví dụ quen thuộc là EC2, RDS, Lambda, và VPC. Bạn không thể nghĩ EC2 là “toàn cầu”, vì khi tạo EC2 bạn luôn phải chọn Region cụ thể.

III. Dịch vụ Compute và Serverless

Phần này bạn có thể hiểu cực đơn giản là: AWS cho bạn nhiều cách để “chạy code” hoặc “chạy ứng dụng”, và điểm khác nhau lớn nhất là bạn phải tự quản lý bao nhiêu thứ. Càng về phía truyền thống thì bạn càng nhiều quyền kiểm soát nhưng cũng càng cực; càng về phía serverless thì AWS làm thay nhiều hơn, bạn nhẹ đầu hơn nhưng ít quyền kiểm soát chi tiết hơn.

Cách hiểu rất đơn giản
- EC2: giống như thuê một máy tính/ máy chủ trên cloud. Bạn tự cài hệ điều hành, tự cài app, tự vá lỗi, tự quản lý gần như mọi thứ.
- ECS / EKS: giống như đóng gói app vào container rồi nhờ AWS giúp bạn sắp xếp và chạy các container đó. Bạn đỡ cực hơn EC2, nhưng vẫn cần hiểu cách vận hành app.
- Lambda: giống như đưa cho AWS một đoạn code nhỏ, khi có sự kiện thì AWS tự chạy giúp. Bạn không cần lo server bật hay tắt.

IV. Lưu trữ – Storage

Nếu nhìn thật tổng quan thì trong AWS, phần lưu trữ không nên học bằng cách nhớ quá nhiều tên dịch vụ ngay từ đầu, mà nên hiểu rằng về bản chất có 3 kiểu storage chính: Block Storage, File Storage, và Object Storage. Toàn bộ các dịch vụ lưu trữ của AWS gần như chỉ là cách hiện thực 3 kiểu này cho các nhu cầu khác nhau. Insight quan trọng nhất là: không có loại nào tốt nhất tuyệt đối, mà chỉ có loại phù hợp nhất với cách dữ liệu được dùng.

4.1. Block Storage – lưu trữ dạng khối

Bạn có thể hiểu Block Storage giống như một ổ đĩa gắn vào máy tính. Hệ thống nhìn nó như từng block dữ liệu nhỏ và có thể đọc ghi rất nhanh. Có nhiều loại volume (gp3, io2)

Đây là loại phù hợp khi bạn chạy:
- Hệ điều hành của server
- Database
- Ứng dụng cần đọc ghi nhanh và liên tục (IOPS cao)

( IOPS là viết tắt của Input/Output Operations Per Second (Số chiến dịch nhập/xuất mỗi giây)

Trong AWS đó chính là dịch vụ Elastic Block Store (EBS).

4.2. File Storage – lưu trữ dạng tệp/thư mục

File Storage là kiểu gần gũi nhất với người dùng bình thường, vì nó giống như các folder và file trên Windows hay Google Drive nội bộ. Thường file storage là khi bạn không chỉ có một máy dùng dữ liệu, mà có nhiều máy hoặc nhiều ứng dụng cùng cần truy cập chung một cấu trúc thư mục.

Loại này phù hợp khi bạn cần:

• Nhiều server cùng đọc/ghi một vùng dữ liệu
• Chia sẻ tài liệu, media, nội dung dùng chung
• Ứng dụng cũ/legacy app vốn quen làm việc với file system

Trong AWS đó chính là dịch vụ Elastic File System (EFS).

4.3. Object Storage – lưu trữ dạng đối tượng

Object Storage là kiểu lưu trữ rất quan trọng trong cloud. Thay vì dữ liệu được tổ chức như ổ đĩa hay thư mục truyền thống, mỗi dữ liệu được lưu như một object độc lập, thường gồm nội dung + metadata + ID riêng. Lưu trữ theo dạng object storage là để giải quyết bài toán scale cực lớn, lưu trữ linh hoạt, bền vững, truy cập qua internet/API rất thuận tiện.

Đây là loại phù hợp khi bạn cần:

• Lưu ảnh, video, file upload
• Backup, archive
• Log, data lake, dữ liệu phân tích
• Static website assets

Trong AWS đó chính là dịch vụ Simple Storage Service (S3).

Hình 4: Ba nhánh lưu trữ chính của AWS Storage (Made with AI)

V. Cơ sở dữ liệu & tích hợp

Nếu nhìn thật tổng quan thì phần database trên AWS không nên học theo kiểu nhớ hàng loạt tên dịch vụ trước, mà nên bắt đầu từ câu hỏi gốc: dữ liệu của hệ thống đang mang bản chất gì, và ứng dụng cần truy cập nó theo cách nào? Đó mới là motivation thật sự phía sau các loại database. AWS không tạo ra nhiều dịch vụ database chỉ để “cho nhiều lựa chọn”, mà vì mỗi loại dữ liệu và mỗi kiểu ứng dụng sẽ phù hợp với một cách lưu trữ khác nhau.

❓Vậy tại vì sao phải có nhiều loại database?

Trong thực tế, không phải dữ liệu nào cũng giống nhau.

Có những hệ thống cần dữ liệu rất có cấu trúc, nhiều bảng liên kết với nhau, cần truy vấn chặt chẽ, cần tính nhất quán cao, ví dụ như ngân hàng, quản lý đơn hàng, kế toán, nhân sự. Nhưng cũng có những hệ thống cần scale rất lớn, phản hồi cực nhanh, dữ liệu linh hoạt hơn, không quá phụ thuộc vào join phức tạp, ví dụ session người dùng, giỏ hàng, leaderboard, log hành vi. Lại có những bài toán cần phân tích dữ liệu khổng lồ theo kiểu báo cáo, BI, tổng hợp lịch sử. Chính vì vậy, AWS mới có nhiều nhóm database khác nhau.

💡 Database không phải chọn theo cái “xịn hơn”, mà chọn theo cách dữ liệu sống trong hệ thống.

5.1. Dịch vụ CSDL quan hệ – Amazon RDS & Aurora

Đây là loại quen thuộc nhất. Bạn có thể hiểu Relational Database là nơi dữ liệu được tổ chức thành bảng, dòng, cột, và các bảng có thể liên kết với nhau bằng khóa. Relational database thường được dùng cho giải quyết những hệ thống mà dữ liệu rõ cấu trúc, rõ quan hệ, rõ ràng logic nghiệp vụ.
Loại này phù hợp khi bạn cần: Dữ liệu có quan hệ chặt chẽ ,Transaction chính xác, Truy vấn SQL, Join nhiều bảng, Tính nhất quán cao

Hình 5: Service Auroza và RDS của AWS về Relational Database (Nguồn: allcode)

5.2 Cơ sở dữ liệu NoSQL– Amazon DynamoDB

NoSQL không có nghĩa là “không tốt bằng SQL”, mà là không đi theo mô hình bảng quan hệ truyền thống. Bản chất của NoSQL là để phục vụ những hệ thống cần linh hoạt hơn, scale lớn hơn, tốc độ cao hơn, đặc biệt khi dữ liệu không quá phụ thuộc vào join và quan hệ chặt.

Loại này phù hợp khi bạn cần:

• Đọc ghi cực nhanh
• Scale rất lớn
• Dữ liệu thay đổi linh hoạt
• Workload nhiều request, ít join phức tạp
• Ứng dụng web/mobile lớn, realtime

Ý nghĩa đằng sau NoSQL là: không phải lúc nào dữ liệu cũng cần bị ép vào bảng quan hệ cứng nhắc. Có những hệ thống chỉ cần biết “key này map tới value gì”. Trong AWS, ví dụ nổi bật nhất là Amazon DynamoDB. Bạn có thể hiểu DynamoDB như một database được sinh ra cho tư duy cloud-native: scale mạnh, độ trễ thấp, phù hợp cho các ứng dụng lớn có traffic cao.

5.3 Dịch vụ kho dữ liệu (Data Warehouse) – Amazon Redshift

Đây là kiểu database dành cho phân tích, không phải để vận hành giao dịch hằng ngày. Motivation của data warehouse là vì dữ liệu vận hành và dữ liệu phân tích là hai thế giới khác nhau. Hệ thống giao dịch cần nhanh và chính xác từng request, còn hệ thống phân tích cần quét lượng dữ liệu rất lớn để trả lời các câu hỏi như: doanh thu tháng này là bao nhiêu, khu vực nào tăng trưởng mạnh nhất, sản phẩm nào bán chạy nhất trong 2 năm qua... Insight ở đây là: đừng bắt database giao dịch làm luôn việc phân tích nặng, vì hai mục tiêu này khác nhau. Một bên tối ưu cho transaction hằng ngày, bên kia tối ưu cho query tổng hợp khổng lồ.

Loại này phù hợp khi bạn cần:

• Báo cáo
• BI/dashboard
• Phân tích lịch sử
• Tổng hợp dữ liệu khối lượng lớn

Trong AWS, ví dụ tiêu biểu là Amazon Redshift.

Hình 7: Service Redshift của AWS về Data Warehouse (Nguồn: igmguru)

VI. Mạng và phân phối nội dung cách chúng thực sự hoạt động ?

Phần mạng trong AWS sinh ra để trả lời một câu hỏi rất thực tế: làm sao để người dùng có thể truy cập đúng ứng dụng, đúng dữ liệu, đủ nhanh, đủ an toàn, và đủ ổn định. Nếu nhìn lại, compute là nơi ứng dụng chạy, storage là nơi dữ liệu nằm, còn networking là phần khiến mọi thứ kết nối được với nhau. Cloud không có nghĩa là mọi thứ đều công khai; ngược lại, cloud tốt là cloud biết tách cái nào nên mở ra và cái nào nên giấu vào trong, một hệ thống không chỉ cần “chạy được”, mà còn phải truy cập được, tách biệt được, bảo vệ được, và phục vụ người dùng nhanh được.

Trước hết là bài toán tách riêng phần công khai và phần nội bộ. Không phải thành phần nào cũng nên lộ ra internet. Đó là lý do có Amazon VPC. Nó cho phép bạn dựng một môi trường mạng có kiểm soát, chia subnet công khai và subnet riêng tư, quy định đường đi của traffic, và quyết định thành phần nào được ra ngoài internet, thành phần nào thì không.

Tiếp theo là bài toán kiểm soát ai được đi vào đâu. Đây là motivation đằng sau các lớp bảo vệ mạng như Security Group hay Network ACL. Bản chất của chúng là giới hạn quyền truy cập để giảm rủi ro. Idea đơn giản là: " không phải cứ cùng hệ thống là được phép nói chuyện với nhau tự do ". Một web server có thể được phép nhận request từ internet, nhưng database thì chỉ nên nhận kết nối từ app server, chứ không phải từ mọi nơi.

Sau đó là bài toán phân phối lưu lượng traffic. Khi có nhiều server hoặc nhiều request, ta không thể dồn hết vào một máy. Đây là chỗ các dịch vụ như Elastic Load Balancing ( ELB ) xuất hiện. Nếu một server phải gánh toàn bộ request, nó rất dễ quá tải hoặc trở thành điểm lỗi duy nhất. Load balancer sinh ra để đứng ở giữa, nhận lưu lượng rồi phân phối sang nhiều server phía sau.

Tiếp theo là bài toán làm sao người dùng tìm thấy hệ thống của bạn. Con người không thể nhớ địa chỉ IP dài ngoằng, nên cần một cơ chế để chuyển tên miền như example.com thành nơi hệ thống thực sự đang chạy. Đây là vai trò của Route 53. Nó giúp tên miền trỏ đúng đến nơi hệ thống đang chạy

Cuối cùng là bài toán làm sao tải nhanh hơn cho người dùng ở xa. Câu trả lời là CloudFront. Nếu mọi request đều phải chạy về server gốc ở rất xa, trải nghiệm sẽ chậm, đặc biệt với ảnh, video, file tĩnh, hay website có người dùng ở nhiều quốc gia. CloudFront sinh ra để đưa nội dung đến gần user hơn thông qua các edge location, giúp giảm độ trễ và giảm tải cho origin server

Nhìn tổng thể, phần mạng và phân phối nội dung trong AWS không phải là một đống dịch vụ rời rạc, mà là một chuỗi logic rất liền mạch. Trước hết bạn cần một mạng riêng để đặt hệ thống vào đó -> sau đó bạn cần kiểm soát traffic đi qua mạng ấy -> tiếp theo bạn cần phân phối lưu lượng hợp lý giữa các thành phần -> rồi bạn cần một cách để người dùng tìm đúng đường vào hệ thống -> và cuối cùng bạn cần đưa nội dung đến gần người dùng để tăng tốc trải nghiệm.

Hình 8: Cách Networking và Phân Phối Nội Dung của AWS tới người dùng (Made with AI)

VII. Bảo mật và tuân thủ

Bảo mật và tuân thủ trong AWS xoay quanh một ý rất quan trọng: làm sao hệ thống an toàn và đúng quy định khi chạy trên cloud. Bản chất của phần này là vì đưa hệ thống lên AWS không có nghĩa là mọi thứ tự động an toàn, mà bạn vẫn phải cấu hình đúng cách. Insight cốt lõi là AWS bảo vệ hạ tầng của cloud, còn bạn bảo vệ dữ liệu, quyền truy cập, cấu hình và ứng dụng của mình. Từ đó mới sinh ra các lớp như IAM để cấp quyền đúng người đúng việc, mã hóa để bảo vệ dữ liệu, logging/monitoring để theo dõi hoạt động, và compliance để đáp ứng các tiêu chuẩn hay quy định. Nói ngắn gọn, phần này là để đảm bảo rằng hệ thống không chỉ chạy được, mà còn chạy an toàn, có kiểm soát, và có thể kiểm chứng được.

• Trách nhiệm của AWS: bảo vệ hạ tầng vật lý (data center, phần cứng, nguồn điện, mạng),hypervisor và cơ sở dịch vụ cốt lõi.

• Trách nhiệm của khách hàng: cấu hình IAM, hệ điều hành, mạng (VPC, SG, NACL), mã hóa dữ liệu, cập nhật phần mềm và tuân thủ yêu cầu luật pháp.

VIII. Giá thành và thanh toán

• On-Demand = linh hoạt nhất
• RI / Savings Plans = đổi cam kết lấy giảm giá
• Spot = rẻ nhất nhưng có thể bị ngắt
• Dedicated Hosts = vì license/compliance
• Capacity Reservations = vì cần chắc chắn có tài nguyên

IX. Tổng kết kiến thức

Qua bài viết của tôi bạn có thể thấy bức tranh toàn cảnh về AWS Cloud Practitioner gồm nhiều mảnh ghép liên kết với nhau:

1. Cloud concepts: AWS giúp dùng tài nguyên CNTT theo kiểu linh hoạt, trả theo mức dùng, mở rộng nhanh và không phải đầu tư hạ tầng từ đầu.
2. Hạ tầng toàn cầu: Region là nơi triển khai lớn, AZ giúp tăng high availability trong cùng Region, Edge Location giúp đưa nội dung đến gần người dùng hơn.
3. Compute & Serverless: AWS cho nhiều cách chạy ứng dụng, từ EC2 (tự quản nhiều) đến Lambda (AWS quản gần hết), khác nhau chủ yếu ở mức độ quản lý.
4. Storage: Có 3 kiểu chính là Block, File, Object, và điểm quan trọng nhất là chọn theo cách dữ liệu được truy cập.
5. Database: Có các hướng chính như Relational, NoSQL, Data Warehouse, và bản chất là chọn theo kiểu dữ liệu và mục tiêu sử dụng.
6. Networking & Content Delivery: Tập trung vào việc kết nối đúng, bảo vệ đúng, điều hướng đúng và phân phối nhanh hơn với VPC, Load Balancer, Route 53, CloudFront.
7. Security & Compliance: AWS bảo vệ hạ tầng cloud, còn bạn bảo vệ dữ liệu, quyền truy cập, cấu hình và ứng dụng của mình.
8. Pricing & Billing: Có nhiều mô hình giá như On-Demand, RI, Savings Plans, Spot..., và ý chính là đổi giữa linh hoạt, cam kết và chi phí.

Hình 9: (Nguồn: dataminded)

X. Tài liệu tham khảo

[1] Slide AIO AWS Cloud Practitioner Buổi 1
[2] Video bài giảng AIO AWS Cloud Practitioner Buổi 1
[3] Predocs AIO AWS Cloud Practitioner Buổi 2
[4] Slide AIO AWS Cloud Practitioner Buổi 3
[5] Video bài giảng AIO AWS Cloud Practitioner Buổi 3
[6] Slide AIO AWS Cloud Practitioner Buổi 4
[7] Video bài giảng AIO AWS Cloud Practitioner Buổi 4
[8] Advantages of Cloud Computing in AWS
[9] What Are the Key Differences Between AWS EC2 and AWS Lambda?
[10] Amazon S3 - Storage Classes