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

Đáp án

**B — API Gateway tạo REST API cho giao tiếp KHÔNG TRẠNG THÁI giữa client và server, và tạo WebSocket API theo giao thức WebSocket, cho giao tiếp CÓ TRẠNG THÁI, song công toàn phần.

Vì sao đúng

Câu này kiểm tra hai thuộc tính, và chỉ một tổ hợp đúng: | Kiểu API | Trạng thái | Chiều | |---|---|---| | REST | KHÔNG trạng thái | client hỏi, server đáp | | WebSocket | CÓ trạng thái | song công toàn phần |

⚠ REST không trạng thái là nguyên tắc kiến trúc, không phải chi tiết cài đặt:

Mỗi yêu cầu chứa ĐỦ thông tin để
  xử lý
        ↓
    Server không nhớ gì giữa các
      yêu cầu
        ↓
    Nhờ vậy mở rộng ngang được:
      máy nào phục vụ cũng như nhau

⚠ Và WebSocket có trạng thái vì nó GIỮ kết nối:

Bắt tay HTTP Upgrade một lần
        ↓
    Kết nối TCP giữ MỞ
        ↓
    Server nhớ `connectionId` của
      từng client
    → đó chính là trạng thái

⚠ Và "song công toàn phần" nghĩa là hai bên gửi cùng lúc: | Kiểu | Chiều dữ liệu | |---|---| | Đơn công | một chiều duy nhất | | Bán song công | hai chiều, nhưng lần lượt | | Song công toàn phần | hai chiều CÙNG LÚC |

HTTP: client hỏi xong mới có đáp
        ↓
    WebSocket: server đẩy tin bất
      cứ lúc nào, client cũng gửi
      bất cứ lúc nào

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

A: nói WebSocket KHÔNG trạng thái
    → sai vế WebSocket
        ↓
C: nói REST CÓ trạng thái và
  WebSocket không
    → sai cả hai
        ↓
D: nói REST CÓ trạng thái
    → sai vế REST

Tạo WebSocket API:

aws apigatewayv2 create-api \
  --name kenh-thoi-gian-thuc \
  --protocol-type WEBSOCKET \
  --route-selection-expression '$request.body.action'

⚠ WebSocket API có ba route hệ thống bắt buộc biết: | Route | Khi nào gọi | |---|---| | $connect | client mở kết nối | | $disconnect | client đóng kết nối | | $default | tin nhắn không khớp route nào |

def xu_ly_ket_noi(event, context):
    ma = event['requestContext']['connectionId']
    bang.put_item(Item={'ma_ket_noi': ma,
                        'het_han': int(time.time()) + 7200})
    return {'statusCode': 200}

⚠ Và đây chính là chỗ "có trạng thái" thể hiện:

Phải LƯU danh sách connectionId
        ↓
    Vào DynamoDB hoặc ElastiCache
        ↓
    Muốn đẩy tin cho ai thì tra
      bảng đó
    → REST API không có khái niệm này

Đẩy tin về client:

apigw = boto3.client('apigatewaymanagementapi',
                     endpoint_url=f'https://{mien}/{giai_doan}')
try:
    apigw.post_to_connection(ConnectionId=ma,
                             Data=json.dumps(tin).encode())
except apigw.exceptions.GoneException:
    bang.delete_item(Key={'ma_ket_noi': ma})

⚠ GoneException nghĩa là client đã ngắt — phải dọn:

Client đóng trình duyệt đột ngột
        ↓
    `$disconnect` có thể không chạy
        ↓
    Bảng kết nối tích luỹ mục chết
    → đặt TTL và dọn khi gặp
      GoneException

⚠ Và cần phân biệt "stateless" của REST với session của ứng dụng:

REST không trạng thái ở TẦNG
  GIAO THỨC
        ↓
    Ứng dụng vẫn có phiên đăng nhập
        ↓
    Nhưng trạng thái đó nằm trong
      TOKEN mà client gửi kèm
    → hoặc trong kho ngoài
      (DynamoDB, ElastiCache)
        ↓
    Server không tự nhớ

⚠ Và ba kiểu API của API Gateway: | Kiểu | Giao thức | Dùng khi | |---|---|---| | REST API | HTTP | đầy đủ tính năng: API key, cache, WAF | | HTTP API | HTTP | rẻ hơn, nhanh hơn, ít tính năng | | WebSocket API | WebSocket | hai chiều, thời gian thực |

Ba lợi ích của WebSocket API: | Lợi ích | Chi tiết | |---|---| | Server đẩy tin không cần client hỏi | | | Một kết nối cho nhiều tin nhắn | | | API Gateway quản lý kết nối, không tự dựng máy chủ | |

⚠ Và so với hỏi vòng thì khác biệt rất lớn:

1.000 client hỏi mỗi 3 giây
        ↓
    20.000 lời gọi/phút, phần lớn
      trả về rỗng
        ↓
    WebSocket: 1.000 kết nối im lặng
    → chỉ tốn khi có tin thật

⚠ Nhưng WebSocket có giới hạn phải nhớ: | Giới hạn | Giá trị | |---|---| | Thời gian kết nối tối đa | 2 giờ | | Thời gian rảnh tối đa | 10 phút | | Kích thước khung | 32 KB |

Kết nối tự đóng sau 2 giờ
        ↓
    Client phải tự kết nối lại
    → và khôi phục trạng thái

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

• **A. REST không trạng thái; WebSocket theo giao thức WebSocket cho giao tiếp không trạng thái, song công toàn phần — đây là phương án gần nhất và vế REST hoàn toàn đúng, nhưng WebSocket giữ kết nối mở và server phải nhớ connectionId, nên nó có trạng thái.
• **C. REST có trạng thái; WebSocket không trạng thái — sai cả hai vế.
• **D. REST có trạng thái; WebSocket có trạng thái — sai vế REST.

Ghi nhớ

⚠ Bốn cách giao tiếp thời gian thực trên AWS — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | API Gateway WebSocket | tự quản connectionId | | AppSync subscription | GraphQL, quản lý sẵn | | IoT Core MQTT | rất nhiều thiết bị, chủ đề phân cấp | | Hỏi vòng | đơn giản nhất, tốn kém nhất |

Từ khoá nhận diện:

"stateful, full-duplex" → WebSocket "stateless client-server" → REST "server pushes to client" → WebSocket hoặc AppSync "chat, live dashboard, multiplayer" → WebSocket

Ba lưu ý về WebSocket API: | Lưu ý | Chi tiết | |---|---| | Route selection expression chọn route theo nội dung | | | $connect có thể từ chối kết nối (authorizer) | | | Tính phí theo tin nhắn và phút kết nối | |

⚠ Xác thực ở $connect là chỗ đúng:

def uy_quyen(event, context):
    token = event['queryStringParameters'].get('token')
    if not hop_le(token):
        raise Exception('Unauthorized')
    return {'principalId': lay_ma_nguoi_dung(token),
            'policyDocument': {...}}

Kiểm tra một lần lúc kết nối
        ↓
    Các tin nhắn sau không phải
      xác thực lại

Ba lưu ý về quản lý kết nối: | Lưu ý | Chi tiết | |---|---| | Lưu connectionId vào DynamoDB với TTL | | | Dọn khi gặp GoneException | | | Nhóm kết nối theo phòng/chủ đề để phát tán | |

Ba lưu ý về mở rộng: | Lưu ý | Chi tiết | |---|---| | Đẩy tin cho hàng nghìn kết nối cần song song | | | Dùng SQS hoặc Step Functions để phát tán | | | AppSync làm sẵn việc này | |

⚠ Phát tán tuần tự là nút thắt:

10.000 kết nối, mỗi lời gọi
  post_to_connection mất 20 ms
        ↓
    200 giây để đẩy hết
        ↓
    Chia lô và gọi song song
    → hoặc dùng AppSync

Ba lưu ý về REST API: | Lưu ý | Chi tiết | |---|---| | API key và usage plan cho kiểm soát truy cập | | | Cache phản hồi giảm tải backend | | | Timeout tối đa 29 giây | |

Ba lưu ý về HTTP API: | Lưu ý | Chi tiết | |---|---| | Rẻ hơn REST API khoảng 70% | | | KHÔNG có API key, cache, WAF | | | Có JWT authorizer sẵn | |

Ba lưu ý về chi phí WebSocket: | Khoản | Cách tính | |---|---| | Tin nhắn | theo triệu tin (32 KB mỗi đơn vị) | | Thời lượng kết nối | theo triệu phút | | Lambda xử lý | GB-giây |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | wscat -c wss://... thử kết nối | | | Mở hai client, gửi tin từ một bên | | | Đóng trình duyệt đột ngột, kiểm bảng kết nối có dọn không | |

Và một lời khuyên: hãy đặt TTL cho bản ghi connectionId ngay từ đầu. Route $disconnect không phải lúc nào cũng chạy — mất mạng, đóng máy, hết pin đều để lại một kết nối chết trong bảng, và không có TTL thì bảng đó chỉ có phình to.

Đáp án

**D — Đổi kích thước volume gp2 trên mỗi instance từ 3 TB lên 4 TB.

Vì sao đúng

Câu này chỉ cần một công thức và một phép tính:

gp2 cấp 3 IOPS cho mỗi GiB
        ↓
    3 TB ≈ 3.000 GiB → 9.000 IOPS
        ↓
    Cần thêm 3.000 IOPS
    → tổng 12.000 IOPS
        ↓
    12.000 / 3 = 4.000 GiB ≈ 4 TB

⚠ Và đây là con số chính xác đề yêu cầu: | Dung lượng | IOPS gp2 | |---|---| | 3 TB (3.000 GiB) | 9.000 | | 4 TB (4.000 GiB) | 12.000 | | Chênh lệch | +3.000 — đúng yêu cầu |

Đổi kích thước:

for may in i-0abc i-0def; do
  vol=$(aws ec2 describe-instances --instance-ids $may \
    --query 'Reservations[0].Instances[0].BlockDeviceMappings[0].Ebs.VolumeId' \
    --output text)
  aws ec2 modify-volume --volume-id $vol --size 4000
done

Mở rộng hệ thống tệp:

sudo growpart /dev/nvme1n1 1
sudo xfs_growfs -d /du-lieu

⚠ Đổi kích thước EBS không tự mở rộng hệ thống tệp:

`modify-volume` xong
        ↓
    `lsblk` thấy đĩa 4 TB
        ↓
    `df -h` vẫn thấy 3 TB
    → phải growpart rồi xfs_growfs

⚠ Và thao tác này làm được khi máy đang chạy:

Không cần dừng instance
    → không cần tháo volume
        ↓
    Có giai đoạn "optimizing"
    → hiệu năng thấp hơn một chút
      trong lúc đó
        ↓
    Đề nói "hiệu quả chi phí nhất"
    → không gián đoạn cũng là
      một dạng tiết kiệm

⚠ Và vì sao phương án A (io1 với 12.000 IOPS) đắt hơn:

gp2 4 TB: chỉ trả tiền dung lượng
  (0,10 USD/GB-tháng)
        ↓
    4.000 GB × 0,10 = 400 USD/tháng
        ↓
    io1 3 TB + 12.000 IOPS:
      3.000 × 0,125 = 375 USD
      + 12.000 × 0,065 = 780 USD
    → tổng 1.155 USD/tháng
        ↓
    Đắt gần ba lần

⚠ Và đây là lý do "tăng dung lượng gp2" là mẫu quen thuộc:

Với gp2, IOPS đi kèm dung lượng
  MIỄN PHÍ
        ↓
    io1/io2: trả riêng cho từng IOPS
        ↓
    Dưới 16.000 IOPS, tăng dung
      lượng gp2 thường rẻ hơn

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

Đề nói tải "I/O nặng với đọc/ghi/
  cập nhật liên tục"
        ↓
    EFS là lưu trữ qua MẠNG (NFS)
    → độ trễ cao hơn hẳn EBS
        ↓
    Với tải bị nghẽn IOPS, EFS
      làm mọi thứ tệ hơn

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

S3 là kho OBJECT
        ↓
    Không có khái niệm cập nhật
      một phần tệp
    → mỗi lần ghi là ghi lại cả
      object
        ↓
    Và không mount như hệ tệp được

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Đạt đúng mức IOPS cần | | | Không dừng máy | | | Rẻ hơn nhiều so với Provisioned IOPS | |

⚠ Nhưng phải kiểm tra trần của chính instance:

r6g.8xlarge: băng thông EBS
  khoảng 9.500 Mbps
        ↓
    Và trần IOPS khoảng 40.000
        ↓
    12.000 IOPS mỗi máy: nằm trong
      giới hạn
    → nếu vượt, đổi volume cũng
      vô ích

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

⚠ gp3 là câu trả lời đúng hơn và rẻ hơn — nó không có trong danh sách.

aws ec2 modify-volume --volume-id vol-abc \
  --volume-type gp3 --iops 12000 --throughput 500

gp3 tách IOPS khỏi dung lượng
        ↓
    Không phải mua thêm 1 TB không
      dùng
        ↓
    Rẻ hơn khoảng 30% cho cùng
      hiệu năng

Và gp2 còn có cơ chế tín dụng bùng nổ mà gp3 không có:

Volume gp2 dưới 1.000 GiB có
  tín dụng
        ↓
    3 TB đã trên ngưỡng đó
    → chạy ở IOPS cơ sở ổn định
        ↓
    Nên trong câu này, cơ chế
      bùng nổ không liên quan

Câu hỏi vẫn kiểm tra đúng công thức 3 IOPS/GiB của gp2, nhưng với kiến thức hiện tại, việc mua thêm dung lượng để lấy IOPS là mẫu nên tránh.

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

• **A. Đổi volume từ gp2 sang io1 với 12.000 IOPS đã cấp — đây là phương án gần nhất và đạt đúng mức IOPS yêu cầu, nhưng io1 tính tiền riêng cho từng IOPS, tổng chi phí cao gần ba lần so với việc tăng dung lượng gp2.
• **B. Chuyển sang EFS và mount vào cả 15 instance — EFS là lưu trữ qua mạng, độ trễ cao hơn EBS, làm tải nghẽn IOPS tệ hơn.
• **C. Chuyển sang S3 — kho object, không mount như hệ tệp và không hỗ trợ cập nhật một phần tệp.

Ghi nhớ

⚠ Công thức IOPS của các loại EBS — bảng phải thuộc: | Loại | IOPS | |---|---| | gp2 | 3 × GiB, tối thiểu 100, tối đa 16.000 | | gp3 | 3.000 miễn phí, mua thêm tới 16.000 | | io1 | tới 50 IOPS/GiB, tối đa 64.000 | | io2 | tới 500 IOPS/GiB, tối đa 64.000 | | io2 Block Express | tối đa 256.000 |

Từ khoá nhận diện:

"need N more IOPS on gp2, cost-effective" → tăng dung lượng (hoặc gp3) "over 16,000 IOPS" → io1/io2 | "over 64,000 IOPS" → io2 Block Express "shared POSIX across instances" → EFS (nhưng chậm hơn EBS)

Ba lưu ý về đổi kích thước: | Lưu ý | Chi tiết | |---|---| | Làm được khi đang chạy | | | Phải mở rộng hệ thống tệp thủ công | | | Chờ 6 giờ mới sửa lại được | |

⚠ Chỉ TĂNG được, không GIẢM:

Tăng 3 TB → 4 TB: được
        ↓
    Giảm 4 TB → 3 TB: KHÔNG
        ↓
    Muốn giảm: tạo volume mới nhỏ
      hơn và chép dữ liệu

Ba lưu ý về gp3: | Lưu ý | Chi tiết | |---|---| | 3.000 IOPS và 125 MB/s miễn phí | | | Rẻ hơn gp2 20% cùng dung lượng | | | Chuyển từ gp2 sang gp3 không cần dừng máy | |

Ba lưu ý về giới hạn instance: | Lưu ý | Chi tiết | |---|---| | Mỗi kiểu instance có trần băng thông EBS | | | Và trần IOPS riêng | | | Instance nhỏ có tín dụng EBS như gp2 | |

Ba chỉ số cần theo dõi: | Chỉ số | Ý nghĩa | |---|---| | VolumeReadOps/WriteOps | IOPS thực tế | | VolumeQueueLength | yêu cầu xếp hàng | | BurstBalance | tín dụng gp2 còn lại |

⚠ Hàng đợi dài là dấu hiệu nghẽn rõ nhất:

`VolumeQueueLength` liên tục trên 1
  cho mỗi 500 IOPS đã cấp
        ↓
    Volume không kịp phục vụ
    → cần thêm IOPS

Ba lưu ý về RAID: | Lưu ý | Chi tiết | |---|---| | RAID 0 nhiều volume cộng IOPS | | | Một volume hỏng là mất hết | | | Thường không cần với gp3 và io2 | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo IOPS thật bằng fio hoặc iostat | | | Kiểm df -h sau khi mở rộng hệ tệp | | | So độ trễ ứng dụng trước và sau | |

Và một lời khuyên: hãy chuyển sang gp3 thay vì mua thêm dung lượng gp2. Mua 1 TB mà bạn không cần chỉ để lấy 3.000 IOPS là trả tiền cho không gian trống — gp3 bán riêng hai thứ đó và tổng cộng vẫn rẻ hơn.

Đáp án

**A — Dùng message timer để hoãn việc giao một số tin nhắn cụ thể vào hàng đợi thêm một phút.

Vì sao đúng

Đề nêu một yêu cầu rất chính xác, và nó quyết định giữa hai cơ chế nghe rất giống nhau:

MỘT SỐ tin nhắn (ảnh nhạy cảm)
  hoãn một phút
        ↓
    MỌI tin nhắn khác giao NGAY
        ↓
    Nghĩa là: hoãn theo TỪNG TIN,
      không phải theo cả hàng đợi

⚠ Đây là khác biệt duy nhất giữa message timer và delay queue: | Cơ chế | Phạm vi | |---|---| | Message timer | TỪNG tin nhắn | | Delay queue | TOÀN BỘ hàng đợi |

Delay queue đặt `DelaySeconds` ở
  cấp HÀNG ĐỢI
        ↓
    MỌI tin nhắn đều bị hoãn
        ↓
    Đề nói ảnh thường phải giao
      NGAY
    → delay queue vi phạm

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

Gửi tin có hẹn giờ:

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

def gui_anh(ma_anh, nhay_cam=False):
    tham_so = {
        'QueueUrl': URL_HANG_DOI,
        'MessageBody': json.dumps({'ma_anh': ma_anh})}
    if nhay_cam:
        tham_so['DelaySeconds'] = 60
    sqs.send_message(**tham_so)

⚠ Cùng một tham số DelaySeconds, nhưng đặt ở hai nơi khác nhau:

# Delay queue — cấp hàng đợi
aws sqs set-queue-attributes --queue-url <url> \
  --attributes DelaySeconds=60

# Message timer — cấp tin nhắn
aws sqs send-message --queue-url <url> \
  --message-body "..." --delay-seconds 60

⚠ Và message timer GHI ĐÈ delay queue:

Hàng đợi có DelaySeconds = 60
        ↓
    Gửi tin với DelaySeconds = 0
    → tin đó giao NGAY
        ↓
    Có thể dùng kết hợp

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

Visibility timeout: sau khi
  consumer NHẬN tin
        ↓
    Tin bị ẩn khỏi consumer khác
      trong khoảng đó
        ↓
    Nó không liên quan tới thời
      điểm tin XUẤT HIỆN lần đầu

Ba mốc thời gian của một tin nhắn SQS:

Gửi vào hàng đợi
    ↓ (DelaySeconds — chưa ai thấy)
Hiện ra cho consumer
    ↓ (consumer nhận)
Bị ẩn (VisibilityTimeout)
    ↓
Xoá, hoặc hiện lại

⚠ Và vì sao phương án C (dead-letter queue) sai:

DLQ nhận tin đã xử lý HỎNG nhiều
  lần
        ↓
    `maxReceiveCount` quyết định
      khi nào chuyển
        ↓
    Không liên quan gì tới việc
      hoãn giao tin

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chỉ tin cần hoãn mới bị hoãn | | | Không cần hàng đợi thứ hai | | | Quyết định ở lúc gửi, rất linh hoạt | |

⚠ Và giới hạn của cả hai cơ chế là 15 phút:

`DelaySeconds` tối đa 900 giây
        ↓
    Cần hoãn lâu hơn:
      EventBridge Scheduler
      hoặc Step Functions Wait

aws scheduler create-schedule \
  --name xu-ly-sau \
  --schedule-expression "at(2026-09-01T14:30:00)" \
  --flexible-time-window '{"Mode": "OFF"}' \
  --target '{"Arn": "<arn-hang-doi>",
             "RoleArn": "<arn-role>",
             "Input": "{\"ma_anh\": \"A-42\"}"}'

⚠ Và FIFO queue KHÔNG hỗ trợ message timer:

FIFO queue: chỉ đặt DelaySeconds
  ở cấp hàng đợi
        ↓
    Không đặt được cho từng tin
        ↓
    Vì hoãn một tin sẽ phá vỡ
      thứ tự

⚠ Và đề nhắc Spot Instance — chi tiết đáng lưu ý về kiến trúc:

Xử lý ảnh bằng Spot, chạy ban đêm
        ↓
    Spot có thể bị thu hồi
        ↓
    SQS giữ tin cho tới khi xử lý
      xong
    → máy bị thu hồi thì tin hiện
      lại cho máy khác
        ↓
    Đây là lý do SQS + Spot là cặp
      rất hợp nhau

⚠ Và visibility timeout phải dài hơn thời gian xử lý ảnh:

Đổi hình mờ một ảnh lớn mất 3 phút
        ↓
    Visibility timeout 30 giây
    → tin hiện lại giữa chừng
    → hai máy cùng xử lý một ảnh
        ↓
    Đặt 6 lần thời gian xử lý,
      hoặc gia hạn động

sqs.change_message_visibility(
    QueueUrl=URL, ReceiptHandle=bien_lai,
    VisibilityTimeout=300)

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

• **B. Dùng delay queue để hoãn giao một số tin nhắn thêm một phút — đây là phương án gần nhất và dùng đúng tham số DelaySeconds, nhưng delay queue áp cho toàn bộ hàng đợi, nên mọi ảnh thường cũng bị hoãn, trái với yêu cầu.
• **D. Dùng visibility timeout — cơ chế đó ẩn tin sau khi consumer đã nhận, không liên quan tới thời điểm tin xuất hiện lần đầu.
• **C. Dùng dead-letter queue — nơi nhận tin xử lý hỏng nhiều lần, không liên quan tới việc hoãn.

Ghi nhớ

⚠ Bốn tham số thời gian của SQS — bảng phải thuộc: | Tham số | Ý nghĩa | Tối đa | |---|---|---| | DelaySeconds (hàng đợi) | hoãn mọi tin | 15 phút | | DelaySeconds (tin nhắn) | hoãn tin đó | 15 phút | | VisibilityTimeout | ẩn sau khi nhận | 12 giờ | | MessageRetentionPeriod | giữ tin bao lâu | 14 ngày |

Từ khoá nhận diện:

"delay certain messages" → message timer "delay all messages in queue" → delay queue "hide message while processing" → visibility timeout "messages that keep failing" → dead-letter queue "delay more than 15 minutes" → EventBridge Scheduler hoặc Step Functions

Ba lưu ý về long polling: | Lưu ý | Chi tiết | |---|---| | ReceiveMessageWaitTimeSeconds tối đa 20 giây | | | Giảm mạnh số lời gọi rỗng | | | Nên bật mặc định | |

Ba lưu ý về DLQ: | Lưu ý | Chi tiết | |---|---| | maxReceiveCount quyết định ngưỡng | | | Đặt cảnh báo khi DLQ có tin | | | Redrive đưa tin về hàng đợi chính | |

Ba lưu ý về FIFO queue: | Lưu ý | Chi tiết | |---|---| | MessageGroupId bắt buộc | | | Khử trùng lặp trong 5 phút | | | KHÔNG hỗ trợ message timer | |

Ba lưu ý về xử lý ảnh với Spot: | Lưu ý | Chi tiết | |---|---| | Bắt tín hiệu thu hồi để rút êm | | | Visibility timeout dài hơn thời gian xử lý | | | Gia hạn visibility khi xử lý lâu | |

⚠ Bắt tín hiệu thu hồi Spot:

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

Có phản hồi → còn 2 phút
        ↓
    Trả tin về hàng đợi bằng
      `change_message_visibility`
      với timeout 0
    → máy khác nhận ngay

Ba lưu ý về xử lý lặp lại: | Lưu ý | Chi tiết | |---|---| | SQS Standard giao ít nhất một lần | | | Consumer phải chịu được xử lý trùng | | | Dùng khoá duy nhất và điều kiện ghi | |

Ba lưu ý về co giãn theo hàng đợi: | Lưu ý | Chi tiết | |---|---| | ASG theo ApproximateNumberOfMessagesVisible | | | Hoặc theo backlog trên mỗi instance | | | Lambda tự co giãn theo hàng đợi | |

Ba chỉ số cần theo dõi: | Chỉ số | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | có tin nào bị kẹt không | | ApproximateNumberOfMessagesVisible | tồn đọng bao nhiêu | | NumberOfMessagesDeleted | tốc độ xử lý |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi một tin có hẹn giờ, đo thời điểm nó hiện ra | | | Gửi tin thường, kiểm nó hiện ngay | | | Kiểm DLQ có tin không | |

Và một lời khuyên: hãy đặt cảnh báo trên ApproximateAgeOfOldestMessage chứ đừng nhìn số tin tồn đọng. Với hàng đợi xử lý ảnh chạy trên Spot ban đêm, số tin lớn là bình thường — nhưng một tin đã nằm đó tám tiếng nghĩa là có ảnh nào đó làm consumer chết mỗi lần nhận.

Đáp án

**D — Trợ lý nghiên cứu không phải trả bất kỳ khoản phí truyền nào cho lần tải ảnh đó.

Vì sao đúng

S3 Transfer Acceleration có một chính sách tính phí rất hiếm gặp:

AWS so tốc độ qua điểm biên với
  tốc độ đi thẳng tới bucket
        ↓
    Nhanh hơn → tính phí tăng tốc
        ↓
    KHÔNG nhanh hơn → KHÔNG tính
      phí tăng tốc

⚠ Và tải dữ liệu VÀO S3 vốn đã miễn phí:

Phí truyền dữ liệu VÀO AWS:
  MIỄN PHÍ
        ↓
    Phí truyền dữ liệu RA: tính tiền
        ↓
    Đề nói "tải LÊN" một ảnh
    → không có phí truyền vào

⚠ Hai điều này cộng lại thành đáp án: | Khoản | Có tính không | |---|---| | Phí truyền vào S3 | KHÔNG (luôn miễn phí) | | Phí tăng tốc S3TA | KHÔNG (vì không nhanh hơn) | | Tổng | 0 |

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

A: chỉ trả phí S3TA
    → không nhanh hơn thì không tính
        ↓
B: trả cả phí S3 lẫn phí S3TA
    → cả hai đều không phát sinh
        ↓
C: chỉ trả phí truyền S3
    → truyền vào miễn phí

⚠ Nhưng cần phân biệt phí TRUYỀN với các phí khác:

Miễn phí: phí TRUYỀN DỮ LIỆU vào
        ↓
    VẪN tính: phí YÊU CẦU (PUT)
    → và phí LƯU TRỮ hằng tháng
        ↓
    Đề chỉ hỏi về "transfer charges"
    → nên đáp án là không có phí
      truyền nào

Bật Transfer Acceleration:

aws s3api put-bucket-accelerate-configuration \
  --bucket anh-y-te \
  --accelerate-configuration Status=Enabled

Dùng endpoint tăng tốc:

import boto3
from botocore.config import Config

s3 = boto3.client('s3', config=Config(
    s3={'use_accelerate_endpoint': True}))
s3.upload_file('anh-chup.dcm', 'anh-y-te', 'ca-benh/A-42.dcm')

⚠ Và endpoint tăng tốc có tên miền riêng:

Bình thường:
  anh-y-te.s3.amazonaws.com
        ↓
    Tăng tốc:
  anh-y-te.s3-accelerate.amazonaws.com
        ↓
    Bật cờ mà client vẫn gọi
      endpoint cũ
    → không có tác dụng, và cũng
      không tính phí

⚠ Và khi nào S3TA thật sự giúp: | Tình huống | Có nhanh hơn | |---|---| | Client cách Region nửa vòng trái đất | CÓ, rõ rệt | | Tệp lớn (hàng trăm MB trở lên) | CÓ | | Client cùng Region với bucket | KHÔNG | | Đường truyền của client rất hẹp | không đáng kể |

Đề nói ảnh 5 GB qua Internet công
  cộng
        ↓
    Đáng lẽ S3TA phải giúp
        ↓
    Không giúp → có thể client ở
      gần Region, hoặc đường truyền
      đầu nguồn là nút thắt

Đo thử trước khi dùng:

https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/
  en/accelerate-speed-comparsion.html

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Thử nghiệm không rủi ro về chi phí | | | Tự động dùng đường nhanh hơn | | | Không phải đổi kiến trúc gì | |

⚠ Và với tệp 5 GB, multipart upload là bắt buộc:

Giới hạn PUT một lần: 5 GB
        ↓
    Trên 5 GB: BẮT BUỘC multipart
        ↓
    AWS khuyến nghị multipart từ
      100 MB trở lên

from boto3.s3.transfer import TransferConfig
cau_hinh = TransferConfig(
    multipart_threshold=100*1024*1024,
    max_concurrency=10,
    multipart_chunksize=100*1024*1024,
    use_threads=True)
s3.upload_file('anh.dcm', KHO, 'anh.dcm', Config=cau_hinh)

⚠ Và multipart song song thường giúp nhiều hơn cả S3TA:

Một luồng TCP đơn qua đường dài
        ↓
    Cửa sổ TCP giới hạn thông lượng
        ↓
    10 luồng song song
    → tận dụng hết băng thông
        ↓
    Thử cái này trước khi bật S3TA

⚠ Và ảnh y tế đặt ra yêu cầu tuân thủ riêng:

Dữ liệu y tế → HIPAA
        ↓
    Mã hoá khi lưu (SSE-KMS)
    → và khi truyền (HTTPS)
        ↓
    Bật CloudTrail data event
    → ghi lại ai truy cập ảnh nào
        ↓
    Ký BAA với AWS

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

• **A. Chỉ phải trả phí truyền S3TA cho lần tải lên — đây là phương án gần nhất và là điều xảy ra khi tăng tốc thật sự hiệu quả, nhưng đề nói rõ S3TA không làm nhanh hơn, và AWS không tính phí tăng tốc trong trường hợp đó.
• **B. Trả cả phí truyền S3 lẫn phí S3TA — truyền dữ liệu vào S3 luôn miễn phí, và phí tăng tốc không phát sinh.
• **C. Chỉ trả phí truyền S3 — truyền vào miễn phí.

Ghi nhớ

⚠ Bảng phí truyền dữ liệu của S3 — phải thuộc: | Chiều | Phí | |---|---| | Internet → S3 (vào) | MIỄN PHÍ | | S3 → Internet (ra) | ~0,09 USD/GB | | S3 → EC2 cùng Region | miễn phí | | S3 → S3 khác Region | tính phí liên Region | | S3 → CloudFront | miễn phí |

⚠ Điểm cuối là lý do CloudFront giảm chi phí:

Phục vụ trực tiếp từ S3 ra Internet
        ↓
    0,09 USD/GB
        ↓
    Qua CloudFront: S3 → CloudFront
      miễn phí, CloudFront → Internet
      rẻ hơn một chút và có cache

Từ khoá nhận diện:

"S3TA did not accelerate" → không tính phí tăng tốc "upload to S3 from far away" → S3TA hoặc multipart song song "data transfer in" → luôn miễn phí "file over 5 GB" → bắt buộc multipart

Ba lưu ý về S3 Transfer Acceleration: | Lưu ý | Chi tiết | |---|---| | Tên bucket không được có dấu chấm | | | Không hỗ trợ PUT Object - Copy | | | Chỉ tính phí khi thật sự nhanh hơn | |

Ba lưu ý về multipart upload: | Lưu ý | Chi tiết | |---|---| | Tối đa 10.000 phần | | | Mỗi phần 5 MB - 5 GB (trừ phần cuối) | | | Phần dở dang vẫn tính phí lưu trữ | |

⚠ Luôn đặt luật dọn phần dở dang:

{"AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}

Ba lưu ý về tối ưu tải lên: | Cách | Khi nào | |---|---| | Multipart song song | luôn luôn với tệp lớn | | S3TA | client ở xa Region | | Snowball | hàng chục TB trở lên |

Ba lưu ý về dữ liệu y tế: | Lưu ý | Chi tiết | |---|---| | Mã hoá SSE-KMS với khoá riêng | | | Bật CloudTrail data event | | | Bật versioning và Object Lock nếu cần | |

Ba lưu ý về chi phí ẩn của S3: | Khoản | Ghi chú | |---|---| | Phí yêu cầu (PUT, GET, LIST) | nhiều tệp nhỏ thì đáng kể | | Phí chuyển tầng vòng đời | theo số object | | Phí lấy ra khỏi Glacier | theo GB và tốc độ |

Ba lưu ý về giám sát: | Công cụ | Việc | |---|---| | S3 Storage Lens | toàn cảnh dung lượng và chi phí | | Cost Explorer | phân tích theo dịch vụ và thẻ | | CloudWatch metric của bucket | số yêu cầu, byte |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy công cụ so tốc độ của S3TA | | | Đo thời gian tải với và không có S3TA | | | Kiểm hoá đơn có dòng phí tăng tốc không | |

Và một lời khuyên: hãy thử multipart upload song song trước khi bật Transfer Acceleration. Với tệp lớn, phần lớn cải thiện thường đến từ việc chia nhỏ và tải song song chứ không phải từ đường đi qua điểm biên — và cách đó không cần bật gì thêm trên bucket.

Đáp án

**D — Dựng một CloudFormation StackSet để tạo cụm Redshift ở Region khác khi cần, và cấu hình Redshift tự động sao chép snapshot sang Region đó; khi có thảm hoạ thì khôi phục cụm từ snapshot ở Region đó.

Vì sao đúng

Đề cho một mục tiêu RTO cụ thể và một ràng buộc chi phí:

Cụm phải hoạt động lại hoặc được
  khôi phục trong 5 GIỜ
        ↓
    Và "hiệu quả chi phí nhất"
        ↓
    5 giờ là RTO khá rộng
    → không cần cụm dự phòng chạy
      sẵn

⚠ Điểm mấu chốt: không cần chạy cụm thứ hai 24/7:

Cụm Redshift dự phòng chạy liên tục
        ↓
    Trả tiền đầy đủ cho một cụm
      không ai dùng
        ↓
    RTO 5 giờ cho phép DỰNG cụm
      khi cần
    → mẫu "backup and restore"

Bật sao chép snapshot liên Region:

aws redshift enable-snapshot-copy \
  --cluster-identifier cum-phan-tich \
  --destination-region us-west-2 \
  --retention-period 7 \
  --snapshot-copy-grant-name grant-us-west-2

⚠ Một lệnh này thay thế toàn bộ đường ống thủ công:

Redshift tự chụp snapshot theo lịch
        ↓
    Và tự sao chép sang Region đích
        ↓
    Không viết script nào, không
      có cron nào để hỏng

⚠ Và đây là lý do phương án A thua:

A dựng cron chạy `UNLOAD` mỗi 5 giờ
  ra S3
        ↓
    Rồi cross-region replication
        ↓
    Rồi một cron nữa nạp vào cụm
      thứ hai
        ↓
    Ba bộ phận tự viết, ba chỗ
      có thể hỏng
    → và cụm thứ hai chạy 24/7

⚠ Và UNLOAD không giữ được mọi thứ:

UNLOAD xuất DỮ LIỆU ra tệp
        ↓
    Không giữ: DISTKEY, SORTKEY,
      quyền người dùng, view,
      stored procedure
        ↓
    Snapshot giữ TOÀN BỘ cụm

Khôi phục khi có thảm hoạ:

aws redshift restore-from-cluster-snapshot \
  --cluster-identifier cum-phuc-hoi \
  --snapshot-identifier <ma-snapshot> \
  --region us-west-2

⚠ Và StackSet dựng phần hạ tầng xung quanh:

Cụm Redshift cần: VPC, subnet
  group, security group, IAM role,
  parameter group
        ↓
    StackSet triển khai chúng ở
      Region dự phòng
        ↓
    Khi thảm hoạ: hạ tầng đã sẵn,
      chỉ khôi phục cụm
    → rút ngắn RTO đáng kể

aws cloudformation create-stack-instances \
  --stack-set-name ha-tang-redshift-dr \
  --regions us-west-2 \
  --accounts 111122223333 \
  --operation-preferences FailureToleranceCount=0

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

B nói dùng Auto Scaling group cho
  node Redshift, trải nhiều AZ
        ↓
    Redshift KHÔNG dùng Auto
      Scaling group
        ↓
    Và cụm Redshift nằm trong MỘT AZ
    → không trải nhiều AZ được
      (trừ Multi-AZ mới có)

⚠ Redshift Multi-AZ là tính năng mới, đáng biết:

aws redshift create-cluster \
  --cluster-identifier cum-ha \
  --multi-az \
  --node-type ra3.4xlarge --number-of-nodes 4

Chỉ có với RA3
        ↓
    Chịu được mất một AZ, tự
      chuyển đổi
        ↓
    Nhưng vẫn TRONG một Region
    → không thay được khôi phục
      liên Region

⚠ Và vì sao phương án C phức tạp quá mức:

C dựng Kinesis Data Streams thu
  dữ liệu trước khi vào cụm chính
        ↓
    Rồi phát cùng dữ liệu sang
      cụm thứ hai
        ↓
    Cụm thứ hai chạy 24/7
    → và phải bảo đảm hai bên xử
      lý giống hệt nhau
        ↓
    Rất phức tạp, rất đắt

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không trả tiền cho cụm dự phòng | | | Sao chép snapshot là tính năng sẵn có | | | Snapshot giữ nguyên cấu trúc và quyền | |

⚠ Nhưng phải đo thời gian khôi phục thật:

Khôi phục cụm lớn có thể mất
  hàng giờ
        ↓
    RTO mục tiêu là 5 giờ
    → phải thử để biết có kịp không
        ↓
    RA3 khôi phục nhanh hơn DC2
      vì dữ liệu nằm trên S3

⚠ Và RA3 có tính năng khôi phục truy vấn được ngay:

Node RA3: tầng lưu trữ tách rời
        ↓
    Khôi phục xong, cụm truy vấn
      được NGAY
    → dữ liệu nạp dần từ S3 theo
      nhu cầu
        ↓
    Node DC2: phải nạp hết mới dùng
      được

⚠ Và snapshot mã hoá cần snapshot copy grant:

aws redshift create-snapshot-copy-grant \
  --snapshot-copy-grant-name grant-us-west-2 \
  --kms-key-id <khoa-o-us-west-2> \
  --region us-west-2

Snapshot mã hoá bằng khoá ở Region
  nguồn
        ↓
    Region đích không dùng được
      khoá đó
        ↓
    Grant cho phép mã hoá lại bằng
      khoá ở đích

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

• **A. Dựng hai cụm giống nhau ở hai Region, cron chạy UNLOAD mỗi 5 giờ ra S3, sao chép liên Region, rồi cron nạp vào cụm thứ hai — đây là phương án gần nhất và thật sự đưa được dữ liệu sang Region khác, nhưng phải tự dựng ba bộ phận, cụm thứ hai chạy 24/7, và UNLOAD không giữ được cấu trúc lẫn quyền.
• **C. Hai cụm ở hai Region, dùng Kinesis Data Streams thu dữ liệu và phát sang cả hai — phức tạp và tốn kém hơn nhiều, và vẫn phải chạy cụm thứ hai liên tục.
• **B. Dùng Auto Scaling group cho node Redshift trải nhiều AZ — Redshift không dùng Auto Scaling group, và cụm truyền thống nằm trong một AZ.

Ghi nhớ

⚠ Bốn chiến lược khôi phục thảm hoạ — bảng phải thuộc: | Chiến lược | RTO | Chi phí | |---|---|---| | Backup & restore | giờ | thấp nhất | | Pilot light | chục phút | thấp | | Warm standby | phút | trung bình | | Multi-site active/active | gần 0 | cao nhất |

RTO 5 giờ → backup & restore là
  đủ và rẻ nhất

Từ khoá nhận diện:

"restore within N hours, cost-effective" → snapshot copy liên Region "near-zero RTO" → cụm dự phòng chạy sẵn "Redshift DR" → enable-snapshot-copy "deploy infrastructure to another Region" → StackSets

Ba lưu ý về snapshot Redshift: | Loại | Đặc điểm | |---|---| | Automated | theo lịch, xoá khi hết hạn giữ | | Manual | giữ tới khi tự xoá | | Cross-Region copy | bật một lần, tự động sau đó |

⚠ Snapshot tự động bị xoá khi xoá cụm:

Xoá cụm mà không tạo final snapshot
        ↓
    Mọi snapshot tự động mất theo
        ↓
    Luôn tạo snapshot thủ công
      trước khi xoá

Ba lưu ý về node RA3: | Lưu ý | Chi tiết | |---|---| | Tách tính toán khỏi lưu trữ | | | Managed storage tự động dùng S3 | | | Khôi phục nhanh hơn, truy vấn được ngay | |

Ba lưu ý về StackSets: | Lưu ý | Chi tiết | |---|---| | Triển khai một template ra nhiều Region, nhiều tài khoản | | | Kiểu SERVICE_MANAGED tự áp cho tài khoản mới | | | Có tuỳ chọn kiểm soát tốc độ triển khai | |

Ba lưu ý về Redshift Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Chỉ có với RA3 | | | Chịu được mất một AZ trong Region | | | KHÔNG thay thế khôi phục liên Region | |

Ba lưu ý về khôi phục: | Lưu ý | Chi tiết | |---|---| | Cụm khôi phục có endpoint MỚI | | | Dùng CNAME để đổi nhanh | | | Kiểm quyền người dùng sau khi khôi phục | |

⚠ Endpoint mới ảnh hưởng mọi công cụ kết nối:

BI tool, ETL job, ứng dụng đều
  cài cứng endpoint
        ↓
    Dùng một bản ghi CNAME
      (kho.cong-ty.vn)
    → khôi phục xong chỉ đổi CNAME

Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Lưu trữ snapshot | theo GB vượt dung lượng cụm | | Truyền snapshot liên Region | theo GB | | Cụm khôi phục | chỉ tính khi thật sự chạy |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khôi phục thử ở Region dự phòng và bấm giờ | | | Kiểm snapshot mới nhất ở Region đích | | | Chạy vài truy vấn sau khi khôi phục | |

Và một lời khuyên: hãy khôi phục thử ít nhất mỗi quý và bấm giờ toàn bộ quá trình. RTO 5 giờ trên giấy chỉ có ý nghĩa khi bạn đã đo thời gian thật — và với một cụm lớn, riêng khâu khôi phục có thể tiêu hết ngân sách thời gian trước khi ai kịp chạy truy vấn đầu tiên.

Đáp án

**C — Dựng một kết nối Direct Connect tới TỪNG trung tâm dữ liệu, từ các nhà cung cấp dịch vụ KHÁC NHAU, và cấu hình định tuyến để chuyển sang Direct Connect của trung tâm dữ liệu kia khi một kết nối hỏng; bảo đảm không dải CIDR nào chồng nhau.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này khớp cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | Sẵn sàng cao | hai DX từ hai nhà cung cấp, dự phòng lẫn nhau | | Băng thông cao | Direct Connect, không phải VPN | | Không dùng NAT | DX giữ nguyên địa chỉ, định tuyến trực tiếp | | Nhiều Region sau di trú | DX Gateway phục vụ nhiều Region |

⚠ Điểm mấu chốt thứ nhất: đề nói rõ KHÔNG dùng NAT được:

Ứng dụng cũ có ràng buộc riêng
        ↓
    NAT làm đổi địa chỉ nguồn
    → một số giao thức và ứng dụng
      không chịu được
        ↓
    Định tuyến trực tiếp là bắt buộc
    → và CIDR không được trùng

⚠ Điểm mấu chốt thứ hai: "hai nhà cung cấp khác nhau":

Hai kết nối từ CÙNG một nhà
  cung cấp
        ↓
    Có thể đi chung một tuyến cáp
    → hoặc chung một thiết bị
        ↓
    Sự cố của nhà cung cấp đó làm
      hỏng cả hai
        ↓
    Hai nhà cung cấp khác nhau
    → độc lập thật sự

⚠ Và AWS có mô hình khả năng phục hồi rõ ràng: | Mức | Cấu hình | |---|---| | Phát triển và thử nghiệm | một DX, một địa điểm | | Sẵn sàng cao | hai DX ở HAI địa điểm khác nhau | | Tối đa | hai DX ở mỗi trung tâm dữ liệu, bốn tổng cộng |

⚠ Và vì sao phương án A không đủ:

A dùng MỘT Direct Connect cho
  MỌI trung tâm dữ liệu, VPN dự phòng
        ↓
    Một DX là điểm hỏng đơn lẻ
        ↓
    Và VPN dự phòng có băng thông
      thấp hơn nhiều
    → khi DX hỏng, hiệu năng sụt
      mạnh
        ↓
    Đề nói "băng thông cao"

⚠ Và cả A còn dùng "cùng một virtual private gateway":

VGW gắn với MỘT VPC
        ↓
    Đề nói triển khai NHIỀU REGION
      sau di trú
        ↓
    VGW không phục vụ nhiều Region
    → cần Direct Connect Gateway

Direct Connect Gateway cho nhiều Region:

aws directconnect create-direct-connect-gateway \
  --direct-connect-gateway-name cong-toan-cau \
  --amazon-side-asn 64512

aws directconnect create-direct-connect-gateway-association \
  --direct-connect-gateway-id <id-dxgw> \
  --gateway-id vgw-o-region-khac

⚠ DX Gateway là mảnh ghép cho yêu cầu nhiều Region:

Một kết nối DX vật lý
        ↓
    Gắn vào DX Gateway
        ↓
    DX Gateway liên kết với VGW
      hoặc TGW ở NHIỀU REGION
    → trừ Trung Quốc
        ↓
    Không phải kéo cáp tới từng
      Region

⚠ Và vì sao hai phương án VPN (B, D) không đủ:

Site-to-Site VPN: mỗi tunnel
  khoảng 1,25 Gbps
        ↓
    Đề nói "băng thông cao"
        ↓
    Và VPN đi qua Internet công cộng
    → độ trễ không ổn định

Và cả hai nói "cấu hình lưu lượng
  của mỗi subnet qua một VPN khác
  nhau để dự phòng"
        ↓
    Đó không phải dự phòng
    → đó là phân chia
        ↓
    Một VPN hỏng thì subnet của nó
      mất kết nối hoàn toàn

⚠ Và "software VPN" trong phương án B còn tệ hơn:

Software VPN: tự dựng phần mềm
  VPN trên EC2
        ↓
    Tự vá, tự làm HA, tự mở rộng
        ↓
    Site-to-Site VPN là dịch vụ
      quản lý
    → không có lý do gì tự dựng

⚠ Và "không CIDR nào chồng nhau" là điều kiện chung của cả bốn phương án:

Định tuyến IP không xử lý được
  địa chỉ trùng
        ↓
    Hai trung tâm dữ liệu cùng
      dùng 10.0.0.0/16
    → không định tuyến giữa chúng
      được
        ↓
    Phải đánh số lại, hoặc dùng NAT
    → mà đề nói không dùng NAT được

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Băng thông cao và ổn định | | | Hai nhà cung cấp độc lập | | | Một DX Gateway phục vụ nhiều Region | |

⚠ Và Direct Connect KHÔNG mã hoá — điểm phải nhớ:

DX là đường riêng, nhưng không
  mã hoá
        ↓
    Dữ liệu nhạy cảm cần:
      MACsec (ở cổng 10/100 Gbps)
      hoặc VPN chạy chồng lên DX

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

⚠ Và định tuyến chuyển đổi phải cấu hình bằng BGP:

Mỗi trung tâm dữ liệu quảng bá
  dải mạng của mình
        ↓
    Và quảng bá cả dải của trung
      tâm kia với AS_PATH dài hơn
        ↓
    DX chính hỏng → AWS học tuyến
      qua trung tâm kia
    → chuyển đổi tự động

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

• **A. Một Direct Connect làm chính cho mọi trung tâm dữ liệu và một VPN dự phòng, cùng dùng một virtual private gateway và BGP — đây là phương án gần nhất và mẫu DX chính + VPN dự phòng là thực hành phổ biến, nhưng một DX là điểm hỏng đơn lẻ, VPN dự phòng không đủ băng thông, và VGW không phục vụ nhiều Region.
• **D. Nhiều hardware VPN, mỗi subnet đi qua một VPN khác nhau — băng thông thấp, và chia subnet theo VPN là phân chia chứ không phải dự phòng.
• **B. Nhiều software VPN tự dựng — vừa băng thông thấp vừa phải tự vận hành.

Ghi nhớ

⚠ Bốn cấu hình kết nối lai — bảng phải thuộc: | Cấu hình | Khả năng phục hồi | |---|---| | Một DX | thấp — điểm hỏng đơn lẻ | | DX + VPN dự phòng | trung bình — băng thông sụt khi chuyển | | Hai DX, hai địa điểm | cao | | Hai DX mỗi địa điểm, hai địa điểm | tối đa |

Từ khoá nhận diện:

"high bandwidth and highly available hybrid" → nhiều DX từ nhiều nhà cung cấp "cannot use NAT" → CIDR không trùng, định tuyến trực tiếp "multi-Region after migration" → Direct Connect Gateway "encrypt over Direct Connect" → MACsec hoặc VPN chồng lên

Ba loại virtual interface: | Loại | Kết nối tới | |---|---| | Private VIF | VPC qua VGW | | Public VIF | dịch vụ công khai AWS | | Transit VIF | Transit Gateway qua DX Gateway |

⚠ Transit VIF là cách hiện đại nhất:

Transit VIF → DX Gateway → TGW
        ↓
    TGW nối hàng trăm VPC
        ↓
    Một kết nối vật lý phục vụ
      toàn bộ mạng

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | Cổng từ 50 Mbps tới 100 Gbps | | | Hosted connection qua đối tác cho băng thông nhỏ | | | LAG gộp nhiều cổng thành một | |

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 | | | Local preference điều khiển chiều đi ra | |

⚠ Điều khiển ưu tiên bằng AS_PATH:

Trung tâm A quảng bá dải của mình:
  AS_PATH ngắn
        ↓
    Trung tâm B quảng bá cùng dải:
      AS_PATH prepend ba lần
        ↓
    AWS ưu tiên đi qua A
    → A hỏng thì tự chuyển sang B

Ba lưu ý về quy hoạch IP: | Lưu ý | Chi tiết | |---|---| | Không dải nào được chồng nhau | | | Chừa chỗ cho tăng trưởng | | | Dùng IPAM để theo dõi | |

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

Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Phí cổng theo giờ | theo băng thông cổng | | Phí truyền dữ liệu ra | rẻ hơn qua Internet | | Phí đối tác | nếu dùng hosted connection |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ngắt một DX và đo thời gian chuyển đổi | | | Kiểm bảng định tuyến BGP hai bên | | | Đo băng thông thật qua từng kết nối | |

Và một lời khuyên: hãy hỏi nhà cung cấp xem hai kết nối có đi chung tuyến cáp vật lý nào không. Hai đường từ hai nhà cung cấp khác nhau vẫn có thể chạy trong cùng một ống ngầm — và một chiếc máy xúc sẽ cắt đứt cả hai cùng lúc, đúng lúc bạn tin rằng mình đã có dự phòng.

Đáp án

**B — Tạo một snapshot copy grant ở Region ĐÍCH cho một khoá KMS ở Region ĐÍCH, rồi cấu hình cross-Region snapshot ở Region NGUỒN.

Vì sao đúng

Câu này kiểm tra hai chi tiết về vị trí, và cả hai đều dễ nhớ ngược.

⚠ Chi tiết thứ nhất: khoá KMS là tài nguyên THEO REGION:

Cụm ở eu-west-1 mã hoá bằng khoá
  ở eu-west-1
        ↓
    Snapshot sao chép sang Region B
        ↓
    Region B KHÔNG dùng được khoá
      của Region A
        ↓
    Phải mã hoá lại bằng khoá ở
      Region B

⚠ Snapshot copy grant chính là cơ chế cho phép việc mã hoá lại đó:

Grant nói: "Redshift được phép
  dùng khoá này ở Region đích để
  mã hoá snapshot sao chép sang"
        ↓
    Nên grant phải tạo Ở REGION
      ĐÍCH
    → và trỏ tới khoá Ở REGION ĐÍCH

Đây là lý do phương án D sai — nó tạo grant ở Region nguồn với khoá ở Region nguồn.

⚠ Chi tiết thứ hai: lệnh bật sao chép chạy ở Region NGUỒN:

Cụm nằm ở Region nguồn
        ↓
    Nó là bên THỰC HIỆN việc sao chép
        ↓
    `enable-snapshot-copy` gọi trên
      cụm đó
    → tức là ở Region nguồn

Tạo grant ở Region đích:

aws redshift create-snapshot-copy-grant \
  --snapshot-copy-grant-name grant-us-east-1 \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abc \
  --region us-east-1

Bật sao chép ở Region nguồn:

aws redshift enable-snapshot-copy \
  --cluster-identifier cum-y-te \
  --destination-region us-east-1 \
  --snapshot-copy-grant-name grant-us-east-1 \
  --retention-period 14 \
  --region eu-west-1

⚠ Và vì sao phương án A phức tạp không cần thiết:

A tạo IAM role ở Region đích có
  quyền dùng khoá ở Region NGUỒN
        ↓
    Điều này không giải quyết vấn đề
    → snapshot ở Region đích vẫn
      phải mã hoá bằng khoá địa
      phương
        ↓
    Và nó tạo grant cho khoá ở
      Region nguồn
    → sai vị trí khoá

⚠ Và vì sao phương án C sai về thuật ngữ:

C nói "Redshift cross-Region
  REPLICATION"
        ↓
    Redshift không có tính năng
      tên đó
        ↓
    Chỉ có cross-Region snapshot COPY
    → sao chép snapshot, không phải
      sao chép liên tục

⚠ Khác biệt giữa hai khái niệm rất quan trọng: | Khái niệm | Nghĩa | |---|---| | Snapshot copy | sao chép bản chụp theo lịch | | Replication | sao chép liên tục từng thay đổi |

Redshift chỉ có snapshot copy
        ↓
    RPO = khoảng cách giữa hai
      snapshot
    → không phải gần bằng 0

⚠ Và cần đặt lịch snapshot phù hợp với RPO:

aws redshift modify-cluster \
  --cluster-identifier cum-y-te \
  --automated-snapshot-retention-period 7

aws redshift create-snapshot-schedule \
  --schedule-definitions "rate(4 hours)" \
  --schedule-identifier lich-4-gio

Snapshot mỗi 4 giờ
        ↓
    RPO tối đa 4 giờ
    → cộng thêm thời gian sao chép
      sang Region đích

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Snapshot ở Region khác, sống sót thảm hoạ vùng | | | Mã hoá bằng khoá địa phương ở đích | | | Tự động, không viết script nào | |

⚠ Và cần cấp quyền trên khoá đích cho Redshift:

{"Sid": "ChoPhepRedshiftDungKhoa",
 "Effect": "Allow",
 "Principal": {"Service": "redshift.amazonaws.com"},
 "Action": ["kms:Encrypt", "kms:Decrypt",
            "kms:GenerateDataKey", "kms:DescribeKey",
            "kms:CreateGrant"],
 "Resource": "*"}

⚠ kms:CreateGrant là quyền hay bị quên:

Redshift cần tạo grant nội bộ để
  dùng khoá
        ↓
    Thiếu quyền này
    → sao chép thất bại với lỗi
      liên quan tới KMS

⚠ Và thời gian giữ ở Region đích đặt riêng:

--retention-period 14

Region nguồn giữ 7 ngày
        ↓
    Region đích giữ 14 ngày
    → cấu hình độc lập
        ↓
    Thường giữ ở đích lâu hơn

⚠ Và tắt sao chép sẽ XOÁ snapshot đã sao chép:

aws redshift disable-snapshot-copy \
  --cluster-identifier cum-y-te

Snapshot TỰ ĐỘNG ở Region đích
  bị xoá
        ↓
    Snapshot THỦ CÔNG vẫn còn
        ↓
    Cẩn thận khi tắt

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

• **A. Tạo IAM role ở Region đích có quyền dùng khoá KMS ở Region nguồn, tạo grant ở Region đích cho khoá ở Region nguồn, rồi bật sao chép ở Region nguồn — đây là phương án gần nhất và vế cuối hoàn toàn đúng, nhưng khoá KMS không dùng được liên Region; snapshot ở đích phải mã hoá bằng khoá của chính Region đó.
• **C. Tạo grant đúng nhưng cấu hình cross-Region replication ở Region nguồn — Redshift không có tính năng replication liên Region, chỉ có snapshot copy.
• **D. Tạo grant ở Region nguồn cho khoá ở Region nguồn và cấu hình sao chép ở Region đích — sai cả hai vị trí.

Ghi nhớ

⚠ Quy tắc vị trí cho sao chép snapshot mã hoá liên Region: | Thành phần | Ở đâu | |---|---| | Khoá KMS | Region ĐÍCH | | Snapshot copy grant | Region ĐÍCH | | Lệnh enable-snapshot-copy | Region NGUỒN (trên cụm) |

Từ khoá nhận diện:

"encrypted Redshift snapshot to another Region" → snapshot copy grant ở Region đích "KMS key is regional" → luôn đúng "Redshift cross-Region replication" → không tồn tại "copy encrypted RDS snapshot" → cũng cần khoá ở Region đích

⚠ RDS cũng có quy tắc tương tự:

aws rds copy-db-snapshot \
  --source-db-snapshot-identifier <arn-nguon> \
  --target-db-snapshot-identifier ban-sao \
  --kms-key-id <khoa-o-region-dich> \
  --region us-east-1

Khác biệt: RDS không cần grant
    → chỉ cần khai khoá đích

Ba lưu ý về KMS: | Lưu ý | Chi tiết | |---|---| | Khoá là tài nguyên theo Region | | | Multi-Region key có bản sao ở nhiều Region | | | Chính sách khoá phải cho phép dịch vụ dùng | |

⚠ Multi-Region key đơn giản hoá việc này:

aws kms create-key --multi-region
aws kms replicate-key --key-id <id> --replica-region us-east-1

Cùng key material ở nhiều Region
        ↓
    Dữ liệu mã hoá ở Region A giải
      mã được ở Region B
        ↓
    Nhưng vẫn phải cấp quyền ở
      từng Region

Ba lưu ý về snapshot Redshift: | Loại | Đặc điểm | |---|---| | Automated | theo lịch, xoá khi hết hạn | | Manual | giữ tới khi tự xoá | | Copied | bản ở Region đích, có hạn giữ riêng |

Ba lưu ý về khôi phục: | Lưu ý | Chi tiết | |---|---| | Khôi phục tạo cụm MỚI | | | Endpoint mới, phải đổi chuỗi kết nối | | | RA3 truy vấn được ngay, DC2 phải nạp hết | |

Ba lưu ý về mã hoá Redshift: | Lưu ý | Chi tiết | |---|---| | Bật mã hoá khi TẠO cụm, hoặc sửa cụm | | | Sửa cụm để bật mã hoá cần di chuyển dữ liệu | | | Hỗ trợ cả KMS và HSM | |

⚠ Bật mã hoá cho cụm đang chạy không tức thì:

Redshift tạo cụm mới đã mã hoá
        ↓
    Chép dữ liệu sang
        ↓
    Cụm ở chế độ chỉ đọc trong
      quá trình đó
    → có thể mất hàng giờ

Ba lưu ý về tuân thủ y tế: | Lưu ý | Chi tiết | |---|---| | Mã hoá khi lưu và khi truyền | | | Bật audit logging của Redshift | | | Ký BAA với AWS cho HIPAA | |

Ba lưu ý về giám sát: | Việc | Cách | |---|---| | Kiểm snapshot mới nhất ở Region đích | describe-cluster-snapshots --region <đích> | | Cảnh báo khi sao chép thất bại | EventBridge bắt sự kiện Redshift | | Theo dõi độ trễ sao chép | so thời điểm snapshot hai bên |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Liệt kê snapshot ở Region đích | | | Khôi phục thử một cụm từ đó | | | Kiểm cụm khôi phục có mã hoá không | |

Và một lời khuyên: hãy kiểm tra danh sách snapshot ở Region đích thay vì tin vào việc lệnh bật sao chép đã chạy thành công. Lỗi quyền trên khoá KMS đích không làm lệnh bật thất bại — nó chỉ khiến từng lần sao chép về sau im lặng không thành, và bạn phát hiện đúng lúc cần khôi phục.

Đáp án

**A — Việc SNS giao tin tới Lambda đã vượt hạn mức đồng thời (concurrency) của tài khoản cho Lambda, nên đội kỹ thuật cần liên hệ AWS Support để nâng hạn mức.

Vì sao đúng

Đề cho một dữ kiện số học rất rõ:

Ngoài mùa: 100 yêu cầu/giây
        ↓
    Cao điểm: 5.000 yêu cầu/giây
        ↓
    Tăng GẤP 50 LẦN
        ↓
    Và thông báo bị mất

⚠ Điểm mấu chốt: Lambda có trần đồng thời ở cấp TÀI KHOẢN:

Mặc định 1.000 lần thực thi đồng
  thời mỗi Region
        ↓
    Vượt trần → Lambda bị chặn
      (throttled)
        ↓
    SNS nhận lỗi 429
    → thử lại theo chính sách
        ↓
    Hết lượt thử → tin bị BỎ

Tính số đồng thời cần:

Số đồng thời = số yêu cầu/giây
               × thời gian chạy (giây)
        ↓
    5.000 × 0,2 giây = 1.000
        ↓
    Hàm chạy 0,5 giây → 2.500
    → vượt trần mặc định

Xem hạn mức hiện tại:

aws lambda get-account-settings \
  --query 'AccountLimit.ConcurrentExecutions'

aws service-quotas get-service-quota \
  --service-code lambda \
  --quota-code L-B99A9384

Xin nâng hạn mức:

aws service-quotas request-service-quota-increase \
  --service-code lambda \
  --quota-code L-B99A9384 \
  --desired-value 5000

⚠ Và vì sao phương án B sai — SNS không có "concurrency limit":

SNS có hạn mức về số tin nhắn
  mỗi giây (rất cao)
        ↓
    Nhưng không có khái niệm
      "concurrency"
        ↓
    SNS là dịch vụ đẩy, nó không
      chạy mã của bạn

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

"Cấp thêm máy chủ chạy dịch vụ
  Lambda"
        ↓
    "Cấp thêm máy chủ chạy dịch vụ
      SNS"
        ↓
    Cả Lambda lẫn SNS đều là dịch
      vụ QUẢN LÝ
    → không có máy chủ nào để cấp

⚠ Và SNS → Lambda không có hàng đợi đệm:

SNS đẩy thẳng tới Lambda
        ↓
    Lambda bị chặn → SNS thử lại
        ↓
    Chính sách thử lại mặc định:
      3 lần ngay, rồi 2 lần với
      khoảng cách, tổng khoảng
      23 giờ
        ↓
    Hết → MẤT (trừ khi có DLQ)

⚠ Đây là lý do chèn SQS vào giữa là mẫu bền vững hơn:

SNS → SQS → Lambda
        ↓
    SQS ĐỆM mọi tin, giữ tới 14 ngày
        ↓
    Lambda bị chặn → tin vẫn nằm
      trong hàng đợi
    → xử lý dần khi có chỗ
        ↓
    Không mất tin nào

aws sns subscribe --topic-arn <arn-topic> \
  --protocol sqs --notification-endpoint <arn-hang-doi>

aws lambda create-event-source-mapping \
  --function-name gui-thong-bao \
  --event-source-arn <arn-hang-doi> \
  --batch-size 10 \
  --scaling-config MaximumConcurrency=500

⚠ Và đặt DLQ cho đăng ký SNS là biện pháp tối thiểu:

aws sns set-subscription-attributes \
  --subscription-arn <arn-dang-ky> \
  --attribute-name RedrivePolicy \
  --attribute-value '{"deadLetterTargetArn":
    "arn:aws:sqs:ap-southeast-1:111122223333:sns-loi"}'

Tin không giao được sau khi thử
  hết lượt
        ↓
    Vào DLQ thay vì biến mất
    → xử lý lại được sau

Ba lợi ích của việc nâng hạn mức: | Lợi ích | Chi tiết | |---|---| | Giải quyết đúng nguyên nhân | | | Miễn phí — chỉ trả cho lượng dùng thật | | | Không đổi kiến trúc | |

⚠ Và nâng hạn mức là miễn phí:

Trần đồng thời không tính tiền
        ↓
    Chỉ trả cho số lượt gọi và
      GB-giây thật sự dùng
        ↓
    Nên nâng trần dự phòng trước
      mùa cao điểm

⚠ Và nên đặt reserved concurrency cho hàm quan trọng:

aws lambda put-function-concurrency \
  --function-name gui-thong-bao \
  --reserved-concurrent-executions 800

Bảo đảm hàm này luôn có 800 chỗ
        ↓
    Hàm khác trong tài khoản không
      chiếm mất
        ↓
    Nhưng cũng giới hạn nó ở 800

⚠ Và theo dõi chỉ số Throttles là cách phát hiện sớm:

aws cloudwatch put-metric-alarm \
  --alarm-name lambda-bi-chan \
  --namespace AWS/Lambda --metric-name Throttles \
  --dimensions Name=FunctionName,Value=gui-thong-bao \
  --statistic Sum --period 60 \
  --evaluation-periods 1 --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold

`Throttles` lớn hơn 0
        ↓
    Đang mất tin
    → cảnh báo ngay

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

• **B. SNS đã chạm giới hạn đồng thời, cần liên hệ AWS Support nâng hạn mức — đây là phương án gần nhất và thật sự nhắc tới việc nâng hạn mức qua Support, nhưng SNS không có khái niệm concurrency; nút thắt nằm ở Lambda.
• **C. Cần cấp thêm máy chủ chạy dịch vụ Lambda — Lambda là dịch vụ quản lý, không có máy chủ nào để cấp.
• **D. Cần cấp thêm máy chủ chạy dịch vụ SNS — cùng lý do.

Ghi nhớ

⚠ Bốn hạn mức của Lambda phải thuộc: | Hạn mức | Giá trị mặc định | |---|---| | Đồng thời mỗi Region | 1.000 (nâng lên được) | | Timeout | 15 phút | | Bộ nhớ | 128 MB - 10 GB | | Kích thước payload | 6 MB (đồng bộ), 256 KB (bất đồng bộ) |

Từ khoá nhận diện:

"notifications not delivered at peak" → kiểm Throttles của Lambda "provision more servers for Lambda" → luôn SAI "buffer between SNS and Lambda" → chèn SQS "guarantee capacity for a function" → reserved concurrency

Ba cơ chế đồng thời của Lambda: | Cơ chế | Ý nghĩa | |---|---| | Unreserved | dùng chung trần tài khoản | | Reserved | dành riêng và giới hạn cho một hàm | | Provisioned | giữ sẵn môi trường, không có khởi động nguội |

⚠ Reserved và provisioned là hai thứ khác nhau:

Reserved concurrency: dành CHỖ
        ↓
    Provisioned concurrency: giữ
      môi trường ĐÃ KHỞI TẠO SẴN
        ↓
    Provisioned tính tiền theo giờ
    → reserved thì không

Ba lưu ý về tốc độ co giãn: | Lưu ý | Chi tiết | |---|---| | Burst ban đầu 500-3.000 tuỳ Region | | | Sau đó tăng 500 mỗi 10 giây mỗi hàm | | | Đỉnh tăng đột ngột vẫn bị chặn lúc đầu | |

⚠ Đây là lý do đỉnh gấp 50 lần gây vấn đề:

Từ 100 lên 5.000 yêu cầu/giây
        ↓
    Ngay cả khi trần đủ cao
    → tốc độ co giãn vẫn có giới hạn
        ↓
    SQS đệm giúp vượt qua giai
      đoạn này

Ba lưu ý về SNS: | Lưu ý | Chi tiết | |---|---| | Không lưu giữ tin nhắn | | | Thử lại theo chính sách rồi bỏ | | | Luôn đặt DLQ cho đăng ký quan trọng | |

Ba lưu ý về mẫu SNS + SQS: | Lợi ích | Chi tiết | |---|---| | Đệm khi có đỉnh | | | Nhiều consumer độc lập | | | Không mất tin khi consumer chết | |

Ba lưu ý về Service Quotas: | Lưu ý | Chi tiết | |---|---| | Xem và xin nâng qua console hoặc API | | | Đặt cảnh báo khi sắp chạm hạn mức | | | Xin nâng TRƯỚC mùa cao điểm | |

⚠ Cảnh báo khi sắp chạm hạn mức:

aws cloudwatch put-metric-alarm \
  --alarm-name sap-cham-tran-lambda \
  --namespace AWS/Lambda \
  --metric-name ConcurrentExecutions \
  --statistic Maximum --period 60 \
  --evaluation-periods 1 --threshold 800 \
  --comparison-operator GreaterThanThreshold

Ba chỉ số cần theo dõi: | Chỉ số | Ý nghĩa | |---|---| | Throttles | bị chặn, đang mất việc | | ConcurrentExecutions | đang dùng bao nhiêu chỗ | | Errors | hàm lỗi bao nhiêu lần |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem Throttles trong mùa cao điểm | | | Kiểm DLQ có tin không | | | Chạy thử tải ở 5.000 yêu cầu/giây | |

Và một lời khuyên: hãy xin nâng hạn mức đồng thời trước mùa cao điểm chứ đừng chờ tới lúc bị chặn. Yêu cầu nâng hạn mức có thể mất vài ngày để AWS xử lý — và trong bóng chày, mùa giải không dời lịch để chờ một ticket support.

Đáp án

**C, D và F — Cấu hình security group cho phép lưu lượng VÀO từ chính cụm và từ các client trên cổng 6379; bật mã hoá cả khi truyền lẫn khi lưu; và tạo cụm với tham số auth-token, kèm token đó trong mọi lệnh gửi tới cụm.

Vì sao đúng

Ba đáp án là ba lớp bảo vệ khác nhau, và cần cả ba: | Lớp | Chống gì | |---|---| | Security group (C) | ai kết nối tới được cụm | | Mã hoá (D) | nghe lén và đọc dữ liệu trên đĩa | | AUTH token (F) | ai đã kết nối được thì có được phép chạy lệnh không |

⚠ Điểm mấu chốt thứ nhất: security group cần quy tắc VÀO, không phải RA:

Client kết nối TỚI cụm
        ↓
    Đó là lưu lượng ĐI VÀO cụm
        ↓
    Quy tắc RA (phương án B) không
      liên quan
    → security group là stateful,
      phản hồi tự đi ra được

⚠ Và "từ chính cụm" là chi tiết riêng của Redis cluster mode:

Cluster mode: nhiều shard, mỗi shard
  có primary và replica
        ↓
    Các node nói chuyện với nhau
      để đồng bộ và bầu chọn
        ↓
    Thiếu quy tắc cho phép chính
      security group đó
    → cụm không hình thành được

aws ec2 authorize-security-group-ingress \
  --group-id sg-elasticache \
  --protocol tcp --port 6379 --source-group sg-elasticache

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

⚠ Điểm mấu chốt thứ hai: mã hoá phải bật LÚC TẠO cụm:

aws elasticache create-replication-group \
  --replication-group-id cum-phan-tich \
  --replication-group-description "cum redis" \
  --engine redis --cache-node-type cache.r6g.large \
  --num-node-groups 3 --replicas-per-node-group 1 \
  --transit-encryption-enabled \
  --at-rest-encryption-enabled \
  --auth-token 'ChuoiBiMatRatDaiVaKhoDoan123'

`at-rest-encryption-enabled` và
  `transit-encryption-enabled`
        ↓
    KHÔNG bật được cho cụm đã tồn tại
      (với engine cũ)
    → phải tạo cụm mới và di chuyển
        ↓
    Redis 7 trở lên cho phép bật
      in-transit trên cụm đang chạy

⚠ Điểm mấu chốt thứ ba: AUTH token BẮT BUỘC phải có mã hoá khi truyền:

`--auth-token` chỉ dùng được khi
  `--transit-encryption-enabled`
        ↓
    Vì nếu không mã hoá, token đi
      dạng rõ trên mạng
    → ai bắt gói tin là có token
        ↓
    Đây là lý do D và F đi cùng nhau

Kết nối có token:

import redis
r = redis.RedisCluster(
    host='cum-phan-tich.abc.clustercfg.apse1.cache.amazonaws.com',
    port=6379, ssl=True,
    password='ChuoiBiMatRatDaiVaKhoDoan123')

⚠ Và vì sao phương án A (CloudTrail) không đủ:

CloudTrail ghi lời gọi API QUẢN TRỊ
        ↓
    Ai tạo cụm, ai sửa tham số,
      ai xoá
        ↓
    KHÔNG ghi lệnh Redis
    → `GET`, `SET` không xuất hiện
      ở đâu

⚠ Và vì sao phương án E vô nghĩa:

E nói "bật CloudWatch Logs để giám
  sát THÔNG TIN ĐĂNG NHẬP của cụm"
        ↓
    CloudWatch Logs không giám sát
      credential
        ↓
    ElastiCache có slow log và
      engine log — nhưng đó là log
      hiệu năng, không phải bảo mật

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chỉ client được phép mới kết nối được | | | Dữ liệu mã hoá cả trên đường lẫn trên đĩa | | | Kết nối được vẫn phải có token mới chạy lệnh | |

⚠ Và RBAC là cách hiện đại hơn AUTH token:

aws elasticache create-user \
  --user-id ung-dung-doc \
  --user-name ung-dung-doc \
  --engine redis \
  --passwords 'MatKhauRatDai...' \
  --access-string 'on ~cache:* -@all +@read'

AUTH token: một mật khẩu cho MỌI
  người, mọi quyền
        ↓
    RBAC: nhiều người dùng, mỗi
      người một tập lệnh và tập khoá
    → quyền tối thiểu thật sự

⚠ Và ElastiCache phải nằm trong subnet riêng:

Cụm không nên có đường ra Internet
        ↓
    Đặt trong private subnet
    → chỉ ứng dụng trong VPC chạm tới
        ↓
    ElastiCache không có endpoint
      công khai — nhưng subnet công
      khai vẫn tăng rủi ro

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

• **B. Cấu hình security group cho phép lưu lượng ĐI RA tới các client trên cổng 6379 — đây là phương án gần nhất và chỉ khác đáp án đúng ở một từ, nhưng client kết nối tới cụm nên đó là lưu lượng đi vào; security group là stateful nên phản hồi tự đi ra được.
• **A. Bật CloudTrail để giám sát lời gọi API của cụm — CloudTrail ghi thao tác quản trị, không ghi lệnh Redis; hữu ích cho kiểm toán nhưng không bảo vệ dữ liệu.
• **E. Bật CloudWatch Logs để giám sát thông tin đăng nhập — CloudWatch Logs không có chức năng như vậy.

Ghi nhớ

⚠ Bốn lớp bảo mật của ElastiCache — bảng phải thuộc: | Lớp | Cơ chế | |---|---| | Mạng | VPC, subnet riêng, security group | | Mã hoá khi truyền | TLS | | Mã hoá khi lưu | KMS | | Xác thực | AUTH token hoặc RBAC |

Từ khoá nhận diện:

"secure ElastiCache cluster" → SG + mã hoá + AUTH "cluster mode enabled" → SG phải cho phép chính nó "fine-grained user permissions" → RBAC "AUTH token" → bắt buộc bật in-transit encryption

Ba lưu ý về mã hoá ElastiCache: | Lưu ý | Chi tiết | |---|---| | At-rest bật lúc TẠO, không sửa sau | | | In-transit làm giảm hiệu năng một chút | | | Memcached chỉ hỗ trợ in-transit (từ 1.6.12) | |

⚠ Redis và Memcached khác nhau về bảo mật: | Tính năng | Redis | Memcached | |---|---|---| | Mã hoá khi lưu | CÓ | không | | AUTH/RBAC | CÓ | SASL (giới hạn) | | Sao chép | CÓ | không |

Ba lưu ý về AUTH token: | Lưu ý | Chi tiết | |---|---| | 16-128 ký tự, không có ký tự đặc biệt nhất định | | | Xoay được bằng modify-replication-group | | | Chế độ ROTATE cho phép hai token cùng lúc | |

⚠ Xoay token không gián đoạn:

aws elasticache modify-replication-group \
  --replication-group-id cum-phan-tich \
  --auth-token 'TokenMoi...' \
  --auth-token-update-strategy ROTATE

Giai đoạn ROTATE: cả token cũ và
  mới đều dùng được
        ↓
    Cập nhật ứng dụng
        ↓
    Rồi SET để bỏ token cũ

Ba lưu ý về sẵn sàng cao: | Lưu ý | Chi tiết | |---|---| | Multi-AZ với automatic failover | | | Replica ở AZ khác primary | | | Cluster mode chia dữ liệu ra nhiều shard | |

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | CacheHitRate | cache có hiệu quả không | | Evictions | bộ nhớ thiếu, đang đẩy dữ liệu ra | | CurrConnections | có chạm trần kết nối không |

Ba lưu ý về Secrets Manager: | Lưu ý | Chi tiết | |---|---| | Lưu AUTH token trong Secrets Manager | | | Đừng cài cứng trong mã hoặc biến môi trường | | | Ứng dụng đọc lúc khởi động | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết nối không có token — phải bị từ chối | | | Kết nối từ ngoài security group — phải timeout | | | Kiểm cụm báo TransitEncryptionEnabled: true | |

Và một lời khuyên: hãy bật cả hai loại mã hoá ngay khi tạo cụm, kể cả khi chưa có yêu cầu tuân thủ nào. Mã hoá khi lưu không bật được cho cụm đã tồn tại — muốn thêm về sau, bạn phải dựng cụm mới và di chuyển toàn bộ dữ liệu.

Đáp án

**D — Dùng Serverless Application Model (SAM) và tận dụng tính năng chuyển dịch lưu lượng có sẵn để triển khai phiên bản Lambda mới qua CodeDeploy, dùng hàm kiểm tra pre-traffic và post-traffic để xác minh, và quay lui khi CloudWatch alarm kích hoạt.

Vì sao đúng

Đề nêu hai mục tiêu, và SAM giải quyết cả hai bằng cơ chế có sẵn: | Mục tiêu | Cách đáp ứng | |---|---| | Giảm thời gian triển khai | SAM khai báo, CodeDeploy tự chuyển lưu lượng | | Phát hiện và quay lui nhanh khi lỗi | CloudWatch alarm tự kích hoạt rollback |

⚠ Điểm mấu chốt: SAM có tính năng chuyển dịch lưu lượng chỉ bằng vài dòng khai báo:

Resources:
  HamXuLy:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.xu_ly
      Runtime: python3.12
      AutoPublishAlias: prod
      DeploymentPreference:
        Type: Canary10Percent5Minutes
        Alarms:
          - !Ref CanhBaoLoi
          - !Ref CanhBaoDoTre
        Hooks:
          PreTraffic: !Ref HamKiemTraTruoc
          PostTraffic: !Ref HamKiemTraSau

⚠ AutoPublishAlias là dòng làm mọi thứ hoạt động:

SAM tự xuất bản phiên bản mới
  mỗi lần mã đổi
        ↓
    Và tạo/cập nhật alias `prod`
        ↓
    CodeDeploy chuyển dần trọng số
      của alias từ phiên bản cũ
      sang mới

⚠ Và alias có trọng số là cơ chế nền tảng:

aws lambda update-alias --function-name ham-xu-ly \
  --name prod --function-version 12 \
  --routing-config AdditionalVersionWeights={"13"=0.1}

90% lời gọi → phiên bản 12
10% lời gọi → phiên bản 13
        ↓
    Lỗi chỉ ảnh hưởng 10% người dùng

⚠ Và các kiểu chuyển dịch có sẵn: | Kiểu | Cách chuyển | |---|---| | Canary10Percent5Minutes | 10% trong 5 phút rồi 100% | | Linear10PercentEvery1Minute | tăng 10% mỗi phút | | AllAtOnce | chuyển hết ngay |

⚠ Và alarm là thứ biến việc quay lui thành tự động:

CloudWatch alarm chuyển sang ALARM
        ↓
    CodeDeploy DỪNG việc chuyển dịch
        ↓
    Và tự đưa trọng số về phiên
      bản cũ
    → không cần ai bấm nút

CanhBaoLoi:
  Type: AWS::CloudWatch::Alarm
  Properties:
    MetricName: Errors
    Namespace: AWS/Lambda
    Dimensions:
      - Name: Resource
        Value: !Sub "${HamXuLy}:live"
    Statistic: Sum
    Period: 60
    EvaluationPeriods: 1
    Threshold: 5
    ComparisonOperator: GreaterThanThreshold

⚠ Và hook kiểm tra chạy ở hai thời điểm khác nhau: | Hook | Khi nào | |---|---| | PreTraffic | TRƯỚC khi chuyển lưu lượng nào | | PostTraffic | SAU khi chuyển xong 100% |

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

def kiem_tra_truoc(event, context):
    ket_qua = 'Succeeded'
    try:
        phan_hoi = lambda_client.invoke(
            FunctionName=ARN_PHIEN_BAN_MOI,
            Payload=json.dumps({'kiem_thu': True}))
        if phan_hoi['StatusCode'] != 200:
            ket_qua = 'Failed'
    except Exception:
        ket_qua = 'Failed'
    codedeploy.put_lifecycle_event_hook_execution_status(
        deploymentId=event['DeploymentId'],
        lifecycleEventHookExecutionId=event['LifecycleEventHookExecutionId'],
        status=ket_qua)

⚠ Và vì sao ba phương án CloudFormation (A, B, C) thua:

Rollback của CloudFormation phải
  dựng lại tài nguyên
        ↓
    Chậm hơn nhiều so với việc đổi
      trọng số alias
        ↓
    Và nó là chuyển ĐỒNG LOẠT
    → 100% người dùng gặp lỗi
      trước khi ai phát hiện

⚠ Và phương án B nói sai về change set:

B nói dùng "pre-traffic và
  post-traffic test function của
  CHANGE SET"
        ↓
    Change set không có khái niệm đó
    → đó là tính năng của CodeDeploy

⚠ Và phương án C tạo API Gateway endpoint MỚI mỗi lần:

Mỗi lần triển khai lại dựng một
  endpoint mới
        ↓
    Rồi đổi origin của CloudFront
        ↓
    Đổi origin CloudFront mất vài
      phút để lan
    → chậm hơn hẳn, và tích luỹ
      endpoint rác

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lỗi chỉ ảnh hưởng một phần nhỏ người dùng | | | Quay lui tự động trong vài giây | | | Toàn bộ khai báo trong template, không có script | |

⚠ Và SAM sinh ra CloudFormation ở phía dưới:

`sam deploy` → biến đổi thành
  CloudFormation template
        ↓
    Vẫn có change set, drift
      detection, stack policy
        ↓
    SAM chỉ là cú pháp rút gọn cho
      tài nguyên serverless

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

• **A. Dùng nested CloudFormation stack, tạo change set và deploy, quay lui bằng cách rollback stack — đây là phương án gần nhất và rollback của CloudFormation thật sự tự động khi triển khai thất bại, nhưng nó chuyển đồng loạt 100% lưu lượng và rollback phải dựng lại tài nguyên, chậm hơn nhiều so với đổi trọng số alias.
• **B. Như A nhưng dùng "pre-traffic và post-traffic test function của change set" — change set không có cơ chế đó; đó là hook của CodeDeploy.
• **C. Dựng API Gateway endpoint mới trỏ tới phiên bản Lambda mới rồi đổi origin CloudFront — tạo tài nguyên mới mỗi lần triển khai, và đổi origin CloudFront chậm hơn đổi trọng số alias.

Ghi nhớ

⚠ Ba kiểu triển khai Lambda — bảng phải thuộc: | Kiểu | Rủi ro | |---|---| | AllAtOnce | cao nhất | | Linear | trung bình, thời gian dài hơn | | Canary | thấp nhất, phát hiện sớm |

Từ khoá nhận diện:

"gradual rollout with automatic rollback" → SAM + CodeDeploy "test before and after traffic shift" → pre/post-traffic hook "weighted alias" → cơ chế nền của traffic shifting "rollback on CloudWatch alarm" → DeploymentPreference.Alarms

Ba lưu ý về alias: | Lưu ý | Chi tiết | |---|---| | Alias trỏ tới một phiên bản cụ thể | | | Trọng số chia được giữa hai phiên bản | | | $LATEST không dùng cho sản xuất | |

⚠ Đừng trỏ trigger vào $LATEST:

API Gateway gọi `$LATEST`
        ↓
    Mọi lần cập nhật mã có hiệu lực
      NGAY
    → không có chỗ nào để canary
        ↓
    Trỏ vào alias `prod`

Ba lưu ý về hook: | Lưu ý | Chi tiết | |---|---| | Phải gọi put_lifecycle_event_hook_execution_status | | | Không gọi → CodeDeploy chờ tới timeout rồi thất bại | | | Hook là Lambda riêng, cần quyền codedeploy:PutLifecycleEventHookExecutionStatus | |

Ba lưu ý về alarm cho canary: | Alarm | Đo gì | |---|---| | Errors | hàm ném lỗi | | Duration p99 | chậm hơn bình thường | | Chỉ số nghiệp vụ | tỷ lệ chuyển đổi giảm |

⚠ Alarm phải gắn với ALIAS, không phải hàm:

Dimension: Resource = ham:live
        ↓
    Nếu gắn với FunctionName
    → đo cả hai phiên bản gộp lại
    → lỗi của 10% bị pha loãng

Ba lưu ý về provisioned concurrency: | Lưu ý | Chi tiết | |---|---| | Gắn với một phiên bản hoặc alias | | | SAM tự quản khi dùng traffic shifting | | | Tính phí theo giờ | |

Ba lưu ý về SAM: | Lệnh | Việc | |---|---| | sam build | đóng gói phụ thuộc | | sam local invoke | chạy thử tại chỗ | | sam deploy --guided | triển khai lần đầu |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cố ý đẩy bản lỗi, xem có tự quay lui không | | | Đo thời gian từ lúc lỗi tới lúc quay lui xong | | | Kiểm hook có chạy và báo trạng thái đúng | |

Và một lời khuyên: hãy gắn alarm vào alias chứ đừng gắn vào tên hàm. Trong giai đoạn canary, chỉ 10% lưu lượng chạy phiên bản mới — nếu alarm đo gộp cả hai phiên bản thì tín hiệu lỗi bị pha loãng đúng mười lần, và việc quay lui tự động sẽ không bao giờ kích hoạt.