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

Đáp án

A — Thêm nút "đánh dấu spam" tuỳ chỉnh vào Contact Control Panel (CCP) của Amazon Connect; nút gọi Lambda cập nhật thuộc tính cuộc gọi và ghi số vào bảng DynamoDB; sửa contact flow đọc thuộc tính đó và tra bảng DynamoDB để lọc cuộc gọi sau này.

Vì sao đúng

Đề đòi hai thứ: tổng đài viên đánh dấu được ngay trong lúc làm việc, và số đó không được chuyển tới tổng đài viên nữa. Phương án A là con đường ngắn nhất giữa hai điểm đó.

⚠ Điểm mấu chốt: contact flow phải tra danh sách TRƯỚC khi đưa vào hàng đợi, nếu không tổng đài viên vẫn nhận máy:

Cuộc gọi tới
        ↓
    Contact flow: gọi Lambda tra số trong DynamoDB
        ↓
    Có trong danh sách spam → ngắt máy hoặc chuyển sang nhánh xử lý riêng
        ↓
    Không có → đưa vào hàng đợi bình thường
        ↓
    → tổng đài viên không bao giờ thấy cuộc gọi spam nữa

Vì sao DynamoDB là kho lưu đúng: việc tra cứu diễn ra trong đường dẫn xử lý cuộc gọi thời gian thực, mỗi mili giây đều tính. Tra theo khoá chính (số điện thoại) là đúng mô hình truy cập của DynamoDB — độ trễ ổn định ở mức một chữ số mili giây, dù bảng có hàng triệu dòng.

# Lambda được contact flow gọi
import boto3, os
bang = boto3.resource('dynamodb').Table(os.environ['BANG_SPAM'])

def handler(su_kien, ngu_canh):
    so = su_kien['Details']['ContactData']['CustomerEndpoint']['Address']
    ket_qua = bang.get_item(Key={'so_dien_thoai': so})
    return {'laSpam': 'true' if 'Item' in ket_qua else 'false'}

CCP hỗ trợ tuỳ biến qua Amazon Connect Streams API, nên thêm một nút và gắn hành động vào đó là việc được hỗ trợ chính thức, không phải giải pháp chắp vá.

⚠ Chặn theo số gọi đến không phải là biện pháp tuyệt đối:

Số gọi đến có thể bị giả mạo (caller ID spoofing)
        ↓
    Kẻ gọi tự động đổi số liên tục
        ↓
    → danh sách chặn phình ra mà hiệu quả giảm dần
        ↓
    → nên có thêm cơ chế: giới hạn tần suất, xác minh, hoặc chấm điểm rủi ro

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

• C (thêm chức năng để tổng đài viên CHUYỂN cuộc gọi spam sang một hàng đợi riêng; hàng đợi đó kích hoạt Lambda ghi số vào DynamoDB) — đây là phương án gần nhất và kết quả cuối cùng của nó giống hệt A: số spam vào DynamoDB, contact flow tra danh sách. Nhưng cách đi tới đó vòng vèo và tốn kém hơn hẳn. Chuyển cuộc gọi sang hàng đợi khác nghĩa là cuộc gọi vẫn tiếp tục sống — vẫn chiếm một kênh Amazon Connect, vẫn tính phút, trong khi mục tiêu là kết thúc nó. Nó cũng cần dựng thêm cả một hàng đợi và một luồng chỉ để phục vụ việc ghi nhận. Và về thao tác của tổng đài viên, chuyển máy tốn nhiều bước hơn bấm một nút. Đề hỏi phương án "hiệu quả vận hành nhất", nên chi tiết này quyết định.

• B (mô hình học máy tự phát hiện và đánh dấu spam) — không đáp ứng yêu cầu đề nêu. Đề nói rõ tổng đài viên đánh dấu, tức là cần một cơ chế thủ công, dứt khoát. Xây và huấn luyện mô hình phát hiện spam là một dự án riêng: cần dữ liệu gán nhãn, cần vòng đánh giá, cần xử lý cả dương tính giả (chặn nhầm khách thật, thiệt hại lớn hơn nhiều so với việc lọt một cuộc spam). "Operationally efficient" là tiêu chí mà phương án này thua rõ nhất.

• D (lệnh thoại để tổng đài viên đánh dấu spam bằng giọng nói) — thêm một tầng phức tạp không cần thiết: phải nhận dạng giọng nói, phải xử lý nhầm lẫn, và rủi ro kích hoạt nhầm khi tổng đài viên đang nói chuyện với khách là rất thật. Một nút bấm vừa đơn giản hơn vừa đáng tin hơn.

Ghi nhớ

⚠ Bốn thành phần của Amazon Connect — bảng phải thuộc: | Thành phần | Việc | |---|---| | Contact flow | kịch bản định tuyến cuộc gọi — nơi cắm logic | | CCP (Contact Control Panel) | giao diện tổng đài viên, tuỳ biến qua Streams API | | Queue | hàng đợi chờ tổng đài viên | | Routing profile | tổng đài viên nào phục vụ hàng đợi nào | | Contact attributes | dữ liệu gắn theo cuộc gọi, đọc được trong flow |

Từ khoá nhận diện:

"agents can mark a call as spam" → nút tuỳ chỉnh trong CCP + Lambda "prevent from being routed to agents" → tra danh sách TRONG contact flow, trước khi vào hàng đợi "lưu danh sách để tra nhanh" → DynamoDB "machine learning model" khi đề đòi thao tác thủ công → quá mức cần thiết "transfer to a designated queue" chỉ để ghi nhận → lãng phí, cuộc gọi vẫn chạy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Flow có tra đúng không | bật flow logs, xem giá trị thuộc tính từng bước | | Lambda có kịp không | chỉ số Duration — phải xa mức 8 giây | | Có chặn nhầm không | rà định kỳ danh sách, đối chiếu với khiếu nại của khách |

Và một lời khuyên: hãy đặt TTL cho các mục trong bảng chặn và rà soát danh sách định kỳ, đừng để nó chỉ có thêm mà không bao giờ bớt. Đây là chỗ hệ thống chặn spam gây thiệt hại mà không ai nhận ra: số điện thoại được tái sử dụng, một tổng đài viên bấm nhầm nút trong lúc bực bội, hoặc một khách hàng thật gọi từ tổng đài công ty có số bị người khác lạm dụng. Từ đó trở đi họ không bao giờ gọi được nữa — cuộc gọi bị ngắt trước khi có ai nhìn thấy nó, nên không có bản ghi tương tác, không có ticket, không có gì trong báo cáo. Với mọi chỉ số bạn theo dõi, những khách hàng đó chỉ đơn giản là ngừng gọi.

Đáp án

B — Tạo một public virtual interface mới trên kết nối Direct Connect hiện có, và dựng VPN nối tới VPC qua public VIF đó.

Vì sao đúng

Đề đòi mã hoá dữ liệu trên đường truyền mà vẫn giữ hiệu năng mạng ổn định. Direct Connect tự nó không mã hoá, nên phải chồng một lớp VPN lên trên — và câu hỏi là chồng lên đường nào.

⚠ Điểm mấu chốt: Direct Connect KHÔNG mã hoá — đó là đường riêng, nhưng dữ liệu đi ở dạng rõ:

Direct Connect: đường vật lý riêng, không đi qua Internet công cộng
        ↓
    Nhưng KHÔNG có mã hoá ở tầng nào cả
        ↓
    Yêu cầu tuân thủ đòi "encrypted in transit" thì DX một mình không đủ
        ↓
    → phải chạy IPSec VPN bên trên nó

Vì sao phải là public VIF. Điểm cuối VPN của AWS (virtual private gateway hoặc transit gateway) có địa chỉ IP công cộng. Muốn tới được chúng thì phải đi qua một đường có thể định tuyến tới endpoint công cộng của AWS — đó chính là public VIF.

Mạng công ty
        ↓
    Direct Connect (đường vật lý)
        ↓
    Public VIF — quảng bá tuyến tới endpoint công cộng của AWS
        ↓
    Đường hầm IPSec tới VGW của VPC
        ↓
    → mã hoá đầy đủ, mà vẫn chạy trên đường riêng, không chạm Internet

⚠ Private VIF KHÔNG dùng để dựng VPN tới VPC được:

Private VIF nối thẳng vào VGW bằng địa chỉ riêng
        ↓
    Nó KHÔNG tới được IP công cộng của endpoint VPN
        ↓
    → không có cách nào thiết lập đường hầm IPSec qua nó
        ↓
    → đây chính là chỗ phương án C sai

Cách làm hiện đại hơn cho cùng bài toán là MACsec (mã hoá tầng 2 trên chính cổng Direct Connect, chỉ có ở một số tốc độ cổng) hoặc Site-to-Site VPN gắn vào transit gateway qua transit VIF. Nhưng với danh sách phương án của đề, public VIF là câu trả lời.

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

• C (tạo private VIF mới trên kết nối DX hiện có, dựng VPN qua private VIF đó) — đây là phương án gần nhất và nó chỉ khác đáp án đúng một từ: cũng thêm VIF vào kết nối sẵn có, cũng chạy VPN trên Direct Connect thay vì Internet, nên nó đúng về ý đồ hiệu năng. Nó chỉ chọn sai loại VIF, và sai này là sai chí mạng. Private VIF chỉ định tuyến tới địa chỉ riêng trong VPC; nó không quảng bá tuyến tới các endpoint công cộng của AWS, mà endpoint của Site-to-Site VPN lại nằm ở đó. Không có đường tới điểm cuối thì không thiết lập được đường hầm. Đây là bẫy hay nhất của câu này vì nó thưởng đúng cho người nhớ được bảng loại VIF.

• A (dựng Site-to-Site VPN mới đi qua Internet) — đạt được yêu cầu mã hoá nhưng phá vỡ yêu cầu về hiệu năng, thứ đề nêu thẳng ("maintain consistent network performance"). Lưu lượng qua Internet công cộng có độ trễ dao động, có mất gói, và không có cam kết băng thông — đúng những lý do công ty đã đầu tư vào Direct Connect. Nó cũng bỏ phí kết nối DX đang trả tiền.

• D (Client VPN endpoint, người dùng nối qua Internet) — sai cả về mô hình lẫn về hiệu năng. Client VPN là client-to-site, dành cho từng máy cá nhân; đề mô tả lưu lượng giữa mạng công ty và VPC, tức là site-to-site. Và nó vẫn đi qua Internet, lặp lại vấn đề của phương án A.

Ghi nhớ

⚠ Ba loại VIF — bảng phải thuộc, và nhớ cột cuối: | Loại VIF | Tới được | Dựng VPN qua được không | |---|---|---| | Private VIF | VPC qua VGW (địa chỉ riêng) | không | | Transit VIF | DX gateway → transit gateway | không trực tiếp | | Public VIF | endpoint công cộng của AWS (S3, DynamoDB, endpoint VPN) | có |

Từ khoá nhận diện:

"Direct Connect" + "data in transit must be encrypted" → VPN trên public VIF, hoặc MACsec "maintain consistent network performance" → không được đẩy sang Internet "VPN over the private virtual interface" → LUÔN SAI, private VIF không tới được endpoint VPN "Client VPN" cho lưu lượng mạng-tới-mạng → SAI mô hình "Direct Connect is encrypted" → SAI, DX không mã hoá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đường hầm có đi qua DX không | traceroute — không được thấy hop của nhà mạng Internet | | Cả hai tunnel có lên không | aws ec2 describe-vpn-connections, xem trạng thái từng tunnel | | Thông lượng thực tế | đo bằng iperf, so với kỳ vọng sau khi trừ chi phí mã hoá |

Và một lời khuyên: hãy chạy traceroute sau khi dựng xong và xác nhận đường đi không có hop nào của nhà mạng Internet. Đây là chỗ cấu hình rất dễ trông như đã đúng trong khi hoàn toàn không: nếu tuyến BGP không được ưu tiên đúng, hoặc thiết bị của bạn có sẵn một tuyến mặc định ra Internet, đường hầm IPSec vẫn thiết lập thành công và vẫn hiện UP — nhưng nó đang chạy qua Internet công cộng chứ không qua Direct Connect. Yêu cầu mã hoá coi như đạt, mọi kiểm tra kết nối đều xanh, và bạn chỉ phát hiện ra vào ngày đầu tiên có sự cố mạng ở nhà mạng — đúng ngày mà Direct Connect lẽ ra phải bảo vệ bạn khỏi chuyện đó.

Đáp án

D — Đổi volume Provisioned IOPS 200 GB / 3.000 IOPS sang một volume General Purpose SSD (gp2) dung lượng 1 TB.

Vì sao đúng

Câu này là một phép tính. Với gp2, IOPS nền = 3 × số GB, nên một volume 1 TB cho ra đúng 3.000 IOPS — bằng mức đang được cấp phát, nhưng rẻ hơn đáng kể.

⚠ Điểm mấu chốt: 1.000 GB là ngưỡng mà gp2 đạt 3.000 IOPS NỀN và không còn phụ thuộc credit:

gp2 dưới 1.000 GB
        ↓
    IOPS nền thấp hơn 3.000, phải tiêu credit để bùng lên
        ↓
    Tải nặng kéo dài → cạn credit → tụt về mức nền

gp2 từ 1.000 GB trở lên
        ↓
    IOPS nền ≥ 3.000, không cần credit nữa
        ↓
    → hiệu năng ổn định vô thời hạn, tương đương PIOPS 3.000

Đây là lý do phương án nêu đúng con số 1 TB chứ không phải một con số bất kỳ. Nếu đổi sang gp2 300 GB thì chỉ có 900 IOPS nền — hiệu năng sụt thảm hại.

⚠ Ngày nay gp3 mới là câu trả lời tối ưu, nhưng nó không có trong danh sách phương án:

gp3 tách IOPS khỏi dung lượng
        ↓
    3.000 IOPS đi kèm miễn phí ở MỌI dung lượng, kể cả 200 GB
        ↓
    → giữ nguyên 200 GB, vẫn có 3.000 IOPS, rẻ hơn gp2 1 TB rất nhiều
        ↓
    → nhưng đề chỉ cho chọn giữa gp2, st1 và EFS

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

• B (đổi sang volume Throughput Optimized HDD (st1) 1 TB) — đây là phương án gần nhất và nó đúng về mặt chi phí: st1 rẻ hơn gp2 khá nhiều, và cũng đúng dung lượng 1 TB. Nhưng nó phá vỡ yêu cầu quan trọng nhất của đề: "low latency and random access". st1 là đĩa từ, được tối ưu cho truy cập tuần tự và thông lượng lớn — kiểu tải của log, big data, xử lý theo lô. Với truy cập ngẫu nhiên, đầu đọc phải di chuyển liên tục và hiệu năng sụp đổ: st1 chỉ đạt khoảng 500 IOPS tối đa so với 3.000 của gp2, và độ trễ cao hơn hàng chục lần. AWS còn nói thẳng rằng st1 và sc1 không dùng cho boot volume và không dùng cho tải truy cập ngẫu nhiên. Đây là bẫy hay vì mọi con số bề mặt đều khớp — cùng 1 TB, rẻ hơn — chỉ có đặc tính truy cập là không khớp.

• A (EFS với throughput mode Provisioned) — đổi hẳn mô hình lưu trữ. EFS là hệ thống tệp mạng (NFS), có độ trễ cao hơn EBS đáng kể vì mỗi thao tác phải qua mạng. Ứng dụng đang cần độ trễ thấp và truy cập ngẫu nhiên, đó là điểm mạnh của khối lưu trữ gắn trực tiếp chứ không phải của NFS. Provisioned throughput cũng đắt, nên phương án này vừa chậm hơn vừa không rẻ hơn.

• C (EFS với performance mode Max I/O) — tệ hơn A ở đúng điểm đề quan tâm. Max I/O đánh đổi độ trễ để lấy thông lượng tổng cao hơn: nó dành cho hàng nghìn client truy cập song song, và độ trễ mỗi thao tác CAO HƠN so với chế độ General Purpose. Đề đòi độ trễ thấp, nên đây là lựa chọn đi ngược yêu cầu một cách rõ ràng nhất.

Ghi nhớ

⚠ Bốn loại EBS — bảng phải thuộc, chú ý cột cuối: | Loại | IOPS tối đa | Hợp với | Truy cập ngẫu nhiên | |---|---|---|---| | gp2 | 16.000 (3 IOPS/GB, bùng bằng credit) | đa dụng | có | | gp3 | 16.000 (3.000 miễn phí, mua thêm độc lập) | đa dụng, mặc định mới | có | | io1 / io2 | 64.000 / 256.000 (Block Express) | CSDL đòi IOPS rất cao | có | | st1 / sc1 | 500 / 250 | log, big data, tuần tự | KHÔNG |

Từ khoá nhận diện:

"low latency and random access" → bắt buộc SSD, loại st1/sc1 "lower cost without impacting performance" → tính lại IOPS ở loại rẻ hơn "1 TB gp2" → đúng 3.000 IOPS nền — con số cố ý của đề "st1 for random access" → LUÔN SAI "EFS Max I/O" khi cần độ trễ thấp → SAI, Max I/O đánh đổi độ trễ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | IOPS thực tế đang dùng | VolumeReadOps + VolumeWriteOps chia cho khoảng thời gian | | Có đang cạn credit không | BurstBalance | | Độ trễ mỗi thao tác | VolumeTotalReadTime chia VolumeReadOps |

Và một lời khuyên: hãy đo IOPS thực tế đang dùng trước khi đổi loại volume, đừng lấy mức đã cấp phát làm chuẩn. Đây là chỗ tiền bị tiêu vô ích nhiều nhất trong toàn bộ hoá đơn EBS: rất nhiều volume PIOPS được cấp 3.000 hay 5.000 IOPS từ ngày dựng hệ thống, dựa trên một ước lượng thận trọng của ai đó nhiều năm trước, trong khi tải thật chỉ chạm tới vài trăm. Không có gì cảnh báo bạn về khoảng cách đó — volume hoạt động hoàn hảo, độ trễ thấp, không một lỗi nào, và hoá đơn thì chỉ hiện một dòng tổng cho EBS. Con số duy nhất phơi bày sự lãng phí là tỷ lệ giữa IOPS đang dùng và IOPS đang trả tiền, và nó không xuất hiện trên bất kỳ bảng điều khiển mặc định nào.

Đáp án

C, E, F — ba bước để chuyển vùng dưới 1 phút với chi phí hợp lý:

• E — Chạy tầng web và ứng dụng ở cả hai Region theo mô hình active/passive, dùng Auto Scaling group trải nhiều AZ, dùng zonal Reserved Instance cho số máy tối thiểu và On-Demand cho phần thêm.
• C — Dùng DynamoDB global table để đọc và ghi được ở cả hai Region.
• F — Dùng Route 53 failover routing policy, đặt TTL 30 giây.

Vì sao đúng

Con số 1 phút là ràng buộc chi phối toàn bộ câu hỏi. Nó loại mọi phương án cần dựng hạ tầng lúc sự cố, và nó quyết định luôn giá trị TTL.

⚠ Điểm mấu chốt: TTL của DNS là trần dưới của thời gian chuyển vùng — không có cách nào nhanh hơn nó:

Route 53 phát hiện Region chính hỏng (health check)
        ↓
    Đổi bản ghi sang Region dự phòng
        ↓
    Nhưng client và DNS resolver còn giữ CACHE bản ghi cũ tới hết TTL
        ↓
    TTL 30 phút → người dùng vẫn đi vào Region đã chết trong 30 phút
        ↓
    TTL 30 giây → hầu hết chuyển sang trong vòng một phút

Đây là lý do F đúng và A sai — và nó chỉ nằm ở một con số.

Vì sao DynamoDB global table (C) mà không phải Aurora global database (D). Đề nói rõ tầng dữ liệu là NoSQL. Ngoài ra global table là multi-active: ghi được ở cả hai Region, nên khi chuyển vùng không cần bước promote nào:

Vì sao active/passive (E) mà không phải active/active (B). Đề đòi tối ưu chi phí đồng thời với RTO 1 phút. Active/passive giữ Region hai chạy ở quy mô tối thiểu — đủ để nhận tải ngay lập tức rồi tự co giãn lên. Và phần "zonal RI cho số máy tối thiểu, On-Demand cho phần thêm" chính là mô hình chi phí đúng cho hình thái đó.

⚠ Health check của Route 53 phải kiểm một endpoint phản ánh SỨC KHOẺ THẬT của cả tầng:

Health check trỏ vào trang tĩnh /index.html
        ↓
    Web server còn sống nhưng CSDL đã mất kết nối
        ↓
    Health check vẫn xanh → không chuyển vùng
        ↓
    → người dùng nhận lỗi 500 trong khi hệ thống DR nằm im

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

• A (weighted routing 100/0 giữa hai Region, TTL 30 phút) — đây là phương án gần nhất và weighted routing thật sự dùng để chuyển vùng được: đặt 100/0 rồi đổi trọng số là một cách chuyển tải hợp lệ. Nhưng nó hỏng ở cả hai vế. Thứ nhất, TTL 30 phút khiến RTO 1 phút là bất khả thi — dù bạn đổi trọng số ngay lập tức, client vẫn giữ bản ghi cũ tới nửa giờ. Thứ hai, weighted routing không tự động chuyển vùng: phải có người vào đổi trọng số, trong khi failover routing gắn với health check và tự làm việc đó. Đây là bẫy tinh vi vì phương án nêu đúng công cụ họ hàng gần nhất, và chỉ sai ở con số TTL cùng tính tự động.

• B (active/active hai Region, dùng Spot Instance) — sai ở lựa chọn Spot. Đề đòi chịu được sự cố và giữ trải nghiệm người dùng, mà Spot có thể bị thu hồi với 2 phút báo trước. Dùng Spot cho hạ tầng dự phòng thảm hoạ nghĩa là đúng lúc bạn cần nó nhất — khi Region chính sập và tải dồn sang — dung lượng Spot ở Region đó cũng đang khan hiếm nhất. Active/active cũng đắt hơn active/passive, đi ngược yêu cầu chi phí.

• D (Aurora global database) — sai loại cơ sở dữ liệu. Đề nói NoSQL data tier; Aurora là cơ sở dữ liệu quan hệ. Đây là phương án chỉ sai một từ nhưng sai dứt khoát.

Ghi nhớ

⚠ Bốn chính sách định tuyến Route 53 — bảng phải thuộc: | Chính sách | Việc | |---|---| | Failover | chính/phụ, tự chuyển theo health check — chuẩn cho DR | | Weighted | chia tải theo tỷ lệ, đổi trọng số thủ công | | Latency-based | gửi tới Region có độ trễ thấp nhất | | Geolocation / Geoproximity | theo vị trí người dùng | | Multivalue answer | trả nhiều bản ghi, có health check, dạng cân bằng tải đơn giản |

Từ khoá nhận diện:

"failover within 1 minute" → failover routing + TTL thấp (30–60 giây) "NoSQL data tier" + đa Region → DynamoDB global table "relational" + đa Region → Aurora global database "TTL 30 minutes" khi RTO tính bằng phút → LUÔN SAI "Spot Instances" cho hạ tầng DR → SAI, có thể bị thu hồi đúng lúc cần

Ba việc kiểm chứng: | Việc | Cách | |---|---| | TTL thật của bản ghi | dig <ten-mien> — đọc giá trị TTL trả về | | Health check có nhạy không | chủ động làm hỏng endpoint và bấm giờ tới lúc DNS đổi | | Region hai có gánh nổi không | diễn tập chuyển toàn bộ tải sang đó |

Và một lời khuyên: hãy diễn tập chuyển toàn bộ tải sang Region dự phòng và để nó chạy thật vài giờ, đừng chỉ kiểm tra rằng health check hoạt động. Đây là chỗ kế hoạch DR sụp đổ đúng vào lúc được dùng: Region dự phòng vẫn chạy suốt nhiều tháng, health check xanh, dữ liệu sao chép đầy đủ, mọi thứ trông sẵn sàng — nhưng nó chưa bao giờ nhận quá vài phần trăm lưu lượng thật. Hạn mức vCPU ở đó chưa được nâng, một biến môi trường trỏ về endpoint của Region chính, một chứng chỉ đã hết hạn từ lâu mà không ai để ý vì không có ai gọi vào. Không chỉ số nào phát hiện được những thứ đó khi hệ thống đang nhàn rỗi; chúng chỉ hiện ra dưới tải thật, và nếu lần đầu tiên có tải thật lại chính là lúc Region chính đang cháy thì bạn đang gỡ hai sự cố cùng lúc.

Đáp án

C, E — hai thay đổi chữa việc mở quá nhiều kết nối cơ sở dữ liệu:

• C — Đưa đoạn mã mở kết nối RA NGOÀI hàm xử lý sự kiện.
• E — Nối RDS Proxy (có gom kết nối) tới reader endpoint của cụm Aurora.

Vì sao đúng

Đề chỉ đích danh nguyên nhân: ứng dụng mở quá nhiều kết nối, gây độ trễ. Đây là bài toán kinh điển khi Lambda gặp cơ sở dữ liệu quan hệ, và có hai lớp phải sửa.

⚠ Điểm mấu chốt: mã ngoài handler chạy MỘT LẦN cho mỗi môi trường thực thi, mã trong handler chạy MỖI lời gọi:

Lambda khởi tạo môi trường thực thi (cold start)
        ↓
    Chạy mã ở phạm vi module — MỞ KẾT NỐI TẠI ĐÂY
        ↓
    Gọi handler lần 1, lần 2, lần 3... trên cùng môi trường
        ↓
    → kết nối được dùng lại, không mở thêm
        ↓
    Nếu mở kết nối TRONG handler: mỗi lời gọi một kết nối mới, và
      kết nối cũ thường không được đóng đúng cách → CSDL cạn slot

import os, pymysql

# ĐÚNG: chạy một lần cho mỗi môi trường thực thi
ket_noi = pymysql.connect(
    host=os.environ['DB_HOST'], user=os.environ['DB_USER'],
    password=os.environ['DB_PASS'], database=os.environ['DB_NAME'],
    connect_timeout=5)

def handler(su_kien, ngu_canh):
    # SAI nếu đặt lệnh connect() ở đây
    with ket_noi.cursor() as con_tro:
        con_tro.execute("SELECT * FROM don_hang WHERE id = %s", (su_kien['id'],))
        return con_tro.fetchall()

E — vì sao vẫn cần RDS Proxy dù đã sửa mã. Tận dụng lại kết nối chỉ giảm số kết nối trên mỗi môi trường thực thi. Khi Lambda co giãn lên 500 lời gọi đồng thời, đó vẫn là 500 môi trường, mỗi cái giữ một kết nối:

Không có proxy:  500 Lambda đồng thời → 500 kết nối tới Aurora
Có RDS Proxy:    500 Lambda → RDS Proxy → vài chục kết nối thật tới Aurora

RDS Proxy còn xử lý một việc quan trọng khác: khi Aurora chuyển dự phòng, proxy giữ kết nối phía client trong lúc nối lại phía sau, nên thời gian gián đoạn giảm mạnh.

Vì sao trỏ vào reader endpoint. Đề nói ứng dụng truy vấn và cụm có ba read replica. Reader endpoint tự phân tải giữa chúng.

⚠ Kết nối tái sử dụng có thể chết giữa các lời gọi — phải kiểm tra trước khi dùng:

Môi trường thực thi nằm im 20 phút
        ↓
    Aurora đóng kết nối nhàn rỗi, hoặc xảy ra chuyển dự phòng
        ↓
    Lời gọi tiếp theo dùng lại kết nối đã chết
        ↓
    → lỗi "MySQL server has gone away", ngẫu nhiên và khó tái hiện
        ↓
    → nên gọi ping/reconnect ở đầu handler

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

• A (dùng cluster endpoint của Aurora) — đây là phương án gần nhất và nó chạm đúng chủ đề endpoint, thứ thật sự quan trọng với Aurora. Nhưng nó đi sai hướng: cluster endpoint luôn trỏ tới instance ghi, nên chuyển sang nó sẽ dồn toàn bộ truy vấn đọc vào một máy duy nhất và bỏ phí cả ba read replica. Với một ứng dụng đang quá tải, đây là thay đổi làm mọi thứ tệ hơn. Quan trọng hơn: nó không đụng gì tới nguyên nhân đã được nêu — số lượng kết nối. Đổi endpoint không làm giảm một kết nối nào.

• B (Gateway Load Balancer phân tải giữa ba read replica) — sai dịch vụ hoàn toàn. Gateway Load Balancer dùng để chèn thiết bị bảo mật ảo (tường lửa, IDS) vào đường đi của gói tin ở tầng 3, sử dụng giao thức GENEVE. Nó không phải bộ cân bằng tải cho cơ sở dữ liệu. Và việc phân tải giữa các replica đã có sẵn ở reader endpoint của Aurora, không cần thêm gì.

• D (chuyển sang Aurora Serverless với tự động co giãn) — thay đổi lớn về kiến trúc để né một vấn đề có cách sửa trực tiếp. Aurora Serverless co giãn dung lượng tính toán, nhưng vấn đề của đề không phải thiếu CPU — mà là quá nhiều kết nối. Serverless v1 thậm chí còn có điểm dừng để co giãn gây gián đoạn kết nối. Nó cũng không rẻ hơn cho tải ổn định có đỉnh.

Ghi nhớ

⚠ Bốn mẫu tối ưu Lambda + cơ sở dữ liệu — bảng phải thuộc: | Mẫu | Việc | |---|---| | Khởi tạo ngoài handler | tái sử dụng kết nối, client SDK, cấu hình đã đọc | | RDS Proxy | gom kết nối, chịu được chuyển dự phòng | | Biến môi trường + Secrets Manager | không hard-code thông tin đăng nhập | | Data API (Aurora Serverless) | gọi qua HTTP, không cần quản lý kết nối gì cả |

Từ khoá nhận diện:

"opens many database connections" + Lambda → RDS Proxy + khởi tạo ngoài handler "read replicas" + truy vấn đọc → reader endpoint "cluster endpoint" cho tải đọc → SAI, dồn hết về instance ghi "Gateway Load Balancer" cho CSDL → LUÔN SAI, đó là để chèn thiết bị bảo mật "cold start" → provisioned concurrency, khác bài toán này

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Số kết nối thật tới CSDL | chỉ số DatabaseConnections của Aurora | | Có tái sử dụng môi trường không | so Init Duration với tổng số lời gọi trong log | | Proxy có gom hiệu quả không | so số kết nối phía client với phía CSDL trong bảng điều khiển proxy |

Và một lời khuyên: hãy theo dõi DatabaseConnections như một chỉ số hạng nhất, đặt cảnh báo ở mức 80% max_connections. Đây là chỗ hệ thống sụp đổ đột ngột sau một thời gian dài trông hoàn toàn khoẻ mạnh: số kết nối tăng tuyến tính theo mức co giãn của Lambda, và trong suốt quá trình đó không có triệu chứng nào — truy vấn vẫn nhanh, CPU vẫn thấp, tỷ lệ lỗi vẫn bằng 0. Rồi tới một đợt cao điểm, số kết nối chạm trần, và từ giây đó mọi lời gọi mới đều bị từ chối ngay ở bước kết nối. Sự cố không tăng dần mà bật lên như một công tắc, và nó xảy ra ở đúng thời điểm tải cao nhất — nghĩa là ở thời điểm tệ nhất để bắt đầu tìm hiểu vì sao.

Đáp án

C, E — hai mẫu di chuyển giảm được cả phí bản quyền lẫn công vận hành:

• C — Chuyển Oracle data warehouse sang Amazon Redshift bằng AWS SCT và AWS DMS.
• E — Chuyển các cơ sở dữ liệu MySQL sang Amazon RDS for MySQL bằng AWS DMS.

Vì sao đúng

Đề nêu hai tiêu chí: giảm chi phí bản quyền và giảm công vận hành. Hai tiêu chí này quyết định phải đi xa hơn "bê nguyên lên cloud".

⚠ Điểm mấu chốt: đổi engine thì cần SCT, cùng engine thì chỉ cần DMS:

Oracle → Redshift: hai engine KHÁC NHAU
        ↓
    Kiểu dữ liệu, thủ tục lưu, cú pháp SQL đều khác
        ↓
    → AWS SCT chuyển đổi LƯỢC ĐỒ và mã trước
        ↓
    → rồi DMS chuyển DỮ LIỆU

MySQL → RDS for MySQL: CÙNG engine
        ↓
    Lược đồ tương thích sẵn
        ↓
    → chỉ cần DMS

Đây là lý do phương án C nhắc cả hai công cụ còn E chỉ nhắc DMS — và sự khác biệt đó không phải ngẫu nhiên.

Vì sao Redshift là đích đúng cho data warehouse. Đề nói rõ đó là data warehouse, tức là tải phân tích: quét lớn, tổng hợp, ít ghi. Redshift là kho dữ liệu dạng cột được thiết kế cho đúng hình thái đó. Chuyển sang RDS for PostgreSQL cũng bỏ được bản quyền Oracle nhưng sẽ cho hiệu năng phân tích kém hơn nhiều vì đó là CSDL dạng dòng.

# DMS: sao chép đầy đủ rồi bám theo thay đổi (CDC) để cắt chuyển gần như không downtime
aws dms create-replication-task \
  --replication-task-identifier oracle-sang-redshift \
  --source-endpoint-arn <oracle> --target-endpoint-arn <redshift> \
  --migration-type full-load-and-cdc \
  --table-mappings file://anh-xa-bang.json

⚠ SCT sinh ra báo cáo đánh giá — phần "không tự chuyển được" mới là phần tốn công thật:

SCT quét lược đồ Oracle
        ↓
    Phần lớn bảng và view chuyển tự động
        ↓
    Nhưng PL/SQL phức tạp, package, trigger thường phải viết lại tay
        ↓
    → đọc báo cáo đánh giá TRƯỚC khi cam kết thời hạn dự án

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

• B (bê nguyên Oracle data warehouse lên EC2 bằng AWS Snowball) — đây là phương án gần nhất và nó là một con đường di chuyển hoàn toàn hợp lệ: rehost lên EC2 là mẫu chuẩn khi cần chuyển nhanh, và Snowball đúng là cách đưa khối dữ liệu lớn lên. Nhưng nó thất bại ở cả hai tiêu chí đề nêu. Về bản quyền: chạy Oracle trên EC2 vẫn phải trả phí bản quyền Oracle — thậm chí mô hình cấp phép trên đám mây có thể đắt hơn. Về vận hành: bạn vẫn tự vá hệ điều hành, tự vá Oracle, tự lo sao lưu, tự lo tính sẵn sàng cao — không giảm được gì. Đây là bẫy hay vì nó là câu trả lời đúng cho một câu hỏi khác ("cách nhanh nhất để rời trung tâm dữ liệu").

• D (bê nguyên MySQL lên EC2 bằng Snowball) — cùng lỗi ở vế vận hành. MySQL không tốn phí bản quyền nên vế đó không đổi, nhưng chạy trên EC2 nghĩa là tự quản toàn bộ: vá lỗi, sao lưu, chuyển dự phòng, giám sát. RDS làm sẵn tất cả những việc đó.

• A (chuyển Oracle data warehouse sang ElastiCache for Redis bằng DMS) — sai hoàn toàn về loại kho dữ liệu. ElastiCache for Redis là bộ nhớ đệm trong RAM, dùng để tăng tốc truy cập dữ liệu nóng — nó không phải kho dữ liệu phân tích, không chạy SQL phân tích, và không lưu trữ bền vững theo cách một data warehouse cần. Chuyển một kho dữ liệu hàng terabyte vào Redis là điều không có ý nghĩa cả về kỹ thuật lẫn chi phí.

Ghi nhớ

⚠ Bảy chiến lược di chuyển (7R) — bảng phải thuộc: | Chiến lược | Nghĩa | Giảm bản quyền | |---|---|---| | Rehost | bê nguyên lên EC2 | không | | Replatform | sửa nhẹ, ví dụ MySQL → RDS | một phần | | Refactor / Re-architect | đổi engine, ví dụ Oracle → Redshift | có | | Repurchase | mua giải pháp SaaS khác | có | | Retire / Retain / Relocate | bỏ / giữ / chuyển nguyên khối | — |

Từ khoá nhận diện:

"reduce licensing costs" → phải rời khỏi engine thương mại, không chỉ đổi chỗ chạy "reduce operational overhead" → dịch vụ có quản lý, không phải EC2 "data warehouse" → Redshift "lift and shift Oracle to EC2" khi đề đòi giảm bản quyền → LUÔN SAI "Oracle → ElastiCache" → LUÔN SAI, sai loại kho dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bao nhiêu phần trăm lược đồ tự chuyển được | báo cáo đánh giá của SCT | | Dữ liệu có khớp không | bật DMS data validation, xem bảng thống kê | | Độ trễ CDC | chỉ số CDCLatencySource và CDCLatencyTarget |

Và một lời khuyên: hãy bật tính năng đối chiếu dữ liệu của DMS và đọc bảng kết quả từng bảng, đừng chỉ nhìn trạng thái "Load complete". Đây là chỗ dữ liệu sai lệch trượt qua mà không ai biết: DMS báo tác vụ hoàn thành, số bảng khớp, log không có lỗi — nhưng các dòng có kiểu dữ liệu không ánh xạ được, ký tự ngoài bộ mã đích, hoặc giá trị vượt độ chính xác của cột mới thì bị cắt bớt hoặc bỏ qua chứ không làm tác vụ thất bại. Với một kho dữ liệu, hệ quả không phải là một lỗi rõ ràng mà là những con số báo cáo lệch đi vài phần trăm — thứ mà không ai phát hiện cho tới khi có người đối chiếu một báo cáo cũ và không hiểu vì sao doanh thu quý trước đã thay đổi.

Đáp án

B — Kiểm tra security group của các EC2 instance, đảm bảo nó cho phép lưu lượng vào từ văn phòng khách hàng.

Vì sao đúng

Câu này xoay quanh một đặc điểm của Network Load Balancer mà rất nhiều người hiểu sai: khi target được đăng ký theo instance-id, NLB giữ nguyên IP nguồn của khách. Vì thế security group của EC2 nhìn thấy địa chỉ của người dùng thật, không nhìn thấy địa chỉ của bộ cân bằng tải.

⚠ Điểm mấu chốt: NLB giữ nguyên IP nguồn, nên security group của EC2 nhìn thấy IP của KHÁCH chứ không phải IP của NLB:

Khách ở văn phòng, IP công cộng 203.0.113.10
        ↓
    Kết nối tới NLB
        ↓
    NLB chuyển tiếp, GIỮ NGUYÊN IP nguồn 203.0.113.10
        ↓
    EC2 nhận gói tin có source = 203.0.113.10
        ↓
    → security group của EC2 phải cho phép 203.0.113.10, không phải cho phép NLB

Đây là khác biệt căn bản với Application Load Balancer. ALB kết thúc kết nối rồi mở kết nối mới tới target, nên EC2 thấy IP của ALB và security group phải cho phép security group của ALB. Với NLB đăng ký theo instance-id thì hoàn toàn ngược lại — và đó chính là lý do rất nhiều người áp thói quen từ ALB sang rồi mắc kẹt.

Chi tiết health check xanh là manh mối bị bỏ qua nhiều nhất. Health check của NLB xuất phát từ chính các node NLB, có IP thuộc dải subnet của NLB. Nếu security group của EC2 cho phép dải subnet đó nhưng không cho phép IP của khách, ta có đúng bức tranh của đề: health check qua, người dùng thật bị chặn.

# xem security group của EC2 đang cho ai vào
aws ec2 describe-security-groups --group-ids sg-ec2-app \
  --query 'SecurityGroups[0].IpPermissions'

# mở cho dải IP của văn phòng khách
aws ec2 authorize-security-group-ingress --group-id sg-ec2-app \
  --protocol tcp --port 443 --cidr 203.0.113.0/24

⚠ Đăng ký theo instance-id và theo IP cho ra hành vi khác nhau: | Kiểu đăng ký target | EC2 thấy IP nguồn là | |---|---| | Instance ID | IP thật của khách | | IP address | IP riêng của node NLB |

Đây là điều nhiều người không biết, và nó đổi hoàn toàn cách viết security group.

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

• C (kiểm security group của EC2 cho phép vào từ các subnet của NLB) — đây là phương án gần nhất và nó gần như đúng, chỉ sai về nguồn cần cho phép: đúng là phải sửa security group của EC2 chứ không phải của NLB, và với kiểu đăng ký theo IP address thì đây sẽ là câu trả lời chính xác. Nhưng đề nói rõ target được đăng ký theo instance-id, nghĩa là IP nguồn được giữ nguyên và EC2 nhìn thấy IP của khách. Cho phép dải subnet của NLB thì chỉ đủ để health check thành công — đúng như hiện trạng đề mô tả — mà vẫn chặn lưu lượng thật của người dùng. Đây là bẫy tinh vi nhất của câu hỏi vì nó khớp hoàn hảo với triệu chứng "health check xanh nhưng khách không vào được", chỉ có điều nó mô tả nguyên nhân chứ không phải cách chữa.

• A (kiểm security group của NLB cho phép vào từ security group của EC2) — sai chiều. Lưu lượng đi từ khách qua NLB tới EC2, không đi từ EC2 ngược lên NLB, nên cho phép security group của EC2 làm nguồn là vô nghĩa. Ngoài ra, trong kiến trúc này NLB thường không gắn security group nào cả (khả năng gắn security group cho NLB chỉ có từ tháng 8/2023 và phải bật khi tạo), nên đây gần như chắc chắn không phải nơi cần sửa.

• D (kiểm security group của NLB cho phép vào từ chính Elastic IP của NLB) — vô nghĩa về mặt luồng lưu lượng: lưu lượng đến từ khách hàng, không đến từ chính bộ cân bằng tải. Và cũng như phương án A, nó đi tìm vấn đề ở một security group nhiều khả năng không tồn tại, trong khi thứ đang chặn nằm ở phía EC2.

Ghi nhớ

⚠ Bốn khác biệt giữa ALB và NLB về mạng — bảng phải thuộc: | | ALB | NLB | |---|---|---| | Tầng | 7 (HTTP/HTTPS) | 4 (TCP/UDP/TLS) | | Security group | bắt buộc có | tuỳ chọn — trước 8/2023 thì không có | | IP nguồn tại target | IP của ALB | IP thật của khách (nếu đăng ký theo instance-id) | | Địa chỉ | tên miền, IP thay đổi | Elastic IP tĩnh mỗi AZ |

Từ khoá nhận diện:

"NLB" + "registered by instance-id" → IP nguồn được giữ nguyên "targets are healthy but customers cannot connect" → health check qua, lưu lượng thật bị chặn "allow ingress from the NLB subnets" khi đăng ký theo instance-id → chỉ đủ cho health check ALB + target không nhận được lưu lượng → cho phép security group của ALB security group của NLB cho phép chính Elastic IP của nó → vô nghĩa về luồng lưu lượng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | EC2 thấy IP nguồn nào | đọc log web server trên chính máy đó | | Gói tin có tới không | VPC Flow Logs, tìm bản ghi REJECT | | Rule đang cho ai vào | describe-security-groups trên SG của EC2 |

Và một lời khuyên: hãy đọc log của web server trên chính EC2 để xem IP nguồn nó thật sự nhận được, đừng suy luận từ sơ đồ kiến trúc. Đây là chỗ hiểu nhầm dai dẳng nhất về NLB, và nó khó phát hiện chính vì hệ thống trông hoàn toàn khoẻ mạnh: target group xanh, health check qua đều, NLB báo active, không có lỗi nào ở bất kỳ đâu. Mọi chỉ số bạn quen theo dõi đều nói rằng bộ cân bằng tải đang hoạt động bình thường — bởi vì đúng là nó đang hoạt động bình thường. Thứ duy nhất không hoạt động là kết nối của người dùng thật, và họ không xuất hiện trong bất kỳ chỉ số nào vì gói tin của họ bị vứt bỏ trước khi tới được ứng dụng.

Đáp án

B, D, E — ba bước cho ứng dụng game UDP một instance, mức bảo mật cao:

• B — Đặt Network Load Balancer trước instance, trỏ bản ghi Route 53 thân thiện tới Elastic IP của NLB.
• D — Bật AWS Shield Advanced trên mọi tài nguyên phơi ra Internet.
• E — Đặt network ACL chặn mọi lưu lượng không phải UDP, gắn vào subnet chứa bộ cân bằng tải.

Vì sao đúng

Ba từ khoá của đề dẫn tới ba lựa chọn: UDP, một instance, mức bảo mật cao.

⚠ Điểm mấu chốt: ALB KHÔNG xử lý được UDP — đây là điều loại thẳng phương án C:

ALB hoạt động ở tầng 7, chỉ hiểu HTTP/HTTPS/gRPC
        ↓
    Game dùng UDP — không phải HTTP
        ↓
    → ALB không có listener UDP, không có cách nào cấu hình
        ↓
    NLB ở tầng 4: hỗ trợ TCP, UDP, TLS, TCP_UDP

D — vì sao Shield Advanced chứ không phải Shield Standard. Shield Standard bật sẵn miễn phí cho mọi khách hàng và chống được các tấn công tầng 3/4 phổ biến. Shield Advanced thêm những thứ mà một dịch vụ game công khai thật sự cần:

Dịch vụ game qua UDP là mục tiêu DDoS điển hình — đặc biệt là tấn công khuếch đại UDP — nên đây không phải lựa chọn thừa.

E — vì sao network ACL chứ không phải WAF. Lọc theo giao thức là việc của tầng mạng. Network ACL hoạt động ở tầng 3/4 và chặn được theo số hiệu giao thức:

# chỉ cho UDP vào subnet của bộ cân bằng tải
aws ec2 create-network-acl-entry --network-acl-id acl-abc \
  --rule-number 100 --protocol 17 --port-range From=7777,To=7777 \
  --cidr-block 0.0.0.0/0 --rule-action allow --ingress

⚠ Network ACL KHÔNG có trạng thái — phải mở cả chiều ra cho cổng ephemeral:

Chỉ tạo rule ingress cho UDP
        ↓
    Gói trả lời đi ra bị chặn vì thiếu rule egress
        ↓
    → kết nối không bao giờ hoàn tất, mà không có lỗi rõ ràng
        ↓
    → phải mở egress cho dải cổng ephemeral 1024–65535

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

• A (AWS Global Accelerator với một Elastic Load Balancer làm endpoint) — đây là phương án gần nhất và Global Accelerator thật sự rất hợp với game qua UDP: nó hỗ trợ UDP, cho địa chỉ anycast tĩnh, giảm độ trễ bằng cách đưa lưu lượng vào mạng AWS sớm, và có Shield Advanced đi kèm. Nhưng nó không nằm trong bộ ba đúng vì hai lý do. Thứ nhất, đề mô tả một instance duy nhất trong một Region — lợi ích chính của Global Accelerator là định tuyến toàn cầu tới nhiều điểm cuối ở nhiều Region, nên phần lớn giá trị của nó không được dùng tới. Thứ hai, câu hỏi đòi chọn ba bước và ba phương án kia đã phủ trọn yêu cầu; thêm Global Accelerator là chồng thêm một lớp (và một khoản chi phí) mà không giải quyết yêu cầu nào còn thiếu.

• C (ALB trước instance, Route 53 trỏ tới FQDN của ALB) — sai dứt khoát: ALB không hỗ trợ UDP. Đây là điểm loại rõ ràng nhất trong cả câu hỏi. Không có cấu hình nào khiến ALB chuyển tiếp được lưu lượng UDP.

• F (luật AWS WAF loại bỏ lưu lượng không phải UDP, gắn vào bộ cân bằng tải) — sai ở hai tầng cùng lúc. WAF chỉ xét lưu lượng HTTP/HTTPS ở tầng 7 — nó không nhìn thấy và không lọc được gói UDP. Và WAF không gắn được vào NLB; các đích hợp lệ chỉ gồm CloudFront, ALB, API Gateway, AppSync, Cognito và App Runner.

Ghi nhớ

⚠ Bốn loại bộ cân bằng tải — bảng phải thuộc, chú ý cột giao thức: | Loại | Tầng | Giao thức | Địa chỉ | |---|---|---|---| | ALB | 7 | HTTP, HTTPS, gRPC — KHÔNG có UDP | tên miền | | NLB | 4 | TCP, UDP, TLS, TCP_UDP | Elastic IP tĩnh | | Gateway LB | 3 | GENEVE — chèn thiết bị bảo mật | endpoint | | Classic LB | 4 và 7 | thế hệ cũ | tên miền |

Từ khoá nhận diện:

"UDP" → NLB, loại ngay ALB "static IP address" → NLB (Elastic IP) hoặc Global Accelerator (anycast) "high level of security" + phơi ra Internet → Shield Advanced "block all non-UDP traffic" → network ACL (tầng 4), không phải WAF "WAF rule to drop non-UDP traffic" → LUÔN SAI, WAF chỉ xét HTTP và không gắn được vào NLB

Ba việc kiểm chứng: | Việc | Cách | |---|---| | UDP có thông không | nc -u <dia-chi> <cong> từ máy ngoài | | NACL có chặn nhầm chiều về không | VPC Flow Logs, tìm REJECT ở cổng ephemeral | | Shield có đang bảo vệ đúng tài nguyên không | kiểm danh sách protected resources |

Và một lời khuyên: hãy mở rule egress cho dải cổng ephemeral 1024–65535 ngay khi bạn viết rule ingress đầu tiên trong network ACL. Đây là lỗi cấu hình gây mất thời gian nhiều nhất với NACL, và nó gây nhầm lẫn vì triệu chứng trông không giống một vấn đề tường lửa chút nào: gói tin của người chơi có tới máy chủ, ứng dụng có xử lý và có gửi trả lời — mọi log phía máy chủ đều bình thường, không có gì bị từ chối ở chiều vào. Chỉ có gói trả lời là biến mất trên đường ra, nên phía người chơi thấy kết nối treo rồi hết thời gian chờ. Bạn sẽ đi tìm lỗi trong mã game rất lâu trước khi nghĩ tới việc một danh sách kiểm soát truy cập không trạng thái đang chặn đúng một nửa cuộc hội thoại.

Đáp án

B — Dùng AWS DataSync đặt lịch tác vụ hằng ngày sao chép dữ liệu giữa file share tại chỗ và Amazon FSx.

Vì sao đúng

Đề có ba dữ kiện quyết định: máy chủ Windows, file share SMB, và cần một hệ thống tệp trên AWS. Chỉ một cặp công cụ khớp cả ba.

⚠ Điểm mấu chốt: DataSync chỉ chuyển phần THAY ĐỔI sau lần chạy đầu, nên tác vụ hằng ngày rất rẻ:

Lần chạy đầu: quét và chuyển toàn bộ
        ↓
    Các lần sau: so sánh metadata, chỉ chuyển tệp mới hoặc đã sửa
        ↓
    Vài GB mỗi ngày → mỗi lần chạy chỉ chuyển đúng phần đó
        ↓
    → tự xác minh checksum, tự thử lại, nhanh hơn rsync nhiều lần

Vì sao FSx for Windows File Server chứ không phải EFS. Đây là điểm phân biệt quan trọng nhất:

Ứng dụng Windows dùng SMB. EFS chỉ nói NFS — máy Windows về lý thuyết gắn được nhưng mất ACL, mất tích hợp AD, và không phải cách AWS khuyến nghị.

aws datasync create-task \
  --source-location-arn <smb-tai-cho> \
  --destination-location-arn <fsx-windows> \
  --schedule ScheduleExpression="cron(0 2 * * ? *)" \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,PreserveDdeviceTime=NONE

⚠ DataSync cần một agent chạy tại chỗ để đọc file share nguồn:

Agent là một máy ảo triển khai trong VMware/Hyper-V tại trung tâm dữ liệu
        ↓
    Nó đọc SMB share rồi đẩy qua Internet hoặc Direct Connect
        ↓
    → thiếu bước này thì không có tác vụ nào chạy được

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

• A (Storage Gateway file gateway, trỏ máy chủ ứng dụng tại chỗ vào gateway mới) — đây là phương án gần nhất và file gateway thật sự phục vụ SMB, đúng giao thức. Nhưng nó giải một bài toán khác: file gateway là giải pháp lưu trữ lai lâu dài — dữ liệu nằm trong S3 dưới dạng object, gateway giữ bản đệm cục bộ và ứng dụng tại chỗ tiếp tục truy cập qua gateway. Đề nói công ty đang di chuyển lên cloud và cần dữ liệu "accessible on a file system in the AWS cloud", tức là đích đến là một hệ thống tệp trên AWS chứ không phải S3 nhìn qua một cửa sổ. Phương án này cũng giữ nguyên sự phụ thuộc vào thiết bị tại chỗ, đi ngược mục tiêu di chuyển.

• C (Storage Gateway volume gateway) — sai loại lưu trữ. Volume gateway phơi ra khối lưu trữ iSCSI, không phải file share. Ứng dụng đang dùng file share dùng chung giữa nhiều máy chủ; một volume iSCSI chỉ gắn được cho một máy tại một thời điểm và không có ngữ nghĩa chia sẻ tệp.

• D (AWS Data Pipeline sao chép sang Amazon EFS) — sai ở cả hai vế. Data Pipeline là dịch vụ điều phối ETL cho dữ liệu có cấu trúc (S3, RDS, DynamoDB, EMR) — nó không phải công cụ đồng bộ file share, và đã ngừng nhận khách hàng mới. Vế EFS thì lặp lại lỗi giao thức: NFS cho ứng dụng Windows.

Ghi nhớ

⚠ Bốn dịch vụ lưu trữ tệp của AWS — bảng phải thuộc: | Dịch vụ | Giao thức | Dành cho | |---|---|---| | FSx for Windows File Server | SMB | Windows, cần ACL và AD | | FSx for Lustre | POSIX, Lustre | HPC, tính toán hiệu năng cao | | FSx for NetApp ONTAP | NFS + SMB + iSCSI | môi trường lai đa giao thức | | EFS | NFS | Linux |

Từ khoá nhận diện:

"Windows servers" + "file share" → FSx for Windows File Server "migrate data to a file system in AWS" → DataSync "Linux" + file system dùng chung → EFS "HPC" / "tightly coupled" → FSx for Lustre "Data Pipeline để đồng bộ file share" → SAI, đó là ETL và đã ngừng nhận khách mới

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tác vụ có chạy đúng lịch không | lịch sử thực thi trong console DataSync | | Dữ liệu có khớp không | báo cáo của DataSync — số tệp, số byte, số tệp bỏ qua | | Máy Windows có gắn được FSx không | net use Z: \\<dns-fsx>\share từ chính máy đó |

Và một lời khuyên: hãy đọc phần "Files skipped" trong báo cáo mỗi lần chạy DataSync, đừng chỉ nhìn trạng thái Success. Đây là chỗ dữ liệu bị bỏ lại một cách lặng lẽ: tệp đang bị khoá bởi một tiến trình khác, tệp có ký tự đường dẫn không hợp lệ ở đích, tệp vượt giới hạn độ dài đường dẫn — tất cả đều bị bỏ qua chứ không làm tác vụ thất bại. Tác vụ báo Success, tổng dung lượng trông gần đúng, và bạn tin rằng bản sao đã đầy đủ. Với dữ liệu tài liệu doanh nghiệp thì những tệp bị khoá thường lại chính là những tệp đang được dùng nhiều nhất.

Đáp án

B — Thêm Aurora Replica và đặt scaling policy; dùng Application Load Balancer với thuật toán phân tải round_robin.

Vì sao đúng

Câu này có hai lựa chọn phải quyết cùng lúc, và cả hai đều bị chi phối bởi một chữ trong đề: ứng dụng có stateful servers.

⚠ Điểm mấu chốt: máy chủ có trạng thái đòi sticky session, và sticky session chỉ chạy với round_robin:

Ứng dụng stateful — phiên nằm trên từng máy
        ↓
    Người dùng phải luôn quay lại đúng máy đó → cần sticky session
        ↓
    Sticky session là tính năng của ALB (cookie), NLB không có theo cách này
        ↓
    Và ALB chỉ hỗ trợ sticky session với thuật toán round_robin
        ↓
    → bật least_outstanding_requests cùng sticky session sẽ không được chấp nhận

Đây là ràng buộc kỹ thuật cụ thể mà câu hỏi đang kiểm tra. Hai phương án C và D đều chọn least_outstanding_requests — một thuật toán tốt hơn về mặt phân bổ tải, nhưng không tương thích với thứ ứng dụng này cần.

Vì sao ALB chứ không NLB. NLB hoạt động ở tầng 4, không đọc được cookie, nên không làm sticky session dựa trên cookie. Nó có "sticky" dựa trên IP nguồn nhưng đó là cơ chế thô hơn nhiều và không phải thứ đề mô tả.

# bật sticky session trên target group của ALB
aws elbv2 modify-target-group-attributes --target-group-arn <arn> \
  --attributes Key=stickiness.enabled,Value=true \
               Key=stickiness.type,Value=lb_cookie \
               Key=stickiness.lb_cookie.duration_seconds,Value=86400

# thuật toán phải là round_robin
aws elbv2 modify-target-group-attributes --target-group-arn <arn> \
  --attributes Key=load_balancing.algorithm.type,Value=round_robin

Về tầng cơ sở dữ liệu: cả bốn phương án đều nói "thêm Aurora Replica và đặt scaling policy" — đó là phần chung, không phân biệt. Aurora Auto Scaling tự thêm bớt replica theo tải, và reader endpoint tự phân tải giữa chúng.

⚠ Sticky session là giải pháp tạm — cách đúng là bỏ trạng thái khỏi máy chủ:

Sticky session giữ người dùng ở đúng một máy
        ↓
    Máy đó chết → người dùng vẫn mất phiên
        ↓
    Tải phân bổ lệch vì phiên dài bám vào một số máy
        ↓
    → giải pháp bền là đưa phiên ra ElastiCache hoặc DynamoDB

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

• C (ALB với least_outstanding_requests) — đây là phương án gần nhất và nó chọn đúng loại bộ cân bằng tải; hơn nữa least_outstanding_requests nói chung là thuật toán tốt hơn round_robin vì nó gửi request tới target đang rảnh nhất, tránh được tình trạng một máy nhận toàn request nặng. Nó chỉ vướng đúng một ràng buộc: không dùng chung được với sticky session, mà ứng dụng stateful thì bắt buộc cần sticky session. Đây là bẫy hay vì phương án này thưởng cho người biết thuật toán nào tốt hơn, rồi phạt vì đã bỏ qua chữ "stateful" ở đầu đề.

• A (NLB với round_robin) — chọn đúng thuật toán nhưng sai loại bộ cân bằng tải. NLB ở tầng 4 không làm sticky session bằng cookie, nên không đảm bảo người dùng quay lại đúng máy giữ phiên của họ. NLB cũng thiếu các tính năng tầng 7 mà một ứng dụng web thường cần: định tuyến theo đường dẫn, theo host header, tích hợp WAF.

• D (NLB với least_outstanding_requests) — sai cả hai. Ngoài vấn đề của A, least_outstanding_requests không phải là tuỳ chọn của NLB — đó là thuộc tính của target group thuộc ALB. Phương án này mô tả một cấu hình không tồn tại.

Ghi nhớ

⚠ Bốn khác biệt ALB và NLB — bảng phải thuộc: | | ALB | NLB | |---|---|---| | Tầng | 7 | 4 | | Sticky session bằng cookie | có | không | | Thuật toán | round_robin, least_outstanding_requests, weighted_random | flow hash | | Định tuyến theo host/path | có | không | | Gắn WAF | được | không |

Từ khoá nhận diện:

"stateful servers" → cần sticky session → ALB "sticky session" → chỉ dùng được với round_robin "least_outstanding_requests" khi ứng dụng stateful → SAI, xung khắc với sticky session "NLB" + sticky session bằng cookie → LUÔN SAI "seamless scalability" cho tầng dữ liệu → Aurora Replica + Auto Scaling

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sticky session có hoạt động không | gửi nhiều request cùng cookie, xem có về một target không | | Tải có lệch không | chỉ số RequestCount theo từng target | | Replica có tự thêm không | lịch sử scaling của Application Auto Scaling |

Và một lời khuyên: hãy theo dõi RequestCount theo từng target chứ đừng chỉ nhìn tổng của bộ cân bằng tải. Sticky session tạo ra một dạng lệch tải mà tổng số liệu che mất hoàn toàn: nếu một số phiên sống rất lâu và nặng hơn hẳn, chúng sẽ dồn lên vài máy trong khi các máy khác gần như rảnh. Tổng số request vẫn tăng đều, CPU trung bình của Auto Scaling group vẫn trông bình thường, nên hệ thống không co giãn lên — trong khi vài máy cụ thể đang chạm trần và người dùng bám vào chúng thì chịu độ trễ cao. Chỉ có số liệu theo từng target mới cho thấy điều đó.