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

Đáp án

A — Định nghĩa quy tắc cấp phép trên AWS License Manager để theo dõi và kiểm soát việc dùng giấy phép; bật tuỳ chọn "Enforce license limit"; thêm Amazon SNS topic để gửi thông báo.

Vì sao đúng

Đề nêu bốn yêu cầu, và License Manager đáp ứng đủ cả bốn: | Yêu cầu | Cơ chế | |---|---| | Theo dõi 50 giấy phép Windows Server | license configuration | | Giấy phép tính theo TỔNG SỐ vCPU | License Manager hỗ trợ đếm theo vCPU, lõi, socket, hoặc instance | | NGĂN khởi chạy khi hết giấy phép | "Enforce license limit" | | Thông báo khi dùng hết | tích hợp SNS |

Cấu hình:

aws license-manager create-license-configuration   --name "giay-phep-windows-server"   --license-counting-type vCPU   --license-count 50   --license-count-hard-limit

Cờ --license-count-hard-limit là điểm mấu chốt:

CÓ hard limit:
    → vượt số giấy phép → LỆNH KHỞI CHẠY BỊ TỪ CHỐI
    → lập trình viên nhận lỗi ngay, không tạo được instance

KHÔNG có hard limit:
    → vẫn khởi chạy được, chỉ ghi nhận là vi phạm
    → phát hiện sau, khi đã quá muộn

Đề nói rõ "won't be able to launch new instances once the licenses are exhausted" — nên bắt buộc phải bật hard limit.

Và bốn kiểu đếm giấy phép mà License Manager hỗ trợ: | Kiểu | Đếm theo | |---|---| | vCPU | tổng số vCPU ← đề yêu cầu | | Cores | số lõi vật lý | | Sockets | số socket CPU | | Instances | số lượng máy |

Đề nói "licenses are tied to the total CPU count of each virtual machine" — khớp chính xác với kiểu đếm vCPU.

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

• **D. Dùng AWS Resource Access Manager (RAM) để theo dõi và kiểm soát giấy phép — đây là phương án gần nhất về mặt tên nghe giống việc chia sẻ tài nguyên, nhưng RAM là dịch vụ chia sẻ tài nguyên AWS giữa các tài khoản (subnet, Transit Gateway, Route 53 rule). Nó không quản lý giấy phép phần mềm.
• **B. Định nghĩa quy tắc trên AWS Certificate Manager với tuỳ chọn "Enforce certificate limit" — nhầm dịch vụ hoàn toàn: ACM quản lý chứng chỉ SSL/TLS, không phải giấy phép phần mềm. Và tuỳ chọn "Enforce certificate limit" không tồn tại.
• **C. Tải giấy phép lên Systems Manager Fleet Manager để mã hoá và phân phối — sai chức năng: Fleet Manager là giao diện quản lý máy chủ từ xa (xem tệp, xem log, kết nối Remote Desktop). Nó không có cơ chế cấp phát giấy phép nào.

Ghi nhớ

Bốn thành phần của AWS License Manager: | Thành phần | Việc | |---|---| | License configuration | quy tắc: loại đếm, số lượng, có hard limit không | | Associated AMI | gắn cấu hình với AMI cụ thể | | License rules | ràng buộc thêm: loại tenancy, nền tảng | | Dashboard | theo dõi mức sử dụng theo thời gian |

Ba loại tenancy mà License Manager kiểm soát được: | Tenancy | Ý nghĩa | |---|---| | Shared (mặc định) | phần cứng dùng chung | | Dedicated Instance | phần cứng không chia sẻ với khách hàng khác | | Dedicated Host | cả máy chủ vật lý riêng — THẤY ĐƯỢC socket và lõi |

Dedicated Host quan trọng cho giấy phép BYOL: nhiều giấy phép phần mềm (Windows Server, SQL Server, Oracle) tính theo lõi VẬT LÝ, và chỉ Dedicated Host mới cho bạn thấy và kiểm soát số lõi đó.

Ba cách lấy giấy phép Windows trên AWS: | Cách | Đặc điểm | |---|---| | License Included | giá instance đã bao gồm giấy phép — đơn giản nhất | | BYOL trên Dedicated Host | dùng giấy phép sẵn có — rẻ hơn nếu đã mua | | BYOL trên Dedicated Instance | tuỳ loại giấy phép, cần kiểm tra điều khoản |

Tình huống của đề là BYOL: công ty đã mua 50 giấy phép và muốn dùng chúng — đó là lý do cần theo dõi và giới hạn.

Ba lợi ích của License Manager: | Lợi ích | Chi tiết | |---|---| | Tránh vi phạm giấy phép | kiểm toán phần mềm có thể phạt rất nặng | | Tránh mua thừa | thấy mức dùng thật thay vì đoán | | Quản lý tập trung nhiều tài khoản | tích hợp AWS Organizations |

Dòng đầu là lý do kinh doanh thật sự: kiểm toán giấy phép từ nhà cung cấp phần mềm là chuyện xảy ra thường xuyên, và mức phạt cho việc dùng vượt giấy phép thường lớn hơn nhiều so với chi phí mua thêm.

Ba nơi License Manager theo dõi được: | Nơi | Chi tiết | |---|---| | EC2 instance | qua AMI được gắn cấu hình | | Máy chủ tại chỗ | qua Systems Manager inventory | | RDS | một số engine thương mại |

Khả năng theo dõi cả máy tại chỗ là điểm mạnh đáng chú ý — nó cho bức tranh giấy phép toàn bộ tổ chức, không chỉ phần trên đám mây.

Ba cách thiết lập thông báo: | Cách | Chi tiết | |---|---| | SNS topic gắn với license configuration | cảnh báo khi chạm ngưỡng | | EventBridge rule cho sự kiện của License Manager | định tuyến linh hoạt hơn | | CloudWatch dashboard | theo dõi xu hướng dùng |

Và một lời khuyên vận hành: đặt cảnh báo trước khi chạm 100% — ví dụ ở mức 80% và 90%. Nếu chỉ báo lúc hết sạch thì lập trình viên đã bị chặn rồi mới có người biết, và việc mua bổ sung giấy phép thường mất vài ngày làm việc.

Đáp án

B và C.

• B — Bật Babelfish trên Aurora PostgreSQL để ứng dụng tiếp tục dùng truy vấn SQL hiện có
• C — Dùng AWS Schema Conversion Tool (SCT) để chuyển lược đồ và AWS DMS để di chuyển dữ liệu

Vì sao đúng

Đề nêu hai mục tiêu, và mỗi đáp án phục vụ một mục tiêu: | Mục tiêu | Giải pháp | |---|---| | GIẢM THIỂU thay đổi mã ứng dụng | B — Babelfish hiểu T-SQL và giao thức TDS | | Chuyển lược đồ và dữ liệu sang Aurora PostgreSQL | C — SCT cho lược đồ, DMS cho dữ liệu |

B — Babelfish là thứ khiến việc "không sửa mã" khả thi:

Babelfish thêm một endpoint thứ hai cho Aurora PostgreSQL
    → nghe trên cổng 1433 (cổng của SQL Server)
    → hiểu giao thức TDS
    → hiểu cú pháp T-SQL
    ↓
Ứng dụng dùng driver SQL Server, gửi truy vấn T-SQL
    → đổi chuỗi kết nối là chạy
    → KHÔNG viết lại truy vấn

Không có Babelfish thì phải chuyển toàn bộ T-SQL sang PL/pgSQL — công việc lớn và rủi ro cao.

C — và SCT + DMS là cặp công cụ tiêu chuẩn cho di chuyển khác engine: | Công cụ | Chuyển | |---|---| | AWS SCT | lược đồ: bảng, index, view, stored procedure, hàm | | AWS DMS | dữ liệu, kèm CDC để giảm thời gian ngừng |

Vì sao cần cả hai: DMS chuyển được dữ liệu nhưng không chuyển đối tượng lược đồ phức tạp; SCT chuyển lược đồ nhưng không chuyển dữ liệu.

Và SCT có báo cáo đánh giá rất hữu ích trước khi bắt đầu:

SCT quét database nguồn → báo cáo:
    - bao nhiêu % đối tượng chuyển tự động được
    - đối tượng nào cần sửa tay
    - ước lượng công sức

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

• **E. Dùng AWS Glue để chuyển đổi truy vấn SQL của ứng dụng cho tương thích Aurora PostgreSQL — đây là phương án gần nhất về mặt cũng nói tới chuyển đổi, nhưng nó sai vai trò của Glue: Glue là dịch vụ ETL cho DỮ LIỆU (trích xuất, biến đổi, nạp). Nó không chuyển đổi mã SQL của ứng dụng.
• **A. Dùng AWS AppConfig để quản lý cập nhật cấu hình trong lúc di chuyển — là công cụ hữu ích nhưng không giải quyết vấn đề chính: AppConfig quản lý cấu hình ứng dụng và triển khai thay đổi an toàn. Nó không giúp gì cho việc chuyển lược đồ, chuyển dữ liệu, hay tương thích SQL.
• **D. Dùng Kinesis Data Streams để sao chép dữ liệu thời gian thực sang Aurora PostgreSQL — sai công cụ: Kinesis là dịch vụ luồng dữ liệu, không phải công cụ di chuyển database. Nó không có cơ chế đọc thay đổi từ SQL Server hay ghi vào Aurora.

Ghi nhớ

Babelfish — điểm cốt lõi: | Đặc điểm | Chi tiết | |---|---| | Chỉ có trên Aurora PostgreSQL | không có ở RDS PostgreSQL thông thường | | Hai endpoint song song | cổng 5432 (PostgreSQL) và 1433 (TDS) | | Miễn phí | không tính phí thêm | | Mã nguồn mở | dự án Babelfish for PostgreSQL |

Hai endpoint song song là tính năng rất tiện cho việc chuyển đổi dần:

Ứng dụng cũ → cổng 1433 (T-SQL qua Babelfish)
Ứng dụng mới → cổng 5432 (PostgreSQL gốc)
    → CÙNG một database, cùng dữ liệu
    → chuyển từng phần một, không phải làm hết cùng lúc

Giới hạn của Babelfish — phải kiểm thử: | Giới hạn | Chi tiết | |---|---| | Không phủ 100% T-SQL | một số tính năng nâng cao chưa hỗ trợ | | Không hỗ trợ SQL Server Agent, SSIS, SSRS | phải thay bằng công cụ khác | | Hiệu năng có thể khác | kế hoạch thực thi của PostgreSQL khác SQL Server |

Công cụ đánh giá tương thích: Babelfish Compass — quét mã T-SQL và báo trước phần nào không chạy được:

BabelfishCompass.sh bao-cao-danh-gia ma-nguon-tsql.sql

Ba thành phần của AWS DMS: | Thành phần | Việc | |---|---| | Replication instance | máy chạy tiến trình sao chép | | Endpoint | thông tin kết nối nguồn và đích | | Task | định nghĩa di chuyển gì, theo cách nào |

Ba chế độ của DMS task: | Chế độ | Dùng khi | |---|---| | Full load | chấp nhận thời gian ngừng | | Full load + CDC | giảm thiểu thời gian ngừng | | CDC only | dữ liệu đã có ở đích |

Yêu cầu cho CDC từ SQL Server: phải bật MS-CDC hoặc dùng chế độ đọc transaction log, và tài khoản DMS cần quyền phù hợp.

Quy trình di chuyển database đầy đủ:

① SCT đánh giá → biết mức độ phức tạp
② SCT chuyển lược đồ → sửa tay phần không tự động được
③ DMS full load → chuyển dữ liệu hiện có
④ DMS CDC → đồng bộ liên tục
⑤ Kiểm thử ứng dụng trên đích (qua Babelfish)
⑥ Cắt chuyển: dừng ghi, chờ CDC bắt kịp, đổi chuỗi kết nối
⑦ Giữ nguồn chạy vài ngày phòng khi cần quay lui

Bước ⑦ hay bị bỏ qua nhưng rất quan trọng: đừng xoá database cũ ngay sau khi cắt chuyển — vấn đề hiệu năng hoặc lỗi tương thích thường chỉ lộ ra sau vài ngày chạy thật.

Ba lý do chuyển từ SQL Server sang Aurora PostgreSQL: | Lý do | Chi tiết | |---|---| | Chi phí giấy phép | SQL Server Enterprise rất đắt; PostgreSQL mã nguồn mở | | Hiệu năng và mở rộng của Aurora | tới 15 replica, lưu trữ tự mở rộng 128 TB | | Tránh phụ thuộc nhà cung cấp | PostgreSQL chạy được ở bất kỳ đâu |

Và một lưu ý về Babelfish trong chiến lược dài hạn: nó là cầu nối để chuyển đổi, không nên là đích đến vĩnh viễn. Chạy T-SQL qua lớp dịch luôn có chi phí và giới hạn; kế hoạch tốt là dùng Babelfish để lên đám mây nhanh, rồi chuyển dần từng phần sang PostgreSQL gốc qua endpoint 5432.

Đáp án

A — Amazon S3 để lưu tệp log và Amazon Elastic MapReduce (EMR) để xử lý.

Vì sao đúng

Đề cần hai việc: lưu log từ nhiều máy chủ Linux và xử lý chúng để lập báo cáo kiểm toán.

S3 là nơi lưu log đúng đắn: | Đặc điểm | Chi tiết | |---|---| | Độ bền 99,999999999% (11 số 9) | phù hợp dữ liệu kiểm toán | | Dung lượng không giới hạn | log tích tụ không ngừng | | Rẻ | và có lifecycle chuyển sang Glacier | | Truy cập được từ mọi dịch vụ phân tích | EMR, Athena, Redshift Spectrum |

Và EMR xử lý được khối lượng lớn:

EMR chạy Hadoop, Spark, Hive, Presto trên cụm được quản lý
    → đọc THẲNG từ S3 qua EMRFS
    → xử lý song song trên nhiều node
    → mở rộng theo khối lượng dữ liệu

Kiến trúc "tách lưu trữ khỏi tính toán" là mẫu thiết kế quan trọng ở đây:

Dữ liệu ở S3 (bền vững, luôn sẵn có)
    ↕
Cụm EMR dựng lên khi cần, tắt khi xong
    → không trả tiền cho cụm rảnh rỗi
    → dữ liệu không mất khi cụm bị xoá

Với báo cáo kiểm toán chạy định kỳ, dùng transient cluster — cụm tự dựng, chạy xong tự tắt.

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

• **B. S3 Glacier để lưu log và Spot EC2 Instance để xử lý — đây là phương án gần nhất về mặt cũng tiết kiệm chi phí, nhưng nó sai ở lớp lưu trữ: Glacier dành cho lưu trữ dài hạn hiếm khi truy cập, mỗi lần đọc phải restore và chờ vài phút tới vài giờ. Log cần xử lý thường xuyên thì để ở Glacier là sai lớp.
• **C. Một EC2 instance duy nhất cho cả lưu trữ lẫn xử lý — không mở rộng được và mong manh: một máy có giới hạn về dung lượng và năng lực tính toán, và đĩa cục bộ không bền — máy hỏng là mất log kiểm toán.
• **D. Glacier Deep Archive để lưu và AWS ParallelCluster để xử lý — sai cả hai: Deep Archive mất 12–48 giờ để lấy dữ liệu. Và ParallelCluster là công cụ dựng cụm HPC cho tính toán khoa học (mô phỏng, CFD), không phải cho phân tích log.

Ghi nhớ

Các lớp lưu trữ S3 — chọn theo tần suất truy cập: | Lớp | Truy cập | Chi phí lưu | |---|---|---| | Standard | thường xuyên | cao nhất | | Intelligent-Tiering | không đoán được — AWS tự chuyển tầng | tự tối ưu | | Standard-IA | ít, nhưng cần ngay | thấp hơn | | Glacier Instant Retrieval | rất ít, cần ngay | thấp | | Glacier Flexible Retrieval | hiếm, chờ được vài phút | rất thấp | | Glacier Deep Archive | gần như không bao giờ, chờ được 12 giờ | thấp nhất |

Quy tắc: log MỚI ở Standard để xử lý, log CŨ chuyển dần xuống Glacier.

{"Rules": [{
  "Status": "Enabled", "Filter": {"Prefix": "log/"},
  "Transitions": [{"Days": 30,  "StorageClass": "STANDARD_IA"},
                  {"Days": 90,  "StorageClass": "GLACIER"},
                  {"Days": 365, "StorageClass": "DEEP_ARCHIVE"}],
  "Expiration": {"Days": 2555}}]}

Ba cách phân tích dữ liệu trên S3: | Cách | Đặc điểm | Phù hợp | |---|---|---| | Amazon Athena | SQL, không máy chủ, trả tiền theo dữ liệu quét | truy vấn thỉnh thoảng — đơn giản nhất | | Amazon EMR | Hadoop/Spark, xử lý phức tạp | ETL nặng, học máy, quy mô rất lớn ← câu này | | Redshift Spectrum | truy vấn S3 từ Redshift | đã có kho dữ liệu Redshift |

Với báo cáo kiểm toán dạng truy vấn SQL, Athena thường đơn giản và rẻ hơn EMR — không có cụm nào để quản lý, trả tiền theo dữ liệu quét. EMR xứng đáng khi cần xử lý phức tạp vượt quá SQL, hoặc khi khối lượng rất lớn và chạy liên tục.

Ba cách thu thập log từ EC2 lên S3: | Cách | Đặc điểm | |---|---| | CloudWatch Agent → CloudWatch Logs → S3 | tìm kiếm được ngay bằng Logs Insights | | Kinesis Data Firehose | luồng liên tục, tự gom thành tệp trên S3 | | Script tự viết đẩy lên S3 | đơn giản nhưng phải tự lo lỗi và thử lại |

CloudWatch Agent là lựa chọn mặc định tốt: nó xử lý việc xoay vòng tệp, thử lại khi lỗi mạng, và cho phép tìm kiếm log gần thời gian thực trước khi lưu trữ.

Ba tối ưu cho phân tích log ở quy mô lớn: | Tối ưu | Lợi ích | |---|---| | Phân vùng theo ngày | chỉ quét phân vùng cần — giảm mạnh chi phí và thời gian | | Chuyển sang Parquet | giảm 80–90% dữ liệu phải đọc | | Nén dữ liệu | ít I/O, ít chi phí lưu trữ |

Cấu trúc thư mục nên theo quy ước Hive:

s3://kho-log/ung-dung/nam=2026/thang=08/ngay=30/

Nó cho phép Athena và EMR bỏ qua hoàn toàn các phân vùng không liên quan.

Ba loại node trong cụm EMR: | Loại | Việc | Dùng Spot được | |---|---|---| | Primary | điều phối cụm | không nên | | Core | tính toán + lưu trữ HDFS | cẩn trọng | | Task | chỉ tính toán | ✅ rất phù hợp |

Dùng Spot cho task node là cách giảm chi phí EMR hiệu quả nhất — mất task node không mất dữ liệu, công việc chỉ được giao lại.

Và một lời khuyên về tuân thủ: với log phục vụ kiểm toán, hãy cân nhắc bật S3 Object Lock hoặc ít nhất versioning + MFA Delete. Một báo cáo kiểm toán dựa trên log có thể bị xoá hoặc sửa sẽ mất phần lớn giá trị chứng minh.

Đáp án

A và C.

• A — Một EC2 instance đang chạy
• C — EBS volume gắn vào EC2 instance đã DỪNG

Vì sao đúng

A — instance đang chạy tính phí, điều hiển nhiên:

Trạng thái running → tính phí theo giây (tối thiểu 60 giây)
    → giá phụ thuộc loại instance, Region, hệ điều hành

C — và đây là khoản chi phí âm thầm mà nhiều người bỏ sót:

Instance dừng:
    ✓ KHÔNG tính phí compute
    ✗ EBS volume VẪN TÍNH PHÍ ĐẦY ĐỦ
        → theo dung lượng ĐÃ CẤP, không phải dung lượng đã dùng
        → volume 500 GB chỉ chứa 10 GB dữ liệu vẫn trả tiền cho 500 GB

Đây là lý do "dừng instance để tiết kiệm" chỉ tiết kiệm được một phần:

Instance m5.xlarge chạy 24/7:   ~140 USD/tháng
Dừng hoàn toàn cả tháng:        ~0 USD compute
    NHƯNG volume gp3 500 GB:    ~40 USD/tháng — vẫn phải trả

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

• **B. Một EC2 instance On-Demand đã DỪNG — đây là phương án gần nhất và là bẫy chính: instance ở trạng thái stopped KHÔNG tính phí compute. Phần tính tiền là EBS volume gắn vào nó — tức là đáp án C, không phải B.
• **D. Việc dùng một Amazon VPC — VPC hoàn toàn miễn phí: tạo VPC, subnet, route table, Internet Gateway, security group, NACL đều không tính phí. (Nhưng NAT Gateway, VPC endpoint interface, và Transit Gateway thì có phí — xem bên dưới.)
• **E. Public Data Set — miễn phí: AWS lưu trữ nhiều bộ dữ liệu công cộng (dữ liệu khí hậu, bộ gen, ảnh vệ tinh) và không tính phí lưu trữ. Bạn chỉ trả cho tài nguyên tính toán dùng để xử lý chúng.

Ghi nhớ

Bảng chi phí theo trạng thái EC2 — nội dung cốt lõi: | Trạng thái | Compute | EBS volume | Elastic IP | |---|---|---|---| | Running | ✅ | ✅ | miễn phí nếu gắn vào máy đang chạy | | Stopped | ❌ | ✅ VẪN TÍNH | ✅ TÍNH PHÍ | | Terminated | ❌ | tuỳ DeleteOnTermination | ✅ nếu chưa giải phóng |

Hai ô đáng nhớ nhất là EBS và Elastic IP ở dòng stopped — cả hai đều tính tiền cho một máy không chạy.

Những gì MIỄN PHÍ trên AWS: | Tài nguyên | Ghi chú | |---|---| | VPC, subnet, route table | | | Internet Gateway | miễn phí | | Security group, Network ACL | | | VPC gateway endpoint (S3, DynamoDB) | hoàn toàn miễn phí | | Dữ liệu ĐI VÀO AWS | inbound luôn miễn phí | | IAM, Organizations | | | Auto Scaling (bản thân dịch vụ) | trả cho instance nó tạo ra | | Elastic Beanstalk, CloudFormation (bản thân) | trả cho tài nguyên bên dưới |

Những gì TÍNH PHÍ mà hay bị bất ngờ: | Tài nguyên | Chi phí điển hình | |---|---| | NAT Gateway | ~32 USD/tháng + phí mỗi GB — khoản âm thầm phổ biến nhất | | Elastic IP không gắn vào máy đang chạy | ~3,6 USD/tháng mỗi cái | | EBS snapshot | theo dung lượng, tích tụ theo thời gian | | Dữ liệu ĐI RA Internet | ~0,09 USD/GB | | Dữ liệu giữa các AZ | ~0,01 USD/GB mỗi chiều | | VPC interface endpoint | phí giờ mỗi AZ + phí mỗi GB | | Load balancer rảnh rỗi | vẫn tính phí giờ |

Dòng "dữ liệu giữa các AZ" là khoản đáng chú ý cho kiến trúc nhiều tầng: mỗi lần web server ở AZ-a gọi database ở AZ-c là tốn tiền hai chiều. Với lưu lượng lớn, khoản này vượt cả chi phí instance.

Năm cách tối ưu chi phí thường bị bỏ qua: | Cách | Tiết kiệm | |---|---| | Xoá EBS volume mồ côi | volume available vẫn tính tiền mãi | | Giải phóng Elastic IP không dùng | ~43 USD/năm mỗi cái | | Thay NAT Gateway bằng VPC gateway endpoint cho S3/DynamoDB | có thể tiết kiệm hàng trăm USD/tháng | | Dọn snapshot cũ bằng Data Lifecycle Manager | snapshot tích tụ âm thầm | | Dọn phần multipart upload dở dang | không hiện trong danh sách object nhưng vẫn tính tiền |

Lifecycle rule cho phần multipart dở dang — nên có cho mọi bucket:

{"Rules": [{"Status": "Enabled",
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

Ba công cụ theo dõi chi phí: | Công cụ | Việc | |---|---| | AWS Cost Explorer | phân tích chi phí theo dịch vụ, thẻ, tài khoản | | AWS Budgets | cảnh báo khi vượt ngưỡng — nên đặt ngay từ ngày đầu | | AWS Cost Anomaly Detection | học mẫu chi tiêu và báo khi có bất thường | | Trusted Advisor | gợi ý tài nguyên nhàn rỗi |

Cost Anomaly Detection đáng bật: nó phát hiện được những khoản tăng bất thường mà ngân sách cố định bỏ sót — ví dụ một dịch vụ tăng gấp đôi nhưng tổng vẫn dưới ngưỡng.

Và một lời khuyên về việc gắn thẻ: kích hoạt cost allocation tag trong Billing console rồi gắn thẻ nhất quán cho mọi tài nguyên. Không có thẻ thì báo cáo chi phí chỉ cho biết "EC2 tốn bao nhiêu", còn có thẻ thì biết phòng ban nào, dự án nào, môi trường nào tốn bao nhiêu — đó mới là thông tin ra quyết định được.

Đáp án

B — Tạo S3 bucket policy từ chối tải lên nếu request không kèm header s3:x-amz-server-side-encryption: AES256; bật SSE-S3 và dựa vào cơ chế xoay khoá dựng sẵn của SSE-S3.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này đáp ứng cả ba với ít công nhất: | Yêu cầu | Cơ chế | |---|---| | Chặn mọi tệp tải lên KHÔNG mã hoá AES-256 | bucket policy với điều kiện header | | Khoá tự động xoay vòng | SSE-S3 tự xoay, AWS lo hoàn toàn | | ÍT CÔNG VẬN HÀNH NHẤT | không có khoá nào để quản lý |

Bucket policy chặn ngay tại thời điểm ghi:

{"Effect": "Deny",
 "Principal": "*",
 "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::kho-tai-lieu-mat/*",
 "Condition": {"StringNotEquals":
   {"s3:x-amz-server-side-encryption": "AES256"}}}

Vì sao chặn ở tầng chính sách quan trọng hơn phát hiện:

Phát hiện rồi sửa:
    tệp không mã hoá TỒN TẠI một khoảng thời gian
    → có cửa sổ rủi ro
Chặn ở bucket policy:
    tệp không mã hoá KHÔNG BAO GIỜ được ghi vào
    → không có cửa sổ nào

Và điểm quyết định là "LEAST operational overhead":

SSE-S3:  AWS quản lý và xoay khoá hoàn toàn — bạn không làm gì
KMS:     phải tạo khoá, quản lý key policy, và trả phí

Nên bổ sung một chính sách thứ hai chặn request không có header nào:

{"Effect": "Deny", "Principal": "*", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::kho-tai-lieu-mat/*",
 "Condition": {"Null": {"s3:x-amz-server-side-encryption": "true"}}}

Điều kiện StringNotEquals không bắt được request thiếu hẳn header — cần cả hai statement mới kín.

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

• **C. Tạo customer-managed key trong KMS, đặt làm mã hoá mặc định của bucket, XOAY KHOÁ THỦ CÔNG hằng năm — đây là phương án gần nhất và cũng đạt mục tiêu mã hoá, nhưng nó thua ở hai điểm: "xoay thủ công" là công vận hành mà đề muốn tránh (KMS có xoay tự động hằng năm — nếu phương án ghi vậy thì đã hợp lý hơn nhiều). Và cấu hình mã hoá mặc định KHÔNG chặn ai đó tải lên với header khai mã hoá kiểu khác.
• **A. Tạo Service Control Policy (SCP) cho S3 bucket — sai đối tượng áp dụng: SCP gắn vào tài khoản hoặc OU trong AWS Organizations, không gắn vào bucket. Và vế "sửa cơ chế xoay khoá dựng sẵn của SSE-S3 để xoay hằng năm" là không làm được — người dùng không điều chỉnh được lịch xoay của SSE-S3.
• **D. Bucket policy yêu cầu header aws:kms và bật S3 Object Lock chế độ compliance để tự xoay khoá AES256 — sai về mặt khái niệm: Object Lock là cơ chế chống XOÁ, hoàn toàn không liên quan tới xoay khoá. Và đề yêu cầu AES-256 (SSE-S3), còn header này bắt buộc dùng KMS.

Ghi nhớ

Bốn cách mã hoá S3 — bảng cần thuộc: | Cách | Giá trị header | Ai quản lý khoá | Xoay khoá | |---|---|---|---| | SSE-S3 | AES256 | AWS hoàn toàn | tự động, AWS lo | | SSE-KMS | aws:kms | AWS KMS, bạn kiểm soát policy | tự động hằng năm nếu bật | | DSSE-KMS | aws:kms:dsse | KMS, mã hoá hai lớp | tự động | | SSE-C | AES256 + khoá trong header | bạn gửi khoá mỗi request | bạn tự lo |

AES256 = SSE-S3, aws:kms = SSE-KMS — hai giá trị này hay bị nhầm và là chi tiết phân biệt của câu hỏi.

SSE-S3 và SSE-KMS — chọn cái nào: | | SSE-S3 | SSE-KMS | |---|---|---| | Chi phí | miễn phí | phí khoá + phí mỗi request | | Công vận hành | gần như bằng 0 | phải quản lý khoá và policy | | Audit ai giải mã | ❌ | ✅ CloudTrail ghi mọi lời gọi Decrypt | | Kiểm soát chính sách khoá | ❌ | ✅ | | Giới hạn tốc độ | không | có hạn mức request KMS |

Đề hỏi "LEAST operational overhead" nên SSE-S3 thắng. Nhưng với ngân hàng đa quốc gia trong thực tế, SSE-KMS thường là lựa chọn đúng vì kiểm toán viên muốn biết ai đã giải mã dữ liệu nào, lúc nào — thứ mà SSE-S3 không cung cấp.

Từ tháng 1/2023, S3 mã hoá SSE-S3 MẶC ĐỊNH cho mọi object mới. Nhưng bucket policy tường minh vẫn cần thiết vì:

Mã hoá mặc định áp khi request KHÔNG khai gì
    → nhưng ai đó VẪN khai được kiểu mã hoá khác
    → hoặc cấu hình mặc định bị đổi
→ bucket policy là ràng buộc CỨNG, không phụ thuộc cấu hình

Ba tầng bảo vệ nên có cho bucket dữ liệu nhạy cảm: | Tầng | Cơ chế | |---|---| | Bắt buộc mã hoá at rest | bucket policy chặn PutObject không mã hoá | | Bắt buộc HTTPS | điều kiện aws:SecureTransport | | Chặn truy cập công khai | Block Public Access ở mức tài khoản |

Chính sách bắt buộc HTTPS:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::kho-tai-lieu-mat",
              "arn:aws:s3:::kho-tai-lieu-mat/*"],
 "Condition": {"Bool": {"aws:SecureTransport": "false"}}}

Lưu ý phải liệt kê CẢ bucket lẫn object ARN — thiếu một cái là chính sách hở.

Ba công cụ kiểm tra tuân thủ mã hoá: | Công cụ | Việc | |---|---| | AWS Config rule s3-bucket-server-side-encryption-enabled | phát hiện bucket chưa bật mã hoá | | S3 Inventory | liệt kê mọi object kèm trạng thái mã hoá — dùng để rà soát tệp cũ | | Amazon Macie | phát hiện dữ liệu nhạy cảm (PII, thẻ tín dụng) trong bucket |

S3 Inventory là công cụ đúng cho phần "kiểm toán phát hiện nhiều tệp chưa mã hoá" mà đề mô tả — nó xuất báo cáo hằng ngày hoặc hằng tuần cho biết chính xác object nào chưa được mã hoá:

aws s3api put-bucket-inventory-configuration --bucket kho-tai-lieu-mat   --id kiem-tra-ma-hoa --inventory-configuration file://cau-hinh.json

Và để mã hoá các tệp đã tồn tại, dùng S3 Batch Operations với thao tác copy — nó ghi đè object bằng phiên bản đã mã hoá mà không cần tải về máy.

Và một lưu ý cho ngân hàng: mã hoá at rest là điều kiện cần nhưng không đủ cho tuân thủ. Còn cần audit trail đầy đủ (CloudTrail data event cho S3), kiểm soát truy cập tối thiểu, và với nhiều quy định là bằng chứng về vị trí lưu trữ dữ liệu — hãy kiểm tra Region của bucket khớp với yêu cầu pháp lý của từng thị trường.

Đáp án

A — Cho phép mọi lời gọi AWS Directory Service (ds) miễn là tài nguyên chứa directory ID d-1234567890.

Vì sao đúng

Câu hỏi kiểm tra khả năng đọc đúng cấu trúc một IAM policy — cụ thể là phân biệt các trường trong đó.

Phân tích statement thứ nhất:

{
  "Sid": "DirectoryTutorialsDojo1234",         ← chỉ là NHÃN, không có ý nghĩa chức năng
  "Effect": "Allow",                            ← cho phép
  "Action": ["ds:*"],                           ← MỌI hành động của Directory Service
  "Resource": "arn:aws:ds:us-east-1:987654321012:directory/d-1234567890"
}

Bóc tách ARN ở trường Resource — đây là phần quyết định:

arn:aws:ds:us-east-1:987654321012:directory/d-1234567890
 │   │   │      │           │          │          │
 │   │   │      │           │          │          └─ ID TÀI NGUYÊN ← thứ policy giới hạn
 │   │   │      │           │          └─ loại tài nguyên
 │   │   │      │           └─ ID TÀI KHOẢN AWS (987654321012)
 │   │   │      └─ Region
 │   │   └─ dịch vụ (Directory Service)
 │   └─ partition
 └─ tiền tố cố định

Nên ds:* được cho phép, nhưng CHỈ trên đúng thư mục d-1234567890.

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

• **B. Cho phép ds miễn là tài nguyên chứa directory ID DirectoryTutorialsDojo1234 — đây là phương án gần nhất và là bẫy chính: DirectoryTutorialsDojo1234 là giá trị của trường Sid, tức là Statement ID — một cái nhãn để con người đọc và để tham chiếu khi sửa policy. Nó không phải directory ID và không ảnh hưởng gì tới việc cấp quyền.
• **C. ...directory ID là 987654321012 — sai loại định danh: đó là ID TÀI KHOẢN AWS, nằm ở phân đoạn thứ năm của ARN. Directory ID luôn bắt đầu bằng tiền tố d-.
• **D. ...tên thư mục là DirectoryTutorialsDojo1234 — sai kép: Sid không phải tên thư mục, và policy giới hạn theo ID trong ARN, không theo tên.

Ghi nhớ

Cấu trúc một IAM policy statement — các trường và vai trò: | Trường | Bắt buộc | Vai trò | |---|---|---| | Sid | không | NHÃN cho người đọc — KHÔNG ảnh hưởng quyền | | Effect | có | Allow hoặc Deny | | Action | có | hành động được phép hoặc bị cấm | | Resource | có (với identity policy) | tài nguyên nào bị áp dụng | | Principal | chỉ resource-based policy | ai được áp dụng | | Condition | không | điều kiện bổ sung |

Sid chỉ là chú thích — đó là điều câu hỏi này kiểm tra.

Cấu trúc ARN chuẩn:

arn:partition:service:region:account-id:resource-type/resource-id

Hai ngoại lệ đáng nhớ:

arn:aws:s3:::ten-bucket/duong-dan     ← S3 KHÔNG có region và account
arn:aws:iam::123456789012:user/nam    ← IAM KHÔNG có region (toàn cầu)

Tiền tố ID của các tài nguyên hay gặp: | Tiền tố | Tài nguyên | |---|---| | d- | Directory Service | | i- | EC2 instance | | vpc- | VPC | | subnet- | subnet | | sg- | security group | | ami- | AMI | | vol- | EBS volume | | snap- | snapshot | | rtb- | route table | | igw- / nat- | Internet Gateway / NAT Gateway | | vpce- | VPC endpoint | | tgw- | Transit Gateway |

Ba nhận xét về chính bản policy trong đề: | Nhận xét | Chi tiết | |---|---| | ds:* là quyền RỘNG | mọi thao tác kể cả xoá thư mục — nên thu hẹp theo nhu cầu thật | | Statement thứ hai ec2:* trên * còn rộng hơn nhiều | đó là quyền quản trị EC2 toàn tài khoản | | Không có Condition nào | không giới hạn theo IP, MFA, hay thẻ |

Statement thứ hai đáng lưu ý về mặt bảo mật: AD Connector có cần một số quyền EC2 (tạo ENI, mô tả subnet), nhưng ec2:* trên * là rộng hơn rất nhiều so với mức cần thiết — người có policy này khởi chạy, dừng, xoá được mọi instance trong tài khoản.

Bộ quyền EC2 tối thiểu cho AD Connector:

{"Effect": "Allow",
 "Action": ["ec2:CreateNetworkInterface", "ec2:DeleteNetworkInterface",
            "ec2:DescribeNetworkInterfaces", "ec2:DescribeSubnets",
            "ec2:DescribeVpcs", "ec2:DescribeSecurityGroups"],
 "Resource": "*"}

Ba loại thư mục trong AWS Directory Service: | Loại | Đặc điểm | |---|---| | AWS Managed Microsoft AD | Active Directory thật, chạy trên AWS | | AD Connector | CẦU NỐI tới AD tại chỗ — không lưu dữ liệu nào ← đề dùng cái này | | Simple AD | tương thích Samba, cho nhu cầu cơ bản |

AD Connector không sao chép dữ liệu người dùng lên AWS — nó chuyển tiếp yêu cầu xác thực về máy chủ AD tại chỗ. Đó là ưu điểm về mặt tuân thủ, nhưng cũng nghĩa là AD tại chỗ mất kết nối thì xác thực dừng hoạt động.

Và một công cụ hữu ích để kiểm chứng policy trước khi áp dụng: IAM Policy Simulator cho phép thử một hành động cụ thể trên một tài nguyên cụ thể và xem kết quả cùng lý do — nhanh hơn nhiều so với gán policy rồi thử trong thực tế.

Đáp án

C và D.

• C — Cho phép mô hình hoá, cấp phát và quản lý phiên bản toàn bộ hạ tầng AWS
• D — Cho phép mô tả toàn bộ hạ tầng trong một tệp văn bản

Vì sao đúng

Đề mô tả tình huống người quản lý không hiểu vì sao kỹ sư viết script YAML thay vì bấm nút tạo tài nguyên — và hai đáp án này là câu trả lời.

D — hạ tầng dưới dạng mã (Infrastructure as Code):

Thay vì bấm 200 lần trong Console:
    một tệp YAML mô tả TOÀN BỘ hệ thống
        → VPC, subnet, EC2, S3, RDS, IAM role, security group
        → dựng lại y hệt bằng một lệnh

C — và điều đó mở ra ba khả năng mà thao tác tay không có: | Khả năng | Ý nghĩa | |---|---| | Mô hình hoá (modeling) | mô tả trạng thái mong muốn, CloudFormation lo cách đạt tới | | Cấp phát (provisioning) | dựng đúng như nhau ở dev, staging, production | | Quản lý phiên bản (version control) | template nằm trong Git — biết ai đổi gì, lúc nào, và quay lui được |

Vế "version-controlling" là lợi ích lớn nhất mà người quản lý cần hiểu:

Thao tác tay trong Console:
    ✗ không có lịch sử ai đổi gì
    ✗ không quay lui được
    ✗ không review được trước khi áp dụng
    ✗ môi trường dev và prod trôi dạt khỏi nhau

CloudFormation + Git:
    ✓ mọi thay đổi qua pull request, có người review
    ✓ lịch sử đầy đủ
    ✓ quay lui bằng cách triển khai commit cũ
    ✓ các môi trường giống hệt nhau

Và với sàn giao dịch tiền mã hoá — hệ thống tài chính chịu quy định — khả năng chứng minh "hạ tầng được cấu hình đúng như đã phê duyệt" là yêu cầu kiểm toán thực sự.

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

• **E. Bản thân CloudFormation miễn phí, KỂ CẢ các tài nguyên AWS được tạo ra — đây là phương án gần nhất và nửa đầu đúng, nhưng nửa sau hoàn toàn sai: CloudFormation không tính phí, nhưng bạn vẫn trả tiền đầy đủ cho mọi tài nguyên nó tạo — EC2, RDS, S3 đều tính phí như bình thường.
• **A. Cung cấp kho lưu trữ dữ liệu bền và mở rộng được — nhầm dịch vụ: đó là mô tả của Amazon S3. CloudFormation không lưu trữ dữ liệu.
• **B. Là nơi lưu mã nguồn ứng dụng — nhầm dịch vụ: đó là AWS CodeCommit hoặc GitHub. CloudFormation lưu định nghĩa hạ tầng, không lưu mã ứng dụng.

Ghi nhớ

Sáu lợi ích của Infrastructure as Code: | Lợi ích | Chi tiết | |---|---| | Lặp lại được | dựng môi trường giống hệt nhau mọi lúc | | Quản lý phiên bản | Git — lịch sử, review, quay lui | | Tự động hoá | tích hợp vào CI/CD | | Tài liệu sống | template CHÍNH LÀ tài liệu, không bao giờ lỗi thời | | Xoá sạch dễ dàng | xoá stack là gỡ hết tài nguyên | | Phát hiện trôi dạt (drift detection) | biết ai sửa tay ngoài template |

Dòng "tài liệu sống" đáng nhấn mạnh: tài liệu kiến trúc viết tay luôn lạc hậu so với thực tế; template thì là thực tế.

Các thành phần của một CloudFormation template: | Phần | Việc | |---|---| | Resources | BẮT BUỘC — tài nguyên cần tạo | | Parameters | đầu vào cho phép tái dùng template | | Outputs | giá trị xuất ra — dùng chéo giữa các stack | | Mappings | bảng tra (ví dụ AMI ID theo Region) | | Conditions | tạo tài nguyên có điều kiện | | Metadata, Transform | cấu hình bổ sung |

Chỉ Resources là bắt buộc — các phần khác đều tuỳ chọn.

Ba khái niệm quan trọng: | Khái niệm | Việc | |---|---| | Stack | tập hợp tài nguyên được quản lý cùng nhau | | Change set | XEM TRƯỚC thay đổi sẽ xảy ra trước khi áp dụng | | StackSet | triển khai cùng template ra NHIỀU tài khoản và Region | | Drift detection | phát hiện tài nguyên bị sửa tay ngoài template |

Change set là thực hành bắt buộc cho môi trường sản xuất:

aws cloudformation create-change-set --stack-name san-giao-dich   --template-body file://ha-tang.yaml --change-set-name thay-doi-thang-8
aws cloudformation describe-change-set --change-set-name thay-doi-thang-8   --stack-name san-giao-dich

Nó cho biết tài nguyên nào sẽ bị THAY THẾ — điều rất quan trọng vì thay thế một RDS instance nghĩa là mất dữ liệu nếu không cẩn thận.

Ba thuộc tính bảo vệ tài nguyên quan trọng: | Thuộc tính | Việc | |---|---| | DeletionPolicy: Retain | giữ tài nguyên khi xoá stack | | DeletionPolicy: Snapshot | chụp snapshot trước khi xoá (RDS, EBS) | | UpdateReplacePolicy | làm gì với tài nguyên cũ khi bị thay thế | | Stack termination protection | ngăn xoá stack vô ý |

Với database của sàn giao dịch, DeletionPolicy: Retain hoặc Snapshot là bắt buộc — một lệnh xoá stack nhầm không được phép làm mất dữ liệu giao dịch.

Các công cụ IaC trên AWS: | Công cụ | Đặc điểm | |---|---| | CloudFormation | gốc của AWS, YAML/JSON, miễn phí | | AWS CDK | viết bằng TypeScript, Python, Java — sinh ra CloudFormation | | AWS SAM | phần mở rộng cho ứng dụng serverless | | Terraform | đa nhà cung cấp đám mây, của HashiCorp |

AWS CDK đáng cân nhắc cho đội ngũ đông lập trình viên: viết hạ tầng bằng ngôn ngữ lập trình quen thuộc, có kiểm tra kiểu, có vòng lặp và hàm — tránh được sự lặp lại dài dòng của YAML thuần.

Và một lời khuyên khi bắt đầu như tình huống của đề: chia hạ tầng thành nhiều stack theo vòng đời, đừng dồn tất cả vào một template khổng lồ. Mạng và IAM ít thay đổi nên tách riêng; ứng dụng thay đổi thường xuyên nên ở stack riêng. Dùng Outputs và Fn::ImportValue để liên kết chúng — như vậy triển khai ứng dụng không bao giờ có nguy cơ đụng tới VPC.

Đáp án

A — Xem CloudWatch Logs hiện có để tìm từ khoá liên quan tới lỗi và tạo custom metric; sau đó tạo CloudWatch alarm cho metric đó với hành động khởi động lại EC2 instance.

Vì sao đúng

Đề nêu ba yêu cầu, và luồng này khớp chính xác: | Yêu cầu | Cơ chế | |---|---| | Log ứng dụng đã được gửi tới CloudWatch | dùng CloudWatch Logs làm nguồn | | Phát hiện lỗi cụ thể trong log | metric filter tìm từ khoá → custom metric | | Tự động khởi động lại instance | CloudWatch alarm với EC2 action |

Luồng đầy đủ:

① Metric filter quét log tìm mẫu
       ↓
② Mỗi lần khớp → tăng CUSTOM METRIC
       ↓
③ Alarm theo dõi metric đó
       ↓
④ Vượt ngưỡng → EC2 action: reboot

Tạo metric filter:

aws logs put-metric-filter   --log-group-name /ung-dung/web   --filter-name loi-can-khoi-dong-lai   --filter-pattern '"OutOfMemoryError"'   --metric-transformations       metricName=SoLoiHetBoNho,metricNamespace=UngDung,metricValue=1

Tạo alarm với hành động khởi động lại:

aws cloudwatch put-metric-alarm --alarm-name khoi-dong-lai-khi-loi   --metric-name SoLoiHetBoNho --namespace UngDung   --statistic Sum --period 300 --threshold 3   --comparison-operator GreaterThanOrEqualToThreshold   --evaluation-periods 1   --alarm-actions arn:aws:automate:ap-southeast-1:ec2:reboot   --dimensions Name=InstanceId,Value=i-0abc123

ARN arn:aws:automate:<region>:ec2:reboot là hành động EC2 dựng sẵn của CloudWatch alarm — không cần Lambda, không cần mã.

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

• **C. Xem Flow Logs để tìm từ khoá lỗi ứng dụng — đây là phương án gần nhất về mặt cấu trúc giải pháp, nhưng nó sai nguồn dữ liệu: VPC Flow Logs chỉ ghi METADATA về lưu lượng mạng — IP nguồn, IP đích, cổng, giao thức, số byte, ACCEPT/REJECT. Nó không chứa log ứng dụng và không bao giờ có từ khoá lỗi của ứng dụng.
• **D. Dùng Flow Logs rồi tạo alarm gọi Lambda để khởi động lại — cùng lỗi về nguồn dữ liệu, và thêm một lớp Lambda không cần thiết khi CloudWatch đã có EC2 action dựng sẵn.
• **B. Tạo alarm trong Amazon SNS cho custom metric — sai dịch vụ: SNS là dịch vụ GỬI THÔNG BÁO, nó không tạo hay đánh giá alarm. Alarm thuộc về CloudWatch; SNS chỉ là một trong các đích nhận thông báo khi alarm kích hoạt.

Ghi nhớ

Bốn hành động dựng sẵn của CloudWatch alarm cho EC2: | Hành động | ARN | |---|---| | Reboot | arn:aws:automate:<region>:ec2:reboot | | Stop | arn:aws:automate:<region>:ec2:stop | | Terminate | arn:aws:automate:<region>:ec2:terminate | | Recover | arn:aws:automate:<region>:ec2:recover |

recover khác reboot và đáng biết: nó di chuyển instance sang máy chủ vật lý khác khi phần cứng nền có vấn đề, giữ nguyên instance ID, IP riêng, Elastic IP và metadata. Dùng cho lỗi phần cứng, không dùng cho lỗi ứng dụng.

Ba nguồn log khác nhau — đừng nhầm: | Nguồn | Nội dung | |---|---| | CloudWatch Logs | log ỨNG DỤNG và hệ thống — gửi bởi CloudWatch Agent | | VPC Flow Logs | METADATA lưu lượng mạng — không có nội dung gói tin | | CloudTrail | lời gọi API tới AWS — ai làm gì với tài nguyên nào |

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

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

Cú pháp mẫu lọc của metric filter: | Mẫu | Khớp với | |---|---| | "ERROR" | dòng chứa chuỗi ERROR | | ?ERROR ?FATAL | chứa ERROR HOẶC FATAL | | "ERROR" - "TestError" | chứa ERROR nhưng KHÔNG chứa TestError | | { $.level = "ERROR" } | log JSON có trường level bằng ERROR | | [ip, user, ts, request, status_code=5*] | log dạng cột, mã trạng thái 5xx |

Với log dạng JSON có cấu trúc, mẫu { $.field = value } chính xác hơn nhiều so với khớp chuỗi — nó không bị nhầm khi từ khoá xuất hiện trong nội dung khác.

Ba trạng thái của CloudWatch alarm: | Trạng thái | Ý nghĩa | |---|---| | OK | trong ngưỡng | | ALARM | vượt ngưỡng | | INSUFFICIENT_DATA | không đủ dữ liệu để đánh giá |

treatMissingData là cấu hình quan trọng khi metric chỉ xuất hiện lúc có lỗi:

notBreaching  → không có dữ liệu = OK   ← thường đúng cho metric đếm lỗi
breaching     → không có dữ liệu = ALARM
ignore        → giữ trạng thái cũ
missing       → mặc định

Với metric filter đếm lỗi, đặt notBreaching — vì không có lỗi nghĩa là không có dòng log nào khớp, và đó là tình huống tốt chứ không phải thiếu dữ liệu.

Và một cảnh báo về việc tự động khởi động lại:

Khởi động lại chữa TRIỆU CHỨNG, không chữa NGUYÊN NHÂN
    → nếu lỗi do rò rỉ bộ nhớ, máy sẽ khởi động lại mãi
    → mỗi lần khởi động lại là một khoảng gián đoạn dịch vụ

Nên kèm theo: | Biện pháp | Lý do | |---|---| | Gửi thông báo SNS song song với việc khởi động lại | để có người biết và điều tra | | Đếm số lần khởi động lại | tần suất tăng là dấu hiệu vấn đề đang xấu đi | | Đặt ngưỡng đủ cao | tránh khởi động lại vì một lỗi đơn lẻ |

Alarm hỗ trợ nhiều hành động cùng lúc — hãy thêm cả ARN của SNS topic vào --alarm-actions bên cạnh hành động reboot.

Và một giải pháp mang tính kiến trúc hơn cho tình huống này: đặt các instance trong Auto Scaling group với health check kiểu ELB. Khi ứng dụng ngừng phản hồi, ASG thay bằng instance MỚI thay vì khởi động lại máy cũ — sạch hơn, và tránh được việc một máy hỏng dần vẫn tiếp tục phục vụ giữa các lần khởi động lại.

Đáp án

D — Amazon Athena, Amazon Redshift Spectrum và AWS Glue.

Vì sao đúng

Đề nêu yêu cầu quyết định: chạy phân tích dữ liệu lớn TRÊN CHÍNH dữ liệu, không phải chuyển sang hệ thống phân tích riêng — và ba dịch vụ này đều truy vấn trực tiếp S3.

Vai trò của từng dịch vụ trong bộ ba: | Dịch vụ | Việc | |---|---| | AWS Glue | Data Catalog — phát hiện lược đồ, làm kho metadata dùng chung | | Amazon Athena | truy vấn SQL THẲNG trên S3, không cần máy chủ | | Redshift Spectrum | truy vấn S3 từ Redshift, kết hợp với dữ liệu trong kho |

Và chúng phối hợp với nhau:

Glue Crawler quét S3
    → phát hiện lược đồ của tệp JSON
    → ghi vào Glue Data Catalog
         ↓
Athena và Redshift Spectrum ĐỀU đọc catalog đó
    → khai báo bảng MỘT LẦN, dùng được ở cả hai

Mẫu kiến trúc "query in place" — đây là điểm chính của câu hỏi:

KIỂU CŨ:
    Dữ liệu ở S3 → ETL → nạp vào kho dữ liệu → mới truy vấn được
        → tốn thời gian, tốn tiền, có hai bản sao dữ liệu

QUERY IN PLACE:
    Dữ liệu ở S3 → truy vấn TRỰC TIẾP
        → không di chuyển, không nhân bản
        → đúng như đề yêu cầu

Với kiến trúc của đề — Lambda ghi JSON vào S3 — Athena chạy được ngay:

CREATE EXTERNAL TABLE ket_qua_phan_tich (
  thoi_gian string, ma_thiet_bi string, gia_tri double
) ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://kho-ket-qua/du-lieu/';

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

• **C. AWS Glue, Amazon Redshift, Amazon S3 — đây là phương án gần nhất và có hai phần ba đúng (Glue và S3), nhưng Redshift thường (không phải Spectrum) đòi NẠP dữ liệu VÀO kho trước khi truy vấn. Đó chính là việc "moving them into a separate analytics system" mà đề nói phải tránh.
• **A. Amazon Neptune, DynamoDB DAX, Redshift Spectrum — hai phần ba sai: Neptune là cơ sở dữ liệu đồ thị, DAX là cache cho DynamoDB. Cả hai đều không truy vấn dữ liệu trên S3.
• **B. Amazon X-Ray, Amazon Neptune, DynamoDB — cả ba đều sai: X-Ray là công cụ theo dõi phân tán để gỡ lỗi ứng dụng, Neptune là database đồ thị, DynamoDB là kho khoá–giá trị. Không cái nào là công cụ phân tích dữ liệu lớn trên S3.

Ghi nhớ

Ba công cụ truy vấn trực tiếp trên S3: | Công cụ | Đặc điểm | Phù hợp | |---|---|---| | Amazon Athena | SQL, KHÔNG máy chủ, trả tiền theo dữ liệu quét | truy vấn thỉnh thoảng, khám phá dữ liệu | | Redshift Spectrum | truy vấn S3 TỪ cụm Redshift | kết hợp dữ liệu nóng trong kho với dữ liệu lạnh ở S3 | | EMR (Spark, Presto) | cụm Hadoop | xử lý phức tạp, ETL nặng |

Athena và Redshift Spectrum — chọn cái nào: | | Athena | Redshift Spectrum | |---|---|---| | Cần cụm Redshift | ❌ | ✅ bắt buộc | | Tính phí | theo dữ liệu quét (~5 USD/TB) | theo dữ liệu quét + chi phí cụm | | Kết hợp với bảng trong kho | ❌ | ✅ — điểm mạnh chính | | Khởi động | tức thì | cụm phải đang chạy |

Redshift Spectrum xứng đáng khi ĐÃ CÓ Redshift và muốn truy vấn dữ liệu lịch sử ở S3 mà không nạp vào kho. Nếu chưa có cụm nào, Athena đơn giản và rẻ hơn nhiều.

Bốn thành phần của AWS Glue: | Thành phần | Việc | |---|---| | Data Catalog | kho metadata DÙNG CHUNG cho Athena, Redshift Spectrum, EMR | | Crawler | tự phát hiện lược đồ và phân vùng | | ETL job | biến đổi dữ liệu bằng Spark hoặc Python | | Glue Studio | giao diện kéo thả dựng ETL job |

Data Catalog là thứ gắn kết cả hệ sinh thái: khai báo bảng một lần, mọi công cụ phân tích đều thấy.

Ba tối ưu quan trọng cho Athena — ảnh hưởng trực tiếp tới chi phí: | Tối ưu | Mức giảm dữ liệu quét | |---|---| | Phân vùng theo ngày/tháng | rất lớn — chỉ đọc phân vùng cần | | Chuyển sang Parquet hoặc ORC | 80–90% | | Nén dữ liệu | đáng kể | | Chọn cột cụ thể thay vì SELECT * | với định dạng cột, chỉ đọc cột được chọn |

Athena tính phí theo DỮ LIỆU QUÉT, nên bốn tối ưu trên giảm hoá đơn trực tiếp:

100 GB JSON, SELECT * → quét 100 GB → ~0,50 USD
Cùng dữ liệu ở Parquet, phân vùng, chọn 3 cột → quét 2 GB → ~0,01 USD

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

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

ALTER TABLE ket_qua_phan_tich ADD PARTITION (nam='2026', thang='08', ngay='30')
  LOCATION 's3://kho-ket-qua/du-lieu/nam=2026/thang=08/ngay=30/';
-- hoặc để Glue Crawler tự phát hiện

Ba lưu ý khi dùng Athena: | Lưu ý | Chi tiết | |---|---| | Kết quả truy vấn lưu vào S3 | đặt lifecycle rule dọn thư mục kết quả | | Nhiều tệp NHỎ làm chậm truy vấn | gộp thành tệp 128 MB – 1 GB | | Có hạn mức truy vấn đồng thời | tăng được nếu cần |

Dòng giữa rất quan trọng với kiến trúc trong đề: Lambda ghi mỗi kết quả thành một tệp JSON nhỏ sẽ tạo ra hàng triệu tệp tí hon — Athena phải mở từng tệp và hiệu năng sụp đổ. Giải pháp là Kinesis Data Firehose gom lại thành tệp lớn trước khi ghi vào S3, hoặc một Glue job định kỳ gộp và chuyển sang Parquet.

Và một lưu ý về kiến trúc tổng thể: nếu dữ liệu đến liên tục từ Lambda như đề mô tả, hãy cân nhắc đưa Firehose vào giữa — nó gom bản ghi theo thời gian hoặc kích thước, chuyển đổi sang Parquet ngay trên đường đi, và phân vùng tự động theo thời gian. Ba việc mà nếu không có nó thì phải tự làm bằng job dọn dẹp về sau.

Đáp án

C — Dùng lệnh curl hoặc GET để lấy thông tin metadata mới nhất từ http://169.254.169.254/latest/meta-data/.

Vì sao đúng

Đề cần lấy IP công khai và IP riêng của chính instance từ trong một shell script — và Instance Metadata Service (IMDS) là cơ chế dành cho đúng việc đó.

Địa chỉ 169.254.169.254 là địa chỉ link-local đặc biệt:

Chỉ truy cập được TỪ BÊN TRONG instance
    → không định tuyến ra ngoài
    → không cần thông tin đăng nhập
    → không cần quyền IAM
    → trả về thông tin về CHÍNH instance đang gọi

Lấy hai địa chỉ IP:

# IMDSv2 — lấy token trước (khuyến nghị)
TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token"   -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

IP_RIENG=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN"   http://169.254.169.254/latest/meta-data/local-ipv4)
IP_CONG_KHAI=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN"   http://169.254.169.254/latest/meta-data/public-ipv4)

echo "Riêng: $IP_RIENG | Công khai: $IP_CONG_KHAI"

Vì sao không dùng cách khác được: IP công khai không xuất hiện trong cấu hình mạng của hệ điều hành — ip addr chỉ thấy IP riêng, vì NAT do hạ tầng AWS thực hiện. IMDS là cách duy nhất biết được IP công khai từ bên trong máy.

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

• **D. Lấy user-data từ http://169.254.169.254/latest/user-data/ — đây là phương án gần nhất và đúng địa chỉ IMDS, nhưng nó sai nhánh: user-data trả về script khởi tạo mà BẠN cung cấp lúc khởi chạy instance. Nó không chứa thông tin về IP.
• **A. Dùng IAM — sai vai trò dịch vụ: IAM quản lý danh tính và quyền. Nó không cung cấp thông tin cấu hình của instance.
• **B. Dùng CloudWatch metric — không có metric nào chứa địa chỉ IP: CloudWatch thu thập số liệu về hiệu năng (CPU, mạng, đĩa). Địa chỉ IP là thuộc tính cấu hình, không phải số đo.

Ghi nhớ

Hai nhánh chính của IMDS: | Nhánh | Nội dung | |---|---| | /latest/meta-data/ | thông tin về instance do AWS cung cấp | | /latest/user-data/ | script hoặc dữ liệu BẠN khai lúc khởi chạy | | /latest/dynamic/ | tài liệu nhận dạng instance, có chữ ký |

Các đường dẫn metadata hay dùng: | Đường dẫn | Trả về | |---|---| | local-ipv4 | IP riêng | | public-ipv4 | IP công khai | | instance-id | ID instance | | instance-type | loại instance | | placement/availability-zone | AZ | | placement/region | Region | | security-groups | tên các security group | | iam/security-credentials/<role> | thông tin đăng nhập tạm thời của IAM role | | spot/instance-action | cảnh báo Spot sắp bị thu hồi | | mac, network/interfaces/ | thông tin mạng chi tiết |

Đường dẫn iam/security-credentials/ là cơ chế nền tảng của IAM role trên EC2:

SDK và CLI tự gọi đường dẫn này
    → nhận access key tạm thời
    → tự làm mới trước khi hết hạn
→ đó là lý do KHÔNG BAO GIỜ cần nhúng access key vào mã trên EC2

Và spot/instance-action là cách nhận cảnh báo thu hồi Spot:

# Trả về 404 khi bình thường, 200 kèm thời điểm khi sắp bị thu hồi
curl -s -o /dev/null -w "%{http_code}" -H "X-aws-ec2-metadata-token: $TOKEN"   http://169.254.169.254/latest/meta-data/spot/instance-action

IMDSv1 và IMDSv2 — khác biệt quan trọng về bảo mật: | | IMDSv1 | IMDSv2 | |---|---|---| | Cách gọi | GET đơn giản | PUT lấy token trước, rồi GET kèm token | | Chống SSRF | ❌ dễ bị khai thác | ✅ | | Giới hạn hop mạng | không | mặc định 1 — chặn container truy cập |

Vì sao IMDSv2 quan trọng:

Lỗ hổng SSRF trong ứng dụng web
    → kẻ tấn công ép máy chủ gọi http://169.254.169.254/...
    → với IMDSv1: LẤY ĐƯỢC thông tin đăng nhập của IAM role
    → đây là nguyên nhân của nhiều vụ rò rỉ dữ liệu lớn

Với IMDSv2:
    → cần PUT để lấy token trước
    → SSRF thông thường chỉ tạo được GET
    → và header X-Forwarded-For khiến request bị từ chối

Nên BẮT BUỘC IMDSv2 cho mọi instance:

aws ec2 modify-instance-metadata-options --instance-id i-0abc123   --http-tokens required --http-put-response-hop-limit 1

Và đặt trong launch template để áp cho instance mới:

{"MetadataOptions": {"HttpTokens": "required",
                     "HttpPutResponseHopLimit": 1,
                     "HttpEndpoint": "enabled"}}

Ba lưu ý về IMDS: | Lưu ý | Chi tiết | |---|---| | Chỉ gọi được từ BÊN TRONG instance | không truy cập từ máy khác | | Không tính phí, không tính vào băng thông | | | Tắt hoàn toàn được nếu không cần | --http-endpoint disabled |

Với hop-limit = 1, container chạy trên instance KHÔNG gọi được IMDS — đó là hành vi mong muốn về bảo mật, nhưng cần biết trước vì một số ứng dụng trong container dựa vào đó để lấy thông tin đăng nhập. Giải pháp đúng cho container là IAM role cho task (ECS) hoặc IRSA (EKS).

Và một lựa chọn thay thế khi cần lấy thông tin từ bên ngoài instance:

aws ec2 describe-instances --instance-ids i-0abc123   --query 'Reservations[0].Instances[0].[PrivateIpAddress,PublicIpAddress]'

Cách này gọi API AWS nên cần quyền IAM và kết nối mạng tới endpoint EC2 — chậm hơn và phụ thuộc nhiều hơn IMDS, nhưng dùng được từ bất kỳ đâu.