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

Đáp án

B và D.

• B — AWS Fargate cho tầng web và tầng ứng dụng
• D — Amazon RDS for MySQL cho tầng CSDL

Vì sao đúng

Đề nêu hai ràng buộc, và cặp này là câu trả lời trực tiếp: | Ràng buộc | Cách đáp ứng | |---|---| | Ứng dụng gồm web tier, app tier, MySQL | hai tầng tính toán + một CSDL | | KHÔNG muốn quản lý instance hay cụm | Fargate + RDS đều được quản lý |

Vì sao Fargate cho hai tầng tính toán:

Fargate = chạy container mà KHÔNG có máy chủ nào để quản lý
    → không vá lỗi hệ điều hành
    → không co giãn cụm EC2
    → không quản lý dung lượng node
        ↓
    Đúng nghĩa "does not want to manage instances or clusters"

So sánh ba cách chạy container: | Cách | Quản lý máy chủ | Quản lý cụm | |---|---|---| | ECS/EKS trên EC2 | ✅ bạn lo | ✅ bạn lo | | ECS/EKS trên Fargate | ❌ AWS lo | ❌ AWS lo | | Lambda | ❌ | ❌ (nhưng giới hạn 15 phút) |

Vì sao RDS for MySQL:

Ứng dụng cũ dùng MySQL
    → chuyển sang RDS for MySQL = KHÔNG đổi mã, không đổi truy vấn
        ↓
    AWS lo: vá lỗi engine, sao lưu, chuyển đổi dự phòng, giám sát
    → bạn chỉ chọn cấu hình

Kiến trúc kết quả:

        ALB (công khai)
            │
    ┌───────▼────────┐
    │ Fargate task   │  tầng web
    └───────┬────────┘
            │ ALB nội bộ hoặc Service Connect
    ┌───────▼────────┐
    │ Fargate task   │  tầng ứng dụng
    └───────┬────────┘
            │
    ┌───────▼────────┐
    │ RDS MySQL      │  Multi-AZ, subnet riêng tư
    └────────────────┘

Triển khai Fargate:

aws ecs create-cluster --cluster-name cum-ung-dung   --capacity-providers FARGATE FARGATE_SPOT

aws ecs create-service --cluster cum-ung-dung --service-name tang-web   --task-definition tang-web:1 --desired-count 3 --launch-type FARGATE   --network-configuration 'awsvpcConfiguration={
    subnets=[subnet-a,subnet-b],securityGroups=[sg-web],assignPublicIp=DISABLED}'   --load-balancers targetGroupArn=<arn-tg>,containerName=web,containerPort=8080

RDS Multi-AZ:

aws rds create-db-instance --db-instance-identifier csdl-ung-dung   --engine mysql --db-instance-class db.m6g.large   --allocated-storage 100 --storage-type gp3 --multi-az   --db-subnet-group-name nhom-subnet-rieng-tu --storage-encrypted   --no-publicly-accessible --backup-retention-period 7

Ba lợi ích của cặp này cho việc di chuyển ứng dụng cũ: | Lợi ích | Chi tiết | |---|---| | Container hoá ứng dụng cũ không cần viết lại | | | MySQL giữ nguyên, không đổi truy vấn | | | Không có máy chủ nào để vá lỗi | |

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

• **C. Amazon DynamoDB — đây là phương án gần nhất vì cũng là CSDL được quản lý hoàn toàn, nhưng nó buộc viết lại toàn bộ tầng dữ liệu: DynamoDB là NoSQL, không có SQL, không có JOIN, không có khoá ngoại. Đề nói rõ ứng dụng dùng MySQL.
• **E. EC2 Spot Instances — ngược hẳn yêu cầu: đây vẫn là instance phải quản lý, và Spot còn bị thu hồi với 2 phút báo trước.
• **A. Kinesis Data Streams — sai loại dịch vụ hoàn toàn: đây là dịch vụ nạp dữ liệu theo luồng, không phải tầng tính toán hay tầng CSDL. Ứng dụng web ba tầng không cần nó.

Ghi nhớ

Ba mức "được quản lý" của tầng tính toán — bảng phải thuộc: | Mức | Dịch vụ | Bạn quản lý | |---|---|---| | Tự quản | EC2 | OS, vá lỗi, co giãn | | Container được quản lý | ECS/EKS trên Fargate | chỉ container | | Serverless hàm | Lambda | chỉ mã |

Từ khoá nhận diện:

"does not want to manage instances or clusters" → Fargate "legacy app, MySQL, minimal changes" → RDS for MySQL "rewrite to serverless functions" → Lambda (nhưng công lớn)

Ba lựa chọn CSDL quan hệ được quản lý: | Lựa chọn | Khi nào | |---|---| | RDS for MySQL | giữ nguyên MySQL, tải ổn định ← câu này | | Aurora MySQL | cần hiệu năng và tính năng cao hơn | | Aurora Serverless v2 | tải biến động |

Aurora MySQL đáng cân nhắc:

Tương thích MySQL (mã không đổi)
    → hiệu năng gấp tới 5 lần
    → tự sửa lỗi lưu trữ, tới 15 replica
        ↓
    Đắt hơn RDS MySQL một chút
    → nhưng đề chỉ đưa "RDS for MySQL" nên đó là đáp án

Ba đặc điểm của Fargate: | Đặc điểm | Chi tiết | |---|---| | Trả tiền theo vCPU và RAM của task | theo giây | | Mỗi task có ENI riêng (awsvpc mode) | | | Khởi động chậm hơn EC2 có sẵn chỗ | ~30-60 giây |

Vế thứ hai có hệ quả về mạng:

Mỗi task một ENI với IP riêng trong subnet
    → security group áp cho từng task
    → nhưng cũng tiêu tốn IP trong subnet
        ↓
    Subnet /24 chỉ chứa được khoảng 250 task
    → tính dung lượng CIDR trước

Ba cách giảm chi phí Fargate: | Cách | Chi tiết | |---|---| | Fargate Spot | rẻ tới 70%, cho tải chịu gián đoạn | | Compute Savings Plans | áp cho cả Fargate | | Right-size vCPU và RAM | |

Chiến lược năng lực hỗn hợp:

{"capacityProviderStrategy": [
  {"capacityProvider": "FARGATE", "base": 2, "weight": 1},
  {"capacityProvider": "FARGATE_SPOT", "weight": 3}]}

Ba bước container hoá ứng dụng cũ: | Bước | Việc | |---|---| | Viết Dockerfile, xây ảnh | | | Tách cấu hình ra biến môi trường | | | Đưa bí mật vào Secrets Manager | |

Bước ba là chỗ hay làm sai:

{"secrets": [{
  "name": "DB_PASSWORD",
  "valueFrom": "arn:aws:secretsmanager:...:secret:csdl-ung-dung-abc:password::"}]}

ECS tự lấy giá trị và tiêm vào biến môi trường lúc chạy
    → mật khẩu KHÔNG nằm trong task definition
    → không nằm trong ảnh container

Ba lưu ý về trạng thái: | Lưu ý | Chi tiết | |---|---| | Container phải stateless | | | Session sang ElastiCache hoặc DynamoDB | | | Tệp tải lên sang S3 hoặc EFS | |

Fargate mount EFS được:

{"volumes": [{"name": "du-lieu-chung",
  "efsVolumeConfiguration": {"fileSystemId": "fs-abc",
    "transitEncryption": "ENABLED"}}]}

Ba lưu ý về RDS: | Lưu ý | Chi tiết | |---|---| | Bật Multi-AZ cho tính sẵn sàng | | | Đặt trong subnet riêng tư | | | RDS Proxy nếu nhiều kết nối ngắn | |

RDS Proxy đặc biệt hợp với container:

Mỗi task Fargate mở connection pool riêng
    → 20 task × 10 kết nối = 200 kết nối tới CSDL
    → co giãn lên 100 task là chạm giới hạn
        ↓
    RDS Proxy gộp lại, tái sử dụng kết nối

Ba việc nên làm khi di chuyển: | Việc | Chi tiết | |---|---| | Dùng DMS chuyển dữ liệu gần như không ngừng | | | Chạy song song một thời gian | | | Đo hiệu năng trước và sau | |

Và một lời khuyên: hãy tính dung lượng CIDR của subnet trước khi triển khai Fargate. Mỗi task chiếm một địa chỉ IP riêng, và một dịch vụ co giãn tới hàng trăm task sẽ lặng lẽ dừng lại ở đúng con số mà subnet hết IP — thông báo lỗi khi đó nói về ENI chứ không nói về mạng, nên rất mất thời gian mới lần ra.

Đáp án

A — Triển khai Amazon FSx for Windows File Server ở chế độ Multi-AZ, dựng Windows Server Failover Cluster trên hai EC2 ở hai AZ, dùng FSx làm lưu trữ chia sẻ.

Vì sao đúng

Đề nêu năm yêu cầu, và phương án này thoả hết: | Yêu cầu | Cách đáp ứng | |---|---| | Chạy trên Microsoft Windows Server | FSx for Windows là lưu trữ gốc của Windows | | Cần lưu trữ CHIA SẺ cho nhất quán dữ liệu | FSx mount được từ nhiều node | | Cụm active-passive qua nhiều AZ | FSx Multi-AZ + WSFC | | Ít công vận hành | AWS quản lý tầng lưu trữ | | Độ trễ thấp | SSD, cùng vùng |

Vì sao FSx for Windows là mảnh ghép then chốt:

Windows Server Failover Cluster cần một "witness" và
lưu trữ chia sẻ mà cả hai node cùng thấy
        ↓
    Tại chỗ: dùng SAN chia sẻ
    Trên AWS: FSx for Windows với SMB Continuous Availability
        ↓
    Đây là cách AWS hỗ trợ WSFC mà không cần SAN

Tạo FSx Multi-AZ:

aws fsx create-file-system --file-system-type WINDOWS   --storage-capacity 1000 --storage-type SSD   --subnet-ids subnet-az-a subnet-az-b   --windows-configuration     'DeploymentType=MULTI_AZ_1,PreferredSubnetId=subnet-az-a,
     ThroughputCapacity=64,ActiveDirectoryId=d-1234567890,
     AutomaticBackupRetentionDays=30'

Bật SMB Continuous Availability cho share dùng với WSFC:

New-FSxSmbShare -Name "DuLieuUngDung" -Path "D:\share\ungdung" `
  -ContinuouslyAvailable $true

Continuous Availability là điều kiện để WSFC dùng được SMB share
    → cho phép chuyển đổi mà không mất kết nối tệp

Kiến trúc:

    AZ-a                          AZ-b
┌──────────────┐            ┌──────────────┐
│ EC2 Windows  │            │ EC2 Windows  │
│  (active)    │            │  (passive)   │
└──────┬───────┘            └───────┬──────┘
       │      Windows Failover      │
       │           Cluster          │
       └────────────┬───────────────┘
                    │ SMB
         ┌──────────▼──────────┐
         │ FSx for Windows     │
         │ Multi-AZ (a ↔ b)    │
         └─────────────────────┘

Ba lý do đây là phương án ít công nhất: | Lý do | Chi tiết | |---|---| | Không tự dựng cụm lưu trữ | AWS lo nhân bản và chuyển đổi | | Không tự lo sao lưu | tự động hằng ngày | | Không đổi ứng dụng | vẫn là SMB share như tại chỗ |

Và FSx Multi-AZ tự chuyển đổi:

AZ-a hỏng → FSx tự chuyển sang file server ở AZ-b
    → tên DNS giữ nguyên
        ↓
    Cả tầng lưu trữ lẫn tầng ứng dụng đều có dự phòng AZ

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

• **D. Dùng Storage Gateway với cached volume làm lưu trữ khối cho cụm Windows qua hai AZ — đây là phương án gần nhất vì cung cấp lưu trữ khối như một SAN, nhưng Storage Gateway là dịch vụ cho hạ tầng tại chỗ, và bản thân gateway chạy trên một EC2 trong một AZ — nó thành điểm hỏng mới, đúng thứ mà kiến trúc đa AZ cần loại bỏ.
• **C. Dùng Amazon EFS chia sẻ dữ liệu giữa hai máy — EFS dùng NFS, không phải SMB. Windows Server Failover Cluster không dùng EFS làm lưu trữ cụm, và ứng dụng Windows sẽ phải đổi cách truy cập tệp.
• **B. Dùng S3 với S3 File Gateway làm lưu trữ chia sẻ — S3 là object store, không cung cấp ngữ nghĩa khoá tệp mà WSFC cần cho nhất quán dữ liệu. Và File Gateway cũng chạy trên một máy ảo, lại thêm một điểm hỏng.

Ghi nhớ

Ba lựa chọn lưu trữ chia sẻ trên AWS — bảng phải thuộc: | Dịch vụ | Giao thức | Dùng cho | |---|---|---| | FSx for Windows File Server | SMB | Windows, WSFC, AD ← câu này | | Amazon EFS | NFS | Linux | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | đa giao thức, cần iSCSI |

Từ khoá nhận diện:

"Windows Server Failover Cluster", "shared storage", "Multi-AZ" → FSx for Windows Multi-AZ "active-passive clustering" trên Windows → WSFC + FSx "Linux shared file system" → EFS

⚠ Ba lựa chọn cho WSFC trên AWS: | Lựa chọn | Đặc điểm | |---|---| | FSx for Windows (SMB CA) | được quản lý, đơn giản nhất ← câu này | | FSx for NetApp ONTAP (iSCSI) | nếu cần lưu trữ KHỐI chia sẻ thật | | EBS Multi-Attach | chỉ trong MỘT AZ, chỉ io1/io2 |

EBS Multi-Attach không dùng được ở đây:

EBS Multi-Attach cho phép nhiều EC2 gắn cùng một volume
    → NHƯNG chỉ trong CÙNG MỘT AZ
        ↓
    Đề yêu cầu cụm qua NHIỀU AZ → loại

Hai chế độ triển khai FSx for Windows: | Chế độ | SLA | Đặc điểm | |---|---|---| | Single-AZ | 99,9% | rẻ hơn | | Multi-AZ | 99,99% | standby ở AZ khác, tự chuyển ← đề cần |

Ba yêu cầu để dựng FSx for Windows: | Yêu cầu | Chi tiết | |---|---| | Active Directory | AWS Managed AD hoặc AD tự quản | | Subnet ở hai AZ (Multi-AZ) | | | Security group mở SMB (445) và cổng AD | |

⚠ AD là điều kiện bắt buộc — không có AD thì không tạo được file system.

Ba tính năng Windows gốc FSx giữ nguyên: | Tính năng | Chi tiết | |---|---| | ACL của Windows và tích hợp AD | | | Shadow Copies | người dùng tự khôi phục tệp | | Deduplication và quota | |

Ba lưu ý về SMB Continuous Availability: | Lưu ý | Chi tiết | |---|---| | Bắt buộc cho WSFC và SQL Server | | | Bật theo từng share, không phải cả file system | | | Có chi phí hiệu năng nhỏ | |

Ba lưu ý về Windows Failover Cluster trên AWS: | Lưu ý | Chi tiết | |---|---| | Cần cấu hình cluster IP đúng cách trong VPC | | | Dùng NLB hoặc secondary IP cho cluster name | | | File share witness đặt trên FSx | |

Vế đầu là chi tiết kỹ thuật hay vấp:

WSFC tại chỗ dùng gratuitous ARP để di chuyển cluster IP
    → VPC của AWS KHÔNG hỗ trợ cơ chế này
        ↓
    Phải dùng secondary private IP gán lại khi failover,
    hoặc đặt NLB trước cụm

File share witness:

Set-ClusterQuorum -FileShareWitness \\amznfsxabc.corp.vidu.com\witness

Witness quyết định node nào giữ quyền khi mạng chia cắt
    → đặt trên FSx Multi-AZ là an toàn nhất
    → nó không nằm trong AZ nào của hai node

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Multi-AZ có độ trễ ghi cao hơn | sao chép đồng bộ | | Chọn SSD cho tải cần độ trễ thấp | | | ThroughputCapacity ảnh hưởng cả IOPS | |

Ba lưu ý về sao lưu: | Lưu ý | Chi tiết | |---|---| | Tự động hằng ngày, giữ 0-90 ngày | | | Sao lưu thủ công giữ vô thời hạn | | | AWS Backup quản lý tập trung được | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Multi-AZ đắt gần gấp đôi Single-AZ | | | ThroughputCapacity tính riêng | | | Deduplication giảm chi phí lưu trữ thật | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ép chuyển đổi cụm Windows | Move-ClusterGroup | | Ép chuyển đổi FSx | AWS Support hoặc bảo trì | | Đo thời gian ngừng thực tế | |

Và một lời khuyên: hãy thử chuyển đổi cụm ít nhất một lần trước khi đưa vào sản xuất. Windows Failover Cluster trên AWS có những khác biệt về mạng so với môi trường tại chỗ, và điều thường gãy không phải là tầng lưu trữ mà là địa chỉ IP của cụm — thứ chỉ lộ ra khi bạn thực sự chuyển vai trò giữa hai node.

Đáp án

C — Cấu hình lifecycle chuyển object sang S3 Standard-Infrequent Access sau 30 ngày.

Vì sao đúng

Đề nêu ba yêu cầu, và mỗi cái loại bớt lựa chọn: | Yêu cầu | Ý nghĩa | |---|---| | Phân tích nhiều trong TUẦN ĐẦU | dữ liệu nóng lúc đầu | | Sau đó vẫn phải CÓ NGAY | loại Glacier Flexible và Deep Archive | | Và phải SẴN SÀNG CAO | loại One Zone-IA |

Vế thứ ba là điểm phân biệt Standard-IA và One Zone-IA: | Lớp | Số AZ | Độ sẵn sàng | |---|---|---| | Standard-IA | ≥ 3 AZ | 99,9% | | One Zone-IA | 1 AZ | 99,5% |

"highly available" → phải trải nhiều AZ
    → One Zone-IA lưu trong MỘT AZ
    → AZ đó mất là mất dữ liệu
        ↓
    Loại cả A và D

Vế "sau 30 ngày" chứ không phải 7 ngày:

⚠ S3 lifecycle KHÔNG cho chuyển từ Standard sang
   Standard-IA hoặc One Zone-IA trước 30 NGÀY
        ↓
    Quy tắc "transition after 7 days" sẽ bị từ chối
    → đây là lý do B sai còn C đúng

Cấu hình:

{"Rules": [{
  "ID": "chuyen-sang-ia",
  "Status": "Enabled",
  "Filter": {},
  "Transitions": [{"Days": 30, "StorageClass": "STANDARD_IA"}]}]}

aws s3api put-bucket-lifecycle-configuration --bucket du-lieu-giao-dich   --lifecycle-configuration file://vong-doi.json

Vì sao Standard-IA là lựa chọn đúng cho "thỉnh thoảng phân tích": | Đặc điểm | Chi tiết | |---|---| | Truy cập TỨC THÌ | không phải khôi phục | | Rẻ hơn Standard ~45% tiền lưu trữ | | | Cùng độ bền 11 số 9 | | | Có phí lấy dữ liệu mỗi GB | |

Vế cuối là đánh đổi cần hiểu:

Standard-IA rẻ hơn khi LƯU
    → nhưng tính phí mỗi GB khi ĐỌC
        ↓
    Chỉ có lợi khi thật sự ít truy cập
    → truy cập thường xuyên thì Standard rẻ hơn

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

• **B. Chuyển sang Standard-IA sau 7 NGÀY — đây là phương án gần nhất và chọn đúng lớp lưu trữ, nhưng nó vi phạm giới hạn kỹ thuật của S3: lifecycle không cho chuyển sang Standard-IA trước khi object nằm 30 ngày ở Standard. Quy tắc này sẽ không có tác dụng.
• **A. Chuyển sang One Zone-IA sau 7 ngày — sai cả hai vế: vi phạm giới hạn 30 ngày, và One Zone-IA chỉ lưu trong một AZ nên không đạt "highly available".
• **D. Chuyển sang One Zone-IA sau 30 ngày — đúng thời điểm nhưng sai lớp: một AZ không thoả yêu cầu tính sẵn sàng cao mà đề nêu rõ.

Ghi nhớ

Bảng lớp lưu trữ S3 — phải thuộc: | Lớp | Truy cập | Số AZ | Lưu tối thiểu | |---|---|---|---| | Standard | tức thì | ≥ 3 | — | | Intelligent-Tiering | tức thì | ≥ 3 | — | | Standard-IA | tức thì | ≥ 3 | 30 ngày | | One Zone-IA | tức thì | 1 ⚠ | 30 ngày | | Glacier Instant Retrieval | tức thì | ≥ 3 | 90 ngày | | Glacier Flexible Retrieval | phút - giờ | ≥ 3 | 90 ngày | | Deep Archive | 12-48 giờ | ≥ 3 | 180 ngày |

⚠ Ba giới hạn lifecycle phải nhớ: | Giới hạn | Con số | |---|---| | Standard → Standard-IA / One Zone-IA | tối thiểu 30 ngày | | Object nhỏ hơn 128 KB | không chuyển sang IA | | Đã ở IA → Glacier | không có ràng buộc 30 ngày nữa |

Từ khoá nhận diện:

"immediately available" + "highly available" + "infrequent" → Standard-IA "can be recreated", "not critical" → One Zone-IA (rẻ hơn 20%) "archive", "retrieval time acceptable" → Glacier "unknown access pattern" → Intelligent-Tiering

Khi nào One Zone-IA hợp lý: | Trường hợp | Vì sao | |---|---| | Bản sao thứ hai của dữ liệu | mất cũng còn bản gốc | | Dữ liệu tạo lại được | thumbnail, bản chuyển mã | | Bản sao lưu tại chỗ đã có | |

Ba khoản chi phí của Standard-IA: | Khoản | Chi tiết | |---|---| | Lưu trữ | rẻ hơn Standard ~45% | | Phí lấy dữ liệu mỗi GB | Standard không có | | Phí lưu tối thiểu 30 ngày | xoá sớm vẫn tính đủ |

Vế cuối là bẫy chi phí:

Chuyển object sang Standard-IA rồi xoá sau 5 ngày
    → vẫn bị tính đủ 30 ngày lưu trữ
        ↓
    Không chuyển sang IA thứ sắp bị xoá

Intelligent-Tiering đáng cân nhắc: | Đặc điểm | Chi tiết | |---|---| | Tự chuyển tầng theo mẫu truy cập thật | | | KHÔNG có phí lấy dữ liệu | | | Có phí giám sát nhỏ mỗi object | |

Không chắc mẫu truy cập?
    → Intelligent-Tiering tự làm thay
    → nhưng phí giám sát khiến nó không hợp với
      hàng triệu object rất nhỏ

Ba công cụ phân tích trước khi quyết định: | Công cụ | Việc | |---|---| | S3 Storage Class Analysis | gợi ý thời điểm chuyển tầng | | S3 Storage Lens | phân bố kích thước và tuổi object | | Cost Explorer | chi phí theo lớp |

Storage Class Analysis là công cụ đúng cho câu này:

aws s3api put-bucket-analytics-configuration --bucket du-lieu-giao-dich   --id phan-tich-tang --analytics-configuration '{
    "Id":"phan-tich-tang","StorageClassAnalysis":{}}'

Chạy vài tháng
    → nó nói "sau N ngày, tỷ lệ truy cập tụt xuống mức này"
    → dùng con số đó đặt lifecycle
        ↓
    Thay vì đoán "30 ngày"

Ba lưu ý khi viết quy tắc lifecycle: | Lưu ý | Chi tiết | |---|---| | Filter rỗng nghĩa là áp cho MỌI object | | | Lọc theo tiền tố hoặc tag để áp chọn lọc | | | Nhiều quy tắc có thể chồng nhau | |

Lọc theo tag rất hữu ích:

{"Filter": {"Tag": {"Key": "loai", "Value": "giao-dich"}},
 "Transitions": [{"Days": 30, "StorageClass": "STANDARD_IA"}]}

Ba lưu ý về versioning: | Lưu ý | Chi tiết | |---|---| | Bật versioning thì phiên bản cũ cũng tính phí | | | NoncurrentVersionTransitions cho bản cũ | | | NoncurrentVersionExpiration để dọn | |

Ba lưu ý về phí chuyển tầng: | Lưu ý | Chi tiết | |---|---| | Tính theo SỐ đối tượng chuyển | | | Hàng triệu object nhỏ = phí đáng kể | | | Object < 128 KB không chuyển được sang IA | |

Và một lời khuyên: hãy kiểm tra phân bố kích thước object bằng S3 Storage Lens trước khi đặt quy tắc IA. Ngưỡng tính phí tối thiểu 128 KB nghĩa là với nhiều tệp nhỏ, chuyển sang Standard-IA có thể làm hoá đơn tăng — và không có cảnh báo nào cho bạn biết điều đó ngoài bảng chi phí tháng sau.

Đáp án

B — Dùng AWS IAM Identity Center tích hợp với AD Connector để nối Active Directory tại chỗ, và cấu hình permission set gán quyền theo nhóm AD.

Vì sao đúng

Đề nêu năm yêu cầu, và IAM Identity Center là dịch vụ sinh ra đúng cho bài toán này: | Yêu cầu | Cách đáp ứng | |---|---| | Truy cập nhiều tài khoản AWS | Identity Center tích hợp sẵn với Organizations | | Đã có AD tại chỗ làm nguồn danh tính | AD Connector uỷ quyền xác thực về AD | | Tập trung quản lý danh tính | một nơi gán quyền cho mọi tài khoản | | Truy cập theo VAI TRÒ | permission set ánh xạ từ nhóm AD | | ÍT công vận hành nhất | không nhân bản người dùng, không quản lý khoá |

Vì sao AD Connector chứ không phải dựng AD mới:

AD Connector là một PROXY
    → không lưu bản sao nào của thư mục
    → chuyển yêu cầu xác thực về AD tại chỗ
        ↓
    Không phải đồng bộ, không phải quản lý trust
    → ít việc nhất

Kiến trúc:

    AD tại chỗ (nguồn danh tính duy nhất)
            │ qua DX hoặc VPN
        AD Connector
            │
    IAM Identity Center
            │ permission set
    ┌───────┼───────┬───────┐
  Tài khoản A     B       C     (trong AWS Organizations)

Permission set là gì:

Một permission set = một tập quyền có thể tái dùng
    → gán cho (nhóm AD) × (tài khoản AWS)
        ↓
    Identity Center tự tạo IAM role tương ứng
    trong từng tài khoản
    → bạn không phải tạo role thủ công ở đâu cả

Cấu hình:

aws sso-admin create-permission-set --instance-arn <arn-instance>   --name QuanTriVanHanh --session-duration PT8H   --description "Quyen van hanh cho doi IT"

aws sso-admin attach-managed-policy-to-permission-set   --instance-arn <arn-instance> --permission-set-arn <arn-ps>   --managed-policy-arn arn:aws:iam::aws:policy/PowerUserAccess

aws sso-admin create-account-assignment --instance-arn <arn-instance>   --target-id 111122223333 --target-type AWS_ACCOUNT   --permission-set-arn <arn-ps>   --principal-type GROUP --principal-id <id-nhom-ad>

Ba lợi ích lớn nhất: | Lợi ích | Chi tiết | |---|---| | KHÔNG có IAM user, KHÔNG có access key dài hạn | | | Credential tạm thời tự hết hạn | | | Nhân viên nghỉ việc → khoá ở AD là mất quyền mọi nơi | |

Vế thứ ba là giá trị vận hành lớn nhất:

Không có Identity Center:
    → nhân viên nghỉ → phải xoá IAM user ở TỪNG tài khoản
    → sót một chỗ là còn đường vào
        ↓
Có Identity Center:
    → vô hiệu hoá tài khoản AD → mất quyền ở mọi tài khoản AWS ngay

Đăng nhập bằng CLI:

aws configure sso
aws sso login --profile van-hanh
aws s3 ls --profile van-hanh

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

• **A. Dựng AWS Managed Microsoft AD với trust một chiều tới AD tại chỗ, dùng IAM role ánh xạ nhóm AD — đây là phương án gần nhất và hoàn toàn khả thi, nhưng nó nhiều việc hơn hẳn: phải vận hành thêm một thư mục trên AWS, thiết lập và duy trì quan hệ trust, rồi vẫn phải tạo và quản lý IAM role trong từng tài khoản. Identity Center làm hết phần cuối đó.
• **C. Dựng nhà cung cấp danh tính OIDC riêng tích hợp AD — tự dựng thứ AWS đã cung cấp: phải vận hành một IdP, tự lo phát hành token, tự cấu hình IAM role tin cậy IdP đó ở mỗi tài khoản.
• **D. Tạo IAM user riêng cho từng người ở từng tài khoản — công vận hành cao nhất và kém an toàn nhất: nhân số người × số tài khoản, access key dài hạn, và không dùng lại được AD hiện có. AWS Config không sửa được vấn đề gốc này.

Ghi nhớ

Ba dịch vụ thư mục của AWS — bảng phải thuộc: | Dịch vụ | Đặc điểm | |---|---| | AWS Managed Microsoft AD | AD THẬT chạy trên AWS, lập trust được | | AD Connector | PROXY — không lưu dữ liệu, uỷ quyền về AD tại chỗ | | Simple AD | AD tối giản (Samba), cho nhu cầu cơ bản |

Từ khoá nhận diện:

"existing on-prem AD" + "multiple accounts" + "least overhead" → IAM Identity Center + AD Connector "need AD features ON AWS" (Windows join, group policy) → AWS Managed Microsoft AD "SAML from Okta / Entra ID" → Identity Center với IdP ngoài

Ba nguồn danh tính cho IAM Identity Center: | Nguồn | Khi nào | |---|---| | Identity Center directory | không có IdP sẵn | | Active Directory (Managed AD hoặc AD Connector) | có AD ← câu này | | IdP ngoài qua SAML 2.0 | Okta, Entra ID, Google |

Ba khái niệm cốt lõi: | Khái niệm | Nghĩa | |---|---| | Permission set | tập quyền tái dùng được | | Account assignment | gán (người/nhóm) × (permission set) × (tài khoản) | | Session duration | 1 giờ tới 12 giờ |

Ba cách xây permission set: | Cách | Chi tiết | |---|---| | AWS managed policy | nhanh nhất | | Customer managed policy | dùng chung, dễ kiểm soát | | Inline policy | riêng cho permission set đó |

⚠ Customer managed policy phải tồn tại ở MỌI tài khoản đích:

Permission set tham chiếu policy tên "ChinhSachVanHanh"
    → tài khoản nào không có policy đó
    → gán quyền THẤT BẠI
        ↓
    Triển khai policy bằng CloudFormation StackSets trước

Ba lợi ích bảo mật: | Lợi ích | Chi tiết | |---|---| | Không có access key dài hạn | | | Credential tạm, tự hết hạn | | | Mọi lần đăng nhập ghi vào CloudTrail | |

Ba lưu ý về AD Connector: | Lưu ý | Chi tiết | |---|---| | KHÔNG lưu dữ liệu thư mục | chỉ chuyển tiếp | | Cần kết nối mạng ổn định tới AD | DX hoặc VPN | | AD tại chỗ chết = không ai đăng nhập được | |

Vế cuối là rủi ro phải cân nhắc:

AD Connector phụ thuộc hoàn toàn vào AD tại chỗ
    → mất kết nối DX → không ai vào được AWS
        ↓
    Cân nhắc: AWS Managed AD với trust hai chiều
    → có bản sao thư mục trên AWS, chịu được mất kết nối
    → nhưng nhiều việc hơn

Ba yêu cầu mạng cho AD Connector: | Yêu cầu | Chi tiết | |---|---| | Kết nối tới AD (DX hoặc VPN) | | | Cổng DNS (53), LDAP (389), Kerberos (88) | | | Hai subnet ở hai AZ | |

Ba lưu ý khi triển khai: | Lưu ý | Chi tiết | |---|---| | Bật Identity Center ở tài khoản QUẢN LÝ | | | Uỷ quyền quản trị cho một tài khoản riêng | thực hành tốt | | Ánh xạ nhóm AD, đừng gán cho từng người | |

Vế cuối là nguyên tắc quan trọng:

Gán quyền cho NHÓM AD
    → thêm người mới: chỉ cần thêm vào nhóm AD
    → không phải đụng gì tới AWS
        ↓
    Gán cho từng người là quay lại đúng vấn đề cũ

Ba lưu ý về ABAC: | Lưu ý | Chi tiết | |---|---| | Truyền thuộc tính AD làm session tag | | | Chính sách dùng aws:PrincipalTag | | | Giảm số permission set cần tạo | |

{"Effect": "Allow", "Action": "ec2:StopInstances", "Resource": "*",
 "Condition": {"StringEquals":
   {"ec2:ResourceTag/doi": "${aws:PrincipalTag/doi}"}}}

Một permission set duy nhất phục vụ mọi đội
    → mỗi người chỉ thao tác được trên tài nguyên của đội mình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng nhập thử bằng tài khoản AD | | | Kiểm tra thấy đúng danh sách tài khoản | | | Khoá một tài khoản AD, xác nhận mất quyền | |

Và một lời khuyên: hãy quyết định giữa AD Connector và Managed AD dựa trên việc bạn chịu được bao lâu khi mất kết nối tới trung tâm dữ liệu. AD Connector ít việc hơn thật, nhưng nó biến đường mạng tới AD tại chỗ thành phụ thuộc cứng cho mọi lần đăng nhập vào AWS — kể cả lúc bạn cần vào AWS chính vì trung tâm dữ liệu đang có sự cố.

Đáp án

D — Tạo read replica của CSDL chính và hướng truy vấn của đội phân tích vào replica đó.

Vì sao đúng

Đề nêu bốn dữ kiện, và read replica khớp cả bốn: | Dữ kiện | Cách đáp ứng | |---|---| | Truy vấn CHỈ ĐỌC (read-only SQL) | replica phục vụ đọc | | Quá nhiều truy vấn làm CSDL chậm | tách tải sang máy khác | | Phải chạy trên DỮ LIỆU MỚI NHẤT | replica đồng bộ liên tục | | THAY ĐỔI ÍT NHẤT với ứng dụng web | ứng dụng không đụng gì, chỉ đổi endpoint cho analyst |

Vì sao "dữ liệu mới nhất" là ràng buộc quyết định:

Yêu cầu này loại mọi phương án phải SAO CHÉP dữ liệu đi nơi khác
    → Redshift: phải nạp định kỳ → dữ liệu cũ
    → S3 + Athena: phải xuất định kỳ → dữ liệu cũ
        ↓
    Read replica đồng bộ liên tục, độ trễ thường dưới một giây

Và "thay đổi ít nhất" củng cố lựa chọn:

Read replica là cùng engine, cùng schema, cùng cú pháp SQL
    → analyst chạy y nguyên truy vấn cũ
    → chỉ đổi chuỗi kết nối
        ↓
    Redshift và Athena đều là phương ngữ SQL khác
    → phải viết lại truy vấn

Tạo read replica:

aws rds create-db-instance-read-replica   --db-instance-identifier csdl-bao-cao   --source-db-instance-identifier csdl-chinh   --db-instance-class db.m6g.xlarge

Kiến trúc sau khi làm:

Ứng dụng web ──▶ CSDL chính (đọc + ghi)
                        │ sao chép bất đồng bộ
                        ▼
Đội phân tích ──▶ Read replica (chỉ đọc)
        ↓
    Truy vấn nặng không còn ảnh hưởng ứng dụng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cô lập tải phân tích khỏi tải giao dịch | | | Có thể chọn cấu hình máy khác cho replica | to hơn cho truy vấn nặng | | Thêm replica nữa nếu analyst tăng lên | |

Vế thứ hai đáng khai thác:

CSDL chính: tối ưu cho nhiều giao dịch nhỏ
Replica:    có thể dùng máy nhiều RAM hơn cho truy vấn quét lớn
        ↓
    Hai tải khác nhau, hai cấu hình khác nhau

Và có thể tinh chỉnh riêng cho replica:

Đặt parameter group riêng cho replica
    → tăng work_mem, tăng thời gian truy vấn tối đa
        ↓
    Không ảnh hưởng CSDL chính

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

• **A. Nạp dữ liệu vào Amazon Redshift rồi cho analyst truy vấn ở đó — đây là phương án gần nhất và là kiến trúc đúng cho phân tích quy mô lớn, nhưng nó thất bại ở hai ràng buộc: dữ liệu phải nạp định kỳ nên không phải "latest data", và analyst phải làm quen phương ngữ SQL của Redshift.
• **C. Xuất ra S3 và dùng Athena — cùng vấn đề: dữ liệu chỉ mới tới lần xuất gần nhất, và Athena dùng Presto SQL với cú pháp khác. Thêm cả một quy trình ETL phải xây và bảo trì.
• **B. Nạp vào ElastiCache rồi truy vấn ở đó — sai loại kho dữ liệu: ElastiCache là bộ nhớ đệm key-value (Redis/Memcached), không chạy SQL. Không thể "run queries against the ElastiCache endpoint" theo nghĩa SQL.

Ghi nhớ

Ba cách giảm tải đọc cho CSDL — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Read replica | cùng engine, dữ liệu gần thời gian thực ← câu này | | ElastiCache | cache kết quả, giảm truy vấn lặp | | Data warehouse (Redshift) | phân tích lớn, dữ liệu theo lô |

Từ khoá nhận diện:

"read-only queries" + "latest data" + "minimal changes" → read replica "same query repeated many times" → ElastiCache "complex analytics over years of data" → Redshift "query files in S3 with SQL" → Athena

⚠ Read replica và Multi-AZ — bảng phân biệt bắt buộc: | | Read Replica | Multi-AZ | |---|---|---| | Mục đích | HIỆU NĂNG đọc | TÍNH SẴN SÀNG | | Sao chép | bất đồng bộ | đồng bộ | | Phục vụ đọc | ✅ | ❌ standby nằm chờ | | Chuyển đổi | thủ công (promote) | tự động | | Vị trí | cùng vùng hoặc vùng khác | AZ khác cùng vùng |

Dòng "standby không phục vụ đọc" là hiểu nhầm phổ biến nhất về RDS.

Ba đặc điểm của read replica: | Đặc điểm | Chi tiết | |---|---| | Tối đa 5 replica (RDS), 15 (Aurora) | | | Có replica lag | dữ liệu có thể trễ vài giây | | Promote thành CSDL độc lập được | |

Vế thứ hai là điều phải nói rõ với analyst:

Sao chép BẤT ĐỒNG BỘ
    → replica có thể trễ so với chính
    → tải ghi nặng làm lag tăng
        ↓
    "Latest data" ở đây nghĩa là gần thời gian thực,
    không phải nhất quán tuyệt đối
    → theo dõi metric ReplicaLag

Ba nguyên nhân replica lag cao: | Nguyên nhân | Chi tiết | |---|---| | Ghi nhiều ở CSDL chính | | | Replica cấu hình yếu hơn chính | | | Truy vấn dài trên replica chặn việc áp thay đổi | |

Vế thứ ba đáng nhớ với PostgreSQL:

Truy vấn phân tích chạy hàng chục phút trên replica
    → có thể chặn việc áp WAL
    → hoặc bị huỷ do xung đột (conflict)
        ↓
    Điều chỉnh max_standby_streaming_delay
    hoặc bật hot_standby_feedback

Ba lưu ý về Aurora (nếu dùng Aurora): | Lưu ý | Chi tiết | |---|---| | Replica chia sẻ CÙNG tầng lưu trữ | lag thường < 100 ms | | Reader endpoint cân bằng tự động | | | Custom endpoint gom vài replica cho báo cáo | |

Custom endpoint là nâng cấp tự nhiên của câu này:

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

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Replica tính phí như một instance đầy đủ | | | Cross-region replica thêm phí truyền | | | Có thể dùng cấu hình nhỏ hơn nếu tải nhẹ | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ReplicaLag | độ trễ dữ liệu | | CPUUtilization của replica | có đủ sức không | | DatabaseConnections | analyst có kết nối vào không |

Ba lưu ý khi chuyển analyst sang replica: | Lưu ý | Chi tiết | |---|---| | Cấp tài khoản CSDL chỉ đọc | | | Ghi tài liệu về replica lag | | | Đặt thời gian tối đa cho truy vấn | |

Vế cuối tránh được sự cố:

-- PostgreSQL
ALTER ROLE analyst SET statement_timeout = '30min';

Một truy vấn viết nhầm không quét vô hạn
    → và không làm lag tăng mãi

Ba dấu hiệu cần nâng cấp lên data warehouse: | Dấu hiệu | Chi tiết | |---|---| | Truy vấn quét hàng trăm triệu dòng | | | Cần dữ liệu lịch sử nhiều năm | | | Replica lag tăng vì truy vấn phân tích | |

Và một lời khuyên: hãy đặt statement_timeout cho tài khoản của đội phân tích ngay khi tạo replica. Read replica giải quyết được việc truy vấn nặng làm chậm ứng dụng, nhưng một truy vấn chạy vô tận trên replica vẫn khiến độ trễ sao chép tăng dần — và lúc đó "dữ liệu mới nhất" không còn đúng nữa.

Đáp án

C — Tạo Route 53 alias record trỏ tới một CloudFront distribution với ALB làm origin, rồi cấu hình custom error page cho distribution.

Vì sao đúng

Đề nêu hai yêu cầu, và CloudFront custom error page giải quyết trọn vẹn: | Yêu cầu | Cách đáp ứng | |---|---| | Hiện trang lỗi tĩnh khi website không truy cập được | CloudFront trả trang lỗi tuỳ chỉnh | | ÍT công vận hành nhất | một tính năng cấu hình, không có health check hay DNS phải quản |

Cách hoạt động:

Người dùng ──▶ CloudFront ──▶ ALB (origin)
                    │
                    └─ origin trả 502/503/504
                       hoặc không trả lời
                            ↓
                    CloudFront trả trang lỗi
                    đã cấu hình sẵn

Cấu hình custom error response:

{"CustomErrorResponses": {"Quantity": 3, "Items": [
  {"ErrorCode": 502, "ResponsePagePath": "/loi.html",
   "ResponseCode": "503", "ErrorCachingMinTTL": 30},
  {"ErrorCode": 503, "ResponsePagePath": "/loi.html",
   "ResponseCode": "503", "ErrorCachingMinTTL": 30},
  {"ErrorCode": 504, "ResponsePagePath": "/loi.html",
   "ResponseCode": "503", "ErrorCachingMinTTL": 30}]}}

Vì sao đây là "ít công nhất": | So với | CloudFront hơn ở chỗ | |---|---| | Route 53 failover | không cần health check, không phụ thuộc TTL DNS | | Weighted routing thủ công | không cần ai can thiệp khi có sự cố | | EC2 dự phòng | không có máy nào phải nuôi |

Vế thứ nhất là điểm mấu chốt:

Route 53 failover:
    → health check phát hiện (30-90 giây)
    → đổi bản ghi DNS
    → client phải chờ TTL hết hạn mới thấy
        ↓
    Tổng có thể vài phút, và client cache lâu thì lâu hơn

CloudFront:
    → phát hiện ngay ở tầng HTTP
    → trả trang lỗi cho CHÍNH request đó
        ↓
    Không có DNS nào phải đổi

Ba lợi ích phụ: | Lợi ích | Chi tiết | |---|---| | CloudFront còn tăng tốc website lúc bình thường | | | Có thể gắn WAF vào distribution | | | Cache giảm tải cho ALB | |

Đặt trang lỗi ở đâu:

Dùng origin group với S3 làm origin phụ
    → hoặc đặt loi.html trong chính origin (nếu còn sống một phần)
    → hoặc dùng CloudFront Function trả HTML trực tiếp

Origin group cho dự phòng đầy đủ:

{"OriginGroups": {"Quantity": 1, "Items": [{
  "Id": "nhom-goc", "FailoverCriteria": {"StatusCodes":
    {"Quantity": 3, "Items": [500, 502, 503]}},
  "Members": {"Quantity": 2, "Items": [
    {"OriginId": "alb-chinh"}, {"OriginId": "s3-trang-loi"}]}}]}}

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

• **B. Dùng Route 53 active-passive failover với S3 static website làm bản ghi phụ — đây là phương án gần nhất và thực sự hoạt động, nhưng nó nhiều việc hơn: phải tạo và duy trì health check, phụ thuộc TTL của DNS (client cache có thể vẫn trỏ về ALB đã chết), và thời gian chuyển lâu hơn.
• **A. Dùng weighted routing với trọng số 0, tăng trọng số khi có sự cố — đây là thao tác THỦ CÔNG: phải có người phát hiện sự cố và vào sửa DNS. Công vận hành cao nhất trong bốn phương án.
• **D. Active-active với ALB và một EC2 chạy trang lỗi — mô tả sai cách active-active hoạt động (nó chia tải cho cả hai, không phải chỉ gửi khi health check hỏng), và phải nuôi một EC2 chỉ để phục vụ một trang HTML tĩnh.

Ghi nhớ

Ba cách hiện trang lỗi khi backend chết — bảng phải thuộc: | Cách | Phát hiện | Công vận hành | |---|---|---| | CloudFront custom error page | tầng HTTP, tức thì | thấp nhất ← câu này | | Route 53 failover + S3 | health check + DNS TTL | trung bình | | ALB fixed-response rule | chỉ khi ALB còn sống | thấp |

ALB fixed-response cũng đáng biết:

aws elbv2 create-rule --listener-arn <arn> --priority 100   --conditions Field=path-pattern,Values='/*'   --actions '[{"Type":"fixed-response","FixedResponseConfig":{
    "StatusCode":"503","ContentType":"text/html",
    "MessageBody":"<h1>Bảo trì</h1>"}}]'

Hoạt động khi TARGET chết nhưng ALB còn sống
    → không giúp gì khi cả ALB có vấn đề

Từ khoá nhận diện:

"static error page" + "least operational overhead" → CloudFront custom error page "failover to another Region" → Route 53 failover "maintenance mode" → ALB fixed-response hoặc CloudFront

Ba nhóm mã lỗi CloudFront xử lý được: | Nhóm | Mã | |---|---| | 4xx từ origin | 400, 403, 404, 405, 414, 416 | | 5xx từ origin | 500, 501, 502, 503, 504 | | CloudFront tự sinh | khi không nối được origin |

Ba tham số của custom error response: | Tham số | Việc | |---|---| | ErrorCode | mã lỗi từ origin | | ResponsePagePath | đường dẫn tới trang lỗi | | ResponseCode | mã trả về cho client (đổi được) | | ErrorCachingMinTTL | cache trang lỗi bao lâu |

⚠ ErrorCachingMinTTL là tham số cần đặt cẩn thận:

Đặt quá dài (ví dụ 300 giây)
    → website đã phục hồi sau 60 giây
    → client vẫn thấy trang lỗi thêm 4 phút
        ↓
    Đặt ngắn (10-30 giây) cho lỗi 5xx

Và ResponseCode có ý nghĩa SEO:

Trả 200 kèm nội dung "website đang lỗi"
    → công cụ tìm kiếm tưởng đó là nội dung thật
    → có thể index trang lỗi
        ↓
    Trả 503 để báo "tạm thời không phục vụ"

Ba lưu ý về origin group: | Lưu ý | Chi tiết | |---|---| | Chỉ chuyển với GET, HEAD, OPTIONS | không với POST | | Chỉ chuyển theo mã lỗi đã khai | | | Origin phụ nên là S3 static website | |

Vế đầu là giới hạn quan trọng:

Origin group KHÔNG chuyển dự phòng cho request POST
    → form gửi lên vẫn lỗi
        ↓
    Nó dành cho nội dung đọc, không phải cho ghi

Ba lưu ý về Route 53 health check (nếu dùng cách B): | Tham số | Ảnh hưởng | |---|---| | RequestInterval | 30 giây (hoặc 10 giây fast) | | FailureThreshold | số lần hỏng liên tiếp | | TTL của record | client cache DNS bao lâu |

TTL là chỗ hay bị bỏ qua:

Health check phát hiện trong 90 giây
    → TTL 300 giây → client vẫn dùng IP cũ thêm 5 phút
        ↓
    Tổng thời gian ngừng thực tế gần 7 phút

Ba lưu ý khi đặt CloudFront trước ALB: | Lưu ý | Chi tiết | |---|---| | Alias record trỏ tới distribution, không phải ALB | | | Chứng chỉ ACM phải ở us-east-1 | | | Giới hạn ALB chỉ nhận từ CloudFront | |

Vế thứ hai là ràng buộc kỹ thuật hay quên:

CloudFront chỉ dùng chứng chỉ ACM ở vùng us-east-1
    → chứng chỉ tạo ở vùng khác không chọn được
        ↓
    Bất kể website chạy ở vùng nào

Vế thứ ba nên làm:

aws wafv2 ... # hoặc dùng header bí mật

Thêm custom header ở CloudFront
    → ALB listener rule chỉ chấp nhận request có header đó
        ↓
    Không ai vào thẳng ALB, bỏ qua CloudFront và WAF

Ba lưu ý về cache cho nội dung động: | Lưu ý | Chi tiết | |---|---| | Dùng CachingDisabled policy cho đường dẫn động | | | Forward cookie và header cần thiết | | | Cache nội dung tĩnh với TTL dài | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tắt hết target của ALB, xem trang lỗi hiện chưa | | | Đo thời gian từ lúc hỏng tới lúc thấy trang lỗi | | | Bật lại, xem bao lâu website trở về bình thường | |

Và một lời khuyên: hãy đặt ErrorCachingMinTTL ngắn và thử nghiệm chu kỳ phục hồi, đừng chỉ thử chu kỳ hỏng. Điều người dùng nhớ không phải là trang lỗi đẹp, mà là website mất bao lâu để trở lại — và một giá trị TTL đặt rộng tay có thể kéo dài sự cố thêm nhiều phút sau khi mọi thứ đã hoạt động trở lại.

Đáp án

B — Đặt tài liệu JSON vào S3 bucket; khi tài liệu tới, Lambda chạy mã Python xử lý; kết quả lưu vào Aurora.

Vì sao đúng

Đề nêu bốn yêu cầu, và kiến trúc serverless này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Ứng dụng Python NHỎ xử lý JSON | hợp hoàn hảo với Lambda | | Chạy hàng NGHÌN lần mỗi ngày | Lambda tự co giãn theo sự kiện | | Tính sẵn sàng cao | S3, Lambda, Aurora đều đa AZ sẵn | | Tối đa khả năng mở rộng, tối thiểu công vận hành | không có máy chủ nào |

Vì sao mô hình sự kiện là đúng:

Tài liệu tới S3 → S3 Event Notification → Lambda chạy
        ↓
    Không có tiến trình nào phải chạy chờ việc
    → không trả tiền lúc không có tài liệu
    → 1.000 tài liệu tới cùng lúc → 1.000 lần gọi song song

Cấu hình:

aws s3api put-bucket-notification-configuration --bucket tai-lieu-json   --notification-configuration '{"LambdaFunctionConfigurations":[{
    "LambdaFunctionArn":"arn:aws:lambda:...:function:xu-ly-json",
    "Events":["s3:ObjectCreated:*"],
    "Filter":{"Key":{"FilterRules":[{"Name":"suffix","Value":".json"}]}}}]}'

Hàm Lambda:

import json, boto3, os
s3 = boto3.client('s3')

def handler(event, context):
    for ban_ghi in event['Records']:
        bucket = ban_ghi['s3']['bucket']['name']
        khoa = ban_ghi['s3']['object']['key']
        noi_dung = json.loads(
            s3.get_object(Bucket=bucket, Key=khoa)['Body'].read())
        ket_qua = xu_ly(noi_dung)
        ghi_vao_aurora(ket_qua)

Vì sao Aurora chứ không phải RDS thường: | Lý do | Chi tiết | |---|---| | Sao chép sang 3 AZ ở tầng lưu trữ | tính sẵn sàng cao hơn | | Tự sửa lỗi lưu trữ, tự mở rộng tới 128 TB | | | Chuyển đổi dự phòng nhanh hơn RDS | | | Aurora Serverless v2 co giãn theo tải | |

Ba lợi ích của kiến trúc này: | Lợi ích | Chi tiết | |---|---| | Không quản lý máy chủ nào | | | Trả tiền theo mili giây thực chạy | | | Co giãn từ 0 tới hàng nghìn tức thì | |

Và có một chi tiết bắt buộc phải xử lý:

Lambda mở kết nối CSDL mỗi lần chạy
    → 1.000 lần gọi song song = 1.000 kết nối
    → Aurora chạm giới hạn max_connections
        ↓
    Dùng RDS Proxy để gộp kết nối
    → hoặc dùng Aurora Data API (HTTP, không giữ kết nối)

RDS Proxy:

aws rds create-db-proxy --db-proxy-name proxy-aurora   --engine-family POSTGRESQL --role-arn <arn-role>   --auth '[{"AuthScheme":"SECRETS","SecretArn":"<arn-secret>","IAMAuth":"REQUIRED"}]'   --vpc-subnet-ids subnet-a subnet-b

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

• **C. Đặt tài liệu vào S3 rồi chạy mã Python trên nhiều EC2 — đây là phương án gần nhất vì cùng dùng S3 và Aurora, nhưng nó giữ lại toàn bộ công vận hành: phải vá lỗi máy, phải cấu hình Auto Scaling, phải viết cơ chế lấy việc, và trả tiền cả lúc không có tài liệu nào.
• **D. Đưa tài liệu vào SQS rồi chạy container Python trên ECS launch type EC2 — cũng hoạt động, nhưng launch type EC2 nghĩa là vẫn phải quản lý cụm máy chủ. Nếu là Fargate thì gần hơn, nhưng vẫn nhiều việc hơn Lambda cho một ứng dụng nhỏ chạy theo sự kiện.
• **A. Dùng EBS Multi-Attach cho tài liệu JSON, gắn vào nhiều EC2 — Multi-Attach chỉ dùng được trong một AZ và chỉ với io1/io2, nên không đạt tính sẵn sàng cao. Và dùng lưu trữ khối chia sẻ để phát tài liệu là mô hình rất dễ sinh xung đột.

Ghi nhớ

Ba mức "không quản lý máy chủ" — bảng phải thuộc: | Mức | Dịch vụ | Bạn quản lý | |---|---|---| | Serverless hàm | Lambda | chỉ mã ← câu này | | Container serverless | Fargate | container | | Container tự quản | ECS/EKS trên EC2 | cụm + máy |

Từ khoá nhận diện:

"small script" + "thousands of times daily" + "minimal overhead" → Lambda "long-running", "> 15 phút" → Fargate hoặc Batch "event-driven from S3" → S3 Event Notification → Lambda

⚠ Ba giới hạn của Lambda phải thuộc: | Giới hạn | Con số | |---|---| | Thời gian chạy tối đa | 15 phút | | Bộ nhớ | 128 MB - 10.240 MB | | Payload đồng bộ | 6 MB | | /tmp | 512 MB - 10 GB |

Nếu xử lý một tài liệu vượt 15 phút thì Lambda không dùng được — chuyển sang Fargate hoặc Step Functions.

Ba cách kích hoạt Lambda từ S3: | Cách | Đặc điểm | |---|---| | S3 Event Notification trực tiếp | đơn giản nhất ← câu này | | EventBridge | lọc và định tuyến phức tạp hơn | | SQS ở giữa | có đệm và thử lại tốt hơn |

Thêm SQS vào giữa đáng cân nhắc:

S3 → SQS → Lambda
    → SQS đệm khi Lambda bị giới hạn đồng thời
    → có dead-letter queue cho tài liệu lỗi
    → xử lý theo lô (tới 10 thông điệp một lần gọi)
        ↓
    Bền hơn, nhưng thêm một thành phần

⚠ S3 Event Notification giao ÍT NHẤT MỘT LẦN:

Cùng một tệp có thể kích hoạt Lambda hai lần
    → ghi vào CSDL hai bản ghi trùng
        ↓
    Hàm phải idempotent
    → dùng khoá chính suy ra từ tên tệp
    → hoặc kiểm tra đã xử lý chưa trước khi ghi

Ba vấn đề kết nối CSDL từ Lambda: | Vấn đề | Cách chữa | |---|---| | Bùng nổ số kết nối | RDS Proxy | | Khởi động lạnh khi ở trong VPC | Hyperplane ENI đã cải thiện nhiều | | Mật khẩu trong mã | Secrets Manager |

Aurora Data API là lựa chọn đáng biết:

import boto3
rds = boto3.client('rds-data')
rds.execute_statement(
    resourceArn='arn:aws:rds:...:cluster:cum-aurora',
    secretArn='arn:aws:secretsmanager:...:secret:db-abc',
    database='ungdung',
    sql='INSERT INTO ket_qua (ma, gia_tri) VALUES (:ma, :gt)',
    parameters=[{'name':'ma','value':{'stringValue':'A1'}},
                {'name':'gt','value':{'doubleValue':3.14}}])

Gọi qua HTTP, KHÔNG giữ kết nối
    → không có vấn đề bùng nổ kết nối
    → Lambda không cần nằm trong VPC
        ↓
    Đánh đổi: độ trễ cao hơn kết nối trực tiếp

Ba lưu ý về đồng thời (concurrency): | Lưu ý | Chi tiết | |---|---| | Giới hạn mặc định 1.000 mỗi vùng | xin tăng được | | Reserved concurrency giới hạn một hàm | bảo vệ CSDL | | Provisioned concurrency giảm khởi động lạnh | |

Reserved concurrency là công cụ bảo vệ CSDL:

aws lambda put-function-concurrency --function-name xu-ly-json   --reserved-concurrent-executions 50

Giới hạn 50 lần chạy song song
    → tối đa 50 kết nối tới CSDL
    → phần còn lại xếp hàng chờ

Ba lưu ý về xử lý lỗi: | Lưu ý | Chi tiết | |---|---| | Cấu hình dead-letter queue hoặc destination | | | Lambda tự thử lại 2 lần với gọi bất đồng bộ | | | Ghi log chi tiết vào CloudWatch | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính theo GB-giây và số lần gọi | | | Tăng bộ nhớ có thể GIẢM tổng chi phí | chạy nhanh hơn | | Graviton (arm64) rẻ hơn ~20% | |

Vế thứ hai là điều nhiều người không ngờ:

128 MB, chạy 10 giây  → 1,28 GB-giây
512 MB, chạy 2 giây   → 1,02 GB-giây
        ↓
    Nhiều RAM hơn = nhiều CPU hơn = có thể RẺ HƠN
    → dùng AWS Lambda Power Tuning để tìm điểm tối ưu

Và một lời khuyên: hãy đặt reserved concurrency cho hàm ghi vào CSDL ngay từ đầu. Lambda co giãn nhanh hơn nhiều so với khả năng chịu kết nối của một CSDL quan hệ, và một đợt hàng nghìn tài liệu đổ vào cùng lúc sẽ hạ gục Aurora trước khi bạn kịp nhận ra rằng chính khả năng mở rộng là thứ gây ra sự cố.

Đáp án

C — Dùng Amazon VPC CNI plugin cho Kubernetes, cấu hình custom subnet trong VPC và liên kết chúng với cụm EKS để pod dùng.

Vì sao đúng

Đề nêu ba yêu cầu, và VPC CNI là cơ chế gốc của EKS cho việc này: | Yêu cầu | Cách đáp ứng | |---|---| | Pod phải dùng SUBNET TUỲ CHỈNH trong VPC có sẵn | VPC CNI cấp IP thật từ subnet cho pod | | Pod giao tiếp AN TOÀN với tài nguyên khác trong VPC | pod có IP riêng, gắn security group được | | Tuân thủ quy định | lưu lượng không rời VPC, kiểm soát bằng SG |

VPC CNI làm gì:

Không có VPC CNI (mạng overlay như Calico thuần):
    → pod có IP ảo trong mạng riêng của cluster
    → tài nguyên khác trong VPC không định tuyến tới được
    → phải NAT qua node

Có VPC CNI:
    → mỗi pod nhận một IP THẬT từ subnet VPC
    → RDS, ALB, EC2 khác nhìn thấy IP đó trực tiếp
        ↓
    Đây là điều đề đang mô tả

Cấu hình custom networking:

kubectl set env daemonset aws-node -n kube-system   AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

kubectl set env daemonset aws-node -n kube-system   ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone

Rồi khai ENIConfig cho mỗi AZ:

apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
  name: ap-southeast-1a
spec:
  subnet: subnet-tuy-chinh-a
  securityGroups:
    - sg-cho-pod

Vì sao gọi là "custom networking":

Mặc định: pod lấy IP từ CÙNG subnet với node
    → subnet node hết IP là không tạo được pod

Custom networking: pod lấy IP từ subnet KHÁC
    → thường là subnet CIDR phụ (100.64.0.0/16)
    → node và pod tách bạch về địa chỉ
        ↓
    Giải quyết cả vấn đề cạn IP

Và security group cho từng pod:

apiVersion: vpcresources.k8s.aws/v1beta1
kind: SecurityGroupPolicy
metadata:
  name: chinh-sach-pod-csdl
spec:
  podSelector:
    matchLabels:
      vai-tro: ket-noi-csdl
  securityGroups:
    groupIds:
      - sg-truy-cap-csdl

Pod có security group riêng
    → RDS chỉ cho phép sg-truy-cap-csdl
    → pod khác trong cùng cluster KHÔNG vào được CSDL
        ↓
    Đây là cách đáp ứng "compliance requirements"

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Pod là công dân hạng nhất của VPC | | | VPC Flow Logs thấy lưu lượng pod | | | Không có tầng NAT hay overlay | |

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

• **D. Định nghĩa Kubernetes network policy ép pod chạy trên node ở subnet tuỳ chỉnh — đây là phương án gần nhất vì cũng nói về mạng của pod, nhưng nó nhầm hai khái niệm: network policy kiểm soát lưu lượng giữa các pod, còn việc quyết định pod chạy ở đâu là node selector / affinity. Và cả hai đều không quyết định pod lấy IP từ subnet nào — đó là việc của CNI.
• **A. Dùng Transit Gateway định tuyến giữa custom subnet và pod — Transit Gateway nối các VPC với nhau; ở đây mọi thứ nằm trong cùng một VPC, không có gì để nối.
• **B. Dựng Site-to-Site VPN giữa custom subnet và cụm EKS — VPN dùng để nối mạng tại chỗ với AWS. Dựng VPN trong cùng một VPC là vô nghĩa.

Ghi nhớ

Ba khái niệm mạng EKS dễ lẫn — bảng phải thuộc: | Khái niệm | Quyết định | |---|---| | CNI plugin | pod lấy IP từ đâu | | Network policy | pod nào nói chuyện được với pod nào | | Node selector / affinity | pod chạy trên node nào |

Từ khoá nhận diện:

"pods must use specific subnets" → VPC CNI custom networking "control pod-to-pod traffic" → network policy (Calico hoặc VPC CNI network policy) "security group per pod" → security groups for pods

Ba đặc điểm của Amazon VPC CNI: | Đặc điểm | Chi tiết | |---|---| | Pod nhận IP THẬT từ subnet VPC | | | Là CNI mặc định của EKS | | | Số pod mỗi node phụ thuộc loại instance | |

⚠ Giới hạn IP là vấn đề lớn nhất của VPC CNI:

Số pod tối đa mỗi node = (số ENI) × (số IP mỗi ENI - 1)

Ví dụ t3.medium: 3 ENI × (6 - 1) = 15 pod
        ↓
    Node to hơn = nhiều pod hơn
    → và mỗi pod ăn một IP của subnet

Ba cách giải quyết cạn IP: | Cách | Chi tiết | |---|---| | Custom networking với CIDR phụ | 100.64.0.0/16 (không định tuyến ra ngoài) | | Prefix delegation | mỗi ENI nhận /28, tăng số pod nhiều lần | | Subnet lớn hơn | |

Prefix delegation đáng bật:

kubectl set env daemonset aws-node -n kube-system   ENABLE_PREFIX_DELEGATION=true

Mỗi ENI nhận một prefix /28 (16 IP) thay vì từng IP lẻ
    → t3.medium từ 15 pod lên tới 110 pod

Thêm CIDR phụ vào VPC:

aws ec2 associate-vpc-cidr-block --vpc-id vpc-abc   --cidr-block 100.64.0.0/16

Dải 100.64.0.0/10 là dải chia sẻ của nhà mạng (RFC 6598)
    → không xung đột với mạng công ty
    → dùng riêng cho pod là thực hành phổ biến

Ba lưu ý về custom networking: | Lưu ý | Chi tiết | |---|---| | ENIConfig phải có cho MỖI AZ | | | Node MẤT một số IP khả dụng | ENI chính không dùng cho pod | | Phải khởi động lại node sau khi bật | |

Vế thứ hai là chi phí ẩn:

Bật custom networking
    → ENI chính của node không cấp IP cho pod nữa
    → số pod tối đa mỗi node GIẢM
        ↓
    Kết hợp với prefix delegation để bù lại

Ba lưu ý về security groups for pods: | Lưu ý | Chi tiết | |---|---| | Chỉ hỗ trợ trên một số loại instance (Nitro) | | | Phải bật ENABLE_POD_ENI=true | | | Giảm số pod mỗi node | |

kubectl set env daemonset aws-node -n kube-system ENABLE_POD_ENI=true

Ba lựa chọn CNI cho EKS: | CNI | Đặc điểm | |---|---| | Amazon VPC CNI | mặc định, IP thật trong VPC | | Calico | network policy mạnh, thường dùng KÈM VPC CNI | | Cilium | eBPF, quan sát sâu |

Calico thường dùng bổ sung chứ không thay thế:

VPC CNI: cấp IP
Calico:  thực thi network policy
        ↓
    Hai việc khác nhau, dùng cùng nhau được

Ba cách kiểm soát lưu lượng pod: | Cách | Cấp | |---|---| | Security group cho pod | tầng VPC (AWS) | | Kubernetes NetworkPolicy | tầng cluster | | Service mesh (App Mesh, Istio) | tầng ứng dụng, mTLS |

Ba lưu ý về tuân thủ: | Lưu ý | Chi tiết | |---|---| | Bật VPC Flow Logs để ghi lưu lượng pod | | | Dùng private endpoint cho API server EKS | | | Bật audit log của control plane | |

aws eks update-cluster-config --name cum-cung-ung   --resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true   --logging '{"clusterLogging":[{"types":["audit","authenticator"],"enabled":true}]}'

Ba việc kiểm chứng: | Việc | Cách | |---|---| | kubectl get pods -o wide | xem IP pod thuộc subnet nào | | Thử kết nối từ pod tới RDS | | | Kiểm tra Flow Logs thấy IP pod | |

Và một lời khuyên: hãy tính số IP cần trước khi chọn CIDR cho subnet của pod. Với VPC CNI, mỗi pod ăn một địa chỉ thật, và một cụm chạy vài trăm pod sẽ cạn một subnet /24 rất nhanh — mở rộng CIDR sau đó là việc làm được, nhưng phải khởi động lại toàn bộ node group để nó có hiệu lực.

Đáp án

D — Dùng AWS Secrets Manager lưu thông tin đăng nhập CSDL, bật xoay tự động 30 ngày, và sửa ứng dụng lấy credential từ Secrets Manager.

Vì sao đúng

Đề nêu ba yêu cầu, và Secrets Manager làm đúng cả ba mà không cần viết mã: | Yêu cầu | Cách đáp ứng | |---|---| | Credential phải được MÃ HOÁ | mã hoá bằng KMS mặc định | | XOAY 30 ngày một lần | xoay tự động có sẵn | | Ít công vận hành, ứng dụng lấy được bản mới | Lambda xoay do AWS cung cấp |

Vì sao xoay tự động là điểm khác biệt:

Secrets Manager có sẵn Lambda xoay cho RDS/Aurora
    → AWS viết sẵn, bạn chỉ bật
        ↓
    Nó tự: tạo mật khẩu mới → cập nhật vào CSDL
           → cập nhật secret → kiểm tra kết nối

Bật xoay:

aws secretsmanager rotate-secret   --secret-id aurora/bang-xep-hang   --rotation-lambda-arn arn:aws:lambda:...:function:SecretsManagerRDSRotation   --rotation-rules AutomaticallyAfterDays=30

Hoặc để AWS tạo luôn cả Lambda:

aws secretsmanager create-secret --name aurora/bang-xep-hang   --secret-string '{"username":"admin","password":"...","engine":"postgres",
    "host":"cum.cluster-abc.ap-southeast-1.rds.amazonaws.com","port":5432,
    "dbClusterIdentifier":"cum-bang-xep-hang"}'   --kms-key-id alias/khoa-bi-mat

Ứng dụng lấy credential:

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

def lay_thong_tin():
    r = sm.get_secret_value(SecretId='aurora/bang-xep-hang')
    return json.loads(r['SecretString'])

tt = lay_thong_tin()
ket_noi(host=tt['host'], user=tt['username'], password=tt['password'])

⚠ Chiến lược hai bộ credential (alternating users) — chi tiết quan trọng:

Secrets Manager tạo MỘT NGƯỜI DÙNG THỨ HAI trong CSDL
    → lần xoay 1: dùng user_a, đổi mật khẩu user_b
    → lần xoay 2: chuyển sang user_b, đổi mật khẩu user_a
        ↓
    Luôn có một bộ credential HỢP LỆ trong lúc xoay
    → ứng dụng đang chạy không bị đứt kết nối

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không viết mã xoay | AWS cung cấp Lambda | | Ứng dụng lấy bản mới tự động | gọi API mỗi lần cần | | Mọi lần truy cập ghi vào CloudTrail | |

Và bảo vệ máy chủ game khỏi giới hạn tần suất:

Máy chủ game gọi GetSecretValue mỗi lần kết nối
    → chạm giới hạn tần suất API
        ↓
    Cache credential trong bộ nhớ, làm mới định kỳ
    → dùng AWS Secrets Manager Agent hoặc thư viện caching

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

• **B. Dùng Parameter Store SecureString và viết Lambda tự xoay — đây là phương án gần nhất và hoàn toàn làm được, nhưng bạn phải tự viết và bảo trì toàn bộ logic xoay: tạo mật khẩu, cập nhật CSDL, cập nhật tham số, xử lý lỗi giữa chừng. Đó chính là thứ Secrets Manager đã làm sẵn.
• **C. Lưu credential trong DynamoDB mã hoá KMS với Lambda xoay — cùng vấn đề tự viết, cộng thêm việc dùng sai công cụ: DynamoDB không có versioning của secret, không có staging label, không có cơ chế rollback khi xoay hỏng.
• **A. Dùng Amazon Cognito sinh credential CSDL tạm thời — sai vai trò dịch vụ: Cognito quản lý danh tính người dùng ứng dụng (đăng nhập, đăng ký), không cấp credential cho CSDL. Nó không có cơ chế nào làm việc này.

Ghi nhớ

Secrets Manager và Parameter Store — bảng phải thuộc: | | Secrets Manager | Parameter Store | |---|---|---| | Xoay tự động | ✅ có sẵn cho RDS | ❌ tự viết | | Giá | ~0,40 USD/secret/tháng | Standard MIỄN PHÍ | | Chia sẻ chéo tài khoản | ✅ | Advanced | | Nhân bản đa vùng | ✅ | ❌ | | Kích thước tối đa | 64 KB | 4 KB (Standard) / 8 KB |

Từ khoá nhận diện:

"rotate credentials automatically" → Secrets Manager "store config, free" → Parameter Store "user authentication for the app" → Cognito "no credentials at all" → IAM database authentication

⚠ IAM database authentication đáng biết — lựa chọn còn tốt hơn:

aws rds generate-db-auth-token --hostname cum.cluster-abc...   --port 5432 --username app_user --region ap-southeast-1

Không có mật khẩu nào cả
    → token sinh từ IAM, hạn 15 phút
    → không có gì để xoay
        ↓
    Nhưng có giới hạn số kết nối mỗi giây
    → và đề yêu cầu "credentials rotated" nên Secrets Manager là đáp án

Ba trạng thái (staging label) của secret: | Label | Nghĩa | |---|---| | AWSCURRENT | bản đang dùng | | AWSPENDING | bản mới đang được tạo | | AWSPREVIOUS | bản trước đó |

Bốn bước của Lambda xoay: | Bước | Việc | |---|---| | createSecret | sinh mật khẩu mới, gắn AWSPENDING | | setSecret | cập nhật mật khẩu trong CSDL | | testSecret | thử kết nối bằng credential mới | | finishSecret | chuyển AWSPENDING thành AWSCURRENT |

Bước testSecret là lý do nên dùng bản của AWS:

Nếu kết nối thử thất bại
    → KHÔNG chuyển label
    → AWSCURRENT vẫn là bản cũ đang chạy tốt
        ↓
    Xoay hỏng không làm sập ứng dụng

Hai chiến lược xoay: | Chiến lược | Đặc điểm | |---|---| | Single user | đổi mật khẩu của chính user đó | | Alternating users | hai user luân phiên — KHÔNG gián đoạn |

Single user: có một khoảnh khắc mật khẩu cũ đã đổi
             mà ứng dụng chưa lấy bản mới
        ↓
    Với ứng dụng chạy liên tục như máy chủ game,
    alternating users an toàn hơn

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Cache credential, đừng gọi API mỗi lần kết nối | | | Có giới hạn tần suất GetSecretValue | | | Dùng thư viện caching chính thức | |

Ba lưu ý về quyền: | Lưu ý | Chi tiết | |---|---| | Role của EC2 cần secretsmanager:GetSecretValue | | | Và kms:Decrypt cho khoá đã dùng | | | Resource policy giới hạn ai đọc được secret | |

Vế thứ hai là lỗi hay gặp:

Cấp GetSecretValue nhưng quên kms:Decrypt
    → AccessDeniedException nhắc tới KMS
    → dễ tưởng là lỗi của Secrets Manager

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | EC2 ở subnet riêng tư cần VPC endpoint | | | Interface endpoint cho Secrets Manager | | | Lambda xoay phải nối được tới CSDL | |

aws ec2 create-vpc-endpoint --vpc-id vpc-abc   --service-name com.amazonaws.ap-southeast-1.secretsmanager   --vpc-endpoint-type Interface --subnet-ids subnet-a subnet-b   --security-group-ids sg-endpoint

Vế thứ ba là chỗ hay gãy:

Lambda xoay do AWS tạo đặt ngoài VPC
    → không kết nối được tới Aurora trong subnet riêng tư
    → xoay thất bại
        ↓
    Phải cấu hình Lambda vào VPC và mở security group

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | ~0,40 USD mỗi secret mỗi tháng | | | Phí gọi API | | | Lambda xoay chạy mỗi 30 ngày — không đáng kể | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ép xoay một lần và quan sát | rotate-secret --rotate-immediately | | Kiểm tra ứng dụng không đứt kết nối | | | Xem CloudTrail ghi lại lần xoay | |

Và một lời khuyên: hãy ép xoay thủ công một lần vào giờ thấp điểm ngay sau khi cấu hình. Chu kỳ 30 ngày nghĩa là lần xoay tự động đầu tiên rơi vào một ngày bạn không nhớ — và nếu Lambda xoay không nối được tới CSDL vì thiếu cấu hình VPC, bạn sẽ phát hiện ra điều đó qua một sự cố chứ không phải qua một bài kiểm thử.

Đáp án

A — Dùng Amazon SQS làm nơi nhận dữ liệu GPS, và sửa ứng dụng để lấy thông điệp từ hàng đợi rồi xử lý.

Vì sao đúng

Đề nêu bốn dữ kiện, và SQS giải quyết đúng vấn đề gốc: | Dữ kiện | Vấn đề | Cách giải | |---|---|---| | Ứng dụng bị quá tải khi cao điểm | không có tầng đệm | hàng đợi hấp thụ | | MẤT dữ liệu, không phát lại được | dữ liệu chỉ tồn tại trong request | SQS giữ tới 14 ngày | | Cần co giãn hiệu quả | | co giãn theo độ dài hàng đợi | | Ít công vận hành nhất | | SQS được quản lý hoàn toàn |

Vấn đề thực sự nằm ở đâu:

Thiết bị GPS ──▶ ứng dụng trên 3 EC2 (đồng bộ)
        ↓
    Ứng dụng bận → request bị từ chối
    → dữ liệu vị trí BIẾN MẤT
    → không có bản sao nào để thử lại

Sau khi thêm SQS:

Thiết bị GPS ──▶ SQS (nhận ngay, lưu bền)
                    │
                    ▼
            Ứng dụng lấy khi xử lý được
        ↓
    Cao điểm: hàng đợi dài ra, KHÔNG MẤT gì
    → ứng dụng xử lý dần

Ba lợi ích đúng với từng câu chữ của đề: | Lợi ích | Câu trong đề | |---|---| | Lưu bền, không mất | "no location data is lost" | | Đọc lại được | "no way to replay the events" | | Đệm khi tải tăng | "overwhelmed" |

Và co giãn theo độ dài hàng đợi:

aws autoscaling put-scaling-policy --auto-scaling-group-name asg-xu-ly-gps   --policy-name theo-hang-doi --policy-type TargetTrackingScaling   --target-tracking-configuration '{"TargetValue":100.0,
    "CustomizedMetricSpecification":{
      "MetricName":"ApproximateNumberOfMessagesVisible",
      "Namespace":"AWS/SQS",
      "Dimensions":[{"Name":"QueueName","Value":"du-lieu-gps"}],
      "Statistic":"Average"}}'

Consumer lấy theo lô:

import boto3
sqs = boto3.client('sqs')
while True:
    r = sqs.receive_message(QueueUrl=URL, MaxNumberOfMessages=10,
                            WaitTimeSeconds=20)   # long polling
    for m in r.get('Messages', []):
        xu_ly_vi_tri(m['Body'])
        sqs.delete_message(QueueUrl=URL, ReceiptHandle=m['ReceiptHandle'])

Và "phát lại được" theo nghĩa nào:

Thông điệp chỉ bị xoá khi consumer gọi DeleteMessage
    → xử lý lỗi giữa chừng → không xoá
    → hết visibility timeout → quay lại hàng đợi
        ↓
    Đây chính là "replay" mà đề đang thiếu

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

• **B. Dùng Kinesis Data Streams với Lambda xử lý và ghi vào DynamoDB — đây là phương án gần nhất và về mặt kỹ thuật rất phù hợp với dữ liệu telemetry (Kinesis còn cho phép nhiều consumer đọc lại cùng dữ liệu), nhưng nó nhiều việc hơn: phải quản lý shard, phải viết lại ứng dụng thành Lambda, và phải đổi cả tầng lưu trữ. Đề nói "minimal operational overhead", còn phương án A chỉ cần sửa ứng dụng để lấy từ hàng đợi.
• **C. Dùng S3 lưu bản ghi GPS và cho ứng dụng quét bucket định kỳ — quét bucket là mô hình rất kém: độ trễ cao, phí LIST request lớn, và phải tự viết cơ chế đánh dấu tệp nào đã xử lý.
• **D. Lưu vào DynamoDB rồi ứng dụng truy vấn bản ghi chưa xử lý — biến một CSDL thành hàng đợi bằng tay: phải tự quản lý cờ trạng thái, tự xử lý tranh chấp giữa các consumer, và Scan để tìm bản ghi chưa xử lý rất tốn kém.

Ghi nhớ

Ba dịch vụ tách rời của AWS — bảng phải thuộc: | Dịch vụ | Mô hình | Đọc lại | |---|---|---| | Amazon SQS | hàng đợi, một consumer lấy một thông điệp | chỉ khi chưa xoá | | Kinesis Data Streams | luồng, NHIỀU consumer đọc cùng dữ liệu | ✅ trong thời gian giữ | | Amazon SNS | pub/sub, đẩy | ❌ |

Từ khoá nhận diện:

"data loss" + "buffer" + "least overhead" → SQS "multiple consumers", "reprocess the same stream", "ordered per key" → Kinesis "fan-out notifications" → SNS

⚠ SQS và Kinesis — bảng phân biệt chi tiết: | | SQS | Kinesis Data Streams | |---|---|---| | Sau khi xử lý | thông điệp bị XOÁ | dữ liệu VẪN CÒN tới hết retention | | Nhiều consumer | mỗi thông điệp cho một consumer | nhiều consumer độc lập | | Thứ tự | FIFO queue mới đảm bảo | theo partition key | | Quản lý | không có gì | shard (hoặc on-demand) | | Giữ dữ liệu | tối đa 14 ngày | tối đa 365 ngày |

Với dữ liệu telemetry thật, Kinesis thường là lựa chọn kiến trúc tốt hơn — nhưng đề nhấn mạnh công vận hành tối thiểu, và SQS đơn giản hơn hẳn.

Hai loại hàng đợi SQS: | Loại | Thứ tự | Thông lượng | |---|---|---| | Standard | không đảm bảo | không giới hạn | | FIFO | đảm bảo | 300 TPS (3.000 khi gộp lô) |

Dữ liệu GPS: mỗi bản ghi có timestamp riêng
    → thứ tự không quan trọng lắm
    → Standard cho thông lượng không giới hạn

Ba tham số quan trọng của SQS: | Tham số | Mặc định | Lưu ý | |---|---|---| | Visibility timeout | 30 giây | ≥ thời gian xử lý | | Message retention | 4 ngày | tối đa 14 ngày | | WaitTimeSeconds | 0 | đặt 20 — long polling |

Long polling giảm chi phí đáng kể:

Short polling: gọi liên tục, phần lớn trả về rỗng
    → trả tiền cho hàng triệu request vô ích

Long polling (20 giây): giữ kết nối chờ thông điệp
    → ít request hơn nhiều, độ trễ cũng thấp hơn

Ba lưu ý khi thiết bị gửi trực tiếp vào SQS: | Lưu ý | Chi tiết | |---|---| | Đặt API Gateway phía trước | thiết bị không cần credential AWS | | Hoặc dùng IoT Core cho thiết bị thật | chứng chỉ X.509 | | Giới hạn kích thước thông điệp 256 KB | dữ liệu GPS rất nhỏ |

API Gateway tích hợp thẳng với SQS:

API Gateway → SQS (AWS service integration)
    → không cần Lambda ở giữa
        ↓
    Bớt một thành phần, bớt một chỗ hỏng

Dead-letter queue là bắt buộc:

aws sqs set-queue-attributes --queue-url $URL --attributes '{
  "RedrivePolicy":"{\"deadLetterTargetArn\":\"<arn-dlq>\",\"maxReceiveCount\":\"5\"}"}'

Không có DLQ: bản ghi lỗi quay vòng mãi
    → chiếm chỗ, làm metric co giãn sai
        ↓
    Có DLQ: thử 5 lần rồi tách ra để điều tra

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | tồn đọng — dùng co giãn | | ApproximateAgeOfOldestMessage | độ trễ thật của dữ liệu | | Số thông điệp trong DLQ | có lỗi hệ thống |

Metric thứ hai đáng đặt alarm nhất — nó cho biết dữ liệu GPS đang cũ bao nhiêu khi được xử lý.

Ba lưu ý về xử lý trùng lặp: | Lưu ý | Chi tiết | |---|---| | Standard queue giao ÍT NHẤT MỘT LẦN | có thể trùng | | Consumer phải idempotent | | | Dùng khoá (id thiết bị + timestamp) để chống ghi trùng | |

Ba cách mở rộng kiến trúc sau này: | Bước tiếp | Chi tiết | |---|---| | Thêm Kinesis nếu cần nhiều consumer | | | Firehose ghi bản thô vào S3 | lưu trữ và phân tích sau | | DynamoDB cho tra cứu vị trí mới nhất | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính theo số request | | | Long polling giảm mạnh | | | Gộp lô 10 thông điệp mỗi lần | |

Và một lời khuyên: hãy đặt alarm trên ApproximateAgeOfOldestMessage chứ không chỉ trên độ dài hàng đợi. Hàng đợi có thể ngắn mà vẫn có bản ghi vị trí bị kẹt từ nửa tiếng trước — và với dữ liệu theo dõi xe thời gian thực, một bản ghi cũ nửa tiếng cũng vô dụng như một bản ghi bị mất.