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

Đáp án

**A — Đóng gói từng ứng dụng thành container Docker rồi triển khai lên một cụm ECS đứng sau một Application Load Balancer.

Vì sao đúng

Đề mô tả một tập ứng dụng có đặc điểm rất riêng:

Hàng trăm ứng dụng PoC và demo
        ↓
    PHP, JavaScript, Python — nhỏ,
      đơn giản
        ↓
    KHÔNG còn phát triển nữa
    → và LƯU LƯỢNG RẤT THẤP

⚠ Điểm mấu chốt: hàng trăm ứng dụng lưu lượng thấp — mật độ là tất cả:

Mỗi ứng dụng một EC2
        ↓
    Hàng trăm instance chạy 24/7
      gần như không tải
        ↓
    Container: hàng chục ứng dụng
      trên một máy
    → tận dụng hết tài nguyên

⚠ Và đây là lý do phương án C thất bại nặng nhất:

C dùng SMS tạo AMI và chạy MỖI
  ứng dụng trên MỘT EC2 riêng
        ↓
    Hàng trăm instance
        ↓
    Chi phí hạ tầng cao nhất trong
      bốn phương án

⚠ Và ALB với định tuyến theo host cho phép dùng chung một load balancer:

{"Conditions": [{"Field": "host-header",
                 "Values": ["demo1.cong-ty.vn"]}],
 "Actions": [{"Type": "forward",
              "TargetGroupArn": "<tg-demo1>"}],
 "Priority": 1}

Một ALB, hàng trăm quy tắc
    → mỗi ứng dụng một tên miền
      con
        ↓
    Không phải trả tiền cho hàng
      trăm load balancer

⚠ Và ECS trên Fargate bỏ luôn việc quản máy chủ:

aws ecs create-service --cluster cum-demo \
  --service-name demo1 \
  --task-definition demo1:1 \
  --launch-type FARGATE \
  --desired-count 1 \
  --network-configuration 'awsvpcConfiguration={
    subnets=[subnet-1a],securityGroups=[sg-app]}' \
  --load-balancers targetGroupArn=<tg-demo1>,\
containerName=demo1,containerPort=8080

⚠ Nhưng với hàng trăm ứng dụng lưu lượng thấp, EC2 launch type rẻ hơn: | Kiểu | Cách tính tiền | |---|---| | Fargate | theo vCPU-giờ và GB-giờ MỖI TASK | | EC2 launch type | theo instance, nhiều task dùng chung |

300 task nhỏ trên Fargate
    → trả tiền cho 300 phần tài
      nguyên tối thiểu
        ↓
    300 task trên vài instance
      lớn: trả tiền cho vài instance
    → rẻ hơn nhiều

⚠ Và "ít công sức phát triển nhất" là tiêu chí loại phương án D:

D viết lại thành Lambda + DynamoDB
        ↓
    Ứng dụng "không còn được phát
      triển"
    → viết lại là công sức lớn nhất
        ↓
    Và PHP không phải runtime sẵn
      của Lambda

⚠ Và vì sao phương án B không hợp:

B nhập VM thành AMI rồi chạy
  Elastic Beanstalk single-instance
        ↓
    Vẫn là MỘT EC2 mỗi ứng dụng
        ↓
    Và "custom image" trong Beanstalk
      là quy trình phức tạp hơn
      Dockerfile nhiều

Dockerfile cho ứng dụng PHP cũ:

FROM php:8.2-apache
COPY . /var/www/html/
RUN docker-php-ext-install mysqli
EXPOSE 80

Ba dòng cho một ứng dụng PHP
    → đây chính là "ít công sức
      phát triển"

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mật độ cao, tận dụng hết tài nguyên | | | Một ALB phục vụ hàng trăm ứng dụng | | | Đóng gói đơn giản, không viết lại mã | |

⚠ Và App2Container tự động hoá việc đóng gói:

sudo app2container inventory
sudo app2container analyze --application-id java-app-id
sudo app2container containerize --application-id java-app-id

Phân tích ứng dụng đang chạy
    → sinh Dockerfile và task
      definition
        ↓
    Hỗ trợ Java và .NET
    → PHP/Python thì viết
      Dockerfile tay, cũng rất ngắn

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

⚠ Với ứng dụng gần như không có lưu lượng, có lựa chọn rẻ hơn container.

Nhiều PoC và demo chỉ là trang
  tĩnh hoặc JavaScript phía client
        ↓
    Đưa lên S3 + CloudFront
    → chi phí gần bằng không
        ↓
    Câu hỏi giả định mọi ứng dụng
      đều cần máy chủ chạy liên tục

Và "hàng trăm ứng dụng" đặt ra vấn đề hạn ngạch mà đề không nhắc: | Hạn ngạch | Giá trị | |---|---| | Quy tắc mỗi ALB listener | 100 (nâng lên được) | | Target group mỗi ALB | 100 | | Chứng chỉ mỗi listener | 25 |

Hàng trăm ứng dụng trên một ALB
        ↓
    Chạm hạn ngạch quy tắc
    → phải xin nâng, hoặc dùng
      nhiều ALB

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

• **B. Dùng VM Import/Export tạo AMI cho từng máy ảo và chạy trong môi trường Elastic Beanstalk single-instance với custom image — đây là phương án gần nhất và thật sự chuyển được ứng dụng lên AWS với ít sửa mã, nhưng vẫn là một EC2 cho mỗi ứng dụng, chi phí hạ tầng cao.
• **C. Dùng Server Migration Service tạo AMI và chạy mỗi ứng dụng trên một EC2 riêng — chi phí cao nhất; và SMS đã ngừng, thay bằng MGN.
• **D. Viết lại sang Lambda và DynamoDB — công sức phát triển lớn nhất, trái hẳn yêu cầu, cho những ứng dụng không còn được phát triển.

Ghi nhớ

⚠ Bốn cách chạy ứng dụng web trên AWS — bảng phải thuộc: | Cách | Mật độ | Công sức | |---|---|---| | EC2 riêng mỗi ứng dụng | thấp nhất | thấp | | ECS/EKS | cao | cần đóng gói | | App Runner | cao, co giãn về 0 | rất thấp | | Lambda | cao nhất | cần viết lại |

Từ khoá nhận diện:

"many low-traffic apps, lowest infra cost" → container, mật độ cao "least development effort" → đóng gói, đừng viết lại "lift and shift servers" → MGN "scale to zero" → Lambda hoặc App Runner

Ba lưu ý về ECS: | Lưu ý | Chi tiết | |---|---| | EC2 launch type rẻ hơn cho tải ổn định, mật độ cao | | | Fargate không quản máy chủ, hợp với tải biến động | | | Capacity provider trộn được cả hai | |

⚠ Capacity provider dùng Spot cho môi trường demo:

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

Ứng dụng demo chịu được gián đoạn
        ↓
    Fargate Spot rẻ hơn tới 70%

Ba lưu ý về ALB: | Lưu ý | Chi tiết | |---|---| | Định tuyến theo host, đường dẫn, header, query | | | Gắn nhiều chứng chỉ, chọn theo SNI | | | Hạn ngạch quy tắc nâng lên được | |

Ba lưu ý về đóng gói ứng dụng cũ: | Lưu ý | Chi tiết | |---|---| | Image cơ sở chính thức có sẵn cho PHP, Python, Node | | | Trạng thái phải đưa ra ngoài container | | | Tệp tải lên đưa sang S3 hoặc EFS | |

⚠ Container là ephemeral — dữ liệu ghi vào nó sẽ mất:

Ứng dụng cũ ghi tệp vào thư mục
  cục bộ
        ↓
    Container khởi động lại → mất
        ↓
    Mount EFS, hoặc đổi sang S3

Ba lưu ý về ECR: | Lưu ý | Chi tiết | |---|---| | Quét lỗ hổng image tự động | | | Luật vòng đời xoá image cũ | | | Pull through cache cho image công khai | |

Ba lưu ý về chi phí: | Khoản | Cách giảm | |---|---| | Instance | Savings Plan hoặc Spot | | ALB | dùng chung một ALB | | Truyền dữ liệu | VPC endpoint cho ECR và S3 |

Ba lưu ý về vận hành: | Lưu ý | Chi tiết | |---|---| | Container Insights cho chỉ số | | | awslogs driver đẩy log ra CloudWatch | | | Health check ở cả task và target group | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo mức dùng CPU/RAM thật của cụm | | | So chi phí với phương án một EC2 mỗi ứng dụng | | | Kiểm định tuyến theo host hoạt động đúng | |

Và một lời khuyên: hãy rà lại xem có bao nhiêu trong số hàng trăm ứng dụng đó thật sự còn ai dùng. Với một kho PoC và demo tích luỹ nhiều năm, chiến lược rẻ nhất thường không phải là di trú chúng cho hiệu quả — mà là tắt hẳn phần lớn trong số đó.

Đáp án

**A — Multi-AZ dùng sao chép ĐỒNG BỘ và trải ít nhất hai Availability Zone trong cùng một Region; Read Replica dùng sao chép KHÔNG ĐỒNG BỘ và đặt được trong cùng AZ, khác AZ, hoặc khác Region.

Vì sao đúng

Câu này kiểm tra hai thuộc tính, và chỉ một tổ hợp đúng: | Cơ chế | Kiểu sao chép | Phạm vi | |---|---|---| | Multi-AZ | ĐỒNG BỘ | ít nhất 2 AZ, cùng Region | | Read Replica | KHÔNG ĐỒNG BỘ | cùng AZ, khác AZ, hoặc khác Region |

⚠ Sao chép đồng bộ là lý do Multi-AZ không mất dữ liệu:

Giao dịch được xác nhận CHỈ KHI
  cả hai bản đã ghi xong
        ↓
    Instance chính chết ngay sau đó
    → standby vẫn có đủ dữ liệu
        ↓
    RPO = 0

⚠ Và sao chép không đồng bộ là lý do read replica có độ trễ:

Instance chính xác nhận giao dịch
  NGAY
        ↓
    Rồi mới gửi thay đổi sang replica
        ↓
    Replica tụt lại vài mili giây
      tới vài giây
    → đọc từ replica có thể thấy
      dữ liệu cũ

Theo dõi độ trễ:

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=replica-1 \
  --statistics Maximum --period 60 \
  --start-time 2026-09-01T00:00:00Z --end-time 2026-09-01T01:00:00Z

⚠ Và đây là lý do ba phương án còn lại sai:

B nói Multi-AZ KHÔNG ĐỒNG BỘ
    → sai vế thứ nhất
        ↓
C nói Multi-AZ không đồng bộ VÀ
  replica đồng bộ
    → sai cả hai vế
        ↓
D nói Multi-AZ trải MỘT AZ
    → mâu thuẫn với chính tên gọi

⚠ Và "Multi-AZ trải một AZ" trong phương án D là mâu thuẫn tự thân:

Multi-AZ = nhiều Availability Zone
        ↓
    Trải một AZ thì không còn là
      Multi-AZ
        ↓
    Đây là loại phương án tự phủ
      định, loại được ngay

⚠ Và cần nhớ: standby của Multi-AZ KHÔNG phục vụ đọc:

Nhiều người tưởng standby chia
  được tải đọc
        ↓
    Với Multi-AZ kiểu INSTANCE:
      standby hoàn toàn thụ động
        ↓
    Chỉ có Multi-AZ DB CLUSTER
      (2 reader) mới đọc được

⚠ Và read replica cùng AZ là cấu hình ít người biết nhưng hợp lệ:

aws rds create-db-instance-read-replica \
  --db-instance-identifier replica-cung-az \
  --source-db-instance-identifier csdl-chinh \
  --availability-zone ap-southeast-1a

Cùng AZ: độ trễ sao chép thấp
  nhất, không tốn phí liên AZ
        ↓
    Nhưng mất AZ đó là mất cả hai

⚠ Và read replica liên Region phục vụ hai mục đích:

Giảm độ trễ đọc cho người dùng
  ở xa
        ↓
    Và làm bản dự phòng cho khôi
      phục thảm hoạ
        ↓
    Promote được thành instance
      độc lập

Ba lợi ích khi hiểu đúng hai cơ chế: | Lợi ích | Chi tiết | |---|---| | Chọn đúng công cụ cho đúng bài toán | | | Không kỳ vọng standby chia tải đọc | | | Biết trước độ trễ khi đọc từ replica | |

⚠ Và độ trễ replica gây lỗi logic trong ứng dụng:

Ghi vào chính, đọc ngay từ replica
        ↓
    Chưa thấy dữ liệu vừa ghi
    → người dùng tưởng thao tác
      thất bại
        ↓
    Quy tắc: sau khi ghi, đọc từ
      chính trong cùng phiên

⚠ Và promote read replica là thao tác MỘT CHIỀU:

aws rds promote-read-replica \
  --db-instance-identifier replica-1

Promote xong: thành instance
  độc lập
        ↓
    Không quay lại làm replica được
    → phải tạo replica mới nếu cần

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

• **B. Multi-AZ dùng sao chép không đồng bộ; read replica không đồng bộ, đặt được nhiều nơi — đây là phương án gần nhất và vế về read replica hoàn toàn đúng, nhưng Multi-AZ dùng sao chép đồng bộ; đó chính là điều bảo đảm không mất dữ liệu khi chuyển đổi.
• **C. Multi-AZ không đồng bộ; read replica đồng bộ — sai cả hai vế.
• **D. Multi-AZ không đồng bộ và trải một AZ; read replica đồng bộ — "Multi-AZ trải một AZ" tự mâu thuẫn.

Ghi nhớ

⚠ Multi-AZ và Read Replica — bảng phải thuộc: | Tiêu chí | Multi-AZ | Read Replica | |---|---|---| | Mục đích | sẵn sàng cao | mở rộng đọc | | Sao chép | đồng bộ | không đồng bộ | | Phục vụ đọc | không (kiểu instance) | CÓ | | Chuyển đổi | tự động | thủ công (promote) | | Liên Region | không | CÓ | | Ảnh hưởng hiệu năng ghi | có (chờ standby) | rất ít |

Từ khoá nhận diện:

"synchronous, no data loss" → Multi-AZ "scale read traffic" → read replica "cross-Region DR for database" → read replica liên Region "standby serves reads" → chỉ Multi-AZ DB cluster

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Chuyển đổi 60-120 giây (kiểu instance) | | | Endpoint không đổi, chỉ DNS trỏ sang standby | | | Sao lưu chạy trên standby, không ảnh hưởng chính | |

⚠ Sao lưu trên standby là lợi ích ít người biết:

Single-AZ: snapshot gây đình trệ
  I/O trên instance chính
        ↓
    Multi-AZ: snapshot lấy từ standby
    → ứng dụng không bị ảnh hưởng

Ba lưu ý về read replica: | Lưu ý | Chi tiết | |---|---| | Tối đa 5 (RDS), 15 (Aurora) | | | Replica của replica được (MySQL, MariaDB) | | | Có thể có cấu hình khác instance chính | |

⚠ Replica cấu hình khác là mẫu hữu ích:

Instance chính: tối ưu cho ghi
        ↓
    Replica báo cáo: instance lớn
      hơn, nhiều RAM
        ↓
    Và có thêm chỉ mục riêng cho
      truy vấn báo cáo

Ba lưu ý về Aurora: | Lưu ý | Chi tiết | |---|---| | Lưu trữ chung, 6 bản trên 3 AZ | | | Replica đọc chung tầng lưu trữ, độ trễ rất thấp | | | Reader endpoint tự cân bằng | |

⚠ Aurora khác RDS ở bản chất sao chép:

RDS replica: gửi log giao dịch
  và phát lại
        ↓
    Aurora replica: đọc CÙNG tầng
      lưu trữ
    → độ trễ thường dưới 100 ms

Ba lưu ý về nguyên nhân độ trễ replica: | Nguyên nhân | Cách chữa | |---|---| | Giao dịch ghi lớn trên chính | chia nhỏ giao dịch | | Replica yếu hơn chính | nâng cỡ replica | | Bảng không có khoá chính | thêm khoá chính |

Ba lưu ý về ứng dụng: | Lưu ý | Chi tiết | |---|---| | Tách endpoint đọc và ghi | | | Đọc từ chính sau khi vừa ghi | | | Xử lý được ReplicaLag tăng đột biến | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ép chuyển đổi Multi-AZ và bấm giờ | | | Đo ReplicaLag khi tải cao | | | Thử đọc ngay sau khi ghi, xem có thấy dữ liệu không | |

Và một lời khuyên: hãy đặt cảnh báo trên ReplicaLag chứ đừng coi read replica là bản sao tức thời. Sao chép không đồng bộ nghĩa là replica luôn tụt lại một chút — và khi có một giao dịch ghi lớn, khoảng tụt đó có thể nhảy từ vài mili giây lên vài phút mà không có dấu hiệu nào khác.

Đáp án

**A — Dựng VPN CloudHub giữa các chi nhánh và trụ sở, cho phép các chi nhánh gửi và nhận dữ liệu với nhau cũng như với trụ sở.

Vì sao đúng

Đề mô tả một mô hình rất cụ thể:

Trụ sở New York: Direct Connect
        ↓
    Chi nhánh San Francisco: VPN
    Chi nhánh Miami: VPN
        ↓
    Cần: chi nhánh nói chuyện được
      VỚI NHAU và với trụ sở

⚠ Điểm mấu chốt: hai chi nhánh không nối trực tiếp với nhau:

SF ──VPN──→ AWS ←──VPN── Miami
        ↓
    Mặc định: SF và Miami KHÔNG
      thấy nhau
        ↓
    Cần một cơ chế cho lưu lượng
      đi VÀO rồi RA khỏi cùng một
      virtual private gateway

⚠ VPN CloudHub chính là cơ chế đó:

Nhiều Site-to-Site VPN cùng gắn
  vào MỘT virtual private gateway
        ↓
    Mỗi site quảng bá dải mạng của
      mình qua BGP
        ↓
    VGW học và quảng bá lại cho
      các site khác
    → mô hình nan hoa, trục là AWS

Cấu hình:

aws ec2 create-customer-gateway \
  --type ipsec.1 --public-ip 203.0.113.10 --bgp-asn 65001
aws ec2 create-customer-gateway \
  --type ipsec.1 --public-ip 198.51.100.20 --bgp-asn 65002

aws ec2 create-vpn-connection \
  --type ipsec.1 --customer-gateway-id cgw-sf \
  --vpn-gateway-id vgw-0abc123

⚠ ASN của BGP phải KHÁC NHAU giữa các site:

Hai site cùng ASN
        ↓
    BGP coi tuyến từ site kia là
      vòng lặp
    → loại bỏ
        ↓
    Mỗi site một ASN riêng

⚠ Và BGP là bắt buộc — VPN tuyến tĩnh không dùng CloudHub được:

Tuyến tĩnh: khai cứng dải mạng
        ↓
    VGW không quảng bá lại cho
      site khác
        ↓
    CloudHub cần BGP để lan truyền
      tuyến

⚠ Và vì sao phương án D (VPC peering) sai:

VPC peering nối hai VPC TRÊN AWS
        ↓
    Chi nhánh và trụ sở là mạng
      TẠI CHỖ
    → không phải VPC
        ↓
    Không peering được với mạng
      bên ngoài

⚠ Và vì sao phương án B (VPC endpoint) sai:

VPC endpoint cho phép truy cập
  DỊCH VỤ AWS riêng tư
        ↓
    S3, DynamoDB, hoặc dịch vụ qua
      PrivateLink
        ↓
    Không phải cơ chế kết nối mạng
      giữa các chi nhánh

⚠ Và vì sao phương án C (Public VIF) sai:

Public Virtual Interface của
  Direct Connect
        ↓
    Cho phép truy cập DỊCH VỤ CÔNG
      KHAI của AWS (S3, DynamoDB)
      qua đường riêng
        ↓
    Không nối các chi nhánh với nhau

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chi nhánh nói chuyện được với nhau qua AWS | | | Không cần dựng VPN chéo giữa các chi nhánh | | | Thêm chi nhánh mới chỉ cần thêm một VPN | |

⚠ Và trụ sở dùng Direct Connect vẫn tham gia được:

Direct Connect với private VIF
  gắn vào cùng VGW
        ↓
    Trụ sở cũng quảng bá dải mạng
      qua BGP
        ↓
    Chi nhánh thấy trụ sở, trụ sở
      thấy chi nhánh

⚠ Nhưng cần biết giới hạn về băng thông:

Mỗi Site-to-Site VPN tunnel:
  khoảng 1,25 Gbps
        ↓
    Lưu lượng chi nhánh này sang
      chi nhánh kia đi qua AWS
    → tốn băng thông cả hai tunnel
        ↓
    Và có phí truyền dữ liệu ra

⚠ Và Transit Gateway là cách hiện đại hơn cho mô hình này:

aws ec2 create-transit-gateway \
  --description "trung tam mang" \
  --options AmazonSideAsn=64512

aws ec2 create-vpn-connection \
  --type ipsec.1 --customer-gateway-id cgw-sf \
  --transit-gateway-id tgw-0abc123 \
  --options TunnelOptions=[]

Đề nói "chi nhánh gửi nhận dữ liệu
  với nhau"
        ↓
    CloudHub đủ cho ba site
        ↓
    Nhưng nếu mở rộng nhiều chi
      nhánh và nhiều VPC
    → Transit Gateway

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

• **C. Cấu hình Public Virtual Interface giữa các chi nhánh và trụ sở — đây là phương án gần nhất và Public VIF thật sự là một cấu hình có thật của Direct Connect, nhưng nó dùng để truy cập dịch vụ công khai của AWS qua đường riêng, không nối các mạng tại chỗ với nhau.
• **D. Dựng VPC peering giữa chi nhánh và trụ sở — peering chỉ nối hai VPC trên AWS, không nối được mạng tại chỗ.
• **B. Cấu hình VPC endpoint giữa chi nhánh và trụ sở — endpoint cho phép truy cập dịch vụ AWS riêng tư, không phải cơ chế kết nối site-to-site.

Ghi nhớ

⚠ Bốn cách kết nối tại chỗ với AWS — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Site-to-Site VPN | qua Internet, IPsec, nhanh dựng | | Direct Connect | đường riêng, băng thông ổn định | | VPN CloudHub | nhiều site nói chuyện qua VGW | | Transit Gateway | hub cho nhiều VPC và nhiều site |

Từ khoá nhận diện:

"branch offices communicate with each other" → VPN CloudHub hoặc TGW "consistent bandwidth, low latency" → Direct Connect "quick to set up, encrypted" → Site-to-Site VPN "hundreds of VPCs and sites" → Transit Gateway

Ba lưu ý về Site-to-Site VPN: | Lưu ý | Chi tiết | |---|---| | Luôn có HAI tunnel để dự phòng | | | Mỗi tunnel khoảng 1,25 Gbps | | | Cần BGP cho định tuyến động | |

⚠ Nhiều khách hàng chỉ cấu hình một tunnel:

AWS cấp hai tunnel tới hai
  endpoint khác nhau
        ↓
    Chỉ dựng một
    → AWS bảo trì tunnel đó là
      mất kết nối
        ↓
    Luôn dựng cả hai

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | Không mã hoá — cần MACsec hoặc VPN chồng lên | | | Một kết nối là điểm hỏng đơn lẻ | | | LAG gộp nhiều kết nối | |

⚠ Direct Connect + VPN dự phòng là mẫu chuẩn:

Direct Connect là chính
        ↓
    VPN qua Internet là dự phòng
        ↓
    BGP tự chuyển khi DX hỏng
    → đặt AS_PATH prepend để VPN
      kém ưu tiên hơn

Ba lưu ý về BGP: | Lưu ý | Chi tiết | |---|---| | ASN riêng cho mỗi site | | | Tuyến cụ thể hơn được ưu tiên | | | AS_PATH prepend để điều khiển ưu tiên | |

Ba lưu ý về quy hoạch IP: | Lưu ý | Chi tiết | |---|---| | Dải mạng các site KHÔNG được trùng | | | VPC CIDR cũng không trùng với tại chỗ | | | Dùng IPAM để quản lý | |

⚠ Trùng dải là lỗi không sửa được dễ dàng:

Hai chi nhánh cùng dùng
  192.168.1.0/24
        ↓
    Không định tuyến giữa chúng được
        ↓
    Phải đánh số lại một bên
    → việc rất lớn

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | TunnelState | tunnel còn sống không | | TunnelDataIn/Out | lưu lượng qua tunnel | | Route table của VGW | tuyến đã học được |

Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | VPN connection-giờ | tính theo giờ mỗi kết nối | | Truyền dữ liệu ra | tính theo GB | | Direct Connect port-giờ + truyền | truyền rẻ hơn qua Internet |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ping từ SF sang Miami | | | Kiểm route table của VGW có đủ tuyến | | | Xem TunnelState cả hai tunnel mỗi VPN | |

Và một lời khuyên: hãy dựng cả hai tunnel cho mỗi kết nối VPN. AWS cấp hai tunnel tới hai endpoint riêng biệt chính vì họ sẽ bảo trì từng cái một — và một chi nhánh chỉ cấu hình một tunnel sẽ mất kết nối trong mỗi lần bảo trì định kỳ.

Đáp án

**A và B — Cài SSM Agent trên mọi instance để quản lý việc vá, thử bản vá ở môi trường tiền sản xuất rồi triển khai như một tác vụ trong maintenance window có phê duyệt; và áp patch baseline bằng tài liệu SSM AWS-RunPatchBaseline.

Vì sao đúng

Đề nêu ba yêu cầu, và Patch Manager đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Đội máy trộn Windows và Linux | Patch Manager hỗ trợ cả hai | | Kiểm toán được | báo cáo tuân thủ vá cho từng máy | | Ít công sức nhất | dịch vụ quản lý, không tự dựng gì |

⚠ Điểm mấu chốt: tên tài liệu SSM là chi tiết quyết định: | Tài liệu | Trạng thái | |---|---| | AWS-RunPatchBaseline | HIỆN HÀNH, cả Linux và Windows | | AWS-ApplyPatchBaseline | CŨ, chỉ Windows |

`AWS-ApplyPatchBaseline` là tài
  liệu thế hệ đầu
        ↓
    Chỉ hỗ trợ Windows
        ↓
    Đề nói đội máy TRỘN Windows
      và Linux
    → phải dùng `AWS-RunPatchBaseline`

Đây là lý do phương án E sai.

Tạo patch baseline:

aws ssm create-patch-baseline \
  --name "chuan-va-linux" \
  --operating-system AMAZON_LINUX_2 \
  --approval-rules 'PatchRules=[{
    PatchFilterGroup={PatchFilters=[
      {Key=CLASSIFICATION,Values=[Security,Bugfix]},
      {Key=SEVERITY,Values=[Critical,Important]}]},
    ApproveAfterDays=7,
    ComplianceLevel=CRITICAL}]' \
  --description "Va bao mat sau 7 ngay"

⚠ ApproveAfterDays là cơ chế "phê duyệt" mà đề nhắc tới:

Bản vá phát hành
        ↓
    Chờ 7 ngày
    → nếu nhà cung cấp không thu hồi
        ↓
    Tự động được duyệt
    → cân bằng giữa an toàn và
      kịp thời

⚠ Và có thể duyệt tường minh cho môi trường sản xuất:

--approved-patches "KB5034441,CVE-2026-1234" \
--approved-patches-compliance-level CRITICAL \
--rejected-patches "KB5030219"

Maintenance window:

aws ssm create-maintenance-window \
  --name "va-hang-thang" \
  --schedule "cron(0 2 ? * SUN#2 *)" \
  --duration 4 --cutoff 1 \
  --allow-unassociated-targets

aws ssm register-task-with-maintenance-window \
  --window-id mw-0abc123 \
  --task-arn "AWS-RunPatchBaseline" \
  --task-type RUN_COMMAND \
  --targets "Key=WindowTargetIds,Values=<id-muc-tieu>" \
  --max-concurrency "10%" --max-errors "5%" \
  --task-invocation-parameters '{"RunCommand":
    {"Parameters": {"Operation": ["Install"],
                    "RebootOption": ["RebootIfNeeded"]}}}'

⚠ max-concurrency là cơ chế bảo vệ quan trọng:

Vá đồng loạt 500 máy
        ↓
    Nhiều máy khởi động lại cùng lúc
    → dịch vụ ngừng
        ↓
    `10%` → vá 50 máy một lượt
    → ALB vẫn còn máy khoẻ mạnh

⚠ Và max-errors dừng lại khi có vấn đề:

5% máy vá hỏng
        ↓
    Dừng toàn bộ chiến dịch
    → không lan ra cả đội

⚠ Và cutoff là chi tiết hay bị bỏ qua:

Duration 4 giờ, cutoff 1 giờ
        ↓
    Trong giờ cuối, không bắt đầu
      tác vụ mới
        ↓
    Tác vụ đang chạy được hoàn tất
    → không bị cắt giữa chừng

⚠ Và vì sao phương án C (OpsWorks) sai:

OpsWorks đã ngừng cả ba biến thể
  từ tháng 5/2024
        ↓
    Và tính năng "tự vá" của nó
      chỉ áp cho hệ điều hành sau
      lần cài đầu
        ↓
    Không có báo cáo tuân thủ vá
      như Patch Manager

⚠ Và vì sao phương án D sai:

D dùng "dịch vụ vá gốc của hệ
  điều hành"
        ↓
    Windows Update và yum/apt tự
      động
    → nhưng mỗi hệ một cơ chế
        ↓
    Không có nơi tập trung quản lý
      và báo cáo
    → trái với "ít công sức nhất"

Xem báo cáo tuân thủ:

aws ssm describe-instance-patch-states \
  --instance-ids i-0abc i-0def \
  --query 'InstancePatchStates[].[InstanceId,
    PatchGroup,InstalledCount,MissingCount,FailedCount,
    OperationEndTime]' --output table

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một công cụ cho cả Windows và Linux | | | Báo cáo tuân thủ sẵn cho kiểm toán | | | Vá theo lô, không làm gián đoạn dịch vụ | |

⚠ Và Patch Group là cách tách môi trường:

aws ec2 create-tags --resources i-0abc \
  --tags Key=Patch\ Group,Value=tien-san-xuat

Thẻ `Patch Group` (có dấu cách!)
        ↓
    Gắn baseline khác nhau cho
      từng nhóm
        ↓
    Tiền sản xuất vá trước, sản
      xuất vá sau
    → đúng quy trình đề yêu cầu

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

• **E. Áp patch baseline bằng tài liệu AWS-ApplyPatchBaseline — đây là phương án gần nhất và là một tài liệu SSM có thật cho việc vá, nhưng nó là thế hệ cũ và chỉ hỗ trợ Windows, trong khi đề nói rõ đội máy trộn cả Windows lẫn Linux.
• **C. Dùng OpsWorks tự vá kèm AWS Config để báo cáo — OpsWorks đã ngừng, và tính năng vá của nó không có báo cáo tuân thủ như Patch Manager.
• **D. Dùng dịch vụ vá gốc của hệ điều hành kèm AWS Config — mỗi hệ điều hành một cơ chế riêng, không quản lý tập trung được.

Ghi nhớ

⚠ Năm thành phần của Patch Manager — bảng phải thuộc: | Thành phần | Vai trò | |---|---| | Patch baseline | bản vá nào được duyệt | | Patch group | nhóm máy áp cùng baseline (thẻ Patch Group) | | Maintenance window | khi nào vá | | AWS-RunPatchBaseline | tài liệu thực thi việc vá | | Compliance report | máy nào thiếu bản vá nào |

Từ khoá nhận diện:

"patch mixed Windows and Linux fleet" → AWS-RunPatchBaseline "auditable patching" → Patch Manager compliance report "test before production" → patch group riêng cho tiền sản xuất "scan without installing" → Operation=Scan

⚠ Chế độ Scan rất hữu ích:

{"Operation": ["Scan"]}

Chỉ kiểm tra máy thiếu bản vá nào
        ↓
    Không cài, không khởi động lại
        ↓
    Chạy hằng ngày để có bức tranh
      tuân thủ liên tục

Ba lưu ý về SSM Agent: | Lưu ý | Chi tiết | |---|---| | Cài sẵn trên AMI Amazon Linux, Ubuntu, Windows | | | Cần instance profile AmazonSSMManagedInstanceCore | | | Cần tới được endpoint SSM | |

⚠ Ba VPC endpoint cho subnet riêng:

com.amazonaws.<region>.ssm
com.amazonaws.<region>.ssmmessages
com.amazonaws.<region>.ec2messages

Ba lưu ý về patch baseline: | Lưu ý | Chi tiết | |---|---| | AWS có baseline mặc định cho mỗi hệ điều hành | | | Baseline mặc định chỉ duyệt bản vá bảo mật quan trọng | | | Tự tạo baseline để kiểm soát chặt hơn | |

Ba lưu ý về khởi động lại: | Tuỳ chọn | Nghĩa | |---|---| | RebootIfNeeded | khởi động lại nếu bản vá yêu cầu | | NoReboot | cài nhưng không khởi động lại |

⚠ NoReboot để lại máy ở trạng thái nửa vời:

Bản vá đã cài nhưng chưa có hiệu lực
        ↓
    Báo cáo tuân thủ ghi
      "InstalledPendingReboot"
        ↓
    Phải có kế hoạch khởi động lại
      riêng

Ba lưu ý về hạ tầng bất biến: | Lưu ý | Chi tiết | |---|---| | Dựng AMI mới đã vá thay vì vá máy đang chạy | | | EC2 Image Builder tự động hoá | | | ASG thay máy cũ bằng máy mới | |

⚠ Đây là hướng hiện đại hơn vá tại chỗ:

Vá tại chỗ: máy dần khác nhau
        ↓
    Thay máy: mọi máy giống hệt AMI
    → không có drift
        ↓
    Nhưng cần ứng dụng không giữ
      trạng thái

Ba lưu ý về báo cáo: | Lưu ý | Chi tiết | |---|---| | describe-instance-patch-states cho trạng thái | | | Config rule kiểm tuân thủ vá | | | Xuất sang S3 cho kiểm toán viên | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy Scan xem máy nào thiếu vá | | | Vá một máy thử, kiểm ứng dụng còn chạy | | | Đọc báo cáo tuân thủ sau maintenance window | |

Và một lời khuyên: hãy đặt max-concurrency thấp cho lần vá đầu tiên trên môi trường sản xuất. Bản vá có thể làm hỏng ứng dụng theo cách không lường trước, và một chiến dịch vá 10% mỗi lượt cho bạn cơ hội dừng lại — còn 100% thì không.

Đáp án

**D — Dùng On-Demand Instance cho tầng web và tầng ứng dụng, và Reserved Instance cho tầng cơ sở dữ liệu.

Vì sao đúng

Đề cho một dữ kiện quyết định mà rất dễ đọc lướt qua:

Tầng web và tầng ứng dụng sẽ được
  THIẾT KẾ LẠI thành API Gateway
  + Lambda
        ↓
    Hoàn tất trong 6 THÁNG
        ↓
    Tầng CSDL vẫn là RDS MySQL,
      KHÔNG đổi

⚠ Điểm mấu chốt: Reserved Instance cam kết TỐI THIỂU MỘT NĂM:

Mua RI cho tầng web
        ↓
    Sáu tháng sau, tầng web biến mất
        ↓
    Vẫn phải trả tiền RI thêm sáu
      tháng nữa
    → trả cho thứ không còn tồn tại

Đây là lý do mọi phương án mua RI cho tầng web và ứng dụng đều sai.

⚠ Và tầng CSDL thì ngược lại — nó ở lại:

CSDL RDS MySQL không nằm trong
  kế hoạch thay đổi
        ↓
    Chạy liên tục, tải ổn định,
      biết trước
        ↓
    Đây là hồ sơ hoàn hảo cho
      Reserved Instance
    → giảm tới ~65%

Mua RI cho RDS:

aws rds purchase-reserved-db-instances-offering \
  --reserved-db-instances-offering-id <id-goi> \
  --reserved-db-instance-id csdl-san-xuat \
  --db-instance-count 1

⚠ Và vì sao phương án B (Spot cho web và ứng dụng) sai:

Spot Instance có thể bị THU HỒI
  với thông báo 2 phút
        ↓
    Tầng web và ứng dụng phục vụ
      khách hàng trực tiếp
        ↓
    Đề nói "đáng tin cậy nhất"
    → Spot không đáp ứng cho tải
      sản xuất nhạy cảm

⚠ Spot hợp với việc khác: | Hợp với Spot | Không hợp với Spot | |---|---| | Xử lý theo lô | web tier phục vụ khách hàng | | CI/CD build | cơ sở dữ liệu | | Kết xuất, mã hoá video | dịch vụ có trạng thái | | Huấn luyện mô hình chịu gián đoạn | tải cần SLA cao |

⚠ Và vì sao phương án A (RI cho cả ba tầng) sai:

Mua RI cho tầng web và ứng dụng
        ↓
    Sáu tháng nữa chúng bị thay
      bằng Lambda
        ↓
    Sáu tháng RI còn lại: lãng phí
      hoàn toàn

⚠ Và vì sao phương án C sai — nó đảo ngược mọi thứ:

C mua RI cho web/ứng dụng
  (sắp biến mất)
        ↓
    Và On-Demand cho CSDL
      (sẽ ở lại lâu dài)
        ↓
    Đúng ngược với cách nên làm

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | CSDL giảm giá mạnh, cam kết an toàn | | | Web và ứng dụng linh hoạt, bỏ được bất cứ lúc nào | | | Không trả tiền cho tài nguyên sắp ngừng dùng | |

⚠ Và Savings Plans là lựa chọn tốt hơn RI cho tầng tính toán:

Compute Savings Plan cam kết SỐ
  TIỀN mỗi giờ, không cam kết
  loại máy
        ↓
    Nó phủ cả EC2, Fargate VÀ LAMBDA
        ↓
    Sáu tháng sau chuyển sang Lambda
    → cam kết vẫn được dùng

aws savingsplans create-savings-plan \
  --savings-plan-offering-id <id> \
  --commitment "10.0" \
  --upfront-payment-amount "0"

⚠ Đây là điểm rất đáng nhớ — Compute Savings Plan phủ Lambda: | Loại | Phạm vi | |---|---| | EC2 Instance Savings Plan | một họ instance, một Region | | Compute Savings Plan | EC2 mọi họ, mọi Region, + Fargate + Lambda | | Standard RI | một loại instance cụ thể |

Với kế hoạch chuyển sang serverless
        ↓
    Compute Savings Plan là công cụ
      đúng nhất
    → mà nó không có trong danh
      sách phương án

⚠ Và có cách giảm chi phí khác cho giai đoạn quá độ:

Right-sizing: máy đang chạy có
  đúng cỡ không
        ↓
    Compute Optimizer phân tích
      và đề xuất
        ↓
    Thường phát hiện 20-40% máy
      quá lớn

aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[?finding==`Overprovisioned`].[
    instanceArn,currentInstanceType,
    recommendationOptions[0].instanceType]' --output table

⚠ Và tắt máy ngoài giờ cho môi trường không phải sản xuất:

Môi trường thử nghiệm chạy 24/7
        ↓
    Chỉ dùng 8 giờ mỗi ngày làm việc
        ↓
    Tắt ngoài giờ: giảm ~75%
    → và không cần cam kết gì

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

• **A. Mua Reserved Instance cho cả ba tầng — đây là phương án gần nhất và RI thật sự là cách giảm chi phí lớn nhất cho tải ổn định, nhưng cam kết tối thiểu một năm trong khi tầng web và ứng dụng sẽ bị thay thế sau sáu tháng.
• **B. Dùng Spot cho web và ứng dụng, RI cho CSDL — Spot có thể bị thu hồi bất cứ lúc nào, không phù hợp với tầng phục vụ khách hàng trực tiếp khi đề yêu cầu "đáng tin cậy nhất".
• **C. Mua RI cho web và ứng dụng, On-Demand cho CSDL — đảo ngược: cam kết cho phần sắp bỏ và trả giá cao nhất cho phần ở lại lâu dài.

Ghi nhớ

⚠ Bốn mô hình giá tính toán — bảng phải thuộc: | Mô hình | Giảm tối đa | Ràng buộc | |---|---|---| | On-Demand | 0% | không có | | Spot | ~90% | có thể bị thu hồi | | Savings Plans | ~72% | cam kết 1 hoặc 3 năm theo USD/giờ | | Reserved Instance | ~72% | cam kết 1 hoặc 3 năm theo loại máy |

Từ khoá nhận diện:

"will be replaced in N months (N < 12)" → On-Demand "steady predictable workload for years" → RI hoặc Savings Plan "fault-tolerant batch processing" → Spot "moving to serverless soon" → Compute Savings Plan

Ba lưu ý về Reserved Instance: | Lưu ý | Chi tiết | |---|---| | Cam kết tối thiểu 1 năm | | | Standard RI bán lại được trên Marketplace | | | Convertible RI đổi được sang loại khác | |

⚠ Standard RI bán lại được — lối thoát khi kế hoạch đổi:

Mua RI rồi đổi kiến trúc
        ↓
    Bán Standard RI trên Reserved
      Instance Marketplace
        ↓
    Nhưng chỉ RI trả trước một phần
      hoặc toàn bộ mới bán được
    → và không chắc bán được giá tốt

Ba lưu ý về Savings Plans: | Lưu ý | Chi tiết | |---|---| | Cam kết USD/giờ, không cam kết loại máy | | | Compute SP phủ cả Fargate và Lambda | | | KHÔNG bán lại được | |

Ba lưu ý về Spot: | Lưu ý | Chi tiết | |---|---| | Thông báo thu hồi trước 2 phút | | | Spot Fleet trộn nhiều loại máy để giảm rủi ro | | | Capacity Rebalancing chủ động thay máy sắp bị thu hồi | |

⚠ Bắt tín hiệu thu hồi để rút êm:

curl -s http://169.254.169.254/latest/meta-data/spot/instance-action

Có phản hồi → sắp bị thu hồi
        ↓
    Rút khỏi target group, hoàn
      tất việc đang làm

Ba lưu ý về tối ưu chi phí RDS: | Cách | Giảm gì | |---|---| | Reserved DB Instance | chi phí instance | | Aurora Serverless v2 | trả theo lượng dùng | | Right-sizing | không trả cho công suất thừa |

Ba lưu ý về giai đoạn quá độ: | Lưu ý | Chi tiết | |---|---| | Đừng cam kết dài cho phần sắp bỏ | | | Right-sizing có hiệu quả ngay, không ràng buộc | | | Tắt môi trường không phải sản xuất ngoài giờ | |

Ba công cụ theo dõi chi phí: | Công cụ | Việc | |---|---| | Cost Explorer | phân tích và dự báo | | Compute Optimizer | đề xuất right-sizing | | Cost Anomaly Detection | cảnh báo tăng bất thường |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem RI Utilization và Coverage | | | Kiểm đề xuất của Compute Optimizer | | | So hoá đơn trước và sau | |

Và một lời khuyên: hãy so thời hạn cam kết với vòng đời dự kiến của tài nguyên trước khi mua bất kỳ gói giảm giá nào. Reserved Instance rẻ hơn 65% nhưng chỉ khi bạn dùng hết một năm — mua cho một tầng ứng dụng sắp bị viết lại là biến khoản tiết kiệm thành khoản lãng phí.

Đáp án

**C — Dùng Route 53 latency-based routing để đưa người dùng tới Region gần nhất và bật health check; đặt website trên S3 ở mỗi Region, dùng API Gateway + Lambda cho tầng ứng dụng; và dùng DynamoDB Global Tables kèm DAX cho tầng dữ liệu.

Vì sao đúng

Đề nêu bốn yêu cầu, và kiến trúc serverless nhiều Region khớp cả bốn: | Yêu cầu | Thành phần | |---|---| | Người dùng toàn cầu, độ trễ cao | latency-based routing + nhiều Region | | Co giãn tới hàng trăm nghìn người đồng thời | Lambda và DynamoDB co giãn tự động | | Tự chuyển đổi khi hỏng | health check của Route 53 | | Chi phí thấp nhất có thể | serverless, trả theo lượt dùng |

⚠ Điểm mấu chốt: "chi phí thấp nhất" loại mọi phương án có máy chủ chạy 24/7:

A: ALB + ASG EC2 ở nhiều Region
B, D: NLB + Fargate ở nhiều Region
        ↓
    Mỗi Region phải chạy tối thiểu
      một số máy 24/7
        ↓
    Nhân với số Region
    → chi phí nền rất lớn
        ↓
    Serverless: không ai gọi thì
      gần như không tốn gì

⚠ Và latency-based routing khác geolocation routing: | Loại | Quyết định theo | |---|---| | Latency-based | độ trễ mạng ĐO ĐƯỢC | | Geolocation | vị trí ĐỊA LÝ của người dùng |

Người dùng ở Ấn Độ
        ↓
    Geolocation: gửi tới Region
      "châu Á" theo bản đồ
        ↓
    Latency-based: đo thật, có thể
      Singapore nhanh hơn Mumbai
        ↓
    Đề nói "độ trễ cao"
    → latency-based đúng hơn

Đây là lý do phương án B (geolocation) thua.

⚠ Và round-robin (phương án D) là lựa chọn tệ nhất cho độ trễ:

Chia đều lưu lượng cho mọi Region
        ↓
    Người dùng ở Việt Nam có thể bị
      gửi sang châu Âu
        ↓
    Làm độ trễ TỆ HƠN

Cấu hình latency-based routing:

aws route53 change-resource-record-sets --hosted-zone-id Z123 \
  --change-batch '{"Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "api.tro-choi.vn", "Type": "A",
      "SetIdentifier": "ap-southeast-1",
      "Region": "ap-southeast-1",
      "HealthCheckId": "hc-sg",
      "AliasTarget": {
        "HostedZoneId": "Z_APIGW_SG",
        "DNSName": "d-abc.execute-api.ap-southeast-1.amazonaws.com",
        "EvaluateTargetHealth": true}}}]}'

⚠ Và DynamoDB Global Tables là mảnh ghép then chốt:

Ghi ở bất kỳ Region nào
        ↓
    Tự sao chép sang mọi Region
      khác, thường dưới một giây
        ↓
    Đây là mô hình ACTIVE-ACTIVE
    → khác Aurora Global Database
      vốn chỉ một Region ghi được

aws dynamodb update-table --table-name nguoi-choi \
  --replica-updates '[{"Create": {"RegionName": "eu-west-1"}},
                      {"Create": {"RegionName": "us-east-1"}}]'

⚠ Đây là lý do Aurora Global Database (B, D) không bằng: | Tiêu chí | DynamoDB Global Tables | Aurora Global Database | |---|---|---| | Ghi | mọi Region | CHỈ Region chính | | Chuyển đổi | không cần, đã active-active | phải promote, ~1 phút | | Co giãn | tự động không giới hạn | theo cỡ instance | | Chi phí nền | trả theo lượt dùng | instance chạy 24/7 |

Trò chơi cần ghi từ mọi nơi
  (điểm số, trạng thái)
        ↓
    Aurora: mọi lượt ghi phải về
      Region chính
    → người chơi ở xa chịu độ trễ

⚠ Và DAX đưa độ trễ đọc xuống micro giây:

DynamoDB: mili giây một chữ số
        ↓
    DAX: micro giây cho lượt đọc
      trúng cache
        ↓
    Với trò chơi, khác biệt này
      cảm nhận được

⚠ Nhưng DAX là theo Region — mỗi Region một cụm:

DAX không sao chép liên Region
        ↓
    Mỗi Region dựng cụm DAX riêng
    → cache trước bản replica
      địa phương

⚠ Và S3 phục vụ website tĩnh gần như không tốn gì:

Trò chơi có phần tĩnh: HTML, JS,
  ảnh, âm thanh
        ↓
    S3 + CloudFront: rẻ nhất
        ↓
    Không có máy chủ web nào

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có chi phí nền khi vắng khách | | | Co giãn tới hàng trăm nghìn người tự động | | | Ghi được ở mọi Region, không cần chuyển đổi | |

⚠ Và SLA 99,99% cần tính toán cẩn thận:

99,99% = 52 phút ngừng mỗi năm
        ↓
    Một Region: SLA của từng dịch
      vụ thường 99,9-99,95%
        ↓
    Nhiều Region hoạt động song song
    → xác suất cả hai cùng hỏng
      rất nhỏ

⚠ Và health check phải kiểm tra logic ứng dụng:

aws route53 create-health-check \
  --caller-reference $(uuidgen) \
  --health-check-config '{
    "Type": "HTTPS", "ResourcePath": "/health/deep",
    "FullyQualifiedDomainName": "api-sg.tro-choi.vn",
    "RequestInterval": 10, "FailureThreshold": 2}'

`/health` trả 200 cố định
        ↓
    DynamoDB hỏng, health check
      vẫn xanh
    → Route 53 vẫn gửi người dùng
      tới Region chết

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

• **A. Route 53 failover kết hợp geolocation, ALB + ASG EC2 ở nhiều Region, RDS MySQL Multi-AZ — đây là phương án gần nhất và có đủ nhiều Region lẫn tự chuyển đổi, nhưng phải chạy đội EC2 ở mọi Region 24/7 và RDS Multi-AZ chỉ chống được lỗi trong một Region.
• **B. Geolocation routing, NLB + Fargate, Aurora Global Database — geolocation không tối ưu độ trễ thật, và Aurora chỉ ghi được ở Region chính.
• **D. Round-robin routing, NLB + Fargate, Aurora Global Database — round-robin làm độ trễ tệ hơn vì không quan tâm người dùng ở đâu.

Ghi nhớ

⚠ Bảy chính sách định tuyến của Route 53 — bảng phải thuộc: | Chính sách | Dùng khi | |---|---| | Simple | một đích duy nhất | | Weighted | chia tỷ lệ, canary | | Latency-based | độ trễ thấp nhất | | Failover | chính và dự phòng | | Geolocation | theo quốc gia, tuân thủ pháp lý | | Geoproximity | theo khoảng cách, có bias | | Multivalue answer | trả nhiều IP khoẻ mạnh |

Từ khoá nhận diện:

"lowest latency for global users" → latency-based routing "comply with data residency laws" → geolocation "active-active multi-Region writes" → DynamoDB Global Tables "lowest cost, scale to zero" → Lambda + DynamoDB "microsecond reads" → DAX

Ba lưu ý về DynamoDB Global Tables: | Lưu ý | Chi tiết | |---|---| | Xung đột giải quyết bằng "last writer wins" | | | Sao chép thường dưới một giây | | | Tính phí replicated write capacity | |

⚠ "Last writer wins" là ràng buộc phải thiết kế quanh nó:

Hai Region cùng ghi một item
        ↓
    Bản ghi sau (theo dấu thời gian)
      thắng
        ↓
    Bản kia MẤT
    → thiết kế để mỗi item chỉ có
      một Region ghi, hoặc dùng
      cấu trúc cộng dồn

Ba lưu ý về DAX: | Lưu ý | Chi tiết | |---|---| | Chỉ tương thích API DynamoDB | | | Cache item và cache truy vấn riêng | | | Ghi đi qua DAX (write-through) | |

Ba lưu ý về Lambda nhiều Region: | Lưu ý | Chi tiết | |---|---| | Triển khai bằng SAM/CDK cho từng Region | | | Provisioned concurrency chống khởi động nguội | | | Trần đồng thời tính riêng theo Region | |

Ba lưu ý về API Gateway: | Lưu ý | Chi tiết | |---|---| | Regional endpoint cho kiến trúc nhiều Region | | | Custom domain với base path mapping | | | Timeout tối đa 29 giây | |

⚠ Dùng regional endpoint, không dùng edge-optimized:

Edge-optimized đã đi qua CloudFront
        ↓
    Kết hợp với latency routing
      của Route 53
    → hai lớp định tuyến chồng nhau
        ↓
    Regional endpoint để Route 53
      quyết định

Ba lưu ý về health check: | Lưu ý | Chi tiết | |---|---| | Kiểm tra phụ thuộc quan trọng, không chỉ trả 200 | | | FailureThreshold thấp thì chuyển nhanh nhưng dễ nhầm | | | Calculated health check gộp nhiều điều kiện | |

Ba lưu ý về chi phí serverless: | Thành phần | Cách tính | |---|---| | Lambda | GB-giây + số lượt gọi | | API Gateway | theo triệu lượt gọi | | DynamoDB on-demand | theo đơn vị đọc/ghi |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ từ nhiều khu vực bằng CloudWatch Synthetics | | | Tắt một Region, xem Route 53 có chuyển không | | | Kiểm độ trễ sao chép của Global Tables | |

Và một lời khuyên: hãy cho health check kiểm tra tới cả tầng dữ liệu. Một endpoint trả về 200 cố định sẽ khiến Route 53 tiếp tục gửi người chơi tới một Region mà DynamoDB đã ngừng phản hồi — và đó chính là lúc việc tự chuyển đổi đáng lẽ phải hoạt động.

Đáp án

**C — Dùng Kinesis Data Firehose làm bộ đệm và một hàm Lambda xử lý, biến đổi sự kiện; đưa sự kiện đã biến đổi vào Amazon OpenSearch; dùng endpoint Kibana đi kèm OpenSearch để dựng bảng điều khiển gần thời gian thực.

Vì sao đúng

Đề nêu bốn yêu cầu, và kiến trúc này khớp cả bốn: | Yêu cầu | Thành phần | |---|---| | Bộ đệm tự co giãn | Firehose | | Biến đổi dữ liệu | Lambda trong Firehose | | JSON bán cấu trúc, schema động | OpenSearch | | Trực quan gần thời gian thực | Kibana / OpenSearch Dashboards |

⚠ Điểm mấu chốt: "schema động" loại mọi CSDL quan hệ:

Aurora PostgreSQL (phương án B):
  schema CỐ ĐỊNH
        ↓
    Sự kiện có trường mới
    → phải `ALTER TABLE`
        ↓
    OpenSearch: dynamic mapping
    → tự thêm trường vào mapping

⚠ Và OpenSearch lưu JSON nguyên bản:

PUT su-kien-2026.09.01/_doc/1
{"thoi_diem": "2026-09-01T10:00:00Z",
 "muc_do": "canh-bao",
 "chi_tiet": {"ma_may": "M-42", "nhiet_do": 78.5},
 "the": ["san-xuat", "khan-cap"]}

Cấu trúc lồng nhau, mảng, trường
  tuỳ ý
        ↓
    Không cần khai trước
    → chỉ số hoá và tìm kiếm ngay

⚠ Và vì sao Firehose chứ không phải Kinesis Data Streams (phương án A): | Tiêu chí | Firehose | Data Streams | |---|---|---| | Quản shard | KHÔNG có | phải cấp hoặc on-demand | | Ghi vào OpenSearch | tích hợp sẵn | phải tự viết consumer | | Biến đổi bằng Lambda | tích hợp sẵn | tự viết | | Co giãn | hoàn toàn tự động | on-demand thì có |

Đề nói "tự động đệm và biến đổi
  theo cách co giãn được"
        ↓
    Firehose làm cả hai mà không
      cần cấu hình gì

⚠ Và phương án A còn sai ở chỗ dùng Athena để trực quan hoá:

A nói dùng "AWS Athena để tạo
  trực quan thời gian thực"
        ↓
    Athena là công cụ TRUY VẤN SQL
    → không phải công cụ vẽ bảng
      điều khiển
        ↓
    Và nó truy vấn dữ liệu trên S3,
      không phải luồng thời gian thực

⚠ Và vì sao phương án D sai hoàn toàn:

D nói "Amazon Aurora Neptune"
        ↓
    Không có dịch vụ tên đó
    → Aurora và Neptune là hai
      dịch vụ riêng
        ↓
    Neptune là CSDL ĐỒ THỊ
    → cho quan hệ giữa thực thể,
      không phải sự kiện chuỗi
      thời gian

Cấu hình luồng phân phối:

aws firehose create-delivery-stream \
  --delivery-stream-name su-kien-giam-sat \
  --amazonopensearchservice-destination-configuration '{
    "RoleARN": "arn:aws:iam::111122223333:role/Firehose",
    "DomainARN": "<arn-domain>",
    "IndexName": "su-kien",
    "IndexRotationPeriod": "OneDay",
    "BufferingHints": {"IntervalInSeconds": 60, "SizeInMBs": 5},
    "RetryOptions": {"DurationInSeconds": 300},
    "S3BackupMode": "FailedDocumentsOnly",
    "ProcessingConfiguration": {"Enabled": true,
      "Processors": [{"Type": "Lambda",
        "Parameters": [{"ParameterName": "LambdaArn",
                        "ParameterValue": "<arn-lambda>"}]}]}}'

Hàm biến đổi:

import base64, json

def xu_ly(event, context):
    ket_qua = []
    for r in event['records']:
        dl = json.loads(base64.b64decode(r['data']))
        dl['@timestamp'] = dl.pop('ts')
        dl['moi_truong'] = dl.get('env', 'khong-ro')
        ket_qua.append({
            'recordId': r['recordId'], 'result': 'Ok',
            'data': base64.b64encode(
                json.dumps(dl).encode()).decode()})
    return {'records': ket_qua}

⚠ Trường @timestamp là quy ước của Kibana:

Kibana cần một trường thời gian
  để vẽ biểu đồ theo thời gian
        ↓
    Quy ước là `@timestamp`
        ↓
    Đặt tên khác vẫn dùng được
    → nhưng phải khai thủ công khi
      tạo index pattern

⚠ Và S3BackupMode là lưới an toàn: | Chế độ | Ghi gì vào S3 | |---|---| | FailedDocumentsOnly | chỉ tài liệu OpenSearch từ chối | | AllDocuments | mọi tài liệu |

OpenSearch từ chối vì mapping
  xung đột
        ↓
    Không có backup → MẤT
        ↓
    Có → sửa mapping rồi nạp lại

⚠ Và xung đột mapping là vấn đề thật của dynamic mapping:

Tài liệu đầu: {"gia_tri": 42}
    → OpenSearch đoán kiểu `long`
        ↓
    Tài liệu sau: {"gia_tri": "cao"}
    → xung đột, bị từ chối
        ↓
    Dùng index template khai kiểu
      trước cho trường quan trọng

PUT _index_template/su-kien
{"index_patterns": ["su-kien-*"],
 "template": {"mappings": {"properties": {
   "@timestamp": {"type": "date"},
   "gia_tri": {"type": "float"},
   "muc_do": {"type": "keyword"}}}}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có shard hay máy chủ nào phải quản | | | Schema tự thích ứng | | | Bảng điều khiển đi kèm domain | |

⚠ Và kết nối từ tại chỗ đã có sẵn theo đề:

Đề nói đã thiết lập kết nối giữa
  tại chỗ và AWS
        ↓
    Kinesis Agent trên máy chủ nguồn
    → hoặc gọi `PutRecordBatch`
      từ ứng dụng

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

⚠ Câu này gần như trùng với một câu khác trong cùng lô (mã #10599): cũng PostgreSQL tại chỗ, cũng cần bộ đệm tự co giãn, cũng JSON schema động, cũng cần bảng điều khiển gần thời gian thực, và đáp án cũng là Firehose + Lambda + OpenSearch.

Khác biệt duy nhất: câu kia hỏi chọn hai phương án rời, câu này hỏi chọn một phương án gộp cả kiến trúc.

Và đề gọi công cụ trực quan là "Kibana" — từ tháng 9/2021, Amazon Elasticsearch Service đổi tên thành Amazon OpenSearch Service, và Kibana thành OpenSearch Dashboards. Đề dùng lẫn cả hai tên trong cùng một phương án.

⚠ Và "thời gian thực" cần đọc kỹ:

Firehose có phép đệm tối thiểu
  60 giây cho đích OpenSearch
        ↓
    "Gần thời gian thực" — đúng
        ↓
    "Thời gian thực" (dưới một giây)
    → phải đọc thẳng từ Kinesis
      Data Streams

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

• **A. Dùng Kinesis Data Stream đệm sự kiện, Lambda xử lý, và Athena để tạo trực quan — đây là phương án gần nhất và Kinesis Data Streams thật sự là bộ đệm co giãn được, nhưng Athena là công cụ truy vấn SQL trên S3 chứ không phải công cụ dựng bảng điều khiển thời gian thực.
• **B. Firehose + Lambda, đưa vào Aurora PostgreSQL rồi dùng QuickSight — schema cố định, không hợp với JSON có schema động; và đó chính là vấn đề công ty đang muốn thoát khỏi.
• **D. Firehose + Lambda, đưa vào "Aurora Neptune" rồi dùng QuickSight — không có dịch vụ tên đó; Neptune là CSDL đồ thị, không hợp với sự kiện chuỗi thời gian.

Ghi nhớ

⚠ Bốn dịch vụ CSDL chuyên biệt của AWS — bảng phải thuộc: | Dịch vụ | Mô hình dữ liệu | |---|---| | DynamoDB | khoá-giá trị, tài liệu | | Neptune | đồ thị | | Timestream | chuỗi thời gian | | OpenSearch | tài liệu, tìm kiếm toàn văn |

Từ khoá nhận diện:

"dynamic schema, semi-structured JSON" → OpenSearch hoặc DynamoDB "near real-time dashboards on events" → OpenSearch Dashboards "auto-scaling buffer, least ops" → Firehose "relationships between entities" → Neptune "time-series metrics at scale" → Timestream

Ba lưu ý về OpenSearch Service: | Lưu ý | Chi tiết | |---|---| | Dedicated master node cho sản xuất | | | Ba AZ cho sẵn sàng cao | | | UltraWarm và Cold Storage cho dữ liệu cũ | |

⚠ OpenSearch Serverless là lựa chọn mới:

Không quản node, không quản shard
        ↓
    Trả theo OCU (OpenSearch
      Compute Unit)
        ↓
    Hợp khi tải biến động mạnh
    → nhưng có mức tối thiểu

Ba lưu ý về Index State Management: | Lưu ý | Chi tiết | |---|---| | Tự chuyển chỉ mục sang UltraWarm | | | Tự xoá chỉ mục quá hạn | | | Khai bằng chính sách JSON | |

{"policy": {"states": [
  {"name": "nong", "transitions": [
    {"state_name": "am", "conditions": {"min_index_age": "7d"}}]},
  {"name": "am", "actions": [{"warm_migration": {}}],
   "transitions": [{"state_name": "xoa",
     "conditions": {"min_index_age": "90d"}}]},
  {"name": "xoa", "actions": [{"delete": {}}]}]}}

Ba lưu ý về Firehose: | Lưu ý | Chi tiết | |---|---| | Không lưu giữ dữ liệu — mất là mất | | | Thử lại tối đa theo RetryOptions | | | Luôn bật backup S3 | |

Ba lưu ý về hàm biến đổi: | Lưu ý | Chi tiết | |---|---| | Trả đủ mọi recordId | | | Ba giá trị: Ok, Dropped, ProcessingFailed | | | Giới hạn 6 MB mỗi lô | |

Ba lưu ý về Kibana/Dashboards: | Lưu ý | Chi tiết | |---|---| | Cần index pattern trỏ tới chỉ mục | | | Trường thời gian phải là kiểu date | | | Xác thực qua Cognito hoặc SAML | |

⚠ Truy cập Dashboards khi domain trong VPC:

Domain trong VPC: Dashboards không
  ra Internet
        ↓
    Truy cập qua VPN, bastion, hoặc
      proxy ngược
        ↓
    Hoặc dùng Cognito với domain
      công khai có chính sách truy cập

Ba lưu ý về chi phí: | Thành phần | Cách tính | |---|---| | OpenSearch | theo instance-giờ + dung lượng EBS | | Firehose | theo GB nạp | | Lambda biến đổi | GB-giây |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi một sự kiện, đo tới lúc thấy trên bảng | | | Kiểm DeliveryToAmazonOpenSearch.Success | | | Xem thư mục lỗi trong bucket backup | |

Và một lời khuyên: hãy khai index template cho các trường quan trọng thay vì phó mặc cho dynamic mapping. Schema động rất tiện cho đến khi một sự kiện gửi chuỗi vào trường mà OpenSearch đã đoán là số — lúc đó mọi tài liệu tương tự bị từ chối im lặng và chỉ backup S3 giữ lại chúng cho bạn.

Đáp án

**A và C — Dựng một VPC peering giữa hai VPC, và thêm tuyến vào bảng định tuyến của VPC X trỏ tới dải 172.30.0.0/16, đồng thời thêm tuyến vào bảng định tuyến của VPC Y trỏ tới dải 172.20.0.0/16.

Vì sao đúng

Đề mô tả đúng triệu chứng của hai VPC không có đường đi giữa chúng:

Ứng dụng ở VPC X (172.20.0.0/16)
        ↓
    CSDL ở VPC Y (172.30.0.0/16)
        ↓
    Lỗi "connection timeout"
    → không phải "connection refused"
        ↓
    Timeout = gói tin không tới nơi
    → vấn đề định tuyến hoặc tường lửa

⚠ Phân biệt hai loại lỗi kết nối là kỹ năng chẩn đoán quan trọng: | Lỗi | Nghĩa | |---|---| | Connection refused | gói tin TỚI NƠI, nhưng không có dịch vụ nghe | | Connection timeout | gói tin KHÔNG tới nơi, hoặc phản hồi không về |

⚠ Và hai CIDR không chồng nhau — điều kiện bắt buộc để peering:

172.20.0.0/16 và 172.30.0.0/16
        ↓
    Không giao nhau
    → peering được
        ↓
    Nếu trùng: KHÔNG peering được,
      phải đánh số lại

Tạo peering:

aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-X --peer-vpc-id vpc-Y

aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id pcx-0abc123

Thêm tuyến ở CẢ HAI bên:

aws ec2 create-route --route-table-id rtb-X \
  --destination-cidr-block 172.30.0.0/16 \
  --vpc-peering-connection-id pcx-0abc123

aws ec2 create-route --route-table-id rtb-Y \
  --destination-cidr-block 172.20.0.0/16 \
  --vpc-peering-connection-id pcx-0abc123

⚠ Chỉ thêm tuyến một bên là lỗi kinh điển:

Chỉ thêm ở VPC X
        ↓
    Gói tin đi sang được Y
        ↓
    Nhưng Y không biết đường về X
    → phản hồi rơi vào default route
        ↓
    Triệu chứng: TIMEOUT
    → đúng như đề mô tả

⚠ Đây là lý do cả A và C đều cần, không chọn một:

Định tuyến IP là hai chiều
        ↓
    Mỗi bên phải biết đường tới
      bên kia
        ↓
    Đề hỏi chọn HAI phương án
    → chính là hai chiều này

⚠ Và security group cũng phải mở — đề không hỏi nhưng phải nhớ:

aws ec2 authorize-security-group-ingress \
  --group-id sg-mysql-o-Y \
  --protocol tcp --port 3306 \
  --cidr 172.20.0.0/24

Tham chiếu security group liên VPC
  chỉ dùng được KHI ĐÃ peering
        ↓
    Và phải cùng Region
        ↓
    Liên Region: chỉ dùng CIDR được

⚠ Và vì sao ba phương án còn lại sai — chúng đều đi vòng qua Internet:

B: virtual private gateway +
  customer gateway + Elastic IP
        ↓
D: NAT gateway + Elastic IP
        ↓
E: internet gateway + Elastic IP
        ↓
    Cả ba đưa lưu lượng CSDL ra
      Internet công cộng
    → đề nói "AN TOÀN"

⚠ Và ba phương án đó còn sai về mặt kỹ thuật: | Phương án | Vấn đề | |---|---| | B | VGW + CGW là để nối tại chỗ, không nối hai VPC | | D | NAT gateway chỉ cho lưu lượng ĐI RA, không nhận vào | | E | phơi CSDL MySQL ra Internet |

Và cả ba đều bắt đổi IP đã cài
  cứng trong ứng dụng
        ↓
    Đề nói "ít bảo trì và ít việc
      nhất"
    → peering không đụng tới ứng dụng

⚠ Và IP cài cứng là chi tiết quan trọng trong đề:

IP của CSDL cài cứng trong ứng dụng
        ↓
    Peering: IP riêng không đổi
    → ứng dụng chạy được ngay
        ↓
    Elastic IP: phải sửa mã và
      triển khai lại 20 instance

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lưu lượng đi trên mạng riêng AWS | | | Không phải sửa ứng dụng | | | Không tốn phí NAT hay Internet gateway | |

⚠ Nhưng peering có ba hạn chế phải nhớ:

1. KHÔNG bắc cầu
   A↔B, B↔C không cho A↔C
        ↓
2. CIDR không được chồng nhau
        ↓
3. Số kết nối tăng theo bình phương
   số VPC

⚠ Và khi có nhiều hơn vài VPC thì dùng Transit Gateway:

3 VPC → 3 kết nối peering
        ↓
    10 VPC → 45 kết nối
        ↓
    Transit Gateway: 10 attachment
    → và bắc cầu được

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

• **D. Tạo NAT gateway cho cả hai VPC, gán Elastic IP cho instance MySQL và cập nhật ứng dụng trỏ tới IP đó — đây là phương án gần nhất và thật sự tạo được đường đi, nhưng NAT gateway chỉ dành cho lưu lượng đi ra; và giải pháp này đưa lưu lượng CSDL qua Internet, đồng thời bắt sửa IP đã cài cứng.
• **E. Tạo internet gateway cho cả hai VPC và gán Elastic IP cho CSDL — phơi MySQL ra Internet công cộng, vi phạm yêu cầu an toàn.
• **B. Tạo virtual private gateway và tuyến mặc định tới customer gateway — VGW/CGW dùng để nối mạng tại chỗ với AWS, không nối hai VPC.

Ghi nhớ

⚠ Bốn cách nối hai VPC — bảng phải thuộc: | Cách | Bắc cầu | Trùng CIDR | |---|---|---| | VPC peering | KHÔNG | không được | | Transit Gateway | CÓ | không được | | PrivateLink | không áp dụng | ĐƯỢC | | VPN giữa hai VPC | có (qua BGP) | không được |

Từ khoá nhận diện:

"connection timeout between VPCs" → thiếu tuyến hoặc peering "connection refused" → dịch vụ không chạy, hoặc sai cổng "overlapping CIDR" → PrivateLink "many VPCs, transitive" → Transit Gateway

Ba lưu ý về VPC peering: | Lưu ý | Chi tiết | |---|---| | Phải sửa bảng định tuyến ở CẢ HAI bên | | | Không bắc cầu | | | Liên Region được, nhưng không tham chiếu SG được | |

⚠ Tham chiếu security group liên VPC chỉ trong cùng Region:

--source-group sg-app-o-X --group-owner 111122223333

Cùng Region: tham chiếu SG được
        ↓
    Khác Region: chỉ dùng CIDR

Ba lưu ý về bảng định tuyến: | Lưu ý | Chi tiết | |---|---| | Mỗi subnet gắn với một bảng định tuyến | | | Sửa bảng của subnet chứa tài nguyên | | | Tuyến cụ thể hơn được ưu tiên | |

⚠ Sửa nhầm bảng định tuyến là lỗi hay gặp:

VPC có nhiều bảng định tuyến
        ↓
    Thêm tuyến vào bảng mặc định
    → nhưng subnet của ứng dụng
      dùng bảng khác
        ↓
    Kiểm `describe-route-tables` xem
      subnet nào gắn bảng nào

Ba lưu ý về chẩn đoán: | Công cụ | Việc | |---|---| | Reachability Analyzer | chỉ ra chính xác chỗ chặn | | VPC Flow Log | xem ACCEPT hay REJECT | | describe-route-tables | kiểm tuyến thật |

⚠ Reachability Analyzer là công cụ nên dùng đầu tiên:

aws ec2 create-network-insights-path \
  --source i-ung-dung --destination i-mysql \
  --protocol tcp --destination-port 3306
aws ec2 start-network-insights-analysis \
  --network-insights-path-id nip-0abc

Kết quả nói rõ: thiếu route, hay
  security group chặn, hay NACL chặn

Ba lưu ý về Transit Gateway: | Lưu ý | Chi tiết | |---|---| | Bắc cầu được giữa mọi attachment | | | Nhiều bảng định tuyến để phân đoạn | | | Tính phí theo attachment và GB xử lý | |

Ba lưu ý về chi phí: | Cách | Chi phí | |---|---| | VPC peering | chỉ phí truyền dữ liệu liên AZ/Region | | Transit Gateway | phí attachment + phí xử lý GB | | NAT gateway | phí giờ + phí xử lý GB |

⚠ Peering rẻ hơn Transit Gateway cho ít VPC:

Hai VPC: peering không tốn phí
  cố định
        ↓
    Transit Gateway: hai attachment
      × phí giờ
        ↓
    Nhưng từ khoảng 5-6 VPC trở lên,
      TGW rẻ hơn về công vận hành

Ba lưu ý về quy hoạch IP: | Lưu ý | Chi tiết | |---|---| | Lên kế hoạch CIDR trước khi tạo VPC | | | Không dùng dải trùng với tại chỗ | | | Dùng IPAM để theo dõi | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | telnet 172.30.x.x 3306 từ instance ứng dụng | | | Kiểm tuyến ở cả hai bảng định tuyến | | | Chạy Reachability Analyzer | |

Và một lời khuyên: hãy kiểm tuyến ở cả hai bảng định tuyến khi gặp lỗi timeout giữa hai VPC. Gói tin đi được một chiều mà không về được là triệu chứng giống hệt việc chưa peering gì cả — và nguyên nhân thường chỉ là một dòng route bị quên ở phía bên kia.

Đáp án

**D — Tạo một Read Replica trong CÙNG Region với instance chính và trỏ khối lượng phân tích sang đó.

Vì sao đúng

Đề mô tả một mẫu rất phổ biến:

Một CSDL phục vụ hai loại tải:
    - SaaS: giao dịch nhỏ, nhiều
    - Phân tích: truy vấn nặng, ít
        ↓
    Truy vấn phân tích chiếm CPU
      và I/O
    → làm chậm giao dịch của khách

⚠ Điểm mấu chốt: tách hai loại tải ra hai instance:

Read replica nhận toàn bộ truy vấn
  phân tích
        ↓
    Instance chính chỉ phục vụ SaaS
        ↓
    Truy vấn nặng chạy trên máy khác
    → không tranh tài nguyên

Tạo replica:

aws rds create-db-instance-read-replica \
  --db-instance-identifier replica-phan-tich \
  --source-db-instance-identifier csdl-chinh \
  --db-instance-class db.r6g.2xlarge \
  --availability-zone ap-southeast-1b

⚠ Và "cùng Region" là chi tiết về chi phí — đây là điểm phân biệt với phương án A: | Vị trí replica | Phí truyền dữ liệu sao chép | |---|---| | Cùng AZ | miễn phí | | Khác AZ, cùng Region | phí liên AZ | | Khác Region | phí liên Region, đắt hơn nhiều |

Đề nói "tối ưu chi phí nhất"
        ↓
    Replica liên Region trả phí
      truyền cho MỌI thay đổi
    → liên tục, suốt ngày đêm

⚠ Và phương án A còn sai về mặt logic:

A nói tạo replica ở Region khác
  "làm CSDL Master"
        ↓
    Read replica KHÔNG phải master
    → nó chỉ đọc
        ↓
    Và trộn mục đích khôi phục thảm
      hoạ với mục đích giảm tải
    → đề chỉ hỏi việc thứ hai

⚠ Và vì sao phương án C sai — standby không đọc được:

C nói bật Multi-AZ và chạy phân
  tích trên STANDBY
        ↓
    Standby của Multi-AZ kiểu
      instance HOÀN TOÀN THỤ ĐỘNG
        ↓
    Không kết nối tới được
    → không có endpoint riêng

⚠ Đây là nhầm lẫn phổ biến nhất về Multi-AZ: | Cấu hình | Standby/replica đọc được | |---|---| | Multi-AZ instance | KHÔNG | | Multi-AZ DB cluster | CÓ (2 reader) | | Read replica | CÓ | | Aurora replica | CÓ |

⚠ Và vì sao phương án B không giải quyết vấn đề:

B chuyển ứng dụng phân tích sang
  Lambda
        ↓
    Đổi nơi CHẠY MÃ
    → nhưng truy vấn vẫn tới cùng
      một CSDL
        ↓
    Tải trên CSDL không đổi
    → vấn đề nguyên vẹn

⚠ Và tách endpoint là việc phải làm ở ứng dụng:

ket_noi_ghi = ket_noi(
    'csdl-chinh.abc.ap-southeast-1.rds.amazonaws.com')
ket_noi_doc = ket_noi(
    'replica-phan-tich.abc.ap-southeast-1.rds.amazonaws.com')

Tạo replica xong không tự có tác
  dụng
        ↓
    Ứng dụng phân tích phải chủ
      động trỏ sang endpoint mới

⚠ Và replica có thể cấu hình khác instance chính:

Instance chính: tối ưu cho nhiều
  giao dịch nhỏ
        ↓
    Replica phân tích: nhiều RAM,
      nhiều CPU
        ↓
    Và thêm chỉ mục riêng phục vụ
      truy vấn báo cáo
    → chỉ mục đó không làm chậm
      việc ghi ở chính

⚠ Nhưng thêm chỉ mục trên replica cần cẩn thận:

MySQL read replica: chỉ mục thêm
  trên replica tồn tại được
        ↓
    Nhưng nếu promote hoặc tạo lại
      replica
    → chỉ mục mất
        ↓
    Ghi lại quy trình để dựng lại

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hai loại tải không tranh tài nguyên | | | Không phải nâng cỡ instance chính | | | Xoá replica được khi không cần | |

⚠ Và độ trễ sao chép phải chấp nhận được:

Đề nói báo cáo "gần thời gian thực"
        ↓
    Replica trễ vài giây
    → thường chấp nhận được cho
      báo cáo quản trị
        ↓
    Cần chính xác tuyệt đối
    → phải chạy trên chính

⚠ Và Aurora làm việc này tốt hơn RDS: | Tiêu chí | RDS replica | Aurora replica | |---|---|---| | Độ trễ sao chép | giây | thường dưới 100 ms | | Endpoint | riêng từng replica | reader endpoint tự cân bằng | | Số lượng | 5 | 15 | | Auto scaling | không | CÓ |

aws application-autoscaling register-scalable-target \
  --service-namespace rds \
  --resource-id cluster:cum-aurora \
  --scalable-dimension rds:cluster:ReadReplicaCount \
  --min-capacity 1 --max-capacity 5

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

• **A. Tạo Read Replica ở Region khác làm CSDL master và trỏ phân tích sang đó — đây là phương án gần nhất và thật sự tách được tải, nhưng phí truyền dữ liệu liên Region tính cho mọi thay đổi, đắt hơn hẳn; và replica không phải master.
• **C. Bật Multi-AZ và chạy phân tích trên standby — standby của Multi-AZ kiểu instance không có endpoint và không phục vụ truy vấn.
• **B. Chuyển ứng dụng phân tích sang Lambda — đổi nơi chạy mã nhưng truy vấn vẫn đổ vào cùng một CSDL.

Ghi nhớ

⚠ Bốn cách giảm tải cho CSDL — bảng phải thuộc: | Cách | Giảm gì | |---|---| | Read replica | chia tải đọc ra nhiều máy | | ElastiCache | loại bỏ truy vấn lặp lại | | Nâng cỡ instance | mỗi máy làm nhiều hơn | | Chuyển phân tích sang Redshift | tách hẳn hệ thống |

Từ khoá nhận diện:

"analytics slows down the app" → read replica "repeated identical queries" → ElastiCache "complex analytical queries at scale" → Redshift "standby serves reads" → SAI với Multi-AZ instance

⚠ Và khi phân tích trở nên quá nặng thì chuyển sang Redshift:

Truy vấn quét hàng trăm triệu dòng
        ↓
    CSDL quan hệ theo dòng không hợp
        ↓
    Redshift lưu theo cột, nén, xử
      lý song song
    → nhanh hơn hàng chục lần
        ↓
    Dùng DMS hoặc zero-ETL để đưa
      dữ liệu sang

⚠ Zero-ETL integration là tính năng mới đáng biết:

aws rds create-integration \
  --integration-name aurora-sang-redshift \
  --source-arn <arn-cum-aurora> \
  --target-arn <arn-redshift>

Dữ liệu Aurora tự chảy sang Redshift
  gần thời gian thực
        ↓
    Không phải dựng đường ống ETL

Ba lưu ý về read replica: | Lưu ý | Chi tiết | |---|---| | Tối đa 5 (RDS), 15 (Aurora) | | | Sao chép không đồng bộ | | | Promote là thao tác một chiều | |

Ba lưu ý về độ trễ sao chép: | Nguyên nhân | Cách chữa | |---|---| | Giao dịch ghi lớn | chia nhỏ | | Replica yếu hơn chính | nâng cỡ replica | | Bảng không có khoá chính | thêm khoá chính |

⚠ MySQL replica áp dụng thay đổi theo một luồng (mặc định):

Instance chính ghi song song
        ↓
    Replica phát lại tuần tự
    → dễ tụt lại khi tải ghi cao
        ↓
    Bật parallel replication để
      cải thiện

Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Replica tính tiền như instance đầy đủ | | | Phí truyền liên AZ và liên Region | | | Xoá replica khi không dùng | |

Ba lưu ý về RDS Proxy: | Lưu ý | Chi tiết | |---|---| | Gộp kết nối, giảm tải CSDL | | | Có read-only endpoint cho replica | | | Giữ kết nối khi chuyển đổi | |

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | ReplicaLag | replica tụt lại bao xa | | CPUUtilization | so giữa chính và replica | | DatabaseConnections | có chạm trần không |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So CPU của instance chính trước và sau | | | Đo ReplicaLag khi báo cáo chạy | | | Kiểm ứng dụng phân tích thật sự dùng endpoint mới | |

Và một lời khuyên: hãy kiểm tra ứng dụng phân tích có thật sự kết nối vào replica hay không sau khi tạo. Read replica không tự nhận lưu lượng — nếu chuỗi kết nối chưa được đổi thì bạn đang trả tiền cho một instance thứ hai mà tải trên instance chính vẫn y nguyên.

Đáp án

**D — Chuyển dữ liệu vào nhiều thiết bị Snowball Edge Storage Optimized, chép dữ liệu từ Snowball Edge vào Amazon S3, rồi đặt luật vòng đời chuyển sang Glacier.

Vì sao đúng

Đề có hai điểm quyết định, và cả hai đều nằm ở chi tiết kỹ thuật.

⚠ Điểm thứ nhất: Snow Family CHỈ nạp vào S3, không nạp thẳng vào Glacier:

Job kiểu IMPORT của Snowball
        ↓
    Đích duy nhất là một BUCKET S3
        ↓
    Muốn dữ liệu vào Glacier
    → nạp vào S3 rồi đặt luật
      vòng đời

Đây là lý do phương án A và B sai — cả hai nói "chép thẳng vào Glacier".

Luật vòng đời:

{"Rules": [{
  "ID": "chuyen-sang-deep-archive",
  "Filter": {},
  "Status": "Enabled",
  "Transitions": [{"Days": 0,
                   "StorageClass": "DEEP_ARCHIVE"}]}]}

⚠ Hoặc chỉ định lớp lưu trữ ngay khi tạo job Snowball:

aws snowball create-job --job-type IMPORT \
  --resources '{"S3Resources": [{
    "BucketArn": "arn:aws:s3:::kho-luu-tru"}]}' \
  --snowball-type EDGE_S3_OPTIMIZED

Object vào S3 Standard trước
        ↓
    Luật vòng đời với `Days: 0`
      chuyển ngay
        ↓
    Vẫn phải qua S3 — không có
      đường tắt

⚠ Điểm thứ hai: Snowmobile đã ngừng dịch vụ (2024):

Snowmobile: xe container chở
  100 PB
        ↓
    AWS đã ngừng nhận đơn
        ↓
    9 PB hiện nay dùng nhiều
      Snowball Edge

Đây là lý do phương án C sai ngoài chuyện đường đi.

⚠ Và ngay cả khi Snowmobile còn, 9 PB vẫn ở vùng ranh giới:

AWS khuyến nghị Snowmobile từ
  10 PB trở lên
        ↓
    9 PB nằm dưới ngưỡng đó
        ↓
    Và Snowmobile đòi hỏi hạ tầng
      tại chỗ rất lớn: nguồn điện,
      chỗ đỗ xe, đường cáp

⚠ Tính số thiết bị cần:

Snowball Edge Storage Optimized:
  80 TB dùng được (bản cũ)
  hoặc 210 TB (bản mới)
        ↓
    9 PB = 9.000 TB
        ↓
    Bản 80 TB: cần khoảng 113 thiết bị
    Bản 210 TB: cần khoảng 43 thiết bị

⚠ Và AWS hỗ trợ đặt cả cụm cho quy mô này:

aws snowball create-cluster \
  --job-type IMPORT \
  --snowball-type EDGE_S3_OPTIMIZED \
  --resources '{"S3Resources": [{"BucketArn": "<arn-kho>"}]}' \
  --address-id <ma-dia-chi> \
  --role-arn <arn-role> \
  --shipping-option EXPEDITED

⚠ Và với quy mô này, phải chạy nhiều thiết bị SONG SONG:

Chép tuần tự từng thiết bị
        ↓
    113 thiết bị × vài ngày mỗi cái
    → hàng năm
        ↓
    Chạy 10-20 thiết bị cùng lúc
    → vài tháng
        ↓
    Nút thắt thật là tốc độ đọc
      của hệ thống lưu trữ nguồn

⚠ Và chọn lớp Glacier nào cho 9 PB: | Lớp | Giá xấp xỉ | Chi phí 9 PB/tháng | |---|---|---| | S3 Standard | 0,023 USD/GB | ~207.000 USD | | Glacier Flexible | 0,0036 USD/GB | ~32.400 USD | | Glacier Deep Archive | 0,00099 USD/GB | ~8.900 USD |

Đề nói "lưu trữ dài hạn bền vững"
  và "tối ưu chi phí nhất"
        ↓
    Deep Archive rẻ hơn Standard
      23 lần

⚠ Nhưng phí chuyển tầng theo số object là điều phải tính:

Chuyển sang Deep Archive: khoảng
  0,05 USD cho 1.000 object
        ↓
    100 triệu object → 5.000 USD
      một lần
        ↓
    Vẫn đáng, nhưng phải biết trước

⚠ Và tệp nhỏ tính tối thiểu 40 KB trong Deep Archive:

Kho lưu trữ có nhiều tệp nhỏ
        ↓
    Gom lại thành tar trước khi
      chép vào Snowball
        ↓
    Giảm cả số object lẫn phí
      chuyển tầng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không chiếm băng thông Internet | | | Chi phí lưu trữ thấp nhất có thể | | | Nhiều thiết bị chạy song song | |

⚠ Và nhập dữ liệu vào AWS là MIỄN PHÍ:

Chỉ trả phí thiết bị và vận chuyển
        ↓
    Không có phí truyền dữ liệu vào
        ↓
    Ngược lại, LẤY RA khỏi Glacier
      thì tốn cả phí lấy ra lẫn
      phí truyền

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

• **A. Chuyển vào nhiều Snowball Edge Storage Optimized rồi chép thẳng vào Glacier — đây là phương án gần nhất và chọn đúng thiết bị cho quy mô này, nhưng job nhập của Snowball chỉ nạp vào bucket S3; không có đường đi thẳng vào Glacier.
• **C. Chuyển vào Snowmobile rồi vào S3 và đặt luật vòng đời — Snowmobile đã ngừng dịch vụ, và 9 PB nằm dưới ngưỡng AWS từng khuyến nghị dùng nó.
• **B. Chuyển vào Snowmobile rồi chép thẳng vào Glacier — sai cả hai điểm.

Ghi nhớ

⚠ Bốn thiết bị của Snow Family — bảng phải thuộc: | Thiết bị | Dung lượng | Trạng thái | |---|---|---| | Snowcone | 8-14 TB | hiện hành | | Snowball Edge Storage Optimized | 80 TB / 210 TB | hiện hành | | Snowball Edge Compute Optimized | 28 TB + tính toán | hiện hành | | Snowmobile | 100 PB | NGỪNG (2024) |

Từ khoá nhận diện:

"petabytes, offline transfer" → nhiều Snowball Edge "long-term archive, cheapest" → Glacier Deep Archive "Snowball loads directly into Glacier" → SAI, chỉ vào S3 "edge compute in disconnected site" → Snowball Edge Compute Optimized

Ba lưu ý về job Snowball: | Lưu ý | Chi tiết | |---|---| | Kiểu IMPORT nạp vào S3 | | | Kiểu EXPORT lấy dữ liệu ra khỏi S3 | | | Cluster job cho nhiều thiết bị | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá bằng KMS, khoá không nằm trên thiết bị | | | Manifest và unlock code gửi riêng | | | AWS xoá theo chuẩn NIST sau khi nạp | |

Ba lưu ý về tối ưu tốc độ chép: | Lưu ý | Chi tiết | |---|---| | Chạy nhiều luồng song song | | | Gom tệp nhỏ trước | | | Đĩa nguồn thường là nút thắt | |

⚠ Với 9 PB, khâu đọc từ nguồn quyết định tiến độ:

Hệ thống lưu trữ tại chỗ đọc
  ở 1 GB/s
        ↓
    9 PB / 1 GB/s ≈ 104 ngày đọc
      liên tục
        ↓
    Đọc song song từ nhiều node
      lưu trữ là bắt buộc

Ba lưu ý về lớp lưu trữ Glacier: | Lớp | Lấy ra | Tối thiểu | |---|---|---| | Glacier Instant Retrieval | tức thì | 90 ngày | | Glacier Flexible Retrieval | 1 phút - 12 giờ | 90 ngày | | Glacier Deep Archive | 12-48 giờ | 180 ngày |

Ba lưu ý về luật vòng đời: | Lưu ý | Chi tiết | |---|---| | Days: 0 chuyển ngay | | | Phí chuyển tầng tính theo object | | | Lọc theo tiền tố hoặc thẻ | |

Ba lưu ý về chi phí lấy ra: | Khoản | Ghi chú | |---|---| | Phí yêu cầu lấy ra | theo số yêu cầu và GB | | Phí truyền ra Internet | ~0,09 USD/GB | | Bulk rẻ nhất, Expedited đắt nhất | |

⚠ Lấy 9 PB ra là khoản tiền rất lớn:

9 PB × 0,09 USD/GB truyền ra
    ≈ 810.000 USD
        ↓
    Lưu trữ thì rẻ, lấy ra thì đắt
    → cân nhắc kỹ trước khi khoá
      dữ liệu vào một đám mây

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đếm object và tổng dung lượng sau khi nạp | | | So checksum vài tệp mẫu | | | Khôi phục thử một tệp từ Deep Archive | |

Và một lời khuyên: hãy thử khôi phục một tệp từ Deep Archive trước khi xoá dữ liệu gốc tại chỗ. Lưu 9 PB vào lớp lưu trữ lạnh nhất là quyết định gần như không đảo ngược được, và bạn muốn biết chắc quy trình lấy ra hoạt động trước khi không còn bản nào khác.