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

Đáp án

A và E.

• A — Tạo EC2 Auto Scaling group và Application Load Balancer trải qua nhiều AZ
• E — Tạo subnet công khai và riêng tư mới ở một AZ khác, và chuyển CSDL sang Amazon RDS Multi-AZ

Vì sao đúng

Đề mô tả một kiến trúc có hai điểm hỏng đơn lẻ, và cần sửa cả hai: | Tầng | Hiện trạng | Sửa bằng | |---|---|---| | Web ở subnet công khai | một AZ | ASG + ALB đa AZ (A) | | CSDL ở subnet riêng tư | EC2 trong một AZ | RDS Multi-AZ (E) |

Sửa một tầng là chưa đủ:

Chỉ làm A:  web đa AZ, CSDL vẫn ở AZ-a
            → AZ-a hỏng → mất CSDL → ứng dụng chết
                ↓
        Web sống nhưng không có dữ liệu = vẫn ngừng dịch vụ

Chỉ làm E:  CSDL đa AZ, web vẫn ở AZ-a
            → AZ-a hỏng → không còn máy web nào

Và E còn tạo điều kiện tiên quyết cho A:

ALB và ASG cần SUBNET ở mỗi AZ mà chúng chạy
    → subnet gắn với đúng MỘT AZ
        ↓
    Phải tạo subnet mới ở AZ thứ hai trước
    → đó chính là nửa đầu của phương án E

RDS Multi-AZ hoạt động thế nào:

AZ-a: instance chính (primary)  ──sao chép đồng bộ──▶  AZ-b: standby
        ↓
    AZ-a hỏng → RDS TỰ chuyển sang standby (1-2 phút)
    → endpoint DNS giữ nguyên, ứng dụng không cần đổi chuỗi kết nối

Chuyển sang RDS Multi-AZ:

aws rds create-db-instance --db-instance-identifier db-chinh   --db-instance-class db.m6g.large --engine mysql   --multi-az --db-subnet-group-name nhom-subnet-rieng-tu   --no-publicly-accessible

Ba lợi ích của việc bỏ CSDL tự quản trên EC2: | Lợi ích | Chi tiết | |---|---| | Chuyển đổi dự phòng tự động | không cần script | | Sao lưu tự động, point-in-time recovery | | | Vá lỗi và nâng cấp do AWS lo | |

Cấu hình cuối cùng:

        Internet
            │
        ┌───▼───┐
        │  ALB  │  (subnet công khai AZ-a + AZ-b)
        └───┬───┘
      ┌─────┴─────┐
   [EC2 AZ-a]  [EC2 AZ-b]     ← ASG trải hai AZ
      └─────┬─────┘
    ┌───────▼────────┐
    │ RDS primary a  │◀──sync──▶│ RDS standby b │
    └────────────────┘   (subnet riêng tư)

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

• **B. Tạo subnet mới ở AZ khác, tạo CSDL bằng EC2 ở một AZ — đây là phương án gần nhất vì nửa đầu đúng, nhưng nửa sau giữ nguyên vấn đề: CSDL tự quản trên EC2 trong một AZ vẫn là điểm hỏng đơn lẻ, và bạn phải tự lo sao chép và chuyển đổi dự phòng.
• **D. Tạo ASG trong subnet công khai và dùng ALB — thiếu vế "trải qua nhiều AZ", và không đụng gì tới tầng CSDL. Một ASG trong một AZ vẫn chết cùng AZ đó.
• **C. Tạo subnet mới cùng AZ nhưng ở VPC khác — không giúp gì: VPC là cấu trúc logic, cùng AZ nghĩa là cùng hạ tầng vật lý. AZ hỏng thì cả hai VPC cùng chết, và còn thêm phí peering.

Ghi nhớ

Nguyên tắc gốc:

Tính sẵn sàng cao của một hệ thống = tầng yếu nhất. Phải kiểm tra MỌI tầng, không chỉ tầng đầu.

Từ khoá nhận diện:

"single Availability Zone" + "high availability" → trải đa AZ MỌI tầng "database on EC2" + "high availability" → chuyển sang RDS Multi-AZ "Select TWO" → thường là một câu cho tầng web, một cho tầng CSDL

Ba lựa chọn dự phòng cho CSDL: | Lựa chọn | Chuyển đổi | Đọc từ bản phụ | |---|---|---| | RDS Multi-AZ (standby) | tự động 1-2 phút | ❌ standby KHÔNG phục vụ đọc | | RDS Multi-AZ DB cluster | tự động < 35 giây | ✅ 2 bản đọc được | | Read replica | THỦ CÔNG | ✅ |

Vế "standby không phục vụ đọc" là điều rất hay bị hiểu sai:

Nhiều người tưởng standby của Multi-AZ chia tải đọc
    → KHÔNG. Nó chỉ nằm chờ.
        ↓
    Muốn chia tải đọc thì phải tạo read replica riêng

Bảng phân biệt Multi-AZ và Read Replica: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | tính sẵn sàng | hiệu năng đọc | | Sao chép | đồng bộ | bất đồng bộ | | Chuyển đổi | tự động | thủ công (promote) | | Vị trí | AZ khác cùng vùng | cả vùng khác |

Ba yêu cầu mạng để RDS Multi-AZ chạy: | Yêu cầu | Chi tiết | |---|---| | DB subnet group có subnet ở ≥ 2 AZ | | | Cả hai subnet đều RIÊNG TƯ | | | Security group cho phép từ tầng web | |

Dòng đầu là lỗi hay gặp nhất khi bật Multi-AZ:

DB subnet group chỉ có subnet ở một AZ
    → không bật được --multi-az
    → lỗi "DB Subnet Group doesn't meet availability zone coverage"

Ba lưu ý về subnet: | Lưu ý | Chi tiết | |---|---| | Một subnet thuộc đúng MỘT AZ | không trải được | | Subnet công khai có route ra IGW | | | Subnet riêng tư ra Internet qua NAT | NAT mỗi AZ |

Vế cuối là chi tiết chi phí đáng cân nhắc:

NAT Gateway đặt ở một AZ:  rẻ hơn nhưng là điểm hỏng
NAT Gateway mỗi AZ:        đắt hơn nhưng thực sự đa AZ
        ↓
    Với kiến trúc HA thật thì phải mỗi AZ một cái

Ba lưu ý khi chuyển CSDL từ EC2 sang RDS: | Lưu ý | Chi tiết | |---|---| | Dùng DMS để chuyển gần như không ngừng | | | Kiểm tra phiên bản engine tương thích | | | RDS không cho truy cập SSH vào máy | |

Vế cuối là điều hay làm người ta bất ngờ — mọi thao tác phải qua tham số nhóm và API.

Ba metric cần theo dõi sau khi chuyển: | Metric | Ý nghĩa | |---|---| | ReplicaLag (nếu có replica) | độ trễ sao chép | | DatabaseConnections | | | FailoverTime qua CloudTrail event | |

Ba việc kiểm chứng HA: | Việc | Cách làm | |---|---| | Ép chuyển đổi dự phòng RDS | reboot-db-instance --force-failover | | Tắt hết instance một AZ | | | Đo thời gian ngừng thực tế | |

aws rds reboot-db-instance --db-instance-identifier db-chinh --force-failover

Ba lưu ý về ứng dụng khi có failover: | Lưu ý | Chi tiết | |---|---| | Kết nối đang mở BỊ NGẮT | ứng dụng phải thử lại | | DNS TTL của endpoint ngắn | | | Connection pool phải xử lý được | |

Dòng đầu là chỗ hay gãy:

Ứng dụng giữ connection pool và không thử lại
    → sau failover, mọi kết nối cũ chết
    → ứng dụng ném lỗi cho tới khi khởi động lại
        ↓
    RDS đã chuyển xong trong 1 phút mà ứng dụng vẫn hỏng

Và một lời khuyên: hãy ép một lần chuyển đổi dự phòng vào giờ thấp điểm ngay sau khi bật Multi-AZ. Đó là cách duy nhất để biết ứng dụng có xử lý được việc mất kết nối hay không — và biết điều đó vào một buổi tối bạn chọn thì tốt hơn nhiều so với vào lúc AWS chọn giúp bạn.

Đáp án

D — API Gateway → Kinesis Data Firehose → S3, dùng S3 Event Notification gọi Lambda để phân tích cảm xúc bằng Amazon Comprehend, ghi kết quả vào DynamoDB có TTL 12 tháng.

Vì sao đúng

Đề nêu bốn yêu cầu, và kiến trúc này đáp ứng từng cái: | Yêu cầu | Thành phần | |---|---| | Hàng nghìn phản hồi mỗi ngày, cần MỞ RỘNG TỐT NHẤT | Firehose đệm và gộp lô | | Tự động phân tích cảm xúc | Amazon Comprehend | | Lưu ít nhất 12 tháng | DynamoDB TTL | | Ít công vận hành | toàn dịch vụ được quản lý |

Vì sao Firehose là điểm khác biệt về khả năng mở rộng:

Không có Firehose:  mỗi phản hồi → một lần gọi Lambda
                    → hàng nghìn lần gọi rời rạc
                        ↓
Có Firehose:        đệm theo kích thước (1-128 MB)
                    hoặc theo thời gian (60-900 giây)
                    → ghi thành TỆP LỚN vào S3
                    → một Lambda xử lý cả lô
                        ↓
                    Ít lần gọi hơn nhiều, chịu được đợt tăng đột biến

Và Firehose tự đệm khi tải tăng vọt:

Đợt khảo sát gửi 50.000 phản hồi trong 5 phút
    → Firehose hấp thụ, ghi S3 theo lô
    → không có thành phần nào bị quá tải
        ↓
    Đây chính là nghĩa của "MOST scalable"

Luồng đầy đủ:

Ứng dụng di động
    │ POST
    ▼
API Gateway  (tích hợp trực tiếp với Firehose, không cần Lambda)
    ▼
Kinesis Data Firehose  (đệm 5 phút hoặc 5 MB)
    ▼
S3 bucket  (tệp JSON theo lô)
    │ S3 Event Notification
    ▼
Lambda ──▶ Amazon Comprehend  (DetectSentiment)
    ▼
DynamoDB  (TTL = now + 12 tháng)

Tích hợp API Gateway với Firehose không cần Lambda:

API Gateway hỗ trợ AWS service integration
    → gọi thẳng firehose:PutRecord
        ↓
    Bớt một thành phần, bớt một chỗ hỏng, bớt chi phí

Gọi Comprehend theo lô cho hiệu quả:

import boto3
comprehend = boto3.client('comprehend')

# BatchDetectSentiment xử lý tới 25 văn bản một lần gọi
kq = comprehend.batch_detect_sentiment(
    TextList=[p['noi_dung'] for p in phan_hoi[:25]],
    LanguageCode='vi')
for r in kq['ResultList']:
    print(r['Sentiment'], r['SentimentScore'])

Đặt TTL cho DynamoDB:

import time
bang.put_item(Item={
    'id': ma_phan_hoi,
    'cam_xuc': r['Sentiment'],
    'diem': str(r['SentimentScore']['Positive']),
    'het_han': int(time.time()) + 365 * 24 * 3600})

aws dynamodb update-time-to-live --table-name phan-hoi   --time-to-live-specification "Enabled=true,AttributeName=het_han"

Và S3 vẫn giữ dữ liệu thô — đó là một lợi ích phụ đáng giá: nếu sau này muốn phân tích lại bằng mô hình khác, dữ liệu gốc vẫn còn.

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

• **B. EventBridge → Step Functions → Lambda + Comprehend → DynamoDB TTL — đây là phương án gần nhất và hoàn toàn chạy được, nhưng kém khả năng mở rộng hơn: Step Functions chạy một lần thực thi cho MỖI phản hồi, tức hàng nghìn lần mỗi ngày, mỗi lần tính phí theo bước chuyển trạng thái. Không có tầng đệm gộp lô, và đợt tăng đột biến sẽ chạm giới hạn tần suất khởi động của Step Functions.
• **A. Máy chủ tại chỗ + mô hình học máy tự viết — ngược hẳn yêu cầu: công vận hành cao nhất, không mở rộng được, và phải tự huấn luyện mô hình. Còn ghi nhầm "xoá sau 12 tháng" trong khi đề nói lưu ít nhất 12 tháng.
• **C. Ghi thẳng vào Redshift và dùng Redshift ML — Redshift là kho dữ liệu phân tích, ghi từng bản ghi một vào đó là mô hình sử dụng sai; và một cụm Redshift chạy liên tục cho hàng nghìn bản ghi mỗi ngày là quá mức và tốn kém.

Ghi nhớ

Ba dịch vụ nạp dữ liệu theo luồng — bảng phải thuộc: | Dịch vụ | Đặc điểm | |---|---| | Kinesis Data Firehose | KHÔNG cần quản lý, tự ghi vào đích | | Kinesis Data Streams | giữ dữ liệu, nhiều consumer, cần quản shard | | Amazon MSK | Kafka được quản lý |

Từ khoá nhận diện:

"most scalable" + "minimal operational overhead" → Firehose | "sentiment analysis", "key phrases", "entities" → Amazon Comprehend "expire data automatically" → DynamoDB TTL hoặc S3 lifecycle

Bốn đích mà Firehose ghi thẳng được: | Đích | Ghi chú | |---|---| | Amazon S3 | phổ biến nhất ← câu này | | Amazon Redshift | qua S3 | | OpenSearch Service | | | HTTP endpoint | Datadog, Splunk, New Relic |

Ba cài đặt đệm của Firehose: | Cài đặt | Khoảng | |---|---| | Buffer size | 1-128 MB | | Buffer interval | 60-900 giây | | Nén | GZIP, Snappy, ZIP |

Firehose ghi khi ĐẠT MỘT trong hai điều kiện — cái nào tới trước.

Ba tính năng của Comprehend: | Tính năng | Việc | |---|---| | DetectSentiment | POSITIVE / NEGATIVE / NEUTRAL / MIXED | | DetectEntities | tên người, địa điểm, tổ chức | | DetectKeyPhrases | cụm từ chính |

Và hai chế độ gọi: | Chế độ | Giới hạn | |---|---| | Đồng bộ (DetectSentiment) | 1 văn bản, 5.000 byte | | Lô (BatchDetectSentiment) | 25 văn bản một lần | | Bất đồng bộ (StartSentimentDetectionJob) | tệp lớn trong S3 |

Ba đặc điểm của DynamoDB TTL: | Đặc điểm | Chi tiết | |---|---| | Xoá MIỄN PHÍ | không tốn WCU | | KHÔNG xoá đúng giây | có thể trễ tới 48 giờ | | Thuộc tính phải là số Unix epoch GIÂY | |

Vế thứ hai là chi tiết hay bị bỏ qua:

TTL không đảm bảo xoá đúng thời điểm
    → mục hết hạn vẫn xuất hiện trong Query/Scan
        ↓
    Nếu cần chính xác, phải LỌC trong ứng dụng
    → hoặc dùng filter expression theo thời gian

Ba lưu ý về đơn vị TTL: | Lỗi | Hậu quả | |---|---| | Dùng mili giây thay vì giây | mốc ở năm 56000 → không bao giờ xoá | | Dùng chuỗi thay vì số | TTL bỏ qua | | Đặt sai tên thuộc tính | như trên |

Ba lưu ý khi tích hợp API Gateway với Firehose: | Lưu ý | Chi tiết | |---|---| | Cần IAM role cho API Gateway | firehose:PutRecord | | Dùng mapping template chuyển thân request | | | Bật throttling để bảo vệ | |

Ba lưu ý về S3 Event Notification: | Lưu ý | Chi tiết | |---|---| | Ít nhất một lần, có thể TRÙNG | Lambda phải idempotent | | Có thể lọc theo tiền tố và hậu tố | | | Dùng EventBridge nếu cần định tuyến phức tạp | |

Dòng đầu là chỗ hay quên:

Cùng một tệp có thể gọi Lambda hai lần
    → ghi DynamoDB hai bản ghi cảm xúc trùng
        ↓
    Dùng khoá chính suy ra từ tên tệp + vị trí dòng
    → ghi đè thay vì tạo mới

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Comprehend tính theo ĐƠN VỊ 100 ký tự | tối thiểu 3 đơn vị mỗi request | | Firehose tính theo GB nạp vào | | | DynamoDB on-demand hợp với tải không đều | |

Dòng đầu đáng nhớ: gọi Comprehend cho từng câu ngắn rất lãng phí vì mỗi request tính tối thiểu 300 ký tự — gộp lô là cách giảm chi phí thực chất.

Ba lựa chọn lưu trữ kết quả: | Lựa chọn | Khi nào | |---|---| | DynamoDB | tra cứu theo khoá, TTL sẵn ← câu này | | S3 + Athena | phân tích xu hướng theo thời gian | | OpenSearch | tìm kiếm và dashboard |

Với yêu cầu "nhận diện xu hướng theo thời gian", S3 + Athena thực ra mạnh hơn — nhưng DynamoDB TTL là thứ đề nêu rõ.

Và một lời khuyên: hãy giữ lại dữ liệu thô trong S3 lâu hơn kết quả đã phân tích. Mô hình phân tích cảm xúc sẽ tốt lên theo thời gian, và có văn bản gốc nghĩa là bạn chạy lại được — còn nếu chỉ giữ nhãn POSITIVE/NEGATIVE thì kết quả của hôm nay là kết quả cuối cùng bạn có.

Đáp án

C — Chép dữ liệu từ tất cả EBS volume sang Amazon EFS, và sửa ứng dụng để lưu tài liệu mới vào EFS.

Vì sao đúng

Đề mô tả một triệu chứng rất đặc trưng, và nguyên nhân chỉ có một: | Triệu chứng | Nguyên nhân | |---|---| | Trước: một EC2, một EBS → thấy đủ tài liệu | mọi tệp ở một chỗ | | Sau: nhiều EC2 sau ALB → chỉ thấy MỘT PHẦN | mỗi máy có EBS riêng |

Chuyện gì đang xảy ra:

Người dùng tải tệp A lên → ALB gửi tới máy 1 → lưu vào EBS của máy 1
Người dùng tải tệp B lên → ALB gửi tới máy 2 → lưu vào EBS của máy 2
        ↓
    Lần sau vào, ALB gửi tới máy 3
    → máy 3 chỉ có tệp của chính nó
    → người dùng thấy "một phần tài liệu"

Vì sao EFS là lời giải đúng: | Đặc điểm EFS | Giải quyết gì | |---|---| | Hệ thống tệp CHIA SẺ, nhiều máy mount cùng lúc | mọi máy thấy cùng tập tệp | | Trải qua nhiều AZ | hợp với ASG đa AZ | | Tự co giãn dung lượng | không phải quản lý |

So sánh cốt lõi:

EBS: gắn được vào MỘT instance tại một thời điểm (trừ Multi-Attach)
     → ổ riêng của mỗi máy

EFS: NFS, hàng nghìn instance mount đồng thời
     → ổ chung

Mount EFS:

sudo mount -t efs -o tls fs-0123456789abcdef0:/ /var/tai-lieu

Hoặc trong /etc/fstab để tự mount khi khởi động:

fs-0123456789abcdef0:/ /var/tai-lieu efs _netdev,tls 0 0

Ba bước chuyển đổi: | Bước | Việc | |---|---| | 1. Tạo EFS với mount target ở MỖI AZ | | | 2. Chép dữ liệu từ mọi EBS volume sang EFS | rsync hoặc DataSync | | 3. Sửa ứng dụng dùng đường dẫn EFS | thêm mount vào user data |

Vế "mount target mỗi AZ" là bắt buộc:

Thiếu mount target ở AZ nào
    → instance ở AZ đó KHÔNG mount được
    → lệnh mount treo rồi timeout
        ↓
    ASG đa AZ mà EFS một AZ = một phần máy không chạy được

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

• **B. Dùng sticky session của ALB để giữ người dùng ở cùng một máy — đây là phương án gần nhất và che được triệu chứng, nhưng nó không sửa nguyên nhân: mỗi người vẫn chỉ thấy tệp trên máy của mình, không ai chia sẻ được tài liệu (mà đề nói ứng dụng là để chia sẻ tài liệu). Và khi máy đó bị ASG thay thế, người dùng mất sạch.
• **D. Chạy script đồng bộ dữ liệu giữa các EBS volume — về lý thuyết chép được, nhưng cực kỳ mong manh: có độ trễ đồng bộ, xung đột khi hai máy ghi cùng lúc, tốn dung lượng gấp N lần, và máy mới do ASG tạo ra sẽ trống rỗng cho tới khi đồng bộ xong.
• **A. Cấu hình ALB gửi request tới mọi máy rồi trả tệp từ máy đúng — ALB không làm được điều này: nó gửi mỗi request tới đúng một target. Đây là mô tả một cơ chế không tồn tại.

Ghi nhớ

Ba loại lưu trữ AWS — bảng phải thuộc: | Loại | Dịch vụ | Chia sẻ | |---|---|---| | Khối (block) | EBS, instance store | ❌ một instance | | Tệp (file) | EFS, FSx | ✅ nhiều instance | | Object | S3 | ✅ qua API |

Từ khoá nhận diện:

"shared file system", "multiple instances access same files" → EFS "users see only a subset after scaling" → lưu trữ cục bộ, cần chia sẻ "Windows file share", "SMB" → FSx for Windows

Ba lựa chọn lưu trữ chia sẻ: | Lựa chọn | Giao thức | Khi nào | |---|---|---| | Amazon EFS | NFS (Linux) | ứng dụng Linux ← câu này | | FSx for Windows | SMB | ứng dụng Windows | | Amazon S3 | HTTP API | tốt nhất cho tài liệu |

S3 thực ra là kiến trúc tốt hơn cho ứng dụng chia sẻ tài liệu:

S3 rẻ hơn EFS nhiều lần, bền hơn, và có presigned URL
    → ứng dụng tải lên/tải xuống thẳng từ trình duyệt
        ↓
    Nhưng phải sửa ứng dụng dùng SDK thay vì API tệp
    → EFS chỉ cần đổi đường dẫn

Đây là đánh đổi đáng nhớ: EFS cho phép chuyển đổi với sửa đổi tối thiểu; S3 tối ưu hơn nhưng cần viết lại tầng lưu trữ.

Ba chế độ hiệu năng của EFS: | Chế độ | Đặc điểm | |---|---| | General Purpose | độ trễ thấp nhất — mặc định | | Max I/O | thông lượng cao hơn, độ trễ cao hơn | | Elastic Throughput | tự co giãn — khuyến nghị hiện nay |

Bốn lớp lưu trữ EFS: | Lớp | Dùng cho | |---|---| | Standard | truy cập thường xuyên | | Infrequent Access (IA) | rẻ hơn ~85%, phí đọc | | Archive | rất ít truy cập | | One Zone | một AZ, rẻ hơn nhưng kém sẵn sàng |

Lifecycle tự chuyển lớp:

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

Ba yêu cầu mạng cho EFS: | Yêu cầu | Chi tiết | |---|---| | Mount target ở MỖI AZ có instance | | | Security group của EFS mở cổng 2049 | NFS | | Nguồn là security group của EC2 | không mở CIDR rộng |

Cổng 2049 là chỗ hay quên nhất:

aws ec2 authorize-security-group-ingress --group-id sg-efs   --protocol tcp --port 2049 --source-group sg-web

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá at rest khi TẠO | không bật sau được | | Mã hoá in transit bằng -o tls | | | Access point giới hạn thư mục và UID | |

Ba cách chép dữ liệu ban đầu: | Cách | Khi nào | |---|---| | rsync -av | vài GB | | AWS DataSync | lượng lớn, có báo cáo | | Snapshot + mount tạm | |

⚠ Chép từ nhiều EBS phải cẩn thận trùng tên:

Máy 1 và máy 2 đều có /tai-lieu/bao-cao.pdf (khác nội dung)
    → chép tuần tự vào EFS → cái sau đè cái trước
        ↓
    Chép vào thư mục riêng trước rồi đối chiếu
    → hoặc đổi tên theo id máy nguồn

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | EFS có độ trễ cao hơn EBS | NFS qua mạng | | Không hợp CSDL cần IOPS cao | | | Nhiều tệp nhỏ chậm hơn ít tệp lớn | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | EFS đắt hơn EBS mỗi GB | ~3 lần với Standard | | Trả theo dung lượng THỰC DÙNG | không cấp phát trước | | Lifecycle sang IA giảm nhiều | |

Ba việc kiểm chứng sau khi chuyển: | Việc | Cách | |---|---| | Tải tệp qua một máy, tải về qua máy khác | | | Chấm dứt một instance, xem tệp còn không | | | Kiểm tra fstab mount lại khi khởi động | |

Và một lời khuyên: hãy đưa lệnh mount vào launch template user data, đừng chỉ sửa /etc/fstab trên các máy đang chạy. ASG sẽ thay máy vào lúc bạn không có mặt, và một máy mới không mount EFS sẽ ghi tệp vào đĩa cục bộ — đúng lại lỗi mà bạn vừa sửa, chỉ khác là lần này nó xảy ra âm thầm.

Đáp án

B và E.

• B — Security group tầng web: cho inbound cổng 443 từ 0.0.0.0/0, và outbound cổng 1433 tới tầng CSDL
• E — Security group tầng CSDL: cho inbound cổng 1433 từ SECURITY GROUP của tầng web

Vì sao đúng

Đề nêu ba dữ kiện, và cấu hình phải bám đúng từng cái: | Dữ kiện | Quy tắc | |---|---| | Tầng web công khai, người dùng vào từ Internet | inbound 443 từ 0.0.0.0/0 | | CSDL là Microsoft SQL Server | cổng 1433 | | Bảo mật là ưu tiên cao | tham chiếu SECURITY GROUP, không dùng CIDR |

Vế thứ ba là điểm quan trọng nhất của câu này:

Cho phép theo CIDR:   "cho 10.0.1.0/24 vào cổng 1433"
    → dải đó có thể chứa cả máy không phải tầng web
    → subnet đổi, CIDR đổi, quy tắc phải sửa theo

Cho phép theo security group:  "cho sg-web vào cổng 1433"
    → CHỈ những máy gắn sg-web mới vào được
    → thêm máy web mới → tự áp dụng
        ↓
    Đây là cách làm chuẩn cho kiến trúc nhiều tầng

Cấu hình:

# Tầng web: nhận HTTPS từ Internet
aws ec2 authorize-security-group-ingress --group-id sg-web   --protocol tcp --port 443 --cidr 0.0.0.0/0

# Tầng CSDL: chỉ nhận từ security group của web
aws ec2 authorize-security-group-ingress --group-id sg-db   --protocol tcp --port 1433 --source-group sg-web

Vì sao B nhắc cả outbound:

Security group MẶC ĐỊNH cho phép MỌI outbound
    → không khai gì cũng chạy
        ↓
    Nhưng "bảo mật là ưu tiên cao" nghĩa là siết cả chiều ra
    → chỉ cho tầng web gọi ra cổng 1433 tới CSDL
    → máy web bị chiếm quyền cũng không kết nối ra ngoài được

aws ec2 revoke-security-group-egress --group-id sg-web   --protocol -1 --port -1 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-egress --group-id sg-web   --protocol tcp --port 1433 --source-group sg-db

Và vì sao KHÔNG cần khai outbound cho tầng CSDL:

Security group là STATEFUL
    → request vào được thì response ra được TỰ ĐỘNG
        ↓
    Không cần quy tắc outbound để trả lời

Vế này là chìa khoá loại phương án C.

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

• **D. Tầng CSDL cho inbound cổng 443 VÀ 1433 từ security group web — đây là phương án gần nhất và chỉ sai một chi tiết: cổng 443 là thừa. Máy chủ SQL Server không phục vụ HTTPS; mở thêm một cổng không dùng đến là vi phạm nguyên tắc đặc quyền tối thiểu, mà đề nhấn mạnh "bảo mật là ưu tiên cao".
• **C. Tầng CSDL cho outbound cổng 443 và 1433 tới tầng web — hiểu sai chiều kết nối: tầng web gọi vào CSDL, không phải ngược lại. Và vì security group là stateful, phản hồi không cần quy tắc outbound.
• **A. Tầng web cho outbound 443 tới 0.0.0.0/0 — nghe hợp lý nhưng thiếu vế quan trọng nhất: không có gì cho phép tầng web nói chuyện với CSDL trên cổng 1433, nên ứng dụng không chạy được. Và mở outbound ra cả Internet là điều B đã siết lại.

Ghi nhớ

Security Group và NACL — bảng phải thuộc: | | Security Group | Network ACL | |---|---|---| | Cấp | ENI (instance) | subnet | | Trạng thái | STATEFUL | STATELESS | | Quy tắc | chỉ Allow | Allow và Deny | | Đánh giá | mọi quy tắc | theo số thứ tự | | Nguồn | CIDR hoặc SECURITY GROUP | chỉ CIDR |

Dòng cuối là ưu thế lớn nhất của security group và là lý do E đúng.

Từ khoá nhận diện:

"security is a high priority" + nhiều tầng → tham chiếu security group "stateless", "deny specific IP" → NACL "least privilege" → chỉ mở cổng cần thiết

Bảng cổng phải thuộc: | Dịch vụ | Cổng | |---|---| | HTTP / HTTPS | 80 / 443 | | SSH / RDP | 22 / 3389 | | MySQL / MariaDB / Aurora MySQL | 3306 | | PostgreSQL | 5432 | | Microsoft SQL Server | 1433 ← câu này | | Oracle | 1521 | | NFS (EFS) | 2049 | | SMB | 445 | | Redis / Memcached | 6379 / 11211 |

Ba quy tắc vàng khi thiết kế security group nhiều tầng: | Quy tắc | Chi tiết | |---|---| | Mỗi tầng một security group | web, ứng dụng, CSDL | | Tầng dưới tham chiếu SG tầng trên | không dùng CIDR | | Chỉ mở đúng cổng cần | |

Mẫu chuẩn ba tầng:

sg-alb:  inbound 443 từ 0.0.0.0/0
sg-web:  inbound 443 từ sg-alb          ← không mở ra Internet!
sg-db:   inbound 1433 từ sg-web

Lưu ý: trong bài này tầng web ở subnet công khai nhận thẳng từ Internet, nhưng kiến trúc tốt hơn là đặt ALB phía trước và chỉ cho ALB gọi vào tầng web.

Ba đặc điểm của security group: | Đặc điểm | Chi tiết | |---|---| | Mặc định: chặn hết inbound, cho hết outbound | | | Chỉ có Allow, KHÔNG có Deny | | | Mọi quy tắc được hợp lại (OR) | |

Vế thứ hai đáng nhớ:

Muốn chặn một IP cụ thể?
    → security group KHÔNG làm được
    → phải dùng NACL hoặc AWS WAF

Ba đặc điểm của stateful: | Đặc điểm | Chi tiết | |---|---| | Kết nối vào → phản hồi ra tự động | | | Kết nối ra → phản hồi vào tự động | | | Không cần quy tắc cho cổng ephemeral | |

Với NACL thì ngược lại — và đó là bẫy kinh điển:

NACL stateless:  phải mở CẢ chiều vào VÀ chiều ra
    → chiều ra phải mở dải cổng ephemeral 1024-65535
        ↓
    Quên vế này là "quy tắc trông đúng mà không kết nối được"

Ba giới hạn cần biết: | Giới hạn | Con số mặc định | |---|---| | Security group mỗi ENI | 5 (tăng được tới 16) | | Quy tắc mỗi security group | 60 inbound, 60 outbound | | Security group mỗi VPC | 2.500 |

Ba lưu ý về outbound: | Lưu ý | Chi tiết | |---|---| | Mặc định mở hết — siết lại khi cần bảo mật cao | | | Siết rồi phải nhớ mở 443 cho cập nhật và API AWS | | | Dùng VPC endpoint để gọi API AWS không qua Internet | |

Dòng thứ hai là sự cố hay gặp khi siết outbound:

Chặn hết outbound → yum update, aws cli, agent CloudWatch đều chết
    → và chúng chết ÂM THẦM
        ↓
    Hoặc mở 443 tới prefix list của AWS
    → hoặc dùng VPC endpoint cho từng dịch vụ

Ba công cụ kiểm tra: | Công cụ | Việc | |---|---| | VPC Reachability Analyzer | tìm xem chặn ở đâu | | VPC Flow Logs | xem gói bị REJECT | | Network Access Analyzer | tìm đường đi ngoài ý muốn |

aws ec2 create-network-insights-path --source i-web --destination i-db   --destination-port 1433 --protocol tcp

Ba lưu ý cho CSDL tự quản trên EC2: | Lưu ý | Chi tiết | |---|---| | Đặt ở subnet RIÊNG TƯ, không có IP công khai | | | Không mở 3389 ra Internet | dùng Session Manager | | Cân nhắc RDS for SQL Server | bớt việc vá lỗi |

Và một lời khuyên: hãy dùng VPC Reachability Analyzer trước khi đi tìm lỗi trong ứng dụng. Khi tầng web không nối được CSDL, nguyên nhân gần như luôn nằm ở security group, NACL hoặc bảng định tuyến — và công cụ này chỉ thẳng vào thành phần đang chặn, thay vì bắt bạn đọc lại từng quy tắc một.

Đáp án

B — Dùng Amazon ECS Service Auto Scaling với chính sách target tracking.

Vì sao đúng

Đề nêu ba yêu cầu, và target tracking đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Chạy trên ECS với launch type Fargate | phải dùng ECS Service Auto Scaling | | Hiệu năng tốt khi ra mắt (tải lớn) | tự thêm task khi vượt mục tiêu | | Chi phí giảm khi nhu cầu giảm | tự bớt task khi dưới mục tiêu |

Vì sao KHÔNG phải EC2 Auto Scaling:

Fargate = KHÔNG có EC2 instance nào để co giãn
    → AWS quản lý hạ tầng bên dưới
        ↓
    Đơn vị co giãn là TASK, không phải instance
    → công cụ đúng là ECS Service Auto Scaling
    (nó dùng Application Auto Scaling bên dưới)

Cấu hình:

aws application-autoscaling register-scalable-target   --service-namespace ecs   --resource-id service/cum-web/dich-vu-web   --scalable-dimension ecs:service:DesiredCount   --min-capacity 2 --max-capacity 50

aws application-autoscaling put-scaling-policy   --policy-name theo-cpu --service-namespace ecs   --resource-id service/cum-web/dich-vu-web   --scalable-dimension ecs:service:DesiredCount   --policy-type TargetTrackingScaling   --target-tracking-scaling-policy-configuration '{
    "TargetValue": 60.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"},
    "ScaleInCooldown": 300, "ScaleOutCooldown": 60}'

Target tracking hoạt động thế nào:

Bạn khai: "giữ CPU trung bình ở 60%"
    → CPU lên 85% → AWS tự tính cần thêm bao nhiêu task
    → CPU xuống 30% → tự bớt task
        ↓
    Giống như đặt nhiệt độ điều hoà
    → không phải viết từng bậc ngưỡng

Vì sao target tracking hơn step scaling ở bài này: | | Target tracking | Step scaling | |---|---|---| | Cấu hình | một con số mục tiêu | nhiều bậc ngưỡng | | Tự tính lượng thay đổi | ✅ | ❌ phải khai từng bậc | | Tự tạo alarm | ✅ hai alarm | phải tự tạo | | Kiểm soát chi tiết | ít hơn | nhiều hơn |

Và một chi tiết quan trọng về hành vi:

Target tracking scale OUT nhanh, scale IN CHẬM
    → tránh dao động lên xuống liên tục
        ↓
    Đúng với yêu cầu "hiệu năng tốt lúc ra mắt"

Ba metric dựng sẵn cho ECS: | Metric | Dùng khi | |---|---| | ECSServiceAverageCPUUtilization | tải nặng CPU | | ECSServiceAverageMemoryUtilization | tải nặng bộ nhớ | | ALBRequestCountPerTarget | theo lượng request |

Metric thứ ba thường phù hợp nhất cho ứng dụng web:

CPU phản ứng SAU khi tải đã tăng
Số request phản ứng NGAY khi tải tăng
        ↓
    Với đợt ra mắt tăng đột ngột, request-per-target nhạy hơn

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

• **C. Dùng EC2 Auto Scaling với simple scaling — đây là phương án gần nhất trong nhóm "co giãn tự động", nhưng sai công cụ: với launch type Fargate không có EC2 instance nào để co giãn. Và simple scaling là kiểu cũ nhất — mỗi lần chỉ kích hoạt một hành động rồi chờ hết cooldown, phản ứng chậm.
• **A. Dùng Lambda co giãn ECS khi CloudWatch alarm kích hoạt — làm được nhưng viết lại thứ AWS đã cung cấp sẵn: phải tự viết mã, tự xử lý lỗi, tự tránh dao động. Công vận hành cao mà không được gì thêm.
• **D. Dùng EC2 Auto Scaling co giãn theo lịch — sai công cụ (Fargate), và co giãn theo lịch không phù hợp với đợt ra mắt: bạn không biết trước tải sẽ đến khi nào và lớn bao nhiêu.

Ghi nhớ

Bốn kiểu chính sách co giãn — bảng phải thuộc: | Kiểu | Cách hoạt động | Khi nào | |---|---|---| | Target tracking | giữ metric ở giá trị mục tiêu | mặc định nên dùng | | Step scaling | bậc thang theo mức vượt ngưỡng | cần kiểm soát chi tiết | | Simple scaling | một hành động, chờ cooldown | kiểu cũ, ít dùng | | Scheduled | theo thời gian | tải biết trước |

Từ khoá nhận diện:

"Fargate" + "scale" → ECS Service Auto Scaling "simplest", "maintain performance" → target tracking "known traffic pattern", "every day at 9am" → scheduled

Ba tầng co giãn trong ECS — hay bị lẫn: | Tầng | Công cụ | Áp cho | |---|---|---| | Số TASK của dịch vụ | ECS Service Auto Scaling | cả EC2 và Fargate | | Số EC2 instance của cụm | ECS Cluster Auto Scaling | chỉ launch type EC2 | | Số cụm | thủ công | |

Với Fargate chỉ có tầng đầu — đó là điểm gọn nhất của Fargate.

Bảng phân biệt hai launch type: | | Fargate | EC2 | |---|---|---| | Quản lý máy chủ | ❌ AWS lo | ✅ bạn lo | | Co giãn | chỉ task | task + instance | | Giá | theo vCPU và RAM của task | theo instance | | Khởi động task | chậm hơn (~30-60 giây) | nhanh nếu có chỗ |

Ba lưu ý về min và max capacity: | Lưu ý | Chi tiết | |---|---| | min đủ để chịu tải nền | đừng để 0 với dịch vụ web | | max đặt cao cho đợt ra mắt | nhưng có trần chi phí | | max cũng là giới hạn an toàn | tránh chi phí thất thoát |

Ba lưu ý về cooldown: | Lưu ý | Chi tiết | |---|---| | ScaleOutCooldown ngắn | phản ứng nhanh với tải | | ScaleInCooldown dài hơn | tránh bớt task quá sớm | | Tính cả thời gian khởi động task | |

Vế thứ ba là chỗ hay sai với Fargate:

Task Fargate mất 30-60 giây mới sẵn sàng
    → cooldown 30 giây → scale thêm lần nữa trước khi task đầu chạy
        ↓
    Thêm task quá nhiều, rồi bớt ồ ạt
    → đặt cooldown ≥ thời gian khởi động thật

Ba lưu ý về health check: | Lưu ý | Chi tiết | |---|---| | healthCheckGracePeriodSeconds đủ dài | | | ALB health check trỏ đúng đường dẫn | | | Deregistration delay hợp lý | |

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

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

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

2 task On-Demand làm nền, phần tăng thêm chủ yếu dùng Spot
    → chịu được việc Spot bị thu hồi

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | RunningTaskCount | có scale không | | CPUUtilization của dịch vụ | có bám mục tiêu không | | TargetResponseTime của ALB | trải nghiệm thật |

Ba việc chuẩn bị trước ngày ra mắt: | Việc | Chi tiết | |---|---| | Thử tải để biết ngưỡng | | | Đặt min cao hơn bình thường vài giờ đầu | | | Kiểm tra hạn ngạch tài khoản | Fargate có quota vCPU |

Dòng cuối rất hay bị quên:

Hạn ngạch Fargate On-Demand vCPU mặc định có giới hạn
    → scale tới trần rồi dừng, task mới ở trạng thái PROVISIONING
        ↓
    Xin tăng hạn ngạch TRƯỚC ngày ra mắt, không phải trong lúc đó

Và một lời khuyên: hãy dùng ALBRequestCountPerTarget thay vì CPU cho đợt ra mắt. CPU là chỉ báo trễ — khi nó lên tới ngưỡng thì người dùng đã chờ lâu rồi. Số request trên mỗi task tăng ngay khi lưu lượng tăng, nên hệ thống bắt đầu thêm task trong lúc còn kịp.

Đáp án

D — Sửa script để chép dữ liệu vào AWS Storage Gateway File Gateway (thiết bị ảo) thay vì máy chủ tệp tại chỗ.

Vì sao đúng

Đề nêu ba yêu cầu, và File Gateway đáp ứng đồng thời cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Sao chép dữ liệu lên AWS để khôi phục thảm hoạ | tệp tự đẩy lên S3 | | Script hiện chép vào máy chủ tệp Windows | File Gateway xuất SMB — script chỉ đổi đường dẫn | | Tệp GẦN ĐÂY phải truy cập ĐỘ TRỄ THẤP | CACHE cục bộ giữ tệp nóng |

Vế thứ ba là điểm quyết định của câu này:

File Gateway có đĩa cache tại chỗ
    → tệp vừa ghi và tệp hay đọc nằm trong cache
    → quản trị viên đọc với tốc độ mạng LAN
        ↓
    Tệp cũ không còn trong cache → tải về từ S3 khi cần
    → chậm hơn nhưng vẫn truy cập được

Và vế thứ hai đáng nhấn mạnh:

File Gateway xuất SMB (và NFS)
    → script hiện chép vào \\fileserver\backup
    → chỉ cần đổi thành \\filegateway\backup
        ↓
    Không phải viết lại script bằng AWS SDK

Cấu hình:

aws storagegateway create-smb-file-share   --client-token $(uuidgen) --gateway-arn <arn-gateway>   --location-arn arn:aws:s3:::sao-luu-dr   --role <arn-role> --authentication ActiveDirectory   --default-storage-class S3_STANDARD_IA

Và lifecycle chuyển bản cũ sang lớp rẻ:

{"Rules": [{"ID":"dr-dai-han","Status":"Enabled","Filter":{},
  "Transitions":[
    {"Days":30,"StorageClass":"GLACIER_IR"},
    {"Days":180,"StorageClass":"DEEP_ARCHIVE"}]}]}

Ba lợi ích cho tình huống DR: | Lợi ích | Chi tiết | |---|---| | Mỗi tệp là object S3 bình thường | khôi phục từ AWS được | | 11 số 9 độ bền | hơn hẳn máy chủ tệp một chỗ | | Không cần viết lại quy trình sao lưu | |

Vế đầu là điều làm File Gateway khác Volume Gateway:

File Gateway:    tệp thành OBJECT → EC2 ở vùng DR đọc thẳng từ S3
Volume Gateway:  dữ liệu dạng khối → chỉ đọc qua gateway
        ↓
    Khi thảm hoạ xảy ra, cách thứ nhất khôi phục nhanh hơn nhiều

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

• **C. Chép vào Amazon EFS — đây là phương án gần nhất vì cũng là hệ thống tệp trên AWS, nhưng nó không có cache cục bộ: mọi lần đọc đều đi qua đường mạng tới AWS, nên yêu cầu "độ trễ thấp cho tệp gần đây" không đạt. Và EFS đắt hơn S3 nhiều lần cho mục đích lưu trữ DR.
• **B. Chép vào S3 Glacier — sai hoàn toàn ở vế truy cập: Glacier cần khôi phục mất từ vài phút tới nhiều giờ, không thể gọi là "độ trễ thấp". Glacier là đích sau một thời gian, không phải đích ghi trực tiếp.
• **A. Chép vào EBS volume — EBS phải gắn vào một EC2 instance, script tại chỗ không ghi thẳng vào được. Và EBS chỉ nằm trong một AZ, độ bền kém hơn S3 nhiều.

Ghi nhớ

Bốn chế độ Storage Gateway — bảng phải thuộc: | Chế độ | Giao diện | Dùng cho | |---|---|---| | S3 File Gateway | NFS, SMB | tệp lên S3, có cache ← câu này | | FSx File Gateway | SMB | truy cập FSx for Windows tại chỗ | | Volume Gateway | iSCSI | ổ đĩa khối, snapshot EBS | | Tape Gateway | iSCSI VTL | thay thư viện băng từ |

Từ khoá nhận diện:

"low latency access to recent files" + "replicate to AWS" → File Gateway (có cache) "replace tape backup" → Tape Gateway "iSCSI block volumes" → Volume Gateway

Ba cách triển khai gateway: | Cách | Khi nào | |---|---| | Máy ảo (VMware, Hyper-V, KVM) | có hạ tầng ảo hoá ← câu này | | Hardware Appliance | không có tài nguyên ảo hoá | | EC2 | tải chạy trên AWS |

Ba yêu cầu tài nguyên cho thiết bị ảo: | Yêu cầu | Con số tối thiểu | |---|---| | vCPU | 4 | | RAM | 16 GB (khuyến nghị 32 GB) | | Đĩa cache | 150 GB |

Ba lưu ý về cache: | Lưu ý | Chi tiết | |---|---| | Cache lớn = nhiều tệp gần đây truy cập nhanh | | | Dùng SSD | | | Theo dõi CachePercentUsed và CacheHitPercent | |

CacheHitPercent là số quan trọng nhất ở bài này:

Tỷ lệ trúng cache thấp
    → quản trị viên vẫn phải chờ tải từ S3
    → yêu cầu "độ trễ thấp" không đạt trên thực tế
        ↓
    Tăng đĩa cache cho tới khi tỷ lệ trúng cao

Ba đặc điểm của SMB file share: | Đặc điểm | Chi tiết | |---|---| | Nối được Active Directory | phân quyền theo AD | | Hoặc dùng người dùng khách | đơn giản hơn | | Hỗ trợ ACL của Windows | |

Ba lưu ý về nhất quán: | Lưu ý | Chi tiết | |---|---| | Ghi vào share → đẩy lên S3 BẤT ĐỒNG BỘ | | | Object ghi thẳng vào S3 KHÔNG tự hiện trong share | | | RefreshCache hoặc CacheStaleTimeout | |

Vế thứ hai là chỗ dễ nhầm khi khôi phục:

Khôi phục dữ liệu từ vùng DR ghi thẳng vào bucket
    → gateway tại chỗ không thấy tệp mới
        ↓
    Phải gọi RefreshCache

aws storagegateway refresh-cache --file-share-arn <arn> --recursive

Ba lưu ý về băng thông: | Lưu ý | Chi tiết | |---|---| | Đặt giới hạn tải lên trong giờ làm việc | | | Lần đồng bộ đầu tiên tốn nhiều băng thông | | | Cân nhắc Snowball cho lượng ban đầu lớn | |

aws storagegateway update-bandwidth-rate-limit-schedule   --gateway-arn <arn> --bandwidth-rate-limit-intervals file://lich.json

Ba lựa chọn thay thế: | Lựa chọn | Đặc điểm | |---|---| | AWS DataSync | nhanh hơn cho di chuyển theo lịch, KHÔNG có cache | | AWS Backup Gateway | sao lưu máy ảo VMware | | FSx for Windows + File Gateway | nếu cần chia sẻ SMB đầy đủ |

DataSync và Storage Gateway — bảng phân biệt: | | DataSync | File Gateway | |---|---|---| | Mục đích | DI CHUYỂN | truy cập liên tục | | Cache cục bộ | ❌ | ✅ ← yêu cầu của đề | | Tốc độ | nhanh hơn | | | Chạy | theo lịch | liên tục |

Vì đề đòi "độ trễ thấp cho tệp gần đây", DataSync không đủ.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lưu trữ S3 theo lớp | | | Phí gateway theo lượng dữ liệu ghi | | | Phí lấy dữ liệu khi cache miss với lớp IA | |

Dòng cuối là chi tiết đáng cân nhắc:

Đặt lớp mặc định là S3_STANDARD_IA cho rẻ
    → nhưng mỗi lần cache miss phải trả phí lấy dữ liệu
        ↓
    Nếu quản trị viên đọc lại thường xuyên,
    S3 Standard rồi lifecycle sau 30 ngày lại rẻ hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi một tệp, xem nó lên S3 chưa | | | Đọc lại tệp cũ, đo thời gian | | | Diễn tập khôi phục từ vùng DR | |

Và một lời khuyên: hãy thực sự diễn tập khôi phục ít nhất một lần. Một kế hoạch DR chưa từng được thử là một giả thuyết — và thứ thường phát hiện ra trong buổi diễn tập đầu tiên không phải là dữ liệu bị thiếu, mà là không ai biết chính xác các bước phải làm theo thứ tự nào.

Đáp án

D — Tạo scheduled action đặt DESIRED CAPACITY lên 10 trước khi giờ làm việc bắt đầu.

Vì sao đúng

Đề nêu ba dữ kiện, và cả ba chỉ về một hướng: | Dữ kiện | Ý nghĩa | |---|---| | Ban đêm 2 máy, giờ làm việc 10 máy | mẫu tải LẶP LẠI và BIẾT TRƯỚC | | Chậm vào ĐẦU ngày làm việc | co giãn phản ứng quá muộn | | Vẫn phải tối thiểu chi phí | không giữ 10 máy cả đêm |

Vì sao co giãn phản ứng không kịp:

07:00 nhân viên bắt đầu đăng nhập
    → CPU tăng
    → alarm cần vài chu kỳ để kích hoạt (3-5 phút)
    → ASG khởi động máy mới (1-3 phút)
    → máy khởi động ứng dụng và qua health check (2-5 phút)
        ↓
    Tổng 6-13 phút mới có máy mới
    → nhân viên đã phàn nàn xong rồi

Co giãn theo lịch giải quyết đúng chỗ đó:

06:45 (trước giờ làm việc 15 phút)
    → đặt desired capacity = 10
    → máy khởi động XONG trước khi có người dùng đầu tiên
        ↓
    Đây gọi là "pre-warming" — làm nóng trước

Cấu hình:

aws autoscaling put-scheduled-update-group-action   --auto-scaling-group-name asg-ho-tro   --scheduled-action-name len-truoc-gio-lam   --recurrence "45 6 * * MON-FRI"   --desired-capacity 10   --time-zone "Asia/Ho_Chi_Minh"

Vì sao đặt DESIRED chứ không đặt MIN:

Đặt desired = 10:
    → có ngay 10 máy
    → nhưng chính sách co giãn theo tải VẪN hoạt động
    → tải nhẹ hơn dự kiến → ASG tự bớt xuống → TIẾT KIỆM

Đặt min = 10:
    → ÉP giữ ít nhất 10 máy suốt ngày
    → tải nhẹ cũng không bớt được
        ↓
    Vi phạm yêu cầu "minimizing costs"

Đây chính là điểm phân biệt B và D.

Và một scheduled action thứ hai cho buổi tối:

aws autoscaling put-scheduled-update-group-action   --auto-scaling-group-name asg-ho-tro   --scheduled-action-name xuong-sau-gio-lam   --recurrence "0 19 * * MON-FRI" --desired-capacity 2   --time-zone "Asia/Ho_Chi_Minh"

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Máy sẵn sàng TRƯỚC khi có tải | | | Vẫn co giãn theo tải trong ngày | | | Ban đêm vẫn xuống 2 máy | |

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

• **B. Scheduled action đặt min VÀ max = 10 trước giờ làm việc — đây là phương án gần nhất và giải quyết được vấn đề hiệu năng, nhưng nó khoá cứng ở 10 máy: min=10 chặn mọi lần bớt máy, max=10 chặn mọi lần thêm máy khi tải vượt dự kiến. Đề yêu cầu tối thiểu chi phí, mà khoá 10 máy suốt ngày là ngược lại.
• **A. Target tracking với ngưỡng CPU thấp hơn và cooldown ngắn hơn — vẫn là co giãn PHẢN ỨNG: phải có tải rồi mới thêm máy, nên vẫn có khoảng chậm đầu ngày. Ngưỡng thấp hơn còn làm hệ thống chạy dư máy suốt ngày, tăng chi phí.
• **C. Step scaling với ngưỡng CPU thấp hơn — cùng vấn đề như A, và step scaling phức tạp hơn mà không giải quyết được việc "tải đến đột ngột lúc 8 giờ sáng".

Ghi nhớ

Nguyên tắc gốc:

Tải BIẾT TRƯỚC → co giãn theo LỊCH. Tải KHÔNG đoán được → co giãn theo TẢI. Thực tế tốt nhất: kết hợp CẢ HAI.

Từ khoá nhận diện:

"poor performance at the beginning of business day" → scheduled action "business hours", "every Monday" → scheduled "unpredictable spikes" → target tracking

Ba tham số dung lượng của ASG — bảng phải thuộc: | Tham số | Nghĩa | |---|---| | min | sàn cứng — ASG KHÔNG bao giờ xuống dưới | | max | trần cứng — không bao giờ vượt | | desired | số máy MUỐN CÓ — co giãn thay đổi con số này |

Quy tắc chọn:

Muốn ĐẢM BẢO có sẵn máy nhưng vẫn cho co giãn → đặt DESIRED
Muốn ÉP không bao giờ xuống dưới một mức       → đặt MIN

Bốn kiểu co giãn: | Kiểu | Kích hoạt bởi | |---|---| | Scheduled | thời gian ← câu này | | Target tracking | metric bám mục tiêu | | Step scaling | ngưỡng theo bậc | | Predictive scaling | học máy dự đoán từ lịch sử |

Predictive scaling là lựa chọn hiện đại cho đúng bài này:

Bật predictive scaling → AWS phân tích 14 ngày lịch sử
    → tự học mẫu "8 giờ sáng tải tăng"
    → tự làm nóng trước
        ↓
    Không cần tự đặt lịch, tự thích nghi khi mẫu đổi

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-ho-tro   --policy-name du-doan --policy-type PredictiveScaling   --predictive-scaling-configuration '{
    "MetricSpecifications":[{"TargetValue":60,
      "PredefinedMetricPairSpecification":{"PredefinedMetricType":"ASGCPUUtilization"}}],
    "Mode":"ForecastAndScale",
    "SchedulingBufferTime":600}'

⚠ SchedulingBufferTime chính là "làm nóng trước bao nhiêu giây".

Ba định dạng thời gian cho scheduled action: | Định dạng | Ví dụ | |---|---| | Cron | "45 6 * * MON-FRI" | | Một lần | --start-time 2026-09-01T06:45:00Z | | Rate | không hỗ trợ ở đây |

⚠ Múi giờ là bẫy kinh điển:

Không khai --time-zone → ASG hiểu là UTC
    → "45 6" thành 13:45 giờ Việt Nam
        ↓
    Máy lên vào giữa buổi chiều
    → luôn khai --time-zone rõ ràng

Ba lưu ý khi kết hợp scheduled và target tracking: | Lưu ý | Chi tiết | |---|---| | Chúng chạy ĐỘC LẬP, không xung đột | | | Scheduled đặt điểm khởi đầu | | | Target tracking điều chỉnh tiếp | |

Nhưng có một tương tác cần biết:

Scheduled đặt desired = 10 lúc 06:45
    → 07:00 target tracking thấy CPU thấp (chưa ai làm việc)
    → nó BỚT máy xuống!
        ↓
    Cách chống: đặt lịch sát giờ tải đến hơn
    → hoặc tăng ScaleInCooldown
    → hoặc đặt min tạm thời rồi hạ min sau 1 giờ

Ba cách rút ngắn thời gian máy sẵn sàng: | Cách | Chi tiết | |---|---| | AMI có sẵn ứng dụng | không cài lúc khởi động | | Warm pool | máy đã dừng, khởi động rất nhanh | | healthCheckGracePeriod hợp lý | |

Warm pool là công cụ đúng khi khởi động chậm:

aws autoscaling put-warm-pool --auto-scaling-group-name asg-ho-tro   --min-size 8 --pool-state Stopped

Máy ở trạng thái Stopped: chỉ trả phí EBS, không trả phí compute
    → khởi động lại nhanh hơn nhiều so với tạo mới

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Chỉ trả cho giờ thực chạy | | | Ban đêm 2 máy tiết kiệm ~80% | | | Savings Plans cho phần tải nền | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem lịch sử hoạt động của ASG | describe-scaling-activities | | Kiểm tra máy sẵn sàng trước giờ tải | | | Hỏi lại nhân viên sau một tuần | |

aws autoscaling describe-scaling-activities   --auto-scaling-group-name asg-ho-tro --max-items 20

Và một lời khuyên: hãy đặt lịch sớm hơn ước tính của bạn khoảng 15 phút. Thời gian từ lúc ASG tăng desired capacity tới lúc máy thực sự phục vụ được gồm cả khởi động EC2, khởi động ứng dụng và qua health check — và con số đó gần như luôn dài hơn người ta nghĩ.

Đáp án

A — Xử lý mỗi phần bằng một ECS task riêng, và tạo hàng đợi Amazon SQS giữa chúng.

Vì sao đúng

Đề nêu hai dữ kiện, và cả hai chỉ về cùng một mẫu kiến trúc: | Dữ kiện | Vấn đề | Cách giải | |---|---|---| | Xử lý gồm HAI PHẦN | ràng buộc chặt vào nhau | tách thành hai task | | Phần thứ hai lâu hơn NHIỀU | phần nhanh phải chờ phần chậm | hàng đợi đệm giữa hai bên |

Vì sao hàng đợi là thứ cần thiết:

Không có hàng đợi:  task 1 xử lý xong → gọi thẳng task 2 → CHỜ
    → phần nhanh bị chặn bởi phần chậm
    → tăng tải là hỏng cả hai

Có SQS:             task 1 xử lý xong → ĐẨY thông điệp vào hàng đợi → xong việc
                    task 2 tự lấy khi rảnh
        ↓
    Hai bên chạy độc lập, mở rộng độc lập

Đây là mẫu "tách rời" kinh điển: | Lợi ích | Chi tiết | |---|---| | Tách rời theo thời gian | bên gửi không chờ bên nhận | | Đệm khi tải tăng | hàng đợi hấp thụ đợt cao điểm | | Mở rộng độc lập | phần chậm chạy nhiều task hơn |

Vế cuối là điều quan trọng nhất:

Phần 1 nhanh  → 2 task là đủ
Phần 2 chậm   → cần 20 task
        ↓
    Có hàng đợi ở giữa mới co giãn riêng được
    → và co giãn theo ĐỘ SÂU hàng đợi

Co giãn theo độ sâu hàng đợi:

aws application-autoscaling put-scaling-policy   --service-namespace ecs --resource-id service/cum/phan-2   --scalable-dimension ecs:service:DesiredCount   --policy-name theo-hang-doi --policy-type TargetTrackingScaling   --target-tracking-scaling-policy-configuration '{
    "TargetValue": 10.0,
    "CustomizedMetricSpecification": {
      "MetricName": "ApproximateNumberOfMessagesVisible",
      "Namespace": "AWS/SQS",
      "Dimensions": [{"Name":"QueueName","Value":"hang-doi-phan-2"}],
      "Statistic": "Average"}}'

Và một lợi ích nữa: độ bền.

Task 2 bị lỗi giữa chừng
    → thông điệp KHÔNG bị xoá (chưa gọi DeleteMessage)
    → hết visibility timeout → quay lại hàng đợi
    → task khác nhận và xử lý lại
        ↓
    Không mất việc

Task 2 xử 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_phan_hai(m['Body'])
        sqs.delete_message(QueueUrl=URL, ReceiptHandle=m['ReceiptHandle'])

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

• **B. Hai task riêng + SNS topic gửi thông báo khi xử lý xong — đây là phương án gần nhất vì cũng tách task và cũng dùng nhắn tin, nhưng SNS là mô hình đẩy, fan-out, không lưu trữ: nếu bên nhận đang bận hoặc chết, thông điệp mất. Với phần việc chạy lâu, đúng thứ cần là hàng đợi giữ việc lại, không phải thông báo bắn đi một lần.
• **D. Lưu kết quả phần một vào DynamoDB — đây là lưu trữ trạng thái, không phải cơ chế tách rời: vẫn phải có gì đó biết là có việc mới và kích hoạt phần hai, mà đề không nói tới. Tự dựng cơ chế polling bảng là viết lại SQS bằng tay.
• **C. Xử lý cả hai phần trong CÙNG một task + Kinesis Firehose — không tách rời gì cả, hai phần vẫn dính vào nhau. Và Firehose là dịch vụ nạp dữ liệu vào kho lưu trữ, không phải hàng đợi công việc.

Ghi nhớ

Ba dịch vụ nhắn tin của AWS — bảng phải thuộc: | Dịch vụ | Mô hình | Đặc điểm | |---|---|---| | Amazon SQS | hàng đợi, KÉO | một consumer lấy một thông điệp | | Amazon SNS | pub/sub, ĐẨY | fan-out tới nhiều nơi | | EventBridge | định tuyến sự kiện | lọc theo nội dung, nhiều nguồn |

Từ khoá nhận diện:

"decouple", "one part takes much longer" → SQS "notify multiple subscribers", "fan-out" → SNS "route events by content", "SaaS integration" → EventBridge

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

Và cách giao: | Loại | Giao | |---|---| | Standard | ít nhất một lần — CÓ THỂ TRÙNG | | FIFO | đúng một lần |

Với Standard, consumer phải idempotent — xử lý cùng thông điệp hai lần không được gây hại.

Ba tham số quan trọng của SQS: | Tham số | Mặc định | Ý nghĩa | |---|---|---| | Visibility timeout | 30 giây | thời gian ẩn thông điệp khi đang xử lý | | Message retention | 4 ngày | tối đa 14 ngày | | Long polling (WaitTimeSeconds) | 0 | đặt 20 để giảm chi phí |

⚠ Visibility timeout là chỗ hay hỏng nhất với việc chạy lâu:

Phần 2 mất 10 phút, visibility timeout 30 giây
    → sau 30 giây thông điệp hiện lại
    → task KHÁC cũng nhận và xử lý
        ↓
    Cùng một việc chạy nhiều lần song song
    → đặt visibility timeout ≥ thời gian xử lý dài nhất

aws sqs set-queue-attributes --queue-url $URL   --attributes VisibilityTimeout=900

Hoặc gia hạn động khi đang xử lý:

sqs.change_message_visibility(QueueUrl=URL,
    ReceiptHandle=rh, VisibilityTimeout=600)

Giới hạn cứng cần biết: | Giới hạn | Con số | |---|---| | Visibility timeout tối đa | 12 giờ | | Kích thước thông điệp | 256 KB | | Retention tối đa | 14 ngày |

Việc chạy quá 12 giờ thì SQS không hợp — dùng Step Functions với callback pattern.

Payload lớn hơn 256 KB:

Dùng Extended Client Library
    → lưu nội dung thật vào S3
    → thông điệp chỉ chứa con trỏ tới object

Dead-letter queue là thứ BẮT BUỘC phải có:

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

Không có DLQ:  thông điệp lỗi quay lại mãi
               → chiếm chỗ, tốn tiền, che khuất việc bình thường
        ↓
    Có DLQ: thử 3 lần rồi chuyển sang hàng đợi riêng để điều tra

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | tồn đọng — dùng để co giãn | | ApproximateAgeOfOldestMessage | có bị kẹt không | | Số thông điệp trong DLQ | có lỗi hệ thống |

Metric thứ hai đáng đặt alarm nhất — hàng đợi ngắn mà thông điệp cũ nghĩa là có gì đó không xử lý được.

Ba mẫu kết hợp SNS + SQS: | Mẫu | Việc | |---|---| | SNS fan-out tới nhiều SQS | nhiều hệ thống cùng nhận, mỗi bên có hàng đợi riêng | | SQS trước Lambda | Lambda tự lấy theo lô | | EventBridge → SQS | định tuyến rồi đệm |

Mẫu đầu là câu trả lời cho "vừa muốn fan-out vừa muốn độ bền".

Ba lưu ý cho ECS làm consumer: | Lưu ý | Chi tiết | |---|---| | Task role cần sqs:ReceiveMessage, DeleteMessage | | | Xử lý SIGTERM để hoàn tất việc đang làm | | | stopTimeout đủ dài | |

Vế thứ hai quan trọng khi scale in:

ECS dừng task → gửi SIGTERM → chờ stopTimeout → SIGKILL
    → không xử lý SIGTERM thì việc đang làm bị cắt giữa chừng
        ↓
    Thông điệp quay lại hàng đợi (tốt) nhưng công đã làm bị phí

Ba lựa chọn thay thế cho quy trình nhiều bước: | Lựa chọn | Khi nào | |---|---| | SQS giữa các task | đơn giản, hai bước ← câu này | | AWS Step Functions | nhiều bước, cần điều phối và thử lại | | Amazon MWAA | quy trình dữ liệu phức tạp |

Và một lời khuyên: hãy đặt visibility timeout bằng thời gian xử lý dài nhất cộng thêm biên an toàn, rồi đặt alarm trên ApproximateAgeOfOldestMessage. Việc cùng một thông điệp bị hai task xử lý song song rất khó phát hiện — nó không sinh lỗi, chỉ sinh ra kết quả trùng, và thường chỉ lộ ra khi ai đó thắc mắc vì sao báo cáo có số liệu gấp đôi.

Đáp án

C — Dùng Amazon EFS ở chế độ General Purpose performance mode, mount trên mọi EC2 instance.

Vì sao đúng

Đề nêu bốn yêu cầu, và EFS thoả cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | Nhiều instance trong ASG cùng truy cập dữ liệu | EFS mount đồng thời trên hàng nghìn máy | | Tính sẵn sàng cao | EFS trải nhiều AZ tự động | | Tiết kiệm chi phí | trả theo dung lượng thực dùng, có lớp IA | | SỬA MÃ ÍT NHẤT | vẫn là hệ thống tệp POSIX — đường dẫn thay đổi, mã không đổi |

Vế cuối là điểm quyết định của câu này:

Ứng dụng Python hiện đang đọc ghi tệp trên EBS:
    with open('/du-lieu/khach-hang.csv') as f: ...

Chuyển sang EFS:
    with open('/mnt/efs/khach-hang.csv') as f: ...
        ↓
    Đổi ĐÚNG một chuỗi đường dẫn
    → hoặc mount EFS vào chính /du-lieu thì không đổi gì cả

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

EBS gp3 gắn vào MỘT instance tại một thời điểm
    → ASG nhiều máy → mỗi máy một volume riêng
    → dữ liệu phân mảnh, không ai thấy đủ

Mount EFS:

sudo yum install -y amazon-efs-utils
sudo mount -t efs -o tls fs-0123456789abcdef0:/ /du-lieu

Và trong /etc/fstab để tự mount khi khởi động:

fs-0123456789abcdef0:/ /du-lieu efs _netdev,tls 0 0

Vì sao General Purpose là chế độ đúng: | Chế độ | Đặc điểm | |---|---| | General Purpose | độ trễ THẤP NHẤT — mặc định, hợp hầu hết ứng dụng | | Max I/O | thông lượng cao hơn nhưng độ trễ cao hơn |

Max I/O chỉ đáng dùng khi có HÀNG NGHÌN máy truy cập đồng thời
    → ứng dụng phân tích trên một ASG không tới mức đó
        ↓
    General Purpose cho độ trễ tốt hơn

Ba đặc điểm về tính sẵn sàng: | Đặc điểm | Chi tiết | |---|---| | Dữ liệu nhân bản qua nhiều AZ (Standard) | | | Mount target ở mỗi AZ | | | Instance mới của ASG tự mount được | |

Và ba cách tiết kiệm: | Cách | Chi tiết | |---|---| | Lifecycle chuyển sang IA sau 30 ngày | rẻ hơn ~85% | | Elastic Throughput trả theo lượng đọc ghi thật | | | Trả theo dung lượng THỰC DÙNG | không cấp phát 1 TB trước |

Điểm cuối đáng nhấn mạnh:

EBS 1 TB: trả tiền cho 1 TB dù chỉ dùng 200 GB
EFS:      trả cho đúng 200 GB đang dùng
        ↓
    Với dữ liệu tăng dần, EFS có thể RẺ HƠN

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

• **A. Dùng Amazon S3 và REST API — đây là phương án gần nhất về mặt chia sẻ dữ liệu, và rẻ hơn EFS nhiều, nhưng nó vi phạm yêu cầu "sửa mã ít nhất": phải viết lại mọi thao tác tệp bằng boto3, xử lý tải lên/tải xuống, xử lý tệp lớn. Đề nêu rõ ràng buộc này.
• **B. Dùng FSx for Lustre tích hợp S3 — hoạt động được và rất nhanh, nhưng quá mức và đắt: Lustre dành cho HPC và học máy với thông lượng hàng trăm GB/s. Với ứng dụng Python xử lý dữ liệu khách hàng thì đây là chi phí không cần thiết.
• **D. Dựng một EC2 làm máy chủ NFS chia sẻ EBS volume — tạo ra điểm hỏng đơn lẻ: máy NFS đó chết là cả ASG mất dữ liệu, và bạn phải tự vá lỗi, tự sao lưu, tự lo mở rộng. Ngược hẳn yêu cầu "tính sẵn sàng cao".

Ghi nhớ

Ba loại lưu trữ — bảng phải thuộc: | Loại | Dịch vụ | Nhiều máy dùng chung | |---|---|---| | Block | EBS | ❌ | | File | EFS, FSx | ✅ | | Object | S3 | ✅ qua API |

Từ khoá nhận diện:

"multiple instances, same data" + "minimal code changes" → EFS "multiple instances, same data" + không ràng buộc mã → S3 (rẻ hơn) "HPC", "machine learning", "hundreds of GB/s" → FSx for Lustre "Windows", "SMB", "Active Directory" → FSx for Windows

Bốn dịch vụ FSx: | Dịch vụ | Dùng cho | |---|---| | FSx for Windows File Server | SMB, AD | | FSx for Lustre | HPC, ML, thông lượng cực cao | | FSx for NetApp ONTAP | đa giao thức, tính năng NetApp | | FSx for OpenZFS | di chuyển từ ZFS |

Hai chế độ hiệu năng EFS: | Chế độ | Độ trễ | Thông lượng | |---|---|---| | General Purpose | thấp nhất | tới 35.000 IOPS | | Max I/O | cao hơn | cao hơn |

⚠ Chế độ hiệu năng KHÔNG đổi được sau khi tạo — phải tạo file system mới và chép dữ liệu.

Ba chế độ thông lượng: | Chế độ | Đặc điểm | |---|---| | Elastic | tự co giãn, trả theo lượng dùng ← khuyến nghị | | Bursting | theo dung lượng, có credit | | Provisioned | cố định, trả theo mức khai |

⚠ Bursting là bẫy với file system nhỏ:

Thông lượng cơ sở của Bursting = 50 KB/s mỗi GB
    → file system 100 GB → chỉ 5 MB/s cơ sở
    → burst credit cạn → ứng dụng chậm đột ngột
        ↓
    Elastic tránh hẳn vấn đề này

Bốn lớp lưu trữ EFS: | Lớp | Giá tương đối | |---|---| | Standard | cao nhất | | Infrequent Access (IA) | rẻ hơn ~85%, có phí đọc | | Archive | rẻ hơn nữa | | One Zone | rẻ hơn nhưng chỉ một AZ |

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

Chính sách cuối là thứ nên có: tệp bị đọc lại sẽ tự quay về Standard, tránh trả phí đọc IA nhiều lần.

Ba yêu cầu mạng: | Yêu cầu | Chi tiết | |---|---| | Mount target ở MỖI AZ có instance | | | Security group EFS mở cổng 2049 | NFS | | Nguồn là security group của EC2 | |

aws ec2 authorize-security-group-ingress --group-id sg-efs   --protocol tcp --port 2049 --source-group sg-ung-dung

Ba bước chuyển từ EBS sang EFS: | Bước | Việc | |---|---| | Tạo EFS, mount tạm trên máy hiện tại | | | rsync -av /du-lieu/ /mnt/efs/ | | | Đổi mount point, cập nhật launch template | |

Vế cuối là chỗ không được quên:

Chỉ sửa fstab trên máy đang chạy
    → ASG tạo máy mới → không mount EFS
    → ghi vào đĩa cục bộ → mất khi máy bị thay
        ↓
    Lệnh mount phải nằm trong user data của launch template

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá at rest bật khi TẠO | không bật sau được | | -o tls cho mã hoá đường truyền | | | Access point giới hạn thư mục và UID/GID | |

Ba lưu ý về hiệu năng với Python: | Lưu ý | Chi tiết | |---|---| | Nhiều tệp nhỏ chậm hơn ít tệp lớn | mỗi thao tác là một vòng mạng | | Đọc tuần tự tốt hơn ngẫu nhiên | | | Không đặt CSDL SQLite trên EFS | khoá tệp qua NFS không đáng tin |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | PercentIOLimit | gần 100% là chạm trần General Purpose | | BurstCreditBalance | nếu dùng Bursting | | ClientConnections | số máy đang mount |

Metric đầu là dấu hiệu duy nhất cho biết có nên đổi sang Max I/O:

PercentIOLimit thường xuyên gần 100%
    → General Purpose đã chạm trần IOPS
        ↓
    Đây là lúc duy nhất Max I/O đáng cân nhắc

Và một lời khuyên: hãy đặt lifecycle chuyển sang IA ngay từ khi tạo file system. Dữ liệu phân tích thường được đọc nhiều trong tuần đầu rồi gần như không đụng tới nữa — và nếu đợi đến khi hoá đơn tăng mới nhớ ra, bạn đã trả giá Standard cho hàng trăm GB dữ liệu nguội suốt nhiều tháng.

Đáp án

A — Tạo và dùng một custom endpoint trỏ tới ba replica có cấu hình cao.

Vì sao đúng

Đề nêu ba yêu cầu, và custom endpoint là thứ duy nhất thoả cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Cụm có 8 Aurora Replica | | | Truy vấn báo cáo chỉ đi tới BA replica cụ thể | custom endpoint chọn đúng ba máy | | Phân phối TỰ ĐỘNG giữa chúng | Aurora cân bằng tải trong endpoint |

Vế thứ ba là điểm phân biệt A với D:

Custom endpoint:   một tên DNS → Aurora tự luân phiên giữa 3 replica
    → thêm bớt replica chỉ cần sửa endpoint, ứng dụng không đổi

Instance endpoint: mỗi replica một tên DNS riêng
    → ứng dụng phải TỰ chọn và tự cân bằng
    → replica chết thì ứng dụng vẫn gửi vào đó

Tạo custom endpoint:

aws rds create-db-cluster-endpoint   --db-cluster-identifier cum-don-hang   --db-cluster-endpoint-identifier bao-cao   --endpoint-type READER   --static-members replica-lon-1 replica-lon-2 replica-lon-3

Kết quả là một tên DNS riêng:

bao-cao.cluster-custom-abc123.ap-southeast-1.rds.amazonaws.com
    ↓
Đội phân tích trỏ vào đây
Ứng dụng đơn hàng vẫn dùng reader endpoint chung

Vì sao cần tách như vậy:

Truy vấn báo cáo NẶNG, chạy lâu
    → nếu dùng chung reader endpoint
    → nó rơi vào bất kỳ replica nào trong 8 cái
    → replica phục vụ đơn hàng bị chậm theo
        ↓
    Custom endpoint cô lập tải phân tích

Hai kiểu danh sách thành viên: | Kiểu | Hành vi | |---|---| | --static-members | liệt kê rõ replica nào thuộc endpoint | | --excluded-members | liệt kê replica KHÔNG thuộc, còn lại tự vào |

Static:   thêm replica mới → KHÔNG tự vào endpoint
Excluded: thêm replica mới → TỰ vào endpoint
        ↓
    Ở bài này dùng static vì chỉ ba máy cấu hình cao

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 | | | Tự cân bằng giữa các thành viên | | | Đổi thành viên không cần sửa ứng dụng | |

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

• **D. Trỏ truy vấn báo cáo vào instance endpoint của ba replica — đây là phương án gần nhất và về mặt định tuyến thì tới đúng nơi, nhưng nó không phân phối tự động: ứng dụng phải tự chọn một trong ba tên DNS, tự cân bằng, và tự phát hiện khi một replica chết. Đề nêu rõ "automatically distributed".
• **C. Dùng reader endpoint — nó phân phối tự động, nhưng trải trên CẢ TÁM replica, gồm cả năm máy cấu hình thấp. Truy vấn báo cáo rơi vào máy nhỏ sẽ chậm, và làm chậm luôn tải giao dịch đang chạy ở đó.
• **B. Tạo cluster clone cho tải báo cáo — clone tạo ra một cụm tách hẳn, dữ liệu đóng băng ở thời điểm clone, nên báo cáo sẽ chạy trên dữ liệu cũ. Và writer endpoint của clone chỉ trỏ tới một instance ghi, không phân phối gì.

Ghi nhớ

Bốn loại endpoint của Aurora — bảng phải thuộc: | Endpoint | Trỏ tới | Dùng cho | |---|---|---| | Cluster (writer) | instance CHÍNH hiện tại | ghi | | Reader | cân bằng qua MỌI replica | đọc chung | | Custom | nhóm instance TỰ CHỌN | tách tải ← câu này | | Instance | một instance cụ thể | chẩn đoán, điều chỉnh |

Từ khoá nhận diện:

"specific replicas" + "automatically distributed" → custom endpoint "distribute reads across all replicas" → reader endpoint "connect to a particular instance" → instance endpoint

Ba đặc điểm của writer endpoint: | Đặc điểm | Chi tiết | |---|---| | Luôn trỏ tới instance chính | | | Khi failover, TỰ trỏ sang instance mới | | | Ứng dụng không cần đổi chuỗi kết nối | |

Vế thứ hai là lý do luôn phải dùng endpoint, không dùng IP hay tên instance.

Ba đặc điểm của reader endpoint: | Đặc điểm | Chi tiết | |---|---| | Cân bằng tải qua DNS round-robin | | | Chỉ gồm Aurora Replica, không gồm writer | | | Replica mới TỰ vào | |

⚠ Cân bằng qua DNS có hạn chế thật sự:

Cân bằng xảy ra lúc PHÂN GIẢI DNS, không phải mỗi truy vấn
    → connection pool giữ kết nối lâu
    → mọi truy vấn dồn vào một replica đã phân giải lúc đầu
        ↓
    Cách chữa: đặt TTL ngắn, hoặc dùng RDS Proxy,
    hoặc mở lại kết nối định kỳ

Ba đặc điểm của custom endpoint: | Đặc điểm | Chi tiết | |---|---| | Tối đa 5 custom endpoint mỗi cụm | | | Chọn theo static hoặc excluded members | | | Cũng cân bằng tải trong nhóm | |

Ba trường hợp dùng custom endpoint: | Trường hợp | Chi tiết | |---|---| | Tách tải phân tích khỏi giao dịch | ← câu này | | Nhóm replica cấu hình khác nhau | | | Nhóm cho môi trường thử nghiệm | |

Ba đặc điểm của Aurora Replica: | Đặc điểm | Chi tiết | |---|---| | Tối đa 15 replica | | | Chia sẻ CÙNG tầng lưu trữ với writer | | | Độ trễ sao chép thường < 100 ms | |

Vế thứ hai là điều làm Aurora khác RDS read replica:

RDS read replica:  sao chép DỮ LIỆU qua binlog → độ trễ giây
Aurora Replica:    đọc CÙNG một tầng lưu trữ → độ trễ mili giây
        ↓
    Và thêm replica Aurora không tốn thêm lưu trữ

Ba ưu tiên failover (promotion tier): | Tier | Ý nghĩa | |---|---| | 0 | được chọn làm writer trước tiên | | 1-15 | ưu tiên giảm dần | | — | cùng tier thì chọn máy lớn nhất |

Chi tiết đáng nhớ ở bài này:

Ba replica cấu hình cao có tier thấp
    → khi failover, một trong chúng thành writer
    → custom endpoint mất một thành viên
        ↓
    Đặt tier CAO cho replica báo cáo
    → chúng không bị chọn làm writer

aws rds modify-db-instance --db-instance-identifier replica-lon-1   --promotion-tier 15

Ba lưu ý về truy vấn phân tích trên replica: | Lưu ý | Chi tiết | |---|---| | Truy vấn dài có thể bị huỷ khi replica bận | | | max_execution_time giới hạn truy vấn chạy hoang | | | Cân nhắc Aurora clone hoặc snapshot cho báo cáo nặng | |

Ba lựa chọn cho tải phân tích: | Lựa chọn | Khi nào | |---|---| | Custom endpoint tới replica riêng | báo cáo gần thời gian thực ← câu này | | Aurora clone | phân tích trên ảnh chụp, không ảnh hưởng production | | Export sang S3 + Athena / Redshift | phân tích nặng, lịch sử dài |

Aurora clone đáng biết vì nó rất rẻ:

aws rds restore-db-cluster-to-point-in-time   --source-db-cluster-identifier cum-don-hang   --db-cluster-identifier cum-bao-cao --restore-type copy-on-write   --use-latest-restorable-time

Copy-on-write: chỉ trả tiền cho phần dữ liệu THAY ĐỔI sau khi clone
    → clone một cụm 10 TB gần như miễn phí lúc đầu

Ba lưu ý về RDS Proxy: | Lưu ý | Chi tiết | |---|---| | Gộp kết nối, giảm áp lực lên CSDL | | | Rút ngắn thời gian failover | | | Có endpoint chỉ đọc riêng | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | AuroraReplicaLag | độ trễ sao chép | | DatabaseConnections theo instance | có cân bằng không | | SelectLatency | |

Metric thứ hai là cách kiểm chứng custom endpoint có hoạt động không — nếu ba replica có số kết nối lệch hẳn nhau thì cân bằng DNS đang không hiệu quả.

Và một lời khuyên: hãy đặt promotion-tier cao cho các replica trong custom endpoint báo cáo. Nếu không, một lần failover bình thường có thể biến chính máy phân tích thành instance ghi của hệ thống đơn hàng — và lúc đó truy vấn báo cáo nặng sẽ chạy trên máy đang phục vụ giao dịch.