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

Đáp án

D — Dùng EC2 Auto Scaling với AMI đã có bản vá OS mới nhất; mount một EFS file system chứa dữ liệu tĩnh vào instance lúc khởi động.

Vì sao đúng

Đề có bốn ràng buộc kéo theo hai hướng ngược nhau, và chỉ một phương án cân bằng được cả hai.

⚠ Điểm mấu chốt: tách hai thứ có nhịp thay đổi khác nhau — bản vá OS đi vào AMI, dữ liệu tĩnh nằm ngoài:

Nhúng 100 GB vào AMI
        ↓
    Mỗi lần vá OS phải dựng lại AMI kèm 100 GB → chậm và tốn
    Mỗi máy khởi động phải cấp phát và nạp 100 GB từ snapshot → rất chậm
        ↓
Đặt dữ liệu trên EFS
        ↓
    AMI chỉ chứa hệ điều hành đã vá → nhỏ, dựng lại nhanh, khởi động nhanh
    Mount EFS mất vài giây, dữ liệu có ngay
        ↓
    → và MỘT bản dữ liệu dùng chung cho mọi máy, mọi AZ

Vì sao EFS chứ không phải EBS (điểm phân biệt với phương án C). Đề nói ứng dụng triển khai trên nhiều Availability Zone. EBS gắn với một AZ; muốn dùng ở ba AZ thì phải có ba bản sao, và không có cơ chế "shared EBS volume" theo cách phương án C mô tả — Multi-Attach chỉ hoạt động trong một AZ, giới hạn 16 instance, và không cung cấp hệ thống tệp dùng chung.

# trong user data hoặc launch template
mount -t efs -o tls fs-0abc123:/ /du-lieu-tinh

⚠ Chi phí nhân lên khi mỗi máy giữ một bản dữ liệu riêng:

100 GB × 50 instance = 5 TB EBS phải trả tiền
        ↓
So với: 100 GB trên EFS, dùng chung cho cả 50 máy
        ↓
    → khác biệt lớn, và càng lớn khi cụm co giãn lên

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

• C (AMI có bản vá mới nhất — đúng; nhưng mount một EBS volume dùng chung chứa dữ liệu tĩnh) — đây là phương án gần nhất và nửa đầu của nó chính xác bằng đáp án đúng: giữ bản vá trong AMI và dữ liệu bên ngoài là tư duy đúng. Nó chỉ chọn sai loại lưu trữ. EBS không phải hệ thống tệp dùng chung: một volume gắn với một AZ, và dù có Multi-Attach thì cũng chỉ trong một AZ, giới hạn số instance, và cần một cluster file system thì nhiều máy mới ghi được an toàn. Đề nói triển khai trên nhiều AZ, nên EBS không đáp ứng được.

• A (AMI bao gồm luôn dữ liệu tĩnh, vá OS bằng Systems Manager) — vi phạm yêu cầu khởi động nhanh. Một AMI 100 GB nghĩa là mỗi lần khởi động phải cấp phát volume lớn và nạp dữ liệu từ snapshot — với EBS được khôi phục từ snapshot, các khối dữ liệu được nạp lười biếng nên lần đọc đầu tiên rất chậm. Nó cũng làm quy trình vá lỗi nặng nề: mỗi bản vá là một AMI 100 GB mới phải dựng và phân phối.

• B (AMI chuẩn, dùng user data script tải 100 GB dữ liệu từ S3 lúc khởi động) — vi phạm nặng nhất yêu cầu khởi động nhanh: tải 100 GB từ S3 cho mỗi máy mất rất nhiều phút, và nhân với số máy trong một đợt co giãn thì vừa chậm vừa tốn băng thông.

Ghi nhớ

⚠ Bốn cách đưa dữ liệu tới instance lúc khởi động — bảng phải thuộc: | Cách | Thời gian khởi động | Dùng chung nhiều AZ | |---|---|---| | Nhúng vào AMI | chậm với dữ liệu lớn | mỗi máy một bản | | Tải từ S3 trong user data | rất chậm với dữ liệu lớn | mỗi máy một bản | | Gắn EBS từ snapshot | trung bình | không — một AZ | | Mount EFS | nhanh — vài giây | có, mọi AZ |

Từ khoá nhận diện:

"dữ liệu lớn cần có trước khi ứng dụng chạy" + "khởi động nhanh" → EFS "nhiều Availability Zone" + lưu trữ dùng chung → EFS, không phải EBS "vá OS trong N giờ" → AMI mới, hoặc Systems Manager Patch Manager "shared EBS volume across AZs" → LUÔN SAI tải hàng chục GB trong user data → giết thời gian khởi động

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thời gian khởi động thật | đo từ lúc launch tới lúc qua health check | | Mount có thành công không | kiểm log cloud-init trên máy mới | | AMI có mới không | so ngày tạo AMI với ngày phát hành bản vá |

Và một lời khuyên: hãy đưa lệnh mount EFS vào launch template kèm cơ chế thử lại, và cho instance thất bại health check nếu mount hỏng. Đây là chỗ một máy khởi động "thành công" mà hoàn toàn vô dụng: nếu mount thất bại — vì mount target ở AZ đó chưa có, vì security group chặn cổng 2049, vì DNS chưa sẵn sàng — thì instance vẫn lên, vẫn chạy, vẫn được Auto Scaling coi là khoẻ mạnh, và vẫn được đăng ký vào load balancer. Nó chỉ không có dữ liệu, nên mọi request đi vào nó đều lỗi. Một health check chạm tới thư mục dữ liệu biến sự cố im lặng đó thành một instance bị thay thế tự động.

Đáp án

C — Gắn endpoint policy vào gateway endpoint để giới hạn truy cập đúng bucket đó; gán IAM role cho các EC2 instance và gắn policy vào bucket chỉ cho phép role đó.

Vì sao đúng

Đề đòi hai điều: lưu lượng không đi qua Internet (đã có gateway endpoint) và chỉ các instance ứng dụng được ghi vào bucket. Vế thứ hai cần một danh tính để cấp quyền.

⚠ Điểm mấu chốt: muốn giới hạn "chỉ ứng dụng này" thì phải có một DANH TÍNH để trỏ tới — và với EC2 đó là IAM role:

Bucket policy cần một principal cụ thể để cho phép
        ↓
    EC2 không có danh tính tự thân
        ↓
    Gán instance profile chứa IAM role
        ↓
    Mọi lời gọi từ máy đó mang danh tính role ấy
        ↓
    → bucket policy viết Allow cho đúng role ARN, Deny mọi principal khác

Hai lớp bổ sung cho nhau và bảo vệ theo hai chiều khác nhau:

// Bucket policy: chỉ role của ứng dụng
{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::tep-ung-dung", "arn:aws:s3:::tep-ung-dung/*"],
  "Condition": {"StringNotEquals": {
    "aws:PrincipalArn": "arn:aws:iam::111122223333:role/UngDungRole"}}
}

⚠ Muốn khoá chặt hơn nữa thì thêm điều kiện aws:SourceVpce vào bucket policy:

Bucket chỉ nhận request đi qua đúng VPC endpoint đó
        ↓
    Ngay cả khi ai đó lấy được thông tin đăng nhập của role
        ↓
    → họ vẫn không dùng được từ ngoài VPC

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

• A (endpoint policy giới hạn bucket — đúng; nhưng bucket policy chỉ cho phép truy cập từ VPC endpoint) — đây là phương án gần nhất và nó thật sự chặn được người ngoài VPC: điều kiện aws:SourceVpce là kỹ thuật hợp lệ và hữu ích. Nhưng nó không đáp ứng vế "only the application instances": mọi tài nguyên trong VPC đi qua endpoint đó — bất kỳ EC2 nào, bất kỳ Lambda nào trong VPC — đều thoả điều kiện và ghi được vào bucket. Nó giới hạn theo đường đi, không theo danh tính. Với yêu cầu quyền tối thiểu ở mức ứng dụng, cần cả hai, và phương án C mới có phần danh tính.

• B (endpoint policy giới hạn theo Region; bucket policy cho phép service ec2.amazonaws.com) — sai về cách principal hoạt động. ec2.amazonaws.com là service principal, đại diện cho chính dịch vụ EC2 khi nó hành động thay bạn (ví dụ gắn volume) — nó không đại diện cho các instance của bạn. Lời gọi từ một EC2 mang danh tính của role được gán, không phải của service principal. Giới hạn endpoint theo Region cũng quá rộng so với yêu cầu.

• D (bucket policy cho phép EC2 bằng điều kiện aws:SourceIp; sửa route table để chỉ instance ứng dụng dùng được endpoint) — hai lỗi. aws:SourceIp không dùng được khi request đi qua VPC endpoint — điều kiện đúng là aws:SourceVpce hoặc aws:SourceVpc. Và route table áp cho cả subnet, không thể "chỉ cho một số instance dùng endpoint"; định tuyến không phân biệt được máy nào với máy nào.

Ghi nhớ

⚠ Bốn lớp kiểm soát khi EC2 truy cập S3 qua endpoint — bảng phải thuộc: | Lớp | Kiểm soát | |---|---| | IAM role của instance | principal đó được làm gì | | Bucket policy | bucket nhận request từ ai | | Endpoint policy | qua endpoint này tới được đâu | | Route table | lưu lượng có đi qua endpoint không |

Từ khoá nhận diện:

"only the application instances" → cần IAM role, không chỉ giới hạn theo VPC "không đi qua Internet" → gateway endpoint "aws:SourceIp" với request qua VPC endpoint → SAI, dùng aws:SourceVpce "ec2.amazonaws.com" làm principal cho instance → SAI, đó là service principal "route table để giới hạn instance" → SAI, route áp cho cả subnet

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance đang mang danh tính gì | aws sts get-caller-identity từ chính máy đó | | Lưu lượng có qua endpoint không | kiểm route table và VPC Flow Logs | | Máy khác có ghi được không | thử từ một EC2 không có role đó — phải bị từ chối |

Và một lời khuyên: hãy thử ghi vào bucket từ một instance KHÔNG được cấp quyền, và xác nhận nó bị từ chối. Đây là phép thử duy nhất phân biệt giữa "đã giới hạn đúng ứng dụng" và "đã giới hạn đúng VPC": cả hai cấu hình đều khiến ứng dụng thật chạy hoàn hảo, đều khiến người ngoài không vào được, và đều trông giống nhau khi bạn đọc lại chính sách. Khác biệt chỉ lộ ra khi có một tài nguyên khác trong cùng VPC — một máy thử nghiệm, một hàm Lambda của đội khác — thử ghi vào bucket. Nếu nó ghi được, bạn đang có một hàng rào quanh mạng chứ không phải quanh ứng dụng.

Đáp án

C — Cấu hình CodeCommit trigger gọi một Lambda function quét mã mới nộp để tìm thông tin đăng nhập; nếu tìm thấy thì vô hiệu hoá chúng và báo cho người dùng.

Vì sao đúng

Đề đòi tự động tìm và khắc phục, liên tục. Điểm mấu chốt là "liên tục" — nghĩa là phải bắt được mọi lần nộp mã mới, ngay khi nó xảy ra.

⚠ Điểm mấu chốt: khoá đã lộ trong lịch sử Git thì phải VÔ HIỆU HOÁ, không phải xoá đi:

Xoá dòng chứa khoá rồi commit lại
        ↓
    Khoá vẫn nằm nguyên trong lịch sử commit
    Ai clone repo đều lấy được
        ↓
    → khoá đã lộ vĩnh viễn kể từ giây nó được push
        ↓
    → hành động đúng duy nhất: VÔ HIỆU HOÁ khoá đó ngay lập tức

Đây là lý do phương án C nói "disable them" chứ không nói "xoá khỏi mã".

import boto3, re
codecommit = boto3.client('codecommit')
iam = boto3.client('iam')

MAU_KHOA = re.compile(r'(?<![A-Z0-9])[A-Z0-9]{20}(?![A-Z0-9])')

def handler(su_kien, ngu_canh):
    for ban_ghi in su_kien['Records']:
        # lấy nội dung commit mới, quét từng tệp
        # nếu khớp mẫu khoá → vô hiệu hoá
        iam.update_access_key(AccessKeyId=khoa_tim_thay, Status='Inactive')

⚠ Trigger của CodeCommit chạy SAU khi mã đã được nhận — nó là phát hiện, không phải ngăn chặn:

Lập trình viên push
        ↓
    CodeCommit nhận mã, rồi mới gọi trigger
        ↓
    → khoá đã nằm trong repo trong khoảng thời gian đó
        ↓
    → muốn NGĂN thì cần git hook phía client (pre-commit) hoặc
      công cụ quét trong pipeline trước khi merge

Vì thế cách làm đầy đủ là kết hợp cả hai lớp: ngăn ở phía lập trình viên, và bắt ở phía máy chủ như một lưới an toàn.

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

• B (tạo Macie job quét CodeCommit repository, Lambda vô hiệu hoá khi tìm thấy) — đây là phương án gần nhất và phần hành động khắc phục của nó đúng: vô hiệu hoá khoá là việc cần làm. Nhưng Amazon Macie chỉ quét dữ liệu trong Amazon S3 — nó không đọc được CodeCommit repository. Macie phân loại dữ liệu nhạy cảm (thông tin cá nhân, số thẻ, khoá bí mật) trong object S3, và danh sách nguồn dữ liệu của nó không bao gồm kho mã. Đây là bẫy hay vì Macie đúng là công cụ tìm bí mật, chỉ là ở một nơi khác.

• A (dùng Trusted Advisor kiểm tra "unsecured credentials", rồi dùng Secrets Manager xoay vòng) — Trusted Advisor có một kiểm tra tên là "Exposed Access Keys", nhưng nó quét các kho công khai trên Internet (như GitHub công khai), không quét CodeCommit riêng tư của bạn. Và Secrets Manager xoay vòng bí mật do nó quản lý, không xoay vòng một khoá IAM ngẫu nhiên tìm thấy trong mã.

• D (chạy cron job trên EC2 để kiểm tra repository, sinh khoá mới và lưu trong AWS KMS) — nhiều lỗi. Cron trên EC2 là hạ tầng phải vận hành, chạy theo chu kỳ nên có độ trễ, và KMS không phải nơi lưu khoá truy cập — nó quản lý khoá mã hoá, không lưu trữ chuỗi bí mật (đó là việc của Secrets Manager). Việc "sinh khoá mới" cũng không giải quyết gì nếu khoá cũ chưa bị vô hiệu hoá.

Ghi nhớ

⚠ Bốn công cụ tìm bí mật — bảng phải thuộc, chú ý phạm vi: | Công cụ | Quét ở đâu | |---|---| | Amazon Macie | chỉ Amazon S3 | | Trusted Advisor "Exposed Access Keys" | kho công khai trên Internet | | CodeCommit trigger + Lambda | kho CodeCommit của bạn | | Amazon CodeGuru Reviewer (Secrets Detector) | mã trong pull request | | git-secrets, gitleaks (bên thứ ba) | phía client, trước khi commit |

Từ khoá nhận diện:

"scan CodeCommit for credentials" → CodeCommit trigger + Lambda, hoặc CodeGuru "on an ongoing basis" → theo sự kiện, không phải cron định kỳ "Macie quét CodeCommit" → LUÔN SAI, Macie chỉ quét S3 "KMS để lưu access key" → SAI, đó là Secrets Manager khoá đã lộ → VÔ HIỆU HOÁ, xoá khỏi mã là chưa đủ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trigger có chạy không | log của Lambda sau một lần push thử | | Có bỏ sót mẫu nào không | thử nhiều dạng khoá: IAM, khoá bên thứ ba, chuỗi kết nối | | Khoá đã lộ có bị dùng không | CloudTrail, lọc theo accessKeyId |

Và một lời khuyên: hãy rà CloudTrail theo accessKeyId của mọi khoá bị phát hiện, đừng chỉ vô hiệu hoá rồi thôi. Vô hiệu hoá chặn được việc lạm dụng từ giây đó trở đi, nhưng nó không nói gì về khoảng thời gian trước đó — và với một khoá đã nằm trong repository nhiều tuần, câu hỏi quan trọng không phải "khoá có bị lộ không" mà là "nó đã bị dùng chưa, và để làm gì". Câu trả lời nằm trong CloudTrail, tra được bằng chính chuỗi khoá đó. Bỏ qua bước này nghĩa là bạn đã đóng cửa nhưng chưa bao giờ kiểm tra xem có ai đã vào.

Đáp án

A — Bucket có thiết lập BlockPublicAcls đặt thành TRUE.

Vì sao đúng

Đề mô tả chính xác một thao tác và một lỗi: PUT Object kèm public ACL bị từ chối với "insufficient permissions". Trong bốn tuỳ chọn của Block Public Access, chỉ một cái chặn đúng hành động đó.

⚠ Điểm mấu chốt: bốn tuỳ chọn chia theo hai trục — ACL hay policy, và ngăn cái mới hay vô hiệu cái cũ:

                    ACL                    Bucket policy
Ngăn cái mới    BlockPublicAcls          BlockPublicPolicy
Vô hiệu cái cũ  IgnorePublicAcls         RestrictPublicBuckets

Người dùng đang đặt một ACL mới, nên thứ chặn họ là ô góc trên bên trái: BlockPublicAcls.

aws s3api get-public-access-block --bucket bao-cao-du-lieu

⚠ Với bucket hiện đại, ACL còn có thể đã bị TẮT hoàn toàn:

Từ tháng 4/2023, bucket mới mặc định "Bucket owner enforced"
        ↓
    ACL bị vô hiệu hoá hoàn toàn
        ↓
    → mọi lời gọi đặt ACL đều thất bại, kể cả khi Block Public Access tắt
        ↓
    → thông báo lỗi cũng là "access denied", rất dễ nhầm với trường hợp của đề

Cách chia sẻ một tệp đúng đắn — không cần ACL công khai chút nào:

# presigned URL: hết hạn, không cần mở công khai gì cả
aws s3 presign s3://bao-cao-du-lieu/bao-cao-thang-9.csv --expires-in 604800

Đây là cách nên dùng cho tình huống của đề: chia sẻ một tệp cho một tổ chức bên ngoài mà không phá vỡ tư thế bảo mật của cả bucket.

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

• C (bucket có BlockPublicPolicy đặt thành TRUE) — đây là phương án gần nhất và nó cùng thuộc đúng tính năng Block Public Access. Nhưng nó nhắm sai trục: BlockPublicPolicy chặn việc gắn hoặc sửa BUCKET POLICY theo hướng làm bucket công khai. Người dùng trong đề không đụng tới bucket policy — họ gọi PutObject kèm một ACL. Hai cơ chế kiểm soát truy cập khác nhau, và mỗi cái có cặp công tắc riêng. Đây là bẫy đòi phân biệt chính xác ACL với policy.

• D (ACL của object không cho phép quyền ghi cho tài khoản IAM đó) — không khớp với tình huống. Người dùng đang tạo hoặc ghi đè object bằng PutObject; quyền cho thao tác đó đến từ IAM policy và bucket policy, không từ ACL của một object có thể còn chưa tồn tại. Và nếu thiếu quyền ghi cơ bản thì họ đã không upload được tệp nào ngay từ đầu.

• B (object có một policy chặn mọi truy cập công khai) — object không có "policy". S3 có bucket policy ở cấp bucket và ACL ở cấp object; không tồn tại khái niệm object policy. Đây là phương án mô tả một cơ chế không có thật.

Ghi nhớ

⚠ Bốn tuỳ chọn Block Public Access — bảng phải thuộc, đây là bảng ra thi nhiều nhất về S3: | Tuỳ chọn | Tác động lên | Ngăn cái mới hay vô hiệu cái cũ | |---|---|---| | BlockPublicAcls | ACL | ngăn đặt mới | | IgnorePublicAcls | ACL | vô hiệu cái đang có | | BlockPublicPolicy | bucket policy | ngăn gắn mới | | RestrictPublicBuckets | bucket policy | vô hiệu cái đang có |

Quy tắc nhớ: Block = ngăn cái mới, Ignore/Restrict = vô hiệu cái đang có.

Từ khoá nhận diện:

"PUT object với public ACL" bị từ chối → BlockPublicAcls "gắn bucket policy công khai" bị từ chối → BlockPublicPolicy "public access đang bật, cần chặn ngay" → IgnorePublicAcls hoặc RestrictPublicBuckets "object policy" → LUÔN SAI, không tồn tại chia sẻ một tệp cho bên ngoài → presigned URL, đừng mở công khai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bốn cờ đang bật cái nào | aws s3api get-public-access-block | | ACL có bị tắt không | aws s3api get-bucket-ownership-controls | | Presigned URL có chạy không | tạo thử và mở bằng trình duyệt ẩn danh |

Và một lời khuyên: hãy dùng presigned URL thay vì mở ACL công khai, ngay cả khi bạn có quyền tắt Block Public Access. Việc mở công khai một object để chia sẻ với một đối tác là quyết định gần như không bao giờ được đảo ngược: người ta chia sẻ URL, URL nằm lại trong email và tài liệu, và không ai quay lại đóng nó sau khi hết nhu cầu. Presigned URL giải quyết cùng bài toán nhưng có hạn dùng gắn sẵn — nghĩa là trạng thái mặc định sau vài ngày là đóng, chứ không phải mở. Với dữ liệu được đề mô tả là "generally confidential", khác biệt đó là toàn bộ vấn đề.

Đáp án

A, B — hai cách để Lambda truy cập được cả Neptune trong VPC lẫn DynamoDB:

• A — Cấu hình hai private subnet trong VPC của Neptune, định tuyến lưu lượng Internet qua NAT gateway, và đặt Lambda vào các subnet đó.
• B — Tạo hai subnet mới trong VPC của Neptune riêng cho Lambda, và dựng VPC endpoint cho DynamoDB để truy cập trực tiếp từ các subnet đó.

Vì sao đúng

Bài toán có hai vế đối nghịch: Neptune chỉ truy cập được từ trong VPC, còn DynamoDB là endpoint công cộng. Lambda phải với tới cả hai.

⚠ Điểm mấu chốt: Lambda đặt trong VPC MẤT quyền truy cập Internet mặc định:

Lambda ngoài VPC
        ↓
    Gọi được mọi endpoint công cộng của AWS, không gọi được tài nguyên riêng

Lambda đặt trong VPC
        ↓
    Gọi được tài nguyên riêng (Neptune)
    NHƯNG mất đường ra Internet — DynamoDB không còn với tới được
        ↓
    → phải khôi phục đường đó bằng NAT gateway (A) hoặc VPC endpoint (B)

Hai phương án đúng là hai cách khác nhau để nối lại đường tới DynamoDB.

Với riêng DynamoDB, phương án B tốt hơn về cả chi phí lẫn bảo mật — nhưng cả hai đều là câu trả lời hợp lệ cho câu hỏi.

# gateway endpoint cho DynamoDB — miễn phí
aws ec2 create-vpc-endpoint --vpc-id vpc-neptune \
  --service-name com.amazonaws.ap-southeast-1.dynamodb \
  --route-table-ids rtb-lambda-1a rtb-lambda-1b

⚠ Đặt Lambda vào private subnet chứ không phải public subnet:

Lambda trong public subnet
        ↓
    ENI của Lambda KHÔNG được gán IP công cộng
        ↓
    → dù subnet có route tới internet gateway, Lambda vẫn không ra được
        ↓
    → đây chính là lý do phương án D sai

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

• D (tạo hai public subnet trong VPC của Neptune, lưu lượng qua internet gateway, đặt Lambda vào đó) — đây là phương án gần nhất và nó đúng ở chỗ đặt Lambda vào VPC của Neptune. Nhưng nó hiểu sai cách Lambda nối mạng: ENI mà Lambda tạo trong VPC không bao giờ nhận địa chỉ IP công cộng, nên dù subnet có tuyến tới internet gateway, hàm vẫn không gọi ra ngoài được. Đây là quy tắc cứng và là một trong những nhầm lẫn phổ biến nhất về Lambda trong VPC. Cách duy nhất để ra Internet là qua NAT gateway đặt trong public subnet, còn bản thân hàm phải nằm trong private subnet.

• E (đặt Lambda ngoài VPC và dựng VPC endpoint cho Neptune) — không có VPC endpoint cho Neptune. PrivateLink hỗ trợ nhiều dịch vụ AWS, nhưng Neptune không nằm trong danh sách đó theo cách này — Neptune là tài nguyên trong VPC của bạn, không phải một dịch vụ AWS phơi endpoint ra. Muốn tới nó thì phải ở trong VPC hoặc nối vào VPC đó.

• C (giữ Lambda ngoài VPC, sửa security group của Neptune để cho phép theo dải IP động của Lambda) — bất khả thi. Lambda ngoài VPC không có dải IP cố định hay công bố được, và Neptune không có endpoint công cộng để mà cho phép. Đây là phương án dựa trên một thứ không tồn tại.

Ghi nhớ

⚠ Bốn điều về Lambda trong VPC — bảng phải thuộc: | Điều | Nội dung | |---|---| | Mất Internet mặc định | phải có NAT gateway hoặc VPC endpoint | | ENI không có IP công cộng | public subnet vô ích | | Hyperplane ENI | dùng chung giữa các hàm cùng cấu hình — cold start không còn bị phạt nặng | | Cần nhiều subnet | nên khai ít nhất hai AZ để chịu lỗi |

Từ khoá nhận diện:

"Lambda cần truy cập tài nguyên trong VPC" → đặt hàm vào VPC "Lambda trong VPC cần gọi dịch vụ AWS công cộng" → NAT gateway hoặc VPC endpoint "đặt Lambda vào public subnet để ra Internet" → LUÔN SAI "VPC endpoint cho Neptune" → SAI, Neptune nằm trong VPC của bạn "dải IP của Lambda ngoài VPC" → SAI, không có dải cố định

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm có gọi được DynamoDB không | thêm một lời gọi thử và xem log | | Subnet còn IP không | AvailableIpAddressCount | | Route có đúng không | private subnet phải trỏ 0.0.0.0/0 tới NAT, và có prefix list DynamoDB nếu dùng endpoint |

Và một lời khuyên: hãy dùng gateway endpoint cho DynamoDB thay vì NAT gateway, nếu đó là dịch vụ công cộng duy nhất hàm cần. Khác biệt không nhỏ như vẻ ngoài: NAT gateway tính tiền theo giờ và theo từng GB đi qua, nên một hàm gọi DynamoDB hàng triệu lần mỗi ngày sẽ tạo ra một dòng chi phí đều đặn cho một việc mà gateway endpoint làm hoàn toàn miễn phí. Và vì cả hai cách đều khiến ứng dụng chạy đúng như nhau, không có gì trong hệ thống báo cho bạn biết rằng bạn đang trả tiền cho một chặng đường không cần thiết.

Đáp án

B — Thêm một lớp Amazon ElastiCache for Redis để cache kết quả truy vấn cơ sở dữ liệu; sửa các hàm Lambda để đọc từ cache khi có.

Vì sao đúng

Đề chỉ đích danh triệu chứng: lỗi bộ nhớ ở cơ sở dữ liệu, gây ra bởi các truy vấn GET lặp lại giống hệt nhau. Nút thắt nằm ở tầng dữ liệu, nên lớp cache đặt ngay trước nó là đòn bẩy trực tiếp nhất.

⚠ Điểm mấu chốt: cache đặt trước cơ sở dữ liệu chặn đúng thứ đang gây lỗi — chính là truy vấn:

Lambda nhận request
        ↓
    Tra Redis bằng khoá dựng từ tham số truy vấn
        ↓
    Trúng → trả về ngay, KHÔNG chạm tới Aurora
    Trượt → truy vấn Aurora, ghi kết quả vào Redis rồi trả về
        ↓
    → số truy vấn tới cụm giảm theo tỷ lệ trúng cache
        ↓
    → áp lực bộ nhớ trên Aurora Serverless giảm theo

import redis, json, os
cache = redis.Redis(host=os.environ['REDIS_HOST'], port=6379, ssl=True)

def lay_du_lieu(ma_xe):
    khoa = f"xe:{ma_xe}"
    da_co = cache.get(khoa)
    if da_co:
        return json.loads(da_co)
    ket_qua = truy_van_aurora(ma_xe)
    cache.setex(khoa, 300, json.dumps(ket_qua))   # TTL 5 phút
    return ket_qua

⚠ Mẫu cache-aside đòi xử lý được trường hợp cache chết:

Cụm Redis không phản hồi
        ↓
    Nếu mã không bắt lỗi → mọi request thất bại, dù Aurora vẫn khoẻ
        ↓
    → luôn bọc lời gọi cache trong try/except và rơi về truy vấn trực tiếp
        ↓
    → cache là lớp tăng tốc, không được trở thành điểm hỏng đơn lẻ

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

• C (chuyển endpoint Regional sang edge-optimized và bật response caching ở stage production) — đây là phương án gần nhất và nó cũng là một kỹ thuật cache hợp lệ, thậm chí chặn sớm hơn một tầng. Nhưng với tình huống này nó có hai hạn chế. Cache của API Gateway chỉ áp cho phản hồi HTTP theo từng endpoint và tham số, nên nó không giúp gì cho các truy vấn giống nhau đến từ những endpoint khác nhau hoặc từ các phần khác của logic nghiệp vụ. Và edge-optimized giảm độ trễ mạng chứ không giảm áp lực bộ nhớ trên cơ sở dữ liệu — mà đề chỉ đích danh "database memory errors" là vấn đề cần chữa. Xem thêm ghi chú về chất lượng câu hỏi bên dưới.

• A (tăng mức bộ nhớ tối đa của cụm Aurora Serverless) — mở rộng dọc: nâng trần chứ không giảm tải, và tăng chi phí trực tiếp — đi ngược yêu cầu "without significantly raising costs". Nó cũng không đụng tới nguyên nhân là hàng loạt truy vấn giống hệt nhau.

• D (áp rate limiting và burst control ở stage production) — từ chối bớt request chứ không tăng năng lực phục vụ. Đề nói mục tiêu là hỗ trợ được lượng tải tăng thêm; chặn bớt người dùng là đổi một sự cố hệ thống lấy một sự cố trải nghiệm.

Ghi nhớ về chất lượng câu hỏi

⚠ Bộ đề có một câu gần trùng với khoá đáp án NGƯỢC LẠI — câu #10918:

#10918: API Gateway + Lambda + Aurora, GET lặp lại theo đợt
        → khoá: edge-optimized endpoint + API Gateway caching

#10938 (câu này): API Gateway + Lambda + Aurora Serverless, GET lặp lại
        → khoá: ElastiCache for Redis
        ↓
    Hai đề mô tả gần như cùng một tình huống, hai khoá loại trừ nhau

Cách phân biệt khi làm bài: đọc kỹ triệu chứng mà đề nhấn mạnh và danh sách phương án. Ở câu này, đề nói rõ "database memory errors" gắn với Aurora Serverless — tức là áp lực nằm ở tầng dữ liệu, nên cache ngay trước cơ sở dữ liệu là câu trả lời. Ở #10918, tình huống là một chiến dịch quảng bá làm bùng số request ở tầng API, nên cache ở API Gateway được chọn.

Không sửa khoá đáp án, chỉ ghi chú. Trong thực tế hai kỹ thuật này bổ sung cho nhau: một hệ thống chịu tải cao thường có cả hai lớp cache, và việc phải chọn một trong hai chỉ tồn tại trong bài thi.

Ghi nhớ

⚠ Bốn tầng cache — bảng phải thuộc, theo thứ tự từ ngoài vào: | Tầng | Công cụ | Chặn được gì | |---|---|---| | Biên | CloudFront | request chưa tới Region | | API | API Gateway cache | Lambda và mọi thứ phía sau | | Ứng dụng | ElastiCache | truy vấn tới cơ sở dữ liệu | | Cơ sở dữ liệu | buffer pool của engine | đọc đĩa |

Từ khoá nhận diện:

"database memory errors" + truy vấn lặp lại → ElastiCache trước cơ sở dữ liệu "repeated identical queries" → cache kết quả truy vấn "rate limiting" khi cần tăng năng lực → SAI, đó là từ chối bớt "tăng bộ nhớ instance" khi vấn đề là truy vấn lặp → mở rộng dọc, không bền cần giảm độ trễ mạng cho người dùng xa → edge-optimized, khác bài toán này

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỷ lệ trúng cache | CacheHits so với CacheMisses | | Tải cơ sở dữ liệu có giảm không | số truy vấn và mức bộ nhớ của Aurora trước/sau | | Cache có bị đầy không | Evictions — khác 0 nghĩa là cần cụm lớn hơn |

Và một lời khuyên: hãy bọc mọi lời gọi cache trong xử lý lỗi và rơi về truy vấn trực tiếp khi thất bại. Đây là cách một lớp tăng tốc biến thành nguyên nhân của sự cố nghiêm trọng hơn thứ nó được thêm vào để chữa: khi cụm Redis gặp sự cố — bảo trì, chuyển dự phòng, hoặc chỉ là một node hết bộ nhớ — mà mã không bắt lỗi, thì toàn bộ ứng dụng ngừng phục vụ dù cơ sở dữ liệu vẫn hoàn toàn khoẻ mạnh và sẵn sàng trả lời. Bạn vừa thêm một điểm hỏng đơn lẻ vào một hệ thống trước đó không có, và nó sẽ chọn đúng ngày tải cao để chứng minh điều đó.

Đáp án

A — Tạo kết nối VPN giữa mạng nội bộ công ty và VPC; cấu hình security group của EC2 chỉ cho phép lưu lượng từ kết nối VPN đó.

Vì sao đúng

Đề đòi ứng dụng chỉ truy cập được từ mạng công ty và không truy cập được từ Internet công cộng. Chỉ một phương án đạt được cả hai vế.

⚠ Điểm mấu chốt: chỉ VPN mới tạo ra một ranh giới mạng thật — mọi cách lọc theo IP công cộng đều mong manh:

Lọc theo dải IP công cộng của công ty
        ↓
    Dải IP có thể đổi, có thể bị giả mạo ở một số kịch bản
    Và ứng dụng vẫn có endpoint công khai để bất kỳ ai gõ thử
        ↓
VPN
        ↓
    Instance chỉ có địa chỉ riêng, không có đường vào từ Internet
    Lưu lượng đi trong đường hầm mã hoá
        ↓
    → không có endpoint công khai nào tồn tại để mà tấn công

aws ec2 create-vpn-connection --type ipsec.1 \
  --customer-gateway-id cgw-abc --vpn-gateway-id vgw-abc \
  --options StaticRoutesOnly=false

aws ec2 authorize-security-group-ingress --group-id sg-app \
  --protocol tcp --port 443 --cidr 192.168.0.0/16    # dải nội bộ công ty

⚠ Instance phải nằm trong private subnet — VPN thôi chưa đủ:

Instance trong public subnet có IP công cộng
        ↓
    Dù có VPN, nó vẫn có một địa chỉ mà Internet gọi tới được
        ↓
    Security group chặn được, nhưng chỉ cần một rule sai là phơi ra
        ↓
    → đặt trong private subnet thì không có địa chỉ nào để mà chặn

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

• D (dựng ELB chỉ nhận lưu lượng từ dải IP công cộng của công ty, gắn vào các EC2) — đây là phương án gần nhất và nó thật sự hạn chế được truy cập: security group của ELB lọc theo dải IP là kỹ thuật hợp lệ và phổ biến. Nhưng nó vẫn tạo ra một endpoint công khai — ELB có tên miền phân giải được từ Internet, và bất kỳ ai cũng có thể gửi request tới nó, chỉ là bị từ chối ở tầng security group. Với dữ liệu tài chính nhạy cảm, tồn tại một điểm vào công khai là một tư thế bảo mật yếu hơn hẳn: nó lộ ra trong quét cổng, chịu tấn công DDoS, và chỉ cần một rule bị nới lỏng nhầm là mở toang. Ngoài ra dải IP công cộng của công ty có thể thay đổi, và lưu lượng vẫn đi qua Internet không mã hoá ở tầng mạng.

• B (CloudFront với origin access identity để hạn chế truy cập tới EC2) — sai công cụ theo hai cách. OAI chỉ dùng với origin là S3, không dùng được với EC2. Và CloudFront là mạng phân phối công khai — đặt nó trước một ứng dụng nội bộ là làm cho ứng dụng đó dễ truy cập từ Internet hơn, đúng điều ngược lại với yêu cầu.

• C (tạo NAT Gateway và cấu hình route table chỉ cho lưu lượng từ dải IP công ty tới EC2) — hiểu sai vai trò NAT gateway. NAT gateway phục vụ lưu lượng ĐI RA từ private subnet ra Internet; nó không nhận lưu lượng đi vào và không phải cơ chế kiểm soát truy cập. Route table cũng không lọc theo IP nguồn — nó chỉ quyết định gói tin đi đâu.

Ghi nhớ

⚠ Bốn cách cho mạng công ty truy cập tài nguyên riêng trong VPC — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Site-to-Site VPN | mạng ↔ VPC, qua Internet nhưng mã hoá, rẻ, nhanh triển khai | | Direct Connect | đường riêng, hiệu năng ổn định, đắt và lâu | | Client VPN | từng máy khách, hợp với người làm từ xa | | Verified Access | truy cập ứng dụng theo danh tính, không cần VPN |

Từ khoá nhận diện:

"only accessible from the corporate network" → VPN hoặc Direct Connect "not accessible from the public internet" → private subnet, không có endpoint công khai "OAI cho EC2" → LUÔN SAI, OAI chỉ dùng với S3 "NAT gateway để kiểm soát truy cập vào" → SAI, NAT là đường đi ra "ELB lọc theo IP công ty" → chạy được nhưng vẫn có endpoint công khai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Từ Internet có vào được không | thử curl từ một máy ngoài — phải không phân giải hoặc timeout | | Từ mạng công ty có vào được không | thử từ máy nội bộ | | Tunnel có lên không | describe-vpn-connections, xem trạng thái từng tunnel |

Và một lời khuyên: hãy cấu hình cả hai đường hầm VPN chứ đừng chỉ dùng một. Đây là chỗ một kết nối trông hoàn toàn khoẻ mạnh cho tới ngày AWS bảo trì: mỗi Site-to-Site VPN connection luôn được cấp hai tunnel ở hai AZ khác nhau, và AWS thực hiện bảo trì trên từng tunnel một — nếu thiết bị phía bạn chỉ cấu hình một, thì mỗi lần tunnel đó được bảo trì là một lần mất kết nối hoàn toàn. Thông báo bảo trì có gửi trước, nhưng nó nằm trong Personal Health Dashboard chứ không đập vào mắt ai, và đội mạng thường chỉ phát hiện ra sự phụ thuộc này khi sự cố đã xảy ra lần thứ hai.

Đáp án

B — Dùng CloudWatch Logs agent để đẩy log trực tiếp lên CloudWatch Logs theo luồng, đặt tham số batch_count bằng 1.

Vì sao đúng

Đề nói rõ nguyên nhân mất log: instance biến mất trước khi cron job kịp chạy. Lời giải phải bỏ hẳn khoảng trễ giữa lúc log được ghi và lúc nó rời khỏi máy.

⚠ Điểm mấu chốt: mọi cách thu gom theo chu kỳ đều để lại một cửa sổ mất mát — chỉ streaming mới đóng được nó:

Cron mỗi 30 phút
        ↓
    Cửa sổ mất mát: tới 30 phút log
        ↓
Cron mỗi 5 phút
        ↓
    Cửa sổ mất mát: tới 5 phút — nhỏ hơn nhưng VẪN CÒN
        ↓
Agent đẩy theo luồng
        ↓
    Log rời khỏi máy ngay khi được ghi
        ↓
    → cửa sổ mất mát gần như bằng 0

Đây là lý do phương án A — giảm chu kỳ cron — chỉ làm vấn đề nhỏ đi chứ không giải quyết.

Vì sao batch_count=1. Agent mặc định gom nhiều sự kiện lại rồi gửi một lần để tiết kiệm lời gọi API. Đặt bằng 1 nghĩa là gửi ngay mỗi sự kiện — đánh đổi chi phí API lấy độ tin cậy tối đa, đúng thứ đề yêu cầu.

[general]
state_file = /var/lib/awslogs/agent-state

[/var/log/ung-dung.log]
file = /var/log/ung-dung.log
log_group_name = /ung-dung/prod
log_stream_name = {instance_id}
batch_count = 1

⚠ Nếu instance bị huỷ đột ngột, vẫn có thể mất vài dòng cuối — nên dùng lifecycle hook cho công việc quan trọng:

Auto Scaling terminate instance
        ↓
    Lifecycle hook giữ máy ở trạng thái Terminating:Wait
        ↓
    Cho agent kịp đẩy nốt phần còn lại
        ↓
    → complete-lifecycle-action rồi máy mới thật sự bị huỷ

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

• A (đổi cron chạy mỗi 5 phút thay vì 30 phút) — đây là phương án gần nhất và nó thật sự giảm được xác suất mất log: cửa sổ rủi ro nhỏ đi sáu lần. Nhưng nó không đổi bản chất vấn đề — vẫn có một khoảng thời gian log chỉ tồn tại trên đĩa của một máy có thể biến mất bất cứ lúc nào. Với một sự cố xảy ra ngay trước lần chạy kế tiếp, bạn vẫn mất đúng những dòng log quan trọng nhất: những dòng ghi lại nguyên nhân máy đó chết. Đề hỏi cách đáng tin cậy nhất, và giảm rủi ro không phải là loại bỏ rủi ro.

• C (CloudWatch Events kích hoạt Lambda thu thập log qua kết nối SSH) — nhiều vấn đề. Lambda kết nối SSH vào EC2 là mẫu chống chỉ định: cần quản lý khoá SSH, cần mở cổng, cần Lambda nằm trong VPC. Nó vẫn là thu gom theo chu kỳ nên vẫn có cửa sổ mất mát. Và với một instance đã bị huỷ, không còn gì để SSH vào cả.

• D (CloudWatch Events kích hoạt Session Manager chạy script thu thập log) — Session Manager là công cụ tốt hơn SSH về mọi mặt, nhưng cùng nhược điểm cốt lõi: vẫn theo chu kỳ, và vẫn cần máy còn sống. Với máy đã bị Auto Scaling huỷ, phương án này không lấy được gì.

Ghi nhớ

⚠ Bốn cách đưa log ra khỏi EC2 — bảng phải thuộc: | Cách | Cửa sổ mất mát | |---|---| | CloudWatch agent (streaming) | gần như bằng 0 | | Cron đẩy lên S3 | bằng chu kỳ cron | | Thu gom từ xa (SSH, Session Manager) | bằng chu kỳ, và cần máy còn sống | | Đọc thủ công khi cần | mất hoàn toàn nếu máy đã huỷ |

Từ khoá nhận diện:

"logs lost when instances terminate" → streaming, không phải thu gom theo chu kỳ "MOST reliable" → CloudWatch agent với batch nhỏ "giảm chu kỳ cron" → giảm rủi ro chứ không loại bỏ "SSH từ Lambda" → mẫu chống chỉ định máy đã bị huỷ → mọi cách thu gom từ xa đều vô nghĩa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent có chạy không | systemctl status amazon-cloudwatch-agent | | Log có tới CloudWatch không | kiểm log stream theo instance_id | | Có mất dòng nào không | so số dòng trên máy với số sự kiện trong log group |

Và một lời khuyên: hãy thêm lifecycle hook cho sự kiện terminate và cho nó vài chục giây trước khi máy bị huỷ. Streaming đóng được gần hết cửa sổ mất mát, nhưng "gần hết" không phải "hết": khi Auto Scaling quyết định huỷ một instance, agent có thể còn vài sự kiện trong bộ đệm chưa kịp gửi — và đó thường chính là những dòng ghi lại điều gì đã xảy ra ngay trước khi máy bị coi là không khoẻ mạnh. Vài chục giây chờ thêm không ảnh hưởng gì tới quá trình co giãn, nhưng nó là khác biệt giữa việc có và không có manh mối cho lần điều tra tiếp theo.

Đáp án

B, C — hai bước để bỏ thông tin đăng nhập khỏi mã và tự động xoay vòng:

• B — Tạo thông tin đăng nhập cơ sở dữ liệu đã mã hoá trong AWS Secrets Manager cho RDS.
• C — Cấu hình Lambda dùng thông tin đăng nhập lưu trong Secrets Manager và bật xoay vòng tự động.

Vì sao đúng

Đề nêu một vấn đề cụ thể: mật khẩu nằm ở dạng rõ trong mã Lambda. Lời giải cần cả nơi lưu an toàn lẫn cơ chế xoay vòng.

⚠ Điểm mấu chốt: chỉ Secrets Manager xoay vòng ĐẦY ĐỦ — nó đổi mật khẩu ở CẢ hai nơi:

Đến hạn xoay vòng
        ↓
    Secrets Manager gọi Lambda xoay vòng (AWS cung cấp sẵn cho RDS)
        ↓
    Hàm đó ĐỔI MẬT KHẨU TRONG CHÍNH CƠ SỞ DỮ LIỆU
        ↓
    Rồi cập nhật giá trị secret
        ↓
    → hai bên luôn khớp, ứng dụng không cần biết gì

Đây là điểm phân biệt cốt lõi với KMS: KMS quản lý khoá mã hoá, nó không lưu chuỗi mật khẩu và không có cách nào đổi mật khẩu trong cơ sở dữ liệu.

import boto3, json, os
sm = boto3.client('secretsmanager')

# lấy lúc chạy, KHÔNG hard-code
bi_mat = json.loads(sm.get_secret_value(SecretId=os.environ['SECRET_ARN'])['SecretString'])
ket_noi = ket_noi_csdl(bi_mat['username'], bi_mat['password'], bi_mat['host'])

⚠ Mật khẩu đã từng nằm trong mã thì coi như đã lộ — phải đổi ngay, không chỉ chuyển chỗ lưu:

Mã đã được commit vào kho
        ↓
    Mật khẩu nằm trong lịch sử Git, ai clone đều thấy
        ↓
    Chuyển sang Secrets Manager không xoá được nó khỏi lịch sử
        ↓
    → bước đầu tiên phải là ĐỔI mật khẩu, rồi mới nói tới chuyện lưu ở đâu

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

• E (cấu hình Lambda dùng thông tin đăng nhập lưu trong AWS KMS và bật xoay vòng khoá tự động) — đây là phương án gần nhất và nó có cấu trúc giống hệt phương án C, chỉ đổi tên dịch vụ. Nhưng nó hiểu sai KMS ở hai tầng. KMS không lưu bí mật — nó tạo và quản lý khoá mã hoá, và các thao tác của nó là mã hoá/giải mã, không phải lưu trữ chuỗi. Và "automatic key rotation" của KMS xoay vòng vật liệu khoá mã hoá, hoàn toàn không liên quan tới việc đổi mật khẩu cơ sở dữ liệu. Đây là bẫy hay vì nó dùng đúng chữ "rotation" cho một thứ xoay vòng hoàn toàn khác.

• A (lưu thông tin đăng nhập RDS trong KMS bằng imported key material) — cùng hiểu nhầm cơ bản, và còn sai thêm: imported key material là tính năng cho phép bạn tự mang vật liệu khoá mã hoá vào KMS, dùng khi có yêu cầu tuân thủ về nguồn gốc khoá. Nó không liên quan gì tới việc lưu mật khẩu.

• D (viết Lambda xoay vòng mỗi giờ bằng cách triển khai một version mới với mật khẩu đã cập nhật) — sai về mọi mặt. Nhúng mật khẩu vào version của hàm nghĩa là mật khẩu vẫn nằm trong mã, chỉ khác là giờ nó nằm trong nhiều version thay vì một. Triển khai lại hàm mỗi giờ là một quy trình mong manh và tốn kém, và nó không đổi mật khẩu trong chính cơ sở dữ liệu.

Ghi nhớ

⚠ Ba nơi lưu cấu hình và bí mật — bảng phải thuộc: | Dịch vụ | Xoay vòng tự động | Chi phí | Dùng cho | |---|---|---|---| | Secrets Manager | CÓ, đổi cả ở CSDL | ~0,4 USD/secret/tháng | mật khẩu CSDL, khoá API | | Parameter Store (SecureString) | không | miễn phí ở bậc Standard | cấu hình, bí mật không cần xoay vòng | | KMS | xoay vòng khoá mã hoá | theo khoá + lượt gọi | quản lý khoá, KHÔNG lưu bí mật |

Từ khoá nhận diện:

"automatic rotation of credentials" → Secrets Manager, không có lựa chọn khác "credentials in clear text in code" → chuyển ra ngoài, và ĐỔI mật khẩu "KMS to store credentials" → LUÔN SAI, KMS quản lý khoá "KMS automatic key rotation" để đổi mật khẩu CSDL → SAI, xoay vòng thứ khác cần rẻ và không cần xoay vòng → Parameter Store

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xoay vòng có chạy không | describe-secret, xem LastRotatedDate | | Ai đang đọc secret | CloudTrail, sự kiện GetSecretValue | | Hàm có chịu được lúc xoay vòng không | xoay vòng thủ công một lần trong giờ thấp điểm |

Và một lời khuyên: hãy cân nhắc bỏ hẳn mật khẩu bằng RDS IAM authentication, thay vì chỉ chuyển nó sang chỗ lưu tốt hơn. Secrets Manager giải quyết được vấn đề đề nêu, nhưng nó vẫn để lại một bí mật dài hạn tồn tại — và mọi bí mật tồn tại đều có thể bị lộ, bị ghi nhầm vào log, bị in ra trong một thông báo lỗi. Với RDS IAM authentication, Lambda dùng chính IAM role của nó để sinh một token có hạn mười lăm phút; không có chuỗi nào để hard-code, không có gì để xoay vòng, và không có gì để lộ. Đó là loại giải pháp làm cho cả một nhóm sự cố trở nên không thể xảy ra, thay vì làm cho chúng ít xảy ra hơn.

Đáp án

A, D — hai rule cần có trên Network ACL của private subnet:

• D — Rule inbound cho cổng 443 từ nguồn 10.1.0.0/24.
• A — Rule outbound cho dải cổng 1024–65535 tới đích 10.1.0.0/24.

Vì sao đúng

Hai điều quyết định câu trả lời: NACL không có trạng thái, và ALB nằm ở public subnet nên EC2 chỉ nhìn thấy địa chỉ của ALB.

⚠ Điểm mấu chốt: NACL không nhớ kết nối — mỗi chiều phải khai riêng, và chiều về dùng cổng EPHEMERAL:

ALB mở kết nối từ cổng ngẫu nhiên (ví dụ 54321) tới EC2 cổng 443
        ↓
    Chiều vào: nguồn 10.1.0.0/24:54321 → đích EC2:443
        ↓
    Chiều ra: nguồn EC2:443 → đích 10.1.0.0/24:54321
        ↓
    → rule outbound phải cho phép dải cổng ĐÍCH là 1024–65535,
      không phải cổng 443

Đây là khác biệt cốt lõi với security group: security group có trạng thái, tự cho gói trả lời đi ra; NACL thì không.

Vì sao nguồn là 10.1.0.0/24 chứ không phải 0.0.0.0/0. ALB kết thúc kết nối của khách rồi mở một kết nối mới tới target. EC2 trong private subnet không bao giờ thấy IP của khách Internet — nó chỉ thấy địa chỉ riêng của ALB, nằm trong dải public subnet.

# inbound: 443 từ dải public subnet
aws ec2 create-network-acl-entry --network-acl-id acl-private \
  --rule-number 100 --protocol tcp --port-range From=443,To=443 \
  --cidr-block 10.1.0.0/24 --rule-action allow --ingress

# outbound: cổng ephemeral về dải public subnet
aws ec2 create-network-acl-entry --network-acl-id acl-private \
  --rule-number 100 --protocol tcp --port-range From=1024,To=65535 \
  --cidr-block 10.1.0.0/24 --rule-action allow --egress

⚠ Dải cổng ephemeral khác nhau tuỳ hệ điều hành — mở 1024–65535 để phủ hết: | Hệ | Dải | |---|---| | Linux nhân hiện đại | 32768–60999 | | Windows Server mới | 49152–65535 | | ELB | 1024–65535 |

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

• B (rule inbound cho cổng 443 từ nguồn 0.0.0.0/0) — đây là phương án gần nhất và nó đúng ở cổng. Nhưng nguồn quá rộng và không phản ánh luồng thật: lưu lượng tới EC2 trong private subnet luôn đến từ ALB, nên nguồn hợp lệ là dải public subnet. Mở 0.0.0.0/0 trên NACL của private subnet là nới lỏng không cần thiết, và nó cũng không giúp gì vì không có đường nào từ Internet vào thẳng private subnet.

• C (rule outbound cho cổng 443 tới đích 0.0.0.0/0) — sai cổng và sai chiều tư duy. Gói trả lời từ EC2 đi về cổng ephemeral của ALB, không đi tới cổng 443 của một đích nào cả. Rule này cho phép EC2 khởi tạo kết nối HTTPS ra ngoài, một việc khác hẳn với việc trả lời request.

• E (rule outbound cho cổng 443 tới đích 10.1.0.0/24) — đúng đích nhưng sai cổng, cùng lỗi tư duy với C: nhầm cổng dịch vụ với cổng đích của gói trả lời.

Ghi nhớ

⚠ Security group so với NACL — bảng phải thuộc: | | Security group | Network ACL | |---|---|---| | Gắn vào | ENI | subnet | | Trạng thái | CÓ — tự cho gói trả lời | KHÔNG — phải khai cả hai chiều | | Rule | chỉ allow | allow và deny | | Đánh giá | tất cả rule cùng lúc | theo số thứ tự, dừng ở rule khớp đầu tiên | | Nguồn/đích | CIDR, security group khác, prefix list | chỉ CIDR |

Từ khoá nhận diện:

"Network ACL" + cho phép truy cập → luôn cần rule cả hai chiều chiều về của NACL → dải cổng ephemeral 1024–65535 EC2 sau ALB → nguồn là dải subnet của ALB, không phải 0.0.0.0/0 outbound cổng 443 cho gói trả lời → SAI, đó là cổng dịch vụ không phải cổng đích NACL đánh giá theo thứ tự → rule số nhỏ hơn thắng |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gói bị chặn ở đâu | VPC Flow Logs — bản ghi REJECT | | NACL hay security group chặn | Flow Logs ghi cả hai chiều; NACL chặn thì thấy REJECT ở một chiều | | Rule có đúng thứ tự không | describe-network-acls, đọc theo RuleNumber |

Và một lời khuyên: hãy bật VPC Flow Logs trước khi bắt đầu gỡ lỗi NACL, đừng đoán bằng cách đọc lại rule. Lỗi thiếu rule chiều về tạo ra một triệu chứng đặc biệt khó chịu: kết nối được thiết lập một phần rồi treo cho tới khi timeout, và cả hai phía đều không nhận được thông báo gì. Ứng dụng báo lỗi mạng chung chung, ALB báo target unhealthy, và bảng rule NACL khi đọc lướt thì trông hoàn toàn hợp lý vì cái bạn đang tìm là một rule không tồn tại chứ không phải một rule sai. Flow Logs chỉ thẳng vào gói tin bị từ chối, kèm chiều và cổng — và thường kết thúc cuộc điều tra trong hai phút.