Ngân hàng đề — AWS Certified Solutions Architect Associate

Đáp án

C — Vertical scaling nghĩa là chạy cùng phần mềm trên máy LỚN HƠN, bị giới hạn bởi năng lực của một máy chủ đơn lẻ. Horizontal scaling là THÊM MÁY vào nhóm hiện có và không gặp giới hạn của từng máy.

Vì sao đúng

Đây là định nghĩa chuẩn của hai hình thức mở rộng.

Vertical scaling (mở rộng theo chiều dọc) — "scale up":

Cùng một máy, nâng cấp lên cấu hình mạnh hơn
    t3.medium (2 vCPU, 4 GB)
        ↓
    m5.4xlarge (16 vCPU, 64 GB)
        ↓
GIỚI HẠN: có một loại instance LỚN NHẤT
    → không thể vượt qua năng lực của một máy vật lý

Horizontal scaling (mở rộng theo chiều ngang) — "scale out":

Thêm nhiều máy giống nhau vào nhóm
    1 máy → 10 máy → 100 máy → 1.000 máy
        ↓
KHÔNG có giới hạn cứng của từng máy
    → cộng dồn năng lực

Và đó chính là lý do đề nói microservice nên co giãn theo chiều ngang:

Microservice tách rời nhau
    → mỗi dịch vụ co giãn ĐỘC LẬP theo nhu cầu riêng
    → dịch vụ thanh toán đông thì chỉ thêm máy cho nó
    → không phải nâng cấp cả hệ thống

Bảng so sánh đầy đủ: | | Vertical (scale up) | Horizontal (scale out) | |---|---|---| | Cách làm | máy LỚN HƠN | THÊM máy | | Giới hạn | năng lực một máy | gần như không có | | Thời gian ngừng | thường CẦN khởi động lại | KHÔNG | | Chịu lỗi | kém — một máy là điểm hỏng đơn | tốt — mất một máy vẫn chạy | | Độ phức tạp ứng dụng | thấp | cao hơn — phải không lưu trạng thái |

Vì sao các phương án khác sai

• **B. Horizontal là chạy trên máy lớn hơn; Vertical là thêm máy — đây là phương án gần nhất và là bẫy chính: nó đảo ngược hai định nghĩa. Nội dung mô tả đúng, chỉ gán nhầm tên.
• **A. Vertical nghĩa là chạy trên kiến trúc serverless với Lambda — sai định nghĩa: serverless là một mô hình triển khai, không phải một hình thức mở rộng. (Và Lambda thực ra mở rộng theo chiều NGANG — nó tạo thêm môi trường thực thi.)
• **D. Horizontal nghĩa là chạy trên container nhỏ hơn với ECS hoặc EKS — nhầm khái niệm: dùng container là lựa chọn về cách đóng gói, không phải định nghĩa của mở rộng ngang.

Ghi nhớ

Hai hình thức mở rộng — thuộc lòng:

VERTICAL (scale UP)    = máy TO HƠN     → có TRẦN
HORIZONTAL (scale OUT) = NHIỀU máy hơn  → gần như không trần

Mẹo nhớ:

Vertical   = chiều DỌC  = một cột cao dần → có giới hạn chiều cao
Horizontal = chiều NGANG = thêm cột       → thêm bao nhiêu cũng được

Các dịch vụ AWS theo hình thức mở rộng: | Dịch vụ | Mở rộng | |---|---| | EC2 Auto Scaling | ngang | | ECS/EKS service scaling | ngang | | Lambda | ngang (tự động) | | DynamoDB | ngang (tự động) | | S3 | ngang (tự động, vô hạn) | | RDS read replica | ngang (chỉ cho ĐỌC) | | RDS đổi instance class | dọc | | Aurora Serverless v2 | dọc, tự động và mượt | | ElastiCache thêm node | ngang |

Chú ý dòng RDS: cơ sở dữ liệu quan hệ khó mở rộng ngang cho GHI.

Đọc  → thêm read replica (ngang) ✅
Ghi  → chỉ có một primary
       → phải mở rộng DỌC (instance lớn hơn)
       → hoặc phân mảnh (sharding) ở tầng ứng dụng

Đây là lý do tầng dữ liệu thường là nút thắt cuối cùng của hệ thống phân tán.

Ba điều kiện để ứng dụng mở rộng ngang được: | Điều kiện | Chi tiết | |---|---| | KHÔNG LƯU TRẠNG THÁI trên máy | phiên đăng nhập ở ElastiCache hoặc DynamoDB | | Không phụ thuộc đĩa cục bộ | tệp ở S3 hoặc EFS | | Không giả định máy nào xử lý request nào | mọi máy tương đương |

Điều kiện đầu là rào cản phổ biến nhất khi hiện đại hoá ứng dụng cũ.

Nơi lưu trạng thái đúng: | Loại dữ liệu | Nơi lưu | |---|---| | Phiên đăng nhập | ElastiCache hoặc DynamoDB | | Tệp người dùng | S3 hoặc EFS | | Dữ liệu ứng dụng | RDS, Aurora, DynamoDB | | Log | CloudWatch Logs hoặc S3 |

Ba lợi ích của mở rộng ngang ngoài khả năng mở rộng: | Lợi ích | Chi tiết | |---|---| | Chịu lỗi | mất một máy không làm sập dịch vụ | | Không gián đoạn khi co giãn | thêm hoặc bớt máy mà không dừng | | Triển khai từng phần | rolling update, canary |

Và mở rộng dọc vẫn có chỗ đứng: | Trường hợp | Lý do | |---|---| | Cơ sở dữ liệu quan hệ (ghi) | không phân mảnh được dễ dàng | | Ứng dụng cũ không tách được | monolith có trạng thái | | Cần nhiều bộ nhớ cho một tiến trình | in-memory database |

Ba nguyên tắc thiết kế microservice liên quan tới câu hỏi: | Nguyên tắc | Chi tiết | |---|---| | Tách rời chi tiết (fine-grained decoupling) | mỗi dịch vụ co giãn độc lập | | Giao tiếp qua API rõ ràng | không chia sẻ database | | Chịu được lỗi của dịch vụ khác | circuit breaker, retry với backoff |

Dòng giữa đáng nhấn mạnh: nếu nhiều microservice dùng chung một database, chúng không thực sự tách rời — tầng dữ liệu vẫn là điểm nghẽn chung và là ràng buộc khi triển khai.

Và một lời khuyên thực tế: đừng chuyển sang microservice chỉ vì khả năng mở rộng. Một monolith được thiết kế không lưu trạng thái cũng mở rộng ngang rất tốt sau ALB và Auto Scaling group — và đơn giản hơn nhiều về vận hành. Microservice đáng giá khi các phần của hệ thống cần nhịp phát triển và triển khai độc lập, chứ không chỉ vì con số quy mô.

Đáp án

D — Thêm mục mới vào route table: 0.0.0.0/0 → Internet Gateway.

Vì sao đúng

Đề cho ba dữ kiện đã kiểm tra, và chúng loại trừ mọi nguyên nhân khác:

✅ Internet Gateway đã gắn vào VPC
✅ EC2 instance có IP công khai
✗ Instance vẫn không truy cập được từ Internet
    ↓
Còn thiếu: ROUTE dẫn lưu lượng ra Internet Gateway

Route table mặc định của VPC chỉ có một mục:

10.0.0.0/27 → local
    → cho phép các tài nguyên TRONG VPC nói chuyện với nhau
    → KHÔNG có đường nào ra Internet

Thiếu route 0.0.0.0/0 thì subnet vẫn là PRIVATE:

Gắn Internet Gateway vào VPC ≠ subnet có đường ra Internet
    → IGW chỉ là cánh cổng
    → phải có ROUTE chỉ tới nó thì gói tin mới biết đường đi

Route cần thêm:

Destination: 0.0.0.0/0     ← mọi địa chỉ không thuộc VPC
Target:      igw-xxxxx

aws ec2 create-route --route-table-id rtb-0abc123   --destination-cidr-block 0.0.0.0/0 --gateway-id igw-0abc123

Và 0.0.0.0/0 nghĩa là "mọi đích còn lại":

Route table được đánh giá theo tiền tố DÀI NHẤT khớp trước:
    10.0.0.0/27 → local     (cụ thể hơn, ưu tiên)
    0.0.0.0/0   → igw       (bắt phần còn lại)

(Ảnh route table trong đề không hiển thị được ở đây, nhưng dạng câu hỏi này luôn cho thấy route table chỉ có mục local — và đó chính là vấn đề.)

Vì sao các phương án khác sai

• **C. Thêm mục 10.0.0.0/27 → Internet Gateway — đây là phương án gần nhất vì cũng thêm route tới IGW, nhưng nó sai đích: 10.0.0.0/27 là chính CIDR của VPC, và nó đã có route local. Thêm route này không tạo đường ra Internet nào.
• **B. Sửa mục hiện có thành 10.0.0.0/27 → Internet Gateway — còn tệ hơn: nó phá vỡ giao tiếp nội bộ trong VPC bằng cách đẩy lưu lượng nội bộ ra IGW. (Thực tế AWS không cho sửa route local.)
• **A. Thêm mục 0.0.0.0/27 → Internet Gateway — ký hiệu CIDR vô nghĩa: 0.0.0.0/27 mô tả 32 địa chỉ đầu tiên của không gian IPv4, không phải "mọi địa chỉ". Để bắt mọi đích phải dùng /0.

Ghi nhớ

Public subnet và private subnet — khác biệt DUY NHẤT: | | Public subnet | Private subnet | |---|---|---| | Route 0.0.0.0/0 | → Internet Gateway | → NAT Gateway (hoặc không có) | | Ra Internet | trực tiếp | qua NAT | | Vào từ Internet | được | không |

Không có công tắc "public/private" nào cả — nó hoàn toàn do route table quyết định.

Ba điều kiện để instance truy cập được từ Internet:

① Internet Gateway gắn vào VPC
② Route table của subnet có 0.0.0.0/0 → IGW
③ Instance có IP công khai hoặc Elastic IP
④ Security group cho phép cổng cần thiết
⑤ NACL cho phép cả vào lẫn ra (stateless)

Đề đã có ①, ③ — thiếu ②.

Ký hiệu CIDR — bảng cần thuộc: | Ký hiệu | Số địa chỉ | Ý nghĩa | |---|---|---| | /32 | 1 | đúng một máy | | /27 | 32 | mạng nhỏ | | /24 | 256 | | | /16 | 65.536 | VPC lớn | | /0 | TẤT CẢ | mọi địa chỉ |

Quy tắc: số càng LỚN thì phạm vi càng HẸP.

Và VPC /27 trong đề rất nhỏ:

/27 → 32 địa chỉ
AWS giữ 5 địa chỉ mỗi subnet:
    .0 mạng, .1 router, .2 DNS, .3 dự phòng, .31 broadcast
        ↓
    còn 27 địa chỉ dùng được cho CẢ VPC

Đây là kích thước quá nhỏ cho môi trường sản xuất — nên chọn /16 hoặc ít nhất /20 ngay từ đầu, vì CIDR chính không đổi được sau khi tạo.

Cách route table được đánh giá:

Tiền tố DÀI NHẤT khớp được ưu tiên (longest prefix match)
    10.0.1.0/24 → pcx-xxx   (cụ thể nhất)
    10.0.0.0/16 → local
    0.0.0.0/0   → igw-xxx   (bắt phần còn lại)

Ba loại target thường gặp trong route table: | Target | Dùng cho | |---|---| | local | tự động, không xoá được — giao tiếp trong VPC | | Internet Gateway (igw-) | public subnet ra Internet | | NAT Gateway (nat-) | private subnet ra Internet | | VPC Endpoint (vpce-) | tới S3, DynamoDB | | VPC Peering (pcx-) | tới VPC khác | | Transit Gateway (tgw-) | tới nhiều VPC hoặc mạng tại chỗ | | Virtual Private Gateway (vgw-) | tới mạng tại chỗ qua VPN |

Và main route table là mặc định cho mọi subnet mới:

Tạo subnet mới → TỰ ĐỘNG gắn với main route table
    ↓
Thêm route ra IGW vào MAIN route table
    → MỌI subnet chưa gắn bảng riêng đều thành PUBLIC
    → kể cả subnet bạn định làm private

Thực hành tốt: giữ main route table KHÔNG có đường ra Internet, và tạo custom route table riêng cho public subnet.

Ba công cụ chẩn đoán mạng VPC: | Công cụ | Việc | |---|---| | VPC Reachability Analyzer | kiểm tra đường đi mà không cần gửi lưu lượng thật | | VPC Flow Logs | ghi ACCEPT/REJECT cho từng luồng | | Network Access Analyzer | phân tích cấu hình, tìm đường đi không mong muốn |

Reachability Analyzer là công cụ nhanh nhất cho tình huống này:

aws ec2 create-network-insights-path   --source igw-0abc123 --destination i-0def456   --protocol tcp --destination-port 443

Nó chỉ ra chính xác thành phần nào chặn đường — route table, security group, hay NACL.

Và một lời khuyên khi dựng VPC: hãy dùng CloudFormation hoặc Terraform với template chuẩn thay vì tạo tay. Route table, IGW, NAT, và các subnet là những thứ dễ quên một mảnh — và triệu chứng thường là timeout không rõ nguyên nhân.

Đáp án

A — Khởi chạy một Network Load Balancer.

Vì sao đúng

Đề nêu ba yêu cầu, và cả ba đều là đặc điểm riêng của NLB: | Yêu cầu | Cơ chế | |---|---| | Cân bằng tải TCP ở TẦNG 4 (transport) | NLB hoạt động ở tầng 4 | | Hàng TRIỆU request mỗi giây | NLB xử lý được quy mô đó | | Độ trễ CỰC THẤP (ultra-low latency) | NLB có độ trễ thấp nhất trong các loại ELB |

Vì sao NLB nhanh hơn ALB:

ALB (tầng 7):
    → phân tích nội dung HTTP: header, đường dẫn, cookie
    → mỗi bước phân tích thêm độ trễ

NLB (tầng 4):
    → chỉ nhìn IP và cổng
    → chuyển tiếp gói tin gần như trực tiếp
    → độ trễ tính bằng chục microgiây

Và với game, độ trễ là yếu tố quyết định trải nghiệm — đó là lý do đề nhấn mạnh "ultra-low latencies".

Và NLB hỗ trợ Fargate qua target type ip:

Task Fargate có ENI riêng với IP riêng tư
    → NLB đăng ký target theo IP
    → ECS tự đăng ký và huỷ đăng ký khi task thay đổi

aws elbv2 create-target-group --name tg-may-chu-game   --protocol TCP --port 7777 --vpc-id vpc-0abc123   --target-type ip --health-check-protocol TCP

Ba đặc điểm khác của NLB phù hợp với game: | Đặc điểm | Lợi ích | |---|---| | IP tĩnh mỗi AZ | client game giữ được địa chỉ cố định | | Giữ IP nguồn của client | máy chủ game biết địa chỉ thật của người chơi | | Hỗ trợ UDP | nhiều game dùng UDP cho dữ liệu thời gian thực |

Vì sao các phương án khác sai

• **B. Khởi chạy Application Load Balancer — đây là phương án gần nhất vì cũng là load balancer được quản lý và hỗ trợ Fargate, nhưng nó hoạt động ở tầng 7: ALB chỉ xử lý HTTP và HTTPS, có độ trễ cao hơn, và không đáp ứng được yêu cầu "Layer 4" mà đề nêu rõ.
• **C. Tạo bản ghi Route 53 với Weighted routing để cân bằng tải — không phải cân bằng tải thật: DNS chia lưu lượng theo mỗi lần phân giải, không theo từng kết nối. Client cache kết quả DNS nên tỷ lệ thực tế lệch, và nó không biết tình trạng tải của từng máy chủ.
• **D. Tự viết một microservice làm load balancer vì ALB và NLB không dùng được với Fargate — tiền đề sai: cả ALB lẫn NLB đều hỗ trợ Fargate qua target type ip. Tự viết load balancer là thêm một thành phần phải bảo trì và là điểm hỏng mới.

Ghi nhớ

Bốn loại Elastic Load Balancer — bảng cần thuộc: | | ALB | NLB | GWLB | CLB | |---|---|---|---|---| | Tầng | 7 (HTTP/HTTPS) | 4 (TCP/UDP/TLS) | 3 (IP) | 4 và 7 | | Độ trễ | thấp | cực thấp | thấp | thấp | | UDP | ❌ | ✅ | ✅ | ❌ | | IP tĩnh | ❌ | ✅ mỗi AZ | — | ❌ | | Giữ IP nguồn | ❌ (dùng X-Forwarded-For) | ✅ | ✅ | ❌ | | Định tuyến theo URL/host | ✅ | ❌ | ❌ | hạn chế | | Quy mô | rất cao | hàng triệu request/giây | cao | thấp hơn |

Từ khoá nhận diện NLB trong đề thi:

"Layer 4" / "transport level"
"TCP" hoặc "UDP"
"static IP address"
"millions of requests per second"
"ultra-low latency" / "extreme performance"
"gaming" / "IoT" / "VoIP"

Đề này có bốn trong sáu dấu hiệu.

Ba target type của ALB và NLB: | Loại | Target là | |---|---| | instance | EC2 instance ID | | ip | địa chỉ IP — dùng cho Fargate và cả máy TẠI CHỖ | | alb (chỉ NLB) | một ALB làm target |

Fargate BẮT BUỘC dùng target-type ip — vì task không phải EC2 instance.

Ba lưu ý khi dùng NLB cho game: | Lưu ý | Chi tiết | |---|---| | Health check của NLB dùng TCP, HTTP hoặc HTTPS | KHÔNG có health check UDP | | Cross-zone load balancing TẮT mặc định | bật lên nếu cần phân phối đều | | NLB có security group (từ 2023) | trước đây không có |

Dòng đầu là chi tiết triển khai quan trọng với game UDP: máy chủ game phải phơi thêm một endpoint TCP hoặc HTTP đơn giản để NLB biết nó còn sống.

Và cross-zone có đánh đổi chi phí:

TẮT:  lưu lượng ở lại trong AZ → không phí truyền chéo AZ
BẬT:  phân phối đều hơn → nhưng TÍNH PHÍ ~0,01 USD/GB mỗi chiều

Và với game toàn cầu, AWS Global Accelerator là bổ sung rất đáng giá:

Global Accelerator:
    ✓ hai IP TĨNH ANYCAST toàn cầu
    ✓ người chơi kết nối tới điểm biên GẦN NHẤT
    ✓ lưu lượng đi trên mạng xương sống AWS thay vì Internet công cộng
    ✓ tự chuyển sang Region khác khi có sự cố

Kết hợp Global Accelerator + NLB là kiến trúc chuẩn cho game nhiều người chơi toàn cầu.

Ba lựa chọn chạy máy chủ game trên AWS: | Lựa chọn | Đặc điểm | |---|---| | Fargate + NLB | không quản lý máy chủ ← đề này | | EC2 + NLB | kiểm soát đầy đủ, dùng được instance chuyên biệt | | Amazon GameLift | dịch vụ chuyên cho game — có matchmaking, đặt phiên chơi, tự co giãn |

GameLift đáng biết: nó lo phần ghép trận, quản lý phiên chơi, và đặt người chơi vào máy chủ có độ trễ thấp nhất — những việc mà tự làm rất phức tạp.

Ba lưu ý về Fargate cho máy chủ game: | Lưu ý | Chi tiết | |---|---| | Không dùng được GPU | game cần render phía máy chủ phải dùng EC2 | | Task khởi động mất 30–60 giây | cân nhắc giữ sẵn dung lượng | | Ràng buộc kết hợp CPU và bộ nhớ | không chọn tuỳ ý |

Và một lời khuyên về co giãn: với game, hãy dùng scheduled scaling cho các khung giờ cao điểm biết trước, kết hợp target tracking cho phần bất ngờ. Người chơi rời đi nếu phải chờ — và mở rộng phản ứng sau khi tải đã tăng thường là quá muộn.

Đáp án

A — Dùng versioned object (bật versioning cho bucket).

Vì sao đúng

Đề nêu yêu cầu rõ: khi tải ảnh mới lên, phải GIỮ LẠI ảnh cũ, không để bị ghi đè — và versioning là cơ chế chính xác cho việc đó.

Cách versioning hoạt động:

Không có versioning:
    PUT object cùng key → GHI ĐÈ bản cũ
    → bản cũ MẤT VĨNH VIỄN

Có versioning:
    PUT object cùng key → tạo VERSION MỚI
    → bản cũ vẫn còn với version ID riêng
    → truy cập được bất cứ lúc nào

aws s3api put-bucket-versioning --bucket kho-anh-y-te   --versioning-configuration Status=Enabled

Truy cập phiên bản cụ thể:

aws s3api list-object-versions --bucket kho-anh-y-te --prefix benh-nhan-001/
aws s3api get-object --bucket kho-anh-y-te --key benh-nhan-001/anh.dcm   --version-id 3HL4kqtJvjVBH40Nrjfkd --output-file anh-cu.dcm

Và versioning còn bảo vệ khỏi xoá nhầm:

DELETE không kèm version ID → chỉ tạo DELETE MARKER
    → các phiên bản cũ VẪN CÒN
    → xoá delete marker là khôi phục được

Với ảnh y tế, đây là yêu cầu nghiêm túc — dữ liệu chẩn đoán phải giữ được lịch sử để đối chiếu diễn biến bệnh.

Vì sao các phương án khác sai

• **B. Invalidate các tệp trong CloudFront distribution — đây là phương án gần nhất vì cũng liên quan tới việc cập nhật nội dung, nhưng nó giải quyết vấn đề CACHE, không phải LƯU TRỮ: invalidation buộc CloudFront lấy lại bản mới từ origin. Nó không ngăn được việc ảnh cũ trong S3 bị ghi đè.
• **C. Thêm cache behavior riêng với Minimum TTL bằng 0 — cùng vấn đề: đây là cấu hình cache của CloudFront. Nó khiến CloudFront luôn lấy bản mới nhất, nhưng bản cũ vẫn đã bị ghi đè ở S3.
• **D. Thêm chỉ thị Cache-Control: no-cache, no-store, private trong S3 — cũng chỉ ảnh hưởng cache, và còn làm mất hết lợi ích của CDN.

Ghi nhớ

Ba tính năng của S3 versioning: | Tính năng | Chi tiết | |---|---| | Giữ mọi phiên bản của object | ghi đè không mất dữ liệu | | Xoá mềm bằng delete marker | khôi phục được | | Bảo vệ khỏi lỗi ứng dụng và người dùng | quay lại bản trước bất cứ lúc nào |

Ba trạng thái của versioning: | Trạng thái | Đặc điểm | |---|---| | Unversioned | mặc định, ghi đè mất dữ liệu | | Enabled | giữ mọi phiên bản | | Suspended | ngừng tạo phiên bản mới, nhưng phiên bản cũ VẪN CÒN |

Và một điều quan trọng: KHÔNG TẮT versioning được — chỉ tạm dừng (Suspended). Các phiên bản đã tạo vẫn tồn tại và vẫn tính phí.

Ba lưu ý về chi phí khi bật versioning: | Lưu ý | Chi tiết | |---|---| | Mỗi phiên bản tính phí lưu trữ RIÊNG | 10 lần ghi đè = 10 bản đầy đủ | | Delete marker cũng chiếm chỗ (nhỏ) | | | Cần lifecycle rule để dọn | nếu không chi phí tăng vô hạn |

Lifecycle rule bắt buộc cho bucket có versioning:

{"Rules": [{
  "Status": "Enabled", "Filter": {},
  "NoncurrentVersionTransitions": [
    {"NoncurrentDays": 30, "StorageClass": "GLACIER"}],
  "NoncurrentVersionExpiration": {"NoncurrentDays": 365},
  "Expiration": {"ExpiredObjectDeleteMarker": true}}]}

Với ảnh y tế cần giữ lâu dài, chuyển phiên bản cũ sang Glacier là tối ưu chi phí quan trọng.

Và versioning là ĐIỀU KIỆN BẮT BUỘC cho ba tính năng khác: | Tính năng | Vì sao cần versioning | |---|---| | Cross-Region Replication | theo dõi trạng thái sao chép theo version ID | | S3 Object Lock | khoá áp cho từng phiên bản | | MFA Delete | yêu cầu MFA để xoá phiên bản |

Và với dữ liệu y tế, S3 Object Lock đáng cân nhắc nghiêm túc:

{"ObjectLockEnabled": "Enabled",
 "Rule": {"DefaultRetention": {"Mode": "COMPLIANCE", "Years": 10}}}

Chế độ Compliance: KHÔNG AI xoá hay sửa được, kể cả root — đáp ứng yêu cầu WORM của nhiều quy định về hồ sơ y tế.

Và với CloudFront trong kiến trúc của đề, có một mẫu tốt hơn invalidation:

Thay vì ghi đè cùng key rồi invalidate:
    /anh/benh-nhan-001/v1.dcm
    /anh/benh-nhan-001/v2.dcm    ← URL MỚI cho ảnh mới
        ↓
    → không cần invalidation
    → TTL dài, tỷ lệ cache hit cao
    → ảnh cũ vẫn truy cập được qua URL cũ

Mẫu này gọi là "versioned URL" và là thực hành được khuyến nghị — invalidation tốn phí và mất vài phút để lan khắp mạng biên.

Ba biện pháp bảo vệ dữ liệu bổ sung cho ảnh y tế: | Biện pháp | Chống lại | |---|---| | Versioning | ghi đè và xoá nhầm ← câu này | | Cross-Region Replication | sự cố cả Region | | Mã hoá SSE-KMS | truy cập trái phép, và có audit trail |

Và tuân thủ HIPAA cần thêm:

✓ Ký BAA với AWS
✓ Chỉ dùng dịch vụ đủ điều kiện HIPAA (S3, CloudFront đều có)
✓ Bật CloudTrail data event — biết ai đọc ảnh nào

Và một lời khuyên: hãy bật MFA Delete cho bucket chứa dữ liệu y tế. Nó yêu cầu thiết bị MFA của tài khoản root để xoá vĩnh viễn một phiên bản — một rào cản đủ mạnh để ngăn cả lỗi vận hành lẫn hành vi cố ý.

Đáp án

A — Amazon Kinesis.

Vì sao đúng

Đề nêu ba yêu cầu, và Kinesis Data Streams đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Nhận toạ độ GPS mỗi 5 giây từ nhiều xe | luồng dữ liệu thông lượng cao | | NHIỀU consumer xử lý THỜI GIAN THỰC | nhiều consumer đọc độc lập cùng một stream | | Ứng dụng báo cáo RIÊNG phân tích dữ liệu tổng hợp | consumer thứ hai đọc cùng dữ liệu |

Vế "multiple consumers in real-time" là điều kiện quyết định:

Kinesis Data Streams:
    Một stream
        ├─▶ Consumer A: cảnh báo xe đi sai tuyến (thời gian thực)
        ├─▶ Consumer B: cập nhật vị trí lên bản đồ
        └─▶ Consumer C: ghi vào S3 cho ứng dụng báo cáo
    → mỗi consumer đọc theo TỐC ĐỘ và VỊ TRÍ RIÊNG
    → không ảnh hưởng lẫn nhau

Trong khi SQS thì không:

SQS: một thông điệp chỉ MỘT consumer đọc được
    → đọc xong là xoá
    → muốn nhiều bên xử lý phải nhân bản hàng đợi

Và Kinesis giữ dữ liệu để phát lại:

Giữ 1–365 ngày
    → consumer lỗi → đọc lại từ checkpoint
    → ứng dụng báo cáo chạy sau vẫn lấy được dữ liệu cũ

Và thông lượng khớp với quy mô của đề:

Mỗi xe gửi một bản ghi mỗi 5 giây
    → 10.000 xe → 2.000 bản ghi/giây
    → một shard chịu 1.000 bản ghi/giây
    → cần 2 shard

Chọn partition key là quyết định thiết kế quan trọng:

Partition key = ID xe tải
    → toạ độ của cùng một xe luôn vào CÙNG shard
    → giữ đúng THỨ TỰ cho từng xe
    → và phân tán đều qua các shard

Vì sao các phương án khác sai

• **D. Amazon Simple Queue Service (SQS) — đây là phương án gần nhất vì cũng nhận được luồng dữ liệu lớn, nhưng nó không hỗ trợ nhiều consumer độc lập: thông điệp bị xoá sau khi một consumer xử lý. Và standard queue không đảm bảo thứ tự — quan trọng với chuỗi toạ độ theo thời gian.
• **B. Amazon EMR — là nền tảng XỬ LÝ, không phải THU THẬP: EMR chạy Spark hoặc Hadoop trên dữ liệu đã có sẵn. Nó không nhận dữ liệu trực tiếp từ thiết bị.
• **C. Amazon AppStream — sai hoàn toàn: AppStream 2.0 là dịch vụ truyền ứng dụng desktop qua trình duyệt. Không liên quan tới dữ liệu luồng.

Ghi nhớ

Kinesis Data Streams và SQS — bảng phân biệt cốt lõi: | | Kinesis Data Streams | SQS | |---|---|---| | Nhiều consumer độc lập | ✅ mỗi cái đọc riêng | ❌ một thông điệp một người đọc | | Phát lại (replay) | ✅ 1–365 ngày | ❌ xoá sau khi xử lý | | Thứ tự | ✅ trong shard | ❌ (standard) / ✅ (FIFO) | | Mô hình | luồng — nhiều bên đọc cùng dữ liệu | hàng đợi — chia việc | | Mở rộng | theo shard | tự động, không giới hạn |

Quy tắc nhận diện:

"multiple consumers", "real-time", "replay", "ordered" → Kinesis Data Streams "decouple", "work queue", "process once" → SQS "fan-out to subscribers" → SNS

Bốn dịch vụ trong họ Kinesis: | Dịch vụ | Việc | |---|---| | Data Streams | luồng có phát lại, nhiều consumer ← câu này | | Data Firehose | giao dữ liệu tự động vào S3, Redshift, OpenSearch | | Managed Service for Apache Flink | phân tích luồng bằng SQL hoặc Flink | | Video Streams | video và âm thanh |

Thông lượng của một shard: | Chiều | Giới hạn | |---|---| | Ghi vào | 1 MB/giây hoặc 1.000 bản ghi/giây | | Đọc (standard) | 2 MB/giây chia cho mọi consumer | | Đọc (enhanced fan-out) | 2 MB/giây RIÊNG mỗi consumer |

Với ba consumer trở lên, hãy bật enhanced fan-out — nếu không chúng chia nhau 2 MB/giây.

Hai chế độ dung lượng: | Chế độ | Phù hợp | |---|---| | Provisioned | tải ổn định, rẻ hơn | | On-demand | tải khó đoán — tự mở rộng tới 200 MB/giây |

Với đội xe đang mở rộng, on-demand tránh được việc phải tính lại số shard.

Kiến trúc đầy đủ cho theo dõi phương tiện:

Xe tải (thiết bị GPS)
    ↓ IoT Core hoặc SDK
Kinesis Data Streams (giữ 24 giờ)
    ├─▶ Managed Service for Apache Flink
    │       → phát hiện xe đi sai tuyến, dừng quá lâu
    │       → cảnh báo thời gian thực
    ├─▶ Lambda → DynamoDB (vị trí hiện tại, truy vấn nhanh)
    └─▶ Firehose → S3 → Athena (ứng dụng báo cáo)

Và AWS IoT Core đáng cân nhắc cho tầng thu thập:

IoT Core:
    ✓ giao thức MQTT nhẹ, phù hợp thiết bị di động băng thông thấp
    ✓ xác thực bằng chứng chỉ X.509 cho từng thiết bị
    ✓ rule engine định tuyến thẳng vào Kinesis
    ✓ device shadow — giữ trạng thái khi thiết bị mất mạng

Với xe tải chạy qua vùng sóng yếu, MQTT và device shadow là ưu điểm thật.

Ba lưu ý khi thiết kế partition key: | Lưu ý | Chi tiết | |---|---| | Độ phân biệt CAO | tránh hot shard | | Cùng khoá → cùng shard → giữ thứ tự | dùng ID xe | | Tránh khoá theo thời gian | mọi bản ghi dồn vào một shard |

Ba metric cần đặt alarm: | Metric | Cảnh báo khi | |---|---| | GetRecords.IteratorAgeMilliseconds | consumer tụt hậu — nguy cơ mất dữ liệu | | WriteProvisionedThroughputExceeded | thiếu shard | | ReadProvisionedThroughputExceeded | quá nhiều consumer standard |

Và một lưu ý về chi phí: giữ dữ liệu lâu trong Kinesis khá đắt. Mẫu kinh tế hơn là giữ ngắn trong Kinesis (24 giờ, đủ để phát lại khi consumer lỗi) và đẩy sang S3 để lưu trữ dài hạn — S3 rẻ hơn hàng chục lần và Athena vẫn truy vấn được cho ứng dụng báo cáo.

Đáp án

A — CloudWatch Logs agent.

Vì sao đúng

Đề cần cách TỰ ĐỘNG gửi dữ liệu log từ EC2 instance lên CloudWatch Logs — và agent là thành phần dành riêng cho việc đó.

Vì sao cần agent:

CloudWatch thu thập metric từ TẦNG HYPERVISOR (bên ngoài máy ảo)
    → thấy được CPU, mạng, I/O ở mức thiết bị
    → KHÔNG thấy được nội dung BÊN TRONG hệ điều hành
        ↓
Tệp log nằm trên hệ thống tệp của instance
    → phải có tiến trình CHẠY TRONG máy đọc và đẩy lên
    → đó chính là CloudWatch agent

Cách agent hoạt động:

Agent theo dõi các tệp log đã khai
    → phát hiện dòng mới
    → đẩy lên CloudWatch Logs theo lô
    → tự xử lý xoay vòng tệp và thử lại khi lỗi mạng

Cấu hình mẫu:

{"logs": {"logs_collected": {"files": {"collect_list": [
  {"file_path": "/var/log/ung-dung/*.log",
   "log_group_name": "/he-thong-giam-sat/ung-dung",
   "log_stream_name": "{instance_id}",
   "timestamp_format": "%Y-%m-%d %H:%M:%S"}]}}}}

Và nên dùng UNIFIED CloudWatch agent — bản hợp nhất thu thập cả log lẫn metric:

Unified agent thu thập:
    ✓ tệp log (như agent cũ)
    ✓ metric BỘ NHỚ và DUNG LƯỢNG ĐĨA
      → hai thứ mà CloudWatch KHÔNG có mặc định

Triển khai hàng loạt bằng Systems Manager:

aws ssm send-command --document-name "AWS-ConfigureAWSPackage"   --targets "Key=tag:MoiTruong,Values=san-xuat"   --parameters '{"action":["Install"],"name":["AmazonCloudWatchAgent"]}'

Vì sao các phương án khác sai

• **B. CloudTrail với log file validation — đây là phương án gần nhất vì cũng là dịch vụ log của AWS, nhưng nó ghi loại dữ liệu khác: CloudTrail ghi lời gọi API tới AWS (ai tạo instance, ai sửa security group). Nó không thu thập log ứng dụng hay hệ điều hành từ bên trong máy.
• **D. CloudTrail Processing Library — là thư viện Java để ĐỌC và xử lý log CloudTrail đã có. Nó không đẩy log lên CloudWatch.
• **C. AWS Transfer for SFTP — là dịch vụ truyền tệp: nó cung cấp endpoint SFTP để đối tác tải tệp lên S3. Không liên quan tới thu thập log.

Ghi nhớ

Ba dịch vụ log của AWS — mỗi cái một loại dữ liệu: | Dịch vụ | Ghi gì | |---|---| | CloudWatch Logs | log ỨNG DỤNG và HỆ ĐIỀU HÀNH — cần agent | | CloudTrail | lời gọi API tới AWS — ai làm gì | | VPC Flow Logs | metadata lưu lượng mạng — không có nội dung gói tin |

Ba nguồn này trả lời ba câu hỏi khác nhau:

CloudWatch Logs → "ứng dụng báo lỗi gì?"
CloudTrail      → "ai đã xoá security group đó?"
VPC Flow Logs   → "gói tin có tới được đích không?"

Metric nào cần agent, metric nào không: | Metric | Cần agent | |---|---| | CPUUtilization | ❌ có sẵn | | NetworkIn / NetworkOut | ❌ có sẵn | | DiskReadOps (mức thiết bị) | ❌ có sẵn | | Mức dùng BỘ NHỚ | ✅ CẦN AGENT | | Dung lượng đĩa CÒN TRỐNG | ✅ CẦN AGENT | | Danh sách tiến trình | ✅ cần agent |

Hai dòng in đậm là lý do nên cài unified agent cho mọi instance sản xuất — chúng là metric cơ bản nhất mà lại không có mặc định.

Ba yêu cầu để agent hoạt động: | Yêu cầu | Chi tiết | |---|---| | IAM role có quyền ghi CloudWatch Logs | policy CloudWatchAgentServerPolicy | | Đường mạng tới endpoint CloudWatch | NAT gateway hoặc VPC endpoint | | Tệp cấu hình agent | lưu cục bộ hoặc trong Parameter Store |

Lưu cấu hình trong Parameter Store là thực hành tốt cho nhiều máy:

aws ssm put-parameter --name "AmazonCloudWatch-cau-hinh-chung"   --type String --value file://cau-hinh.json

aws ssm send-command --document-name "AmazonCloudWatch-ManageAgent"   --targets "Key=tag:MoiTruong,Values=san-xuat"   --parameters '{"action":["configure"],
                 "optionalConfigurationSource":["ssm"],
                 "optionalConfigurationLocation":["AmazonCloudWatch-cau-hinh-chung"]}'

Sửa một chỗ, áp cho cả đội máy.

Ba khái niệm của CloudWatch Logs: | Khái niệm | Ý nghĩa | |---|---| | Log group | nhóm log cùng loại, đặt thời hạn giữ ở đây | | Log stream | một nguồn cụ thể (thường là một instance) | | Log event | một dòng log kèm timestamp |

Và đặt thời hạn giữ là bắt buộc:

aws logs put-retention-policy --log-group-name /he-thong-giam-sat/ung-dung   --retention-in-days 30

Mặc định là VÔ HẠN — với hệ thống ghi log liên tục, chi phí tăng đều đặn mãi.

Ba cách phân tích log trong CloudWatch: | Cách | Đặc điểm | |---|---| | Logs Insights | truy vấn bằng ngôn ngữ riêng, rất nhanh | | Metric filter | biến mẫu trong log thành METRIC để đặt alarm | | Subscription filter | chuyển tiếp sang Kinesis, Lambda, OpenSearch |

Metric filter là cách biến log thành cảnh báo:

aws logs put-metric-filter --log-group-name /he-thong-giam-sat/ung-dung   --filter-name dem-loi --filter-pattern '"ERROR"'   --metric-transformations       metricName=SoLoi,metricNamespace=UngDung,metricValue=1

Ví dụ truy vấn Logs Insights:

fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(1h)
| sort @timestamp desc

Ba lưu ý về chi phí CloudWatch Logs: | Khoản | Chi tiết | |---|---| | Dữ liệu nạp vào | ~0,50 USD/GB — khoản lớn nhất | | Lưu trữ | theo GB-tháng | | Truy vấn Logs Insights | theo dữ liệu quét |

Ba cách giảm chi phí:

✓ Chỉ thu thập tệp log THỰC SỰ CẦN
✓ Đặt thời hạn giữ hợp lý (30–90 ngày)
✓ Đẩy log cần giữ lâu sang S3 qua subscription filter → Firehose

Và một lời khuyên cho hệ thống giám sát mạng như đề mô tả: hãy cân nhắc CloudWatch agent thu thập cả VPC Flow Logs và log ứng dụng vào cùng một log group theo chủ đề. Khi điều tra sự cố mạng, việc đối chiếu hai loại log theo cùng mốc thời gian trong một truy vấn Logs Insights nhanh hơn nhiều so với xem hai nơi.

Đáp án

B — Chuyển dữ liệu JSON sang định dạng Apache Parquet; đảm bảo người dùng có quyền IAM lakeformation:GetDataAccess để kiểm soát truy cập dữ liệu bên dưới.

Vì sao đúng

Đề nêu hai yêu cầu, và đáp án giải quyết lần lượt: | Yêu cầu | Giải pháp | |---|---| | Cải thiện hiệu năng truy vấn Athena | chuyển sang Parquet | | Đảm bảo an toàn dữ liệu | quyền lakeformation:GetDataAccess |

Vì sao Parquet cải thiện hiệu năng mạnh nhất:

JSON (định dạng DÒNG, dạng văn bản):
    → Athena phải đọc TOÀN BỘ mỗi bản ghi
    → kể cả khi truy vấn chỉ cần 3 trong 50 cột
    → không nén hiệu quả

Parquet (định dạng CỘT, nén sẵn):
    → chỉ đọc các CỘT được chọn
    → nén rất tốt
    → có thống kê ở mỗi khối để bỏ qua dữ liệu không khớp

Con số cụ thể:

100 GB JSON, SELECT ba cột       → quét 100 GB → ~0,50 USD
Cùng dữ liệu ở Parquet           → quét ~2 GB  → ~0,01 USD
    → nhanh hơn và rẻ hơn tới 50 lần

Và Athena tính phí theo DỮ LIỆU QUÉT — nên chuyển sang Parquet cải thiện cả tốc độ lẫn chi phí.

Chuyển đổi bằng CTAS ngay trong Athena:

CREATE TABLE du_lieu_parquet
WITH (format = 'PARQUET',
      parquet_compression = 'SNAPPY',
      partitioned_by = ARRAY['ngay'],
      external_location = 's3://kho-du-lieu/parquet/')
AS SELECT * FROM du_lieu_json;

Và lakeformation:GetDataAccess là quyền then chốt của Lake Formation:

Lake Formation cấp quyền ở mức bảng và cột
    → nhưng khi Athena thực sự đọc dữ liệu từ S3,
      nó cần Lake Formation cấp thông tin đăng nhập tạm thời
    → đó chính là GetDataAccess
        ↓
    Thiếu quyền này → truy vấn thất bại dù đã được cấp quyền bảng

Vì sao các phương án khác sai

• **A. Chuyển JSON sang CSV; dùng kiểm soát truy cập theo tài nguyên đặt tên (named resource) — đây là phương án gần nhất vì cũng đổi định dạng, nhưng CSV không cải thiện nhiều: nó vẫn là định dạng DÒNG và dạng văn bản — Athena vẫn phải đọc toàn bộ mỗi bản ghi. Cải thiện so với JSON là nhỏ so với Parquet.
• **C. Áp dụng minification và dùng kiểm soát truy cập theo THẺ (LF-TBAC) — minification chỉ bỏ khoảng trắng: nó giảm kích thước vài phần trăm, không đổi bản chất định dạng dòng. (LF-TBAC là cơ chế phân quyền hợp lệ và rất hữu ích, nhưng vế hiệu năng quá yếu.)
• **D. Nén thành GZIP và áp IAM policy với aws:SourceArn — GZIP không cho phép đọc chọn lọc: dữ liệu nén gzip không chia tách được, nên Athena phải giải nén toàn bộ mới đọc được. Và aws:SourceArn dùng để chống vấn đề "confused deputy" giữa các dịch vụ — không liên quan tới quyền truy cập dữ liệu của người dùng.

Ghi nhớ

Ba định dạng dữ liệu cho phân tích — bảng cần thuộc: | Định dạng | Kiểu | Đọc chọn cột | Nén | |---|---|---|---| | JSON, CSV | DÒNG, văn bản | ❌ phải đọc hết | kém | | Parquet | CỘT, nhị phân | ✅ | rất tốt | | ORC | CỘT, nhị phân | ✅ | rất tốt | | Avro | dòng, nhị phân | ❌ | tốt |

Parquet và ORC đều tốt; Parquet phổ biến hơn trong hệ sinh thái AWS.

Bốn tối ưu cho Athena — theo mức tác động: | Tối ưu | Mức giảm dữ liệu quét | |---|---| | Chuyển sang Parquet hoặc ORC | 80–90% | | Phân vùng theo cột hay lọc | rất lớn — bỏ qua hẳn phân vùng không cần | | Chọn cột cụ thể thay vì SELECT * | với định dạng cột, chỉ đọc cột được chọn | | Gộp tệp nhỏ thành tệp lớn | 128 MB – 1 GB mỗi tệp |

Và dòng cuối rất quan trọng với tình huống của đề:

"hàng trăm tài liệu JSON mỗi giờ"
    → hàng nghìn tệp nhỏ mỗi ngày
    → Athena phải mở từng tệp
    → chi phí overhead vượt cả chi phí đọc dữ liệu

Gộp tệp là tối ưu quan trọng ngang với đổi định dạng.

Cấu trúc phân vùng theo quy ước Hive:

s3://kho-du-lieu/parquet/nam=2026/thang=08/ngay=30/

SELECT * FROM du_lieu_parquet
WHERE nam='2026' AND thang='08';
-- chỉ quét phân vùng của tháng 8

Ba cách nén — chọn đúng: | Nén | Chia tách được | Tỷ lệ nén | |---|---|---| | Snappy | ✅ (với Parquet) | vừa | | GZIP | ❌ (với tệp văn bản) | cao | | BZIP2 | ✅ | cao, chậm | | Zstandard | ✅ | cao, nhanh |

Snappy với Parquet là kết hợp mặc định tốt — cân bằng giữa tốc độ giải nén và tỷ lệ nén.

Ba cấp phân quyền của AWS Lake Formation: | Cấp | Chi tiết | |---|---| | Named resource | cấp quyền cho database và bảng cụ thể | | Tag-based (LF-TBAC) | gắn thẻ cho tài nguyên, cấp quyền theo thẻ — mở rộng tốt | | Cột, dòng, ô | lọc chi tiết tới từng cột hoặc từng dòng |

LF-TBAC là cách quản lý tốt nhất khi có nhiều bảng:

Gắn thẻ: MucNhayCam = cao / trung-binh / thap
    → cấp quyền theo thẻ thay vì từng bảng
    → bảng mới gắn thẻ là tự có quyền phù hợp

Và Lake Formation lọc được tới TỪNG DÒNG:

-- Data filter: chỉ thấy dữ liệu của khu vực mình
CREATE DATA FILTER loc_theo_khu_vuc
ON TABLE du_lieu_parquet
ROW FILTER "khu_vuc = 'mien-nam'"
COLUMNS ALL;

Một bảng, nhiều nhóm người dùng, mỗi nhóm thấy phần dữ liệu của mình.

Ba quyền IAM cần thiết khi dùng Lake Formation với Athena: | Quyền | Việc | |---|---| | lakeformation:GetDataAccess | lấy thông tin đăng nhập tạm thời để đọc S3 | | glue:GetTable, glue:GetDatabase | đọc metadata | | athena:StartQueryExecution | chạy truy vấn |

Và Lake Formation thay thế việc cấp quyền S3 trực tiếp:

Không có Lake Formation:
    → phải cấp quyền S3 cho từng người dùng
    → phân quyền theo prefix, thô và khó quản lý

Có Lake Formation:
    → chỉ Lake Formation có quyền S3
    → người dùng được cấp quyền ở mức BẢNG và CỘT
    → Lake Formation cấp thông tin đăng nhập tạm thời khi truy vấn

Ba cách tự động hoá việc chuyển đổi định dạng: | Cách | Đặc điểm | |---|---| | AWS Glue ETL job | theo lịch, xử lý được khối lượng lớn | | Kinesis Data Firehose | chuyển sang Parquet NGAY trên đường ghi vào S3 | | Athena CTAS | thủ công hoặc theo lịch qua Lambda |

Firehose là cách tốt nhất cho dữ liệu đến liên tục:

{"DataFormatConversionConfiguration": {
   "Enabled": true,
   "OutputFormatConfiguration": {"Serializer": {"ParquetSerDe": {}}}},
 "BufferingHints": {"SizeInMBs": 128, "IntervalInSeconds": 300},
 "DynamicPartitioningConfiguration": {"Enabled": true}}

Nó giải quyết cả ba vấn đề cùng lúc: đổi định dạng, gộp tệp, và phân vùng.

Và một lời khuyên: hãy giữ cả dữ liệu JSON gốc lẫn bản Parquet trong giai đoạn đầu, và so sánh kết quả truy vấn để chắc chắn việc chuyển đổi không làm mất hay biến đổi dữ liệu. Sau khi đã tin tưởng, chuyển bản JSON sang Glacier thay vì xoá — chi phí rất thấp và bạn giữ được bản gốc để đối chiếu.

Đáp án

D — Tệp ứng dụng lưu trong S3; tệp log của máy chủ có thể tuỳ chọn lưu trong S3 hoặc CloudWatch Logs.

Vì sao đúng

Elastic Beanstalk lưu hai loại dữ liệu ở hai nơi khác nhau, và đáp án nêu đúng cả hai.

Tệp ứng dụng luôn ở S3:

Khi bạn chạy eb deploy hoặc tải gói lên
    → Elastic Beanstalk lưu phiên bản ứng dụng vào một S3 bucket
    → bucket tên dạng: elasticbeanstalk-<region>-<account-id>
    → instance tải gói từ đó khi khởi chạy

Và tệp log có HAI lựa chọn: | Lựa chọn | Đặc điểm | |---|---| | Xoay vòng log sang S3 | theo lịch, lưu trữ dài hạn | | Truyền log sang CloudWatch Logs | gần thời gian thực, tìm kiếm được ngay |

Bật cả hai:

# Xoay vòng log sang S3
aws elasticbeanstalk update-environment   --environment-name moi-truong-san-xuat   --option-settings     Namespace=aws:elasticbeanstalk:hostmanager,OptionName=LogPublicationControl,Value=true

# Truyền log sang CloudWatch Logs
aws elasticbeanstalk update-environment   --environment-name moi-truong-san-xuat   --option-settings     Namespace=aws:elasticbeanstalk:cloudwatch:logs,OptionName=StreamLogs,Value=true     Namespace=aws:elasticbeanstalk:cloudwatch:logs,OptionName=RetentionInDays,Value=30

Và lấy log nhanh bằng CLI:

eb logs                 # xem log gần đây
eb logs --all --zip     # tải toàn bộ log về

Vì sao các phương án khác sai

• **A. Tệp ứng dụng ở S3; log chỉ lưu được trên EBS volume của instance — đây là phương án gần nhất vì log THỰC SỰ nằm trên instance trước tiên, nhưng nó bỏ sót hai lựa chọn quan trọng: Elastic Beanstalk hỗ trợ cả xoay vòng sang S3 lẫn truyền sang CloudWatch Logs. Và giữ log chỉ trên instance là rủi ro — máy bị thay là mất log.
• **C. Log lưu trong CloudTrail hoặc CloudWatch Logs — sai một nửa: CloudTrail ghi lời gọi API tới AWS, không phải log ứng dụng hay log máy chủ web.
• **B. Log lưu trực tiếp vào Glacier hoặc CloudWatch Logs — sai: Elastic Beanstalk không ghi thẳng vào Glacier. (Có thể dùng lifecycle rule chuyển log từ S3 sang Glacier sau, nhưng đó là bước riêng.)

Ghi nhớ

Elastic Beanstalk lưu gì ở đâu: | Loại dữ liệu | Nơi lưu | |---|---| | Phiên bản ứng dụng (gói mã) | S3 (bucket do EB tạo) | | Tệp log | instance → tuỳ chọn S3 hoặc CloudWatch Logs | | Cấu hình môi trường | trong dịch vụ Elastic Beanstalk | | Dữ liệu ứng dụng | bạn tự lo — RDS, DynamoDB, S3 |

Hai chế độ log của Elastic Beanstalk: | Chế độ | Đặc điểm | |---|---| | Tail logs | 100 dòng cuối, xem nhanh | | Bundle logs | toàn bộ log, đóng gói zip lên S3 | | Rotate to S3 | tự xoay vòng theo lịch | | Stream to CloudWatch Logs | gần thời gian thực, tìm kiếm và đặt alarm được |

Và truyền sang CloudWatch Logs là lựa chọn nên bật:

Log nằm trên instance:
    → instance bị thay do co giãn hoặc lỗi
    → LOG BIẾN MẤT theo
        ↓
CloudWatch Logs:
    → log đã ở nơi an toàn ngay khi được ghi
    → tìm kiếm bằng Logs Insights
    → đặt alarm trên mẫu lỗi

Ba đường dẫn log mà Elastic Beanstalk thu thập: | Nền tảng | Đường dẫn | |---|---| | Node.js | /var/log/nodejs/nodejs.log | | Nginx (proxy) | /var/log/nginx/access.log, error.log | | Tất cả | /var/log/eb-engine.log, eb-hooks.log |

eb-engine.log là nơi xem lỗi triển khai — khi eb deploy thất bại, nguyên nhân thường nằm ở đó.

Ba khái niệm của Elastic Beanstalk: | Khái niệm | Ý nghĩa | |---|---| | Application | vùng chứa logic cho một ứng dụng | | Application version | một gói mã cụ thể, lưu ở S3 | | Environment | tập tài nguyên chạy một phiên bản (prod, staging) |

Và một cạm bẫy về chi phí: phiên bản ứng dụng tích tụ ở S3.

aws elasticbeanstalk update-application-resource-lifecycle   --application-name ung-dung-ban-ve   --resource-lifecycle-config '{
    "ServiceRole": "arn:aws:iam::...:role/aws-elasticbeanstalk-service-role",
    "VersionLifecycleConfig": {
      "MaxCountRule": {"Enabled": true, "MaxCount": 20,
                       "DeleteSourceFromS3": true}}}'

Không đặt lifecycle thì mọi phiên bản từng triển khai đều nằm mãi trong S3 — và có giới hạn 1.000 phiên bản mỗi ứng dụng.

Năm chính sách triển khai: | Chính sách | Đặc điểm | |---|---| | All at once | nhanh nhất, có gián đoạn | | Rolling | thay từng nhóm, giảm dung lượng tạm thời | | Rolling with additional batch | giữ đủ dung lượng | | Immutable | dựng đội máy MỚI — an toàn nhất | | Blue/Green | hai môi trường, swap URL |

Ba lưu ý quan trọng khi dùng Elastic Beanstalk: | Lưu ý | Chi tiết | |---|---| | RDS tạo TRONG môi trường bị XOÁ theo môi trường | tạo RDS RIÊNG cho sản xuất | | Không lưu trạng thái trên instance | dữ liệu ở RDS, S3, ElastiCache | | Dùng .ebextensions để tuỳ chỉnh | cài gói, đặt biến, chạy lệnh |

Dòng đầu là cạm bẫy nghiêm trọng nhất — xoá môi trường staging có thể vô tình xoá cả database nếu nó được tạo bên trong.

Và blue/green với Elastic Beanstalk rất gọn:

eb clone moi-truong-san-xuat --clone-name moi-truong-moi
eb deploy moi-truong-moi
# kiểm thử...
eb swap moi-truong-san-xuat --destination-name moi-truong-moi

Swap chỉ đổi bản ghi CNAME — quay lui bằng cách swap ngược, mất vài giây.

Ba metric sức khoẻ mà Elastic Beanstalk theo dõi: | Trạng thái | Ý nghĩa | |---|---| | Ok (xanh) | mọi thứ bình thường | | Warning (vàng) | có vấn đề nhưng chưa nghiêm trọng | | Degraded / Severe (đỏ) | cần can thiệp |

Bật enhanced health reporting để có chẩn đoán chi tiết hơn — nó cho biết chính xác instance nào và metric nào gây ra trạng thái xấu.

Và một lời khuyên vận hành: hãy bật truyền log sang CloudWatch Logs ngay từ đầu và đặt thời hạn giữ 30 ngày. Chi phí nhỏ, và nó loại bỏ hoàn toàn tình huống "instance đã bị thay, không còn log để điều tra" — đúng vấn đề mà đội DevOps trong đề đang gặp.

Đáp án

B và D.

• D — Dùng Consolidated Billing bằng cách tạo AWS Organizations liên kết tài khoản của các bộ phận với tài khoản mẹ của công ty
• B — Bật IAM cross-account access cho quản trị viên IT của công ty vào từng tài khoản con

Vì sao đúng

Đề nêu hai yêu cầu đối lập nhau, và hai đáp án giải quyết lần lượt: | Yêu cầu | Giải pháp | |---|---| | Mỗi bộ phận TỰ CHỦ quản trị tài nguyên riêng | tài khoản AWS RIÊNG cho từng bộ phận | | IT tập trung giám sát chi phí và quản trị | D — consolidated billing; B — cross-account access |

D — Consolidated billing cho tầm nhìn chi phí tập trung:

AWS Organizations liên kết mọi tài khoản
    → MỘT hoá đơn duy nhất
    → Cost Explorer xem được chi phí theo TỪNG tài khoản
    → và gộp mức dùng để hưởng giá bậc thang tốt hơn

Và lợi ích gộp mức dùng là thật:

Ba bộ phận, mỗi bộ phận dùng 40 TB S3:
    Riêng lẻ: mỗi bên tính ở bậc giá đầu (đắt nhất)
    Gộp lại:  120 TB → hưởng bậc giá thấp hơn cho phần vượt

Reserved Instance và Savings Plan cũng chia sẻ được giữa các tài khoản.

B — Cross-account access cho quản trị viên IT vào từng tài khoản:

Tài khoản con tạo IAM role
    → trust policy cho phép tài khoản IT đảm nhận
    → quản trị viên IT chuyển vai (switch role) vào từng tài khoản
    → giám sát và can thiệp khi cần

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
   "Action": "sts:AssumeRole",
   "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}}]}

Và mỗi bộ phận vẫn tự chủ trong tài khoản của mình — đúng yêu cầu "maintain administrative control of the discrete AWS resources they consume".

Vì sao các phương án khác sai

• **A. Dùng AWS Trusted Advisor và Resource Groups Tag Editor — đây là phương án gần nhất vì cả hai đều là công cụ quản trị hữu ích, nhưng chúng không tạo ra ranh giới tự chủ nào: Trusted Advisor đưa khuyến nghị, Tag Editor sửa thẻ hàng loạt. Không cái nào giải quyết bài toán tách quyền quản trị giữa các bộ phận.
• **C. Tạo VPC riêng cho mỗi bộ phận trong MỘT tài khoản và dùng Transit Gateway — không đủ cách ly: VPC tách được MẠNG, nhưng mọi bộ phận vẫn dùng chung IAM, hạn mức dịch vụ, và hoá đơn. Quản trị viên của một bộ phận vẫn thấy và có thể động tới tài nguyên của bộ phận khác.
• **E. Tạo Availability Zone riêng cho mỗi bộ phận — hiểu sai hoàn toàn về AZ: AZ là vị trí vật lý của AWS, bạn không "tạo" AZ. Và AZ không phải ranh giới bảo mật hay quản trị.

Ghi nhớ

Ba mức cách ly trên AWS — từ yếu tới mạnh: | Mức | Cách ly | Dùng khi | |---|---|---| | Thẻ + IAM condition (ABAC) | logic, trong một tài khoản | đội nhỏ, cùng môi trường | | VPC riêng | MẠNG | tách lưu lượng | | TÀI KHOẢN riêng | TUYỆT ĐỐI: IAM, hạn mức, hoá đơn | bộ phận độc lập ← câu này |

Ba lợi ích của mô hình đa tài khoản: | Lợi ích | Chi tiết | |---|---| | Cách ly rủi ro | sự cố ở một tài khoản không lan sang tài khoản khác | | Ranh giới hạn mức rõ ràng | một bộ phận dùng hết hạn mức không ảnh hưởng bộ phận khác | | Phân bổ chi phí tự nhiên | mỗi tài khoản một dòng trong hoá đơn |

Ba tính năng chính của AWS Organizations: | Tính năng | Việc | |---|---| | Consolidated billing | một hoá đơn, gộp mức dùng, chia sẻ RI và Savings Plan | | Service Control Policy (SCP) | đặt TRẦN QUYỀN cho tài khoản hoặc OU | | Quản lý tài khoản tập trung | tạo, mời, di chuyển tài khoản giữa các OU |

Và SCP là công cụ quản trị mạnh nhất mà câu hỏi không nêu:

{"Effect": "Deny",
 "Action": ["cloudtrail:StopLogging", "config:DeleteConfigurationRecorder"],
 "Resource": "*"}

SCP áp cho MỌI principal trong tài khoản, kể cả root của tài khoản thành viên — đó là thứ giữ được "governance" thật sự trong khi vẫn cho bộ phận tự chủ.

Ba cách thiết lập cross-account access: | Cách | Đặc điểm | |---|---| | IAM role với trust policy | cách truyền thống, dùng switch role | | IAM Identity Center với permission set | hiện đại hơn — quản lý tập trung, SSO | | Resource-based policy | cho tài nguyên cụ thể (S3, KMS) |

IAM Identity Center là cách được khuyến nghị hiện nay:

Một permission set định nghĩa một lần
    → gán cho nhóm người dùng × nhiều tài khoản
    → nhân viên đăng nhập một cửa, chọn tài khoản và vai
    → thông tin đăng nhập TẠM THỜI, tự hết hạn

Cấu trúc OU điển hình cho công ty đa quốc gia:

Root
├── Security          (log archive, audit)
├── Infrastructure    (mạng dùng chung, Transit Gateway)
├── Workloads
│   ├── BoPhanA
│   ├── BoPhanB
│   └── BoPhanC
└── Sandbox

Ba công cụ giám sát chi phí trong mô hình đa tài khoản: | Công cụ | Việc | |---|---| | Cost Explorer | phân tích theo tài khoản, dịch vụ, thẻ | | AWS Budgets | cảnh báo khi một tài khoản vượt ngưỡng | | Cost Anomaly Detection | phát hiện tăng bất thường | | Cost and Usage Report | dữ liệu chi tiết nhất, đưa vào Athena |

Và cost allocation tag là điều kiện để báo cáo có ý nghĩa:

Kích hoạt khoá thẻ trong Billing console
    → Cost Explorer nhóm chi phí theo thẻ
    → biết dự án nào, môi trường nào tốn bao nhiêu

Và tag policy của Organizations chuẩn hoá cách viết thẻ — tránh tình trạng mỗi bộ phận viết một kiểu.

Và AWS Control Tower dựng sẵn toàn bộ nền tảng này:

Control Tower tự tạo:
    ✓ cấu trúc OU chuẩn
    ✓ tài khoản Log Archive và Audit
    ✓ CloudTrail toàn tổ chức
    ✓ IAM Identity Center
    ✓ guardrail phòng ngừa và phát hiện
    ✓ Account Factory cấp tài khoản mới tự động

Với công ty có nhiều bộ phận trên toàn cầu, nó tiết kiệm hàng tuần công việc so với tự cấu hình.

Ba lưu ý về consolidated billing: | Lưu ý | Chi tiết | |---|---| | Tài khoản quản lý chịu trách nhiệm thanh toán | mọi chi phí dồn về đó | | Chia sẻ RI và Savings Plan bật/tắt được | mặc định bật | | Mức miễn phí tính CHUNG cho cả tổ chức | không nhân theo số tài khoản |

Và một lời khuyên: hãy không chạy workload nào trong tài khoản quản lý. SCP không áp cho nó, và nếu tài khoản đó bị xâm nhập thì kẻ tấn công kiểm soát được cả tổ chức. Dùng nó chỉ để quản lý Organizations và thanh toán.

Đáp án

A — Tăng số shard của Kinesis stream bằng lệnh UpdateShardCount.

Vì sao đúng

Đề nêu triệu chứng rõ: hệ thống chậm dần khi tốc độ dữ liệu tăng, và nút thắt nằm ở Kinesis Data Streams.

Và shard là đơn vị thông lượng của Kinesis:

Mỗi shard chịu được:
    GHI VÀO:  1 MB/giây hoặc 1.000 bản ghi/giây
    ĐỌC RA:   2 MB/giây (chia cho mọi consumer standard)
        ↓
Vượt giới hạn → ProvisionedThroughputExceededException
             → producer bị throttle, dữ liệu chậm hoặc mất

Thêm shard là cách duy nhất tăng thông lượng ở chế độ provisioned:

aws kinesis update-shard-count --stream-name luong-du-lieu   --target-shard-count 8 --scaling-type UNIFORM_SCALING

Và UpdateShardCount xử lý việc chia shard tự động:

Trước: 4 shard
Sau:   8 shard
    → Kinesis tự chia mỗi shard thành hai
    → không gián đoạn việc ghi

Kiểm chứng bằng metric trước khi quyết định:

WriteProvisionedThroughputExceeded > 0
    → đang bị throttle ở chiều GHI → thiếu shard

GetRecords.IteratorAgeMilliseconds tăng
    → consumer tụt hậu → có thể do thiếu shard hoặc consumer chậm

Vì sao các phương án khác sai

• **C. Cải thiện hiệu năng bằng cách GIẢM số shard với lệnh MergeShard — đây là phương án gần nhất vì cũng thao tác với shard, nhưng nó làm ngược lại: giảm shard nghĩa là giảm thông lượng, khiến vấn đề nghiêm trọng hơn. MergeShard dùng khi muốn tiết kiệm chi phí lúc tải giảm.
• **B. Thay data stream bằng Amazon Data Firehose — thay đổi bản chất kiến trúc: Firehose không cho phát lại và không hỗ trợ nhiều consumer độc lập. Nếu ứng dụng phân tích cần đọc lại dữ liệu hoặc có nhiều consumer, đổi sang Firehose là mất tính năng.
• **D. Áp dụng Step Scaling cho Kinesis Data Stream — không có cơ chế như vậy: step scaling là chính sách của EC2 Auto Scaling. Kinesis không tích hợp trực tiếp với Auto Scaling. (Muốn tự động co giãn shard thì phải tự viết Lambda, hoặc dùng chế độ on-demand.)

Ghi nhớ

Thông lượng của một shard Kinesis — bảng cần thuộc: | Chiều | Giới hạn | |---|---| | Ghi vào | 1 MB/giây HOẶC 1.000 bản ghi/giây | | Đọc (standard) | 2 MB/giây CHIA cho mọi consumer | | Đọc (enhanced fan-out) | 2 MB/giây RIÊNG mỗi consumer |

Chú ý chiều ghi có HAI giới hạn — chạm bất kỳ cái nào cũng bị throttle. Với bản ghi nhỏ (ví dụ 100 byte), giới hạn 1.000 bản ghi/giây sẽ chạm trước.

Hai chế độ dung lượng của Kinesis Data Streams: | | Provisioned | On-demand | |---|---|---| | Quản lý shard | bạn tự tính và điều chỉnh | AWS tự lo | | Thông lượng tối đa | theo số shard | 200 MB/giây, 200.000 bản ghi/giây | | Chi phí | rẻ hơn khi tải ỔN ĐỊNH | đắt hơn mỗi đơn vị nhưng không phải tính toán | | Phù hợp | tải dự báo được | tải biến động, mới ra mắt |

Chuyển sang on-demand giải quyết triệt để vấn đề của đề:

aws kinesis update-stream-mode --stream-arn <arn>   --stream-mode-details StreamMode=ON_DEMAND

Nó tự mở rộng theo tải — không còn phải theo dõi và điều chỉnh shard. (Đáp án A vẫn đúng theo bộ đề và phù hợp khi muốn kiểm soát chi phí.)

Ba cách điều chỉnh shard ở chế độ provisioned: | Cách | Đặc điểm | |---|---| | UpdateShardCount | đơn giản nhất — khai số shard mục tiêu | | SplitShard | chia một shard cụ thể (khi có hot shard) | | MergeShard | gộp hai shard liền kề (giảm chi phí) |

Giới hạn của UpdateShardCount:

Không quá GẤP ĐÔI hoặc GIẢM MỘT NỬA trong một lần gọi
Tối đa 10 lần thay đổi trong 24 giờ

Muốn tăng gấp bốn thì phải gọi hai lần.

Ba nguyên nhân gây nghẽn Kinesis — chẩn đoán đúng trước khi sửa: | Nguyên nhân | Metric | |---|---| | Thiếu shard cho chiều ghi | WriteProvisionedThroughputExceeded > 0 | | Quá nhiều consumer standard chia băng thông đọc | ReadProvisionedThroughputExceeded > 0 | | HOT SHARD — partition key phân bố kém | một shard bị throttle trong khi các shard khác nhàn rỗi |

Hot shard là nguyên nhân âm thầm hay bị bỏ sót:

Partition key = tên khu vực, và 80% dữ liệu đến từ một khu vực
    → một shard nhận 80% tải
    → thêm shard KHÔNG giúp gì
    → phải sửa PARTITION KEY

Dùng SplitShard cho shard nóng, hoặc đổi partition key sang giá trị phân tán đều hơn.

Và với ba consumer trở lên, enhanced fan-out là giải pháp cho nghẽn đọc:

aws kinesis register-stream-consumer   --stream-arn <arn> --consumer-name consumer-phan-tich

Ba cách tối ưu phía producer: | Cách | Lợi ích | |---|---| | PutRecords theo lô | tới 500 bản ghi mỗi request | | Kinesis Producer Library (KPL) | tự gom và nén bản ghi nhỏ | | Thử lại với backoff | xử lý throttle êm hơn |

KPL đặc biệt hữu ích khi bản ghi nhỏ — nó gộp nhiều bản ghi vào một bản ghi Kinesis, vượt qua giới hạn 1.000 bản ghi/giây.

Ba cấu hình phía consumer Lambda: | Cấu hình | Việc | |---|---| | BatchSize | số bản ghi mỗi lần gọi | | ParallelizationFactor | tới 10 lô song song mỗi shard | | MaximumBatchingWindowInSeconds | cân bằng độ trễ và chi phí |

ParallelizationFactor tăng thông lượng xử lý mà không cần thêm shard — nhưng làm mất thứ tự trong shard, nên chỉ dùng khi ứng dụng không phụ thuộc thứ tự.

Ba metric cần đặt alarm: | Metric | Ý nghĩa | |---|---| | WriteProvisionedThroughputExceeded | thiếu shard ở chiều ghi | | GetRecords.IteratorAgeMilliseconds | consumer tụt hậu — nguy cơ mất dữ liệu | | ReadProvisionedThroughputExceeded | nghẽn ở chiều đọc |

Và một lời khuyên: hãy đo trước khi thêm shard. Nếu vấn đề thực ra nằm ở consumer Lambda chạy chậm chứ không phải ở Kinesis, thêm shard sẽ tốn tiền mà không cải thiện gì — metric IteratorAge cao trong khi WriteProvisionedThroughputExceeded bằng 0 chính là dấu hiệu của tình huống đó.