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

Tìm thấy 2194 câu.

Câu 811 AWS Application Integration

There are two applications in a company: a sender application that sends messages containing payloads, and a processing application that receives messages containing payloads. The company wants to implement an AWS service to handle messages between these two different applications. The sender application sends on average 1,000 messages each hour and the messages depending on the type sometimes take up to 2 days to be processed. If the messages fail to process, they must be retained so that they do not impact the processing of any remaining messages.

Which solution meets these requirements and is the MOST operationally efficient?

  1. A

    Provide an Amazon Simple Queue Service (Amazon SQS) queue for the sender and processor applications. Set up a dead-letter queue to collect failed messages.
  2. B

    Receive the messages from the sender application using an Amazon Kinesis data stream. Utilize the Kinesis Client Library (KCL) to integrate the processing application.
  3. C

    Set up a Redis database on Amazon EC2. Configure the instance to be used by both applications. The messages should be stored, processed, and deleted, respectively.
  4. D

    Subscribe the processing application to an Amazon Simple Notification Service (Amazon SNS) topic to receive notifications. Write to the SNS topic using the sender application.
Xem giải thích

Đáp án

A — Dùng Amazon SQS giữa ứng dụng gửi và ứng dụng xử lý, thiết lập dead-letter queue thu thập thông điệp thất bại.

Vì sao đúng

Đề nêu ba yêu cầu, và SQS với DLQ đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Truyền thông điệp giữa hai ứng dụng | SQS tách rời hai bên | | Xử lý có thể mất TỚI 2 NGÀY | SQS giữ thông điệp tới 14 ngày | | Thông điệp lỗi phải được GIỮ LẠI, không chặn phần còn lại | dead-letter queue |

Vế thứ hai đáng kiểm chứng bằng con số:

SQS message retention: 60 giây tới 14 NGÀY
    → xử lý mất 2 ngày → hoàn toàn nằm trong khoảng
        ↓
    Và visibility timeout tối đa 12 GIỜ
    → với việc chạy 2 ngày, phải GIA HẠN định kỳ

Gia hạn visibility timeout cho việc chạy lâu:

while dang_xu_ly:
    sqs.change_message_visibility(
        QueueUrl=url, ReceiptHandle=rh, VisibilityTimeout=43200)
    time.sleep(30000)

Hoặc thiết kế lại thành nhiều bước ngắn hơn.

Và DLQ giải quyết vế thứ ba:

Không có DLQ:
    Thông điệp lỗi → thử lại → lỗi tiếp → thử lại...
        ↓
    ✗ chiếm chỗ trong hàng đợi
    ✗ tiêu tài nguyên vô ích
    ✗ tới khi hết thời gian giữ thì BIẾN MẤT

Có DLQ:
    Thất bại đủ maxReceiveCount lần → chuyển sang DLQ
        ↓
    ✓ hàng đợi chính thông suốt
    ✓ thông điệp lỗi được GIỮ để điều tra

Cấu hình:

aws sqs create-queue --queue-name hang-doi-dlq   --attributes '{"MessageRetentionPeriod":"1209600"}'

aws sqs set-queue-attributes --queue-url <url-chinh>   --attributes '{"MessageRetentionPeriod":"1209600",
    "VisibilityTimeout":"43200",
    "RedrivePolicy":"{\"deadLetterTargetArn\":\"<arn-dlq>\",
                      \"maxReceiveCount\":\"3\"}"}'

Và 1.000 thông điệp mỗi giờ là tải rất nhỏ với SQS:

SQS Standard: thông lượng gần như vô hạn
    → 1.000/giờ ≈ 0,3 thông điệp mỗi giây
        ↓
    Không có vấn đề gì về quy mô

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

  • **B. Dùng Kinesis Data Stream với KCL — đây là phương án gần nhất và cũng tách rời được hai ứng dụng, nhưng nó phức tạp hơn cần thiết: Kinesis dành cho luồng dữ liệu tần suất cao với nhiều consumer, và không có cơ chế dead-letter dựng sẵn cho từng bản ghi. Với 1.000 thông điệp mỗi giờ, SQS đơn giản và phù hợp hơn.
  • **D. SNS topic cho ứng dụng xử lý đăng ký — SNS KHÔNG giữ thông điệp: nếu subscriber lỗi, thông điệp mất. Và không chờ được 2 ngày.
  • **C. Dựng Redis trên EC2 làm nơi trao đổi — tự vận hành hạ tầng: phải lo sẵn sàng cao, bền vững, và tự viết logic thử lại. Đi ngược yêu cầu "most operationally efficient".

Ghi nhớ

Bốn cơ chế thời gian của SQS — bảng phải thuộc: | Cơ chế | Khoảng cho phép | |---|---| | Message retention | 60 giây – 14 NGÀY | | Visibility timeout | 0 – 12 GIỜ | | Delay queue | 0 – 15 phút | | Receive wait time (long polling) | 0 – 20 giây |

Hai con số đầu là chìa khoá của câu này.

Ba cơ chế xử lý việc chạy lâu: | Cơ chế | Chi tiết | |---|---| | Gia hạn visibility timeout định kỳ | heartbeat | | Chia nhỏ thành nhiều bước | với Step Functions | | Dùng Step Functions callback pattern | chờ tới 1 năm |

Step Functions callback đáng biết:

{"Type": "Task",
 "Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
 "Parameters": {"QueueUrl":"...",
                "MessageBody":{"TaskToken.$":"$$.Task.Token"}}}

Gửi task token qua SQS
    → hệ thống xử lý xong gọi SendTaskSuccess
        ↓
    Chờ được tới MỘT NĂM, không phải gia hạn gì

Ba nguyên tắc cấu hình DLQ: | Nguyên tắc | Chi tiết | |---|---| | DLQ phải CÙNG LOẠI với hàng đợi chính | Standard với Standard | | Thời gian giữ DLQ nên DÀI HƠN | có thời gian điều tra | | maxReceiveCount 3–5 | đủ cho lỗi tạm thời |

⚠ Và thời gian giữ tính từ lúc vào hàng đợi GỐC:

Thông điệp vào hàng đợi chính lúc T
    → thất bại, chuyển sang DLQ lúc T+2 ngày
        ↓
    Thời gian giữ KHÔNG đặt lại
    → nó bị xoá tại T+14 ngày dù mới vào DLQ
        ↓
    Đặt DLQ giữ đủ 14 ngày

Ba thao tác với DLQ: | Thao tác | Chi tiết | |---|---| | Xem nội dung để hiểu lỗi | | | Sửa lỗi ở consumer hoặc dữ liệu | | | Redrive về hàng đợi chính | |

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

⚠ Và ĐẶT ALARM cho DLQ là bắt buộc:

aws cloudwatch put-metric-alarm --alarm-name dlq-co-thong-diep   --metric-name ApproximateNumberOfMessagesVisible --namespace AWS/SQS   --dimensions Name=QueueName,Value=hang-doi-dlq   --statistic Maximum --period 300 --threshold 0   --comparison-operator GreaterThanThreshold

DLQ không có alarm
    → thông điệp lỗi nằm im không ai biết
        ↓
    Chỉ chuyển vấn đề từ "mất thông điệp" sang
      "thông điệp nằm trong hàng đợi không ai mở"

Hai loại hàng đợi SQS — nhắc lại: | | Standard | FIFO | |---|---|---| | Thông lượng | gần như vô hạn | 300/3.000 msg/giây | | Thứ tự | không đảm bảo | đảm bảo trong group | | Trùng lặp | có thể | đúng một lần |

Ba yêu cầu với consumer khi dùng Standard: | Yêu cầu | Chi tiết | |---|---| | IDEMPOTENT | giao ít nhất một lần | | Chỉ xoá SAU KHI xử lý xong | | | Xử lý được lỗi và có DLQ | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | chỉ báo trải nghiệm tốt nhất | | ApproximateNumberOfMessagesVisible | tồn đọng | | Số thông điệp trong DLQ | có lỗi |

Ba giới hạn của SQS: | Giới hạn | Giá trị | |---|---| | Kích thước thông điệp | 256 KB | | Thông điệp lớn hơn | Extended Client Library với S3 | | Số thông điệp trong hàng đợi | không giới hạn |

Ba lựa chọn cho consumer: | Lựa chọn | Đặc điểm | |---|---| | EC2 trong ASG co giãn theo hàng đợi | cho việc chạy lâu | | Lambda | giới hạn 15 phút — KHÔNG hợp với 2 ngày | | Fargate | container, không giới hạn thời gian |

Dòng giữa quan trọng với đề này:

Xử lý mất tới 2 ngày
    → Lambda hoàn toàn không dùng được
        ↓
    EC2 hoặc Fargate là lựa chọn đúng

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Standard queue | ~0,40 USD mỗi triệu request | | 1.000 thông điệp/giờ ≈ 720.000/tháng | dưới 1 USD | | Long polling giảm số request | |

Và một lời khuyên: hãy cân nhắc Step Functions callback pattern nếu việc xử lý thật sự kéo dài hai ngày. Visibility timeout tối đa của SQS là 12 giờ, nên bạn sẽ phải viết logic heartbeat gia hạn — trong khi Step Functions chờ được tới một năm mà không cần bất kỳ mã nào cho việc đó.

Câu 812 AWS Application Integration

A web application allows users to upload photos and add graphical elements to them. The application offers two tiers of service: free and paid. Photos uploaded by paid users should be processed before those submitted using the free tier. The photos are uploaded to an Amazon S3 bucket which uses an event notification to send the job information to Amazon SQS.

How should a Solutions Architect configure the Amazon SQS deployment to meet these requirements?

  1. A

    Use a separate SQS Standard queue for each tier. Configure Amazon EC2 instances to prioritize polling for the paid queue over the free queue.
  2. B

    Use one SQS standard queue. Use batching for the paid photos and short polling for the free photos.
  3. C

    Use a separate SQS FIFO queue for each tier. Set the free queue to use short polling and the paid queue to use long polling.
  4. D

    Use one SQS FIFO queue. Assign a higher priority to the paid photos so they are processed first.
Xem giải thích

Đáp án

A — Dùng hàng đợi SQS Standard RIÊNG cho mỗi hạng; cấu hình EC2 ưu tiên lấy việc từ hàng đợi trả phí trước hàng đợi miễn phí.

Vì sao đúng

Đề nêu yêu cầu rõ: ảnh của người dùng trả phí phải xử lý TRƯỚC.

SQS KHÔNG có độ ưu tiên trong một hàng đợi
    → không đánh dấu thông điệp "ưu tiên cao" được
        ↓
    Cách duy nhất: TÁCH thành hai hàng đợi
    → consumer quyết định lấy từ đâu trước

Logic consumer:

def lay_viec():
    tn = sqs.receive_message(QueueUrl=URL_TRA_PHI,
                             MaxNumberOfMessages=10, WaitTimeSeconds=1)
    if tn.get('Messages'):
        return tn['Messages'], URL_TRA_PHI
    tn = sqs.receive_message(QueueUrl=URL_MIEN_PHI,
                             MaxNumberOfMessages=10, WaitTimeSeconds=20)
    return tn.get('Messages', []), URL_MIEN_PHI

WaitTimeSeconds khác nhau là chi tiết quan trọng:

Hàng đợi trả phí: chờ NGẮN (1 giây)
    → trống thì chuyển sang miễn phí ngay

Hàng đợi miễn phí: chờ DÀI (20 giây, long polling)
    → tiết kiệm chi phí API khi cả hai trống

Và cần tránh bỏ đói hàng đợi miễn phí:

Nếu hàng đợi trả phí LUÔN có việc
    → consumer không bao giờ chạm tới miễn phí
        ↓
    Giải pháp: dành riêng một phần worker cho miễn phí
    → ví dụ 70% ưu tiên trả phí, 30% chỉ đọc miễn phí

Và co giãn riêng từng hàng đợi:

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-tra-phi   --policy-name theo-hang-doi --policy-type TargetTrackingScaling   --target-tracking-configuration '{
    "TargetValue": 5,
    "CustomizedMetricSpecification": {
      "MetricName":"ApproximateNumberOfMessagesVisible",
      "Namespace":"AWS/SQS","Statistic":"Average",
      "Dimensions":[{"Name":"QueueName","Value":"hang-doi-tra-phi"}]}}'

Mục tiêu thấp hơn cho hàng đợi trả phí — thêm máy sớm hơn.

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

  • **C. Hai hàng đợi FIFO, đặt hàng đợi miễn phí dùng short polling và trả phí dùng long polling — đây là phương án gần nhất và có tách hai hàng đợi đúng, nhưng nó hiểu sai chức năng của polling: short và long polling quyết định thời gian CHỜ khi hàng đợi trống, không quyết định độ ưu tiên. Và dùng long polling cho hàng đợi trả phí còn khiến consumer chờ lâu hơn ở đó.
  • **B. MỘT hàng đợi Standard, dùng batching cho ảnh trả phí và short polling cho ảnh miễn phí — không tách được hai loại: cùng một hàng đợi thì consumer không biết thông điệp nào thuộc hạng nào trước khi nhận.
  • **D. MỘT hàng đợi FIFO, gán độ ưu tiên cao hơn cho ảnh trả phí — SQS FIFO không có thuộc tính độ ưu tiên: nó chỉ đảm bảo thứ tự trong message group.

Ghi nhớ

SQS không có độ ưu tiên — cách duy nhất là tách hàng đợi:

Hàng đợi ưu tiên cao  ─┐
                       ├─→ consumer ưu tiên đọc hàng đợi cao trước
Hàng đợi ưu tiên thấp ─┘

Short polling và long polling — bảng phải thuộc: | | Short polling | Long polling | |---|---|---| | Chờ khi trống | trả về ngay | tới 20 giây | | Số lời gọi API rỗng | nhiều | ít | | Chi phí | cao hơn | thấp hơn | | Ảnh hưởng độ ưu tiên | KHÔNG | KHÔNG |

Dòng cuối là điểm mà phương án B và C hiểu sai.

Ba lợi ích của tách hàng đợi: | Lợi ích | Chi tiết | |---|---| | Kiểm soát thứ tự phục vụ | ← câu này | | Co giãn ĐỘC LẬP từng hạng | | | Đo được SLA riêng cho từng hạng | |

Ba mẫu ưu tiên: | Mẫu | Chi tiết | |---|---| | Ưu tiên nghiêm ngặt | luôn đọc hàng đợi cao trước | | Chia tỷ lệ worker | tránh bỏ đói | | Trọng số theo vòng | cứ 3 lô cao thì 1 lô thấp |

Bỏ đói là rủi ro thật của ưu tiên nghiêm ngặt:

Hàng đợi trả phí luôn có việc
    → hàng đợi miễn phí không bao giờ được đọc
        ↓
    Người dùng miễn phí chờ vô hạn
    → và không có cảnh báo nào cho tới khi họ phàn nàn

Đặt alarm cho hàng đợi ưu tiên thấp:

aws cloudwatch put-metric-alarm --alarm-name mien-phi-cho-qua-lau   --metric-name ApproximateAgeOfOldestMessage --namespace AWS/SQS   --dimensions Name=QueueName,Value=hang-doi-mien-phi   --statistic Maximum --period 300 --threshold 1800   --comparison-operator GreaterThanThreshold

Hai loại hàng đợi — nhắc lại: | | Standard | FIFO | |---|---|---| | Thông lượng | gần như vô hạn | 300/3.000 msg/giây | | Thứ tự | không đảm bảo | trong message group | | Trùng lặp | có thể | đúng một lần |

Với xử lý ảnh không cần thứ tự, Standard là lựa chọn đúng.

Ba khái niệm riêng của FIFO: | Khái niệm | Việc | |---|---| | MessageGroupId | thứ tự trong group | | MessageDeduplicationId | khử trùng lặp 5 phút | | — | KHÔNG có khái niệm độ ưu tiên |

Ba metric để theo dõi từng hàng đợi: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | tồn đọng | | ApproximateAgeOfOldestMessage | SLA từng hạng | | NumberOfMessagesReceived | thông lượng |

Ba lựa chọn thay thế cho ưu tiên: | Lựa chọn | Chi tiết | |---|---| | Hai hàng đợi + consumer ưu tiên | ← câu này | | Hai ASG riêng, cỡ khác nhau | | | AWS Batch với job queue có priority | dựng sẵn cơ chế ưu tiên |

AWS Batch đáng cân nhắc:

Nhiều job queue với priority khác nhau
    → cùng trỏ tới một compute environment
    → Batch tự lập lịch theo độ ưu tiên
        ↓
    Không phải tự viết logic chọn hàng đợi

Ba lưu ý về kiến trúc xử lý ảnh: | Lưu ý | Chi tiết | |---|---| | Ảnh ở S3, chỉ gửi khoá qua SQS | thông điệp tối đa 256 KB | | Lưu kết quả vào bucket KHÁC | tránh vòng lặp sự kiện | | Đặt timeout cho việc xử lý | |

Ba cách giảm chi phí: | Cách | Tiết kiệm | |---|---| | Spot cho worker hạng miễn phí | trả phí dùng On-Demand | | Long polling | giảm số request | | Nhận theo lô (MaxNumberOfMessages: 10) | |

Dòng đầu là mẫu rất hợp lý:

Người dùng trả phí: worker On-Demand, đảm bảo
Người dùng miễn phí: worker Spot, rẻ hơn 90%
        ↓
    Mức dịch vụ khác nhau, chi phí khác nhau

Ba thông số SQS quan trọng: | Thông số | Chi tiết | |---|---| | Visibility timeout ≥ thời gian xử lý | | | DLQ với maxReceiveCount | | | Long polling 20 giây | |

Và một lời khuyên: hãy dành riêng một phần worker chỉ đọc hàng đợi miễn phí. Ưu tiên nghiêm ngặt hoạt động tốt cho tới ngày lượng người dùng trả phí đủ lớn để hàng đợi của họ không bao giờ trống — và khi đó người dùng miễn phí ngừng được phục vụ hoàn toàn trong khi mọi metric hệ thống vẫn báo bình thường.

Câu 813 AWS Analytics

A genetics research firm processes DNA sequencing data for multiple clients. The raw data is stored in relational databases provided by each client. The company must extract the data, apply unique transformation algorithms for each client, and store the processed results in Amazon S3.

Due to the sensitivity of the data, the company must encrypt it both during processing and at rest in Amazon S3. Each client must have their own encryption keys to meet compliance requirements. The company also wants to minimize operational overhead while implementing this solution.

Which solution will meet these requirements with the LEAST operational effort?

  1. A

    Deploy a centralized Amazon EMR cluster to process data for all clients. Encrypt the data in transit using TLS certificates for each client and store the data in Amazon S3 using server-side encryption with Amazon S3 managed keys (SSE-S3).
  2. B

    Deploy an Amazon EMR cluster for each client with a client-specific Hadoop configuration. Use client-side encryption (CSE) to encrypt data with customer-managed root keys during transformations and upload the results to S3.
  3. C

    Use AWS Glue to create a single ETL pipeline for all clients. Configure the pipeline to tag each client’s data and use server-side encryption with AWS KMS keys (SSE-KMS) to encrypt data based on client-specific keys before storing it in Amazon S3.
  4. D

    Use AWS Glue to create individual ETL jobs for each client. Attach a security configuration that uses client-specific AWS KMS keys for server-side encryption (SSE-KMS) during processing and storage in S3.
Xem giải thích

Đáp án

D — Dùng AWS Glue tạo ETL job RIÊNG cho từng khách hàng, gắn security configuration dùng khoá KMS riêng của từng khách cho mã hoá SSE-KMS trong lúc xử lý và khi lưu vào S3.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án D đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Trích xuất từ database quan hệ của từng khách | Glue connector | | Thuật toán biến đổi RIÊNG cho mỗi khách | job riêng cho mỗi khách | | Mỗi khách có KHOÁ MÃ HOÁ RIÊNG | security configuration riêng | | Ít công vận hành nhất | Glue serverless — không quản cụm |

Security configuration của Glue là mảnh ghép quan trọng:

Glue security configuration mã hoá:
    ✓ dữ liệu tạm trong lúc xử lý (S3 encryption)
    ✓ CloudWatch Logs của job
    ✓ Glue Data Catalog
    ✓ bookmark của job
        ↓
    Mỗi khách một security configuration với khoá riêng

Tạo:

aws glue create-security-configuration   --name cau-hinh-khach-a   --encryption-configuration '{
    "S3Encryption":[{"S3EncryptionMode":"SSE-KMS",
                     "KmsKeyArn":"<arn-khoa-khach-a>"}],
    "CloudWatchEncryption":{"CloudWatchEncryptionMode":"SSE-KMS",
                            "KmsKeyArn":"<arn-khoa-khach-a>"},
    "JobBookmarksEncryption":{"JobBookmarksEncryptionMode":"CSE-KMS",
                              "KmsKeyArn":"<arn-khoa-khach-a>"}}'

aws glue create-job --name etl-khach-a   --role <arn-role> --security-configuration cau-hinh-khach-a   --command Name=glueetl,ScriptLocation=s3://script/khach-a.py   --glue-version 4.0 --worker-type G.1X --number-of-workers 10

Và vì sao job RIÊNG cho mỗi khách:

Mỗi khách có "unique transformation algorithms"
    → logic biến đổi khác nhau
        ↓
    Một job chung với if-else theo khách
    → khó bảo trì, và KHÔNG gắn được security
      configuration khác nhau
        ↓
    Security configuration gắn ở cấp JOB, không phải cấp bản ghi

Đây là lý do kỹ thuật khiến phương án C không làm được.

Và Glue là lựa chọn ít công vận hành nhất:

AWS Glue:
    ✓ serverless — không cụm nào để dựng
    ✓ tự co giãn worker
    ✓ có connector sẵn cho database quan hệ
    ✓ trả theo DPU-giờ khi chạy

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

  • **C. Dùng MỘT Glue pipeline chung, gắn tag cho dữ liệu từng khách và dùng SSE-KMS với khoá theo khách — đây là phương án gần nhất và ý tưởng đúng về mã hoá, nhưng nó không làm được về mặt kỹ thuật: security configuration gắn ở cấp job, không chọn được khoá theo từng bản ghi trong cùng một job. Và một pipeline chung không chứa được thuật toán riêng cho mỗi khách.
  • **B. Dựng EMR cluster RIÊNG cho mỗi khách với client-side encryption — công vận hành cao nhất: phải dựng, cấu hình và bảo trì một cụm Hadoop cho mỗi khách hàng.
  • **A. Một EMR cluster chung với SSE-S3 — hai lỗi: SSE-S3 dùng khoá do AWS quản lý, không tách được theo khách hàng; và cụm chung không chứa được thuật toán riêng.

Ghi nhớ

Ba dịch vụ ETL của AWS — bảng phải thuộc: | Dịch vụ | Đặc điểm | |---|---| | AWS Glue | serverless, Spark được quản lý, có Data Catalog | | Amazon EMR | cụm Hadoop/Spark tự quản, linh hoạt nhất | | AWS Batch | job container theo lô |

Từ khoá nhận diện:

"least operational effort", "serverless ETL" → AWS Glue "custom Hadoop config", "full control" → EMR "container jobs with queue" → AWS Batch

Bốn thứ Glue security configuration mã hoá: | Đối tượng | Chế độ | |---|---| | S3 (dữ liệu đầu ra và tạm) | SSE-S3, SSE-KMS | | CloudWatch Logs | SSE-KMS | | Job bookmark | CSE-KMS | | Data Catalog | cấu hình riêng |

Ba cách mã hoá S3 — nhắc lại: | Cách | Ai giữ khoá | Tách theo khách | |---|---|---| | SSE-S3 | AWS hoàn toàn | ❌ | | SSE-KMS | KMS, bạn kiểm soát | ✅ khoá riêng mỗi khách | | Client-side | bạn hoàn toàn | ✅ nhưng nhiều công |

Ba lợi ích của khoá riêng mỗi khách: | Lợi ích | Chi tiết | |---|---| | Cách ly mật mã | mất một khoá không lộ dữ liệu khách khác | | Audit riêng qua CloudTrail | ai dùng khoá nào | | Thu hồi quyền bằng key policy | |

Key policy giới hạn theo job:

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::123456789012:role/glue-khach-a"},
 "Action": ["kms:Decrypt","kms:GenerateDataKey"],
 "Resource": "*"}

Ba thành phần của một Glue job: | Thành phần | Việc | |---|---| | Connection | tới database nguồn | | Script | logic biến đổi (PySpark hoặc Scala) | | Security configuration | mã hoá | | Job bookmark | nhớ đã xử lý tới đâu |

Job bookmark rất hữu ích:

Bật bookmark
    → job chỉ xử lý dữ liệu MỚI từ lần chạy trước
        ↓
    Không xử lý lại toàn bộ mỗi lần

Ba loại worker của Glue: | Loại | Tài nguyên | |---|---| | G.1X | 4 vCPU, 16 GB — mặc định | | G.2X | 8 vCPU, 32 GB | | G.025X | 2 vCPU, 4 GB — cho luồng nhỏ |

Ba cách kết nối Glue tới database: | Cách | Chi tiết | |---|---| | JDBC connection | database trong VPC hoặc on-premises | | AWS Glue connector từ Marketplace | nguồn đặc biệt | | Crawler | tự phát hiện schema |

Ba lưu ý về Glue trong VPC: | Lưu ý | Chi tiết | |---|---| | Cần connection với subnet và security group | | | Security group phải tự tham chiếu | Glue dùng nhiều ENI | | Cần VPC endpoint cho S3 | tránh đi Internet |

Ba lưu ý về chi phí Glue: | Khoản | Chi tiết | |---|---| | Tính theo DPU-giờ | tối thiểu 1 phút | | Chỉ trả khi job chạy | | | Data Catalog miễn phí tới 1 triệu object | |

Ba biện pháp bảo mật bổ sung cho dữ liệu gen: | Biện pháp | Chi tiết | |---|---| | Bucket riêng cho mỗi khách | cách ly rõ ràng | | IAM role riêng cho mỗi job | quyền tối thiểu | | CloudTrail data event | ghi mọi thao tác |

Ba lưu ý về mã hoá trong lúc xử lý: | Lưu ý | Chi tiết | |---|---| | Dữ liệu tạm của Spark cũng phải mã hoá | security configuration lo | | TLS giữa Glue và database nguồn | cấu hình trong connection | | Log cũng chứa dữ liệu — phải mã hoá | |

Dòng cuối hay bị bỏ sót:

Log của job có thể chứa mẫu dữ liệu khi gỡ lỗi
    → không mã hoá log = rò rỉ dữ liệu gen
        ↓
    CloudWatchEncryption trong security configuration

Ba lựa chọn điều phối nhiều job: | Lựa chọn | Chi tiết | |---|---| | Glue Workflow | dựng sẵn trong Glue | | Step Functions | linh hoạt hơn, tích hợp nhiều dịch vụ | | EventBridge Scheduler | chạy theo lịch |

Và một lời khuyên: hãy tạo bucket riêng cho mỗi khách hàng bên cạnh khoá riêng. Cách ly ở tầng khoá là bắt buộc, nhưng cách ly ở tầng bucket khiến mọi chính sách quyền trở nên đơn giản và dễ kiểm chứng — và với dữ liệu gen, khả năng chứng minh cách ly quan trọng ngang việc thực sự cách ly.

Câu 814 AWS Migration & Transfer

The database tier of a web application is running on a Windows server on-premises. The database is a Microsoft SQL Server database. The application owner would like to migrate the database to an Amazon RDS instance.

How can the migration be executed with minimal administrative effort and downtime?

  1. A

    Use the AWS Server Migration Service (SMS) to migrate the server to Amazon EC2.Use AWS Database Migration Service (DMS) to migrate the database to RDS
  2. B

    Use the AWS Database Migration Service (DMS) to directly migrate the database to RDS. Use the Schema Conversion Tool (SCT) to enable conversion from Microsoft SQL Server to Amazon RDS
  3. C

    Use AWS DataSync to migrate the data from the database to Amazon S3. Use AWS Database Migration Service (DMS) to migrate the database to RDS
  4. D

    Use the AWS Database Migration Service (DMS) to directly migrate the database to RDS
Xem giải thích

Đáp án

D — Dùng AWS Database Migration Service (DMS) di chuyển trực tiếp database sang RDS.

Vì sao đúng

Đề nêu hai yêu cầu, và DMS đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Ít công quản trị nhất | DMS là dịch vụ được quản lý | | Thời gian ngừng tối thiểu | full load + CDC |

Và điểm mấu chốt: SQL Server sang SQL Server KHÔNG cần chuyển đổi schema.

AWS Schema Conversion Tool (SCT) dùng khi ĐỔI ENGINE
    → ví dụ SQL Server sang PostgreSQL
        ↓
    SQL Server → RDS for SQL Server là CÙNG engine
    → schema tương thích hoàn toàn
    → KHÔNG cần SCT

Đây là lý do phương án B thừa một bước.

Và full-load-and-cdc cho ngừng tối thiểu:

Giai đoạn ①: full load — chuyển toàn bộ dữ liệu hiện có
Giai đoạn ②: CDC — bắt thay đổi liên tục từ transaction log
        ↓
    Nguồn VẪN CHẠY suốt quá trình
    → tới lúc cắt chuyển, chênh lệch chỉ vài giây

Triển khai:

aws dms create-endpoint --endpoint-identifier nguon-sqlserver   --endpoint-type source --engine-name sqlserver   --server-name 192.168.1.50 --port 1433   --username quantri --password '<mat-khau>' --database-name QuanLy

aws dms create-endpoint --endpoint-identifier dich-rds   --endpoint-type target --engine-name sqlserver   --server-name db.abc.rds.amazonaws.com --port 1433   --username quantri --password '<mat-khau>' --database-name QuanLy

aws dms create-replication-task --replication-task-identifier di-chuyen   --source-endpoint-arn <arn-nguon> --target-endpoint-arn <arn-dich>   --replication-instance-arn <arn-instance>   --migration-type full-load-and-cdc   --table-mappings file://anh-xa.json

Và DMS Serverless bỏ luôn việc chọn cỡ replication instance:

aws dms create-replication-config   --replication-config-identifier di-chuyen   --replication-type full-load-and-cdc   --compute-config MinCapacityUnits=2,MaxCapacityUnits=16

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

  • **B. Dùng DMS di chuyển trực tiếp, dùng SCT để chuyển đổi từ SQL Server sang RDS — đây là phương án gần nhất và đúng ở phần DMS, nhưng nó thêm một bước không cần thiết: SCT dùng khi đổi engine database, còn đây là SQL Server sang SQL Server. Thêm SCT là thêm công việc và thêm chỗ có thể sai.
  • **A. Dùng Server Migration Service (SMS) chuyển máy chủ sang EC2 rồi mới dùng DMS — đường vòng không cần thiết, và AWS SMS đã ngừng cung cấp, được thay bằng Application Migration Service (MGN).
  • **C. Dùng DataSync chuyển dữ liệu sang S3 rồi mới dùng DMS — DataSync là công cụ chuyển TỆP, không hiểu cấu trúc database. Và thêm một chặng trung gian vô ích.

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

Phương án A nhắc tới AWS Server Migration Service — dịch vụ đã ngừng.

AWS SMS ngừng nhận khách hàng mới từ 2022
    → thay bằng AWS Application Migration Service (MGN)
        ↓
    Với việc di chuyển máy chủ, MGN là dịch vụ hiện tại

Điều đó khiến phương án A sai theo cả hai nghĩa: kiến trúc vòng vèo, và dịch vụ không còn tồn tại.

Ghi nhớ

Ba công cụ di chuyển của AWS — bảng phải thuộc: | Công cụ | Việc | |---|---| | AWS DMS | di chuyển DỮ LIỆU database, có CDC | | AWS SCT | chuyển đổi SCHEMA khi ĐỔI ENGINE | | AWS MGN | lift-and-shift máy chủ | | AWS DataSync | di chuyển tệp |

Quy tắc: cùng engine → chỉ cần DMS; khác engine → SCT + DMS.

Ba loại tác vụ của DMS: | Loại | Việc | |---|---| | full-load | dữ liệu hiện có, một lần | | cdc | chỉ thay đổi | | full-load-and-cdc | cả hai — ngừng tối thiểu ← câu này |

Ba thành phần của DMS: | Thành phần | Việc | |---|---| | Replication instance | máy chạy việc sao chép | | Endpoint | nguồn và đích | | Task | ánh xạ bảng và quy tắc |

Ba yêu cầu để CDC hoạt động với SQL Server: | Yêu cầu | Chi tiết | |---|---| | Bật FULL recovery model hoặc BULK_LOGGED | | | Bật MS-CDC hoặc MS-REPLICATION | tuỳ phiên bản | | User DMS có quyền đọc transaction log | |

EXEC msdb.dbo.rds_cdc_enable_db 'QuanLy';

Ba thứ DMS KHÔNG tự chuyển: | Không chuyển | Phải làm gì | |---|---| | Index phụ | tạo ở đích sau full load | | Stored procedure, function, trigger | script thủ công hoặc SCT | | Sequence, user, quyền | |

Điểm này rất quan trọng:

DMS chuyển DỮ LIỆU trong bảng
    → không chuyển đầy đủ đối tượng schema
        ↓
    Với cùng engine, dùng script generate của SQL Server
      để tạo các đối tượng đó

Ba lựa chọn di chuyển SQL Server khác: | Cách | Đặc điểm | |---|---| | DMS | ← câu này, ngừng tối thiểu | | Native backup/restore qua S3 | đơn giản nhất, có ngừng | | Log shipping | phức tạp |

Native backup/restore đáng biết:

EXEC msdb.dbo.rds_restore_database
  @restore_db_name='QuanLy',
  @s3_arn_to_restore='arn:aws:s3:::kho-backup/QuanLy.bak';

Đơn giản hơn DMS nhiều
    → nhưng phải dừng ghi trong lúc backup và restore
        ↓
    Nếu chấp nhận ngừng vài giờ, đây là cách dễ nhất

Ba lưu ý về validation: | Lưu ý | Chi tiết | |---|---| | Bật validation của DMS | so từng dòng | | Đếm số dòng từng bảng | | | Kiểm tra ràng buộc và index | |

aws dms create-replication-task ...   --replication-task-settings '{"ValidationSettings":{"EnableValidation":true}}'

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CDCLatencySource | độ trễ đọc từ nguồn | | CDCLatencyTarget | độ trễ ghi vào đích | | FullLoadThroughputRowsTarget | tốc độ tải ban đầu |

Hai metric đầu phân biệt nút thắt ở đâu.

Ba mô hình giấy phép SQL Server trên RDS: | Mô hình | Chi tiết | |---|---| | License Included | giá instance đã gồm giấy phép | | BYOL | cần Dedicated Host cho một số phiên bản | | — | RDS chủ yếu hỗ trợ License Included |

Ba phiên bản SQL Server trên RDS và Multi-AZ: | Phiên bản | Multi-AZ | |---|---| | Express, Web | ❌ | | Standard, Enterprise | ✅ |

Ba việc cần làm khi cắt chuyển: | Việc | Chi tiết | |---|---| | Xác nhận CDCLatencyTarget gần 0 | | | Dừng ghi ở nguồn | vài phút | | Đổi chuỗi kết nối của ứng dụng | |

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | Cần kết nối từ AWS tới SQL Server tại chỗ | VPN hoặc Direct Connect | | Băng thông quyết định tốc độ full load | | | Mở cổng 1433 | |

Và một lời khuyên: hãy tạo index phụ ở đích SAU KHI full load xong. DMS không chuyển index, và việc để đích không có index trong lúc nạp dữ liệu khiến quá trình nhanh hơn nhiều lần — nhưng nếu quên tạo lại trước khi cắt chuyển, ứng dụng sẽ chậm thảm hại ngay giây phút đầu tiên trên hệ thống mới.

Câu 815 AWS Analytics

A research organization wants to set up an Amazon EMR cluster for multiple departments to run their big data analytics jobs. The organization needs to ensure that each department’s workloads can access only the specific AWS services required for their analysis. Additionally, the organization wants to block access to Instance Metadata Service Version 2 (IMDSv2) on the EMR cluster's underlying EC2 instances.

Which solution will meet these requirements?

  1. A

    Configure VPC interface endpoints for each AWS service that the departments require. Route traffic from the big data workloads through these VPC endpoints.
  2. B

    Create an EMR security configuration that disables access to the Instance Metadata Service. Use this security configuration with application-specific IAM roles to submit the workloads.
  3. C

    Use EMR runtime roles to enforce granular permissions for each department's workloads. Configure the EMR cluster to use these roles when submitting jobs.
  4. D

    Assign unique EC2 IAM instance profiles to each team’s workloads. Configure the instance profiles with the specific permissions needed for each department.
Xem giải thích

Đáp án

C — Dùng EMR runtime role để áp quyền chi tiết cho từng phòng ban; cấu hình cụm EMR dùng các role đó khi gửi job.

Vì sao đúng

Đề nêu hai yêu cầu, và EMR runtime role đáp ứng cả hai cùng lúc: | Yêu cầu | Cơ chế | |---|---| | Mỗi phòng ban chỉ truy cập dịch vụ của mình | runtime role riêng cho mỗi job | | CHẶN truy cập Instance Metadata Service | runtime role TỰ ĐỘNG chặn IMDS |

Vế thứ hai là điểm ít người biết:

Khi bật EMR runtime role:
    → EMR TỰ ĐỘNG chặn ứng dụng truy cập IMDS
        ↓
    Job KHÔNG lấy được credential của EC2 instance profile
    → buộc phải dùng runtime role được cấp
        ↓
    Hai yêu cầu của đề được giải quyết bằng MỘT tính năng

Vì sao không có runtime role thì không tách được:

Mặc định: mọi job trên cụm dùng chung
  EC2 instance profile của node
        ↓
    Phòng ban A và B có QUYỀN GIỐNG NHAU
    → không cách nào phân biệt

Bật runtime role:

aws emr create-security-configuration --name cau-hinh-runtime-role   --security-configuration '{
    "AuthorizationConfiguration": {
      "IAMConfiguration": {"EnableApplicationScopedIAMRole": true}}}'

aws emr create-cluster --name cum-phan-tich   --release-label emr-7.0.0   --security-configuration cau-hinh-runtime-role   --instance-type m6i.xlarge --instance-count 3

Và gửi job với role riêng:

aws emr add-steps --cluster-id j-ABC   --steps Type=Spark,Name=phong-a,Args=[--class,com.vidu.PhanTich,s3://script/phong-a.jar]   --execution-role-arn arn:aws:iam::123456789012:role/emr-phong-a

Và mỗi role có quyền riêng:

{"Effect": "Allow",
 "Action": ["s3:GetObject","s3:PutObject"],
 "Resource": "arn:aws:s3:::du-lieu/phong-a/*"}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một cụm dùng chung cho nhiều phòng ban | tiết kiệm chi phí | | Quyền tách bạch từng job | | | IMDS bị chặn tự động | |

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

  • **B. Tạo EMR security configuration TẮT truy cập Instance Metadata Service, dùng IAM role theo ứng dụng — đây là phương án gần nhất và mô tả gần đúng cơ chế, nhưng nó tách rời hai thứ vốn là một: việc chặn IMDS trong EMR chính là hệ quả của việc bật runtime role, không phải một cấu hình độc lập. Phương án C nêu đúng tên tính năng.
  • **D. Gán EC2 instance profile riêng cho từng phòng ban — instance profile gắn với NODE, không gắn với job: mọi job chạy trên cùng node vẫn dùng chung một profile. Muốn tách thì phải dựng cụm riêng cho mỗi phòng ban.
  • **A. Cấu hình VPC interface endpoint cho từng dịch vụ — endpoint kiểm soát ĐƯỜNG ĐI mạng, không kiểm soát DANH TÍNH: mọi job trên cụm đều đi qua cùng endpoint với cùng quyền.

Ghi nhớ

Ba cách phân quyền trong EMR — bảng phải thuộc: | Cách | Mức chi tiết | |---|---| | EC2 instance profile | cả CỤM — mọi job dùng chung | | EMR runtime role | từng JOB ← câu này | | EMR File System (EMRFS) role mapping | theo user hoặc group, cho S3 |

Từ khoá nhận diện:

"per-job permissions", "block IMDS", "shared cluster" → EMR runtime role "per-user S3 access on shared cluster" → EMRFS role mapping

Ba yêu cầu để dùng runtime role: | Yêu cầu | Chi tiết | |---|---| | EMR 6.7.0 trở lên | | | Security configuration bật EnableApplicationScopedIAMRole | | | Role có trust policy cho elasticmapreduce | |

Trust policy của runtime role:

{"Effect": "Allow",
 "Principal": {"Service": "elasticmapreduce.amazonaws.com"},
 "Action": ["sts:AssumeRole","sts:TagSession"]}

Ba tác dụng của việc chặn IMDS: | Tác dụng | Chi tiết | |---|---| | Job không lấy được credential của node | | | Buộc phải dùng runtime role | | | Giảm rủi ro khi job bị xâm nhập | |

Và đây là biện pháp chung cho mọi tải container:

aws ec2 modify-instance-metadata-options --instance-id i-0abc   --http-tokens required --http-put-response-hop-limit 1

Hop limit = 1
    → gói tin từ container bị chặn
        ↓
    Nguyên tắc áp dụng cho cả EKS, ECS, EMR

Ba lớp phân quyền trong EMR: | Lớp | Kiểm soát | |---|---| | EMR service role | EMR quản lý tài nguyên AWS | | EC2 instance profile | quyền của node | | Runtime role | quyền của JOB |

Ba lựa chọn kiến trúc cho nhiều phòng ban: | Lựa chọn | Chi phí | Cách ly | |---|---|---| | Một cụm + runtime role | thấp nhất | tốt | | Cụm riêng mỗi phòng ban | cao | mạnh nhất | | EMR Serverless | theo lượng dùng | tự cách ly theo application |

EMR Serverless đáng cân nhắc:

aws emr-serverless create-application   --name ung-dung-phong-a --type SPARK --release-label emr-7.0.0

aws emr-serverless start-job-run   --application-id <id> --execution-role-arn <arn-role-phong-a>

Mỗi phòng ban một application riêng
    → execution role riêng
    → không quản cụm nào
        ↓
    Cách ly và ít công vận hành nhất

Ba lưu ý về EMRFS: | Lưu ý | Chi tiết | |---|---| | Là lớp truy cập S3 của EMR | | | Có role mapping theo user hoặc prefix | | | Hỗ trợ mã hoá theo bucket | |

Ba biện pháp bảo mật cho EMR: | Biện pháp | Chi tiết | |---|---| | Cụm trong PRIVATE subnet | | | Mã hoá at rest và in transit | qua security configuration | | Kerberos hoặc Lake Formation cho xác thực | |

Lake Formation tích hợp với EMR runtime role:

Lake Formation quản lý quyền tới bảng và CỘT
    → EMR runtime role áp quyền đó
        ↓
    Phân quyền tới cấp cột và dòng cho dữ liệu phân tích

Ba lưu ý về chi phí EMR: | Khoản | Chi tiết | |---|---| | Phí EMR cộng thêm trên giá EC2 | | | Spot cho task node | tiết kiệm nhiều | | EMR Serverless trả theo lượng dùng | |

Ba loại node trong cụm EMR: | Loại | Việc | |---|---| | Primary (master) | điều phối | | Core | tính toán và lưu trữ HDFS | | Task | chỉ tính toán — dùng Spot được |

Ba lưu ý về vận hành cụm dùng chung: | Lưu ý | Chi tiết | |---|---| | YARN queue tách tài nguyên giữa phòng ban | | | Runtime role tách quyền | | | Tag job để quy chi phí | |

Và một lời khuyên: hãy đánh giá EMR Serverless trước khi dựng cụm dùng chung. Nó cho mỗi phòng ban một application riêng với execution role riêng, không có node nào để quản lý, và không có IMDS nào để lo chặn — ba vấn đề của câu hỏi này biến mất cùng lúc.

Câu 816 AWS Security, Identity, & Compliance

A developer created an application that uses Amazon EC2 and an Amazon RDS MySQL database instance. The developer stored the database user name and password in a configuration file on the root EBS volume of the EC2 application instance. A Solutions Architect has been asked to design a more secure solution.

What should the Solutions Architect do to achieve this requirement?

  1. A

    Move the configuration file to an Amazon S3 bucket. Create an IAM role with permission to the bucket and attach it to the EC2 instance.
  2. B

    Install an Amazon-trusted root certificate on the application instance and use SSL/TLS encrypted connections to the database.
  3. C

    Attach an additional volume to the EC2 instance with encryption enabled. Move the configuration file to the encrypted volume.
  4. D

    Create an IAM role with permission to access the database. Attach this IAM role to the EC2 instance.
Xem giải thích

Đáp án

D — Tạo IAM role có quyền truy cập database và gắn role đó vào EC2 instance.

Vì sao đúng

Đề nêu vấn đề rõ: tên đăng nhập và mật khẩu database nằm trong tệp cấu hình trên đĩa.

Rủi ro:
    ✗ ai vào được máy đều đọc được
    ✗ lộ ra nếu snapshot hay AMI bị chia sẻ
    ✗ không xoay vòng tự động
    ✗ không truy vết được ai dùng

Giải pháp là bỏ hẳn mật khẩu bằng IAM database authentication:

RDS hỗ trợ xác thực bằng IAM
    → ứng dụng sinh TOKEN từ IAM role của instance
    → token có hạn 15 PHÚT
        ↓
    KHÔNG có mật khẩu nào được lưu ở đâu cả

Bật trên RDS:

aws rds modify-db-instance --db-instance-identifier db-ung-dung   --enable-iam-database-authentication --apply-immediately

Tạo user trong database dùng IAM:

CREATE USER ung_dung IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
GRANT SELECT, INSERT, UPDATE ON ban_hang.* TO 'ung_dung'@'%';

Và IAM policy cho role của EC2:

{"Effect": "Allow",
 "Action": "rds-db:connect",
 "Resource": "arn:aws:rds-db:ap-northeast-1:123456789012:dbuser:db-ABCDEFG/ung_dung"}

Và ứng dụng sinh token:

import boto3
token = boto3.client('rds').generate_db_auth_token(
    DBHostname='db.abc.ap-northeast-1.rds.amazonaws.com',
    Port=3306, DBUsername='ung_dung')
# dùng token làm mật khẩu khi kết nối

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | KHÔNG có credential dài hạn nào | | | Quyền quản lý bằng IAM | thu hồi tức thì | | Audit qua CloudTrail | |

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

  • **A. Chuyển tệp cấu hình sang S3 bucket, gắn IAM role cho EC2 đọc — đây là phương án gần nhất và có cải thiện (không còn trên đĩa cục bộ, có kiểm soát bằng IAM), nhưng nó vẫn lưu credential DÀI HẠN: mật khẩu vẫn tồn tại, chỉ đổi chỗ. Và vẫn không xoay vòng tự động.
  • **C. Gắn volume mã hoá và chuyển tệp cấu hình sang đó — mã hoá at rest không giải quyết vấn đề: ai đăng nhập được vào máy vẫn đọc được tệp bình thường, vì hệ điều hành tự giải mã.
  • **B. Cài chứng chỉ gốc và dùng SSL/TLS khi kết nối — giải quyết vấn đề khác: TLS bảo vệ dữ liệu trên đường truyền, không liên quan tới việc credential nằm ở đâu.

Ghi nhớ

Ba cách quản lý credential database — bảng phải thuộc: | Cách | Credential dài hạn | |---|---| | Tệp cấu hình trên đĩa | ✅ tệ nhất | | Secrets Manager với xoay vòng tự động | ✅ nhưng có xoay vòng | | IAM database authentication | ❌ KHÔNG có mật khẩu |

Từ khoá nhận diện:

"no long-term credentials", "IAM role" → IAM database authentication "rotate database password automatically" → Secrets Manager "store configuration securely" → Parameter Store hoặc Secrets Manager

Ba đặc điểm của IAM database authentication: | Đặc điểm | Chi tiết | |---|---| | Token có hạn 15 phút | | | Hỗ trợ MySQL, PostgreSQL, MariaDB | và Aurora | | Giới hạn ~200 kết nối mới mỗi giây | |

Dòng cuối là hạn chế cần biết:

IAM authentication có trần số kết nối MỚI mỗi giây
    → ứng dụng mở đóng kết nối liên tục sẽ chạm trần
        ↓
    Dùng connection pool hoặc RDS Proxy

RDS Proxy giải quyết trọn vẹn:

aws rds create-db-proxy --db-proxy-name proxy-ung-dung   --engine-family MYSQL --role-arn <arn-role>   --auth '[{"SecretArn":"<arn-secret>","IAMAuth":"REQUIRED"}]'   --vpc-subnet-ids subnet-a subnet-c

RDS Proxy:
    ✓ gộp kết nối
    ✓ hỗ trợ IAM authentication
    ✓ lấy mật khẩu thật từ Secrets Manager
        ↓
    Ứng dụng dùng IAM, proxy lo phần còn lại

Ba lựa chọn lưu bí mật trên AWS: | Dịch vụ | Đặc điểm | |---|---| | Secrets Manager | có XOAY VÒNG tự động, tích hợp RDS | | Parameter Store (SecureString) | rẻ hơn, không xoay vòng sẵn | | — | cả hai đều mã hoá bằng KMS |

Secrets Manager với xoay vòng:

aws secretsmanager rotate-secret --secret-id db-ung-dung   --rotation-lambda-arn <arn-lambda>   --rotation-rules AutomaticallyAfterDays=30

Ba lưu ý về instance profile: | Lưu ý | Chi tiết | |---|---| | KHÔNG dùng access key trên EC2 | dùng instance profile | | Credential tự động xoay vòng | AWS lo | | Bắt buộc IMDSv2 | chống SSRF |

Bắt buộc IMDSv2:

aws ec2 modify-instance-metadata-options --instance-id i-0abc   --http-tokens required --http-put-response-hop-limit 1

Ba lớp bảo vệ database: | Lớp | Cơ chế | |---|---| | Danh tính | IAM authentication hoặc Secrets Manager | | Mạng | private subnet, security group | | Mã hoá | KMS at rest, TLS in transit |

Ba lưu ý khi triển khai IAM authentication: | Lưu ý | Chi tiết | |---|---| | Bật trên instance và tạo user trong database | hai bước riêng | | Vẫn nên dùng TLS | token đi qua mạng | | Giữ một tài khoản mật khẩu dự phòng | cho quản trị khẩn cấp |

Dòng cuối quan trọng:

IAM authentication phụ thuộc IAM và STS
    → sự cố ở đó = không kết nối được
        ↓
    Giữ một tài khoản quản trị dùng mật khẩu
      trong Secrets Manager làm đường thoát

Ba cách kiểm chứng: | Cách | Chi tiết | |---|---| | Thử kết nối bằng token | | | Kiểm tra CloudTrail thấy rds-db:connect | | | Xoá tệp cấu hình cũ và xác nhận ứng dụng vẫn chạy | |

Ba nguyên tắc quyền tối thiểu cho database: | Nguyên tắc | Chi tiết | |---|---| | Không dùng tài khoản master cho ứng dụng | | | Chỉ cấp quyền trên bảng cần dùng | | | Tách user đọc và user ghi | |

Ba lưu ý về audit: | Nguồn | Ghi gì | |---|---| | CloudTrail | ai sinh token, khi nào | | Database Activity Streams | mọi truy vấn | | RDS log | kết nối và lỗi |

Ba lỗi bảo mật hay gặp với credential: | Lỗi | Hậu quả | |---|---| | Mật khẩu trong mã nguồn | lộ khi commit lên Git | | Mật khẩu trong user data | đọc được từ metadata service | | Mật khẩu trong biến môi trường không mã hoá | lộ trong log |

Và một lời khuyên: hãy giữ lại một tài khoản quản trị dùng mật khẩu trong Secrets Manager khi chuyển sang IAM authentication. Đó là đường thoát duy nhất nếu có sự cố với IAM hoặc STS — và một database mà không ai đăng nhập được vào là tình huống tệ hơn nhiều so với việc còn một mật khẩu được bảo vệ tốt.

Câu 817 AWS Compute

A financial services company runs a trading application on a Kubernetes cluster hosted in its on-premises data center. Due to a recent surge in trading activity, the on-premises infrastructure can no longer support the increased load. The company plans to migrate the trading application to the AWS Cloud using an Amazon Elastic Kubernetes Service (Amazon EKS) cluster.

The company wants to minimize the operational overhead by avoiding management of the underlying compute infrastructure for the new AWS architecture.

Which solution will meet these requirements with the LEAST operational overhead?

  1. A

    Use managed node groups to provide the compute capacity for the EKS cluster. Deploy the application to the cluster using the managed nodes.
  2. B

    Use self-managed EC2 instances to provide the compute capacity for the EKS cluster. Deploy the application to the cluster using these instances.
  3. C

    Use Amazon EC2 Spot Instances with managed node groups to provide cost-effective compute capacity for the EKS cluster. Deploy the application using the Spot nodes.
  4. D

    Use AWS Fargate to provide the compute capacity for the EKS cluster. Create a Fargate profile and deploy the application using the profile.
Xem giải thích

Đáp án

D — Dùng AWS Fargate làm năng lực tính toán cho cụm EKS; tạo Fargate profile và triển khai ứng dụng qua profile đó.

Vì sao đúng

Đề nêu yêu cầu rõ: tránh quản lý hạ tầng tính toán bên dưới.

"minimize operational overhead by AVOIDING MANAGEMENT
 of the underlying COMPUTE INFRASTRUCTURE"
        ↓
    Fargate là lựa chọn DUY NHẤT không có node nào để quản lý

So sánh ba mức quản lý node của EKS: | Mức | Bạn phải làm gì | |---|---| | Self-managed node | AMI, vá lỗi, nâng cấp, co giãn — tất cả | | Managed node group | AWS lo vá lỗi, bạn vẫn chọn cỡ và số node | | Fargate | KHÔNG có gì — không thấy node nào |

Fargate cấp năng lực theo từng Pod:

Mỗi Pod chạy trên một môi trường cách ly riêng
    → AWS tự cấp CPU và bộ nhớ theo resource request
    → không có EC2 instance nào xuất hiện trong tài khoản
        ↓
    Không vá lỗi, không nâng cấp, không co giãn node

Tạo Fargate profile:

eksctl create fargateprofile --cluster cum-giao-dich   --name ho-so-giao-dich   --namespace giao-dich   --labels app=trading

Và Pod khớp với profile sẽ tự chạy trên Fargate:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ung-dung-giao-dich
  namespace: giao-dich
spec:
  template:
    metadata:
      labels:
        app: trading
    spec:
      containers:
        - name: ung-dung
          resources:
            requests:
              cpu: "1"
              memory: "2Gi"

resources.requests là bắt buộc với Fargate:

Fargate cấp tài nguyên THEO request của Pod
    → thiếu request → Fargate dùng mức tối thiểu (0,25 vCPU, 0,5 GB)
        ↓
    Ứng dụng có thể bị thiếu tài nguyên mà không rõ vì sao

Và cụm EKS giữ nguyên toàn bộ công cụ Kubernetes:

kubectl, Helm, manifest YAML — không đổi gì
    → ứng dụng đang chạy trên Kubernetes tại chỗ
    → chuyển sang EKS với Fargate gần như không sửa

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

  • **A. Dùng managed node group — đây là phương án gần nhất và giảm đáng kể công vận hành (AWS lo vá lỗi và nâng cấp AMI), nhưng bạn vẫn phải chọn loại instance, số node, và cấu hình co giãn. Đề nói rõ muốn tránh quản lý hạ tầng tính toán, và Fargate là mức duy nhất đạt điều đó.
  • **C. EC2 Spot với managed node group — thêm việc phải lo: xử lý gián đoạn, đảm bảo đa dạng loại instance. Và đề không nêu yêu cầu tối ưu chi phí.
  • **B. Self-managed EC2 instance — công vận hành cao nhất: tự quản AMI, vá lỗi, nâng cấp Kubernetes trên node.

Ghi nhớ

Ba mức tính toán của EKS — bảng phải thuộc: | Mức | Công vận hành | Kiểm soát | |---|---|---| | Self-managed node | cao nhất | cao nhất | | Managed node group | vừa | vừa | | Fargate | thấp nhất | thấp nhất |

Từ khoá nhận diện:

"avoid managing compute infrastructure", "least operational overhead" → Fargate "need GPU, DaemonSet, custom AMI" → node group | "cost optimization, interruption tolerant" → Spot với node group

⚠ Ba hạn chế của Fargate với EKS: | Hạn chế | Chi tiết | |---|---| | KHÔNG hỗ trợ DaemonSet | agent giám sát phải chạy sidecar | | KHÔNG hỗ trợ GPU | | | KHÔNG hỗ trợ volume kiểu hostPath hoặc EBS | chỉ EFS |

Ba hạn chế này quyết định Fargate có dùng được không:

Ứng dụng cần DaemonSet cho log agent
    → phải chuyển sang sidecar container
Ứng dụng cần GPU
    → Fargate KHÔNG dùng được
        ↓
    Kiểm tra trước khi cam kết

Ba khái niệm của Fargate profile: | Khái niệm | Việc | |---|---| | Namespace | Pod ở namespace nào | | Label selector | thêm điều kiện theo nhãn | | Subnet | CHỈ private subnet |

Dòng cuối là ràng buộc bắt buộc:

Fargate profile CHỈ dùng private subnet
    → Pod cần ra Internet phải có NAT Gateway
        ↓
    Hoặc VPC endpoint cho dịch vụ AWS

Ba lưu ý về tài nguyên của Fargate Pod: | Lưu ý | Chi tiết | |---|---| | CPU và bộ nhớ theo resources.requests | | | Fargate làm tròn lên tổ hợp gần nhất | | | Thêm ~256 MB cho thành phần Kubernetes | |

Bảng tổ hợp CPU và bộ nhớ: | vCPU | Bộ nhớ | |---|---| | 0,25 | 0,5, 1, 2 GB | | 1 | 2–8 GB | | 4 | 8–30 GB | | 16 | 32–120 GB |

Ba lưu ý về mạng của Fargate Pod: | Lưu ý | Chi tiết | |---|---| | Mỗi Pod có ENI riêng | và IP riêng trong VPC | | Security group gắn được | qua Fargate profile | | Tiêu tốn IP trong subnet | quy hoạch CIDR đủ rộng |

Ba cách cấp quyền AWS cho Pod: | Cách | Chi tiết | |---|---| | IRSA | hoạt động với Fargate | | EKS Pod Identity | kiểm tra hỗ trợ Fargate | | Instance profile | không có với Fargate |

Điểm cuối là lợi ích bảo mật:

Fargate KHÔNG có EC2 instance profile
    → Pod bắt buộc dùng IRSA
        ↓
    Không có credential cấp node nào để bị lấy cắp

Ba lưu ý về lưu trữ: | Lưu trữ | Fargate | |---|---| | EFS | ✅ qua EFS CSI Driver | | EBS | ❌ | | Ephemeral storage | ✅ 20 GB mặc định, tới 175 GB |

Ba lưu ý về khởi động: | Lưu ý | Chi tiết | |---|---| | Pod Fargate khởi động chậm hơn node có sẵn | vài chục giây | | Không có image cache giữa các Pod | mỗi Pod kéo image riêng | | Image nhỏ khởi động nhanh hơn | |

Dòng giữa đáng lưu ý với ứng dụng giao dịch:

Mỗi Pod kéo image từ ECR
    → image lớn làm chậm việc mở rộng
        ↓
    Tối ưu kích thước image nếu cần phản ứng nhanh

Ba lựa chọn nếu Fargate không phù hợp: | Lựa chọn | Khi nào | |---|---| | Managed node group | cần DaemonSet, GPU, hoặc EBS | | Karpenter với node group | co giãn node thông minh | | Kết hợp Fargate và node group | Pod nào hợp cái nào |

Karpenter đáng biết:

Tự chọn loại instance tối ưu cho Pod đang chờ
    → khởi động nhanh hơn Cluster Autoscaler
    → tự gộp Pod để giảm số node
        ↓
    Gần đạt mức tiện của Fargate mà vẫn dùng EC2

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Fargate tính theo vCPU-giây và GB-giây | | | Đắt hơn EC2 khi tải cao và ổn định | | | Rẻ hơn khi tải không đều | | | Fargate Spot | KHÔNG hỗ trợ với EKS (chỉ ECS) |

Dòng cuối là chi tiết cần nhớ.

Ba lưu ý khi di chuyển từ Kubernetes tại chỗ: | Lưu ý | Chi tiết | |---|---| | Manifest gần như giữ nguyên | | | Đổi StorageClass sang EFS hoặc EBS CSI | | | Đổi Ingress sang AWS Load Balancer Controller | |

Và một lời khuyên: hãy kiểm tra ứng dụng có dùng DaemonSet không trước khi chọn Fargate. Rất nhiều cụm Kubernetes chạy agent thu thập log và metric dưới dạng DaemonSet — và Fargate không hỗ trợ chúng, nên bạn sẽ phải chuyển sang mô hình sidecar, một thay đổi không lớn nhưng phải biết trước.

Câu 818 AWS Storage

A global manufacturing company uses AWS Outposts servers to manage IoT workloads in its factories across multiple continents. The company regularly updates factory IoT software, consisting of 50 files, from a central Amazon S3 bucket in the us-east-1 Region. Factories report significant delays when downloading and applying the updates, causing downtime. The company needs to minimize the latency for distributing software updates globally while reducing operational overhead.

Which solution will meet this requirement with the LEAST operational overhead?

  1. A

    Create Amazon S3 buckets in multiple Regions. Configure S3 Cross-Region Replication (CRR) between the buckets. Deploy updates from the nearest bucket to each factory location.
  2. B

    Create an Amazon S3 bucket in the us-east-1 Region. Configure Amazon S3 Transfer Acceleration for the bucket. Use the S3 Transfer Acceleration endpoint for faster downloads.
  3. C

    Create an Amazon S3 bucket in the us-east-1 Region. Deploy AWS Outposts servers at the factories as S3 endpoints. Configure the servers to cache the updates locally.
  4. D

    Create an Amazon S3 bucket in the us-east-1 Region. Set up an Amazon CloudFront distribution with the S3 bucket as the origin. Use signed URLs to download the software updates.
Xem giải thích

Đáp án

D — Tạo bucket S3 ở us-east-1, dựng CloudFront distribution với bucket đó làm origin, dùng signed URL để tải bản cập nhật.

Vì sao đúng

Đề nêu ba yêu cầu, và CloudFront đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Giảm độ trễ phân phối TOÀN CẦU | đệm ở edge location gần nhà máy | | Ít công vận hành nhất | một distribution, không quản lý gì thêm | | Kiểm soát ai tải được | signed URL |

Và bài toán này là trường hợp lý tưởng cho CloudFront:

50 tệp cập nhật GIỐNG NHAU
    → tải về NHIỀU nhà máy trên nhiều châu lục
        ↓
    Lần đầu ở mỗi khu vực: kéo từ us-east-1
    Những lần sau: phục vụ NGAY tại edge
        ↓
    Tỷ lệ trúng cache rất cao

Đây là khác biệt so với dữ liệu riêng của từng nơi:

Nội dung GIỐNG NHAU cho mọi người → đệm cực hiệu quả
Nội dung riêng từng người         → đệm gần như vô dụng
        ↓
    Bản cập nhật phần mềm thuộc loại đầu

Triển khai:

aws cloudfront create-distribution   --origin-domain-name kho-cap-nhat.s3.us-east-1.amazonaws.com   --default-root-object index.html

Và signed URL kiểm soát truy cập:

from botocore.signers import CloudFrontSigner
import rsa, datetime

signer = CloudFrontSigner('K2ABCDEFG', lambda m: rsa.sign(m, khoa_rieng, 'SHA-1'))
url = signer.generate_presigned_url(
    'https://d123.cloudfront.net/ban-cap-nhat/v2.4.1.tar.gz',
    date_less_than=datetime.datetime.now() + datetime.timedelta(hours=6))

Và ba lợi ích phụ: | Lợi ích | Chi tiết | |---|---| | Giảm tải bucket gốc | request không tới S3 | | Egress RẺ HƠN so với S3 trực tiếp | | | Chỉ một nơi để cập nhật tệp | |

Dòng cuối là điểm "least operational overhead":

Tải phiên bản mới lên MỘT bucket
    → CloudFront tự phân phối toàn cầu
        ↓
    Không phải đồng bộ nhiều bucket

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

  • **A. Tạo bucket ở nhiều Region với Cross-Region Replication, mỗi nhà máy tải từ bucket gần nhất — đây là phương án gần nhất và thật sự đưa dữ liệu tới gần hơn, nhưng nó nhiều công vận hành hơn hẳn: phải tạo và quản lý bucket ở mỗi Region, cấu hình replication, và mỗi nhà máy phải biết bucket nào gần mình. CloudFront làm việc đó tự động.
  • **B. Bật S3 Transfer Acceleration — tối ưu chủ yếu cho việc TẢI LÊN: nó giúp đưa dữ liệu vào S3 từ xa, còn với việc tải xuống lặp lại cùng tệp thì đệm của CloudFront hiệu quả hơn nhiều.
  • **C. Triển khai Outposts server làm S3 endpoint và đệm cục bộ — hiểu sai vai trò của Outposts: nó là hạ tầng AWS đặt trong trung tâm dữ liệu của bạn, rất đắt, và không phải cơ chế đệm nội dung.

Ghi nhớ

Ba cách tăng tốc phân phối nội dung — bảng phải thuộc: | Cách | Phù hợp | |---|---| | CloudFront | ĐỌC lặp lại cùng nội dung toàn cầu | | S3 Transfer Acceleration | GHI từ xa vào S3 | | Cross-Region Replication | cần bản sao thật ở Region khác |

Từ khoá nhận diện:

"distribute same files globally", "reduce download latency" → CloudFront "upload from remote offices" → Transfer Acceleration "data residency", "disaster recovery" → CRR

Ba lợi ích của CloudFront: | Lợi ích | Chi tiết | |---|---| | Đệm ở hơn 600 edge location | | | Egress rẻ hơn S3 trực tiếp | | | Bảo vệ bằng OAC, WAF, signed URL | |

Ba cơ chế bảo vệ nội dung: | Cơ chế | Kiểm soát | |---|---| | Signed URL | một tệp, có hạn ← câu này | | Signed cookie | nhiều tệp | | Geo restriction | theo quốc gia |

Với 50 tệp cập nhật, signed cookie cũng dùng được — nhưng signed URL đơn giản hơn cho việc tải từng gói.

Ba lưu ý về cache của CloudFront: | Lưu ý | Chi tiết | |---|---| | Dùng cache policy CachingOptimized | cho tệp tĩnh | | Đặt Cache-Control từ S3 | | | Đưa phiên bản vào tên tệp | v2.4.1.tar.gz |

Cách cuối rất phù hợp với bản cập nhật:

Tên tệp có phiên bản
    → mỗi phiên bản là một URL mới
    → KHÔNG cần vô hiệu hoá cache
        ↓
    Và nhà máy biết chính xác đang tải phiên bản nào

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 | sau đó tính phí | | Mất vài phút để lan ra mọi edge | | | Dùng phiên bản trong tên tệp thay thế | |

Ba lưu ý về Origin Access Control: | Lưu ý | Chi tiết | |---|---| | Thay thế OAI (legacy) | hỗ trợ SSE-KMS | | Bucket giữ Block Public Access | | | Bucket policy cho service principal CloudFront | |

Ba lưu ý về Outposts (để phân biệt): | Lưu ý | Chi tiết | |---|---| | Là rack phần cứng AWS trong trung tâm dữ liệu của bạn | | | Chi phí rất cao | | | Dùng khi cần độ trễ cực thấp hoặc dữ liệu phải ở tại chỗ | |

Đề nói công ty ĐÃ dùng Outposts — nhưng đó là để chạy tải IoT, không phải để phân phối nội dung.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitRate | hiệu quả đệm — nên rất cao ở đây | | OriginLatency | S3 phản hồi chậm | | BytesDownloaded | lượng tải |

Ba cách tăng tỷ lệ trúng cache: | Cách | Chi tiết | |---|---| | Cache key tối giản | không đưa header thừa vào | | TTL dài cho tệp có phiên bản | | | Origin Shield | thêm lớp đệm trước origin |

Origin Shield hữu ích khi phân phối toàn cầu:

Nhiều edge location cùng trượt cache
    → tất cả gọi origin cùng lúc
        ↓
    Origin Shield gộp thành MỘT request
    → giảm tải S3 đáng kể

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | CloudFront egress rẻ hơn S3 egress | | | Phí request nhỏ | | | Price class giới hạn edge location để tiết kiệm | |

Price class đáng cân nhắc:

--price-class PriceClass_All        # mọi edge, đắt nhất
--price-class PriceClass_200        # bỏ Nam Mỹ và một số nơi
--price-class PriceClass_100        # chỉ Bắc Mỹ và châu Âu

Nhà máy ở nhiều châu lục
    → cần PriceClass_All để phủ hết

Ba lưu ý về bảo mật bản cập nhật phần mềm: | Lưu ý | Chi tiết | |---|---| | Ký số gói cập nhật | thiết bị xác minh trước khi cài | | Signed URL có hạn ngắn | | | Ghi log ai tải phiên bản nào | |

Dòng đầu quan trọng hơn cả signed URL:

Signed URL kiểm soát AI TẢI ĐƯỢC
    → nhưng không đảm bảo gói KHÔNG BỊ SỬA
        ↓
    Ký số gói là biện pháp bảo vệ thật sự

Ba lựa chọn khác cho phân phối phần mềm IoT: | Lựa chọn | Đặc điểm | |---|---| | CloudFront | ← câu này | | AWS IoT Device Management job | quản lý triển khai theo nhóm thiết bị | | S3 Multi-Region Access Point | tự định tuyến |

IoT Device Management đáng biết:

Tạo job triển khai cho nhóm thiết bị
    → theo dõi tiến độ từng thiết bị
    → triển khai dần, dừng khi có lỗi
        ↓
    Kiểm soát tốt hơn nhiều so với chỉ phát tệp

Và một lời khuyên: hãy đưa số phiên bản vào tên tệp thay vì ghi đè cùng một đường dẫn. Với 50 tệp phân phối tới hàng chục nhà máy, việc vô hiệu hoá cache sau mỗi lần cập nhật vừa tốn phí vừa mất vài phút lan truyền — còn tên tệp có phiên bản thì mọi edge phục vụ đúng bản mới ngay lập tức.

Câu 819 AWS Database

A company uses an Amazon RDS for MySQL instance for its operational database. To handle the increased read-only traffic during a recent peak period, the company added a read replica. During the peak period, the CPU usage on the read replica reached 60%, and the primary instance also had 60% CPU usage. After the peak period ended, the read replica's CPU usage decreased to 25%, while the primary instance consistently remains at 60%. The company wants to optimize costs while ensuring enough capacity for future growth.

Which solution will meet these requirements?

  1. A

    Resize the read replica to a smaller instance size and keep the primary instance unchanged.
  2. B

    Delete the read replica and upgrade the primary instance to a larger instance size.
  3. C

    Upgrade the read replica to a larger instance size and downgrade the primary instance to a smaller instance size.
  4. D

    Delete the read replica and keep the primary instance unchanged.
Xem giải thích

Đáp án

A — Thu nhỏ read replica xuống loại instance nhỏ hơn, giữ nguyên primary.

Vì sao đúng

Đề cho bốn con số, và chúng kể một câu chuyện rõ ràng: | Thời điểm | Primary | Replica | |---|---|---| | Trong đỉnh tải | 60% | 60% | | Sau đỉnh tải | 60% — KHÔNG đổi | 25% — giảm mạnh |

Phân tích:

Primary giữ 60% LIÊN TỤC
    → tải ghi và tải đọc nền là ỔN ĐỊNH
    → 60% là mức lành mạnh, còn dư cho tăng trưởng
        ↓
    KHÔNG nên đụng tới primary

Replica tụt từ 60% xuống 25%
    → nó chỉ bận trong đỉnh tải
    → phần lớn thời gian đang CẤP THỪA
        ↓
    Thu nhỏ replica là đúng

Và vì sao không xoá hẳn replica:

Trong đỉnh tải, replica chạy 60%
    → nó ĐANG GÁNH tải đọc thật
        ↓
    Xoá replica → toàn bộ tải đó dồn về primary
    → primary từ 60% lên có thể trên 90%
        ↓
    Mất khả năng chịu đỉnh và không còn dư cho tăng trưởng

Thu nhỏ replica:

aws rds modify-db-instance --db-instance-identifier replica-doc   --db-instance-class db.r6g.large --apply-immediately

Và nên bật auto scaling cho replica:

aws application-autoscaling register-scalable-target   --service-namespace rds   --scalable-dimension rds:cluster:ReadReplicaCount   --resource-id cluster:cum-van-hanh   --min-capacity 1 --max-capacity 4

Replica nhỏ cho tải nền
    + tự thêm replica khi có đỉnh
        ↓
    Vừa tiết kiệm vừa chịu được đỉnh

(Auto scaling replica count áp cho Aurora; với RDS thường thì thêm replica thủ công hoặc theo lịch.)

Ba yêu cầu của đề đều được thoả: | Yêu cầu | Kết quả | |---|---| | Tối ưu chi phí | replica nhỏ hơn | | Đủ năng lực cho tăng trưởng | primary giữ nguyên ở 60% | | Vẫn chịu được đỉnh | replica còn đó |

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

  • **D. Xoá replica và giữ nguyên primary — đây là phương án gần nhất về mặt tiết kiệm chi phí, nhưng nó dồn toàn bộ tải đọc về primary: trong đỉnh tải, primary đang ở 60% sẽ phải gánh thêm phần việc mà replica đang làm ở 60%, đẩy nó tới mức nguy hiểm.
  • **B. Xoá replica và NÂNG CẤP primary lên loại lớn hơn — đắt hơn và kém linh hoạt: một instance lớn thường tốn hơn một instance vừa cộng một replica nhỏ, và mất luôn khả năng tách tải đọc.
  • **C. Nâng replica lên lớn hơn, hạ primary xuống nhỏ hơn — ngược hoàn toàn với dữ liệu: primary đang ở 60% liên tục, hạ nó xuống sẽ đẩy lên mức nguy hiểm; replica chỉ ở 25% phần lớn thời gian, nâng lên là lãng phí.

Ghi nhớ

Cách đọc metric CPU để quyết định kích thước: | Mức CPU | Ý nghĩa | |---|---| | Dưới 30% liên tục | cấp thừa — thu nhỏ được | | 40–70% | lành mạnh, còn dư cho đỉnh | | Trên 80% liên tục | thiếu — cần nâng cấp |

Và phải xem cả TRUNG BÌNH lẫn ĐỈNH:

Chỉ nhìn trung bình
    → bỏ lỡ việc instance chạm trần trong đỉnh
Chỉ nhìn đỉnh
    → cấp thừa cho phần lớn thời gian
        ↓
    Xem phân bố (P50, P95, P99) mới đủ

Ba nguyên tắc tối ưu kích thước database: | Nguyên tắc | Chi tiết | |---|---| | Đo ít nhất 2 tuần | bắt được chu kỳ | | Thu nhỏ TỪNG BƯỚC | một bậc mỗi lần | | Theo dõi sau mỗi thay đổi | |

Ba metric cần xem ngoài CPU: | Metric | Ý nghĩa | |---|---| | FreeableMemory | thiếu bộ nhớ gây swap, chậm hẳn | | DatabaseConnections | gần trần thì ứng dụng bị từ chối | | ReadIOPS, WriteIOPS | có thể nút thắt ở lưu trữ |

Bộ nhớ thường quan trọng hơn CPU với database:

Buffer pool nhỏ hơn tập dữ liệu nóng
    → đọc từ đĩa thay vì RAM
    → CPU có thể vẫn thấp nhưng độ trễ cao
        ↓
    Thu nhỏ instance = giảm RAM
    → phải kiểm tra FreeableMemory trước

Ba công cụ hỗ trợ quyết định: | Công cụ | Việc | |---|---| | AWS Compute Optimizer | khuyến nghị cho RDS (tính năng mới) | | Performance Insights | truy vấn nào tốn tài nguyên | | CloudWatch | metric cơ bản |

Performance Insights nên bật:

aws rds modify-db-instance --db-instance-identifier replica-doc   --enable-performance-insights   --performance-insights-retention-period 7

7 ngày lưu trữ MIỄN PHÍ
    → thấy truy vấn nào chiếm tài nguyên
        ↓
    Đôi khi tối ưu một truy vấn còn hiệu quả hơn
      đổi cỡ instance

Ba lưu ý về read replica: | Lưu ý | Chi tiết | |---|---| | Cỡ instance chọn riêng được | không cần bằng primary | | Dung lượng lưu trữ phải ≥ primary | | | Replica nhỏ dễ TỤT LẠI trong sao chép | theo dõi ReplicaLag |

Dòng cuối là rủi ro của việc thu nhỏ:

Replica phải áp dụng MỌI thay đổi của primary
    → replica quá nhỏ không theo kịp
    → ReplicaLag tăng dần
        ↓
    Thu nhỏ một bậc rồi theo dõi, đừng nhảy nhiều bậc

Ba cách xử lý tải đỉnh: | Cách | Chi tiết | |---|---| | Thêm replica khi cần | thủ công hoặc auto scaling | | Đệm bằng ElastiCache | giảm SỐ truy vấn | | Aurora Serverless v2 | tự co giãn |

ElastiCache thường hiệu quả hơn thêm replica:

Read replica: chia cùng lượng truy vấn cho nhiều máy
ElastiCache:  LOẠI BỎ phần lớn truy vấn
        ↓
    Với truy vấn lặp lại, đệm rẻ hơn nhiều

Ba lưu ý về đổi cỡ instance RDS: | Lưu ý | Chi tiết | |---|---| | CÓ thời gian ngừng | vài phút | | Multi-AZ giảm ngừng | đổi standby trước rồi chuyển đổi | | Đặt trong maintenance window | hoặc --apply-immediately |

Ba cách tiết kiệm thêm cho RDS: | Cách | Tiết kiệm | |---|---| | Reserved Instance | tới 69% | | Graviton (db.r6g, db.r7g) | ~20% | | Thu nhỏ đúng mức TRƯỚC khi mua RI | |

Dòng cuối là thứ tự quan trọng:

Mua Reserved Instance cho instance cấp thừa
    → khoá khoản lãng phí 1–3 năm
        ↓
    Thu nhỏ trước, cam kết sau

Ba việc nên làm sau khi thu nhỏ: | Việc | Chi tiết | |---|---| | Theo dõi CPU và bộ nhớ một tuần | | | Kiểm tra ReplicaLag không tăng | | | Đo độ trễ truy vấn từ ứng dụng | |

Và một lời khuyên: hãy kiểm tra FreeableMemory trước khi thu nhỏ replica, không chỉ CPU. Instance nhỏ hơn có ít RAM hơn, và nếu buffer pool không còn chứa đủ dữ liệu nóng thì độ trễ truy vấn sẽ tăng vọt trong khi CPU vẫn trông hoàn toàn bình thường — đó là kiểu suy giảm hiệu năng khó chẩn đoán nhất.

Câu 820 AWS Networking & Content Delivery

A company operates a multi-tier application with its backend services deployed on Amazon EC2 instances in a VPC. The backend services must communicate securely with APIs of a third-party SaaS provider that is also hosted on AWS. The company wants to ensure that this communication occurs privately and minimizes exposure to the public internet.

Which solution will meet these requirements?

  1. A

    Use an AWS VPN connection to establish a secure tunnel between the VPC and the third-party SaaS provider's infrastructure.
  2. B

    Configure AWS PrivateLink to create a private connection between the VPC and the third-party SaaS provider's APIs.
  3. C

    Deploy a NAT gateway in the VPC to enable secure outbound communication with the third-party SaaS provider.
  4. D

    Set up an AWS Direct Connect connection between the VPC and the third-party SaaS provider to establish private communication.
Xem giải thích

Đáp án

B — Cấu hình AWS PrivateLink tạo kết nối riêng tư giữa VPC và API của nhà cung cấp SaaS.

Vì sao đúng

Đề nêu ba yếu tố, và cả ba dẫn tới PrivateLink: | Yếu tố | Cơ chế | |---|---| | SaaS cũng chạy TRÊN AWS | PrivateLink chỉ hoạt động giữa các VPC trong AWS | | Giao tiếp RIÊNG TƯ | lưu lượng đi hoàn toàn trong mạng AWS | | Giảm phơi ra Internet công cộng | không cần IP công cộng, không cần NAT |

Cơ chế:

Nhà cung cấp SaaS:
    NLB trong VPC của họ → VPC Endpoint Service

Bạn:
    Interface endpoint trong VPC của bạn
        → ENI có IP RIÊNG trong subnet của bạn
        → ứng dụng gọi tới IP đó như dịch vụ nội bộ

Tạo endpoint:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc   --vpc-endpoint-type Interface   --service-name com.amazonaws.vpce.ap-northeast-1.vpce-svc-0abc123   --subnet-ids subnet-a subnet-c   --security-group-ids sg-privatelink   --private-dns-enabled

Ba lợi ích riêng của PrivateLink: | Lợi ích | Chi tiết | |---|---| | MỘT CHIỀU | nhà cung cấp KHÔNG khởi tạo kết nối ngược lại được | | KHÔNG cần CIDR không chồng lấn | khác VPC peering | | Chỉ expose MỘT dịch vụ | không mở cả mạng |

Và --private-dns-enabled khiến ứng dụng không phải sửa gì:

Không có private DNS:
    → phải gọi vpce-0abc-xyz.ap-northeast-1.vpce.amazonaws.com

Có private DNS:
    → gọi api.nha-cung-cap.com như bình thường
    → DNS trong VPC tự phân giải về IP của endpoint

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

  • **A. Dùng AWS VPN tạo đường hầm tới hạ tầng của nhà cung cấp SaaS — đây là phương án gần nhất vì cũng cho kết nối mã hoá, nhưng nó là công cụ sai cho tình huống này: Site-to-Site VPN nối on-premises với AWS. Cả hai bên ở đây đều đã trong AWS, và VPN nối cả mạng chứ không expose một dịch vụ.
  • **C. Triển khai NAT Gateway để giao tiếp ra ngoài — lưu lượng VẪN đi qua Internet công cộng: NAT chỉ dịch địa chỉ, đúng điều đề muốn tránh.
  • **D. Dựng Direct Connect giữa VPC và nhà cung cấp SaaS — không phải cách hoạt động: Direct Connect nối trung tâm dữ liệu của bạn với AWS, không nối hai VPC trong AWS.

Ghi nhớ

Ba cách kết nối VPC — bảng phải thuộc: | | VPC Peering | Transit Gateway | PrivateLink | |---|---|---|---| | Phạm vi | nối cả MẠNG | nối cả mạng | expose MỘT dịch vụ | | Chiều | hai chiều | hai chiều | MỘT chiều | | CIDR chồng lấn | ❌ | ❌ | ✅ được | | Bắc cầu | ❌ | ✅ | — |

Từ khoá nhận diện:

"SaaS provider on AWS", "one-way", "private API access", "overlapping CIDR" → PrivateLink "connect many VPCs and on-premises" → Transit Gateway "on-premises to AWS" → VPN hoặc Direct Connect

Hai loại VPC endpoint: | | Gateway endpoint | Interface endpoint (PrivateLink) | |---|---|---| | Dịch vụ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS + bên thứ ba | | Cơ chế | route trong route table | ENI có IP riêng | | Chi phí | MIỄN PHÍ | ~0,01 USD/giờ mỗi AZ | | Từ on-premises | ❌ | ✅ | | Security group | ❌ | ✅ |

Ba thành phần của PrivateLink: | Thành phần | Bên nào | |---|---| | Network Load Balancer | nhà cung cấp | | VPC Endpoint Service | nhà cung cấp | | Interface endpoint | người tiêu dùng |

Phía nhà cung cấp:

aws ec2 create-vpc-endpoint-service-configuration   --network-load-balancer-arns <arn-nlb> --acceptance-required

aws ec2 modify-vpc-endpoint-service-permissions   --service-id vpce-svc-0abc   --add-allowed-principals arn:aws:iam::123456789012:root

Ba lưu ý về private DNS: | Lưu ý | Chi tiết | |---|---| | Cần bật enableDnsHostnames và enableDnsSupport | trong VPC | | Nhà cung cấp phải xác minh sở hữu tên miền | | | Ứng dụng không phải sửa mã | |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Endpoint | ~0,01 USD/giờ mỗi AZ | | Xử lý dữ liệu | ~0,01 USD/GB | | — | 2 AZ ≈ 15 USD/tháng cộng phí dữ liệu |

So với NAT Gateway:

Gọi SaaS qua NAT Gateway: ~32 USD/tháng + 0,045 USD/GB
PrivateLink:              ~15 USD/tháng + 0,01 USD/GB
        ↓
    PrivateLink vừa RẺ HƠN vừa AN TOÀN HƠN

Ba giới hạn cần biết: | Giới hạn | Chi tiết | |---|---| | Chỉ hỗ trợ TCP | không UDP | | Cần NLB phía nhà cung cấp | không dùng ALB trực tiếp | | Endpoint theo Region | không xuyên Region trực tiếp |

Ba trường hợp dùng PrivateLink: | Trường hợp | Chi tiết | |---|---| | Truy cập dịch vụ AWS riêng tư | rất phổ biến | | Truy cập SaaS trong AWS | ← câu này | | Expose dịch vụ nội bộ cho tài khoản khác | |

Ba biện pháp bảo mật: | Biện pháp | Chi tiết | |---|---| | Security group cho endpoint | giới hạn ai gọi được | | Endpoint policy | với dịch vụ AWS | | VPC Flow Logs | audit lưu lượng |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | BytesProcessed | lượng dữ liệu và chi phí | | ActiveConnections | | | PacketsDropped | vấn đề kết nối |

Và một lời khuyên: hãy hỏi nhà cung cấp SaaS xem họ đã có endpoint service chưa trước khi thiết kế bất cứ giải pháp nào khác. Nhiều nhà cung cấp lớn trên AWS đã dựng sẵn PrivateLink, và khi đó việc tích hợp chỉ còn là tạo một endpoint trong VPC của bạn — nhanh và an toàn hơn hẳn mọi phương án tự dựng.