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

Tìm thấy 1221 câu.

Câu 321 Accelerate Workload Migration and Modernization

An e-commerce company is planning to migrate its IT infrastructure from the on-premises data center to AWS Cloud to ramp up its capabilities well in time for the upcoming Holiday Sale season. The company’s CTO has hired you as an AWS Certified Solutions Architect Professional to design a distributed, highly available and loosely coupled order processing application. The application is responsible for receiving and processing orders before storing them in a DynamoDB table. The application has seen sporadic traffic spikes in the past and the CTO wants the application to be able to scale during marketing campaigns to process the orders with minimal disruption.

Which of the following options would you recommend as the MOST reliable solution to address these requirements?

A
Push the orders to Kinesis Data Streams and use Amazon EC2 instances to process them
B
Ingest the orders via a Step Function state machine and trigger an ECS container to process them
C
Push the orders to an SNS topic and subscribe a Lambda function to process them
D
Ingest the orders in an SQS queue and trigger a Lambda function to process them

Xem giải thích

Đáp án

**D — Nhận đơn hàng vào một hàng đợi SQS và kích hoạt một hàm Lambda xử lý chúng.

Vì sao đúng

Đề nêu bốn yêu cầu, và SQS + Lambda khớp cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | Phân tán, ghép lỏng | hàng đợi tách người gửi khỏi người xử lý | | Sẵn sàng cao | cả hai đều tự trải nhiều AZ | | Chịu đỉnh đột ngột | hàng đợi đệm, Lambda tự co giãn | | Đáng tin cậy nhất | tin nhắn không mất, có thử lại và DLQ |

⚠ Điểm mấu chốt: "đáng tin cậy nhất" — SQS không mất tin nhắn:

Tin nhắn nằm trong hàng đợi tới
  khi được xử lý XONG
        ↓
    Consumer chết giữa chừng
    → visibility timeout hết hạn
    → tin nhắn hiện lại
        ↓
    Xử lý hỏng nhiều lần
    → chuyển sang dead-letter queue

⚠ Và đây là lý do phương án C (SNS) thua:

SNS là mô hình PUSH, không lưu trữ
        ↓
    Lambda bị chặn (throttle) hoặc
      lỗi
    → SNS thử lại theo chính sách
      rồi BỎ CUỘC
        ↓
    Đơn hàng MẤT

Tiêu chí	SQS	SNS
Mô hình	kéo (poll)	đẩy (push)
Lưu giữ	tới 14 ngày	KHÔNG lưu
Đệm khi đỉnh	CÓ	không
Thứ tự	FIFO có	FIFO có

Với đơn hàng — thứ không được
  phép mất
        ↓
    Hàng đợi là lựa chọn đúng

⚠ Nhưng SNS + SQS kết hợp là mẫu tốt hơn nữa:

SNS topic → nhiều SQS queue
        ↓
    Một đơn hàng, nhiều hệ thống
      xử lý độc lập
    → kho, thanh toán, gửi thư
        ↓
    Mỗi bên có hàng đợi riêng,
      hỏng không ảnh hưởng nhau

Cấu hình hàng đợi có DLQ:

aws sqs create-queue --queue-name don-hang \
  --attributes '{
    "VisibilityTimeout": "180",
    "MessageRetentionPeriod": "1209600",
    "RedrivePolicy": "{\"deadLetterTargetArn\":
      \"arn:aws:sqs:ap-southeast-1:111122223333:don-hang-loi\",
      \"maxReceiveCount\":\"3\"}"}'

Nối Lambda vào hàng đợi:

aws lambda create-event-source-mapping \
  --function-name xu-ly-don-hang \
  --event-source-arn <arn-hang-doi> \
  --batch-size 10 \
  --maximum-batching-window-in-seconds 5 \
  --scaling-config MaximumConcurrency=200

⚠ VisibilityTimeout phải LỚN HƠN timeout của Lambda:

Lambda timeout 60 giây
    → visibility timeout 30 giây
        ↓
    Tin nhắn hiện lại trước khi
      xử lý xong
    → hai lần xử lý cùng một đơn
        ↓
    AWS khuyến nghị: visibility
      timeout = 6 lần timeout hàm

⚠ Và Lambda tự co giãn theo độ dài hàng đợi:

Hàng đợi bắt đầu có tin
    → Lambda khởi động 5 phiên bản
        ↓
    Còn tồn đọng → tăng thêm 60
      phiên bản mỗi phút
        ↓
    Tới trần đồng thời của tài khoản
    → đây chính là "co giãn khi có
      chiến dịch tiếp thị"

⚠ Và vì sao phương án A (Kinesis + EC2) nặng nề hơn:

Kinesis Data Streams: phải quản
  shard, hoặc chọn on-demand
        ↓
    EC2 xử lý: phải dựng ASG, phải
      vá máy, phải làm HA
        ↓
    Và Kinesis sinh ra cho DỮ LIỆU
      LUỒNG cần thứ tự và phát lại
    → không phải cho hàng đợi việc

⚠ Kinesis và SQS khác nhau ở mục đích: | Tiêu chí | SQS | Kinesis Data Streams | |---|---|---| | Sau khi xử lý | tin nhắn bị xoá | dữ liệu vẫn còn tới hết hạn giữ | | Nhiều consumer độc lập | mỗi tin một consumer | nhiều consumer đọc cùng dữ liệu | | Thứ tự | FIFO queue | theo shard | | Phát lại | không | CÓ |

⚠ Và vì sao phương án B (Step Functions + ECS) không hợp:

Step Functions điều phối LUỒNG
  nhiều bước
        ↓
    Nhận đơn hàng là một bước đơn
      giản
    → không cần máy trạng thái
        ↓
    Và ECS container phải chờ sẵn
    → không co giãn nhanh bằng
      Lambda

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có máy chủ nào phải quản | | | Đỉnh tải được hàng đợi hấp thụ | | | Tin nhắn hỏng đi vào DLQ, không mất | |

⚠ Và xử lý phải chịu được lặp lại:

SQS Standard giao ÍT NHẤT một lần
        ↓
    Cùng một đơn có thể xử lý hai lần
        ↓
    Dùng mã đơn làm khoá và
      ConditionExpression

try:
    bang.put_item(
        Item={'ma_don': ma, 'trang_thai': 'da-nhan', ...},
        ConditionExpression='attribute_not_exists(ma_don)')
except bang.meta.client.exceptions.ConditionalCheckFailedException:
    return   # đã xử lý rồi, bỏ qua

⚠ Và nếu thứ tự quan trọng thì dùng FIFO queue:

Đơn hàng của cùng một khách phải
  xử lý theo thứ tự
        ↓
    FIFO với `MessageGroupId` =
      mã khách hàng
        ↓
    Trong cùng nhóm: đúng thứ tự
    → khác nhóm: song song

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

**C. Đẩy đơn hàng vào SNS topic và đăng ký một Lambda xử lý — đây là phương án gần nhất và cũng ghép lỏng và không cần máy chủ, nhưng SNS không lưu trữ; khi Lambda bị chặn hoặc lỗi kéo dài, SNS thử lại rồi bỏ cuộc và đơn hàng mất.
**A. Đẩy đơn hàng vào Kinesis Data Streams và dùng EC2 xử lý — phải quản shard và đội EC2; Kinesis hợp với dữ liệu luồng cần phát lại, không phải hàng đợi việc.
**B. Nhận đơn qua Step Functions và kích hoạt container ECS — máy trạng thái là công cụ quá nặng cho một bước nhận đơn, và container không co giãn nhanh bằng Lambda.

Ghi nhớ

⚠ Bốn dịch vụ ghép lỏng — bảng phải thuộc: | Dịch vụ | Mô hình | Dùng khi | |---|---|---| | SQS | hàng đợi, kéo | việc cần xử lý một lần, không được mất | | SNS | chủ đề, đẩy | một sự kiện, nhiều bên quan tâm | | EventBridge | bus sự kiện, lọc theo mẫu | định tuyến sự kiện phức tạp | | Kinesis | luồng, có phát lại | dữ liệu chuỗi, nhiều consumer đọc lại |

Từ khoá nhận diện:

"decouple, must not lose messages" → SQS "fan-out to multiple subscribers" → SNS (hoặc SNS → nhiều SQS) "route events by content" → EventBridge "replay data, multiple consumers read same records" → Kinesis "strict ordering" → SQS FIFO hoặc Kinesis theo shard

Ba lưu ý về SQS: | Lưu ý | Chi tiết | |---|---| | Giữ tin tối đa 14 ngày | | | Visibility timeout lớn hơn thời gian xử lý | | | Long polling giảm lời gọi rỗng | |

⚠ Long polling nên bật mặc định:

--attributes ReceiveMessageWaitTimeSeconds=20

Short polling: trả về ngay dù
  hàng đợi rỗng
    → tốn rất nhiều lời gọi API
        ↓
    Long polling: chờ tới 20 giây
    → giảm chi phí và độ trễ

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

aws sqs start-message-move-task \
  --source-arn <arn-dlq> \
  --destination-arn <arn-hang-doi-chinh>

Ba lưu ý về Lambda với SQS: | Lưu ý | Chi tiết | |---|---| | Batch size tối đa 10 (Standard) hoặc 10.000 với batching window | | | Báo lỗi một tin làm cả lô quay lại | | | ReportBatchItemFailures chỉ trả lại tin lỗi | |

⚠ ReportBatchItemFailures rất đáng bật:

def xu_ly(event, context):
    that_bai = []
    for ban_ghi in event['Records']:
        try:
            xu_ly_don(json.loads(ban_ghi['body']))
        except Exception:
            that_bai.append({'itemIdentifier': ban_ghi['messageId']})
    return {'batchItemFailures': that_bai}

Không có: một tin lỗi làm 9 tin
  đã xử lý xong quay lại
        ↓
    Có: chỉ tin lỗi quay lại

Ba lưu ý về FIFO: | Lưu ý | Chi tiết | |---|---| | MessageGroupId bắt buộc | | | Thông lượng 3.000 msg/s với batching | | | Khử trùng lặp trong 5 phút | |

Ba lưu ý về co giãn: | Lưu ý | Chi tiết | |---|---| | Lambda tăng 60 phiên bản/phút cho SQS | | | Đặt MaximumConcurrency để không nuốt hết trần tài khoản | | | ASG co giãn được theo độ dài hàng đợi | |

⚠ Đặt trần đồng thời để bảo vệ hệ thống phía sau:

Lambda co giãn tới 1.000 phiên bản
        ↓
    1.000 kết nối đồng thời tới
      DynamoDB hoặc RDS
    → CSDL bị quá tải
        ↓
    `MaximumConcurrency` giới hạn lại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo ApproximateAgeOfOldestMessage | | | Kiểm DLQ có tin không | | | Chạy thử tải với đỉnh dự kiến | |

Và một lời khuyên: hãy đặt cảnh báo trên ApproximateAgeOfOldestMessage chứ đừng chỉ nhìn số tin trong hàng đợi. Một hàng đợi dài mà đang được tiêu thụ nhanh thì hoàn toàn bình thường — nhưng một tin nhắn đã nằm đó bốn tiếng nghĩa là có thứ gì đó đã kẹt, và đó mới là tín hiệu cần biết.

Câu 322 Continuous Improvement for Existing Solutions

An Internet-of-Things (IoT) company is using Kinesis Data Streams (KDS) to process IoT data from field devices. Multiple consumer applications are using the incoming data streams and the engineers have noticed a performance lag for the data delivery speed between producers and consumers of the data streams.

As a Solutions Architect Professional, which of the following would you recommend to improve the performance for the given use-case?

A
Use Enhanced Fanout feature of Kinesis Data Streams to support the desired read throughput for the downstream applications
B
Swap out Kinesis Data Streams with SQS Standard queues to support the desired read throughput for the downstream applications
C
Swap out Kinesis Data Streams with SQS FIFO queues to support the desired read throughput for the downstream applications
D
Swap out Kinesis Data Streams with Kinesis Data Firehose to support the desired read throughput for the downstream applications

Xem giải thích

Đáp án

**A — Dùng tính năng Enhanced Fan-Out của Kinesis Data Streams để đáp ứng thông lượng đọc mà các ứng dụng phía sau cần.

Vì sao đúng

Đề mô tả đúng triệu chứng mà Enhanced Fan-Out sinh ra để chữa:

NHIỀU ứng dụng consumer cùng đọc
  một luồng
        ↓
    Độ trễ giữa producer và consumer
      tăng lên
        ↓
    Đây là dấu hiệu kinh điển của
      việc tranh nhau thông lượng đọc

⚠ Điểm mấu chốt: chế độ đọc chia sẻ có trần 2 MB/s MỖI SHARD, chia cho MỌI consumer:

Một shard: 2 MB/s đọc
        ↓
    Một consumer → dùng cả 2 MB/s
        ↓
    Năm consumer → mỗi cái ~400 KB/s
    → và tranh nhau 5 lời gọi
      `GetRecords` mỗi giây

⚠ Enhanced Fan-Out cấp cho MỖI consumer 2 MB/s riêng:

Đăng ký consumer với EFO
        ↓
    Mỗi consumer có ống dẫn riêng
      2 MB/s mỗi shard
        ↓
    Năm consumer → 10 MB/s tổng
    → không ai tranh với ai

Đăng ký consumer:

aws kinesis register-stream-consumer \
  --stream-arn arn:aws:kinesis:ap-southeast-1:111122223333:stream/du-lieu-iot \
  --consumer-name ung-dung-phan-tich

Đọc bằng SubscribeToShard:

kinesis = boto3.client('kinesis')
phan_hoi = kinesis.subscribe_to_shard(
    ConsumerARN='<arn-consumer>',
    ShardId='shardId-000000000000',
    StartingPosition={'Type': 'LATEST'})
for su_kien in phan_hoi['EventStream']:
    for ban_ghi in su_kien['SubscribeToShardEvent']['Records']:
        xu_ly(ban_ghi['Data'])

⚠ Và EFO dùng HTTP/2 push thay vì hỏi vòng: | Tiêu chí | Chia sẻ | Enhanced Fan-Out | |---|---|---| | Cách đọc | GetRecords hỏi vòng | SubscribeToShard đẩy | | Thông lượng | 2 MB/s chia chung | 2 MB/s mỗi consumer | | Độ trễ điển hình | ~200 mili giây | ~70 mili giây | | Chi phí | không thêm | theo consumer-shard-giờ + GB |

Đề nói "độ trễ giữa producer và
  consumer"
        ↓
    EFO giảm cả độ trễ lẫn tranh
      chấp

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

Firehose là dịch vụ PHÂN PHỐI,
  không phải luồng
        ↓
    Nó ghi vào một đích (S3,
      Redshift, OpenSearch)
        ↓
    Nhiều ứng dụng consumer độc lập
    → Firehose không phục vụ được
        ↓
    Và độ trễ tối thiểu 60 giây
    → tệ hơn hẳn

⚠ Và vì sao hai phương án SQS (B, C) sai:

SQS: mỗi tin nhắn được MỘT
  consumer nhận rồi XOÁ
        ↓
    Kinesis: nhiều consumer đọc
      CÙNG một bản ghi
        ↓
    Chuyển sang SQS là mất hẳn
      mô hình nhiều consumer

Muốn nhiều bên nhận cùng dữ liệu
  bằng SQS
    → phải dựng SNS → nhiều SQS
        ↓
    Và mất khả năng phát lại

⚠ Và FIFO queue còn tệ hơn cho thông lượng:

SQS FIFO: 3.000 tin/giây có
  batching
        ↓
    Kinesis: 1.000 bản ghi/giây
      mỗi shard, mở rộng bằng
      cách thêm shard
        ↓
    Với IoT quy mô lớn, FIFO là
      nút thắt

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mỗi consumer có thông lượng riêng | | | Độ trễ giảm khoảng ba lần | | | Không phải đổi kiến trúc | |

⚠ Nhưng EFO tính phí thêm — phải cân nhắc:

Phí theo consumer-shard-giờ
  + phí theo GB đọc
        ↓
    Nhiều shard × nhiều consumer
    → khoản này lớn nhanh
        ↓
    Chỉ đăng ký EFO cho consumer
      thật sự cần độ trễ thấp

⚠ Và cách khác là thêm shard — nhưng nó không giải quyết tranh chấp:

Thêm shard: tăng tổng thông lượng
        ↓
    Nhưng MỖI shard vẫn chỉ 2 MB/s
      chia chung
    → năm consumer vẫn tranh nhau
      trên từng shard
        ↓
    Thêm shard chữa vấn đề thông
      lượng GHI, không chữa tranh
      chấp ĐỌC

⚠ Và cần kiểm chỉ số này để xác nhận chẩn đoán:

aws cloudwatch get-metric-statistics \
  --namespace AWS/Kinesis \
  --metric-name GetRecords.IteratorAgeMilliseconds \
  --dimensions Name=StreamName,Value=du-lieu-iot \
  --statistics Maximum --period 300 \
  --start-time 2026-09-01T00:00:00Z --end-time 2026-09-01T06:00:00Z

`IteratorAge` tăng dần
    → consumer không theo kịp
        ↓
    Đây chính là "độ trễ giữa
      producer và consumer"

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

**D. Thay Kinesis Data Streams bằng Kinesis Data Firehose — đây là phương án gần nhất và Firehose thật sự là dịch vụ trong họ Kinesis xử lý được lượng lớn dữ liệu, nhưng nó chỉ ghi vào một đích chứ không phục vụ nhiều ứng dụng consumer độc lập, và độ trễ tối thiểu 60 giây.
**B. Thay bằng SQS Standard — SQS xoá tin sau khi một consumer nhận; mô hình nhiều consumer đọc cùng dữ liệu không còn.
**C. Thay bằng SQS FIFO — cùng vấn đề, thêm vào đó FIFO có trần thông lượng thấp hơn nhiều.

Ghi nhớ

⚠ Hai chế độ đọc của Kinesis — bảng phải thuộc: | Chế độ | Thông lượng | Độ trễ | Chi phí | |---|---|---|---| | Chia sẻ (GetRecords) | 2 MB/s chia chung mỗi shard | ~200 ms | không thêm | | Enhanced Fan-Out | 2 MB/s MỖI consumer mỗi shard | ~70 ms | theo consumer-shard-giờ |

Từ khoá nhận diện:

"multiple consumers, read throughput contention" → Enhanced Fan-Out "lowest latency streaming" → Enhanced Fan-Out "deliver to S3/Redshift, least ops" → Firehose "one message one worker" → SQS "replay data" → Kinesis (SQS không có)

Ba giới hạn của shard phải thuộc: | Chiều | Giới hạn | |---|---| | Ghi | 1 MB/s hoặc 1.000 bản ghi/giây | | Đọc (chia sẻ) | 2 MB/s, 5 lời gọi GetRecords/giây | | Đọc (EFO) | 2 MB/s mỗi consumer |

Ba lưu ý về Enhanced Fan-Out: | Lưu ý | Chi tiết | |---|---| | Tối đa 20 consumer đăng ký mỗi luồng | | | Dùng SubscribeToShard, không phải GetRecords | | | Đăng ký hết 5 phút mới hoạt động | |

Ba lưu ý về chế độ công suất: | Chế độ | Đặc điểm | |---|---| | Provisioned | tự khai số shard, rẻ hơn khi tải ổn định | | On-demand | tự co giãn tới 200 MB/s, không quản shard |

⚠ On-demand co giãn theo đỉnh trước đó:

Tăng gấp đôi mức cao nhất trong
  30 ngày qua
        ↓
    Đỉnh tăng đột ngột gấp mười
    → vẫn bị chặn một lúc

Ba lưu ý về khoá phân vùng: | Lưu ý | Chi tiết | |---|---| | Quyết định bản ghi vào shard nào | | | Khoá lệch gây shard nóng | | | Cùng khoá thì cùng shard, giữ được thứ tự | |

⚠ Shard nóng là sự cố hay gặp với IoT:

Dùng loại thiết bị làm khoá
    → chỉ vài giá trị
        ↓
    Mọi bản ghi dồn vào vài shard
    → bị chặn dù còn shard rảnh
        ↓
    Dùng mã thiết bị làm khoá
    → phân tán đều

Ba chỉ số cần theo dõi: | Chỉ số | Ý nghĩa | |---|---| | IteratorAgeMilliseconds | consumer tụt lại bao xa | | WriteProvisionedThroughputExceeded | ghi bị chặn | | ReadProvisionedThroughputExceeded | đọc bị chặn |

Ba lưu ý về consumer: | Lựa chọn | Đặc điểm | |---|---| | Lambda | đơn giản nhất, hỗ trợ EFO | | KCL | tự quản checkpoint, cân bằng shard | | Managed Flink | xử lý luồng bằng SQL hoặc Java |

⚠ Lambda với Kinesis cũng dùng được EFO:

aws lambda create-event-source-mapping \
  --function-name xu-ly-iot \
  --event-source-arn <arn-consumer-efo> \
  --starting-position LATEST

Trỏ vào ARN của CONSUMER, không
  phải ARN của luồng

Ba lưu ý về lưu giữ: | Lưu ý | Chi tiết | |---|---| | Mặc định 24 giờ, nâng tới 365 ngày | | | Phát lại được trong khoảng đó | | | Lưu lâu hơn thì tính phí thêm | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So IteratorAge trước và sau khi bật EFO | | | Kiểm ReadProvisionedThroughputExceeded về 0 | | | Đo độ trễ đầu-cuối thật | |

Và một lời khuyên: hãy kiểm IteratorAgeMilliseconds trước khi bật Enhanced Fan-Out. Nếu chỉ số đó tăng đều thì consumer đang không theo kịp và EFO sẽ giúp — nhưng nếu nó bằng phẳng còn ứng dụng vẫn chậm, nút thắt nằm trong chính mã xử lý, và trả thêm tiền cho EFO sẽ không đổi được gì.

Câu 323 Chọn nhiều đáp án Design Solutions for Organizational Complexity

A mobile app based social media company is using Amazon CloudFront to deliver media-rich content to its audience across the world. The Content Delivery Network (CDN) offers a multi-tier cache by default, with regional edge caches that improve latency and lower the load on the origin servers when the object is not already cached at the edge. However, there are certain content types that bypass the regional edge cache and go directly to the origin.

Which of the following content types skip the regional edge cache? (Select two)

A
Static content such as style sheets, JavaScript files
B
Dynamic content, as determined at request time (cache-behavior configured to forward all headers)
C
E-commerce assets such as product photos
D
User-generated videos
E
Proxy methods PUT/POST/PATCH/OPTIONS/DELETE go directly to the origin

Xem giải thích

Đáp án

**B và E — Nội dung động (được xác định tại thời điểm yêu cầu, cache behavior cấu hình chuyển tiếp mọi header) và các phương thức proxy PUT/POST/PATCH/OPTIONS/DELETE đi thẳng tới origin, bỏ qua regional edge cache.

Vì sao đúng

CloudFront có hai tầng cache, và không phải mọi thứ đều đi qua cả hai:

Người xem
    ↓
Điểm biên (edge location) — hơn 600 điểm
    ↓
Regional edge cache — khoảng 13 điểm, cache lớn hơn
    ↓
Origin

⚠ Mục đích của regional edge cache là giữ nội dung lâu hơn:

Điểm biên có cache nhỏ
    → nội dung ít được yêu cầu bị
      đẩy ra sớm
        ↓
    Regional edge cache lớn hơn
    → giữ được lâu hơn
        ↓
    Cache miss ở biên vẫn có thể
      hit ở tầng này
    → giảm tải cho origin

⚠ Và đây là lý do nội dung động bỏ qua tầng đó:

Nội dung động sinh riêng cho từng
  yêu cầu
        ↓
    Không cache được
    → đưa qua một tầng cache nữa
      chỉ thêm một chặng mạng
        ↓
    Đi thẳng tới origin nhanh hơn

⚠ Và "chuyển tiếp mọi header" là dấu hiệu của nội dung không cache được:

Cache key gồm mọi header
        ↓
    Mỗi client có User-Agent khác
      nhau, Accept-Language khác nhau
        ↓
    Gần như mỗi yêu cầu là một
      khoá cache riêng
    → tỷ lệ hit gần bằng 0

⚠ Và các phương thức ghi hiển nhiên không cache được: | Phương thức | Cache được | |---|---| | GET, HEAD | CÓ | | OPTIONS | cache được nếu cấu hình | | PUT, POST, PATCH, DELETE | KHÔNG BAO GIỜ |

Chúng THAY ĐỔI trạng thái ở origin
        ↓
    Cache một lời gọi POST là vô
      nghĩa và nguy hiểm
    → đi thẳng tới origin

⚠ Và OPTIONS nằm trong danh sách bỏ qua dù nó là phương thức đọc:

OPTIONS là yêu cầu preflight
  của CORS
        ↓
    Phản hồi phụ thuộc header
      `Origin` của client
    → và cần tới origin để biết
      chính sách CORS

Cấu hình cache behavior cho nội dung động:

{"PathPattern": "/api/*",
 "TargetOriginId": "alb-ung-dung",
 "CachePolicyId": "4135ea2d-6df8-44a3-9df3-4b5a84be39ad",
 "OriginRequestPolicyId": "216adef6-5c7f-47e4-b989-5492eafa07d3",
 "AllowedMethods": {"Quantity": 7,
   "Items": ["GET","HEAD","OPTIONS","PUT","POST","PATCH","DELETE"]}}

⚠ CachingDisabled và AllViewer là hai chính sách quản lý cần nhớ: | Chính sách | ID | |---|---| | CachingDisabled | 4135ea2d-6df8-44a3-9df3-4b5a84be39ad | | CachingOptimized | 658327ea-f89d-4fab-a63d-7e88639e58f6 | | AllViewer (origin request) | 216adef6-5c7f-47e4-b989-5492eafa07d3 |

⚠ Và vì sao ba phương án còn lại sai — chúng đều là nội dung TĨNH:

A: style sheet, tệp JavaScript
C: ảnh sản phẩm thương mại điện tử
D: video do người dùng đăng
        ↓
    Cả ba đều là object tĩnh
    → cache được ở cả hai tầng
        ↓
    Và video lớn chính là thứ
      regional edge cache có ích
      nhất

⚠ Video là ví dụ điển hình nhất cho lợi ích của tầng này:

Video vài trăm MB
    → kéo lại từ origin rất tốn
        ↓
    Regional edge cache giữ nó
    → nhiều điểm biên trong vùng
      cùng hưởng lợi

Ba lợi ích của regional edge cache: | Lợi ích | Chi tiết | |---|---| | Tỷ lệ hit tổng cao hơn | | | Giảm tải cho origin | | | Tự động, không phải cấu hình gì | |

⚠ Và có thể ép nội dung động đi nhanh hơn bằng Origin Shield:

"OriginShield": {"Enabled": true,
                 "OriginShieldRegion": "ap-southeast-1"}

Origin Shield là tầng cache THỨ BA,
  đặt gần origin
        ↓
    Mọi cache miss gom về một điểm
    → origin chỉ nhận một yêu cầu
      thay vì nhiều
        ↓
    Rất hữu ích khi origin đắt đỏ
      hoặc dễ quá tải

⚠ Và nội dung động vẫn hưởng lợi từ CloudFront dù không cache:

Kết nối TLS kết thúc ở điểm biên
        ↓
    Từ đó tới origin đi trên mạng
      xương sống AWS
    → nhanh hơn và ổn định hơn
      Internet công cộng
        ↓
    Đây là lý do vẫn nên đưa API
      qua CloudFront

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

**D. Video do người dùng đăng — đây là phương án gần nhất và nghe như nội dung "cá nhân hoá" nên có vẻ không cache được, nhưng video là object tĩnh, cache rất tốt, và chính là loại nội dung mà regional edge cache có ích nhất.
**A. Nội dung tĩnh như style sheet, tệp JavaScript — cache được ở cả hai tầng.
**C. Ảnh sản phẩm thương mại điện tử — cũng là object tĩnh, cache bình thường.

Ghi nhớ

⚠ Ba tầng cache của CloudFront — bảng phải thuộc: | Tầng | Số lượng | Kích thước cache | |---|---|---| | Điểm biên | hơn 600 | nhỏ nhất | | Regional edge cache | khoảng 13 | lớn hơn | | Origin Shield | tuỳ chọn, một Region | gom mọi cache miss |

Từ khoá nhận diện:

"bypasses regional edge cache" → nội dung động và phương thức ghi "reduce origin load further" → Origin Shield "cache key too specific" → xem lại cache policy "dynamic content acceleration" → CloudFront vẫn có ích nhờ mạng AWS

Ba lưu ý về cache policy: | Lưu ý | Chi tiết | |---|---| | Quyết định KHOÁ cache: header, cookie, query string | | | Thêm càng nhiều thì cache càng phân mảnh | | | Có chính sách quản lý sẵn cho các trường hợp thường gặp | |

⚠ Phân biệt cache policy và origin request policy:

Cache policy: cái gì tạo thành
  KHOÁ cache
        ↓
    Origin request policy: cái gì
      được CHUYỂN TỚI origin
        ↓
    Origin cần header mà không muốn
      phân mảnh cache
    → để header đó trong origin
      request policy, không để
      trong cache policy

Ba lưu ý về tối ưu tỷ lệ hit: | Cách | Chi tiết | |---|---| | Bỏ header không cần khỏi cache key | | | Chuẩn hoá query string, chỉ giữ tham số có nghĩa | | | Đặt Cache-Control dài cho nội dung bất biến | |

⚠ Query string ngẫu nhiên phá nát cache:

?utm_source=facebook&fbclid=abc123
        ↓
    Mỗi lượt chia sẻ là một khoá
      cache mới
        ↓
    Chỉ giữ tham số thật sự đổi
      nội dung

Ba lưu ý về vô hiệu hoá cache: | Lưu ý | Chi tiết | |---|---| | 1.000 đường dẫn miễn phí mỗi tháng | | | Mất vài phút để lan khắp | | | Tên tệp có mã băm thì không cần | |

Ba lưu ý về hàm ở biên: | Loại | Chạy ở | |---|---| | CloudFront Functions | điểm biên, dưới 1 ms | | Lambda@Edge viewer | điểm biên | | Lambda@Edge origin | regional edge cache |

⚠ Lambda@Edge origin-facing chỉ chạy khi CACHE MISS:

Viewer request: chạy mọi yêu cầu
        ↓
    Origin request: chỉ khi cache
      miss
        ↓
    Đặt logic nặng ở origin-facing
    → chạy ít lần hơn, rẻ hơn

Ba lưu ý về nội dung động: | Lưu ý | Chi tiết | |---|---| | Vẫn nên qua CloudFront vì mạng AWS | | | Bật CachingDisabled, đừng để TTL 0 thủ công | | | WAF gắn vào CloudFront chặn sớm hơn | |

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | CacheHitRate | tỷ lệ phục vụ từ cache | | OriginLatency | origin phản hồi chậm không | | 5xxErrorRate | origin có lỗi không |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem header X-Cache trong phản hồi | | | Hit from cloudfront hay Miss from cloudfront | | | Bật cache statistics report trong console | |

Và một lời khuyên: hãy rà lại cache policy khi tỷ lệ hit thấp bất thường. Phần lớn ca "CloudFront không cache gì cả" hoá ra là do cache key chứa một header hoặc query string thay đổi theo từng người dùng — nội dung hoàn toàn cache được, chỉ là mỗi yêu cầu bị coi là một object khác nhau.

Câu 324 Chọn nhiều đáp án Design Solutions for Organizational Complexity

A global healthcare company wants to develop a solution called Health Information Systems (HIS) on AWS Cloud that would allow the providers, payers, and government agencies to collaborate, anticipate and navigate the changing healthcare landscape. While pursuing this endeavor, the company would like to decrease its IT operational overhead so it could focus more intently on its core business - healthcare analytics. The solution should help the company eliminate the bottleneck created by manual provisioning of development pipelines while adhering to crucial governance and control requirements. As a means to this end, the company has set up "AWS Organizations" to manage several of these scenarios and would like to use Service Control Policies (SCP) for central control over the maximum available permissions for the various accounts in their organization. This allows the organization to ensure that all accounts stay within the organization’s access control guidelines.

As a Solutions Architect Professional, which of the following scenarios would you identify as correct regarding the given use-case? (Select three)

A
SCPs affect service-linked roles
B
If a user or role has an IAM permission policy that grants access to an action that is either not allowed or explicitly denied by the applicable SCPs, the user or role can't perform that action
C
If a user or role has an IAM permission policy that grants access to an action that is either not allowed or explicitly denied by the applicable SCPs, the user or role can still perform that action
D
SCPs affect all users and roles in attached accounts, excluding the root user
E
SCPs affect all users and roles in attached accounts, including the root user
F
SCPs do not affect service-linked role

Xem giải thích

Đáp án

**B, E và F — Nếu người dùng hoặc vai trò có chính sách IAM cấp quyền cho một hành động mà SCP không cho phép hoặc từ chối tường minh, thì không thực hiện được; SCP áp cho mọi người dùng và vai trò trong tài khoản đính kèm, KỂ CẢ user root; và SCP KHÔNG áp cho service-linked role.

Vì sao đúng

Ba mệnh đề này là ba quy tắc nền tảng của SCP.

⚠ Mệnh đề B — quyền hiệu lực là GIAO của hai lớp:

Quyền cuối cùng = SCP ∩ IAM policy
        ↓
    SCP không cho phép → không có
    → dù IAM có Allow
        ↓
    IAM không cho phép → không có
    → dù SCP có Allow

Đây là lý do mệnh đề C sai — nó nói ngược lại.

Bảng chân trị: | SCP | IAM | Kết quả | |---|---|---| | Allow | Allow | CHO PHÉP | | Allow | không có | từ chối | | không có | Allow | từ chối | | Deny | Allow | TỪ CHỐI |

⚠ Mệnh đề E — SCP áp cho cả user root của tài khoản thành viên:

Root của tài khoản THÀNH VIÊN:
  BỊ SCP giới hạn
        ↓
    Root của tài khoản QUẢN LÝ:
      KHÔNG bị
        ↓
    Đây là lý do không nên chạy
      workload ở tài khoản quản lý

Đây là lý do mệnh đề D sai — nó nói loại trừ root.

⚠ Và điểm này rất quan trọng về mặt an ninh:

SCP là cách duy nhất giới hạn
  được user root
        ↓
    IAM policy không gắn được vào
      root
    → root luôn có toàn quyền
      trong tài khoản
        ↓
    SCP chặn được cả root
    → đây là ranh giới thật sự

SCP bảo vệ những thứ không được đụng tới:

{"Effect": "Deny",
 "Action": ["cloudtrail:StopLogging",
            "cloudtrail:DeleteTrail",
            "config:DeleteConfigurationRecorder",
            "guardduty:DeleteDetector"],
 "Resource": "*"}

Kể cả root của tài khoản thành
  viên cũng không tắt được giám sát

⚠ Mệnh đề F — service-linked role miễn nhiễm SCP:

Service-linked role là vai trò
  do chính dịch vụ AWS tạo và dùng
        ↓
    Ví dụ:
      AWSServiceRoleForAutoScaling
      AWSServiceRoleForElasticLoadBalancing
        ↓
    SCP không áp cho chúng

Đây là lý do mệnh đề A sai.

⚠ Và đây là thiết kế có chủ đích:

SCP chặn `ec2:RunInstances` ở một
  Region
        ↓
    Nếu áp cho service-linked role:
      Auto Scaling không thay được
      máy hỏng
    → dịch vụ AWS gãy theo
        ↓
    Miễn trừ chúng để hạ tầng vẫn
      hoạt động

⚠ Nhưng đừng nhầm service-linked role với service role thường: | Loại | Ai tạo | SCP áp | |---|---|---| | Service-linked role | dịch vụ AWS tự tạo, tên AWSServiceRoleFor* | KHÔNG | | Service role thường | bạn tạo cho một dịch vụ dùng | CÓ |

Vai trò bạn tạo cho Lambda
    → là service role thường
    → SCP VẪN áp

Ba lợi ích của SCP: | Lợi ích | Chi tiết | |---|---| | Ranh giới quyền mà tài khoản con không gỡ được | | | Áp cả cho root | | | Tài khoản mới tự thừa hưởng theo OU | |

⚠ Và thừa hưởng theo cây là GIAO chứ không phải HỢP:

Root SCP cho phép: A, B, C
        ↓
    OU cha cho phép: B, C, D
        ↓
    OU con cho phép: C, D, E
        ↓
    Quyền còn lại: C

⚠ Và mỗi cấp phải có ít nhất một Allow:

Gắn một SCP chỉ có Deny
    → và gỡ FullAWSAccess
        ↓
    Không còn Allow nào
    → tài khoản KHÔNG LÀM GÌ ĐƯỢC
        ↓
    Luôn giữ FullAWSAccess khi
      dùng chiến lược deny list

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

**D. SCP áp cho mọi người dùng và vai trò trong tài khoản đính kèm, loại trừ user root — đây là phương án gần nhất và chỉ khác đáp án đúng một từ, nhưng SCP áp cả cho root của tài khoản thành viên; chỉ tài khoản quản lý mới được miễn.
**C. Nếu IAM cấp quyền cho hành động mà SCP không cho phép thì vẫn thực hiện được — ngược với quy tắc giao; SCP là trần quyền tối đa.
**A. SCP áp cho service-linked role — chúng được miễn trừ có chủ đích để dịch vụ AWS không bị gãy.

Ghi nhớ

⚠ Năm điều phải thuộc về SCP: | Điều | Nội dung | |---|---| | 1 | KHÔNG cấp quyền, chỉ giới hạn | | 2 | Áp cho root của tài khoản thành viên | | 3 | KHÔNG áp cho tài khoản quản lý | | 4 | KHÔNG áp cho service-linked role | | 5 | Thừa hưởng theo cây, GIAO nhau |

Từ khoá nhận diện:

"prevent even the root user" → SCP "SCP allows but still denied" → thiếu IAM policy "management account not restricted" → luôn đúng "Auto Scaling still works despite SCP" → service-linked role

Hai chiến lược SCP: | Chiến lược | Cách làm | Đặc điểm | |---|---|---| | Deny list | giữ FullAWSAccess + thêm Deny | dễ vận hành, khuyến nghị | | Allow list | gỡ FullAWSAccess, chỉ Allow cái cần | chặt hơn, dễ gãy |

⚠ Allow list dễ chặn nhầm dịch vụ phụ thuộc:

Chỉ Allow `ec2:*` và `s3:*`
        ↓
    Không gọi được `sts:AssumeRole`
    → không giả nhận vai trò được
        ↓
    Và không gọi được `iam:*`
    → không tạo được instance profile

Ba lưu ý về RCP (resource control policy): | Lưu ý | Chi tiết | |---|---| | Loại chính sách mới (2024) | | | Giới hạn AI truy cập được TÀI NGUYÊN | | | Chặn được cả principal ngoài tổ chức | |

⚠ SCP và RCP bổ trợ nhau:

SCP: nhân viên của tôi làm được gì
        ↓
    RCP: ai chạm được vào tài nguyên
      của tôi
        ↓
    SCP không chặn được người ngoài
      đọc bucket bị cấu hình sai
    → RCP chặn được

Ba lưu ý về permissions boundary: | Lưu ý | Chi tiết | |---|---| | Trần quyền cho MỘT danh tính | | | Cho phép uỷ quyền tạo vai trò an toàn | | | Cũng không cấp quyền | |

Ba lưu ý về thứ tự đánh giá:

1. Deny tường minh ở BẤT KỲ lớp nào → TỪ CHỐI
        ↓
2. SCP có Allow không → không thì TỪ CHỐI
        ↓
3. Resource policy có Allow không
        ↓
4. Permissions boundary có Allow không
        ↓
5. IAM identity policy có Allow không
        ↓
6. Không lớp nào Allow → TỪ CHỐI mặc định

Ba lưu ý về triển khai: | Lưu ý | Chi tiết | |---|---| | Thử trên OU thử nghiệm trước | | | Rà CloudTrail tìm lời gọi sẽ bị chặn | | | Đọc errorMessage để biết lớp nào chặn | |

⚠ CloudTrail nói rõ lớp nào từ chối:

"errorMessage": "User: ... is not authorized to perform: ...
  with an explicit deny in a service control policy"

Ba lưu ý về Control Tower: | Lưu ý | Chi tiết | |---|---| | Guardrail = SCP + Config rule đóng gói | | | Preventive guardrail dùng SCP | | | Detective guardrail dùng Config | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem SCP hiệu lực trong console Organizations | | | Thử hành động bị cấm bằng vai trò thật | | | Kiểm tài khoản mới có thừa hưởng đúng không | |

Và một lời khuyên: hãy không bao giờ chạy workload trong tài khoản quản lý. Đó là tài khoản duy nhất mà SCP không chạm tới được, nên mọi ranh giới bảo mật bạn dựng lên cho cả tổ chức đều dừng lại ở cửa của nó.

Câu 325 Accelerate Workload Migration and Modernization

A big data analytics company is leveraging AWS Cloud to process Internet of Things (IoT) sensor data from the field devices of an agricultural sciences company. The analytics company stores the IoT sensor data in Amazon DynamoDB tables. To detect anomalous behaviors and respond quickly, all changes to the items stored in the DynamoDB tables must be logged in near real-time.

As an AWS Certified Solutions Architect Professional, which of the following solutions would you recommend to meet the requirements of the given use-case so that it requires minimal custom development and infrastructure maintenance?

A
Set up DynamoDB Streams to capture and send updates to a Lambda function that outputs records to Kinesis Data Analytics (KDA) via Kinesis Data Streams (KDS). Detect and analyze anomalies in KDA and send notifications via SNS
B
Set up DynamoDB Streams to capture and send updates to a Lambda function that outputs records directly to Kinesis Data Analytics (KDA). Detect and analyze anomalies in KDA and send notifications via SNS
C
Configure event patterns in EventBridge events to capture DynamoDB API call events and set up Lambda function as a target to analyze anomalous behavior. Send SNS notifications when anomalous behaviors are detected
D
Set up CloudTrail to capture all API calls that update the DynamoDB tables. Leverage CloudTrail event filtering to analyze anomalous behaviors and send SNS notifications in case anomalies are detected

Xem giải thích

Đáp án

**A — Bật DynamoDB Streams để bắt thay đổi và gửi tới một hàm Lambda, hàm này đẩy bản ghi vào Kinesis Data Analytics qua Kinesis Data Streams; phát hiện và phân tích bất thường trong KDA rồi gửi thông báo qua SNS.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp cả ba: | Yêu cầu | Thành phần | |---|---| | Ghi lại MỌI thay đổi item | DynamoDB Streams | | Gần thời gian thực | Streams → Lambda, độ trễ dưới giây | | Ít mã tự viết, ít hạ tầng | KDA có hàm phát hiện bất thường sẵn |

⚠ Điểm mấu chốt: chỉ DynamoDB Streams bắt được thay đổi ITEM:

CloudTrail ghi lời gọi API
        ↓
    Nhưng `PutItem`, `UpdateItem`
      là DATA event
    → không ghi mặc định
        ↓
    Và ngay cả khi bật, CloudTrail
      không ghi GIÁ TRỊ cũ và mới
      của item

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

⚠ Và DynamoDB Streams ghi cả trước lẫn sau:

aws dynamodb update-table --table-name du-lieu-cam-bien \
  --stream-specification \
    StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES

`StreamViewType`	Nội dung
`KEYS_ONLY`	chỉ khoá
`NEW_IMAGE`	item sau khi đổi
`OLD_IMAGE`	item trước khi đổi
`NEW_AND_OLD_IMAGES`	cả hai

Phát hiện bất thường cần SO SÁNH
    → giá trị nhảy từ 20 lên 200
        ↓
    Phải có cả cũ lẫn mới

⚠ Và vì sao phương án C (EventBridge bắt lời gọi API) sai:

EventBridge nhận sự kiện từ
  CloudTrail
        ↓
    Cùng vấn đề: data event của
      DynamoDB không ghi mặc định
        ↓
    Và nội dung sự kiện là THAM SỐ
      LỜI GỌI, không phải trạng
      thái item

⚠ Và điểm khác biệt giữa A và B là chi tiết kỹ thuật quyết định:

B nói Lambda ghi TRỰC TIẾP vào
  Kinesis Data Analytics
        ↓
    KDA KHÔNG nhận dữ liệu trực tiếp
    → nguồn của nó phải là Kinesis
      Data Streams hoặc Firehose
        ↓
    Đây là lý do A đúng và B sai

Thành phần	Nguồn hợp lệ cho KDA
Kinesis Data Streams	CÓ
Kinesis Data Firehose	CÓ
Lambda ghi thẳng	KHÔNG
MSK	CÓ (với Managed Flink)

Hàm Lambda chuyển tiếp:

import boto3, json
kinesis = boto3.client('kinesis')

def xu_ly(event, context):
    ban_ghi = []
    for r in event['Records']:
        if r['eventName'] not in ('INSERT', 'MODIFY'):
            continue
        moi = r['dynamodb']['NewImage']
        ban_ghi.append({
            'Data': json.dumps({
                'ma_cam_bien': moi['ma_cam_bien']['S'],
                'gia_tri': float(moi['gia_tri']['N']),
                'thoi_diem': moi['thoi_diem']['S']}) + '\n',
            'PartitionKey': moi['ma_cam_bien']['S']})
    if ban_ghi:
        kinesis.put_records(StreamName='luong-cam-bien', Records=ban_ghi)

⚠ Và KDA có hàm phát hiện bất thường viết sẵn — đây là lý do "ít mã tự viết":

CREATE OR REPLACE STREAM "BAT_THUONG" (
    ma_cam_bien VARCHAR(32), gia_tri DOUBLE, diem_so DOUBLE);

CREATE OR REPLACE PUMP "BOM" AS
INSERT INTO "BAT_THUONG"
SELECT STREAM ma_cam_bien, gia_tri, DIEM_SO
FROM TABLE(RANDOM_CUT_FOREST(
    CURSOR(SELECT STREAM ma_cam_bien, gia_tri FROM "NGUON_001")))
WHERE DIEM_SO > 3.0;

⚠ RANDOM_CUT_FOREST là thuật toán phát hiện bất thường không cần huấn luyện:

Không phải gán nhãn dữ liệu
    → không phải huấn luyện mô hình
        ↓
    Nó học phân bố bình thường từ
      chính luồng dữ liệu
    → và chấm điểm bất thường
        ↓
    Đây chính là "ít phát triển
      tuỳ chỉnh"

⚠ Và cần biết KDA đã đổi tên:

Kinesis Data Analytics for SQL
    → vẫn còn nhưng không phát
      triển thêm
        ↓
    Kinesis Data Analytics for Flink
    → đổi tên thành
      Amazon Managed Service
      for Apache Flink
        ↓
    Hướng hiện nay là Flink

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bắt mọi thay đổi, có cả giá trị cũ và mới | | | Phát hiện bất thường không cần huấn luyện | | | Không có máy chủ nào phải quản | |

⚠ Và Kinesis Data Streams ở giữa cho phép nhiều consumer:

DynamoDB Streams chỉ cho 2 consumer
  mỗi shard
        ↓
    Đưa qua KDS: nhiều ứng dụng
      cùng đọc
    → phân tích, lưu trữ, cảnh báo
        ↓
    Và phát lại được

⚠ Và có cách gọn hơn: DynamoDB Kinesis Data Streams tích hợp sẵn:

aws dynamodb enable-kinesis-streaming-destination \
  --table-name du-lieu-cam-bien \
  --stream-arn arn:aws:kinesis:ap-southeast-1:111122223333:stream/luong-cam-bien

DynamoDB ghi THẲNG vào Kinesis
    → không cần Lambda ở giữa
        ↓
    Ít một thành phần, ít một chỗ
      hỏng

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

**B. DynamoDB Streams → Lambda → ghi trực tiếp vào Kinesis Data Analytics — đây là phương án gần nhất và chỉ khác đáp án đúng ở một chặng, nhưng KDA không nhận dữ liệu trực tiếp; nguồn của nó phải là Kinesis Data Streams hoặc Firehose.
**C. Dùng EventBridge bắt lời gọi API của DynamoDB — data event không ghi mặc định, và nội dung sự kiện là tham số lời gọi chứ không phải trạng thái item.
**D. Dùng CloudTrail bắt mọi lời gọi API cập nhật bảng và lọc sự kiện để phân tích — CloudTrail không phải công cụ phân tích luồng, và không có giá trị item.

Ghi nhớ

⚠ Ba cách bắt thay đổi trong DynamoDB — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | DynamoDB Streams | giữ 24 giờ, 2 consumer mỗi shard | | Kinesis Data Streams integration | giữ tới 365 ngày, nhiều consumer | | CloudTrail data event | ghi lời gọi API, không có nội dung item |

Từ khoá nhận diện:

"capture item-level changes" → DynamoDB Streams "anomaly detection on streaming data" → RANDOM_CUT_FOREST trong KDA "many consumers, replay" → Kinesis Data Streams integration "who called the API" → CloudTrail

Ba lưu ý về DynamoDB Streams: | Lưu ý | Chi tiết | |---|---| | Giữ 24 giờ | | | Thứ tự bảo đảm trong cùng khoá phân vùng | | | Bật/tắt được, đổi StreamViewType cần tắt rồi bật lại | |

⚠ Đổi StreamViewType làm mất luồng cũ:

Phải tắt stream rồi bật lại
        ↓
    Stream ARN đổi
    → event source mapping phải
      cấu hình lại
        ↓
    Và dữ liệu trong 24 giờ qua mất

Ba lưu ý về Lambda với Streams: | Lưu ý | Chi tiết | |---|---| | Xử lý theo lô, mặc định 100 bản ghi | | | Lỗi làm cả lô thử lại, có thể chặn shard | | | BisectBatchOnFunctionError chia đôi lô khi lỗi | |

⚠ Một bản ghi độc làm kẹt cả shard:

Bản ghi gây lỗi
    → cả lô thử lại mãi
        ↓
    Shard đó ngừng tiến
    → dữ liệu sau đó không được
      xử lý
        ↓
    Đặt `MaximumRetryAttempts` và
      DLQ để bỏ qua

Ba lưu ý về Managed Flink: | Lưu ý | Chi tiết | |---|---| | Kế thừa KDA, dùng Apache Flink | | | Có cửa sổ trượt, cửa sổ phiên | | | Trạng thái lưu bền, khôi phục được | |

Ba lưu ý về phát hiện bất thường: | Cách | Đặc điểm | |---|---| | RANDOM_CUT_FOREST trong KDA | không cần huấn luyện | | CloudWatch anomaly detection | cho chỉ số CloudWatch | | SageMaker | mô hình tuỳ chỉnh, chính xác nhất |

Ba lưu ý về SNS: | Lưu ý | Chi tiết | |---|---| | Fan-out tới email, SMS, Lambda, SQS | | | Đặt DLQ cho đăng ký Lambda | | | Lọc tin bằng filter policy | |

⚠ Filter policy giảm nhiễu cảnh báo:

{"muc_do": ["nghiem-trong"],
 "diem_bat_thuong": [{"numeric": [">", 5]}]}

Chỉ đẩy cảnh báo nghiêm trọng tới
  số điện thoại trực
        ↓
    Cảnh báo nhẹ chỉ vào hàng đợi
      để xem sau

Ba lưu ý về chi phí: | Thành phần | Cách tính | |---|---| | DynamoDB Streams | theo lời gọi đọc | | Kinesis Data Streams | theo shard-giờ + PUT payload | | KDA/Flink | theo KPU-giờ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi một giá trị bất thường, đo thời gian tới lúc có cảnh báo | | | Kiểm IteratorAge của Lambda | | | Xem tỷ lệ báo động giả có chấp nhận được không | |

Và một lời khuyên: hãy cân nhắc tích hợp DynamoDB với Kinesis Data Streams thay vì ghép qua Lambda. Nó bỏ được hẳn một thành phần khỏi đường dữ liệu — và mỗi hàm Lambda trong một đường ống là một chỗ có thể hết bộ nhớ, hết thời gian, hoặc kẹt vì một bản ghi hỏng.

Câu 326 Accelerate Workload Migration and Modernization

A blog hosting company has an existing SaaS product architected as an on-premises three-tier web application. The blog content is posted and updated several times a day by multiple authors, so the Linux web servers serve content from a centralized file share on a NAS server. The CTO at the company has done an extensive technical review and highlighted to the company management that the existing infrastructure is not optimized. The company would like to migrate to AWS so that the resources can be dynamically scaled in response to load. The on-premises infrastructure and AWS Cloud are connected using Direct Connect.

As a Solutions Architect Professional, which of the following solutions would you recommend to the company so that it can migrate the web infrastructure to AWS without delaying the content updation process?

A
Attach an EFS file system to the on-premises servers to act as the NAS server. Mount the same EFS file system to the AWS based web servers running on EC2 instances to serve the content
B
Set up an on-premises file gateway using Storage Gateway to replace the NAS server and then replicate the existing content to AWS. On the AWS Cloud, mount the same Storage Gateway bucket to the EC2 instance based web servers to serve the content
C
Provision a cluster of 20 EC2 instances based web servers running behind an Application Load Balancer on AWS across multiple Availability Zones. Share an EBS volume among all instances for accessing the content. Develop custom code to periodically synchronize this volume with the NAS server
D
Provision EC2 instances based web servers with an Auto Scaling group. Create a nightly data transfer batch job to update the web server instances from the NAS server

Xem giải thích

Đáp án

**A — Gắn một hệ tệp EFS vào máy chủ tại chỗ để thay vai trò máy NAS, và mount chính hệ tệp EFS đó vào các máy chủ web chạy trên EC2 để phục vụ nội dung.

Vì sao đúng

Đề nêu ba yêu cầu, và EFS đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Nhiều máy chủ web đọc chung một kho nội dung | EFS mount đồng thời | | Co giãn theo tải | EC2 mới mount là có ngay nội dung | | Không làm gián đoạn quy trình đăng bài | tác giả vẫn ghi vào cùng một chỗ |

⚠ Điểm mấu chốt: đề đã cho sẵn Direct Connect, và EFS mount được qua đó:

EFS phơi giao thức NFSv4.1
        ↓
    Máy chủ tại chỗ mount được qua
      Direct Connect hoặc VPN
        ↓
    Cùng một hệ tệp, hai bên cùng
      đọc và ghi
    → không cần đồng bộ gì cả

Mount từ máy tại chỗ:

sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,\
hard,timeo=600,retrans=2,noresvport \
  10.0.1.50:/ /noi-dung-blog

⚠ Mount từ tại chỗ phải dùng IP của mount target, không dùng tên DNS:

Tên DNS của EFS chỉ phân giải
  được TRONG VPC
        ↓
    Từ tại chỗ: dùng IP của mount
      target
    → hoặc dựng Route 53 Resolver
      inbound endpoint

⚠ Và đây là điểm mấu chốt vì sao không cần đồng bộ:

Tác giả đăng bài
        ↓
    Ghi vào EFS (qua Direct Connect)
        ↓
    Máy chủ web trên AWS thấy NGAY
    → cùng một hệ tệp
        ↓
    Không có độ trễ đồng bộ, không
      có xung đột

⚠ Và vì sao phương án D (đồng bộ hằng đêm) vi phạm đề:

Đề nói bài viết đăng và sửa
  NHIỀU LẦN MỖI NGÀY
        ↓
    Đồng bộ hằng đêm → nội dung
      trên AWS trễ tới một ngày
        ↓
    Đề nói rõ: "không làm chậm
      quy trình cập nhật nội dung"

⚠ Và vì sao phương án C sai về mặt kỹ thuật:

C nói "chia sẻ một EBS volume cho
  20 instance"
        ↓
    EBS thường gắn được vào MỘT
      instance
        ↓
    Multi-Attach chỉ có với io1/io2,
      tối đa 16 instance, cùng AZ,
      và cần hệ tệp CỤM
        ↓
    Mount ext4 trên nhiều máy là
      HỎNG dữ liệu

Và "20 instance cố định" thì không
  co giãn theo tải

⚠ Và vì sao phương án B không chính xác:

B nói dựng File Gateway thay NAS,
  rồi "mount cùng bucket Storage
  Gateway vào EC2"
        ↓
    File Gateway ghi thành OBJECT
      trên S3
        ↓
    EC2 KHÔNG mount được bucket S3
      như hệ tệp
    → phải dùng API S3, hoặc dựng
      thêm một gateway nữa

⚠ Nhưng File Gateway vẫn là mẫu hợp lý — chỉ là mô tả sai:

Cách đúng với File Gateway:
    tại chỗ ghi qua NFS
        ↓
    Nội dung thành object S3
        ↓
    Máy chủ web trên AWS đọc bằng
      API S3, hoặc CloudFront phục
      vụ thẳng từ S3
        ↓
    Nhưng phải sửa ứng dụng web
    → EFS thì không cần sửa gì

Tạo hệ tệp và mount target:

aws efs create-file-system --performance-mode generalPurpose \
  --throughput-mode elastic --encrypted \
  --tags Key=Name,Value=noi-dung-blog

aws efs create-mount-target --file-system-id fs-0abc123 \
  --subnet-id subnet-1a --security-groups sg-efs

⚠ Security group của mount target phải mở cổng 2049 cho dải IP tại chỗ:

aws ec2 authorize-security-group-ingress --group-id sg-efs \
  --protocol tcp --port 2049 --cidr 192.168.0.0/16

Thiếu bước này: mount treo mà
  không báo lỗi rõ ràng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một nguồn nội dung duy nhất, không đồng bộ | | | Máy web mới mount là có ngay nội dung | | | Không phải sửa ứng dụng | |

⚠ Nhưng độ trễ qua Direct Connect là điều phải tính:

NFS rất nhạy với độ trễ
        ↓
    Mỗi thao tác tệp là một vòng
      khứ hồi
        ↓
    Ghi từ tại chỗ qua Direct
      Connect: chấp nhận được
    → đọc liên tục từ tại chỗ:
      sẽ chậm

⚠ Và đây là lý do nên chuyển hẳn quy trình đăng bài lên AWS sau đó:

Giai đoạn quá độ: tại chỗ ghi,
  AWS đọc
        ↓
    Giai đoạn cuối: cả hai đều
      trên AWS
    → gỡ Direct Connect khỏi
      đường dữ liệu nóng

⚠ Và nên đặt CloudFront trước để giảm tải EFS:

Blog: đọc nhiều, ghi ít
        ↓
    CloudFront cache nội dung
    → EFS chỉ phục vụ cache miss
        ↓
    Và giảm hẳn chi phí thông lượng
      EFS

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

**B. Dựng File Gateway thay máy NAS và "mount cùng bucket Storage Gateway" vào EC2 — đây là phương án gần nhất và File Gateway thật sự là cầu nối NAS lên đám mây, nhưng nó lưu thành object S3, mà EC2 không mount bucket S3 như hệ tệp được.
**C. Dựng 20 EC2 sau ALB và chia sẻ một EBS volume, tự viết mã đồng bộ với NAS — EBS không chia sẻ được cho 20 máy, và số máy cố định thì không co giãn.
**D. Dựng EC2 với Auto Scaling và đồng bộ hằng đêm từ NAS — nội dung cập nhật nhiều lần mỗi ngày sẽ trễ tới một ngày.

Ghi nhớ

⚠ Bốn cách chia sẻ tệp giữa tại chỗ và AWS — bảng phải thuộc: | Cách | Giao thức | Dữ liệu nằm ở | |---|---|---| | EFS mount qua DX/VPN | NFS | EFS, cả hai bên dùng chung | | File Gateway | NFS/SMB tại chỗ | object S3 | | FSx File Gateway | SMB | FSx for Windows | | DataSync | sao chép theo lịch | hai bản riêng |

Từ khoá nhận diện:

"same file system on-premises and in AWS" → EFS mount qua DX "replace NAS, data as S3 objects" → File Gateway "one-time or scheduled copy" → DataSync "Windows file share" → FSx for Windows hoặc FSx File Gateway

Ba lưu ý về EFS: | Lưu ý | Chi tiết | |---|---| | Mount target ở mỗi AZ | | | Chế độ Elastic tự co giãn thông lượng | | | Access point cho quyền POSIX theo ứng dụng | |

⚠ EFS Access Point rất hữu ích cho nhiều ứng dụng:

aws efs create-access-point --file-system-id fs-0abc123 \
  --posix-user Uid=1001,Gid=1001 \
  --root-directory 'Path=/blog,CreationInfo={OwnerUid=1001,
    OwnerGid=1001,Permissions=0755}'

Mỗi ứng dụng thấy thư mục con
  của nó như thư mục gốc
        ↓
    Và chạy với UID cố định

Ba chế độ thông lượng của EFS: | Chế độ | Đặc điểm | |---|---| | Elastic | tự co giãn, trả theo lượng dùng | | Provisioned | cấp cố định, không phụ thuộc dung lượng | | Bursting | theo dung lượng, có tín dụng |

⚠ Bursting là bẫy với dữ liệu nhỏ:

50 GB nội dung
    → thông lượng nền 2,5 MB/s
        ↓
    Hết tín dụng bùng nổ
    → website chậm hẳn
        ↓
    Elastic tránh được chuyện này

Ba lưu ý về lớp lưu trữ EFS: | Lớp | Dùng khi | |---|---| | Standard | đọc thường xuyên | | Infrequent Access | ít đọc, rẻ hơn nhiều | | Archive | rất ít đọc |

⚠ Lifecycle policy tự chuyển tầng:

aws efs put-lifecycle-configuration --file-system-id fs-0abc123 \
  --lifecycle-policies \
    TransitionToIA=AFTER_30_DAYS \
    TransitionToPrimaryStorageClass=AFTER_1_ACCESS

Ba lưu ý về mount qua Direct Connect: | Lưu ý | Chi tiết | |---|---| | Dùng IP mount target, không dùng DNS | | | Mở cổng 2049 trong security group | | | Độ trễ ảnh hưởng mạnh tới hiệu năng NFS | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá khi lưu và khi truyền | | | File system policy giới hạn truy cập | | | IAM authorization thay cho chỉ dựa vào mạng | |

Ba lưu ý về hiệu năng web: | Lưu ý | Chi tiết | |---|---| | CloudFront cache giảm tải EFS rất nhiều | | | Nhiều tệp nhỏ chậm hơn ít tệp lớn | | | Cache cục bộ trên máy web cho tệp hay đọc | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng một bài từ tại chỗ, xem AWS có thấy ngay | | | Khởi động thêm một máy web, kiểm nội dung | | | Đo PercentIOLimit và BurstCreditBalance | |

Và một lời khuyên: hãy đặt CloudFront trước máy chủ web ngay từ đầu. EFS chia sẻ qua Direct Connect giải quyết đúng bài toán nhất quán nội dung, nhưng mỗi lượt đọc vẫn là một vòng khứ hồi NFS — và với một blog đọc nhiều ghi ít, cache ở biên là thứ giữ cho kiến trúc này chạy nhanh.

Câu 327 Design for New Solutions

A financial services company runs more than 400 core-banking microservices on AWS, using services including Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Block Store (Amazon EBS), and Amazon Simple Storage Service (Amazon S3). The company also segregates parts of its infrastructure using separate AWS accounts, so if one account is compromised, critical parts of the infrastructure in other accounts remain unaffected. The company uses one account for production, one for non-production, and one for storing and managing users’ login information and roles within AWS. The privileges that are assigned in the user account then allow users to read or write to production and non-production accounts. The company has set up "AWS Organizations" to manage several of these scenarios. The company wants to provide shared and centrally-managed VPCs to all business units for certain applications that need a high degree of interconnectivity.

As a solutions architect, which of the following options would you choose to facilitate this use-case?

A
Use VPC sharing to share one or more subnets with other AWS accounts belonging to the same parent organization from AWS Organizations
B
Use VPC peering to share one or more subnets with other AWS accounts belonging to the same parent organization from AWS Organizations
C
Use VPC sharing to share a VPC with other AWS accounts belonging to the same parent organization from AWS Organizations
D
Use VPC peering to share a VPC with other AWS accounts belonging to the same parent organization from AWS Organizations

Xem giải thích

Đáp án

**A — Dùng VPC sharing để chia sẻ một hoặc nhiều SUBNET với các tài khoản AWS khác thuộc cùng tổ chức trong AWS Organizations.

Vì sao đúng

Đề hỏi cách cung cấp VPC dùng chung, quản lý tập trung cho nhiều đơn vị kinh doanh, và VPC sharing sinh ra đúng cho việc đó:

Tài khoản chủ (owner) tạo VPC
        ↓
    Chia sẻ SUBNET qua AWS RAM
        ↓
    Tài khoản khác (participant)
      dựng tài nguyên TRONG subnet đó
        ↓
    Mạng do một đội quản, workload
      do từng đội quản

⚠ Điểm mấu chốt: chia sẻ được SUBNET chứ không phải cả VPC:

Không có thao tác "chia sẻ VPC"
        ↓
    Đơn vị chia sẻ là SUBNET
        ↓
    Chia sẻ mọi subnet của một VPC
      thì hiệu quả gần giống chia
      sẻ cả VPC
    → nhưng cơ chế vẫn là theo subnet

Đây là lý do phương án C sai — nó nói chia sẻ "một VPC".

Chia sẻ subnet qua RAM:

aws ram create-resource-share \
  --name mang-dung-chung \
  --resource-arns \
    arn:aws:ec2:ap-southeast-1:111122223333:subnet/subnet-1a \
    arn:aws:ec2:ap-southeast-1:111122223333:subnet/subnet-1b \
  --principals arn:aws:organizations::111122223333:ou/o-abc/ou-xyz

⚠ Và chia sẻ cho cả OU là điểm mạnh:

Chia sẻ với một OU
    → tài khoản mới vào OU tự
      có quyền
        ↓
    Không phải cập nhật resource
      share mỗi lần thêm tài khoản

⚠ Và vì sao VPC peering (B, D) không phải câu trả lời: | Tiêu chí | VPC sharing | VPC peering | |---|---|---| | Số VPC | MỘT VPC dùng chung | nhiều VPC nối với nhau | | Quản lý | tập trung ở tài khoản chủ | mỗi bên tự quản VPC của mình | | Trùng CIDR | không có vấn đề | KHÔNG được trùng | | Bắc cầu | không áp dụng | KHÔNG bắc cầu | | Phí liên AZ | có | có |

Đề nói "VPC dùng chung và quản lý
  tập trung"
        ↓
    Peering là nhiều VPC RIÊNG nối
      với nhau
    → mỗi đội vẫn tự quản mạng
      của mình
        ↓
    Trái với "quản lý tập trung"

⚠ Và "mức độ liên kết cao" trong đề là dấu hiệu rõ:

Ứng dụng cần nói chuyện với nhau
  rất nhiều
        ↓
    Cùng một VPC → cùng dải IP,
      không qua gateway nào
    → độ trễ thấp nhất, không phí
      truyền liên VPC
        ↓
    Peering: vẫn qua kết nối peering

⚠ Và VPC sharing tiết kiệm địa chỉ IP:

Mỗi đội một VPC /16
        ↓
    Hàng chục VPC → cạn dải IP
      riêng của công ty
        ↓
    Dùng chung một VPC
    → một dải IP, dùng hết công suất

⚠ Nhưng cần hiểu rõ ranh giới quyền: | Việc | Tài khoản chủ | Tài khoản tham gia | |---|---|---| | Tạo/xoá subnet, route table | CÓ | không | | Tạo/xoá VPC, gateway | CÓ | không | | Tạo EC2, RDS trong subnet | có | CÓ | | Tạo security group | có | CÓ (trong VPC dùng chung) | | Xem tài nguyên của bên kia | thấy ENI, không thấy instance | chỉ thấy của mình |

Tài khoản tham gia KHÔNG sửa được
  hạ tầng mạng
        ↓
    Đó chính là "quản lý tập trung"

⚠ Và có một điểm bất ngờ về security group:

Tài khoản tham gia tham chiếu được
  security group của tài khoản chủ
        ↓
    Nhưng KHÔNG sửa được nó
        ↓
    Và tài khoản chủ không xoá được
      subnet còn tài nguyên của
      bên khác

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một đội quản mạng cho cả tổ chức | | | Tiết kiệm địa chỉ IP | | | Không phí truyền dữ liệu liên VPC | |

⚠ Và giảm hẳn số NAT gateway, endpoint phải trả tiền:

Mỗi VPC riêng: NAT gateway riêng,
  interface endpoint riêng
        ↓
    VPC dùng chung: một bộ cho tất cả
    → tiết kiệm rất lớn

⚠ Nhưng cũng có mặt trái phải biết:

Mọi workload trong CÙNG một VPC
        ↓
    Bán kính ảnh hưởng lớn hơn
    → cấu hình sai một route table
      ảnh hưởng mọi đội
        ↓
    Và hạn ngạch của VPC (số ENI,
      số security group) dùng chung

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

**C. Dùng VPC sharing để chia sẻ một VPC với các tài khoản khác — đây là phương án gần nhất và chọn đúng cơ chế, nhưng đơn vị chia sẻ trong VPC sharing là subnet, không phải cả VPC; đây là loại câu chỉ khác nhau một từ.
**B. Dùng VPC peering để chia sẻ một hoặc nhiều subnet — peering nối hai VPC riêng biệt, không chia sẻ subnet cho tài khoản khác dựng tài nguyên vào.
**D. Dùng VPC peering để chia sẻ một VPC — cùng lý do; peering không phải cơ chế chia sẻ.

Ghi nhớ

⚠ Bốn cách kết nối và chia sẻ mạng — bảng phải thuộc: | Cách | Mô hình | |---|---| | VPC sharing | một VPC, nhiều tài khoản dựng tài nguyên vào | | VPC peering | hai VPC riêng nối với nhau, không bắc cầu | | Transit Gateway | hub-and-spoke, bắc cầu được | | PrivateLink | phơi một dịch vụ, không định tuyến cả dải |

Từ khoá nhận diện:

"shared, centrally managed VPC" → VPC sharing "high degree of interconnectivity" → VPC sharing (cùng dải IP) "hundreds of VPCs, transitive routing" → Transit Gateway "overlapping CIDR" → PrivateLink "expose one service to consumers" → PrivateLink

Ba lưu ý về VPC sharing: | Lưu ý | Chi tiết | |---|---| | Chỉ trong cùng AWS Organizations | | | Chia sẻ qua AWS RAM | | | Tài khoản tham gia không sửa được hạ tầng mạng | |

⚠ Phải bật chia sẻ với Organizations trước:

aws ram enable-sharing-with-aws-organization

Không bật: chỉ chia sẻ được với
  từng tài khoản một

Ba lưu ý về VPC peering: | Lưu ý | Chi tiết | |---|---| | KHÔNG bắc cầu | | | CIDR không được chồng nhau | | | Phải sửa bảng định tuyến ở CẢ HAI bên | |

⚠ Sửa route một bên là lỗi hay gặp nhất:

Chỉ thêm route ở VPC A
        ↓
    Gói đi được sang B
    → nhưng phản hồi không về được
        ↓
    Triệu chứng: kết nối treo

Ba lưu ý về Transit Gateway: | Lưu ý | Chi tiết | |---|---| | Chia sẻ qua RAM cho nhiều tài khoản | | | Nhiều bảng định tuyến để phân đoạn | | | Tính phí theo attachment và GB xử lý | |

Ba lưu ý về quy hoạch IP: | Lưu ý | Chi tiết | |---|---| | Dùng IPAM để quản dải địa chỉ | | | Chừa chỗ cho tăng trưởng | | | Tránh trùng với dải tại chỗ | |

⚠ AWS IPAM giải quyết vấn đề quy hoạch IP:

aws ec2 create-ipam-pool --ipam-scope-id <id> \
  --address-family ipv4 --locale ap-southeast-1 \
  --provisioned-cidrs Cidr=10.0.0.0/8

Cấp phát dải cho từng đội tự động
    → không trùng nhau
    → theo dõi được mức sử dụng

Ba lưu ý về bảo mật trong VPC dùng chung: | Lưu ý | Chi tiết | |---|---| | Security group là ranh giới chính giữa các đội | | | Đội chủ nên kiểm soát NACL | | | Flow log tập trung ở tài khoản chủ | |

Ba lưu ý về hạn ngạch: | Hạn ngạch | Giá trị mặc định | |---|---| | Subnet mỗi VPC | 200 | | Security group mỗi VPC | 2.500 | | Quy tắc mỗi security group | 60 vào, 60 ra |

⚠ Hạn ngạch dùng chung là mặt trái của VPC sharing:

Nhiều đội trong một VPC
        ↓
    Một đội tạo quá nhiều security
      group
    → cả VPC chạm trần
        ↓
    Phải theo dõi và đặt quy ước

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Từ tài khoản tham gia, thử tạo EC2 trong subnet chia sẻ | | | Thử sửa route table — phải bị từ chối | | | Kiểm hai đội nói chuyện được với nhau | |

Và một lời khuyên: hãy đọc kỹ xem phương án nói chia sẻ "subnet" hay "VPC". Đây là loại câu chỉ khác nhau đúng một danh từ, và AWS rất hay dùng nó — đơn vị chia sẻ trong VPC sharing luôn là subnet.

Câu 328 Chọn nhiều đáp án Continuous Improvement for Existing Solutions

The engineering team at a social media company is building an ElasticSearch based index for all the existing files in S3. To build this index, it only needs to read the first 250 bytes of each object in S3, which contains some metadata about the content of the file itself. There are over 100,000 files in your S3 bucket, adding up to 50TB of data.

As a Solutions Architect Professional, which of the following solutions can be used to build this index MOST efficiently? (Select two)

A
Use the ElasticSearch Import feature to load the entire data from S3 to ElasticSearch and then ElasticSearch would automatically build the index
B
Create an application that will use the S3 Select ScanRange parameter to get the first 250 bytes and store that information in ElasticSearch
C
Create an application that will traverse the S3 bucket, issue a Byte Range Fetch for the first 250 bytes, and store that information in ElasticSearch
D
Use the Database Migration Service to load the entire data from S3 to ElasticSearch and then ElasticSearch would automatically build the index
E
Create an application that will traverse the S3 bucket, read the entire files one by one, extract the first 250 bytes, and store that information in ElasticSearch

Xem giải thích

Đáp án

**B và C — Viết ứng dụng dùng tham số ScanRange của S3 Select để lấy 250 byte đầu; hoặc viết ứng dụng duyệt bucket và phát Byte Range Fetch cho 250 byte đầu, rồi lưu thông tin đó vào ElasticSearch.

Vì sao đúng

Đề có một dữ kiện quyết định mọi thứ:

Chỉ cần 250 BYTE ĐẦU của mỗi object
        ↓
    Có 100.000 object, tổng 50 TB
        ↓
    250 byte × 100.000 = 25 MB
    → so với 50 TB
        ↓
    Chênh nhau HAI TRIỆU LẦN

⚠ Điểm mấu chốt: S3 cho phép đọc MỘT PHẦN object:

Byte Range Fetch: header HTTP
  `Range`
        ↓
    Chỉ trả về đoạn byte yêu cầu
        ↓
    Và chỉ TÍNH TIỀN cho phần
      truyền thật

Byte Range Fetch:

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

def lay_dau_tep(kho, khoa):
    phan_hoi = s3.get_object(Bucket=kho, Key=khoa,
                             Range='bytes=0-249')
    return phan_hoi['Body'].read()

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

E đọc TOÀN BỘ tệp rồi mới cắt
  250 byte đầu
        ↓
    Truyền 50 TB qua mạng
        ↓
    Với phí truyền và thời gian:
      hoàn toàn lãng phí
    → và kết quả giống hệt

S3 Select với ScanRange:

phan_hoi = s3.select_object_content(
    Bucket=kho, Key=khoa,
    ExpressionType='SQL',
    Expression="SELECT * FROM S3Object LIMIT 1",
    InputSerialization={'CSV': {}},
    OutputSerialization={'CSV': {}},
    ScanRange={'Start': 0, 'End': 250})

⚠ ScanRange khác Range ở chỗ nó tôn trọng ranh giới bản ghi:

`Range`: cắt đúng byte, có thể
  cắt giữa một dòng
        ↓
    `ScanRange`: bắt đầu quét từ
      byte đó, nhưng lấy trọn bản ghi
        ↓
    Với dữ liệu có cấu trúc thì
      hợp lý hơn

⚠ Và vì sao hai phương án còn lại sai hoàn toàn:

A: "ElasticSearch Import feature"
        ↓
    Không có tính năng nào tên vậy
      để nạp thẳng từ S3
        ↓
    Và nạp cả 50 TB vào ElasticSearch
      để lấy 25 MB metadata là vô lý

D: dùng DMS nạp từ S3 sang
  ElasticSearch
        ↓
    DMS di trú CƠ SỞ DỮ LIỆU
    → S3 là nguồn được hỗ trợ,
      nhưng ElasticSearch KHÔNG
      phải đích của DMS
        ↓
    Và vẫn là nạp toàn bộ dữ liệu

⚠ Và cả A lẫn D đều mắc cùng một sai lầm căn bản:

Chỉ mục cần METADATA
        ↓
    Không cần nội dung tệp
        ↓
    Nạp toàn bộ 50 TB vào một cụm
      tìm kiếm
    → cụm phải rất lớn, rất đắt
    → và 99,99% dữ liệu không dùng

Xử lý song song để nhanh hơn:

from concurrent.futures import ThreadPoolExecutor

def lap_chi_muc():
    trang = s3.get_paginator('list_objects_v2')
    with ThreadPoolExecutor(max_workers=50) as pool:
        for tr in trang.paginate(Bucket=KHO):
            khoa = [o['Key'] for o in tr.get('Contents', [])]
            for kq in pool.map(lambda k: (k, lay_dau_tep(KHO, k)), khoa):
                ghi_vao_opensearch(kq)

⚠ Và 100.000 lời gọi GET là chi phí rất nhỏ:

100.000 / 1.000 × 0,0004 USD
    = 0,04 USD
        ↓
    Cộng phí truyền 25 MB
    → gần như bằng không
        ↓
    So với truyền 50 TB

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chỉ truyền 25 MB thay vì 50 TB | | | Chạy nhanh hơn hàng nghìn lần | | | Chi phí gần như bằng không | |

⚠ Và có thể chạy song song bằng Lambda cho nhanh hơn nữa:

S3 Inventory liệt kê object
        ↓
    S3 Batch Operations gọi Lambda
      cho từng object
        ↓
    Hàng nghìn Lambda chạy song song
    → xong trong vài phút

aws s3control create-job --account-id 111122223333 \
  --operation '{"LambdaInvoke": {"FunctionArn": "<arn-lambda>"}}' \
  --manifest '{"Spec": {"Format": "S3InventoryReport_CSV_20161130"},
               "Location": {"ObjectArn": "<arn-inventory>",
                            "ETag": "..."}}' \
  --report '{"Bucket": "<arn-kho-bao-cao>", "Enabled": true,
             "Format": "Report_CSV_20180820", "ReportScope": "AllTasks"}' \
  --role-arn <arn-role> --priority 10

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

⚠ S3 Select không còn nhận khách hàng mới từ tháng 7/2024.

AWS khuyến nghị thay bằng:
    Athena — truy vấn SQL trên S3
        ↓
    S3 Object Lambda — biến đổi
      khi đọc
        ↓
    Byte Range Fetch — vẫn hoạt
      động bình thường

Với bài toán trong đề, Byte Range Fetch (phương án C) là cách còn dùng được lâu dài, còn S3 Select chỉ còn phục vụ khách hàng đã dùng từ trước.

Và đề gọi dịch vụ là "ElasticSearch" — tên hiện tại là Amazon OpenSearch Service (đổi tên tháng 9/2021). Kibana cũng đã thành OpenSearch Dashboards.

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

**E. Duyệt bucket, đọc toàn bộ từng tệp, cắt 250 byte đầu rồi lưu vào ElasticSearch — đây là phương án gần nhất và cho kết quả hoàn toàn đúng, nhưng phải truyền 50 TB thay vì 25 MB để có cùng kết quả.
**A. Dùng "tính năng ElasticSearch Import" nạp toàn bộ dữ liệu từ S3 — không có tính năng như vậy, và nạp toàn bộ là thừa hai triệu lần.
**D. Dùng DMS nạp toàn bộ dữ liệu từ S3 sang ElasticSearch — DMS di trú cơ sở dữ liệu và không hỗ trợ ElasticSearch làm đích.

Ghi nhớ

⚠ Bốn cách đọc một phần dữ liệu từ S3 — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Byte Range Fetch | đọc đúng dải byte, mọi định dạng | | S3 Select | SQL trên một object (legacy) | | Athena | SQL trên nhiều object, có phân vùng | | S3 Object Lambda | biến đổi khi đọc bằng Lambda |

Từ khoá nhận diện:

"only need first N bytes" → Byte Range Fetch "query across many objects" → Athena "transform per consumer on read" → S3 Object Lambda "operate on every object in bucket" → S3 Batch Operations

Ba lưu ý về Byte Range Fetch: | Lưu ý | Chi tiết | |---|---| | Header Range: bytes=0-249 | | | Chỉ tính phí phần truyền thật | | | Dùng được cả để tải song song nhiều phần | |

⚠ Tải song song bằng byte range làm tệp lớn nhanh hơn:

Tệp 10 GB
    → chia thành 10 dải 1 GB
        ↓
    Tải song song 10 luồng
    → nhanh hơn nhiều lần
        ↓
    Đây là cách SDK tự làm khi
      dùng TransferManager

Ba lưu ý về S3 Batch Operations: | Lưu ý | Chi tiết | |---|---| | Nguồn danh sách là S3 Inventory hoặc CSV tự viết | | | Gọi Lambda hoặc thao tác sẵn có cho từng object | | | Có báo cáo hoàn thành và thử lại | |

Ba lưu ý về S3 Inventory: | Lưu ý | Chi tiết | |---|---| | Báo cáo hằng ngày hoặc hằng tuần | | | Rẻ hơn nhiều so với ListObjectsV2 hàng triệu lần | | | Có kích thước, ngày sửa, lớp lưu trữ, mã hoá | |

⚠ ListObjectsV2 trên bucket lớn rất chậm:

1.000 object mỗi lời gọi
        ↓
    100.000 object → 100 lời gọi
    → còn chấp nhận được
        ↓
    100 triệu object → 100.000 lời
      gọi, mất hàng giờ
    → dùng S3 Inventory

Ba lưu ý về OpenSearch: | Lưu ý | Chi tiết | |---|---| | Nạp bằng bulk API, không nạp từng tài liệu | | | Chỉ mục siêu dữ liệu nhỏ, cụm nhỏ là đủ | | | UltraWarm cho dữ liệu ít truy vấn | |

⚠ Bulk API nhanh hơn hàng chục lần:

from opensearchpy import helpers
helpers.bulk(khach, ({'_index': 'sieu-du-lieu',
                      '_id': k, '_source': dl}
                     for k, dl in danh_sach))

Ba lưu ý về chi phí S3: | Khoản | Ghi chú | |---|---| | GET | ~0,0004 USD/1.000 lời gọi | | Truyền ra Internet | ~0,09 USD/GB | | Truyền trong cùng Region | miễn phí tới EC2 cùng Region |

⚠ Chạy trong cùng Region là điều bắt buộc:

Chạy ứng dụng lập chỉ mục từ máy
  cá nhân
        ↓
    50 TB × 0,09 USD = 4.500 USD
      phí truyền
        ↓
    Chạy trên EC2 cùng Region
    → miễn phí

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So thời gian chạy với ước tính | | | Kiểm lượng dữ liệu truyền trong CloudWatch | | | Đối chiếu số tài liệu trong chỉ mục với số object | |

Và một lời khuyên: hãy chạy công việc lập chỉ mục từ trong cùng Region với bucket. Truyền dữ liệu ra khỏi Region tính tiền theo GB, và một script chạy từ máy cá nhân có thể biến một việc gần như miễn phí thành một hoá đơn bốn chữ số.

Câu 329 Chọn nhiều đáp án Design Solutions for Organizational Complexity

A data analytics company needs to set up a data lake on Amazon S3 for a financial services client. The data lake is split in raw and curated zones. For compliance reasons, the source data needs to be kept for a minimum of 5 years. The source data arrives in the raw zone and is then processed via an AWS Glue based ETL job into the curated zone. The business analysts run ad-hoc queries only on the data in the curated zone using Athena. The team is concerned about the cost of data storage in both the raw and curated zones as the data is increasing at a rate of 2 TB daily in each zone.

Which of the following options would you implement together as the MOST cost-optimal solution? (Select two)

A
Setup a lifecycle policy to transition the curated zone data into Glacier Deep Archive after 1 day of object creation
B
Use Glue ETL job to write the transformed data in the curated zone using CSV format
C
Setup a lifecycle policy to transition the raw zone data into Glacier Deep Archive after 1 day of object creation
D
Use Glue ETL job to write the transformed data in the curated zone using a compressed file format
E
Create a Lambda function based job to delete the raw zone data after 1 day

Xem giải thích

Đáp án

**C và D — Đặt luật vòng đời chuyển dữ liệu vùng raw sang Glacier Deep Archive sau 1 ngày kể từ khi tạo object; và cho job Glue ETL ghi dữ liệu vùng curated bằng định dạng nén.

Vì sao đúng

Đề mô tả hai vùng với hai kiểu sử dụng hoàn toàn khác nhau: | Vùng | Ai dùng | Sau khi ETL xong | |---|---|---| | Raw | chỉ job Glue ETL đọc một lần | không ai đọc nữa | | Curated | nhà phân tích chạy Athena | truy vấn thường xuyên |

⚠ Điểm mấu chốt: vùng raw phải giữ 5 năm nhưng không ai đọc:

Yêu cầu tuân thủ: giữ 5 năm
        ↓
    Nhưng ETL đọc xong là hết
      nhu cầu
        ↓
    Đó chính là định nghĩa của
      dữ liệu lưu trữ
    → Deep Archive rẻ nhất

⚠ Và chênh lệch giá là rất lớn: | Lớp | Giá xấp xỉ (USD/GB-tháng) | |---|---| | S3 Standard | 0,023 | | Standard-IA | 0,0125 | | Glacier Instant Retrieval | 0,004 | | Glacier Flexible Retrieval | 0,0036 | | Glacier Deep Archive | 0,00099 |

2 TB mỗi ngày × 365 × 5 năm
    = 3.650 TB
        ↓
    Standard: ~84.000 USD/tháng ở
      năm thứ năm
        ↓
    Deep Archive: ~3.600 USD/tháng
    → rẻ hơn 23 lần

Luật vòng đời:

{"Rules": [{
  "ID": "raw-sang-deep-archive",
  "Filter": {"Prefix": "raw/"},
  "Status": "Enabled",
  "Transitions": [{"Days": 1, "StorageClass": "DEEP_ARCHIVE"}]}]}

⚠ Chuyển sau 1 ngày là hợp lệ với Deep Archive:

Standard-IA và One Zone-IA: phải
  chờ tối thiểu 30 ngày
        ↓
    Glacier và Deep Archive: chuyển
      từ Standard được NGAY
    → không có thời gian chờ tối
      thiểu để CHUYỂN

⚠ Nhưng có phí lưu trữ tối thiểu 180 ngày:

Xoá object khỏi Deep Archive
  trước 180 ngày
        ↓
    Vẫn tính tiền đủ 180 ngày
        ↓
    Đề nói giữ 5 năm → không sao

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

A chuyển vùng CURATED sang
  Deep Archive sau 1 ngày
        ↓
    Nhà phân tích chạy Athena
      trên vùng đó
        ↓
    Deep Archive: KHÔNG truy vấn
      được, phải khôi phục 12-48 giờ
    → phá hỏng công việc chính

⚠ Và định dạng nén giảm chi phí Athena rất mạnh:

Athena tính tiền theo lượng DỮ LIỆU
  QUÉT
        ↓
    CSV không nén: quét toàn bộ
        ↓
    Parquet nén Snappy: quét ít hơn
      5-10 lần
    → giảm cả phí lưu trữ lẫn phí
      truy vấn

Ghi Parquet trong Glue:

glueContext.write_dynamic_frame.from_options(
    frame=du_lieu_da_bien_doi,
    connection_type="s3",
    connection_options={"path": "s3://ho-du-lieu/curated/",
                        "partitionKeys": ["nam", "thang", "ngay"]},
    format="glueparquet",
    format_options={"compression": "snappy"})

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

B ghi vùng curated bằng CSV
        ↓
    CSV là định dạng theo DÒNG,
      không nén
        ↓
    Athena phải đọc mọi cột dù
      truy vấn chỉ cần vài cột
    → tăng chi phí, không giảm

⚠ Parquet có hai lợi thế cộng dồn: | Lợi thế | Tác dụng | |---|---| | Lưu theo CỘT | chỉ đọc cột được chọn | | Nén theo cột | cùng kiểu dữ liệu nén rất tốt |

Bảng 50 cột, truy vấn dùng 3 cột
        ↓
    CSV: đọc 50 cột
    → Parquet: đọc 3 cột
        ↓
    Cộng thêm nén ~5 lần
    → tổng cộng giảm khoảng 80 lần

⚠ Và vì sao phương án E sai — nó vi phạm yêu cầu tuân thủ:

E xoá dữ liệu raw sau 1 ngày
        ↓
    Đề nói rõ: "dữ liệu nguồn phải
      giữ TỐI THIỂU 5 NĂM"
        ↓
    Rẻ nhất nhưng vi phạm quy định

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Vùng raw rẻ hơn 23 lần | | | Vùng curated truy vấn nhanh và rẻ hơn | | | Vẫn giữ đủ 5 năm theo quy định | |

⚠ Và cần cẩn thận với chi phí CHUYỂN TẦNG:

Chuyển sang Deep Archive: khoảng
  0,05 USD cho 1.000 object
        ↓
    Hàng triệu tệp nhỏ
    → phí chuyển tầng lớn hơn cả
      phí lưu trữ tiết kiệm được
        ↓
    Gom tệp nhỏ trước khi chuyển

⚠ Và Deep Archive tính tối thiểu 40 KB mỗi object:

Tệp 5 KB
    → tính tiền như 40 KB
        ↓
    Cộng thêm 8 KB siêu dữ liệu
      ở Standard
        ↓
    Với hàng triệu tệp nhỏ, gom
      lại trước là bắt buộc

⚠ Và có lựa chọn khác đáng cân nhắc: Intelligent-Tiering:

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

Không đoán được mẫu truy cập
    → Intelligent-Tiering tự chuyển
        ↓
    Với vùng raw thì biết chắc rồi
    → luật vòng đời rẻ hơn

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

**A. Chuyển dữ liệu vùng curated sang Deep Archive sau 1 ngày — đây là phương án gần nhất và thật sự là lớp lưu trữ rẻ nhất, nhưng nhà phân tích chạy truy vấn Athena trên vùng curated, mà Deep Archive không truy vấn trực tiếp được và cần 12-48 giờ để khôi phục.
**B. Ghi vùng curated bằng định dạng CSV — CSV không nén và lưu theo dòng, làm Athena quét nhiều dữ liệu hơn hẳn.
**E. Dùng Lambda xoá dữ liệu vùng raw sau 1 ngày — vi phạm yêu cầu giữ tối thiểu 5 năm.

Ghi nhớ

⚠ Sáu lớp lưu trữ S3 và thời gian lấy ra — bảng phải thuộc: | Lớp | Lấy ra | Tối thiểu | |---|---|---| | Standard | tức thì | không | | Intelligent-Tiering | tức thì (tầng nóng) | không | | Standard-IA | tức thì | 30 ngày | | Glacier Instant Retrieval | tức thì | 90 ngày | | Glacier Flexible Retrieval | 1 phút - 12 giờ | 90 ngày | | Glacier Deep Archive | 12-48 giờ | 180 ngày |

Từ khoá nhận diện:

"keep for compliance, never read" → Deep Archive "queried by analysts" → giữ ở Standard hoặc Standard-IA "reduce Athena cost" → Parquet + phân vùng "unknown access pattern" → Intelligent-Tiering

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

⚠ Phân vùng quan trọng hơn cả định dạng:

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

Không phân vùng: quét 5 năm dữ liệu
        ↓
    Có phân vùng: quét một tháng
    → giảm 60 lần

Ba lưu ý về Glue ETL: | Lưu ý | Chi tiết | |---|---| | Ghi Parquet bằng glueparquet nhanh hơn | | | partitionKeys tạo phân vùng tự động | | | Job bookmark tránh xử lý lại dữ liệu cũ | |

⚠ Job bookmark tiết kiệm rất nhiều:

Không có bookmark: mỗi lần chạy
  xử lý lại toàn bộ vùng raw
        ↓
    Có: chỉ xử lý tệp mới
    → thời gian và chi phí giảm
      theo tỷ lệ dữ liệu mới

Ba lưu ý về kích thước tệp: | Vấn đề | Cách chữa | |---|---| | Quá nhiều tệp nhỏ | gom lại, nhắm 128-512 MB mỗi tệp | | Chi phí chuyển tầng cao | gom trước khi chuyển | | Athena chậm | tệp nhỏ làm tăng chi phí liệt kê |

⚠ Glue có tính năng gom tệp nhỏ:

format_options={"groupFiles": "inPartition",
                "groupSize": "134217728"}

Ba lưu ý về nén: | Codec | Đặc điểm | |---|---| | Snappy | nhanh, nén vừa — mặc định tốt | | GZIP | nén tốt hơn, chậm hơn | | ZSTD | cân bằng tốt nhất hiện nay |

Ba lưu ý về vòng đời: | Lưu ý | Chi tiết | |---|---| | Lọc theo tiền tố hoặc thẻ | | | Chuyển tầng tính phí theo số object | | | Dọn cả multipart dở dang | |

⚠ Luôn thêm quy tắc dọn multipart:

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

Phần dở dang không hiện khi liệt
  kê object
    → nhưng vẫn tính tiền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | S3 Storage Lens xem phân bố lớp lưu trữ | | | So chi phí Athena trước và sau khi đổi Parquet | | | Kiểm object đã chuyển tầng đúng chưa | |

Và một lời khuyên: hãy gom tệp nhỏ lại trước khi đặt luật chuyển sang Deep Archive. Phí chuyển tầng tính theo số object chứ không theo dung lượng, nên hàng triệu tệp nhỏ có thể khiến việc "tiết kiệm chi phí lưu trữ" tốn nhiều hơn số tiền nó tiết kiệm được.

Câu 330 Continuous Improvement for Existing Solutions

The DevOps team at a financial services company has provisioned a new GPU optimized EC2 instance X by choosing the default security group of the default VPC. The team can ping instance X from other instances in the VPC. The other instances were also created using the default security group. The next day, the team launches another GPU optimized instance Y by creating a new security group and attaching it to instance Y. All other configuration options for instance Y are chosen as default. However, the team is not able to ping instance Y from other instances in the VPC.

As a Solutions Architect Professional, which of the following would you identify as the root cause of the issue?

A
Instance X is in the default security group. The default rules for the default security group allow inbound traffic from all sources. Instance Y is in a new security group. The default rules for a security group that you create allow no inbound traffic
B
Instance X is in the default security group. The default rules for the default security group allow no inbound traffic from all sources. Instance Y is in a new security group. The default rules for a security group that you create allow inbound traffic from all sources
C
Instance X is in the default security group. The default rules for the default security group allow inbound traffic from network interfaces (and their associated instances) that are assigned to the same security group. Instance Y is in a new security group. The default rules for a security group that you create allow no inbound traffic
D
Instance X is in the default security group. The default rules for the default security group allow no inbound traffic from network interfaces (and their associated instances) that are assigned to the same security group. Instance Y is in a new security group. The default rules for a security group that you create allow inbound traffic from all sources

Xem giải thích

Đáp án

**C — Instance X nằm trong security group mặc định, mà quy tắc mặc định của security group mặc định cho phép lưu lượng vào từ các network interface được gán CÙNG security group đó; instance Y nằm trong một security group mới, mà quy tắc mặc định của security group tự tạo là KHÔNG cho phép lưu lượng vào nào cả.

Vì sao đúng

Câu này kiểm tra hai sự thật rất cụ thể mà nhiều người nhớ sai.

⚠ Sự thật thứ nhất: security group MẶC ĐỊNH có một quy tắc vào đặc biệt:

Quy tắc vào của SG mặc định:
    Nguồn = CHÍNH security group đó
        ↓
    Nghĩa là: mọi instance dùng
      SG mặc định nói chuyện được
      với nhau
        ↓
    KHÔNG phải "cho phép từ mọi
      nguồn"

Đây là lý do mệnh đề A sai — nó nói SG mặc định cho phép từ mọi nguồn.

Xem quy tắc mặc định:

aws ec2 describe-security-groups \
  --filters Name=group-name,Values=default \
  --query 'SecurityGroups[0].IpPermissions'

[{"IpProtocol": "-1",
  "UserIdGroupPairs": [{"GroupId": "sg-0abc123"}],
  "IpRanges": []}]

⚠ UserIdGroupPairs trỏ về chính nó — đó là điểm mấu chốt:

Nguồn không phải là dải IP
        ↓
    Nguồn là MỘT SECURITY GROUP
        ↓
    Instance nào mang SG đó thì
      được vào

⚠ Sự thật thứ hai: security group TỰ TẠO không có quy tắc vào nào:

`create-security-group`
        ↓
    Quy tắc VÀO: rỗng
    → không ai vào được
        ↓
    Quy tắc RA: cho phép tất cả

Đây là lý do mệnh đề B và D sai — cả hai nói SG tự tạo cho phép lưu lượng vào.

⚠ Và bảng so sánh đầy đủ: | Loại SG | Quy tắc VÀO | Quy tắc RA | |---|---|---| | Mặc định | cho phép từ chính SG đó | cho phép tất cả | | Tự tạo | RỖNG | cho phép tất cả |

Sửa lỗi — cho phép ping:

aws ec2 authorize-security-group-ingress \
  --group-id sg-moi-cua-Y \
  --protocol icmp --port -1 \
  --source-group sg-mac-dinh

⚠ Tham chiếu security group làm nguồn tốt hơn dùng CIDR:

Dùng CIDR: IP đổi là phải sửa
  quy tắc
        ↓
    Dùng SG làm nguồn: máy mới
      thêm vào SG đó tự được phép
        ↓
    Đây là thực hành chuẩn trên AWS

⚠ Và ping cần ICMP, không phải TCP — chi tiết dễ quên:

--protocol icmp --port -1

Mở cổng 22 hay 80 không giúp
  ping được
        ↓
    ICMP là giao thức riêng
    → `--port -1` nghĩa là mọi loại
      ICMP

⚠ Và security group là STATEFUL — khác hẳn NACL: | Tiêu chí | Security group | NACL | |---|---|---| | Trạng thái | stateful | stateless | | Quy tắc | chỉ Allow | Allow và Deny | | Áp ở | ENI | subnet | | Đánh giá | mọi quy tắc | theo thứ tự số |

Stateful: cho phép vào thì phản
  hồi tự được ra
        ↓
    Không phải mở quy tắc ra riêng

⚠ Và đây là lý do NACL không phải nguyên nhân trong đề:

Cả hai instance ở cùng VPC mặc định
        ↓
    NACL mặc định cho phép mọi
      lưu lượng vào và ra
        ↓
    Nên khác biệt duy nhất là
      security group

Ba lợi ích của việc dùng SG làm nguồn: | Lợi ích | Chi tiết | |---|---| | Không phụ thuộc IP | | | Máy mới tự được phép | | | Quy tắc đọc hiểu được về mặt nghiệp vụ | |

⚠ Và mẫu phân tầng bằng security group rất đáng học:

sg-web: cho phép 443 từ Internet
        ↓
    sg-ung-dung: cho phép 8080 từ
      sg-web
        ↓
    sg-csdl: cho phép 3306 từ
      sg-ung-dung
        ↓
    Không có IP nào trong quy tắc
    → mở rộng bao nhiêu cũng đúng

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

**A. SG mặc định cho phép lưu lượng vào từ mọi nguồn; SG tự tạo không cho phép lưu lượng vào nào — đây là phương án gần nhất và vế thứ hai hoàn toàn đúng, nhưng SG mặc định chỉ cho phép từ chính nó, không phải từ mọi nguồn.
**B. SG mặc định không cho phép lưu lượng vào; SG tự tạo cho phép từ mọi nguồn — ngược hoàn toàn với thực tế.
**D. SG mặc định không cho phép từ interface cùng SG; SG tự tạo cho phép từ mọi nguồn — cũng ngược.

Ghi nhớ

⚠ Bốn điều phải thuộc về security group: | Điều | Nội dung | |---|---| | 1 | Stateful — cho vào thì phản hồi tự ra được | | 2 | Chỉ có Allow, không có Deny | | | 3 | SG mặc định: cho phép từ chính nó | | 4 | SG tự tạo: không có quy tắc vào nào |

Từ khoá nhận diện:

"can't reach new instance, default settings" → SG mới không có inbound rule "need explicit deny" → NACL "allow from another tier" → tham chiếu SG làm nguồn "ping fails" → thiếu quy tắc ICMP

Ba lưu ý về NACL: | Lưu ý | Chi tiết | |---|---| | Stateless — phải mở cả hai chiều | | | Nhớ mở dải cổng tạm 1024-65535 chiều ra | | | Xử lý theo số thứ tự, dừng ở quy tắc khớp đầu | |

⚠ Quên dải cổng tạm là lỗi kinh điển với NACL:

Cho phép vào cổng 443
        ↓
    Phản hồi đi ra từ cổng tạm
    → NACL chặn
        ↓
    Kết nối treo mà không có
      lỗi rõ

Ba lưu ý về hạn ngạch: | Hạn ngạch | Mặc định | |---|---| | Quy tắc mỗi SG | 60 vào, 60 ra | | SG mỗi ENI | 5 (nâng lên 16) | | SG mỗi VPC | 2.500 |

Ba lưu ý về VPC mặc định: | Lưu ý | Chi tiết | |---|---| | Có subnet công khai ở mỗi AZ | | | Có internet gateway và route sẵn | | | Instance nhận IP công khai tự động | |

⚠ VPC mặc định tiện nhưng không hợp cho sản xuất:

Mọi subnet đều công khai
        ↓
    Instance có IP công khai
    → bề mặt tấn công lớn
        ↓
    Sản xuất nên tự tạo VPC với
      subnet riêng

Ba lưu ý về chẩn đoán kết nối: | Công cụ | Việc | |---|---| | VPC Reachability Analyzer | phân tích đường đi, chỉ ra chỗ chặn | | VPC Flow Log | xem ACCEPT hay REJECT | | describe-security-groups | xem quy tắc thật |

⚠ Reachability Analyzer chỉ đúng chỗ chặn:

aws ec2 create-network-insights-path \
  --source i-nguon --destination i-dich \
  --protocol tcp --destination-port 3306

Kết quả nói rõ: security group nào,
  NACL nào, route table nào chặn

Ba lưu ý về thiết kế: | Lưu ý | Chi tiết | |---|---| | Một SG mỗi tầng ứng dụng | | | Tham chiếu SG thay vì CIDR | | | Đặt tên và mô tả rõ ràng | |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | Config rule phát hiện SG mở 0.0.0.0/0 | | | CloudTrail ghi mọi thay đổi SG | | | EventBridge cảnh báo khi có SG mở rộng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | describe-security-groups xem quy tắc thật | | | Chạy Reachability Analyzer giữa hai máy | | | Xem VPC Flow Log tìm dòng REJECT | |

Và một lời khuyên: hãy tham chiếu security group làm nguồn thay vì viết dải CIDR. Quy tắc "cho phép cổng 3306 từ sg-ung-dung" vẫn đúng khi đội ứng dụng co giãn từ 2 lên 200 máy — còn một danh sách IP thì sai ngay từ lần co giãn đầu tiên.

Trang 33 / 123 — tổng 1221 câu hỏi