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

Đáp án

**B — Dùng một NAT gateway để ánh xạ nhiều địa chỉ IP thành một địa chỉ IP công khai duy nhất.

Vì sao đúng

Đề yêu cầu một địa chỉ IP tĩnh duy nhất để nhận diện lưu lượng ĐI RA từ môi trường Beanstalk:

"Địa chỉ này sẽ được dùng để nhận
  diện duy nhất lưu lượng ĐẾN TỪ
  môi trường Beanstalk"
        ↓
    Đó là lưu lượng ĐI RA
        ↓
    NAT gateway dịch mọi địa chỉ
      nguồn thành Elastic IP của nó

⚠ Điểm mấu chốt: đây là bài toán về IP NGUỒN, không phải IP đích:

Nhiều EC2 sau ALB
        ↓
    Mỗi máy có IP riêng khác nhau
        ↓
    Gọi ra một API bên ngoài
    → bên kia thấy nhiều IP khác nhau
        ↓
    Không thêm được vào allowlist

⚠ Và NAT gateway giải quyết đúng chuyện đó:

Instance trong private subnet
        ↓
    Route mặc định trỏ tới NAT gateway
        ↓
    NAT thay địa chỉ nguồn bằng
      Elastic IP của nó
        ↓
    Bên ngoài luôn thấy MỘT IP

Cấu hình Beanstalk dùng private subnet:

aws elasticbeanstalk update-environment \
  --environment-name moi-truong-san-xuat \
  --option-settings \
    Namespace=aws:ec2:vpc,OptionName=Subnets,\
Value=subnet-rieng-1a\,subnet-rieng-1b \
    Namespace=aws:ec2:vpc,OptionName=ELBSubnets,\
Value=subnet-cong-khai-1a\,subnet-cong-khai-1b \
    Namespace=aws:ec2:vpc,OptionName=AssociatePublicIpAddress,\
Value=false

⚠ Ba tuỳ chọn đó phải đi cùng nhau:

`Subnets`: instance ở subnet RIÊNG
        ↓
    `ELBSubnets`: load balancer ở
      subnet CÔNG KHAI
        ↓
    `AssociatePublicIpAddress=false`:
      instance không có IP công khai
        ↓
    Thiếu cái cuối → instance vẫn
      đi ra bằng IP riêng của nó

Tạo NAT gateway:

aws ec2 allocate-address --domain vpc

aws ec2 create-nat-gateway \
  --subnet-id subnet-cong-khai-1a \
  --allocation-id eipalloc-abc123

aws ec2 create-route --route-table-id rtb-rieng \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-abc123

⚠ Và vì sao phương án A (NAT instance) kém hơn: | Tiêu chí | NAT gateway | NAT instance | |---|---|---| | Vận hành | AWS quản lý | bạn vá, bạn giám sát | | Sẵn sàng cao | tự động trong AZ | phải tự dựng | | Băng thông | tới 100 Gbps | theo cỡ instance | | Trạng thái | hiện hành | legacy |

Đề nói "ít bảo trì nhất"
        ↓
    NAT instance là một EC2 phải vá
        ↓
    Và phải tự làm HA bằng script
      chuyển đổi

⚠ Và vì sao phương án D sai — không gắn chung một Elastic IP được:

D nói gắn CÙNG một Elastic IP vào
  mọi instance
        ↓
    Một Elastic IP chỉ gắn được vào
      MỘT ENI tại một thời điểm
        ↓
    Về mặt kỹ thuật là không thể

⚠ Và ngay cả khi mỗi máy một EIP thì cũng không giải quyết được:

Mỗi instance một Elastic IP riêng
        ↓
    Bên ngoài vẫn thấy nhiều IP
        ↓
    Và Auto Scaling tạo máy mới
    → phải gán EIP mới mỗi lần
        ↓
    Đúng thứ đề muốn tránh

⚠ Và vì sao phương án C sai — bastion host là để đi VÀO:

Bastion host: điểm vào an toàn để
  quản trị viên SSH vào private
  subnet
        ↓
    Lưu lượng ĐI VÀO
        ↓
    Không dịch địa chỉ nguồn cho
      lưu lượng đi ra

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một IP cố định cho mọi lưu lượng đi ra | | | Dịch vụ quản lý, không vá gì | | | Instance không có IP công khai, an toàn hơn | |

⚠ Và nên có NAT gateway ở MỖI AZ:

Một NAT gateway ở một AZ
        ↓
    AZ đó hỏng → instance ở AZ khác
      mất đường ra
        ↓
    Mỗi AZ một NAT gateway, mỗi cái
      một EIP
        ↓
    Nhưng khi đó có NHIỀU IP đi ra
    → phải khai cả hai vào allowlist

⚠ Đây là đánh đổi thật giữa sẵn sàng cao và số IP:

Một NAT → một IP, nhưng SPOF
        ↓
    Nhiều NAT → nhiều IP, nhưng HA
        ↓
    Bên ngoài thường chấp nhận
      allowlist vài IP
    → chọn HA

⚠ Và Global Accelerator là lựa chọn khác cho IP tĩnh:

Global Accelerator cấp hai IP tĩnh
  anycast
        ↓
    Nhưng đó là IP để KHÁCH VÀO
        ↓
    Không phải IP nguồn khi đi ra
    → sai bài toán

⚠ Và chi phí NAT gateway đáng chú ý:

~0,045 USD/giờ + 0,045 USD/GB xử lý
        ↓
    Với lưu lượng lớn, khoản GB rất
      đáng kể
        ↓
    Gateway endpoint cho S3 và
      DynamoDB miễn phí
    → giảm mạnh lưu lượng qua NAT

aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.ap-southeast-1.s3 \
  --vpc-endpoint-type Gateway \
  --route-table-ids rtb-rieng

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

• **A. Dùng một NAT instance để ánh xạ nhiều IP thành một IP công khai — đây là phương án gần nhất và về mặt chức năng làm được đúng việc, nhưng NAT instance là một EC2 mà bạn phải vá, giám sát và tự dựng cơ chế sẵn sàng cao, trái với yêu cầu ít bảo trì nhất.
• **D. Gắn cùng một Elastic IP vào mọi instance — một Elastic IP chỉ gắn được vào một ENI tại một thời điểm.
• **C. Dùng bastion host — điểm vào an toàn cho quản trị viên, không dịch địa chỉ nguồn cho lưu lượng đi ra.

Ghi nhớ

⚠ Bốn cách có IP tĩnh trên AWS — bảng phải thuộc: | Cách | IP tĩnh cho | |---|---| | NAT gateway + EIP | lưu lượng ĐI RA | | NLB + EIP | lưu lượng ĐI VÀO | | Global Accelerator | lưu lượng ĐI VÀO, anycast | | Elastic IP trên instance | một instance duy nhất |

Từ khoá nhận diện:

"identify outbound traffic by single IP" → NAT gateway "static IP for inbound" → NLB hoặc Global Accelerator "least maintenance" → NAT gateway, không phải NAT instance "SSH into private subnet" → bastion host hoặc Session Manager

Ba lưu ý về NAT gateway: | Lưu ý | Chi tiết | |---|---| | Đặt trong subnet CÔNG KHAI | | | Instance ở subnet RIÊNG trỏ route tới nó | | | Chỉ cho lưu lượng ĐI RA | |

⚠ NAT gateway trong private subnet là lỗi kinh điển:

NAT gateway cần đường ra Internet
        ↓
    Nó phải ở subnet có route tới
      internet gateway
        ↓
    Đặt nhầm vào private subnet
    → không hoạt động, không lỗi rõ

Ba lưu ý về Elastic IP: | Lưu ý | Chi tiết | |---|---| | Gắn vào một ENI tại một thời điểm | | | EIP không gắn vào đâu VẪN TÍNH TIỀN | | | Hạn ngạch 5 EIP mỗi Region (nâng được) | |

⚠ EIP mồ côi là khoản lãng phí âm thầm:

aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]' \
  --output table

Ba lưu ý về Beanstalk trong VPC: | Tuỳ chọn | Ý nghĩa | |---|---| | Subnets | nơi đặt instance | | ELBSubnets | nơi đặt load balancer | | AssociatePublicIpAddress | instance có IP công khai không |

Ba lưu ý về sẵn sàng cao của NAT: | Lưu ý | Chi tiết | |---|---| | NAT gateway chỉ trong một AZ | | | Mỗi AZ một NAT gateway để chịu lỗi | | | Mỗi NAT một Elastic IP riêng | |

Ba lưu ý về giảm chi phí NAT: | Cách | Tác dụng | |---|---| | Gateway endpoint cho S3, DynamoDB | miễn phí, giảm nhiều nhất | | Interface endpoint cho dịch vụ khác | rẻ hơn NAT với lưu lượng lớn | | Gộp NAT khi chấp nhận rủi ro AZ | giảm phí giờ |

Ba lưu ý về Session Manager thay bastion: | Lưu ý | Chi tiết | |---|---| | Không cần bastion, không cần cổng 22 | | | Ghi log mọi phiên | | | Hoạt động qua VPC endpoint, không cần Internet | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Từ instance chạy curl ifconfig.me | | | Kiểm IP trả về là EIP của NAT | | | Kiểm instance không có IP công khai | |

Và một lời khuyên: hãy tạo gateway endpoint cho S3 và DynamoDB ngay khi dựng NAT gateway. Lưu lượng tới hai dịch vụ đó thường chiếm phần lớn lưu lượng đi ra, và cho nó đi qua NAT là trả tiền theo GB cho thứ mà endpoint xử lý hoàn toàn miễn phí.

Đáp án

**B — Cấu hình một public virtual interface trên kết nối Direct Connect, và tạo một AWS Site-to-Site VPN giữa customer gateway và virtual private gateway của VPC.

Vì sao đúng

Đề nêu hai yêu cầu, và chúng dẫn tới kiến trúc "VPN chạy trên Direct Connect": | Yêu cầu | Cách đáp ứng | |---|---| | Hiệu năng ổn định | Direct Connect, không qua Internet | | Dữ liệu phải mã hoá khi truyền | IPsec VPN |

⚠ Điểm mấu chốt: Direct Connect KHÔNG mã hoá:

Direct Connect là kết nối RIÊNG
        ↓
    Riêng tư ≠ mã hoá
        ↓
    Dữ liệu đi ở dạng rõ trên đường
      cáp đó
        ↓
    Yêu cầu tuân thủ đòi mã hoá
    → phải chồng thêm một lớp

⚠ Và VPN chạy trên Direct Connect cần PUBLIC VIF:

Endpoint của Site-to-Site VPN có
  địa chỉ CÔNG KHAI
        ↓
    Private VIF chỉ vào được VPC
      qua IP riêng
        ↓
    Không tới được endpoint VPN
        ↓
    Public VIF cho phép tới endpoint
      công khai của AWS qua đường DX

Đây là lý do phương án C sai — nó dùng private VIF.

⚠ Và đây là kiến trúc đầy đủ:

Trung tâm dữ liệu
        ↓ (Direct Connect, public VIF)
Endpoint công khai của VPN
        ↓ (đường hầm IPsec)
Virtual private gateway
        ↓
VPC và EC2

Gói tin được mã hoá bởi IPsec
        ↓
    Rồi đi trên đường Direct Connect
        ↓
    Vừa riêng tư vừa mã hoá
    → và độ trễ ổn định vì không
      qua Internet

Tạo public VIF:

aws directconnect create-public-virtual-interface \
  --connection-id dxcon-abc123 \
  --new-public-virtual-interface '{
    "virtualInterfaceName": "vif-cong-khai",
    "vlan": 200, "asn": 65001,
    "amazonAddress": "175.45.176.1/30",
    "customerAddress": "175.45.176.2/30"}'

Tạo VPN tới virtual private gateway:

aws ec2 create-vpn-connection \
  --type ipsec.1 \
  --customer-gateway-id cgw-abc \
  --vpn-gateway-id vgw-abc \
  --options '{"StaticRoutesOnly": false}'

⚠ Và vì sao phương án D sai — không có "virtual public gateway":

D nói tạo VPN tới "virtual PUBLIC
  gateway"
        ↓
    AWS không có khái niệm đó
        ↓
    Chỉ có:
      - virtual private gateway (VGW)
      - customer gateway (CGW)
      - transit gateway (TGW)

⚠ Và vì sao phương án A không phải lựa chọn tốt nhất ở đây:

A dùng transit virtual interface
        ↓
    Transit VIF nối tới TRANSIT
      GATEWAY
        ↓
    Nhưng đề nói VPN tới VIRTUAL
      PRIVATE GATEWAY
    → hai thứ không khớp nhau
        ↓
    Và transit VIF cũng không tới
      được endpoint công khai của VPN

⚠ Và có ba cách mã hoá trên Direct Connect — phải phân biệt: | Cách | Đặc điểm | |---|---| | VPN trên public VIF | phổ biến nhất, băng thông giới hạn bởi tunnel | | MACsec | mã hoá tầng 2, chỉ cổng 10/100 Gbps chuyên dụng | | Mã hoá ở tầng ứng dụng (TLS) | luôn nên có, nhưng không phải mã hoá đường truyền |

⚠ Và MACsec là lựa chọn hiệu năng cao hơn:

aws directconnect update-connection \
  --connection-id dxcon-abc \
  --encryption-mode must_encrypt

MACsec mã hoá ở tầng 2
        ↓
    Không giới hạn băng thông như
      tunnel VPN
        ↓
    Nhưng chỉ có với cổng chuyên
      dụng 10 hoặc 100 Gbps
    → và thiết bị hai đầu phải hỗ trợ

⚠ Và giới hạn băng thông của tunnel VPN là điều phải biết:

Mỗi tunnel Site-to-Site VPN:
  khoảng 1,25 Gbps
        ↓
    Direct Connect có thể là 10 Gbps
        ↓
    VPN trên DX bị giới hạn ở
      1,25 Gbps mỗi tunnel
        ↓
    Cần nhiều hơn → dùng nhiều
      tunnel với ECMP qua Transit
      Gateway

⚠ Và ECMP qua Transit Gateway cộng băng thông:

aws ec2 create-vpn-connection \
  --type ipsec.1 \
  --customer-gateway-id cgw-abc \
  --transit-gateway-id tgw-abc \
  --options '{"EnableAcceleration": false,
              "TunnelOptions": []}'

Nhiều VPN tới cùng Transit Gateway
        ↓
    Bật ECMP
        ↓
    Băng thông cộng dồn
    → vượt được giới hạn 1,25 Gbps

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hiệu năng ổn định của đường riêng | | | Dữ liệu mã hoá đáp ứng tuân thủ | | | Dùng lại kết nối Direct Connect đã có | |

⚠ Và cần chú ý tới MTU:

Direct Connect hỗ trợ jumbo frame
  9.001 byte (private VIF)
        ↓
    VPN tunnel: MTU 1.500 hoặc thấp
      hơn
        ↓
    IPsec thêm header
    → MTU hiệu dụng còn khoảng 1.436
        ↓
    Phân mảnh gói làm giảm hiệu năng

⚠ Và VPN dự phòng qua Internet là lớp cuối:

Direct Connect hỏng
        ↓
    Cùng VPN đó chuyển sang đi qua
      Internet
        ↓
    Băng thông thấp hơn nhưng vẫn
      kết nối được
    → BGP tự chuyển

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

• **C. Cấu hình private virtual interface và tạo VPN tới virtual private gateway — đây là phương án gần nhất và private VIF là cách chuẩn để tới VPC qua Direct Connect, nhưng endpoint của Site-to-Site VPN có địa chỉ công khai nên phải đi qua public VIF mới tới được.
• **D. Cấu hình public VIF và tạo VPN tới virtual public gateway — AWS không có khái niệm "virtual public gateway".
• **A. Cấu hình transit virtual interface và tạo VPN tới virtual private gateway — transit VIF nối tới Transit Gateway, không khớp với virtual private gateway, và cũng không tới được endpoint công khai của VPN.

Ghi nhớ

⚠ Ba loại virtual interface — bảng phải thuộc: | VIF | Tới được | Dùng cho VPN trên DX | |---|---|---| | Private | VPC qua VGW | KHÔNG | | Public | endpoint công khai AWS | CÓ | | Transit | Transit Gateway | không |

Từ khoá nhận diện:

"encrypt data over Direct Connect" → VPN trên public VIF, hoặc MACsec "consistent performance" → Direct Connect "reach VPC privately" → private VIF "connect to Transit Gateway" → transit VIF

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | KHÔNG mã hoá theo mặc định | | | Một kết nối vật lý mang nhiều VIF | | | Public VIF cần IP công khai hợp lệ | |

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 | | | BGP cho định tuyến động | |

⚠ Nhiều khách hàng chỉ dựng một tunnel:

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

Ba lưu ý về MACsec: | Lưu ý | Chi tiết | |---|---| | Mã hoá tầng 2, hiệu năng cao | | | Chỉ cổng chuyên dụng 10/100 Gbps | | | Thiết bị hai đầu phải hỗ trợ | |

Ba lưu ý về khả năng phục hồi: | Cấu hình | Mức | |---|---| | Một DX | thấp | | DX + VPN dự phòng | trung bình | | Hai DX ở hai địa điểm | cao |

Ba lưu ý về BGP: | Lưu ý | Chi tiết | |---|---| | Tuyến cụ thể hơn được ưu tiên | | | AS_PATH prepend làm tuyến kém ưu tiên | | | Direct Connect ưu tiên hơn VPN theo mặc định | |

Ba lưu ý về MTU: | Đường | MTU | |---|---| | Private VIF (jumbo) | 9.001 | | Transit VIF | 8.500 | | VPN tunnel | ~1.436 hiệu dụng |

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | TunnelState | tunnel còn sống không | | ConnectionState | kết nối DX còn sống không | | ConnectionErrorCount | lỗi tầng vật lý |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bắt gói và xác nhận lưu lượng được mã hoá | | | Kiểm cả hai tunnel ở trạng thái UP | | | Đo băng thông thật qua tunnel | |

Và một lời khuyên: hãy đo băng thông thật của tunnel VPN trước khi cam kết hiệu năng. Direct Connect có thể là 10 Gbps nhưng mỗi tunnel IPsec chỉ khoảng 1,25 Gbps — nên "hiệu năng ổn định" mà bạn hứa với đội nghiệp vụ có thể thấp hơn tám lần so với con số trên hợp đồng đường truyền.

Đáp án

**B — Cấu hình security group của ứng dụng để chỉ mở đúng những cổng cần thiết, và dùng Amazon Inspector quét lỗ hổng trên các instance EC2 định kỳ.

Vì sao đúng

Đề hỏi thực hành để quét và giảm thiểu lỗ hổng đã biết, và hai vế của đáp án phủ đúng hai việc đó: | Việc | Thành phần | |---|---| | Giảm bề mặt tấn công | security group chỉ mở cổng cần | | Quét lỗ hổng đã biết | Amazon Inspector |

⚠ Điểm mấu chốt: "quét lỗ hổng đã biết" là định nghĩa của Inspector:

Inspector quét:
    - CVE trong gói phần mềm
    - cấu hình mạng phơi ra ngoài
    - lỗ hổng trong image container
    - lỗ hổng trong gói Lambda
        ↓
    Dựa trên cơ sở dữ liệu CVE
    → "lỗ hổng ĐÃ BIẾT"

Bật Inspector:

aws inspector2 enable \
  --resource-types EC2 ECR LAMBDA \
  --account-ids 111122223333

⚠ Và Inspector thế hệ hai quét LIÊN TỤC, không theo lịch:

Inspector Classic: chạy theo
  "assessment template"
        ↓
    Inspector v2: quét tự động khi
      có thay đổi
        ↓
    Cài gói mới → quét lại ngay
    → CVE mới công bố → đánh giá
      lại toàn bộ

⚠ Và Inspector v2 dùng SSM Agent, không cần agent riêng:

Inspector Classic cần agent riêng
        ↓
    Inspector v2 dùng SSM Agent
    → hầu hết AMI đã cài sẵn
        ↓
    Chỉ cần instance profile có
      `AmazonSSMManagedInstanceCore`

Xem kết quả quét:

aws inspector2 list-findings \
  --filter-criteria '{"severity": [{"comparison":"EQUALS",
                                    "value":"CRITICAL"}]}' \
  --query 'findings[].[title,resources[0].id,
                       packageVulnerabilityDetails.vulnerabilityId]' \
  --output table

⚠ Và vì sao phương án C sai — Systems Manager không quét CVE:

Systems Manager có:
    - Patch Manager: cài bản vá
    - Inventory: liệt kê phần mềm
    - Compliance: báo cáo tuân thủ vá
        ↓
    Nhưng nó không đối chiếu với cơ
      sở dữ liệu CVE
    → đó là việc của Inspector

⚠ Nhưng hai dịch vụ bổ trợ nhau rất tốt:

Inspector PHÁT HIỆN lỗ hổng
        ↓
    Patch Manager KHẮC PHỤC bằng
      cách cài bản vá
        ↓
    Dùng cả hai là quy trình đầy đủ

⚠ Và vì sao phương án A không trả lời câu hỏi:

A cài chứng chỉ ACM lên EC2 để mã
  hoá lưu lượng
        ↓
    Đó là bảo vệ dữ liệu KHI TRUYỀN
        ↓
    Không quét lỗ hổng nào
        ↓
    Và chứng chỉ ACM cấp không xuất
      khoá riêng ra được
    → không cài lên EC2 được

⚠ Điểm cuối là chi tiết kỹ thuật đáng nhớ:

Chứng chỉ do ACM cấp: khoá riêng
  không bao giờ rời khỏi ACM
        ↓
    Chỉ gắn được vào ALB, NLB,
      CloudFront, API Gateway
        ↓
    Muốn cài lên EC2
    → ACM Private CA, hoặc CA bên
      ngoài

⚠ Và vì sao phương án D sai — KMS không mã hoá lưu lượng mạng:

D nói dùng KMS mã hoá "mọi lưu
  lượng giữa client và máy chủ"
        ↓
    KMS quản lý KHOÁ, mã hoá DỮ LIỆU
        ↓
    Mã hoá lưu lượng mạng là việc
      của TLS
    → không phải KMS

Thu hẹp security group:

aws ec2 revoke-security-group-ingress \
  --group-id sg-ung-dung \
  --protocol tcp --port 22 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
  --group-id sg-ung-dung \
  --protocol tcp --port 8080 --source-group sg-alb

⚠ Và tham chiếu security group thay vì CIDR là thực hành đúng:

`--cidr 10.0.0.0/16`
        ↓
    Cho phép cả VPC
        ↓
    `--source-group sg-alb`
    → chỉ ALB
        ↓
    Và tự đúng khi ALB co giãn

⚠ Và bỏ SSH hoàn toàn nhờ Session Manager:

aws ssm start-session --target i-0abc123

Không cần cổng 22 mở
        ↓
    Không cần bastion host
        ↓
    Không cần khoá SSH quản lý
    → và mọi phiên đều được ghi log

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bề mặt tấn công nhỏ nhất | | | Phát hiện CVE tự động và liên tục | | | Kết quả gom về Security Hub | |

⚠ Và Inspector tính điểm rủi ro theo ngữ cảnh:

CVSS score thuần: chỉ mức nghiêm
  trọng của lỗ hổng
        ↓
    Inspector score: cộng thêm
      - có phơi ra Internet không
      - có mã khai thác công khai không
        ↓
    Ưu tiên sửa đúng thứ nguy hiểm
      thật

⚠ Và Inspector quét cả image container trong ECR:

aws ecr put-image-scanning-configuration \
  --repository-name ung-dung \
  --image-scanning-configuration scanOnPush=true

Quét lúc đẩy image
        ↓
    Và quét lại khi có CVE mới
    → chặn image có lỗ hổng nghiêm
      trọng ngay ở pipeline

⚠ Và GuardDuty là lớp bổ trợ khác hẳn Inspector: | Dịch vụ | Phát hiện | |---|---| | Inspector | lỗ hổng ĐÃ BIẾT (CVE) | | GuardDuty | HÀNH VI bất thường, đe doạ đang diễn ra | | Macie | dữ liệu nhạy cảm bị phơi |

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

• **C. Cấu hình security group chỉ mở cổng cần thiết và dùng Systems Manager quét lỗ hổng định kỳ — đây là phương án gần nhất và vế security group hoàn toàn đúng, nhưng Systems Manager quản lý bản vá và kiểm kê phần mềm chứ không đối chiếu với cơ sở dữ liệu CVE; đó là việc của Inspector.
• **A. Cài chứng chỉ ACM lên EC2 để bảo vệ lưu lượng — đó là mã hoá khi truyền, không quét lỗ hổng nào; và chứng chỉ do ACM cấp không xuất khoá riêng ra để cài lên EC2 được.
• **D. Dùng KMS mã hoá lưu lượng giữa client và máy chủ, kèm security group — KMS quản lý khoá mã hoá dữ liệu, không mã hoá lưu lượng mạng.

Ghi nhớ

⚠ Bốn dịch vụ bảo mật của AWS — bảng phải thuộc: | Dịch vụ | Phát hiện | |---|---| | Inspector | lỗ hổng phần mềm (CVE), cấu hình mạng phơi ra | | GuardDuty | hành vi độc hại, credential bị lộ | | Macie | dữ liệu nhạy cảm trong S3 | | Detective | điều tra sâu sau khi có phát hiện |

Từ khoá nhận diện:

"scan for known vulnerabilities" → Inspector "detect crypto mining, compromised instance" → GuardDuty "find PII in S3" → Macie "apply patches" → Systems Manager Patch Manager

Ba lưu ý về Inspector v2: | Lưu ý | Chi tiết | |---|---| | Quét liên tục, không theo lịch | | | Dùng SSM Agent, không cần agent riêng | | | Quét EC2, ECR, Lambda | |

⚠ Inspector Classic đã ngừng (2024):

Inspector Classic dùng
  "assessment template" và agent riêng
        ↓
    Đã ngừng nhận khách hàng mới
        ↓
    Đề thi cũ hay nhắc tới nó
    → nhưng Inspector v2 là hiện hành

Ba lưu ý về security group: | Lưu ý | Chi tiết | |---|---| | Chỉ có Allow, không có Deny | | | Stateful — phản hồi tự đi ra được | | | Tham chiếu SG thay vì CIDR | |

Ba lưu ý về giảm bề mặt tấn công: | Cách | Tác dụng | |---|---| | Đóng cổng 22, dùng Session Manager | bỏ hẳn SSH | | Instance trong private subnet | không có IP công khai | | ALB làm điểm vào duy nhất | một chỗ để bảo vệ |

Ba lưu ý về Patch Manager: | Lưu ý | Chi tiết | |---|---| | AWS-RunPatchBaseline cho cả Linux và Windows | | | Patch baseline khai bản vá được duyệt | | | Maintenance window đặt thời điểm | |

Ba lưu ý về Security Hub: | Lưu ý | Chi tiết | |---|---| | Gom phát hiện của Inspector, GuardDuty, Macie | | | Chấm điểm theo chuẩn CIS, PCI-DSS | | | Một bảng điều khiển cho toàn tổ chức | |

Ba lưu ý về quy trình xử lý lỗ hổng: | Bước | Việc | |---|---| | Phát hiện | Inspector quét | | Ưu tiên | theo điểm rủi ro có ngữ cảnh | | Khắc phục | Patch Manager hoặc dựng AMI mới |

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á | | | Inspector quét cả AMI trong pipeline | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem danh sách phát hiện của Inspector | | | nmap từ ngoài xem cổng nào mở | | | Kiểm không còn security group mở 0.0.0.0/0 | |

Và một lời khuyên: hãy kết hợp Inspector với Patch Manager thành một quy trình khép kín. Inspector rất giỏi tìm ra lỗ hổng nhưng nó không sửa gì cả — và một danh sách phát hiện dài ra mỗi tuần mà không ai khắc phục thì chỉ tạo cảm giác an toàn giả.

Đáp án

**B, C và D — Tạo một VPC có virtual private gateway; tạo một đường hầm IPsec giữa thiết bị customer gateway và virtual private gateway; và cấu hình một public virtual interface trên kết nối Direct Connect.

Vì sao đúng

Đề nêu hai yêu cầu và một ràng buộc chi phí: | Yêu cầu | Cách đáp ứng | |---|---| | Tính bảo mật (confidentiality) | IPsec mã hoá | | Tính toàn vẹn (integrity) | IPsec có xác thực gói | | Hiệu quả chi phí nhất | dùng lại DX đã có, dịch vụ VPN quản lý |

⚠ Điểm mấu chốt: Direct Connect không mã hoá, phải chồng VPN lên:

Direct Connect là đường riêng
        ↓
    Nhưng dữ liệu đi ở dạng rõ
        ↓
    Yêu cầu bảo mật và toàn vẹn
    → IPsec cung cấp cả hai

⚠ Và IPsec cho đúng hai tính chất đề yêu cầu: | Tính chất | Cơ chế IPsec | |---|---| | Bảo mật | mã hoá ESP | | Toàn vẹn | HMAC xác thực từng gói | | Xác thực nguồn | IKE với pre-shared key hoặc chứng chỉ |

⚠ Và ba đáp án là ba mảnh của cùng một kiến trúc:

D: public VIF trên Direct Connect
        ↓
    → đường đi tới endpoint công
      khai của VPN
        ↓
B: VPC có virtual private gateway
        ↓
    → điểm cuối phía AWS
        ↓
C: đường hầm IPsec giữa CGW và VGW
        ↓
    → lớp mã hoá

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

Endpoint của Site-to-Site VPN có
  địa chỉ CÔNG KHAI
        ↓
    Private VIF chỉ tới VPC bằng
      IP riêng
        ↓
    Không tới được endpoint VPN
    → phải public VIF

⚠ Đây là điểm rất dễ nhầm:

"VPN tới VPC" nghe như phải dùng
  private VIF
        ↓
    Nhưng bản thân đường hầm VPN
      kết thúc ở endpoint CÔNG KHAI
        ↓
    Sau khi vào đường hầm mới tới
      VPC

Tạo public VIF:

aws directconnect create-public-virtual-interface \
  --connection-id dxcon-abc123 \
  --new-public-virtual-interface '{
    "virtualInterfaceName": "vif-cho-vpn",
    "vlan": 200, "asn": 65001,
    "amazonAddress": "175.45.176.1/30",
    "customerAddress": "175.45.176.2/30",
    "routeFilterPrefixes": [{"cidr": "203.0.113.0/24"}]}'

Tạo VGW và VPN:

aws ec2 create-vpn-gateway --type ipsec.1
aws ec2 attach-vpn-gateway --vpn-gateway-id vgw-abc --vpc-id vpc-abc

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

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

⚠ Và vì sao phương án E đắt hơn và nhiều việc hơn:

E dựng software VPN trên EC2 trong
  VPC
        ↓
    Phải tự cài, tự vá, tự làm HA
        ↓
    Và phải trả tiền instance 24/7
        ↓
    Site-to-Site VPN là dịch vụ
      quản lý
    → rẻ hơn và không phải vận hành

⚠ Nhưng software VPN có một trường hợp dùng đúng:

Cần giao thức mà AWS VPN không hỗ
  trợ
        ↓
    Hoặc cần tính năng đặc thù của
      một hãng
        ↓
    Hoặc cần transit routing phức tạp
    → khi đó mới tự dựng

⚠ Và vì sao phương án F sai — internet gateway không phải điểm cuối VPN:

Internet gateway cho phép tài
  nguyên trong VPC ra Internet
        ↓
    Nó không kết thúc đường hầm
      IPsec
        ↓
    Điểm cuối VPN phía AWS là
      virtual private gateway hoặc
      transit gateway

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mã hoá đầu cuối trên đường riêng | | | Dịch vụ VPN quản lý, không tự vận hành | | | Dùng lại kết nối Direct Connect đã có | |

⚠ Và cần dựng CẢ HAI tunnel:

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

⚠ Và giới hạn băng thông của tunnel phải tính trước:

Mỗi tunnel khoảng 1,25 Gbps
        ↓
    Direct Connect có thể 10 Gbps
        ↓
    VPN trên DX bị nghẽn ở tunnel
        ↓
    Cần nhiều hơn:
      - nhiều VPN + ECMP qua TGW
      - hoặc MACsec

⚠ Và MACsec là lựa chọn thay thế cho hiệu năng cao:

aws directconnect update-connection \
  --connection-id dxcon-abc \
  --encryption-mode must_encrypt

⚠ Và cần chú ý tới MTU khi chồng VPN lên DX:

Direct Connect private VIF hỗ trợ
  jumbo frame 9.001
        ↓
    VPN tunnel MTU khoảng 1.436
      hiệu dụng
        ↓
    Phân mảnh gói làm giảm hiệu năng
    → đặt MTU đúng ở thiết bị hai đầu

⚠ Và với dữ liệu y tế thì mã hoá tầng ứng dụng vẫn cần:

IPsec bảo vệ trên ĐƯỜNG TRUYỀN
        ↓
    Nhưng dữ liệu lưu trong S3, RDS
      cần mã hoá riêng
        ↓
    HIPAA đòi mã hoá cả khi lưu
    → SSE-KMS, RDS encryption

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

• **A. Cấu hình private virtual interface trên kết nối Direct Connect — đây là phương án gần nhất và private VIF là cách chuẩn để tới VPC qua DX, nhưng đường hầm VPN kết thúc ở endpoint có địa chỉ công khai nên phải đi qua public VIF.
• **E. Tạo đường hầm IPsec giữa customer gateway và một software VPN trên EC2 — phải tự cài, tự vá, tự làm sẵn sàng cao, và trả tiền instance 24/7.
• **F. Tạo VPC có internet gateway — internet gateway không phải điểm cuối của đường hầm IPsec.

Ghi nhớ

⚠ Ba loại VIF và mục đích — bảng phải thuộc: | VIF | Tới được | |---|---| | Private | VPC qua VGW hoặc DX Gateway | | Public | endpoint công khai AWS (gồm cả endpoint VPN) | | Transit | Transit Gateway |

Từ khoá nhận diện:

"encrypt over Direct Connect" → public VIF + VPN, hoặc MACsec "confidentiality and integrity in transit" → IPsec "cost-effective encryption" → Site-to-Site VPN quản lý, không tự dựng "VPN endpoint" → virtual private gateway hoặc transit gateway

Ba lưu ý về Site-to-Site VPN: | Lưu ý | Chi tiết | |---|---| | Hai tunnel, luôn dựng cả hai | | | Mỗi tunnel khoảng 1,25 Gbps | | | BGP cho định tuyến động | |

Ba lưu ý về VGW và TGW: | Tiêu chí | VGW | TGW | |---|---|---| | Số VPC | một | hàng nghìn | | ECMP cho VPN | không | CÓ | | Bắc cầu | không | CÓ |

⚠ ECMP qua Transit Gateway cộng băng thông VPN:

Bốn VPN tới cùng TGW, bật ECMP
        ↓
    Băng thông cộng dồn ~5 Gbps
        ↓
    Vượt được giới hạn một tunnel

Ba lưu ý về IPsec: | Thành phần | Việc | |---|---| | IKE | thiết lập khoá và xác thực | | ESP | mã hoá và toàn vẹn dữ liệu | | Pre-shared key hoặc chứng chỉ | xác thực hai đầu |

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | KHÔNG mã hoá theo mặc định | | | Nhiều VIF trên một kết nối vật lý | | | Public VIF cần IP công khai hợp lệ | |

Ba lưu ý về MTU: | Đường | MTU | |---|---| | Private VIF jumbo | 9.001 | | Transit VIF | 8.500 | | VPN tunnel | ~1.436 hiệu dụng |

Ba lưu ý về tuân thủ y tế: | Lớp | Yêu cầu | |---|---| | Khi truyền | IPsec hoặc TLS | | Khi lưu | SSE-KMS, RDS encryption | | Kiểm toán | CloudTrail, VPC Flow Log |

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 | | ConnectionState | kết nối DX |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm cả hai tunnel ở trạng thái UP | | | Bắt gói xác nhận lưu lượng được mã hoá | | | Đo băng thông thật qua tunnel | |

Và một lời khuyên: hãy đo băng thông thật ngay sau khi dựng xong VPN trên Direct Connect. Nhiều đội chỉ phát hiện giới hạn 1,25 Gbps của tunnel khi đã di trú xong dữ liệu và bắt đầu chạy tải thật — lúc đó việc chuyển sang MACsec hay dựng ECMP là một dự án riêng chứ không còn là một dòng cấu hình.

Đáp án

**C — Dùng Athena chạy phân tích bằng SQL trực tiếp trên dữ liệu ở S3.

Vì sao đúng

Đề nêu ba yêu cầu, và Athena khớp cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Kiểm tra bằng SQL | Athena dùng SQL chuẩn (Trino) | | Hiệu quả chi phí | serverless, trả theo TB quét | | Dễ bảo trì | không có cụm nào để quản |

⚠ Điểm mấu chốt: ba phương án còn lại đều NẠP dữ liệu đi nơi khác:

A: nạp vào Redshift mỗi giờ
        ↓
B: nạp vào RDS mỗi giờ
        ↓
D: nạp vào cụm EMR mỗi giờ
        ↓
    Cả ba đều phải:
      - dựng và duy trì một hệ thống
      - viết và vận hành job nạp
      - trả tiền cho hệ thống đó 24/7

⚠ Và Athena truy vấn TẠI CHỖ, không di chuyển dữ liệu:

Dữ liệu nằm nguyên trên S3
        ↓
    Athena đọc trực tiếp
        ↓
    Không có bước ETL nào
    → không có gì để hỏng

Tạo bảng ngoài:

CREATE EXTERNAL TABLE vung_tho.clickstream (
    ma_phien    STRING,
    ma_nguoi_dung STRING,
    trang       STRING,
    thoi_diem   TIMESTAMP,
    thiet_bi    STRING)
PARTITIONED BY (nam STRING, thang STRING, ngay STRING)
STORED AS PARQUET
LOCATION 's3://ho-du-lieu/vung-tho/clickstream/';

Kiểm tra chất lượng dữ liệu:

SELECT
    COUNT(*) AS tong_dong,
    COUNT(DISTINCT ma_phien) AS so_phien,
    SUM(CASE WHEN ma_nguoi_dung IS NULL THEN 1 ELSE 0 END) AS thieu_ma_nd,
    SUM(CASE WHEN thoi_diem > current_timestamp THEN 1 ELSE 0 END)
      AS thoi_diem_tuong_lai,
    MIN(thoi_diem) AS som_nhat,
    MAX(thoi_diem) AS muon_nhat
FROM vung_tho.clickstream
WHERE nam = '2026' AND thang = '09' AND ngay = '01';

⚠ Và Athena chỉ tính tiền khi CHẠY truy vấn:

Không chạy → không tốn gì
        ↓
    Redshift, RDS, EMR: trả tiền
      theo giờ dù có dùng hay không
        ↓
    Kiểm tra chất lượng chạy vài lần
      mỗi ngày
    → Athena rẻ hơn rất nhiều

⚠ Và giá là 5 USD cho mỗi TB QUÉT:

Quét 100 GB = 0,50 USD
        ↓
    Với phân vùng đúng, mỗi lần
      kiểm tra chỉ quét vài GB
        ↓
    Chi phí gần như không đáng kể

⚠ Và phân vùng là thứ quyết định chi phí:

WHERE nam='2026' AND thang='09' AND ngay='01'

Không có điều kiện phân vùng
        ↓
    Quét TOÀN BỘ vùng thô
        ↓
    Có → chỉ quét một thư mục
    → giảm hàng trăm lần

⚠ Và partition projection bỏ được việc khai phân vùng:

TBLPROPERTIES (
  'projection.enabled'='true',
  'projection.nam.type'='integer',
  'projection.nam.range'='2024,2030',
  'projection.thang.type'='integer',
  'projection.thang.range'='1,12',
  'projection.thang.digits'='2',
  'projection.ngay.type'='integer',
  'projection.ngay.range'='1,31',
  'projection.ngay.digits'='2',
  'storage.location.template'=
    's3://ho-du-lieu/vung-tho/clickstream/${nam}/${thang}/${ngay}')

Không cần chạy crawler
        ↓
    Không cần `ALTER TABLE ADD PARTITION`
        ↓
    Athena tự suy ra từ đường dẫn
    → đúng tinh thần "dễ bảo trì"

⚠ Và định dạng cột giảm chi phí thêm một bậc: | Định dạng | Lượng quét cho truy vấn 3 cột | |---|---| | CSV/JSON | toàn bộ tệp | | Parquet | chỉ 3 cột |

⚠ Và vì sao phương án A (Redshift) đắt hơn:

Cụm Redshift chạy 24/7
        ↓
    Cộng job nạp hằng giờ
        ↓
    Cho một việc chỉ là kiểm tra
      chất lượng dữ liệu
    → dùng búa tạ đập ruồi

⚠ Nhưng Redshift Spectrum là lựa chọn hợp lý NẾU đã có cụm:

Công ty đã có cụm Redshift
        ↓
    Spectrum truy vấn S3 tại chỗ
        ↓
    Và JOIN được với bảng trong cụm
        ↓
    Đề không nói có cụm nào
    → Athena đơn giản hơn

⚠ Và vì sao phương án B (RDS) sai về mô hình:

RDS là CSDL GIAO DỊCH
        ↓
    Không tối ưu cho quét lượng lớn
        ↓
    Và nạp clickstream hằng giờ vào
      RDS
    → bảng phình rất nhanh

⚠ Và vì sao phương án D (EMR) là nhiều việc nhất:

Cụm EMR phải: chọn kiểu node, cấu
  hình Spark, quản phiên bản
        ↓
    Và chạy 24/7 hoặc dựng/xoá theo
      lịch
        ↓
    SparkSQL mạnh hơn Athena
    → nhưng bài toán này không cần
      sức mạnh đó

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có hạ tầng nào để quản | | | Chỉ trả tiền khi chạy truy vấn | | | Dữ liệu không phải di chuyển | |

⚠ Và có thể tự động hoá kiểm tra bằng EventBridge + Lambda:

import boto3, time
athena = boto3.client('athena')

def kiem_tra(event, context):
    ph = athena.start_query_execution(
        QueryString=open('kiem-tra.sql').read(),
        ResultConfiguration={'OutputLocation':
                             's3://ket-qua-athena/'},
        WorkGroup='kiem-tra-chat-luong')
    return ph['QueryExecutionId']

⚠ Và workgroup giới hạn chi phí:

aws athena create-work-group --name kiem-tra-chat-luong \
  --configuration '{
    "ResultConfiguration": {"OutputLocation": "s3://ket-qua-athena/"},
    "BytesScannedCutoffPerQuery": 10737418240,
    "EnforceWorkGroupConfiguration": true,
    "PublishCloudWatchMetricsEnabled": true}'

`BytesScannedCutoffPerQuery`
        ↓
    Truy vấn quét quá 10 GB bị HUỶ
        ↓
    Chống một truy vấn thiếu điều
      kiện phân vùng đốt hết ngân
      sách

⚠ Và AWS Glue Data Quality là công cụ chuyên cho việc này:

Rules = [
  ColumnCount = 5,
  IsComplete "ma_nguoi_dung",
  Uniqueness "ma_phien" > 0.95,
  ColumnValues "thoi_diem" <= now()
]

Khai luật chất lượng bằng DSL
        ↓
    Chạy theo lịch, có báo cáo
        ↓
    Chuyên dụng hơn viết SQL tay

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

• **A. Nạp dữ liệu vùng thô vào Redshift hằng giờ và chạy kiểm tra bằng SQL — đây là phương án gần nhất và Redshift thật sự chạy SQL trên dữ liệu lớn rất tốt, nhưng phải duy trì một cụm 24/7 và một job nạp hằng giờ chỉ để kiểm tra chất lượng.
• **B. Nạp vào RDS hằng giờ — RDS là CSDL giao dịch, không tối ưu cho việc quét lượng lớn, và bảng sẽ phình rất nhanh.
• **D. Nạp vào cụm EMR Spark hằng giờ và dùng SparkSQL — nhiều việc vận hành nhất, và sức mạnh của Spark là thừa cho bài toán kiểm tra chất lượng.

Ghi nhớ

⚠ Bốn công cụ chạy SQL trên dữ liệu ở S3 — bảng phải thuộc: | Công cụ | Cần cụm | Dùng khi | |---|---|---| | Athena | KHÔNG | truy vấn không thường xuyên | | Redshift Spectrum | CÓ (Redshift) | đã có cụm, cần JOIN với bảng trong cụm | | EMR SparkSQL | CÓ | xử lý phức tạp, tuỳ biến cao | | Glue ETL | serverless | biến đổi và nạp, không phải truy vấn |

Từ khoá nhận diện:

"SQL checks on S3, cost-effective, easy to maintain" → Athena "join S3 data with warehouse tables" → Redshift Spectrum "complex distributed processing" → EMR "data quality rules" → Glue Data Quality

Ba lưu ý về Athena: | Lưu ý | Chi tiết | |---|---| | 5 USD mỗi TB quét | | | Phân vùng giảm chi phí nhiều nhất | | | Định dạng cột giảm tiếp | |

⚠ Athena engine v3 dựa trên Trino:

Hỗ trợ nhiều hàm hơn, nhanh hơn
        ↓
    Và có thêm: UNLOAD, CTAS, view
        ↓
    Kiểm phiên bản engine của
      workgroup

Ba lưu ý về CTAS: | Lưu ý | Chi tiết | |---|---| | CREATE TABLE AS SELECT ghi kết quả ra S3 | | | Chuyển sang Parquet và phân vùng luôn | | | Hữu ích để tạo vùng curated | |

CREATE TABLE vung_curated.clickstream_sach
WITH (format = 'PARQUET',
      partitioned_by = ARRAY['nam','thang','ngay'],
      external_location = 's3://ho-du-lieu/vung-curated/')
AS SELECT * FROM vung_tho.clickstream
   WHERE ma_nguoi_dung IS NOT NULL;

Ba lưu ý về Glue Data Catalog: | Lưu ý | Chi tiết | |---|---| | Dùng chung cho Athena, Spectrum, EMR, Glue | | | Crawler tự phát hiện schema | | | Partition projection bỏ được crawler | |

Ba lưu ý về kiểm soát chi phí: | Cách | Tác dụng | |---|---| | BytesScannedCutoffPerQuery | huỷ truy vấn quét quá nhiều | | Workgroup riêng cho từng đội | theo dõi chi phí riêng | | CloudWatch metric của workgroup | cảnh báo khi vượt ngưỡng |

Ba lưu ý về tối ưu truy vấn: | Cách | Tác dụng | |---|---| | Chỉ chọn cột cần | giảm quét với Parquet | | Lọc theo phân vùng | giảm nhiều nhất | | Gom tệp nhỏ | giảm chi phí liệt kê |

⚠ Quá nhiều tệp nhỏ làm Athena chậm:

Hàng triệu tệp vài KB
        ↓
    Chi phí liệt kê và mở tệp lấn át
        ↓
    Nhắm 128-512 MB mỗi tệp

Ba lưu ý về tự động hoá: | Công cụ | Việc | |---|---| | EventBridge Scheduler | chạy kiểm tra theo lịch | | Step Functions | luồng nhiều bước có xử lý lỗi | | Glue workflow | điều phối job ETL và kiểm tra |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem DataScannedInBytes của mỗi truy vấn | | | Kiểm truy vấn có dùng phân vùng không | | | So chi phí Athena với chi phí một cụm | |

Và một lời khuyên: hãy đặt BytesScannedCutoffPerQuery cho workgroup ngay khi tạo. Một truy vấn quên điều kiện phân vùng chạy hoàn toàn bình thường và cho kết quả đúng — chỉ có hoá đơn mới nói cho bạn biết nó vừa quét cả năm dữ liệu để đếm số dòng của một ngày.

Đáp án

**B và E — Bản ghi không có health check luôn được coi là khoẻ mạnh; nếu KHÔNG bản ghi nào khoẻ mạnh thì Route 53 coi TẤT CẢ đều khoẻ mạnh; và khi tạo bản ghi failover trong private hosted zone, phải gán IP công khai cho một instance trong VPC để kiểm tra sức khoẻ của endpoint bên trong VPC theo địa chỉ IP.

Vì sao đúng

Hai mệnh đề này là hai hành vi của Route 53 mà rất nhiều người nhớ sai.

⚠ Mệnh đề B — hành vi "tất cả đều hỏng thì coi như tất cả đều khoẻ":

Route 53 đánh giá health check
        ↓
    Mọi bản ghi đều không khoẻ
        ↓
    Trả về NXDOMAIN? KHÔNG
        ↓
    Route 53 coi TẤT CẢ đều khoẻ và
      trả về bình thường

⚠ Lý do của thiết kế này rất hợp lý:

Nếu trả về rỗng
        ↓
    Client không có địa chỉ nào để
      thử
    → chắc chắn hỏng
        ↓
    Trả về một địa chỉ dù nó có thể
      hỏng
    → vẫn có cơ hội
        ↓
    "Fail open" thay vì "fail closed"

⚠ Và vế đầu — bản ghi không có health check luôn khoẻ:

Route 53 không tự đoán trạng thái
        ↓
    Không gắn health check → mặc
      định khoẻ
        ↓
    Đây là lý do PHẢI gắn health
      check cho mọi bản ghi trong
      cấu hình failover

⚠ Mệnh đề E — health check không tới được endpoint trong VPC:

Health checker của Route 53 nằm
  NGOÀI VPC của bạn
        ↓
    Chúng gọi từ Internet công cộng
        ↓
    Endpoint trong private subnet
      không tới được
        ↓
    Muốn kiểm tra theo IP → phải có
      IP công khai

⚠ Nhưng có cách tốt hơn — calculated health check dựa trên CloudWatch:

aws route53 create-health-check \
  --caller-reference $(uuidgen) \
  --health-check-config '{
    "Type": "CLOUDWATCH_METRIC",
    "AlarmIdentifier": {"Region": "ap-southeast-1",
                        "Name": "alarm-ung-dung-noi-bo"},
    "InsufficientDataHealthStatus": "LastKnownStatus"}'

Không cần IP công khai
        ↓
    Alarm CloudWatch phản ánh trạng
      thái nội bộ
        ↓
    Route 53 đọc trạng thái alarm
    → đây là cách chuẩn cho private
      hosted zone

⚠ Và vì sao mệnh đề A sai:

A nói trong cấu hình ACTIVE-ACTIVE,
  Route 53 chỉ trả về tài nguyên
  CHÍNH khoẻ mạnh
        ↓
    Active-active không có khái niệm
      "chính" và "phụ"
        ↓
    Mọi bản ghi đều phục vụ
    → Route 53 trả về những cái khoẻ

⚠ Và active-active với active-passive khác nhau: | Kiểu | Cách cấu hình | |---|---| | Active-active | nhiều bản ghi cùng loại routing (weighted, latency...), đều có health check | | Active-passive | failover routing với PRIMARY và SECONDARY |

⚠ Và vì sao mệnh đề C sai:

C nói phải tạo health check cho
  alias record trỏ tới tài nguyên AWS
        ↓
    Alias record dùng
      `EvaluateTargetHealth`
        ↓
    Route 53 tự đọc trạng thái của
      ELB, CloudFront...
    → KHÔNG cần health check riêng

"AliasTarget": {
  "HostedZoneId": "Z_ALB",
  "DNSName": "alb.elb.amazonaws.com",
  "EvaluateTargetHealth": true}

⚠ Và vì sao mệnh đề D sai — con số không đúng:

D nói "hơn một nửa bản ghi có
  trọng số khác 0 phải hỏng"
        ↓
    Thực tế: Route 53 chỉ dùng bản
      ghi trọng số 0 khi TẤT CẢ bản
      ghi trọng số khác 0 đều hỏng
        ↓
    Không phải "một nửa"

Ba lợi ích khi hiểu đúng: | Lợi ích | Chi tiết | |---|---| | Không kỳ vọng Route 53 trả về rỗng khi mọi thứ hỏng | | | Gắn health check cho MỌI bản ghi | | | Dùng calculated health check cho tài nguyên nội bộ | |

⚠ Và calculated health check gộp nhiều điều kiện:

aws route53 create-health-check \
  --caller-reference $(uuidgen) \
  --health-check-config '{
    "Type": "CALCULATED",
    "ChildHealthChecks": ["hc-web", "hc-csdl", "hc-cache"],
    "HealthThreshold": 2}'

Khoẻ khi ít nhất 2 trong 3 con
  khoẻ
        ↓
    Diễn đạt được logic phức tạp
    → ví dụ "web khoẻ VÀ CSDL khoẻ"

⚠ Và có thể đảo ngược health check:

{"Inverted": true}

Dùng để chủ động rút một Region
  khỏi vòng phục vụ
        ↓
    Đặt alarm ở trạng thái ALARM
    → Route 53 coi endpoint đó hỏng
        ↓
    Đây là cách "tắt" một Region có
      kiểm soát

⚠ Và ngưỡng thất bại quyết định tốc độ chuyển đổi:

`FailureThreshold` = 3, khoảng 30
  giây
        ↓
    90 giây mới coi là hỏng
        ↓
    Cộng TTL của bản ghi
    → tổng thời gian chuyển đổi

⚠ Và TTL thấp là điều kiện để failover nhanh:

TTL 300 giây
        ↓
    Client cache 5 phút
        ↓
    Health check phát hiện hỏng sau
      90 giây
    → client vẫn dùng địa chỉ cũ
      thêm 5 phút
        ↓
    Đặt TTL 60 giây cho bản ghi
      failover

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

• **C. Nếu định tuyến tới tài nguyên AWS mà bạn tạo được alias record thì cũng phải tạo health check cho chúng — đây là phương án gần nhất và health check thật sự là phần cốt lõi của failover, nhưng alias record dùng EvaluateTargetHealth để tự đọc trạng thái của tài nguyên AWS, không cần health check riêng.
• **A. Trong cấu hình active-active, Route 53 chỉ trả về tài nguyên chính khoẻ mạnh — active-active không có khái niệm chính và phụ.
• **D. Phải có hơn một nửa bản ghi trọng số khác 0 hỏng thì Route 53 mới dùng bản ghi trọng số 0 — thực tế là phải TẤT CẢ đều hỏng.

Ghi nhớ

⚠ Ba loại health check của Route 53 — bảng phải thuộc: | Loại | Kiểm gì | |---|---| | Endpoint | gọi HTTP/HTTPS/TCP tới địa chỉ hoặc tên miền | | Calculated | gộp trạng thái của nhiều health check con | | CloudWatch alarm | đọc trạng thái một alarm |

Từ khoá nhận diện:

"all records unhealthy" → Route 53 coi tất cả đều khoẻ | "health check for private resources" → CloudWatch alarm health check "alias to AWS resource" → EvaluateTargetHealth, không cần health check riêng "weight zero records" → chỉ dùng khi mọi bản ghi khác đều hỏng

Ba lưu ý về endpoint health check: | Lưu ý | Chi tiết | |---|---| | Health checker ở nhiều khu vực trên thế giới | | | Endpoint phải nhận được từ Internet công cộng | | | Khoảng 15 checker, mỗi cái gọi độc lập | |

⚠ Ngưỡng đánh giá là 18% checker báo khoẻ:

Route 53 coi endpoint khoẻ khi
  hơn 18% checker báo khoẻ
        ↓
    Không phải 50% hay 80%
        ↓
    Thiết kế để chịu được lỗi mạng
      cục bộ ở một vài khu vực

Ba lưu ý về search string: | Lưu ý | Chi tiết | |---|---| | Tìm chuỗi trong thân phản hồi | | | Chuỗi phải nằm trong 5.120 byte đầu | | | Phải nhận thân trong 2 giây sau mã trạng thái | |

⚠ Search string mạnh hơn chỉ kiểm mã 200:

`/health` trả 200 dù CSDL chết
        ↓
    Cho nó in "OK-DB-OK-CACHE"
        ↓
    Health check tìm chuỗi đó
    → kiểm được cả phụ thuộc

Ba lưu ý về HTTPS health check: | Lưu ý | Chi tiết | |---|---| | Endpoint phải hỗ trợ TLS | | | KHÔNG kiểm tra chứng chỉ hợp lệ hay hết hạn | | | Chỉ cần bắt tay TLS thành công | |

Ba lưu ý về failover routing: | Lưu ý | Chi tiết | |---|---| | PRIMARY và SECONDARY | | | SECONDARY dùng khi PRIMARY hỏng | | | Cả hai nên có health check | |

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | TTL thấp cho bản ghi failover | | | 60 giây là giá trị thường dùng | | | Nhiều client bỏ qua TTL | |

Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Health check endpoint AWS | ~0,50 USD/tháng | | Health check endpoint ngoài AWS | ~0,75 USD/tháng | | Tính năng tuỳ chọn (HTTPS, string) | thêm phí |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tắt endpoint chính và đo thời gian chuyển đổi | | | Xem lịch sử trạng thái health check | | | Kiểm health check có gắn vào mọi bản ghi | |

Và một lời khuyên: hãy dùng CloudWatch alarm health check cho mọi endpoint nằm trong private hosted zone. Gán IP công khai cho một instance chỉ để Route 53 kiểm tra được nó là mở một lỗ hổng vào mạng riêng — và alarm phản ánh trạng thái nội bộ chính xác hơn nhiều so với một lời gọi HTTP từ ngoài Internet.

Đáp án

**A, B và D — Health check HTTPS KHÔNG kiểm chứng chứng chỉ SSL/TLS, nên chứng chỉ sai hoặc hết hạn không làm health check thất bại; nếu cấu hình health check dùng giao thức HTTPS thì endpoint đó phải hỗ trợ TLS; và sau khi nhận mã trạng thái HTTP, health checker phải nhận được thân phản hồi chứa chuỗi tìm kiếm trong VÒNG HAI GIÂY, và chuỗi đó phải nằm trọn trong 5.120 byte đầu.

Vì sao đúng

Ba mệnh đề này là ba chi tiết kỹ thuật của health check mà rất dễ nhớ sai.

⚠ Mệnh đề A — health check HTTPS không kiểm chứng chứng chỉ:

Route 53 chỉ cần bắt tay TLS thành
  công
        ↓
    KHÔNG kiểm:
      - chứng chỉ còn hạn không
      - tên miền có khớp không
      - CA có tin cậy không
        ↓
    Chứng chỉ hết hạn → health check
      VẪN XANH
    → nhưng người dùng thấy cảnh báo

⚠ Đây là bẫy vận hành thật:

Chứng chỉ hết hạn lúc nửa đêm
        ↓
    Trình duyệt chặn, người dùng
      không vào được
        ↓
    Route 53 vẫn báo endpoint khoẻ
    → không có failover, không có
      cảnh báo
        ↓
    Phải giám sát hạn chứng chỉ
      riêng

aws cloudwatch put-metric-alarm \
  --alarm-name chung-chi-sap-het-han \
  --namespace AWS/CertificateManager \
  --metric-name DaysToExpiry --statistic Minimum \
  --period 86400 --evaluation-periods 1 \
  --threshold 30 --comparison-operator LessThanThreshold

⚠ Mệnh đề B — endpoint phải hỗ trợ TLS:

Cấu hình health check kiểu HTTPS
        ↓
    Health checker bắt tay TLS
        ↓
    Endpoint chỉ nghe HTTP
    → bắt tay thất bại
    → health check báo hỏng

⚠ Và Route 53 dùng SNI trong bắt tay:

Health checker gửi tên miền trong
  SNI
        ↓
    Endpoint phục vụ nhiều tên miền
      trên một IP
    → chọn đúng chứng chỉ
        ↓
    Endpoint không hỗ trợ SNI
    → có thể trả về chứng chỉ sai
    → nhưng vẫn không làm health
      check hỏng (vì không kiểm
      chứng chỉ)

⚠ Mệnh đề D — hai ràng buộc về string matching: | Ràng buộc | Giá trị | |---|---| | Thời gian nhận thân sau mã trạng thái | 2 giây | | Vị trí chuỗi trong thân | trong 5.120 byte đầu |

Trang trả về HTML lớn
        ↓
    Chuỗi cần tìm nằm ở cuối trang
        ↓
    Vượt 5.120 byte
    → health check thất bại
        ↓
    Đặt chuỗi ở đầu, hoặc dùng một
      endpoint riêng trả về ngắn gọn

Endpoint kiểm tra sức khoẻ đúng cách:

@app.route('/health')
def suc_khoe():
    trang_thai = {'db': kiem_tra_csdl(),
                  'cache': kiem_tra_cache()}
    if all(trang_thai.values()):
        return 'HEALTHY-ALL-OK', 200
    return 'UNHEALTHY', 503

Phản hồi rất ngắn
        ↓
    Chuỗi `HEALTHY-ALL-OK` nằm ngay
      byte đầu
    → không bao giờ vượt 5.120

Tạo health check có search string:

aws route53 create-health-check \
  --caller-reference $(uuidgen) \
  --health-check-config '{
    "Type": "HTTPS_STR_MATCH",
    "FullyQualifiedDomainName": "app.cong-ty.vn",
    "ResourcePath": "/health",
    "SearchString": "HEALTHY-ALL-OK",
    "Port": 443,
    "RequestInterval": 30,
    "FailureThreshold": 3,
    "MeasureLatency": true}'

⚠ Và vì sao mệnh đề C sai — con số không đúng:

C nói "hơn 80% health checker báo
  khoẻ thì Route 53 coi là khoẻ"
        ↓
    Ngưỡng thật là 18%
        ↓
    Route 53 coi endpoint khoẻ khi
      HƠN 18% checker báo khoẻ

⚠ Ngưỡng 18% thấp có lý do:

Health checker ở nhiều khu vực
  trên thế giới
        ↓
    Sự cố mạng cục bộ làm vài checker
      không tới được
        ↓
    Ngưỡng cao → false positive
    → chuyển đổi không cần thiết
        ↓
    18% đủ để chịu lỗi mạng vùng

⚠ Và vì sao mệnh đề E sai — Route 53 dùng IPv4 theo mặc định:

E nói Route 53 dùng CẢ IPv6 lẫn
  IPv4 khi khai bằng tên miền
        ↓
    Mặc định health check dùng IPv4
        ↓
    Muốn IPv6 phải khai `IPAddress`
      là địa chỉ IPv6
    → không tự dùng cả hai

⚠ Và vì sao mệnh đề F sai:

F nói health check bị tắt thì
  KHÔNG tính phí
        ↓
    Route 53 vẫn tính phí cho health
      check đã tạo, kể cả khi
      `Disabled`
        ↓
    Muốn ngừng tính phí → XOÁ nó

Ba lợi ích khi hiểu đúng: | Lợi ích | Chi tiết | |---|---| | Không tin nhầm health check về chứng chỉ | | | Thiết kế endpoint health đúng cách | | | Biết ngưỡng thật khi chẩn đoán | |

⚠ Và MeasureLatency bật một lần duy nhất:

{"MeasureLatency": true}

Chỉ đặt được lúc TẠO
        ↓
    Không sửa được sau
        ↓
    Bật nó cho biểu đồ độ trễ từ
      nhiều khu vực
    → rất hữu ích để chẩn đoán

⚠ Và bốn loại health check theo giao thức: | Loại | Kiểm | |---|---| | HTTP | mã trạng thái 2xx hoặc 3xx | | HTTPS | bắt tay TLS + mã trạng thái | | HTTP_STR_MATCH | thêm chuỗi trong thân | | TCP | chỉ bắt tay TCP |

⚠ Và TCP health check nhanh nhất nhưng ít thông tin nhất:

Chỉ mở được kết nối TCP là khoẻ
        ↓
    Ứng dụng treo nhưng cổng vẫn mở
    → vẫn báo khoẻ
        ↓
    Dùng cho dịch vụ không phải HTTP

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

• **C. Route 53 tổng hợp dữ liệu từ health checker và coi endpoint khoẻ nếu hơn 80% báo khoẻ — đây là phương án gần nhất và mô tả đúng cơ chế tổng hợp, nhưng ngưỡng thật là 18% chứ không phải 80%; ngưỡng thấp để chịu được lỗi mạng cục bộ.
• **E. Nếu khai endpoint bằng tên miền thì Route 53 dùng cả IPv6 lẫn IPv4 — mặc định chỉ dùng IPv4; muốn IPv6 phải khai địa chỉ IPv6 tường minh.
• **F. Health check tới endpoint ngoài AWS tính phí thêm, và không tính phí khi bị tắt — vế đầu đúng, nhưng health check đã tạo vẫn tính phí kể cả khi ở trạng thái tắt.

Ghi nhớ

⚠ Sáu con số về health check phải thuộc: | Con số | Ý nghĩa | |---|---| | 18% | ngưỡng checker báo khoẻ | | 2 giây | thời gian nhận thân sau mã trạng thái | | 5.120 byte | phạm vi tìm search string | | 10 hoặc 30 giây | khoảng cách giữa các lần kiểm | | 3 | FailureThreshold mặc định | | ~15 | số health checker |

Từ khoá nhận diện:

"HTTPS health check validates certificate" → luôn SAI "search string position" → 5.120 byte đầu "how many checkers must agree" → 18% "health check for private endpoint" → CloudWatch alarm health check

Ba lưu ý về thiết kế endpoint health: | Lưu ý | Chi tiết | |---|---| | Phản hồi ngắn gọn | | | Kiểm cả phụ thuộc quan trọng | | | Đừng để endpoint health tốn tài nguyên | |

⚠ Endpoint health quá nặng gây vấn đề riêng:

`/health` truy vấn CSDL mỗi lần gọi
        ↓
    15 checker × mỗi 10 giây
    → 90 truy vấn mỗi phút
        ↓
    Cache kết quả kiểm tra vài giây

Ba lưu ý về failover: | Lưu ý | Chi tiết | |---|---| | Gắn health check cho MỌI bản ghi | | | TTL thấp để chuyển đổi nhanh | | | Tất cả hỏng → Route 53 trả về tất cả | |

Ba lưu ý về calculated health check: | Lưu ý | Chi tiết | |---|---| | Gộp tới 256 health check con | | | HealthThreshold đặt số con phải khoẻ | | | Inverted đảo ngược kết quả | |

⚠ Inverted dùng để rút Region có kiểm soát:

Muốn tắt một Region để bảo trì
        ↓
    Đặt alarm ở trạng thái ALARM
        ↓
    Health check inverted → báo hỏng
    → Route 53 ngừng gửi lưu lượng

Ba lưu ý về CloudWatch alarm health check: | Lưu ý | Chi tiết | |---|---| | Dùng cho endpoint không ra Internet | | | InsufficientDataHealthStatus quyết định khi thiếu dữ liệu | | | Alarm phải ở cùng tài khoản | |

Ba lưu ý về alias record: | Lưu ý | Chi tiết | |---|---| | EvaluateTargetHealth tự đọc trạng thái tài nguyên AWS | | | Không cần health check riêng | | | Miễn phí (không tính phí truy vấn) | |

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | HealthCheckStatus | khoẻ hay không | | HealthCheckPercentageHealthy | bao nhiêu checker báo khoẻ | | ConnectionTime | độ trễ từ mỗi khu vực |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem lịch sử trạng thái trong console | | | Cố ý làm endpoint trả 503 và đo thời gian phát hiện | | | Kiểm chuỗi tìm kiếm nằm trong 5.120 byte đầu | |

Và một lời khuyên: hãy giám sát ngày hết hạn chứng chỉ bằng một alarm riêng. Health check HTTPS của Route 53 chỉ cần bắt tay TLS thành công, nên một chứng chỉ hết hạn sẽ khiến mọi trình duyệt từ chối kết nối trong khi bảng điều khiển của bạn vẫn hiển thị màu xanh.

Đáp án

**B và D — Phân tích dữ liệu nguội bằng Athena, và chuyển dữ liệu sang S3 Standard-IA sau 30 ngày.

Vì sao đúng

Đề nêu ba yêu cầu, và hai đáp án ghép lại đáp ứng cả ba: | Yêu cầu | Thành phần | |---|---| | Giữ khả năng truy vấn SQL | Athena | | Truy vấn bắt đầu NGAY LẬP TỨC | Standard-IA (đọc tức thì) | | Tiết kiệm tối đa chi phí Redshift | dữ liệu nguội không nằm trong cụm |

⚠ Điểm mấu chốt: "truy vấn bắt đầu ngay" loại Glacier Deep Archive:

Glacier Deep Archive: 12-48 giờ để
  lấy ra
        ↓
    Athena KHÔNG truy vấn được object
      ở lớp đó
        ↓
    Phải khôi phục trước
    → không "bắt đầu ngay"

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

⚠ Và bảng thời gian lấy ra quyết định lớp nào dùng được với Athena: | Lớp | Athena truy vấn trực tiếp | |---|---| | Standard | CÓ | | Standard-IA | CÓ | | Intelligent-Tiering (tầng nóng/lạnh) | CÓ | | Glacier Instant Retrieval | CÓ | | Glacier Flexible Retrieval | KHÔNG | | Glacier Deep Archive | KHÔNG |

⚠ Và Standard-IA rẻ hơn Standard khoảng 46%: | Lớp | Giá xấp xỉ | |---|---| | Standard | 0,023 USD/GB | | Standard-IA | 0,0125 USD/GB | | Glacier Instant Retrieval | 0,004 USD/GB |

Dữ liệu "hiếm khi truy vấn"
        ↓
    Standard-IA hợp
        ↓
    Nhưng có phí LẤY RA 0,01 USD/GB
    → truy vấn nhiều thì đắt hơn
      Standard

Luật vòng đời:

{"Rules": [{
  "ID": "chuyen-sang-ia-sau-30-ngay",
  "Filter": {"Prefix": "du-lieu-phan-tich/"},
  "Status": "Enabled",
  "Transitions": [{"Days": 30, "StorageClass": "STANDARD_IA"}]}]}

⚠ Và 30 ngày là thời gian tối thiểu để chuyển sang IA:

Standard-IA có phí lưu trữ tối
  thiểu 30 ngày
        ↓
    Chuyển sang trước 30 ngày cũng
      không được
        ↓
    Đề nói "sau 30 ngày" — khớp
      chính xác

⚠ Và Athena truy vấn dữ liệu nguội mà không cần cụm nào:

CREATE EXTERNAL TABLE du_lieu_nguoi.giao_dich (
    ma_giao_dich BIGINT,
    ma_khach     STRING,
    so_tien      DECIMAL(12,2),
    thoi_diem    TIMESTAMP)
PARTITIONED BY (nam STRING, thang STRING)
STORED AS PARQUET
LOCATION 's3://ho-du-lieu/du-lieu-phan-tich/';

⚠ Và vì sao phương án A vô nghĩa về mặt kỹ thuật:

A nói "chuyển lưu trữ nền của
  Redshift sang S3 IA"
        ↓
    Không có cách nào làm việc đó
        ↓
    Node DC2: lưu trữ gắn liền node
        ↓
    Node RA3: AWS tự quản lưu trữ
      trên S3
    → nhưng không chọn lớp được

⚠ Nhưng RA3 managed storage đáng nhắc:

RA3 tách tính toán khỏi lưu trữ
        ↓
    Dữ liệu ít dùng tự chuyển xuống
      S3 do AWS quản
        ↓
    Người dùng không thấy và không
      chọn lớp
    → nhưng chi phí lưu trữ thấp hơn

⚠ Và vì sao phương án E không tiết kiệm:

E dựng một cụm Redshift NHỎ HƠN
  cho dữ liệu nguội
        ↓
    Vẫn là một cụm chạy 24/7
        ↓
    Cho dữ liệu "hiếm khi truy vấn"
    → trả tiền liên tục cho thứ ít
      dùng
        ↓
    Athena: không chạy thì không tốn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cụm Redshift nhỏ lại, rẻ hơn | | | Dữ liệu nguội lưu ở lớp rẻ hơn 46% | | | Vẫn truy vấn SQL được, bắt đầu ngay | |

⚠ Và Redshift Spectrum cũng là lựa chọn hợp lệ:

Đã có cụm Redshift
        ↓
    Spectrum truy vấn dữ liệu S3
      tại chỗ
        ↓
    Và JOIN được với bảng nóng trong
      cụm
        ↓
    Athena: không cần cụm, nhưng
      không JOIN được với bảng trong
      Redshift

⚠ Và đề chỉ nói "giữ khả năng truy vấn SQL" — Athena đủ:

Không nói cần đối chiếu với dữ
  liệu nóng
        ↓
    Athena đơn giản hơn và rẻ hơn

Chuyển dữ liệu nguội ra khỏi Redshift:

UNLOAD ('SELECT * FROM giao_dich
         WHERE thoi_diem < CURRENT_DATE - 30')
TO 's3://ho-du-lieu/du-lieu-phan-tich/'
IAM_ROLE 'arn:aws:iam::111122223333:role/RedshiftUnload'
FORMAT AS PARQUET
PARTITION BY (nam, thang)
CLEANPATH;

DELETE FROM giao_dich WHERE thoi_diem < CURRENT_DATE - 30;
VACUUM giao_dich;

⚠ VACUUM là bước hay bị quên sau khi xoá:

DELETE đánh dấu dòng là đã xoá
        ↓
    Nhưng không giải phóng dung lượng
        ↓
    `VACUUM` mới sắp xếp lại và thu
      hồi chỗ
    → không chạy thì cụm không nhỏ
      lại

⚠ Và Parquet giảm chi phí Athena rất nhiều:

Athena tính 5 USD mỗi TB QUÉT
        ↓
    CSV: quét toàn bộ tệp
        ↓
    Parquet: chỉ đọc cột được chọn
    → giảm 5-10 lần

⚠ Và phân vùng giảm thêm một bậc nữa:

WHERE nam='2026' AND thang='08'

Không có điều kiện phân vùng
        ↓
    Quét toàn bộ dữ liệu nguội
        ↓
    Có → chỉ quét một tháng

⚠ Và cần cân nhắc phí lấy ra của Standard-IA:

0,01 USD/GB khi đọc
        ↓
    Truy vấn 100 GB = 1 USD phí
      lấy ra
    + 0,50 USD phí quét Athena
        ↓
    Truy vấn thường xuyên
    → Standard có thể rẻ hơn
        ↓
    Đề nói "hiếm khi truy vấn"
    → IA đúng

⚠ Và Intelligent-Tiering là lựa chọn an toàn khi không chắc:

aws s3api put-bucket-intelligent-tiering-configuration \
  --bucket ho-du-lieu --id tu-phan-tang \
  --intelligent-tiering-configuration '{
    "Id": "tu-phan-tang", "Status": "Enabled",
    "Tierings": [{"Days": 90, "AccessTier": "ARCHIVE_ACCESS"}]}'

Tự chuyển giữa tầng nóng và lạnh
        ↓
    Không có phí lấy ra
        ↓
    Có phí giám sát nhỏ mỗi object
    → hợp khi mẫu truy cập khó đoán

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

• **C. Chuyển dữ liệu sang S3 Glacier Deep Archive sau 30 ngày — đây là phương án gần nhất và thật sự là lớp rẻ nhất, nhưng Athena không truy vấn trực tiếp được, và việc lấy ra mất 12-48 giờ nên vi phạm yêu cầu truy vấn bắt đầu ngay.
• **E. Dựng một cụm Redshift nhỏ hơn cho dữ liệu nguội — vẫn là một cụm chạy 24/7 cho dữ liệu hiếm khi dùng.
• **A. Chuyển lưu trữ nền của Redshift sang S3 IA — không có cơ chế nào cho phép làm việc đó.

Ghi nhớ

⚠ Lớp lưu trữ nào Athena truy vấn được — bảng phải thuộc: | Lớp | Athena | |---|---| | Standard, Standard-IA, One Zone-IA | CÓ | | Intelligent-Tiering | CÓ (trừ tầng Deep Archive Access) | | Glacier Instant Retrieval | CÓ | | Glacier Flexible, Deep Archive | KHÔNG |

Từ khoá nhận diện:

"queryable immediately, rarely accessed" → Standard-IA hoặc Glacier Instant Retrieval "SQL on S3 without cluster" → Athena "join cold data with warehouse tables" → Redshift Spectrum "cheapest, retrieval time not important" → Deep Archive

Ba lưu ý về Standard-IA: | Lưu ý | Chi tiết | |---|---| | Phí lưu trữ tối thiểu 30 ngày | | | Kích thước object tối thiểu 128 KB | | | Có phí lấy ra 0,01 USD/GB | |

⚠ Object nhỏ hơn 128 KB vẫn tính như 128 KB:

Hàng triệu tệp nhỏ chuyển sang IA
        ↓
    Tính tiền theo 128 KB mỗi cái
        ↓
    Có thể ĐẮT HƠN Standard
    → gom tệp nhỏ trước

Ba lưu ý về Glacier Instant Retrieval: | Lưu ý | Chi tiết | |---|---| | Đọc tức thì như Standard-IA | | | Rẻ hơn Standard-IA 68% | | | Phí lấy ra cao hơn (0,03 USD/GB) | | | Tối thiểu 90 ngày | |

⚠ Glacier Instant Retrieval có thể tốt hơn Standard-IA ở đây:

Dữ liệu "hiếm khi truy vấn"
        ↓
    Lưu trữ rẻ hơn nhiều
        ↓
    Phí lấy ra cao hơn — nhưng
      hiếm khi lấy
        ↓
    Đề đưa ra Standard-IA
    → cũng đúng, chỉ là không rẻ
      nhất

Ba lưu ý về Redshift: | Lưu ý | Chi tiết | |---|---| | UNLOAD xuất ra S3, hỗ trợ Parquet | | | VACUUM sau khi xoá để thu hồi chỗ | | | RA3 tách tính toán khỏi lưu trữ | |

Ba lưu ý về Athena: | Lưu ý | Chi tiết | |---|---| | 5 USD mỗi TB quét | | | Phân vùng và Parquet giảm mạnh chi phí | | | Workgroup giới hạn được lượng quét | |

Ba lưu ý về Redshift Spectrum: | Lưu ý | Chi tiết | |---|---| | Cần cụm Redshift đang chạy | | | JOIN được với bảng trong cụm | | | Cùng giá quét như Athena | |

Ba lưu ý về vòng đời: | Lưu ý | Chi tiết | |---|---| | Phí chuyển tầng tính theo số object | | | Không chuyển ngược tự động được | | | Lọc theo tiền tố hoặc thẻ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy truy vấn Athena trên dữ liệu đã chuyển tầng | | | Xem DataScannedInBytes mỗi truy vấn | | | So chi phí Redshift trước và sau | |

Và một lời khuyên: hãy chạy VACUUM sau khi xoá dữ liệu nguội khỏi Redshift. Lệnh DELETE chỉ đánh dấu dòng là đã xoá chứ không giải phóng dung lượng — nên nếu bỏ qua bước này thì cụm vẫn to như cũ và toàn bộ khoản tiết kiệm mà bạn tính toán sẽ không xuất hiện trên hoá đơn.

Đáp án

**C — Chứng chỉ SSL trên máy chủ ứng dụng cũ đã hết hạn. Cấp lại chứng chỉ do một CA được công nhận toàn cầu ký, và cài đầy đủ chuỗi chứng chỉ lên máy chủ đó.

Vì sao đúng

Đề cho ba manh mối, ghép lại chỉ ra đúng một nguyên nhân:

HTTP 502 kèm header
  "X-Cache: Error from CloudFront"
        ↓
    CloudFront KHÔNG kết nối được
      tới origin
        ↓
    Nhưng cổng 443 vẫn mở và phản hồi
        ↓
    → Mạng thông, nhưng bắt tay TLS
      thất bại

⚠ Điểm mấu chốt: CloudFront KIỂM CHỨNG chứng chỉ của origin:

CloudFront yêu cầu origin có chứng
  chỉ:
    - do CA công cộng tin cậy ký
    - còn hạn
    - tên khớp với domain origin
        ↓
    Thiếu một điều kiện → 502

⚠ Và đây là khác biệt lớn so với ALB: | Nơi kết thúc TLS | Chấp nhận chứng chỉ tự ký | |---|---| | Trình duyệt → website | có, kèm cảnh báo đỏ | | ALB → target | CÓ, không kiểm chứng | | CloudFront → custom origin | KHÔNG |

Đây là lý do phương án A sai
        ↓
    Chứng chỉ TỰ KÝ không bao giờ
      dùng được cho origin của
      CloudFront

⚠ Và vì sao phương án B sai — ACM không cấp chứng chỉ để cài lên máy chủ:

Chứng chỉ do ACM cấp: khoá riêng
  KHÔNG BAO GIỜ rời khỏi ACM
        ↓
    Chỉ gắn được vào ALB, NLB,
      CloudFront, API Gateway
        ↓
    Máy chủ ứng dụng cũ (tại chỗ
      hoặc EC2 tự quản)
    → không cài được

⚠ Và có một lựa chọn khác nếu muốn dùng AWS:

aws acm-pca issue-certificate \
  --certificate-authority-arn <arn-ca> \
  --csr fileb://may-chu.csr \
  --signing-algorithm SHA256WITHRSA \
  --validity Value=365,Type=DAYS

ACM Private CA cấp chứng chỉ xuất
  được
        ↓
    Nhưng nó là CA RIÊNG
    → CloudFront không tin
        ↓
    Vẫn phải là CA công cộng

⚠ Và vì sao phương án D sai — chứng chỉ ở CloudFront không gây 502:

Chứng chỉ trên CloudFront hết hạn
        ↓
    Trình duyệt sẽ báo lỗi TLS
        ↓
    Không phải 502 "Error from
      CloudFront"
        ↓
    Và đề nói lỗi hiện ở TRÌNH DUYỆT
      với header của CloudFront
    → nghĩa là CloudFront đã nhận
      được yêu cầu

⚠ Và "cài đầy đủ chuỗi chứng chỉ" là chi tiết quan trọng nhất:

Chứng chỉ lá một mình
        ↓
    CloudFront không dựng được
      chuỗi tin cậy tới CA gốc
        ↓
    Bắt tay thất bại → 502
        ↓
    Phải cài cả chứng chỉ trung gian

Kiểm tra chuỗi chứng chỉ:

openssl s_client -connect ung-dung-cu.cong-ty.vn:443 \
  -servername ung-dung-cu.cong-ty.vn -showcerts

Kết quả phải có:
    - chứng chỉ máy chủ
    - chứng chỉ trung gian
        ↓
    Thiếu trung gian → "unable to
      verify the first certificate"

⚠ Và trình duyệt che giấu lỗi này — đó là lý do khó phát hiện:

Trình duyệt tự tải chứng chỉ trung
  gian nếu thiếu (AIA fetching)
        ↓
    Nên thử bằng trình duyệt thấy
      bình thường
        ↓
    CloudFront KHÔNG làm việc đó
    → nghiêm ngặt hơn trình duyệt

Cấu hình origin cho đúng:

{"CustomOriginConfig": {
   "HTTPPort": 80, "HTTPSPort": 443,
   "OriginProtocolPolicy": "https-only",
   "OriginSslProtocols": {"Quantity": 2,
     "Items": ["TLSv1.2", "TLSv1.3"]},
   "OriginReadTimeout": 30,
   "OriginKeepaliveTimeout": 5}}

Ba lợi ích của việc sửa đúng nguyên nhân: | Lợi ích | Chi tiết | |---|---| | Bắt tay TLS thành công trở lại | | | Trình duyệt cũng tin cậy chứng chỉ đó | | | Không phải thay đổi kiến trúc gì | |

⚠ Và nên đặt cảnh báo để lần sau không tái diễn:

aws cloudwatch put-metric-alarm \
  --alarm-name cloudfront-loi-5xx \
  --namespace AWS/CloudFront \
  --metric-name 5xxErrorRate \
  --dimensions Name=DistributionId,Value=E1ABC \
  --statistic Average --period 300 \
  --evaluation-periods 1 --threshold 5 \
  --comparison-operator GreaterThanThreshold

⚠ Và giám sát hạn chứng chỉ là biện pháp phòng ngừa đúng:

Chứng chỉ hết hạn lúc nửa đêm
        ↓
    Website chết ngay lập tức
        ↓
    Đặt lịch nhắc từ 30 ngày trước
    → hoặc dùng CA có tự động gia hạn
      (Let's Encrypt với certbot)

⚠ Và cần phân biệt các mã lỗi của CloudFront: | Mã | Nghĩa | |---|---| | 502 Bad Gateway | CloudFront không kết nối được origin, thường do TLS | | 503 Service Unavailable | origin quá tải hoặc CloudFront hết công suất | | 504 Gateway Timeout | origin không phản hồi kịp (mặc định 30 giây) |

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

• **A. Chứng chỉ hết hạn, cài chứng chỉ tự ký kèm đầy đủ chuỗi lên máy chủ — đây là phương án gần nhất và chẩn đoán nguyên nhân hoàn toàn đúng, nhưng CloudFront từ chối origin dùng chứng chỉ tự ký; nó bắt buộc phải do CA công cộng ký.
• **B. Cấp lại chứng chỉ trên máy chủ web qua ACM ở us-east-1 — chứng chỉ do ACM cấp không xuất khoá riêng ra được nên không cài lên máy chủ ứng dụng.
• **D. Chứng chỉ trên CloudFront distribution hết hạn, cấp lại qua ACM — chứng chỉ ở phía CloudFront hết hạn gây lỗi TLS ở trình duyệt, không phải 502 với header của CloudFront.

Ghi nhớ

⚠ Yêu cầu chứng chỉ của CloudFront theo từng chặng — bảng phải thuộc: | Chặng | Nguồn chứng chỉ | |---|---| | Người xem ↔ CloudFront | ACM us-east-1, hoặc IAM store | | CloudFront ↔ S3 origin | không cần | | CloudFront ↔ custom origin | CA CÔNG CỘNG, còn hạn, đủ chuỗi |

Từ khoá nhận diện:

"502 with X-Cache: Error from CloudFront" → vấn đề TLS với origin "self-signed certificate as CloudFront origin" → KHÔNG được "ACM certificate on EC2" → KHÔNG xuất khoá riêng được "504 from CloudFront" → origin phản hồi chậm

Ba lưu ý về chứng chỉ origin: | Lưu ý | Chi tiết | |---|---| | Phải do CA công cộng ký | | | Tên trong chứng chỉ phải khớp domain origin | | | Phải cài đủ chuỗi trung gian | |

⚠ Tên không khớp cũng gây 502:

Origin là `alb.elb.amazonaws.com`
        ↓
    Chứng chỉ cấp cho
      `www.cong-ty.vn`
        ↓
    Không khớp → 502
        ↓
    Giải: đặt `OriginDomainName` là
      một tên miền có trong chứng chỉ

Ba lưu ý về chẩn đoán: | Công cụ | Việc | |---|---| | openssl s_client | xem chuỗi chứng chỉ và ngày hết hạn | | CloudFront access log | xem mã lỗi và thời điểm | | x-amz-cf-id | mã yêu cầu để gửi AWS Support |

Ba lưu ý về ACM: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ ACM cấp: miễn phí, tự gia hạn | | | Chỉ gắn vào dịch vụ AWS tích hợp | | | Muốn cài lên máy chủ → ACM Private CA hoặc CA ngoài | |

Ba lưu ý về timeout của origin: | Tham số | Mặc định | Tối đa | |---|---|---| | OriginReadTimeout | 30 giây | 60 giây | | OriginKeepaliveTimeout | 5 giây | 60 giây | | ConnectionTimeout | 10 giây | 10 giây |

Ba lưu ý về origin failover: | Lưu ý | Chi tiết | |---|---| | Origin group gồm origin chính và dự phòng | | | Chuyển khi origin chính trả mã lỗi khai trước | | | Chỉ áp cho GET, HEAD, OPTIONS | |

Ba lưu ý về phòng ngừa: | Lưu ý | Chi tiết | |---|---| | Cảnh báo 5xxErrorRate của CloudFront | | | Giám sát hạn chứng chỉ riêng | | | Tự động gia hạn nếu CA hỗ trợ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | openssl s_client kiểm chuỗi và hạn | | | curl -I qua CloudFront xem mã trả về | | | Kiểm 5xxErrorRate về 0 sau khi sửa | |

Và một lời khuyên: hãy kiểm chuỗi chứng chỉ bằng openssl chứ đừng thử bằng trình duyệt. Trình duyệt tự tải chứng chỉ trung gian còn thiếu nên nó luôn báo mọi thứ bình thường — còn CloudFront thì không, và đó chính là chỗ khác biệt tạo ra lỗi 502 mà không ai giải thích được.

Đáp án

**B, C và F — Ở tài khoản A, tạo một khoá KMS tự quản cấp quyền dùng cho service role của CodePipeline ở tài khoản A và cho tài khoản B, đồng thời tạo bucket S3 có bucket policy cho tài khoản B truy cập; ở tài khoản B tạo một IAM role liên tài khoản, và ở tài khoản A thêm quyền AssumeRole cho service role của CodePipeline; ở tài khoản B tạo service role cho CloudFormation stack với quyền cần thiết, rồi cập nhật cấu hình CodePipeline ở tài khoản A để bao gồm tài nguyên của tài khoản B.

Vì sao đúng

Triển khai liên tài khoản bằng CodePipeline cần ba mảnh ghép, và ba đáp án là ba mảnh đó: | Mảnh | Ở đâu | Vai trò | |---|---|---| | Khoá KMS + bucket artifact | tài khoản A | CodePipeline lưu artifact ở đây | | Cross-account role | tài khoản B | cho A giả nhận để hành động ở B | | CloudFormation service role | tài khoản B | quyền để dựng tài nguyên |

⚠ Điểm mấu chốt: bucket artifact và khoá KMS phải ở TÀI KHOẢN A:

CodePipeline chạy ở tài khoản A
        ↓
    Nó ghi artifact vào bucket của
      chính nó
        ↓
    Tài khoản B ĐỌC artifact đó
    → nên bucket policy phải cho B
      đọc

Đây là lý do phương án D sai — nó đặt bucket ở tài khoản B.

⚠ Và khoá KMS TỰ QUẢN là bắt buộc — không dùng khoá mặc định được:

Artifact được mã hoá bằng KMS
        ↓
    Khoá mặc định `aws/s3` KHÔNG
      chia sẻ liên tài khoản được
        ↓
    Phải tạo customer-managed key
    → và cấp quyền cho tài khoản B

Chính sách khoá KMS ở tài khoản A:

{"Sid": "ChoPhepTaiKhoanBDung",
 "Effect": "Allow",
 "Principal": {"AWS": [
   "arn:aws:iam::111111111111:role/CodePipelineServiceRole",
   "arn:aws:iam::222222222222:root"]},
 "Action": ["kms:Decrypt", "kms:DescribeKey",
            "kms:Encrypt", "kms:GenerateDataKey*",
            "kms:ReEncrypt*"],
 "Resource": "*"}

Bucket policy ở tài khoản A:

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::222222222222:root"},
 "Action": ["s3:Get*", "s3:Put*", "s3:ListBucket"],
 "Resource": ["arn:aws:s3:::artifact-pipeline",
              "arn:aws:s3:::artifact-pipeline/*"]}

⚠ Và chiều giả nhận vai trò rất dễ nhớ ngược:

CodePipeline Ở TÀI KHOẢN A
        ↓
    Muốn hành động Ở TÀI KHOẢN B
        ↓
    → Vai trò được giả nhận nằm Ở B
    → Quyền `sts:AssumeRole` nằm Ở A

Đây là lý do phương án A sai — nó đặt cả hai ở nhầm chỗ.

Cross-account role ở tài khoản B:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111111111111:root"},
  "Action": "sts:AssumeRole"}]}

Chính sách quyền của role đó:

{"Effect": "Allow",
 "Action": ["cloudformation:*", "s3:Get*", "s3:ListBucket",
            "iam:PassRole"],
 "Resource": "*"}

⚠ iam:PassRole là quyền hay bị quên nhất:

Cross-account role gọi CloudFormation
        ↓
    Và truyền service role cho nó
        ↓
    Thiếu `iam:PassRole`
    → lỗi "not authorized to perform
      iam:PassRole"

⚠ Và CloudFormation service role phải ở TÀI KHOẢN B:

Stack được dựng ở tài khoản B
        ↓
    CloudFormation ở B dùng service
      role của B
        ↓
    Role đó có quyền tạo EC2, RDS,
      Lambda... trong B

Đây là lý do phương án E sai — nó đặt service role ở tài khoản A.

⚠ Và service role tách quyền rất tốt về mặt bảo mật:

Không có service role
        ↓
    CloudFormation dùng quyền của
      người gọi
        ↓
    Người gọi phải có quyền tạo MỌI
      tài nguyên trong template
        ↓
    Có service role: người gọi chỉ
      cần `cloudformation:*` và
      `iam:PassRole`

Cấu hình action trong CodePipeline:

{"name": "TrienKhaiTaiKhoanB",
 "actionTypeId": {"category": "Deploy",
                  "owner": "AWS",
                  "provider": "CloudFormation",
                  "version": "1"},
 "roleArn": "arn:aws:iam::222222222222:role/CrossAccountRole",
 "configuration": {
   "ActionMode": "CREATE_UPDATE",
   "StackName": "ung-dung",
   "TemplatePath": "SourceArtifact::mau.yaml",
   "RoleArn": "arn:aws:iam::222222222222:role/CloudFormationServiceRole",
   "Capabilities": "CAPABILITY_NAMED_IAM"}}

⚠ Hai roleArn khác nhau trong cùng một action: | Trường | Vai trò | |---|---| | roleArn (cấp action) | cross-account role — CodePipeline giả nhận | | configuration.RoleArn | service role — CloudFormation dùng |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một pipeline triển khai nhiều tài khoản | | | Quyền tách bạch giữa các tài khoản | | | Artifact mã hoá và kiểm soát được | |

⚠ Và CodePipeline có kiểu "cross-account deployment" dựng sẵn với CDK Pipelines:

CDK Pipelines tự dựng mọi vai trò
  và khoá
        ↓
    Chỉ khai tài khoản đích
        ↓
    Bỏ được toàn bộ việc cấu hình
      thủ công ở trên

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

• **D. Tạo khoá KMS ở tài khoản A nhưng tạo bucket S3 ở tài khoản B với policy cho A truy cập — đây là phương án gần nhất và khoá KMS đặt đúng chỗ, nhưng bucket artifact phải nằm ở tài khoản chứa pipeline (tài khoản A) vì CodePipeline ghi artifact vào đó.
• **A. Ở tài khoản B thêm quyền AssumeRole cho service role của A để giả nhận vai trò ở tài khoản A — chiều bị đảo hai lần; quyền AssumeRole phải ở A, vai trò được giả nhận phải ở B.
• **E. Tạo CloudFormation service role ở tài khoản A và cập nhật CodePipeline ở tài khoản B — cả hai vế đều ngược; stack dựng ở B nên service role ở B, còn pipeline ở A.

Ghi nhớ

⚠ Ba thành phần của triển khai liên tài khoản — bảng phải thuộc: | Thành phần | Ở tài khoản | |---|---| | Pipeline, bucket artifact, khoá KMS | A (nơi có pipeline) | | Cross-account role | B (nơi triển khai) | | CloudFormation service role | B |

Từ khoá nhận diện:

"cross-account CodePipeline" → customer-managed KMS key bắt buộc "artifact bucket location" → tài khoản chứa pipeline "role to assume" → tài khoản đích "CloudFormation service role" → tài khoản đích

Ba lưu ý về khoá KMS: | Lưu ý | Chi tiết | |---|---| | Phải là customer-managed key | | | Khoá mặc định không chia sẻ liên tài khoản được | | | Chính sách khoá phải cho cả hai bên | |

Ba lưu ý về iam:PassRole: | Lưu ý | Chi tiết | |---|---| | Cần khi truyền role cho dịch vụ khác | | | Giới hạn bằng iam:PassedToService | | | Thiếu nó là lỗi hay gặp nhất | |

{"Effect": "Allow", "Action": "iam:PassRole",
 "Resource": "arn:aws:iam::222222222222:role/CloudFormationServiceRole",
 "Condition": {"StringEquals": {
   "iam:PassedToService": "cloudformation.amazonaws.com"}}}

Ba lưu ý về CloudFormation service role: | Lưu ý | Chi tiết | |---|---| | CloudFormation dùng nó thay quyền người gọi | | | Cho phép quyền tối thiểu ở tầng người dùng | | | Cần CAPABILITY_IAM nếu template tạo IAM | |

Ba lưu ý về StackSets: | Lưu ý | Chi tiết | |---|---| | Triển khai một template ra nhiều tài khoản, nhiều Region | | | Kiểu SERVICE_MANAGED dùng Organizations | | | Đơn giản hơn CodePipeline cho việc phân phối hạ tầng | |

⚠ StackSets hợp hơn khi chỉ cần phân phối template:

CodePipeline: có build, test, phê
  duyệt, nhiều giai đoạn
        ↓
    StackSets: chỉ phân phối stack
        ↓
    Cần CI/CD đầy đủ → CodePipeline
    → chỉ cần dựng hạ tầng → StackSets

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Bật versioning cho bucket artifact | | | Chặn truy cập công khai | | | CloudTrail ghi mọi lần giả nhận vai trò | |

Ba lưu ý về chẩn đoán: | Triệu chứng | Nguyên nhân hay gặp | |---|---| | AccessDenied khi đọc artifact | thiếu quyền KMS | | AccessDenied khi PassRole | thiếu iam:PassRole | | Không giả nhận được vai trò | trust policy sai |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy pipeline và xem log từng giai đoạn | | | Đọc CloudTrail ở tài khoản B tìm AssumeRole | | | Kiểm stack đã tạo đúng ở tài khoản B | |

Và một lời khuyên: hãy cân nhắc CDK Pipelines hoặc StackSets trước khi tự dựng cấu hình liên tài khoản này bằng tay. Bốn thành phần phải khớp nhau chính xác ở đúng hai tài khoản, và mỗi lỗi nhỏ đều hiện ra dưới dạng cùng một thông báo AccessDenied không nói gì thêm.