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

Đáp án

A — Tạo IAM service role có quyền truy cập bảng DynamoDB, và cấu hình instance profile để gán role đó cho EC2 instance.

Vì sao đúng

Đây là thực hành tốt nhất của AWS, và lý do nằm ở loại thông tin đăng nhập.

Cách IAM role hoạt động với EC2:

Gắn role qua instance profile
    ↓
EC2 tự lấy thông tin đăng nhập TẠM THỜI từ instance metadata
    ↓ SDK và CLI tự tìm thấy, không cần cấu hình
    ↓ tự động GIA HẠN trước khi hết hạn
        ↓
    KHÔNG có access key dài hạn nào tồn tại trên máy

Bốn lợi ích: | Lợi ích | Chi tiết | |---|---| | Thông tin đăng nhập TẠM THỜI | tự hết hạn | | Tự xoay vòng | không ai phải làm gì | | Không có gì để rò rỉ | không nằm trong mã hay tệp | | Sửa quyền tức thì | đổi policy, có hiệu lực ngay |

Cấu hình đầy đủ:

aws iam create-role --role-name vai-tro-ung-dung   --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{
    "Effect":"Allow","Principal":{"Service":"ec2.amazonaws.com"},
    "Action":"sts:AssumeRole"}]}'

aws iam put-role-policy --role-name vai-tro-ung-dung   --policy-name quyen-dynamodb --policy-document '{
    "Version":"2012-10-17","Statement":[{
      "Effect":"Allow",
      "Action":["dynamodb:GetItem","dynamodb:PutItem","dynamodb:Query"],
      "Resource":"arn:aws:dynamodb:ap-northeast-1:123456789012:table/bang-ung-dung"}]}'

aws iam create-instance-profile --instance-profile-name profile-ung-dung
aws iam add-role-to-instance-profile   --instance-profile-name profile-ung-dung --role-name vai-tro-ung-dung

aws ec2 associate-iam-instance-profile --instance-id i-0abc   --iam-instance-profile Name=profile-ung-dung

Và trong mã, không khai gì:

import boto3
bang = boto3.resource('dynamodb').Table('bang-ung-dung')

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

• **C. Tạo IAM service role, rồi thêm EC2 instance vào trust policy để instance đảm nhận role — đây là phương án gần nhất và là bẫy tinh vi: trust policy đúng là nơi khai ai được đảm nhận role, nhưng principal ở đó phải là dịch vụ ec2.amazonaws.com, không phải một instance cụ thể. Và cơ chế gán role cho instance là instance profile, không phải sửa trust policy.
• **B. Tạo IAM user, lưu access key trong S3 bucket và đọc từ mã ứng dụng — vòng luẩn quẩn và không an toàn: để đọc được bucket đó, ứng dụng đã cần thông tin đăng nhập rồi. Và access key dài hạn là thứ nên tránh.
• **D. Tạo IAM user, lưu access key trên đĩa cục bộ — kém nhất: ai đọc được đĩa hoặc chụp được snapshot của volume đều lấy được khoá.

Ghi nhớ

Bốn cơ chế cấp quyền không cần access key — bảng phải thuộc: | Ngữ cảnh | Cơ chế | |---|---| | EC2 | instance profile (IAM role) ← câu này | | ECS | task role | | EKS | IRSA hoặc EKS Pod Identity | | Lambda | execution role | | Máy ngoài AWS | IAM Roles Anywhere | | CI/CD (GitHub Actions) | OIDC federation |

Instance profile là gì:

Instance profile = VỎ BỌC chứa MỘT IAM role
    → EC2 không gắn trực tiếp role được
    → phải qua instance profile
        ↓
    Console tự tạo instance profile khi bạn gắn role
    CLI thì phải tạo tường minh

Ba lưu ý về instance profile: | Lưu ý | Chi tiết | |---|---| | Chứa ĐÚNG MỘT role | không nhiều hơn | | Gắn và đổi được khi instance ĐANG CHẠY | không cần dừng máy | | Một instance chỉ có MỘT role | dùng chung cho mọi ứng dụng trên máy |

Thứ tự SDK tìm thông tin đăng nhập:

① Tham số truyền vào code
② Biến môi trường (AWS_ACCESS_KEY_ID...)
③ Tệp ~/.aws/credentials
④ Container credentials (ECS task role)
⑤ Instance metadata (instance profile)  ← cách đúng

Access key ở tầng cao hơn sẽ THẮNG instance role — nguyên nhân của lỗi "gắn role rồi mà vẫn AccessDenied".

Trust policy của role cho EC2:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Principal": {"Service": "ec2.amazonaws.com"},
   "Action": "sts:AssumeRole"}]}

Principal là DỊCH VỤ, không phải instance cụ thể — đây chính là điểm mà phương án C hiểu sai.

Bảo vệ instance metadata — rất quan trọng:

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

Vì sao IMDSv2 quan trọng:

IMDSv1: GET đơn giản tới 169.254.169.254
    → lỗ hổng SSRF trong ứng dụng web
    → kẻ tấn công lừa máy chủ tự gọi metadata
    → LẤY ĐƯỢC thông tin đăng nhập của role
        ↓
IMDSv2: phải PUT lấy token trước
    → SSRF thông thường không thực hiện được PUT

Ba nguyên tắc cho IAM role của EC2: | Nguyên tắc | Chi tiết | |---|---| | Đặc quyền tối thiểu | chỉ hành động và tài nguyên thật sự cần | | Giới hạn tới ARN cụ thể | không dùng Resource: "*" | | Rà soát bằng Access Advisor | gỡ quyền không dùng |

Ba nơi KHÔNG BAO GIỜ đặt access key:

❌ Trong mã nguồn hoặc kho git
❌ Trên EC2 instance
❌ Trong biến môi trường của container

Ba công cụ phát hiện bí mật bị lộ: | Công cụ | Việc | |---|---| | git-secrets, truffleHog | quét kho mã nguồn | | Amazon CodeGuru Security | phân tích mã | | GuardDuty | phát hiện access key bị dùng bất thường |

Finding của GuardDuty đáng chú ý:

UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration
    → thông tin đăng nhập của EC2 role đang dùng từ NGOÀI AWS
    → dấu hiệu rõ ràng của việc bị đánh cắp

Ba lưu ý về VPC endpoint cho DynamoDB: | Lưu ý | Chi tiết | |---|---| | Gateway endpoint cho DynamoDB MIỄN PHÍ | nên luôn tạo | | Tránh phí NAT Gateway | ~0,045 USD/GB | | Lưu lượng không ra Internet | an toàn hơn |

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc   --service-name com.amazonaws.ap-northeast-1.dynamodb   --route-table-ids rtb-private

Ba cách chẩn đoán khi role không hoạt động:

# Kiểm tra instance profile đã gắn chưa
aws ec2 describe-instances --instance-ids i-0abc   --query 'Reservations[].Instances[].IamInstanceProfile'

# Trên instance: kiểm tra danh tính hiện tại
aws sts get-caller-identity

# Kiểm tra có access key nào che mất role không
env | grep AWS_ ; cat ~/.aws/credentials 2>/dev/null

Và một lời khuyên: hãy chạy aws sts get-caller-identity trên chính instance khi gặp lỗi quyền. Nó cho biết ứng dụng đang chạy dưới danh tính nào — và rất thường là một access key cũ trong biến môi trường đang che mất instance role, chứ không phải policy sai.

Đáp án

B — KHÔNG dùng được Internet Gateway ID làm nguồn tuỳ chỉnh cho inbound rule của security group.

Vì sao đúng

Security group chỉ chấp nhận bốn loại nguồn, và Internet Gateway không nằm trong đó: | Loại nguồn hợp lệ | Ví dụ | |---|---| | Một địa chỉ IP | 203.0.113.45/32 | | Dải CIDR | 10.0.0.0/16 | | Security group khác | sg-0abc123 | | Prefix list | pl-0abc123 |

Vì sao Internet Gateway không dùng được:

Internet Gateway là thành phần ĐỊNH TUYẾN của VPC
    → nó cho phép lưu lượng đi ra và vào Internet
    → nó KHÔNG phải một danh tính hay một dải địa chỉ
        ↓
    Security group lọc theo NGUỒN LƯU LƯỢNG
    → IGW không phải nguồn của lưu lượng nào

Muốn cho phép từ Internet thì dùng 0.0.0.0/0:

aws ec2 authorize-security-group-ingress --group-id sg-web   --protocol tcp --port 443 --cidr 0.0.0.0/0

Và prefix list là loại nguồn thứ tư đáng biết:

aws ec2 create-managed-prefix-list --prefix-list-name ip-van-phong   --max-entries 10 --address-family IPv4   --entries Cidr=203.0.113.0/24,Description=HN Cidr=198.51.100.0/24,Description=HCM

aws ec2 authorize-security-group-ingress --group-id sg-quan-tri   --ip-permissions 'IpProtocol=tcp,FromPort=22,ToPort=22,
    PrefixListIds=[{PrefixListId=pl-0abc123}]'

Sửa danh sách IP ở MỘT chỗ, mọi security group tham chiếu đều cập nhật.

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

• **D. Dùng security group làm nguồn — đây là phương án gần nhất vì nghe có vẻ lạ với người mới, nhưng nó hoàn toàn hợp lệ và là thực hành TỐT NHẤT: tham chiếu security group thay vì CIDR khiến quy tắc tự thích ứng khi ASG tạo instance mới.
• **A. Dùng một địa chỉ IP làm nguồn — hợp lệ, viết dưới dạng /32.
• **C. Dùng dải CIDR làm nguồn — hợp lệ, và là cách phổ biến nhất.

Ghi nhớ

Bốn loại nguồn hợp lệ của security group rule: | Loại | Ví dụ | Dùng khi | |---|---|---| | IP đơn (/32) | 203.0.113.45/32 | một máy cụ thể | | Dải CIDR | 10.0.0.0/16 | một mạng | | Security group | sg-0abc123 | tầng khác trong cùng kiến trúc | | Prefix list | pl-0abc123 | danh sách IP dùng lại nhiều nơi |

Và ba thứ KHÔNG dùng được làm nguồn:

❌ Internet Gateway ID   ← câu này
❌ Instance ID
❌ Route table ID
❌ Tên miền (DNS name)

Dòng cuối cũng hay bị hỏi: security group không hỗ trợ tên miền — muốn cho phép theo tên miền thì phải dùng AWS Network Firewall hoặc giải pháp khác.

Hai loại prefix list: | Loại | Chi tiết | |---|---| | Customer-managed | bạn tự tạo và quản lý | | AWS-managed | AWS duy trì — ví dụ dải IP của S3 và DynamoDB |

AWS-managed prefix list rất hữu ích:

aws ec2 describe-managed-prefix-lists   --filters Name=owner-id,Values=AWS

com.amazonaws.ap-northeast-1.s3        → dải IP của S3
com.amazonaws.ap-northeast-1.dynamodb  → dải IP của DynamoDB
        ↓
    Cho phép outbound tới S3 mà không phải liệt kê hàng trăm dải
    và AWS tự cập nhật khi dải thay đổi

Ba đặc điểm của security group: | Đặc điểm | Chi tiết | |---|---| | CHỈ có quy tắc Allow | không có Deny | | STATEFUL | phản hồi tự động được phép | | Tham chiếu security group khác được | kể cả xuyên tài khoản (trong VPC dùng chung) |

Security group và NACL — bảng phân biệt: | | Security group | Network ACL | |---|---|---| | Phạm vi | ENI | SUBNET | | Quy tắc | chỉ Allow | Allow và Deny | | Trạng thái | stateful | stateless | | Đánh giá | mọi quy tắc | theo số thứ tự, dừng ở quy tắc đầu khớp | | Nguồn | IP, CIDR, SG, prefix list | CHỈ CIDR | | Mặc định | chặn inbound, cho outbound | cho cả hai chiều |

Muốn CHẶN một IP cụ thể thì phải dùng NACL — security group không có quy tắc Deny.

Ba thành phần của một quy tắc: | Thành phần | Chi tiết | |---|---| | Giao thức | TCP, UDP, ICMP, hoặc tất cả | | Dải cổng | ví dụ 443 hoặc 1024–65535 | | Nguồn (inbound) / Đích (outbound) | bốn loại ở trên | | Mô tả | nên điền — giải thích vì sao có quy tắc này |

Trường mô tả rất đáng dùng:

aws ec2 authorize-security-group-ingress --group-id sg-db   --ip-permissions 'IpProtocol=tcp,FromPort=5432,ToPort=5432,
    UserIdGroupPairs=[{GroupId=sg-app,Description="Tang ung dung goi PostgreSQL"}]'

Sau vài tháng, không ai nhớ vì sao có quy tắc nào — mô tả là cách duy nhất giữ lại lý do.

Ba hạn mức của security group: | Hạn mức | Giá trị | |---|---| | Quy tắc mỗi SG | 60 inbound + 60 outbound (nâng được) | | SG mỗi ENI | 5 (nâng tối đa 16) | | SG mỗi VPC | 2.500 |

Lưu ý về cách đếm với prefix list:

Một quy tắc tham chiếu prefix list
    → tính bằng SỐ MỤC TỐI ĐA của prefix list đó
        ↓
    Prefix list max-entries = 50
    → chiếm 50 slot trong hạn mức quy tắc

Ba nguyên tắc thiết kế: | Nguyên tắc | Chi tiết | |---|---| | Một SG cho mỗi TẦNG | dễ quản lý | | Tham chiếu SG thay vì CIDR | an toàn hơn và tự thích ứng | | Chỉ mở cổng thật sự cần | không mở dải rộng |

Ba công cụ kiểm tra: | Công cụ | Việc | |---|---| | VPC Reachability Analyzer | kiểm tra đường đi giữa hai tài nguyên | | VPC Flow Logs | thấy lưu lượng bị từ chối | | AWS Config rule | phát hiện SG mở quá rộng |

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "khong-mo-ssh-ra-internet",
  "Source": {"Owner":"AWS",
             "SourceIdentifier":"INCOMING_SSH_DISABLED"}}'

Và một lời khuyên: hãy dùng prefix list cho danh sách IP văn phòng và VPN. Khi công ty mở thêm chi nhánh hoặc đổi nhà cung cấp Internet, bạn sửa một prefix list thay vì đi tìm hàng chục security group — và không sót cái nào.

Đáp án

C — Provisioned IOPS SSD (io1).

Vì sao đúng

Đề cho một con số quyết định: cần tới 25.000 IOPS mỗi volume.

So với trần IOPS của từng loại volume:
    gp2:  16.000  → KHÔNG ĐỦ
    gp3:  16.000  → KHÔNG ĐỦ
    io1:  64.000  → ĐỦ ✓
    st1:  500     → không phải loại này
    sc1:  250     → không phải loại này

Và đề còn nêu hai đặc điểm khác cùng dẫn tới io1: | Đặc điểm trong đề | Kết luận | |---|---| | Tải nặng I/O (I/O intensive) | cần IOPS cao → SSD | | Tải nặng thông lượng | io1 cho tới 1.000 MB/giây | | NoSQL database | truy cập ngẫu nhiên → SSD, không phải HDD |

Cấu hình io1:

aws ec2 create-volume --volume-type io1 --size 500 --iops 25000   --availability-zone ap-northeast-1a --encrypted

Và có ràng buộc tỷ lệ IOPS trên dung lượng:

io1: tối đa 50 IOPS mỗi GiB
    → muốn 25.000 IOPS cần ít nhất 500 GiB
        ↓
    Cấp volume nhỏ hơn sẽ không đạt được IOPS mong muốn

Bảng tỷ lệ của các loại SSD: | Loại | Tỷ lệ IOPS/GiB | IOPS tối đa | |---|---|---| | gp2 | 3 (burst 3.000) | 16.000 | | gp3 | 500 | 16.000 | | io1 | 50 | 64.000 | | io2 | 500 | 64.000 | | io2 Block Express | 1.000 | 256.000 |

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

• **D. General Purpose SSD (gp2) — đây là phương án gần nhất và cũng là SSD phù hợp cho truy cập ngẫu nhiên, nhưng nó không đạt được 25.000 IOPS: trần của gp2 là 16.000 IOPS, thấp hơn yêu cầu.
• **A. Throughput Optimized HDD (st1) — sai công nghệ: đây là đĩa từ, tối ưu cho thông lượng TUẦN TỰ, tối đa chỉ 500 IOPS. Database NoSQL truy cập ngẫu nhiên sẽ chạy rất chậm.
• **B. Cold HDD (sc1) — tệ hơn nữa: tối đa 250 IOPS, dành cho dữ liệu lạnh truy cập rất thưa.

Ghi nhớ

Các loại EBS volume — bảng phải thuộc: | Loại | Công nghệ | IOPS tối đa | Thông lượng tối đa | Boot | |---|---|---|---|---| | gp3 | SSD | 16.000 | 1.000 MB/giây | ✅ | | gp2 | SSD | 16.000 | 250 MB/giây | ✅ | | io1 | SSD | 64.000 | 1.000 MB/giây | ✅ | | io2 | SSD | 64.000 | 1.000 MB/giây | ✅ | | io2 Block Express | SSD | 256.000 | 4.000 MB/giây | ✅ | | st1 | HDD | 500 | 500 MB/giây | ❌ | | sc1 | HDD | 250 | 250 MB/giây | ❌ |

Hai dòng cuối: HDD KHÔNG làm boot volume được — chi tiết hay bị hỏi.

Quy tắc chọn loại volume:

① Cần IOPS trên 16.000?
      Có → io1, io2, hoặc io2 Block Express
      Không → gp3 (rẻ hơn)

② Truy cập TUẦN TỰ khối lớn, chi phí quan trọng?
      → st1 (nóng) hoặc sc1 (lạnh)

③ Còn lại → gp3

gp3 là mặc định đúng cho hầu hết trường hợp: | Ưu điểm | Chi tiết | |---|---| | IOPS và thông lượng khai RIÊNG với dung lượng | không phải mua dung lượng thừa | | 3.000 IOPS và 125 MB/giây MIỄN PHÍ | ở mọi kích thước | | Rẻ hơn gp2 khoảng 20% | |

Chuyển gp2 sang gp3 là tối ưu dễ nhất:

aws ec2 modify-volume --volume-id vol-0abc --volume-type gp3

Một lệnh, không gián đoạn, giảm ngay chi phí.

io1 và io2 — bảng phân biệt: | | io1 | io2 | |---|---|---| | Tỷ lệ IOPS/GiB | 50 | 500 | | Độ bền | 99,8–99,9% | 99,999% | | Giá | tương đương | giống io1 nhưng bền hơn | | Khuyến nghị | — | dùng io2 thay io1 cho volume mới |

io2 có độ bền cao gấp 100 lần io1 với giá tương đương — nên chọn io2 cho mọi volume mới.

Ba lưu ý về IOPS thực tế: | Lưu ý | Chi tiết | |---|---| | Loại instance cũng có trần IOPS | volume nhanh nhưng instance nhỏ thì không đạt được | | Cần instance EBS-optimized | hầu hết thế hệ mới bật mặc định | | IOPS đo với block 16 KB | block lớn hơn thì số IOPS giảm |

Dòng đầu rất quan trọng:

aws ec2 describe-instance-types --instance-types r5.4xlarge   --query 'InstanceTypes[].EbsInfo.EbsOptimizedInfo'

Cấp volume 25.000 IOPS nhưng instance chỉ chịu 18.750
    → thực tế chỉ đạt 18.750
    → trả tiền cho IOPS không dùng được

Ba lựa chọn cho NoSQL trên EC2: | Lựa chọn | Đặc điểm | |---|---| | io2 với IOPS cấp phát | bền vững, snapshot được ← câu này | | Instance store NVMe | IOPS cao nhất, MIỄN PHÍ, nhưng KHÔNG bền | | gp3 | rẻ hơn nếu dưới 16.000 IOPS |

Instance store đáng cân nhắc cho NoSQL:

Cassandra, MongoDB, Elasticsearch:
    → TỰ sao chép dữ liệu giữa các node
    → độ bền của từng ổ đĩa là dư thừa
        ↓
    Instance store NVMe: hàng triệu IOPS, không tốn thêm tiền

Ba đặc điểm căn bản của EBS: | Đặc điểm | Chi tiết | |---|---| | Gắn với MỘT Availability Zone | chuyển AZ phải qua snapshot | | Bền vững độc lập với instance | trừ khi DeleteOnTermination = true | | Snapshot có phạm vi Region | sao chép chéo Region được |

Ba lưu ý về multi-attach: | Lưu ý | Chi tiết | |---|---| | Chỉ io1 và io2 | gp3 KHÔNG hỗ trợ | | Tối đa 16 instance trong CÙNG AZ | | | Cần hệ thống tệp hỗ trợ truy cập đồng thời | ext4 hay XFS thông thường sẽ HỎNG DỮ LIỆU |

Ba cách tối ưu chi phí EBS: | Cách | Tiết kiệm | |---|---| | Chuyển gp2 sang gp3 | ~20% | | Xoá volume mồ côi | volume available vẫn tính tiền | | Dọn snapshot cũ bằng Data Lifecycle Manager | |

aws ec2 describe-volumes --filters Name=status,Values=available   --query 'Volumes[].{Id:VolumeId,GB:Size,Tao:CreateTime}' --output table

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | VolumeReadOps và VolumeWriteOps | IOPS thực tế | | VolumeQueueLength | cao liên tục = volume là nút thắt | | BurstBalance | chỉ với gp2, hết credit thì tụt về baseline |

Và một lời khuyên: hãy đo IOPS thực tế bằng CloudWatch trong một tuần trước khi chốt con số cấp phát. IOPS cấp phát tính tiền dù có dùng hay không, và với io1 ở mức 25.000, khoản đó là đáng kể — nhiều tải thực tế hoá ra chỉ cần một phần con số ước lượng ban đầu.

Đáp án

D — Dùng Amazon EFS với chế độ Provisioned Throughput.

Vì sao đúng

Đề nêu ba yêu cầu, và EFS với thông lượng cấp phát là lựa chọn đúng theo cách phân loại của bộ đề: | Yêu cầu | Cơ chế | |---|---| | HÀNG TRĂM task truy cập đồng thời | EFS — hàng nghìn client mount cùng lúc | | Đọc ghi TẦN SUẤT CAO | thông lượng cấp phát đảm bảo mức ổn định | | Dung lượng không quá 1 TB | EFS tự co giãn |

Vì sao phải là EFS chứ không phải EBS:

Hàng trăm task ECS trên nhiều EC2 instance
    → cần kho DÙNG CHUNG
        ↓
    EBS gắn với MỘT instance
    → task trên máy khác không thấy dữ liệu

Và vì sao Provisioned thay vì Bursting:

Chế độ Bursting:
    → thông lượng cơ sở = 50 KB/giây MỖI GiB lưu trữ
    → với 1 TB (1.024 GiB): baseline ~50 MB/giây
    → burst cao hơn nhưng TIÊU CREDIT
        ↓
    Đọc ghi tần suất cao liên tục → HẾT CREDIT
    → tụt về baseline → CHẬM ĐỘT NGỘT

Chế độ Provisioned:
    → khai thông lượng cố định, không phụ thuộc dung lượng
    → KHÔNG có credit để hết
    → hiệu năng ổn định và dự đoán được

aws efs create-file-system   --throughput-mode provisioned   --provisioned-throughput-in-mibps 512   --performance-mode generalPurpose --encrypted

Và mount vào ECS task:

{"volumes": [{"name": "du-lieu",
  "efsVolumeConfiguration": {
    "fileSystemId": "fs-0abc123",
    "transitEncryption": "ENABLED",
    "authorizationConfig": {"accessPointId": "fsap-0abc"}}}],
 "containerDefinitions": [{
   "name": "tac-vu",
   "mountPoints": [{"sourceVolume": "du-lieu", "containerPath": "/du-lieu"}]}]}

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

• **B. EFS với Bursting Throughput — đây là phương án gần nhất và cùng dịch vụ, cùng kiến trúc, nhưng nó không đảm bảo hiệu năng ổn định: với 1 TB dữ liệu, baseline chỉ khoảng 50 MB/giây, và tải đọc ghi tần suất cao sẽ tiêu hết burst credit rồi tụt xuống mức đó.
• **C. Dùng EBS volume gắn vào các instance của cụm ECS — không chia sẻ được: mỗi EBS gắn với một instance, nên task trên máy khác không thấy dữ liệu của nhau.
• **A. Dùng DynamoDB cho mọi instance truy cập — sai loại dữ liệu: mỗi task sinh khoảng 20 MB dữ liệu, vượt xa giới hạn 400 KB mỗi item của DynamoDB.

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

Câu này phản ánh cách phân loại trước khi có Elastic throughput, và lời khuyên hiện hành của AWS đã đổi.

Từ năm 2023, EFS có chế độ Elastic throughput và AWS đặt nó làm mặc định được khuyến nghị: | Chế độ | Đặc điểm | |---|---| | Elastic (mặc định mới) | tự co giãn tới hàng GB/giây, trả theo lượng dùng THẬT | | Provisioned | khai trước, tính phí DÙ KHÔNG DÙNG | | Bursting | theo dung lượng, có credit |

Elastic throughput:
    ✓ không có credit để hết
    ✓ không phải đoán trước mức thông lượng
    ✓ chỉ trả cho dữ liệu đọc ghi thật
        ↓
    Với tải biến động như "hàng trăm task chạy lúc có lúc không",
    Elastic thường RẺ HƠN Provisioned đáng kể

AWS khuyến nghị Provisioned chỉ khi biết rõ mức thông lượng cần và nó cao hơn đáng kể so với mức Elastic sẽ tự cấp — một trường hợp khá hẹp.

(Đáp án D vẫn đúng theo các phương án cho sẵn: trong hai chế độ được nêu, Provisioned là chế độ đảm bảo hiệu năng ổn định, còn Bursting thì không.)

Ghi nhớ

Ba chế độ thông lượng của EFS: | Chế độ | Cách tính | |---|---| | Elastic | theo lượng dữ liệu đọc ghi thật | | Provisioned | theo MB/giây khai trước, tính phí liên tục | | Bursting | theo dung lượng lưu trữ, có credit |

Công thức của chế độ Bursting:

Baseline = 50 KB/giây × số GiB lưu trữ
Burst    = 100 MB/giây × số TiB (tối thiểu 100 MB/giây)
    ↓
    File system 100 GiB → baseline chỉ 5 MB/giây

Đây là lý do Bursting không phù hợp với tải đọc ghi liên tục.

Metric quan trọng với chế độ Bursting:

BurstCreditBalance
    → giảm dần khi vượt baseline
    → về 0 → thông lượng tụt về baseline
        ↓
    Phải đặt alarm cho metric này

Hai chế độ hiệu năng (khác với chế độ thông lượng): | Chế độ | Đặc điểm | |---|---| | General Purpose (mặc định) | độ trễ thấp nhất — dùng cho hầu hết trường hợp | | Max I/O | thông lượng cao hơn nhưng độ trễ cao hơn |

Nhầm lẫn giữa "performance mode" và "throughput mode" là bẫy phổ biến — chúng là hai cấu hình độc lập.

Ba lớp lưu trữ của EFS: | Lớp | Giá tham khảo | |---|---| | Standard | ~0,30 USD/GB-tháng | | Standard-IA | ~0,025 USD/GB-tháng | | Archive | ~0,008 USD/GB-tháng | | One Zone (và IA) | rẻ hơn ~47% |

Và lifecycle tự phân tầng:

aws efs put-lifecycle-configuration --file-system-id fs-0abc   --lifecycle-policies '[{"TransitionToIA":"AFTER_30_DAYS"},
                         {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'

Ba lựa chọn lưu trữ chia sẻ cho ECS: | Lựa chọn | Đặc điểm | |---|---| | EFS | NFS, nhiều task mount cùng lúc ← câu này | | FSx for Lustre | thông lượng cao nhất, cho HPC | | S3 | object, không mount được như hệ thống tệp |

Ba yêu cầu để mount EFS vào ECS task: | Yêu cầu | Chi tiết | |---|---| | Task định nghĩa efsVolumeConfiguration | | | Security group cho phép cổng 2049 | từ task tới mount target | | Mount target ở mọi AZ có task chạy | tránh phí chéo AZ |

Và EFS Access Point nên dùng:

aws efs create-access-point --file-system-id fs-0abc   --posix-user Uid=1001,Gid=1001   --root-directory 'Path=/tac-vu,CreationInfo={OwnerUid=1001,OwnerGid=1001,Permissions=755}'

Ba lưu ý về hiệu năng khi nhiều task cùng ghi: | Lưu ý | Chi tiết | |---|---| | Thông lượng CHIA SẺ giữa mọi client | | | Dùng nconnect để tăng thông lượng mỗi client | | | Ghi tệp lớn hiệu quả hơn nhiều tệp nhỏ | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | PercentIOLimit | gần 100% = chạm trần chế độ hiệu năng | | MeteredIOBytes | thông lượng thực tế | | BurstCreditBalance | chỉ với chế độ Bursting |

Ba cách giảm chi phí EFS: | Cách | Tiết kiệm | |---|---| | Chuyển sang Elastic throughput | không trả cho thông lượng không dùng | | Lifecycle sang IA | ~90% cho dữ liệu cũ | | One Zone cho dữ liệu tái tạo được | ~47% |

Và một lời khuyên: hãy đo thông lượng thực tế bằng metric MeteredIOBytes trong vài tuần rồi so với mức Provisioned đang trả. Với tải theo đợt như task ECS, rất thường xảy ra tình huống bạn trả tiền cho 512 MB/giây suốt tháng trong khi mức dùng trung bình chỉ bằng một phần nhỏ — và Elastic throughput sẽ rẻ hơn hẳn.

Đáp án

A — Tạo read replica và trỏ công cụ tạo báo cáo vào đó.

Vì sao đúng

Đề cho một dữ kiện quan trọng: CPU, bộ nhớ và lưu trữ đều chỉ ở mức 50%.

Tài nguyên còn dư một nửa
    → nút thắt KHÔNG phải do thiếu năng lực
        ↓
    Vấn đề là truy vấn báo cáo NẶNG cạnh tranh tài nguyên
    với truy vấn của ứng dụng sản xuất

Và read replica tách hoàn toàn hai loại tải:

Trước:
    Ứng dụng ────┐
                 ├──▶ MỘT instance database
    Báo cáo ─────┘    (tranh nhau I/O, khoá, bộ nhớ đệm)

Sau:
    Ứng dụng ──▶ primary
    Báo cáo  ──▶ read replica (instance RIÊNG)
        ↓
    Truy vấn báo cáo KHÔNG ảnh hưởng ứng dụng

Và vì sao đây là cách tiết kiệm nhất trong các phương án: | Phương án | Chi phí | |---|---| | Read replica | thêm một instance, dùng đúng mục đích | | Tăng cỡ instance | đắt hơn và không giải quyết việc tranh chấp |

Tạo read replica:

aws rds create-db-instance-read-replica   --db-instance-identifier replica-bao-cao   --source-db-instance-identifier db-san-xuat   --db-instance-class db.r5.2xlarge

Và ứng dụng báo cáo trỏ vào endpoint riêng:

ket_noi_bao_cao = connect(host='replica-bao-cao.abc123.rds.amazonaws.com')

Với báo cáo, độ trễ sao chép vài giây là hoàn toàn chấp nhận được — báo cáo nghiệp vụ không cần dữ liệu của mili giây trước.

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

• **B. Tăng cỡ instance RDS — đây là phương án gần nhất và có thể giảm triệu chứng, nhưng nó không giải quyết nguyên nhân: hai loại tải vẫn cạnh tranh trên cùng một máy. Và đề nói rõ tài nguyên mới dùng 50%, nên thêm CPU và bộ nhớ chưa chắc giúp gì — vấn đề nằm ở tranh chấp I/O và khoá.
• **D. Chuyển sang Multi-AZ và trỏ công cụ báo cáo vào instance ở AZ khác — không làm được về mặt kỹ thuật: standby của Multi-AZ KHÔNG truy cập được, nó chỉ tồn tại để chuyển đổi.
• **C. Chuyển từ gp2 sang magnetic storage để tăng IOPS — đi ngược hoàn toàn: magnetic (standard) là loại lưu trữ cũ nhất với IOPS thấp nhất. Nó làm chậm đi chứ không nhanh hơn.

Ghi nhớ

Multi-AZ và Read Replica — bảng phải thuộc: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | MỞ RỘNG ĐỌC ← câu này | | Sao chép | đồng bộ | bất đồng bộ | | Chuyển đổi | tự động | thủ công (promote) | | Standby phục vụ đọc | ❌ (Multi-AZ instance) | ✅ | | Phạm vi | cùng Region | cùng hoặc khác Region |

Từ khoá nhận diện:

"reporting queries slow down production", "scale reads" → Read replica "high availability", "automatic failover" → Multi-AZ "analytics on separate infrastructure" → Read replica hoặc kho dữ liệu riêng

Ba cách giảm tải đọc cho database — theo thứ tự nên thử: | Thứ tự | Cách | |---|---| | ① | Tối ưu truy vấn và index — rẻ nhất, thường hiệu quả nhất | | ② | Đệm kết quả hay dùng (ElastiCache) | | ③ | Thêm read replica |

Thêm replica cho một truy vấn thiếu index chỉ là trả tiền để chạy nhanh hơn một chút cái vốn sai.

Ba lưu ý về read replica: | Lưu ý | Chi tiết | |---|---| | CHỈ ĐỌC | ứng dụng phải tách đường ghi | | Có ĐỘ TRỄ sao chép | không dùng cho đọc-sau-ghi | | Promote là KHÔNG đảo ngược | thành instance độc lập |

Và metric cần theo dõi:

ReplicaLag (giây)
    → tăng dần = replica không theo kịp
    → thường do replica NHỎ HƠN primary
      hoặc truy vấn báo cáo quá nặng

Ba cấu hình cho replica dùng làm báo cáo: | Cấu hình | Chi tiết | |---|---| | Cỡ instance ĐỦ LỚN | báo cáo là truy vấn nặng | | Tham số riêng nếu cần | ví dụ work_mem lớn hơn cho PostgreSQL | | Có thể ở AZ khác | không ảnh hưởng gì |

Ba lựa chọn tách tải báo cáo: | Lựa chọn | Phù hợp | |---|---| | Read replica | báo cáo trên dữ liệu giao dịch ← câu này | | Kho dữ liệu (Redshift) | báo cáo phức tạp trên khối lượng lớn | | Xuất sang S3 + Athena | báo cáo ad-hoc, chi phí thấp |

Với truy vấn nhiều JOIN phức tạp như đề mô tả, Redshift có thể là hướng dài hạn:

Redshift là kiến trúc MPP, lưu trữ theo CỘT
    → tối ưu cho truy vấn tổng hợp và JOIN lớn
    → nhanh hơn database giao dịch rất nhiều cho loại tải này

(Không nằm trong các phương án; read replica là bước đúng và rẻ nhất trước mắt.)

Ba đặc điểm của Aurora khiến nó tốt hơn cho tình huống này: | | RDS read replica | Aurora replica | |---|---|---| | Sao chép | tầng database | tầng LƯU TRỮ | | Độ trễ | giây | thường dưới 100ms | | Số lượng | 5 | 15 | | Tạo replica mới | tốn thời gian sao chép | rất nhanh | | Custom endpoint | ❌ | ✅ tách nhóm replica cho báo cáo |

Custom endpoint của Aurora rất phù hợp:

aws rds create-db-cluster-endpoint --db-cluster-identifier cum   --db-cluster-endpoint-identifier bao-cao --endpoint-type READER   --static-members replica-bao-cao-lon

Reader endpoint  → replica nhỏ cho ứng dụng
Custom endpoint  → replica LỚN cho báo cáo
    ↓
    Hai loại tải hoàn toàn tách biệt

Ba công cụ chẩn đoán hiệu năng RDS: | Công cụ | Việc | |---|---| | Performance Insights | truy vấn nào tốn tài nguyên nhất, đang chờ ở đâu | | Enhanced Monitoring | metric hệ điều hành chi tiết | | Slow query log | truy vấn vượt ngưỡng thời gian |

Performance Insights là công cụ nên bật đầu tiên:

Nó cho biết:
    ✓ top truy vấn theo tải database
    ✓ đang chờ ở đâu (I/O, khoá, CPU)
    ✓ so sánh theo thời gian
        ↓
    Thường tìm ra một hai truy vấn chiếm phần lớn tải

Ba loại lưu trữ của RDS — nhắc lại vì phương án C nhắc tới magnetic: | Loại | Trạng thái | |---|---| | gp3 | khuyến nghị — IOPS khai riêng | | gp2 | phổ biến, IOPS gắn với dung lượng | | io1/io2 | IOPS cấp phát cao | | magnetic (standard) | CŨ, không dùng cho hệ thống mới |

Và một lời khuyên: hãy bật Performance Insights trước khi tạo replica. Nếu vấn đề thực sự là hai ba truy vấn thiếu index, việc thêm index sẽ giải quyết triệt để mà không tốn thêm một instance nào — và bạn sẽ biết điều đó trong vài phút thay vì sau khi đã trả tiền cho replica cả tháng.

Đáp án

A — Dùng Amazon ECS với Fargate launch type; cấp phát EFS file system và mount volume EFS vào container lúc chạy để có lưu trữ bền vững.

Vì sao đúng

Đề nêu ba yêu cầu, và đáp án thoả cả ba: | Yêu cầu | Cơ chế | |---|---| | Ứng dụng container hoá (Docker) | ECS chạy container image nguyên trạng | | Cần lưu trữ BỀN VỮNG | EFS — dữ liệu tồn tại độc lập với task | | KHÔNG quản lý EC2, volume hay máy chủ | Fargate + EFS đều được quản lý hoàn toàn |

Vì sao Fargate + EFS là kết hợp đúng:

Fargate:
    ✓ không có EC2 nào để cấp phát hay vá lỗi
    ✓ mỗi task có vCPU và bộ nhớ riêng
    ✓ tự co giãn

EFS:
    ✓ không có volume nào để cấp phát
    ✓ tự co giãn dung lượng
    ✓ dữ liệu tồn tại khi task khởi động lại

Và EFS là lựa chọn lưu trữ DUY NHẤT của Fargate:

Fargate KHÔNG mount được:
    ✗ EBS volume
    ✗ hostPath
    ✗ instance store
        ↓
    Chỉ có: ephemeral storage (mất khi task dừng) và EFS

Cấu hình task definition:

{"family": "phan-tich-rui-ro",
 "requiresCompatibilities": ["FARGATE"],
 "networkMode": "awsvpc",
 "cpu": "2048", "memory": "4096",
 "volumes": [{"name": "du-lieu-mo-phong",
   "efsVolumeConfiguration": {
     "fileSystemId": "fs-0abc123",
     "transitEncryption": "ENABLED",
     "authorizationConfig": {"accessPointId": "fsap-0abc", "iam": "ENABLED"}}}],
 "containerDefinitions": [{
   "name": "cong-cu-rui-ro",
   "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/rui-ro:latest",
   "mountPoints": [{"sourceVolume": "du-lieu-mo-phong",
                    "containerPath": "/du-lieu"}]}]}

Và vì ứng dụng tại chỗ vốn mount volume cục bộ vào /du-lieu, việc chuyển sang EFS gần như không đòi sửa mã.

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

• **B. Dùng EKS với managed node group, cấp EBS volume và mount qua PersistentVolume, quản lý vòng đời lưu trữ thủ công — đây là phương án gần nhất và hoàn toàn hoạt động được, nhưng nó vi phạm yêu cầu rõ ràng nhất: managed node group vẫn là EC2 instance bạn phải quản lý, và phương án nêu thẳng "manage storage lifecycle manually" — đúng thứ đội ngũ muốn tránh.
• **D. ECS Fargate nhưng gắn S3 bucket bằng script mount — không phải cách được hỗ trợ: S3 là kho object, mount nó thành hệ thống tệp bằng công cụ như s3fs là giải pháp chắp vá, hiệu năng kém và không có ngữ nghĩa POSIX đầy đủ. Fargate cũng không cho chạy script cần quyền đặc biệt để mount.
• **C. Dùng Lambda với container image, lưu trạng thái trong /tmp rồi đồng bộ với S3 định kỳ — không bền vững: /tmp mất khi môi trường thực thi bị thu hồi, và đồng bộ định kỳ nghĩa là mất dữ liệu giữa hai lần đồng bộ. Và Lambda có giới hạn 15 phút.

Ghi nhớ

Ba lựa chọn lưu trữ của ECS Fargate: | Lựa chọn | Bền vững | Chi tiết | |---|---|---| | Ephemeral storage | ❌ mất khi task dừng | 20–200 GB | | Amazon EFS | ✅ | lựa chọn bền vững DUY NHẤT ← câu này | | Bind mount giữa container trong task | ❌ | chia sẻ trong task |

Và ECS trên EC2 có thêm lựa chọn: | Lựa chọn | Chi tiết | |---|---| | Docker volume trên host | gắn với instance | | EBS volume | gắn với task từ 2024 (ECS on EC2 và Fargate) | | Bind mount hostPath | |

(ECS hiện hỗ trợ gắn EBS volume cho task, nhưng EFS vẫn là lựa chọn chuẩn cho dữ liệu chia sẻ và bền vững.)

Ba hạn chế của Fargate cần biết: | Hạn chế | Chi tiết | |---|---| | Không mount hostPath hay instance store | chỉ EFS | | Không dùng được GPU | | | Không hỗ trợ mọi tính năng mạng của EC2 | ví dụ một số chế độ networkMode | | Tài nguyên tối đa | 16 vCPU, 120 GB bộ nhớ |

Ba cấu hình EFS cho Fargate: | Cấu hình | Chi tiết | |---|---| | transitEncryption: ENABLED | mã hoá đường truyền — nên bật | | authorizationConfig.accessPointId | ép POSIX user và thư mục gốc | | authorizationConfig.iam: ENABLED | dùng task role để xác thực |

Và EFS Access Point rất đáng dùng:

aws efs create-access-point --file-system-id fs-0abc   --posix-user Uid=1001,Gid=1001   --root-directory 'Path=/rui-ro,CreationInfo={OwnerUid=1001,OwnerGid=1001,Permissions=755}'

Ba yêu cầu mạng: | Yêu cầu | Chi tiết | |---|---| | Security group cho phép cổng 2049 | từ task tới mount target | | Mount target ở mọi AZ có task chạy | tránh phí chéo AZ | | Task cần đường ra để kéo image từ ECR | NAT Gateway hoặc VPC endpoint |

Dòng cuối là chi tiết vận hành hay bị quên — Fargate task ở private subnet cần VPC endpoint cho ECR, S3 và CloudWatch Logs, hoặc NAT Gateway.

Ba VPC endpoint cần cho Fargate ở private subnet:

com.amazonaws.<region>.ecr.api
com.amazonaws.<region>.ecr.dkr
com.amazonaws.<region>.logs
+ gateway endpoint cho S3 (ECR lưu layer trong S3)

ECS và EKS — bảng phân biệt: | | Amazon ECS | Amazon EKS | |---|---|---| | Độ phức tạp | thấp hơn, riêng của AWS | Kubernetes chuẩn | | Chi phí control plane | MIỄN PHÍ | ~73 USD/tháng mỗi cụm | | Hệ sinh thái | AWS | Kubernetes rộng lớn | | Phù hợp | mới lên đám mây, muốn đơn giản | đã dùng Kubernetes |

Với công ty chỉ chạy Docker trên một máy như trong đề, ECS đơn giản hơn nhiều.

Ba chế độ tính toán của ECS: | Chế độ | Bạn quản lý | |---|---| | Fargate | KHÔNG có máy nào ← câu này | | EC2 launch type | instance, AMI, vá lỗi | | ECS Anywhere | máy chủ của bạn |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Fargate | theo vCPU-giờ và GB-giờ của task | | EFS | theo GB lưu trữ + thông lượng | | Fargate Spot | giảm tới 70% cho tải chịu được gián đoạn |

Ba việc nên làm khi chuyển từ Docker tại chỗ: | Việc | Chi tiết | |---|---| | Đẩy image lên ECR | | | Chuyển dữ liệu hiện có lên EFS | DataSync hoặc sao chép trực tiếp | | Kiểm chứng ứng dụng hoạt động với EFS | độ trễ NFS khác đĩa cục bộ |

Dòng cuối đáng lưu ý: ứng dụng tối ưu cho đĩa cục bộ có thể chậm hơn trên NFS, nhất là khi thao tác với nhiều tệp nhỏ.

Và một lời khuyên: hãy đo hiệu năng I/O sau khi chuyển sang EFS và so với đĩa cục bộ tại chỗ. Với công cụ phân tích rủi ro ghi nhiều tệp kết quả mô phỏng, độ trễ của NFS có thể là khác biệt đáng kể — và nếu có, cân nhắc chế độ Elastic throughput hoặc gộp kết quả thành ít tệp lớn hơn.

Đáp án

A — Tạo FSx for Lustre file system và nhập 150 TB dữ liệu vào đó; mount file system lên các node HPC để có truy cập độ trễ thấp và thông lượng cao.

Vì sao đúng

Đề nêu bốn yêu cầu về hiệu năng, và FSx for Lustre là dịch vụ duy nhất đáp ứng: | Yêu cầu | Cơ chế | |---|---| | Độ trễ DƯỚI MILI GIÂY | Lustre — hệ thống tệp song song hiệu năng cao | | Thông lượng cao | hàng trăm GB/giây | | Truy cập tệp SONG SONG và NHANH | thiết kế cho HPC | | Dữ liệu ảnh sonar khối lượng lớn | mở rộng tới hàng PB |

Lustre là gì:

Hệ thống tệp SONG SONG mã nguồn mở
    → dùng trong siêu máy tính hàng chục năm
    → thông lượng hàng trăm GB/giây
    → hàng triệu IOPS
    → độ trễ DƯỚI MILI GIÂY
        ↓
    AWS nêu đích danh HPC và phân tích địa không gian
    là trường hợp dùng của FSx for Lustre

Cấu hình:

aws fsx create-file-system --file-system-type LUSTRE   --storage-capacity 153600 --storage-type SSD   --subnet-ids subnet-a   --lustre-configuration '{
    "DeploymentType": "PERSISTENT_2",
    "PerUnitStorageThroughput": 1000,
    "DataCompressionType": "LZ4"}'

Và mount trên node HPC:

sudo amazon-linux-extras install -y lustre
sudo mount -t lustre fs-0abc123.fsx.ap-northeast-1.amazonaws.com@tcp:/abc123 /du-lieu

Vì sao không dùng EFS cho HPC:

EFS là NFS:
    → mỗi thao tác tệp là một vòng lượt mạng
    → thông lượng thấp hơn Lustre hàng chục lần
    → KHÔNG đạt được độ trễ dưới mili giây

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

• **B. Nhập dữ liệu vào S3, tạo FSx for Lustre LIÊN KẾT với bucket S3, rồi mount lên node HPC — đây là phương án gần nhất và là mẫu kiến trúc rất phổ biến, nhưng nó thêm độ trễ ở lần đọc đầu tiên: Lustre liên kết S3 dùng lazy loading — tệp chỉ được nạp từ S3 khi được đọc lần đầu, và lần đọc đó chậm hơn nhiều so với dưới mili giây. Với yêu cầu độ trễ chặt như đề nêu, dữ liệu cần nằm sẵn trong Lustre.
• **C. Nhập vào S3, dùng FSx for NetApp ONTAP đồng bộ với bucket — sai dịch vụ cho HPC: ONTAP là hệ thống tệp doanh nghiệp đa giao thức (NFS, SMB, iSCSI), không phải hệ thống tệp song song. Nó không đạt được thông lượng của Lustre.
• **D. Sao chép vào S3 rồi chuyển sang EFS — hiệu năng thấp nhất: EFS là NFS, không phù hợp cho tải HPC cần truy cập song song hàng trăm node.

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

Có một chi tiết trong đáp án A không khớp với cách AWS Snowball thực sự hoạt động.

AWS Snowball Edge import job:
    → đích LUÔN LÀ Amazon S3
    → KHÔNG có tuỳ chọn nhập thẳng vào FSx for Lustre

Nói cách khác, quy trình thật bắt buộc phải đi qua S3, và phương án B mô tả đúng luồng được hỗ trợ. Điều mà đáp án A muốn nhấn mạnh — dữ liệu nằm sẵn trong Lustre thay vì lazy-load từ S3 — vẫn đạt được trong luồng của B bằng cách nạp trước (preload):

# Nạp trước toàn bộ dữ liệu từ S3 vào Lustre
sudo lfs hsm_restore /du-lieu/**/*

Hoặc dùng data repository task để nạp theo danh sách.

Vậy nên hiểu câu này thế nào: đáp án A đúng về kết luận kỹ thuật (FSx for Lustre là hệ thống tệp phù hợp, và dữ liệu nên nằm trong Lustre để đạt độ trễ dưới mili giây), nhưng cách diễn đạt "nhập trực tiếp từ Snowball vào Lustre" không phản ánh quy trình thật. Trong thực tế, hãy làm theo B rồi nạp trước.

Ghi nhớ

Bốn dịch vụ FSx — bảng phải thuộc: | Dịch vụ | Giao thức | Phù hợp | |---|---|---| | FSx for Lustre | Lustre (POSIX) | HPC, học máy, phân tích địa không gian ← câu này | | FSx for Windows File Server | SMB | chia sẻ tệp Windows, AD | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | đa giao thức, doanh nghiệp | | FSx for OpenZFS | NFS | di chuyển từ ZFS |

Từ khoá nhận diện:

"HPC", "sub-millisecond", "parallel file access", "high throughput" → FSx for Lustre "Windows", "SMB", "Active Directory" → FSx for Windows "simple NFS, auto-scaling" → EFS

Hai kiểu triển khai của FSx for Lustre: | Kiểu | Đặc điểm | |---|---| | Scratch | KHÔNG sao chép — mất nếu máy chủ hỏng, rẻ, cho việc tạm | | Persistent | có sao chép trong AZ, tự thay phần cứng hỏng |

Quy tắc: dữ liệu nguồn còn ở S3 thì scratch đủ dùng — mất thì nạp lại.

Ba mức thông lượng của Persistent SSD:

PerUnitStorageThroughput: 125, 250, 500, hoặc 1000 MB/giây mỗi TiB
    ↓
    150 TB × 1000 MB/giây/TiB = thông lượng rất lớn

Ba khái niệm của tích hợp S3 (data repository): | Khái niệm | Việc | |---|---| | Lazy loading | tệp chỉ nạp từ S3 khi ĐƯỢC ĐỌC lần đầu | | AutoImportPolicy | tự cập nhật khi S3 đổi | | Data repository task | xuất kết quả ngược về S3, hoặc nạp trước |

Lazy loading vừa là ưu điểm vừa là nhược điểm:

Ưu: file system nhỏ hơn tổng dữ liệu, tiết kiệm chi phí
Nhược: LẦN ĐỌC ĐẦU của mỗi tệp CHẬM
    ↓
    Với tải cần độ trễ ổn định, phải nạp trước

Ba cách nạp trước dữ liệu:

# Nạp toàn bộ
sudo lfs hsm_restore /du-lieu/**/*

# Hoặc data repository task
aws fsx create-data-repository-task --type IMPORT_METADATA_FROM_REPOSITORY   --file-system-id fs-0abc --paths /du-lieu   --report Enabled=true,Path=s3://bao-cao/

Ba lưu ý về hiệu năng Lustre: | Lưu ý | Chi tiết | |---|---| | Thông lượng tỷ lệ với DUNG LƯỢNG cấp phát | muốn nhanh hơn phải cấp lớn hơn | | Dùng instance có băng thông mạng cao | nếu không mạng thành nút thắt | | Đặt node HPC trong cluster placement group | độ trễ mạng thấp |

Và data compression giảm cả chi phí lẫn thời gian:

--lustre-configuration '{"DataCompressionType": "LZ4"}'

Với dữ liệu sonar, tỷ lệ nén thường tốt.

Ba thành phần của cụm HPC hoàn chỉnh: | Thành phần | Lựa chọn | |---|---| | Tính toán | EC2 trong cluster placement group + EFA | | Lưu trữ chia sẻ | FSx for Lustre ← câu này | | Bộ lập lịch | AWS ParallelCluster (Slurm) hoặc AWS Batch |

AWS ParallelCluster đáng biết:

ParallelCluster:
    ✓ dựng cụm HPC hoàn chỉnh từ một tệp cấu hình
    ✓ tự cấu hình placement group, EFA và FSx for Lustre
    ✓ tích hợp Slurm — quen thuộc với giới nghiên cứu

Ba lựa chọn Snow Family: | Sản phẩm | Dung lượng | |---|---| | Snowcone | ~8–14 TB | | Snowball Edge Storage Optimized | ~80 TB ← dùng trong đề | | Snowball Edge Compute Optimized | ~28 TB + tính toán |

150 TB cần khoảng hai thiết bị Snowball Edge Storage Optimized.

Ba lưu ý về chi phí FSx for Lustre: | Lưu ý | Chi tiết | |---|---| | Trả theo DUNG LƯỢNG CẤP PHÁT | không theo lượng dùng thật | | Scratch rẻ hơn Persistent đáng kể | | | Xoá file system khi xong việc | dữ liệu đã xuất về S3 thì giữ Lustre là lãng phí |

Và một lời khuyên về quy trình: hãy dựng file system Lustre theo từng đợt phân tích — tạo, nạp dữ liệu từ S3, chạy, xuất kết quả về S3, rồi xoá. Với 150 TB, chi phí giữ một file system Lustre chạy liên tục rất lớn, còn dựng theo đợt biến nó thành chi phí theo giờ.

Đáp án

D — Dùng VPC sharing để chia sẻ MỘT HOẶC NHIỀU SUBNET với các tài khoản AWS khác thuộc cùng tổ chức trong AWS Organizations.

Vì sao đúng

Có hai điểm cần đúng, và chỉ đáp án D đúng cả hai: | Điểm | Chi tiết | |---|---| | Cơ chế | VPC sharing (không phải VPC peering) | | Đơn vị chia sẻ | SUBNET (không phải cả VPC) |

Điểm thứ hai là chi tiết chính xác của dịch vụ:

AWS RAM chia sẻ SUBNET, không chia sẻ "VPC"
    → chủ VPC chọn subnet nào để chia sẻ
    → tài khoản tham gia tạo tài nguyên TRONG subnet đó
        ↓
    Cho phép kiểm soát chi tiết:
    chia sẻ subnet A cho đội 1, subnet B cho đội 2

Chia sẻ subnet:

aws ram create-resource-share --name chia-se-subnet   --resource-arns arn:aws:ec2:ap-northeast-1:111122223333:subnet/subnet-abc                   arn:aws:ec2:ap-northeast-1:111122223333:subnet/subnet-def   --principals ou-abc-12345678   --permission-arns arn:aws:ram::aws:permission/AWSRAMDefaultPermissionSubnet

Và vì sao VPC sharing phù hợp với "mức độ kết nối cao":

Mọi tài nguyên nằm trong CÙNG MỘT VPC
    → giao tiếp qua IP riêng trực tiếp
    → KHÔNG có kết nối liên VPC nào
    → không phí, không độ trễ thêm, không giới hạn bắc cầu
        ↓
    Đây là mức kết nối cao nhất có thể

So với các cách khác: | Cách | Mức kết nối | Chi phí | |---|---|---| | VPC sharing | cùng một mạng | RAM miễn phí | | VPC peering | qua kết nối, không bắc cầu | miễn phí kết nối | | Transit Gateway | bắc cầu được | theo giờ + theo GB |

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

• **C. Dùng VPC sharing để chia sẻ MỘT VPC với các tài khoản khác — đây là phương án gần nhất và đúng cơ chế, nhưng nó sai đơn vị chia sẻ: AWS RAM chia sẻ subnet, không chia sẻ nguyên một VPC. Đây chính là chi tiết mà câu hỏi kiểm tra.
• **A. Dùng VPC peering để chia sẻ subnet — nhầm cơ chế hoàn toàn: peering nối hai VPC riêng biệt, nó không "chia sẻ subnet" cho tài khoản khác dùng.
• **B. Dùng VPC peering để chia sẻ một VPC — cùng lỗi khái niệm.

Ghi nhớ

Bốn cách kết nối mạng giữa nhiều tài khoản — bảng phải thuộc: | Cách | Đơn vị | Chi phí kết nối | Đặc điểm | |---|---|---|---| | VPC sharing (RAM) | SUBNET | MIỄN PHÍ | cùng một VPC ← câu này | | VPC peering | VPC ⟷ VPC | miễn phí | KHÔNG bắc cầu | | Transit Gateway | VPC attachment | theo giờ + theo GB | bắc cầu được | | PrivateLink | một dịch vụ | theo giờ + theo GB | một chiều |

Từ khoá nhận diện:

"share subnets", "centrally managed VPC", "high degree of interconnectivity", "cheapest" → VPC sharing "many VPCs, hub-and-spoke" → Transit Gateway "expose one service one-way, overlapping CIDR" → PrivateLink

Ba đặc điểm của VPC sharing: | Đặc điểm | Chi tiết | |---|---| | Chủ VPC quản lý mạng | subnet, route table, NACL, IGW, NAT, endpoint | | Tài khoản tham gia SỞ HỮU tài nguyên của mình | EC2, RDS, ALB | | Tài khoản tham gia KHÔNG sửa được cấu hình mạng | tách bạch trách nhiệm |

Đây là mô hình phân chia trách nhiệm rất rõ:

Đội mạng (chủ VPC):
    → thiết kế mạng, kết nối tại chỗ, NAT, VPC endpoint

Đội ứng dụng (tham gia):
    → triển khai tài nguyên, quản lý security group của mình

Ba lợi ích của VPC sharing: | Lợi ích | Chi tiết | |---|---| | Tiết kiệm | một NAT Gateway, một bộ VPC endpoint cho mọi đội | | Tiết kiệm không gian địa chỉ IP | không phải cấp CIDR cho mỗi đội | | Quản lý mạng tập trung | chính sách nhất quán |

Ước lượng tiết kiệm với 10 đội:

Mỗi VPC riêng:
    10 × 2 NAT Gateway × 33 USD = 660 USD/tháng
    + 10 × interface endpoint

VPC dùng chung:
    2 NAT Gateway = 66 USD/tháng
    + 1 bộ interface endpoint

Ba thứ KHÔNG chia sẻ được: | Không chia sẻ | Chi tiết | |---|---| | Default VPC | phải tạo VPC mới | | Default subnet | | | Một số tài nguyên đặc thù | kiểm tra tài liệu RAM |

Các tài nguyên chia sẻ được qua AWS RAM: | Tài nguyên | Việc | |---|---| | VPC subnet | ← câu này | | Transit Gateway | dùng chung TGW | | Route 53 Resolver rule | DNS lai dùng chung | | Aurora DB cluster | | | License Manager configuration | | | Capacity Reservation, Prefix list | |

Ba lưu ý về security group trong VPC dùng chung: | Lưu ý | Chi tiết | |---|---| | Tài khoản tham gia TỰ tạo security group | trong VPC dùng chung | | Tham chiếu SG XUYÊN TÀI KHOẢN được | nếu chủ VPC chia sẻ | | Không thấy SG của tài khoản khác trong console | chỉ tham chiếu bằng id |

Ba lưu ý về hạn mức: | Lưu ý | Chi tiết | |---|---| | Hạn mức VPC áp cho TỔNG mọi tài khoản | ENI, security group, route | | Lập kế hoạch CIDR đủ rộng | nhiều đội dùng chung dải IP | | Một đội dùng hết hạn mức ảnh hưởng đội khác | |

Ba bước chuẩn bị:

① Bật chia sẻ trong Organizations:
   aws ram enable-sharing-with-aws-organization
② Lập kế hoạch CIDR đủ chỗ cho mọi đội
③ Thống nhất quy ước đặt tên và gắn thẻ

Ba mẫu kiến trúc mạng nhiều tài khoản: | Mẫu | Phù hợp | |---|---| | VPC sharing | nhiều đội, cần kết nối cao, tiết kiệm ← câu này | | Transit Gateway hub-and-spoke | mỗi đội cần VPC riêng, cách ly rõ | | Kết hợp | VPC dùng chung + TGW nối tới tại chỗ |

Mẫu kết hợp rất phổ biến:

Tài khoản mạng:
    ├── VPC dùng chung (chia sẻ subnet cho các đội)
    └── Transit Gateway (nối tới trung tâm dữ liệu và VPC đặc biệt)

Ba lưu ý về VPC peering — vì hai phương án nhắc tới: | Lưu ý | Chi tiết | |---|---| | KHÔNG bắc cầu | N VPC cần N×(N−1)/2 kết nối | | CIDR không được chồng lấn | | | Miễn phí kết nối, tính phí truyền chéo AZ | |

Và một lời khuyên: hãy gắn thẻ bắt buộc cho mọi tài nguyên trong VPC dùng chung (đội, dự án, môi trường). Khi hàng chục đội cùng triển khai vào một VPC, việc xác định ENI hay security group nào thuộc về ai trở thành công việc thường xuyên — và không có thẻ thì không ai dám dọn dẹp gì cả.

Đáp án

A — Dùng Amazon FSx for Windows File Server làm giải pháp lưu trữ chia sẻ.

Vì sao đúng

Đề nêu ba yêu cầu, và FSx for Windows đáp ứng cả ba với ít công tích hợp nhất: | Yêu cầu | Cơ chế | |---|---| | Ứng dụng dựa trên WINDOWS | FSx for Windows chạy Windows Server thật | | Nhiều ứng dụng truy cập CHUNG, KHÔNG cần sao chép | SMB file share — mọi máy mount cùng một nơi | | Tích hợp Active Directory TỰ QUẢN LÝ | FSx tham gia trực tiếp domain của bạn |

Vế thứ ba là điểm phân biệt quan trọng:

FSx for Windows tham gia CHÍNH domain AD tại chỗ
    → người dùng đăng nhập bằng tài khoản quen thuộc
    → ACL hiện có áp dụng NGUYÊN VẸN
    → không phải đồng bộ hay tạo lại phân quyền
        ↓
    Đây là "minimal integration effort" mà đề hỏi

Cấu hình với AD tự quản lý:

aws fsx create-file-system --file-system-type WINDOWS   --storage-capacity 2048 --storage-type SSD   --subnet-ids subnet-a subnet-b   --security-group-ids sg-fsx   --windows-configuration '{
    "SelfManagedActiveDirectoryConfiguration": {
      "DomainName": "congty.local",
      "OrganizationalUnitDistinguishedName": "OU=FSx,DC=congty,DC=local",
      "FileSystemAdministratorsGroup": "QuanTriFSx",
      "UserName": "svc-fsx",
      "Password": "<mat-khau>",
      "DnsIps": ["10.100.0.10", "10.100.0.11"]},
    "ThroughputCapacity": 512,
    "DeploymentType": "MULTI_AZ_1"}'

Và người dùng truy cập như ổ mạng bình thường:

net use Z: \\amznfsxabc123.congty.local\share

Vế "không cần sao chép" cũng được đáp ứng:

Nhiều ứng dụng mount CÙNG một file share
    → một bản dữ liệu duy nhất
    → không có xung đột phiên bản

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

• **B. Dùng File Gateway của Storage Gateway cho giải pháp lưu trữ lai — đây là phương án gần nhất và cũng phơi ra SMB và tích hợp AD được, nhưng nó phù hợp với kịch bản khác: File Gateway dành cho mô hình LAI — dữ liệu ở S3, truy cập từ tại chỗ với cache. Đề nói công ty đang chuyển lên AWS, nên FSx for Windows là đích đến trực tiếp và ít thành phần hơn.
• **C. Dùng Amazon EFS — sai giao thức: EFS phục vụ NFS cho Linux, không hỗ trợ SMB và không tích hợp Active Directory. Ứng dụng Windows không mount được.
• **D. Dùng FSx for Lustre — sai loại hệ thống tệp: Lustre là hệ thống tệp song song cho HPC trên Linux. Không hỗ trợ SMB, không tích hợp AD.

Ghi nhớ

Bốn dịch vụ FSx — bảng phải thuộc: | Dịch vụ | Giao thức | Tích hợp AD | Phù hợp | |---|---|---|---| | FSx for Windows File Server | SMB | ✅ đầy đủ | ứng dụng Windows ← câu này | | FSx for Lustre | Lustre | ❌ | HPC, học máy | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | ✅ | đa giao thức | | FSx for OpenZFS | NFS | ❌ | di chuyển từ ZFS |

Từ khoá nhận diện:

"Windows applications", "SMB", "Active Directory", "shared storage" → FSx for Windows "hybrid, on-premises with local cache" → File Gateway "Linux NFS" → EFS "HPC, parallel" → FSx for Lustre

Ba lựa chọn tích hợp Active Directory của FSx: | Lựa chọn | Chi tiết | |---|---| | AWS Managed Microsoft AD | AD chạy trên AWS, AWS quản lý | | Self-managed AD | AD tại chỗ hoặc trên EC2 của bạn ← câu này | | — | cả hai đều dùng được |

Với AD tự quản lý, cần khai: | Thông tin | Chi tiết | |---|---| | DomainName | tên domain đầy đủ | | DnsIps | IP của domain controller | | UserName và Password | tài khoản dịch vụ có quyền tham gia domain | | OrganizationalUnitDistinguishedName | OU chứa đối tượng máy tính |

Ba yêu cầu mạng: | Yêu cầu | Chi tiết | |---|---| | Đường mạng tới domain controller | Direct Connect hoặc VPN | | Mở cổng AD | 389/636 (LDAP), 88 (Kerberos), 53 (DNS), 445 (SMB) | | DNS phân giải được tên domain | Route 53 Resolver forwarding rule |

Ba tính năng của FSx for Windows: | Tính năng | Chi tiết | |---|---| | Data deduplication | tiết kiệm 50–60% với dữ liệu doanh nghiệp | | Shadow Copy | người dùng tự khôi phục phiên bản cũ | | DFS Namespaces và Replication | gộp nhiều file system | | User quota | giới hạn theo người dùng |

Hai kiểu triển khai: | Kiểu | Đặc điểm | |---|---| | Single-AZ | rẻ hơn, không chịu được mất AZ | | Multi-AZ | standby ở AZ khác, tự chuyển đổi — cho sản xuất |

Ba lựa chọn lưu trữ: | Loại | Phù hợp | |---|---| | SSD | ứng dụng cần I/O cao | | HDD | lưu trữ dung lượng lớn, truy cập thưa | | SSD cache trên HDD | cân bằng |

Ba cách di chuyển dữ liệu lên FSx: | Cách | Đặc điểm | |---|---| | AWS DataSync | nhanh, GIỮ ACL và metadata NTFS | | DFS Replication | đồng bộ liên tục, chuyển dần | | Robocopy | thủ công, khối lượng nhỏ |

Giữ được ACL rất quan trọng:

Công cụ sao chép thường:
    → mất toàn bộ ACL của NTFS
    → phải cấu hình lại phân quyền từ đầu

DataSync và DFSR:
    → giữ nguyên ACL, timestamp, chủ sở hữu

Ba lưu ý khi chuyển từ file server tại chỗ: | Lưu ý | Chi tiết | |---|---| | Kiểm kê ACL và cấu trúc thư mục | trước khi bắt đầu | | Chạy song song một thời gian | DFSR đồng bộ hai chiều | | Tìm phụ thuộc ẩn | script cũ, ứng dụng trỏ vào đường dẫn UNC cụ thể |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Tính theo dung lượng CẤP PHÁT | không phải dung lượng dùng | | Thông lượng tính riêng | ảnh hưởng giá đáng kể | | Bật deduplication | giảm dung lượng thật cần cấp |

Ba biện pháp bảo mật: | Biện pháp | Chi tiết | |---|---| | Mã hoá at rest bằng KMS | bật lúc tạo | | Mã hoá in transit (SMB 3.0+) | | | ACL của NTFS giữ nguyên từ AD | mô hình quyền không đổi |

Và FSx File Gateway cho truy cập từ tại chỗ:

Người dùng còn ở văn phòng truy cập FSx trên AWS:
    → gateway cache dữ liệu nóng ở địa phương
    → độ trễ như file server nội bộ

Và một lời khuyên: hãy bật Shadow Copy và đặt lịch chụp thường xuyên ngay sau khi chuyển. Nó cho phép người dùng tự khôi phục tệp bị xoá hoặc sửa nhầm — và trong giai đoạn chuyển đổi, đó là thứ giảm rất nhiều phiếu hỗ trợ và giúp người dùng tin tưởng hệ thống mới.

Đáp án

A — Dùng AWS Lambda chạy microservice Python; tích hợp với API Gateway cho truy cập HTTP; bật provisioned concurrency để đảm bảo hiệu năng lúc cao điểm.

Vì sao đúng

Đề nêu bốn yêu cầu, và Lambda thoả cả bốn: | Yêu cầu | Cơ chế | |---|---| | Hỗ trợ Python | Lambda có runtime Python nguyên bản | | Xử lý hàng TRĂM request mỗi giây | Lambda tự co giãn tới 1.000 lượt đồng thời | | Tự co giãn theo lưu lượng | không cấu hình gì | | ÍT công hạ tầng và vận hành nhất | không có container, không có máy chủ |

Vì sao Lambda là lựa chọn ít công nhất:

Lambda:
    ✓ chỉ cần đẩy mã Python lên
    ✓ không đóng gói Docker image
    ✓ không quản lý cụm, task definition hay service
    ✓ không cấu hình auto scaling
        ↓
    Từ mã tới chạy được: vài phút

Và tính toán khả năng đáp ứng:

Đồng thời = số request/giây × thời gian chạy (giây)

500 request/giây × 0,2 giây = 100 lượt đồng thời
    → dưới hạn mức mặc định 1.000 rất nhiều

Provisioned concurrency giải quyết vấn đề cold start:

Không có provisioned concurrency:
    → lượt gọi đầu tiên của mỗi môi trường mới phải khởi tạo
    → cold start của Python: ~200–800ms
    → lúc lưu lượng tăng đột ngột, nhiều request bị chậm

Có provisioned concurrency:
    → giữ sẵn N môi trường đã khởi tạo
    → phản hồi ổn định ở mức mili giây

aws lambda put-provisioned-concurrency-config   --function-name vi-dich-vu-phan-tich   --qualifier prod --provisioned-concurrent-executions 50

Và có thể co giãn provisioned concurrency theo lịch:

aws application-autoscaling register-scalable-target   --service-namespace lambda   --resource-id function:vi-dich-vu-phan-tich:prod   --scalable-dimension lambda:function:ProvisionedConcurrency   --min-capacity 10 --max-capacity 200

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

• **B. Triển khai lên Fargate task qua ECS, đóng gói Docker image Python, cấu hình ECS Service Auto Scaling theo CPU — đây là phương án gần nhất và hoàn toàn hoạt động được, nhưng nó nhiều công hơn: phải viết Dockerfile, xây và đẩy image lên ECR, tạo task definition, tạo service, cấu hình target group và auto scaling policy. Với một microservice thử nghiệm, đó là công việc đáng kể.
• **D. Dùng AWS App Runner triển khai thẳng từ GitHub — là lựa chọn hợp lý và cũng ít công, nhưng nó kém phù hợp hơn với microservice theo sự kiện: App Runner tối ưu cho ứng dụng web chạy liên tục, và nó luôn có ít nhất một instance chạy nên tốn chi phí ngay cả khi không có lưu lượng. Lambda trả tiền theo mili giây thực chạy.
• **C. Dùng EC2 Spot trong Auto Scaling group, cài phụ thuộc lúc khởi động — nhiều công nhất và rủi ro nhất: phải quản lý AMI, cài đặt lúc khởi động, và Spot bị thu hồi bất cứ lúc nào — không phù hợp cho dịch vụ phục vụ request thời gian thực.

Ghi nhớ

Bốn lựa chọn compute cho microservice — bảng so sánh: | Lựa chọn | Công vận hành | Trả tiền khi nhàn rỗi | |---|---|---| | AWS Lambda | thấp nhất | KHÔNG ← câu này | | AWS App Runner | thấp | CÓ (tối thiểu 1 instance) | | ECS Fargate | vừa | có | | EC2 với ASG | cao nhất | có |

Từ khoá nhận diện:

"minimal operational overhead", "scales automatically", "Python", "hundreds of req/s" → Lambda "long-running", "over 15 minutes", "GPU" → Fargate hoặc EC2 "web app from git repo, simple" → App Runner

Giới hạn của Lambda — nhắc lại: | Giới hạn | Giá trị | |---|---| | Thời gian chạy | 15 phút | | Bộ nhớ | 128 MB – 10 GB | | Payload đồng bộ | 6 MB | | Đồng thời mặc định | 1.000 mỗi tài khoản mỗi Region (nâng được) | | Burst concurrency | 500–3.000 tuỳ Region |

Ba loại concurrency của Lambda: | Loại | Việc | |---|---| | Unreserved | dùng chung phần còn lại của hạn mức | | Reserved concurrency | DÀNH RIÊNG và cũng GIỚI HẠN cho hàm | | Provisioned concurrency | giữ sẵn môi trường — hết cold start, CÓ PHÍ |

Reserved và Provisioned dễ nhầm:

Reserved concurrency:
    → giới hạn trên, không có phí thêm
    → bảo vệ các hàm khác

Provisioned concurrency:
    → giữ môi trường ấm, CÓ PHÍ theo giờ
    → loại bỏ cold start

Ba cách giảm cold start: | Cách | Chi tiết | |---|---| | Provisioned concurrency | triệt để nhất, có phí | | Giảm kích thước gói triển khai | ít phụ thuộc hơn | | Khởi tạo ngoài handler | tái dùng kết nối giữa các lượt gọi |

Mẫu khởi tạo đúng:

import boto3
# Khởi tạo NGOÀI handler — tái dùng giữa các lượt gọi
ddb = boto3.resource('dynamodb')
bang = ddb.Table('bang-phan-tich')

def handler(event, context):
    return bang.get_item(Key={'ma': event['ma']})

Ba cách phơi Lambda ra HTTP: | Cách | Đặc điểm | |---|---| | API Gateway HTTP API | rẻ hơn ~70%, JWT authorizer | | API Gateway REST API | đầy đủ tính năng | | Lambda Function URL | đơn giản nhất, MIỄN PHÍ |

Ba cấu hình quan trọng của Lambda: | Cấu hình | Chi tiết | |---|---| | Bộ nhớ | tăng bộ nhớ = tăng CPU = chạy nhanh hơn, có khi RẺ HƠN | | Timeout | đặt sát thời gian thực tế | | Kiến trúc arm64 (Graviton) | rẻ hơn ~20%, thường nhanh hơn |

Chuyển sang arm64 là tối ưu dễ:

aws lambda update-function-configuration   --function-name vi-dich-vu-phan-tich --architectures arm64

Với Python thuần thì gần như luôn chạy được — chỉ cần chú ý thư viện có mã native.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | Duration (p99) | độ trễ đuôi | | Throttles | chạm hạn mức đồng thời | | ConcurrentExecutions | tiến gần hạn mức | | Errors | lỗi trong hàm |

Ba lưu ý cho ứng dụng y tế: | Lưu ý | Chi tiết | |---|---| | Ký BAA với AWS | bắt buộc cho PHI | | Mã hoá biến môi trường bằng KMS | | | Lambda trong VPC nếu cần truy cập tài nguyên riêng | có cold start lâu hơn |

Và Lambda trong VPC có hệ quả:

Lambda trong VPC:
    → cần VPC endpoint hoặc NAT để gọi dịch vụ AWS
    → cold start lâu hơn (dù đã cải thiện nhiều từ 2019)
        ↓
    Chỉ đưa vào VPC khi thực sự cần

Ba công cụ phát triển: | Công cụ | Việc | |---|---| | AWS SAM | framework của AWS, chạy thử cục bộ được | | AWS CDK | hạ tầng bằng ngôn ngữ lập trình | | AWS Lambda Powertools for Python | logging, tracing, metrics theo chuẩn |

Lambda Powertools rất đáng dùng cho Python:

from aws_lambda_powertools import Logger, Tracer, Metrics
logger = Logger()
tracer = Tracer()

@tracer.capture_lambda_handler
@logger.inject_lambda_context
def handler(event, context):
    ...

Và một lời khuyên: hãy bắt đầu KHÔNG có provisioned concurrency và đo Duration p99 trong vài ngày. Nếu cold start không gây vấn đề thực tế cho người dùng, bạn tiết kiệm được khoản phí đó — và với một microservice thử nghiệm, biết con số thật quan trọng hơn tối ưu trước khi có dữ liệu.