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

Tìm thấy 1221 câu.

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

An electric utility company deploys smart meters for its customers to easily track their electricity usage. Each smart meter sends data every five minutes to an Amazon API Gateway which is then processed by several AWS Lambda functions before storing to an Amazon DynamoDB table. The Lambda functions take about 5 to 10 seconds to process the data based on the initial deployment testing. As the company’s customer base grew, the solutions architect noticed that the Lambda functions are now taking 60 to 90 seconds to complete the processing. New metrics are also collected from the smart meters which further increased the processing time. Errors began showing when running the Lambda function such as TooManyRequestsException and ProvisionedThroughputExceededException error when performing PUT operation on the DynamoDB table.

Which combination of the following actions will resolve these issues? (Select TWO.)

  1. A

    The new metrics being collected requires more processing power from the Lambda functions. Adjust the memory allocation for the Lambda function to accommodate the surge.
  2. B

    Since the Lambda functions are being overwhelmed with too many requests, increase the payload size from the meters but send the data less frequently to avoid reaching the concurrency limit.
  3. C

    Set up an Amazon SQS FIFO queue to handle the burst of the data stream from the smart metrics. Trigger the Lambda function to run whenever a message is received on the queue.
  4. D

    Process the data in batches to avoid reaching the write limits to the DynamoDB table. Group the requests from API Gateway by streaming the data into an Amazon Kinesis data stream.
  5. E

    As more customers are sending data, adjust the Write Capacity Unit (WCU) of the DynamoDB table to be able to accommodate all the write requests being processed by the Lambda functions.
Xem giải thích

Đáp án

**D và E — Xử lý theo lô để không chạm giới hạn ghi của DynamoDB, gom các yêu cầu từ API Gateway bằng cách đưa vào Kinesis Data Stream; và tăng Write Capacity Unit (WCU) của bảng DynamoDB để nhận đủ lượng ghi.

Vì sao đúng

Đề nêu hai lỗi khác nhau, và mỗi đáp án chữa một lỗi: | Lỗi | Nghĩa | Cách chữa | |---|---|---| | TooManyRequestsException | Lambda chạm giới hạn đồng thời | gom lô qua Kinesis | | ProvisionedThroughputExceededException | DynamoDB hết WCU | tăng WCU |

⚠ Đây là chỗ nhiều người chỉ chữa một nửa:

Chỉ tăng WCU
    → DynamoDB nhận được
    → nhưng Lambda vẫn bị chặn
        ↓
    Chỉ gom lô
    → Lambda đỡ hơn
    → nhưng lượng ghi tổng không đổi
    → DynamoDB vẫn hết WCU
        ↓
    Phải làm CẢ HAI

⚠ Vì sao Kinesis giải quyết được vấn đề đồng thời của Lambda:

Không có Kinesis: mỗi yêu cầu API
  = một lượt Lambda
    → hàng nghìn lượt đồng thời
        ↓
    Có Kinesis: Lambda nhận một LÔ
      hàng trăm bản ghi mỗi lượt
    → số lượt đồng thời giảm hàng trăm lần
        ↓
    Và số lượt bị chặn theo số SHARD,
      không theo số yêu cầu

Cấu hình event source:

aws lambda create-event-source-mapping \
  --function-name xu-ly-cong-to \
  --event-source-arn <arn-luong-kinesis> \
  --batch-size 500 \
  --maximum-batching-window-in-seconds 10 \
  --parallelization-factor 4

⚠ Ba tham số này quyết định hành vi gom lô: | Tham số | Tác dụng | |---|---| | batch-size | tối đa bao nhiêu bản ghi mỗi lượt | | maximum-batching-window | chờ tối đa bao lâu để gom đủ lô | | parallelization-factor | bao nhiêu lượt song song mỗi shard |

Cửa sổ gom 10 giây
    → lưu lượng thấp cũng không chờ mãi
        ↓
    Đánh đổi: thêm tối đa 10 giây độ trễ
    → chấp nhận được với số đo công tơ

Ghi theo lô vào DynamoDB:

import boto3
dynamodb = boto3.resource('dynamodb')
bang = dynamodb.Table('SoDoCongTo')

def handler(su_kien, ngu_canh):
    with bang.batch_writer() as bo_ghi:
        for ban_ghi in su_kien['Records']:
            d = giai_ma(ban_ghi['kinesis']['data'])
            bo_ghi.put_item(Item=d)

⚠ batch_writer tự gom 25 mục mỗi lời gọi và tự thử lại:

`BatchWriteItem` nhận tối đa 25 mục
    → SDK tự chia và tự xử lý
      `UnprocessedItems`
        ↓
    Giảm số lời gọi API rất nhiều
    → nhưng KHÔNG giảm WCU tiêu thụ
    → WCU tính theo số mục và kích thước

Tăng WCU:

aws dynamodb update-table --table-name SoDoCongTo \
  --provisioned-throughput ReadCapacityUnits=100,WriteCapacityUnits=2000

⚠ Nhưng on-demand là lựa chọn tốt hơn cho tải đang tăng:

aws dynamodb update-table --table-name SoDoCongTo \
  --billing-mode PAY_PER_REQUEST

Đề nói khách hàng tăng liên tục
    → provisioned phải liên tục chỉnh tay
        ↓
    On-demand tự co giãn
    → đắt hơn mỗi đơn vị nhưng
      không bao giờ bị chặn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hết cả hai lỗi cùng lúc | | | Kinesis làm bộ đệm cho đỉnh tải | | | Kinesis giữ dữ liệu, phát lại được khi lỗi | |

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

  • **C. Dùng SQS FIFO để nhận luồng dữ liệu, kích hoạt Lambda khi có thông điệp — đây là phương án gần nhất và hàng đợi cũng là bộ đệm hợp lý, nhưng FIFO có trần 300 thông điệp/giây mỗi nhóm (3.000 khi gom lô), thấp hơn Kinesis nhiều; và đề không cần thứ tự nghiêm ngặt.
  • **A. Tăng bộ nhớ cho Lambda — bộ nhớ tăng thì CPU tăng và hàm chạy nhanh hơn, nhưng cả hai lỗi trong đề đều là giới hạn tần suất, không phải thiếu tài nguyên tính toán.
  • **B. Tăng kích thước payload và giảm tần suất gửi từ công tơ — thay đổi phía thiết bị là việc lớn với hàng triệu công tơ đã lắp; và giảm tần suất làm mất độ chi tiết của dữ liệu.

Ghi nhớ

⚠ Hai ngoại lệ trong đề và ý nghĩa — bảng phải thuộc: | Ngoại lệ | Dịch vụ | Nguyên nhân | |---|---|---| | TooManyRequestsException | Lambda | chạm đồng thời hoặc tần suất | | ProvisionedThroughputExceededException | DynamoDB | vượt WCU/RCU đã cấp | | ThrottlingException | nhiều dịch vụ | vượt tần suất API chung |

Từ khoá nhận diện:

"too many Lambda invocations" → gom lô qua Kinesis hoặc SQS "ProvisionedThroughputExceeded" → tăng WCU hoặc chuyển on-demand "hot partition" → thiết kế lại khoá phân vùng "need strict ordering" → Kinesis theo khoá phân vùng hoặc SQS FIFO

⚠ Điểm nóng phân vùng là nguyên nhân hay bị bỏ sót:

Bảng có tổng WCU rất lớn
    → nhưng vẫn báo ProvisionedThroughputExceeded
        ↓
    WCU chia đều cho các phân vùng
    → khoá lệch làm một phân vùng
      nhận hết tải
        ↓
    Kiểm bằng CloudWatch Contributor Insights

aws dynamodb update-contributor-insights \
  --table-name SoDoCongTo \
  --contributor-insights-action ENABLE

⚠ Thiết kế khoá cho dữ liệu công tơ:

Khoá phân vùng = maCongTo
Khoá sắp xếp   = thoiGian
        ↓
    Tải phân bố đều theo hàng triệu công tơ
    → truy vấn lịch sử một công tơ rất nhanh

Ba lưu ý về WCU: | Lưu ý | Chi tiết | |---|---| | 1 WCU = 1 KB mỗi giây | | | Mục 3 KB tốn 3 WCU | | | Ghi giao dịch tốn gấp đôi | |

Ba lưu ý về on-demand: | Lưu ý | Chi tiết | |---|---| | Không phải chỉnh công suất | | | Đắt hơn mỗi đơn vị nhưng không bị chặn | | | Đổi qua lại được, giới hạn 24 giờ một lần | |

Ba lưu ý về Kinesis: | Lưu ý | Chi tiết | |---|---| | Mỗi shard: 1 MB/s ghi, 1.000 bản ghi/giây | | | On-demand tự co giãn tới 200 MB/s | | | Giữ dữ liệu 24 giờ tới 365 ngày | |

⚠ Lambda đọc Kinesis có một bẫy nghiêm trọng:

Một bản ghi hỏng làm Lambda ném lỗi
    → Lambda thử lại cả lô mãi
        ↓
    Shard đó DỪNG HOÀN TOÀN
    → phải đặt các tham số sau

aws lambda update-event-source-mapping --uuid <id> \
  --maximum-retry-attempts 3 \
  --bisect-batch-on-function-error \
  --destination-config '{"OnFailure":{"Destination":"<arn-sqs>"}}'

Ba lưu ý về giám sát: | Chỉ số | Cảnh báo khi | |---|---| | IteratorAge | tăng đều — consumer không theo kịp | | Throttles của Lambda | lớn hơn 0 | | WriteThrottleEvents của DynamoDB | lớn hơn 0 |

Ba lưu ý về API Gateway: | Lưu ý | Chi tiết | |---|---| | Tích hợp thẳng với Kinesis, không cần Lambda ở giữa | | | Đặt throttling ở mức stage | | | Usage plan giới hạn theo client | |

⚠ Tích hợp thẳng bỏ được một tầng Lambda:

API Gateway → Lambda → Kinesis
    → Lambda này chỉ chuyển tiếp
        ↓
    API Gateway → Kinesis (AWS integration)
    → ít một tầng, ít một chỗ bị chặn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy tải bằng lượng công tơ dự kiến | | | Theo dõi Throttles và WriteThrottleEvents | | | Bật Contributor Insights xem có phân vùng nóng | |

Và một lời khuyên: hãy kiểm tra phân bố khoá phân vùng trước khi tăng WCU. Tăng công suất cho một bảng có phân vùng nóng chỉ là trả thêm tiền cho phần công suất mà phân vùng bận rộn kia không bao giờ chạm tới.

Câu 122 Domain - Design for New Solutions

A company implements best practices and mandates that all of the cloud-related deployments should not be done manually but through the use of CloudFormation. All of the CloudFormation templates should be treated as code and hence, all of them are committed in a private GIT repository. A senior solutions architect has recently left the team. One of the tasks of the junior solutions architect is to handle a distributed system in AWS, in which the architecture is declared in a CloudFormation template. The distributed system needs to be migrated to another VPC and the junior solutions architect tried to read the template to understand the AWS resources that the template will generate. While analyzing the CloudFormation template, he stumbled upon the code below.

What does this code snippet do in CloudFormation?


"SNSTopic" : {
"Type" : "AWS::SNS::Topic",
"Properties" : {
"Subscription" : [{
"Protocol" : "sqs",
"Endpoint" : { "Fn::GetAtt" : [ "TutorialsDojoQueue", "Arn" ] }
}]
}

  1. A Creates an SNS topic which allows SQS subscription endpoints.
  2. B Creates an SNS topic and then invokes the call to create an SQS queue with a logical resource name of TutorialsDojoQueue.
  3. C Creates an SNS topic and then adds a subscription using the ARN attribute name for the SQS resource, which is created under the logical name TutorialsDojoQueue.
  4. D Creates an SNS topic which allows SQS subscription endpoints to be added as a parameter on the template.
Xem giải thích

Đáp án

**C — Đoạn mã tạo một SNS topic rồi thêm một subscription, dùng thuộc tính ARN của tài nguyên SQS được khai với tên logic TutorialsDojoQueue.

Vì sao đúng

Đọc đoạn mã theo từng phần:

"SNSTopic": {
  "Type": "AWS::SNS::Topic",        ← tạo topic
  "Properties": {
    "Subscription": [{              ← kèm subscription
      "Protocol": "sqs",            ← giao thức SQS
      "Endpoint": {
        "Fn::GetAtt": [             ← LẤY thuộc tính
          "TutorialsDojoQueue",     ← của tài nguyên này
          "Arn"]}}]}}               ← thuộc tính Arn

⚠ Fn::GetAtt LẤY thuộc tính của tài nguyên đã khai ở nơi khác — nó không TẠO ra gì:

`Fn::GetAtt` cần tài nguyên
  `TutorialsDojoQueue` TỒN TẠI
  trong cùng template
        ↓
    Nó chỉ đọc thuộc tính `Arn` của cái đó
    → không tự tạo hàng đợi

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

⚠ Và Fn::GetAtt tạo ra một PHỤ THUỘC NGẦM:

CloudFormation thấy SNSTopic tham chiếu
  TutorialsDojoQueue
        ↓
    Tự sắp xếp: tạo hàng đợi TRƯỚC,
      topic SAU
    → không cần khai `DependsOn`

Template đầy đủ phải có cả hai:

Resources:
  TutorialsDojoQueue:
    Type: AWS::SQS::Queue
    Properties:
      QueueName: hang-doi-xu-ly
      VisibilityTimeout: 300

  SNSTopic:
    Type: AWS::SNS::Topic
    Properties:
      Subscription:
        - Protocol: sqs
          Endpoint: !GetAtt TutorialsDojoQueue.Arn

⚠ Nhưng template như trên VẪN CHƯA CHẠY được — thiếu queue policy:

SNS phải có quyền `sqs:SendMessage`
  vào hàng đợi
        ↓
    Không có: subscription tạo thành công
    → nhưng thông điệp KHÔNG BAO GIỜ tới
    → và không có lỗi nào ở đâu cả

  ChinhSachHangDoi:
    Type: AWS::SQS::QueuePolicy
    Properties:
      Queues: [!Ref TutorialsDojoQueue]
      PolicyDocument:
        Statement:
          - Effect: Allow
            Principal: {Service: sns.amazonaws.com}
            Action: sqs:SendMessage
            Resource: !GetAtt TutorialsDojoQueue.Arn
            Condition:
              ArnEquals: {aws:SourceArn: !Ref SNSTopic}

⚠ Ref và GetAtt trả về giá trị khác nhau tuỳ tài nguyên — bảng phải thuộc: | Tài nguyên | Ref trả về | GetAtt ... .Arn | |---|---|---| | SNS Topic | ARN | ARN | | SQS Queue | URL | ARN | | S3 Bucket | tên bucket | ARN | | EC2 Instance | instance ID | không có Arn | | IAM Role | tên vai trò | ARN |

SQS: `Ref` cho URL, `GetAtt Arn` cho ARN
    → subscription cần ARN
    → dùng `Ref` ở đây là sai

Ba lợi ích của mẫu SNS-SQS này: | Lợi ích | Chi tiết | |---|---| | Fan-out: một sự kiện tới nhiều hàng đợi | | | Mỗi hệ thống có bộ đệm riêng | | | Hệ thống chậm không ảnh hưởng hệ thống khác | |

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

  • **A. Tạo SNS topic cho phép các endpoint SQS đăng ký — đây là phương án gần nhất và mô tả đúng phần giao thức, nhưng nó bỏ mất chi tiết quan trọng nhất: đoạn mã đăng ký một hàng đợi CỤ THỂ bằng ARN lấy qua GetAtt, chứ không chỉ "cho phép" nói chung.
  • **B. Tạo SNS topic rồi gọi lệnh tạo SQS queue tên TutorialsDojoQueue — Fn::GetAtt không tạo tài nguyên; hàng đợi phải được khai riêng.
  • **D. Tạo SNS topic cho phép thêm endpoint SQS làm tham số trên template — không có phần Parameters nào trong đoạn mã.

Ghi nhớ

⚠ Bốn hàm nội tại hay dùng nhất — bảng phải thuộc: | Hàm | Việc | |---|---| | Ref | giá trị mặc định của tài nguyên hoặc tham số | | Fn::GetAtt | một thuộc tính cụ thể | | Fn::Sub | thay biến trong chuỗi | | Fn::ImportValue | lấy export từ stack khác |

Cú pháp rút gọn trong YAML:

!Ref TenTaiNguyen
!GetAtt TenTaiNguyen.ThuocTinh
!Sub 'arn:aws:s3:::${TenBucket}/*'
!ImportValue mang-chung-VPCID

Từ khoá nhận diện:

"reference another resource's ARN" → GetAtt "resource must be created first" → phụ thuộc ngầm hoặc DependsOn "value from another stack" → ImportValue "secret at deploy time" → dynamic reference

Ba lưu ý về phụ thuộc: | Lưu ý | Chi tiết | |---|---| | Ref và GetAtt tạo phụ thuộc ngầm | | | DependsOn khi phụ thuộc không thể hiện qua tham chiếu | | | Phụ thuộc vòng làm stack lỗi | |

⚠ Phụ thuộc vòng và cách gỡ:

SG-A cho phép từ SG-B
    + SG-B cho phép từ SG-A
        ↓
    Vòng — CloudFormation từ chối
        ↓
    Gỡ bằng cách tách quy tắc ra
      `AWS::EC2::SecurityGroupIngress`
      riêng

Ba lưu ý về SNS: | Lưu ý | Chi tiết | |---|---| | Hỗ trợ SQS, Lambda, HTTP/S, email, SMS | | | Standard và FIFO | | | Filter policy lọc theo thuộc tính thông điệp | |

⚠ Filter policy giảm xử lý thừa:

{"loaiSuKien": ["don-hang-moi"],
 "giaTri": [{"numeric": [">", 1000000]}]}

Chỉ hàng đợi quan tâm mới nhận
    → không phải mọi consumer đều
      nhận rồi tự lọc

Ba lưu ý về mẫu fan-out: | Lưu ý | Chi tiết | |---|---| | SNS đẩy, SQS đệm | | | Bật raw message delivery nếu không cần vỏ SNS | | | Mỗi hàng đợi có DLQ riêng | |

⚠ Raw message delivery ảnh hưởng mã xử lý:

Mặc định: thông điệp bọc trong JSON
  của SNS
    → consumer phải bóc lớp `Message`
        ↓
    Bật raw: nội dung gốc đi thẳng
    → nhưng mất thuộc tính SNS

Ba lưu ý về quyền: | Lưu ý | Chi tiết | |---|---| | Queue policy cho SNS gửi vào SQS | | | Topic policy cho ai publish được | | | Điều kiện aws:SourceArn chống confused deputy | |

Ba lưu ý về gỡ lỗi template: | Công cụ | Việc | |---|---| | cfn-lint | bắt lỗi cú pháp và thuộc tính sai | | validate-template | kiểm tra cơ bản | | Change set | xem trước thay đổi |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Publish một thông điệp, xem có tới hàng đợi | | | Kiểm NumberOfNotificationsFailed của SNS | | | Xem queue policy đã có chưa | |

Và một lời khuyên: hãy luôn khai queue policy cùng lúc với subscription SNS-SQS. Thiếu nó là chế độ hỏng tệ nhất trong nhóm này — mọi thứ tạo thành công, bảng điều khiển hiện subscription đang hoạt động, và thông điệp lặng lẽ biến mất không để lại dấu vết nào.

Câu 123 Chọn nhiều đáp án Domain - Accelerate Workload Migration and Modernization

A company is using AWS Managed Active Directory Service to host the company AD in the AWS Cloud with a custom AD domain name private.tutorialsdojo.com. A pair of domain controllers are launched with the default configuration inside the VPC. A VPC interface endpoint was also created for the Amazon Kinesis using AWS Private Link to allow instances to connect to Kinesis service endpoints from inside the VPC. The solutions architect launched several EC2 instances in the VPC, however, the instances were not able to resolve the company’s custom AD domain name.

Which of the following steps should the Solutions Architect implement to allow the instances to resolve both AWS VPC endpoints and the AWS Managed Microsoft AD domain’s FQDN? (Select TWO.)

  1. A

    Create a forwarding rule inside the endpoint to forward any queries for private.tutorialsdojo.com to the IP addresses of the two domain controllers.
  2. B

    Create a conditional forwarder inside the endpoint to forward any queries for private.tutorialsdojo.com to the IP addresses of the two domain controllers.
  3. C

    Create an outbound endpoint on the Amazon Route 53 console. Set the AmazonProvidedDNS as the DNS resolver for the VPC.
  4. D

    Reconfigure the DNS service on every client on the VPC to split DNS queries. Use the Active Directory servers for the custom AD domain and the VPC resolver for all other DNS queries.
  5. E

    Create an inbound endpoint on the Amazon Route 53 console. Set the AmazonProvidedDNS as the DNS resolver for the VPC.
Xem giải thích

Đáp án

**A và C — Tạo forwarding rule chuyển mọi truy vấn cho private.tutorialsdojo.com tới IP của hai domain controller; và tạo outbound endpoint trên Route 53 Resolver, đặt AmazonProvidedDNS làm bộ phân giải của VPC.

Vì sao đúng

Đề mô tả một xung đột DNS kinh điển: | Cần phân giải | Chỉ ai làm được | |---|---| | Tên miền AD private.tutorialsdojo.com | domain controller | | Tên VPC endpoint (PrivateLink) | AmazonProvidedDNS |

Đặt DNS của VPC thành IP của
  domain controller
    → phân giải được AD
    → nhưng MẤT khả năng phân giải
      VPC endpoint
        ↓
    Giữ AmazonProvidedDNS
    → ngược lại
        ↓
    Cần một cơ chế chuyển tiếp CÓ ĐIỀU KIỆN

⚠ Route 53 Resolver giải quyết đúng bài toán này:

Giữ AmazonProvidedDNS làm bộ phân giải
    → EC2 hỏi nó mọi thứ
        ↓
    Forwarding rule nói: tên nào thuộc
      `private.tutorialsdojo.com`
      thì chuyển sang domain controller
        ↓
    Mọi tên khác: Resolver tự trả lời
    → gồm cả VPC endpoint

⚠ Và chiều của endpoint phải chọn đúng: | Endpoint | Chiều | Dùng khi | |---|---|---| | Outbound | từ VPC ra ngoài | VPC hỏi DNS bên ngoài (AD, tại chỗ) | | Inbound | từ ngoài vào VPC | mạng tại chỗ hỏi tên trong VPC |

Ở đây EC2 trong VPC cần hỏi
  domain controller
    → chiều ĐI RA
    → outbound endpoint
        ↓
    Đây là lý do phương án E sai

Tạo outbound endpoint:

aws route53resolver create-resolver-endpoint \
  --name endpoint-ra --direction OUTBOUND \
  --security-group-ids sg-resolver \
  --ip-addresses SubnetId=subnet-a SubnetId=subnet-b

Tạo forwarding rule:

aws route53resolver create-resolver-rule \
  --name chuyen-tiep-ad --rule-type FORWARD \
  --domain-name private.tutorialsdojo.com \
  --resolver-endpoint-id rslvr-out-abc \
  --target-ips Ip=10.0.1.10,Port=53 Ip=10.0.2.10,Port=53

Gắn quy tắc vào VPC:

aws route53resolver associate-resolver-rule \
  --resolver-rule-id rslvr-rr-abc --vpc-id vpc-abc

⚠ Bước gắn này hay bị quên:

Tạo quy tắc xong nhưng chưa gắn VPC
    → quy tắc tồn tại mà không có
      hiệu lực gì
        ↓
    Không có lỗi nào, chỉ là DNS
      vẫn không phân giải được

⚠ "Conditional forwarder" và "forwarding rule" là hai thuật ngữ khác nhau: | Thuật ngữ | Thuộc về | |---|---| | Conditional forwarder | Active Directory / Windows DNS | | Forwarding rule | Route 53 Resolver |

Cả hai làm việc tương tự
    → nhưng ở hai sản phẩm khác nhau
        ↓
    Phương án B nói "conditional forwarder
      trong endpoint" — trộn lẫn hai thứ

⚠ Và chiều ngược lại cũng thường cần:

Domain controller cần phân giải tên
  trong VPC (ví dụ endpoint)
        ↓
    Thêm conditional forwarder TRÊN AD
      trỏ tới inbound endpoint
    → hai chiều mới trọn vẹn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Phân giải được cả AD lẫn dịch vụ AWS | | | Không phải sửa cấu hình DNS trên từng máy | | | Quy tắc chia sẻ được cho nhiều VPC qua RAM | |

Security group cho endpoint:

aws ec2 authorize-security-group-egress \
  --group-id sg-resolver --protocol udp --port 53 \
  --cidr 10.0.0.0/16
aws ec2 authorize-security-group-egress \
  --group-id sg-resolver --protocol tcp --port 53 \
  --cidr 10.0.0.0/16

⚠ Phải mở CẢ UDP lẫn TCP cổng 53:

Truy vấn DNS thường dùng UDP
    → nhưng phản hồi lớn chuyển sang TCP
        ↓
    Chỉ mở UDP: phần lớn hoạt động
    → rồi thỉnh thoảng hỏng khó hiểu

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

  • **B. Tạo conditional forwarder trong endpoint chuyển truy vấn tới domain controller — đây là phương án gần nhất và ý tưởng hoàn toàn đúng, nhưng thuật ngữ sai: trong Route 53 Resolver, cấu trúc đó gọi là forwarding rule; conditional forwarder là khái niệm của Windows DNS.
  • **E. Tạo inbound endpoint và đặt AmazonProvidedDNS làm bộ phân giải — sai chiều: inbound dành cho mạng bên ngoài hỏi vào VPC.
  • **D. Cấu hình lại DNS trên từng máy khách để chia truy vấn — không co giãn, phải sửa mọi instance và mọi instance mới, và trái với tinh thần dịch vụ quản lý.

Ghi nhớ

⚠ Ba thành phần DNS trong VPC — bảng phải thuộc: | Thành phần | Việc | |---|---| | AmazonProvidedDNS (.2 của VPC) | phân giải tên AWS và Internet | | Route 53 private hosted zone | tên riêng trong VPC | | Route 53 Resolver endpoint | cầu nối với DNS bên ngoài |

Từ khoá nhận diện:

"resolve on-premises names from VPC" → outbound endpoint + forwarding rule "resolve VPC names from on-premises" → inbound endpoint "both AD and VPC endpoints" → giữ AmazonProvidedDNS + forwarding rule "private names within VPC only" → private hosted zone

Ba lưu ý về Resolver endpoint: | Lưu ý | Chi tiết | |---|---| | Cần ít nhất hai IP ở hai AZ | | | Tính phí theo giờ mỗi ENI | | | Có hạn mức truy vấn mỗi giây mỗi IP | |

⚠ Hạn mức truy vấn là điểm phải tính khi đội máy lớn:

Mỗi IP của endpoint có trần
  truy vấn mỗi giây
        ↓
    Đội máy lớn hoặc ứng dụng
      hỏi DNS liên tục
    → thêm IP cho endpoint

Ba lưu ý về forwarding rule: | Lưu ý | Chi tiết | |---|---| | Khớp theo tên miền, cụ thể hơn thắng | | | Kiểu SYSTEM để loại trừ tên miền con | | | Chia sẻ qua RAM cho nhiều tài khoản | |

⚠ Quy tắc SYSTEM để tạo ngoại lệ:

FORWARD `tutorialsdojo.com` → AD
    + SYSTEM `www.tutorialsdojo.com`
        ↓
    Tên miền con này dùng phân giải
      mặc định của Route 53
    → không chuyển sang AD

Ba lưu ý về VPC endpoint và DNS: | Lưu ý | Chi tiết | |---|---| | Bật PrivateDnsEnabled để dùng tên chuẩn của dịch vụ | | | Cần enableDnsHostnames và enableDnsSupport trên VPC | | | Không bật thì phải dùng tên riêng của endpoint | |

⚠ Hai thuộc tính VPC là điều kiện tiên quyết:

aws ec2 modify-vpc-attribute --vpc-id vpc-abc \
  --enable-dns-hostnames
aws ec2 modify-vpc-attribute --vpc-id vpc-abc \
  --enable-dns-support

Thiếu: `PrivateDnsEnabled` không bật được
    → và tên chuẩn của dịch vụ vẫn
      trỏ ra endpoint công cộng

Ba lưu ý về Managed Microsoft AD: | Lưu ý | Chi tiết | |---|---| | Hai domain controller ở hai AZ | | | IP của chúng là target của forwarding rule | | | describe-directories lấy IP | |

aws ds describe-directories \
  --query 'DirectoryDescriptions[0].DnsIpAddrs'

Ba lưu ý về gỡ lỗi DNS: | Công cụ | Việc | |---|---| | dig @10.0.0.2 ten.can.tim | hỏi thẳng resolver của VPC | | Resolver query logging | xem truy vấn và kết quả | | Reachability Analyzer | kiểm đường tới domain controller |

aws route53resolver create-resolver-query-log-config \
  --name log-truy-van \
  --destination-arn arn:aws:logs:...:log-group:/dns

Ba lưu ý về chia sẻ quy tắc: | Lưu ý | Chi tiết | |---|---| | RAM chia sẻ quy tắc cho tổ chức | | | Mỗi VPC vẫn phải gắn quy tắc | | | Quản lý tập trung ở tài khoản mạng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | dig private.tutorialsdojo.com từ EC2 | | | dig kinesis.ap-southeast-1.amazonaws.com | | | Kiểm cả hai đều ra IP riêng tư | |

Và một lời khuyên: hãy kiểm tra cả hai loại tên sau khi cấu hình xong. Rất dễ sửa được việc phân giải AD rồi vô tình làm hỏng việc phân giải VPC endpoint — và lỗi thứ hai chỉ lộ ra khi một ứng dụng nào đó gọi dịch vụ AWS lần đầu tiên.

Câu 124 Domain - Continuous Improvement for Existing Solutions

A company stores several terabytes of data on an Amazon S3 bucket. The data will be made available to respective partner companies, however, the management doesn’t want the partner companies to access the files directly from Amazon S3 URLs. The solutions architect has been asked to ensure that all confidential files shared via Amazon S3 should only be accessible through CloudFront.

Which of the following options could satisfy this requirement?

  1. A

    Create an Origin Access Control (OAC) and associate it with your CloudFront distribution. Change the permissions on your Amazon S3 bucket so that only the origin access control has read permission.
  2. B

    Write individual policies for each S3 bucket containing the confidential documents that would grant CloudFront access.
  3. C Assign an IAM user that is granted access to objects in the S3 bucket to CloudFront.
  4. D Write an S3 bucket policy that assigns the CloudFront distribution ID as the Principal and the target bucket as the Amazon Resource Name (ARN).
Xem giải thích

Đáp án

**A — Tạo Origin Access Control (OAC) và gắn vào phân phối CloudFront; đổi quyền trên bucket S3 sao cho chỉ OAC đó có quyền đọc.

Vì sao đúng

Đề yêu cầu tệp chỉ truy cập được qua CloudFront, và OAC là cơ chế dành riêng cho việc đó:

Không có OAC: bucket phải công khai
  để CloudFront đọc được
    → mà công khai nghĩa là URL S3
      trực tiếp cũng dùng được
        ↓
    Có OAC: CloudFront KÝ yêu cầu bằng
      SigV4 khi gọi S3
    → bucket policy chỉ cho principal
      `cloudfront.amazonaws.com`
    → mọi đường khác bị 403

⚠ OAC thay cho OAI đã cũ — bảng phải thuộc: | Tiêu chí | OAI (cũ) | OAC (nay) | |---|---|---| | Bucket mã hoá SSE-KMS | KHÔNG hỗ trợ | CÓ | | Phương thức | chỉ GET/HEAD | cả PUT, POST, DELETE | | Mọi Region | hạn chế | có | | Ký yêu cầu | SigV4 hạn chế | SigV4 đầy đủ |

Bucket dùng SSE-KMS
    → OAI không đọc được
    → đây là lý do chính AWS ra OAC

Tạo OAC:

aws cloudfront create-origin-access-control \
  --origin-access-control-config '{
    "Name": "oac-tai-lieu",
    "OriginAccessControlOriginType": "s3",
    "SigningBehavior": "always",
    "SigningProtocol": "sigv4"}'

Bucket policy đúng:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Principal": {"Service": "cloudfront.amazonaws.com"},
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::tai-lieu-mat/*",
  "Condition": {"StringEquals":
    {"AWS:SourceArn":
      "arn:aws:cloudfront::111122223333:distribution/E1ABC2DEF"}}}]}

⚠ Điều kiện AWS:SourceArn là phần bắt buộc:

Principal chỉ là "cloudfront.amazonaws.com"
    → nghĩa là MỌI phân phối CloudFront
      của MỌI khách hàng AWS
        ↓
    Ai đó tạo phân phối trỏ vào
      bucket của bạn là đọc được
        ↓
    `AWS:SourceArn` khoá đúng
      phân phối của bạn

Đây cũng là lý do phương án D sai — không có cách nào đặt distribution ID làm Principal.

Chặn mọi truy cập công khai:

aws s3api put-public-access-block --bucket tai-lieu-mat \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,\
BlockPublicPolicy=true,RestrictPublicBuckets=true

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bucket hoàn toàn riêng tư | | | Một điểm kiểm soát: phân phối CloudFront | | | Áp dụng cho mọi object, không phải từng cái | |

⚠ Nhưng OAC chỉ chặn ĐƯỜNG S3 — nó không giới hạn AI xem:

Sau khi bật OAC
    → URL S3 trực tiếp: 403
    → URL CloudFront: ai cũng tải được
        ↓
    Muốn giới hạn người xem
    → thêm signed URL hoặc signed cookie

Bật signed URL cho một cache behavior:

{"TrustedKeyGroups": {
  "Enabled": true, "Quantity": 1,
  "Items": ["<id-key-group>"]}}

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

  • **D. Viết bucket policy đặt distribution ID làm Principal — đây là phương án gần nhất và hướng đi đúng là dùng bucket policy, nhưng Principal phải là một danh tính IAM hoặc service principal; distribution ID không phải principal, nó chỉ dùng được trong Condition.
  • **B. Viết chính sách riêng cho từng bucket cấp quyền cho CloudFront — mơ hồ về cơ chế và không nói tới OAC; không có OAC thì CloudFront gọi S3 như người dùng ẩn danh và bucket vẫn phải công khai.
  • **C. Gán một IAM user có quyền đọc bucket cho CloudFront — CloudFront không giả nhận IAM user; đó không phải cách dịch vụ này hoạt động.

Ghi nhớ

⚠ Ba lớp bảo vệ nội dung qua CloudFront — bảng phải thuộc: | Lớp | Chặn gì | |---|---| | OAC | truy cập thẳng vào S3 | | Signed URL / cookie | người không được cấp quyền | | Geo restriction / WAF | theo quốc gia hoặc mẫu tấn công |

Từ khoá nhận diện:

"only accessible through CloudFront" → OAC "only specific users can view" → signed URL hoặc cookie "block a country" → geo restriction "S3 bucket must not be public" → OAC + Block Public Access

Ba lưu ý về OAC: | Lưu ý | Chi tiết | |---|---| | SigningBehavior: always cho hầu hết trường hợp | | | Hỗ trợ cả origin không phải S3 (Lambda URL, MediaStore) | | | Bucket policy phải có AWS:SourceArn | |

⚠ Nếu bucket mã hoá SSE-KMS thì cần thêm quyền KMS:

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": ["kms:Decrypt"],
 "Resource": "*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn": "<arn-phan-phoi>"}}}

Đặt trong KEY POLICY, không phải
  bucket policy
        ↓
    Thiếu: CloudFront trả 403 dù
      bucket policy đã đúng

Ba lưu ý về Block Public Access: | Lưu ý | Chi tiết | |---|---| | Bật ở cả mức tài khoản và bucket | | | Không cản trở OAC | | | Nên là mặc định cho mọi bucket | |

Ba lưu ý về signed URL: | Lưu ý | Chi tiết | |---|---| | Cần key group với public key | | | Chính sách custom giới hạn được IP | | | Đặt hạn ngắn nhất dùng được | |

Ba lưu ý về S3 website endpoint: | Lưu ý | Chi tiết | |---|---| | OAC KHÔNG dùng được với website endpoint | | | Website endpoint luôn là HTTP và công khai | | | Dùng REST endpoint để có OAC | |

⚠ Đây là chỗ hay nhầm khi cần chuyển hướng thư mục:

Cần index.html tự động cho thư mục con
    → website endpoint làm được
    → nhưng mất OAC
        ↓
    Giữ REST endpoint + CloudFront Functions
      viết lại URL
    → có cả hai

function handler(su_kien) {
  var yeu_cau = su_kien.request;
  if (yeu_cau.uri.endsWith('/'))
    yeu_cau.uri += 'index.html';
  return yeu_cau;
}

Ba lưu ý về ghi nhận truy cập: | Lưu ý | Chi tiết | |---|---| | CloudFront standard log vào S3 | | | Real-time log qua Kinesis | | | S3 server access log cho tầng dưới | |

Ba lưu ý về nhiều origin: | Lưu ý | Chi tiết | |---|---| | Mỗi origin có OAC riêng | | | Cache behavior chọn origin theo đường dẫn | | | Origin group cho failover | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl URL S3 trực tiếp — phải 403 | | | curl URL CloudFront — phải 200 | | | Kiểm bucket không có quyền công khai nào | |

Và một lời khuyên: hãy luôn thêm điều kiện AWS:SourceArn vào bucket policy dùng OAC. Không có nó, bạn không cấp quyền cho phân phối của mình — bạn cấp quyền cho dịch vụ CloudFront nói chung, và bất kỳ ai cũng tạo được một phân phối trỏ vào bucket đó.

Câu 125 Domain - Continuous Improvement for Existing Solutions

A car parts manufacturing company installed IP cameras along its assembly line. These cameras are part of the quality inspection process, capturing images of each car part and detecting defects by performing a comparison with a baseline image. To improve the accuracy of detection, the company used Amazon SageMaker AI to train a machine learning (ML) model that contains baseline images and common defects.

Upon detection, the workers should receive feedback from the Linux server in the on-premises data center that hosts an API for the IP cameras. The company wants to make this solution available even when the factory’s internet connectivity is down.

Which of the following options is the recommended solution for deploying the ML model that meets the company's requirements?

  1. A

    Deploy the AWS IoT Greengrass client software to another local server. Run ML inference on the Greengrass server from the ML model trained from SageMaker AI. Use Greengrass components to interact with the Linux server API whenever a defect is detected.
  2. B

    Request for an AWS Snowball Edge Compute Optimized device. This can provide the computing power for the ML training model. Migrate the Linux server to an Amazon EC2 host on the Snowball device. Configure the IP cameras to send the pictures to the Snowball local storage to be processed by the EC2 server.
  3. C

    Deploy an AWS Outposts server on the local data center to create an AWS private cloud. Deploy SageMaker AI on this server for ML training and leverage Amazon Rekognition with its computer vision capabilities to detect defects among manufactured car parts.
  4. D

    Use Amazon SageMaker Edge Manager to deploy and manage the ML model on the IP cameras themselves, allowing them to detect defects and send results to the Linux server API.
Xem giải thích

Đáp án

**A — Cài AWS IoT Greengrass lên một máy chủ nội bộ khác, chạy suy luận ML ngay trên máy đó bằng mô hình đã huấn luyện từ SageMaker AI, và dùng Greengrass component để gọi API trên máy chủ Linux mỗi khi phát hiện lỗi.

Vì sao đúng

Đề nêu ba yêu cầu, và Greengrass là dịch vụ được thiết kế đúng cho cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Chạy mô hình ML tại nhà máy | suy luận trên thiết bị biên | | Vẫn hoạt động khi mất Internet | Greengrass chạy độc lập | | Gọi API trên máy chủ Linux nội bộ | component tuỳ chỉnh |

⚠ "Hoạt động cả khi mất mạng" là yêu cầu quyết định:

Mọi phương án gọi dịch vụ trên cloud
    → mất Internet là dừng dây chuyền
        ↓
    Greengrass: mô hình và mã nằm
      TRÊN máy tại nhà máy
    → mất mạng vẫn kiểm định bình thường
    → chỉ đồng bộ kết quả khi có mạng lại

⚠ Và luồng làm việc đúng của SageMaker + Greengrass:

Huấn luyện trên đám mây (SageMaker AI)
    → nhiều dữ liệu, nhiều GPU
        ↓
    Triển khai mô hình xuống biên
      (Greengrass)
    → suy luận tại chỗ, độ trễ thấp
        ↓
    Gửi kết quả và dữ liệu mới về
      để huấn luyện lại

Triển khai component:

aws greengrassv2 create-deployment \
  --target-arn <arn-nhom-thiet-bi> \
  --deployment-name trien-khai-kiem-dinh \
  --components '{
    "aws.greengrass.SageMakerEdgeManager": {"componentVersion": "1.3.0"},
    "com.nhamay.KiemDinhAnh": {"componentVersion": "1.0.0"}}'

Component gọi API nội bộ:

import awsiot.greengrasscoreipc.clientv2 as ipc
import requests

client = ipc.GreengrassCoreIPCClientV2()

def khi_phat_hien_loi(anh, loai_loi, do_tin_cay):
    requests.post('http://may-chu-noi-bo:8080/api/canh-bao',
                  json={'loaiLoi': loai_loi,
                        'doTinCay': do_tin_cay})
    client.publish_to_iot_core(
        topic_name='nha-may/loi', qos='1',
        payload=json.dumps({'loaiLoi': loai_loi}))

⚠ Stream Manager giữ dữ liệu khi mất mạng:

from stream_manager import StreamManagerClient, ExportDefinition

client = StreamManagerClient()
client.create_message_stream(MessageStreamDefinition(
    name='ket-qua-kiem-dinh',
    strategy_on_full=StrategyOnFull.OverwriteOldestData,
    export_definition=ExportDefinition(
        kinesis=[KinesisConfig(identifier='len-cloud',
                               kinesis_stream_name='ket-qua')])))

Mất mạng: dữ liệu ghi vào đĩa cục bộ
    → có mạng lại: tự đẩy lên cloud
        ↓
    Không mất dữ liệu, không cần
      tự viết cơ chế đệm

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Độ trễ vài mili giây, không đi ra cloud | | | Hoạt động không phụ thuộc đường truyền | | | Cập nhật mô hình từ xa qua deployment | |

⚠ Độ trễ là lý do thứ hai, quan trọng không kém:

Dây chuyền chạy liên tục
    → gửi ảnh lên cloud và chờ trả lời
    → hàng trăm mili giây mỗi ảnh
        ↓
    Suy luận tại chỗ: vài mili giây
    → theo kịp tốc độ dây chuyền

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

⚠ Phương án D nhắc tới một dịch vụ đã ngừng hoạt động.

Amazon SageMaker Edge Manager đã ngừng từ 26/04/2024. Ngay cả khi còn, nó quản lý mô hình trên thiết bị chứ không tự chạy được logic gọi API như đề mô tả.

Và cách làm hiện nay: | Nhu cầu | Dịch vụ | |---|---| | Chạy mô hình ở biên | Greengrass + component suy luận | | Tối ưu mô hình cho phần cứng biên | SageMaker Neo | | Quản lý đội thiết bị | IoT Device Management |

SageMaker Neo biên dịch mô hình
  cho chip cụ thể
    → nhanh hơn nhiều lần, nhẹ hơn
        ↓
    Vẫn còn và vẫn dùng được
    → khác với Edge Manager

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

  • **B. Xin Snowball Edge Compute Optimized, chuyển máy chủ Linux thành EC2 trên thiết bị đó — đây là phương án gần nhất và Snowball Edge thật sự chạy được tính toán tại chỗ, nhưng nó là thiết bị mượn tạm cho việc di chuyển dữ liệu hoặc xử lý ngắn hạn, không phải nền tảng thường trực cho dây chuyền sản xuất; và đề nói huấn luyện đã xong trên SageMaker.
  • **C. Triển khai AWS Outposts và chạy SageMaker trên đó cùng Rekognition — Outposts là tủ rack nguyên chiếc, chi phí và độ phức tạp quá lớn cho một bài toán kiểm định; và Rekognition không chạy trên Outposts.
  • **D. Dùng SageMaker Edge Manager triển khai mô hình lên chính camera IP — dịch vụ đã ngừng, và camera IP thường không đủ năng lực chạy mô hình.

Ghi nhớ

⚠ Bốn lựa chọn tính toán ở biên — bảng phải thuộc: | Dịch vụ | Bản chất | |---|---| | IoT Greengrass | phần mềm cài trên máy của bạn | | Outposts | rack phần cứng AWS đặt tại chỗ | | Snowball Edge | thiết bị mượn tạm, có tính toán | | Local Zones / Wavelength | hạ tầng AWS gần người dùng |

Từ khoá nhận diện:

"must work when internet is down" → Greengrass "AWS hardware in my data centre" → Outposts "one-time bulk transfer with processing" → Snowball Edge "optimise model for edge hardware" → SageMaker Neo

Ba lưu ý về Greengrass: | Lưu ý | Chi tiết | |---|---| | Kiến trúc component, viết bằng ngôn ngữ nào cũng được | | | Triển khai theo nhóm thiết bị | | | Lambda chạy được tại chỗ | |

⚠ Component thay cho mô hình Lambda-only của Greengrass v1:

v1: chỉ chạy hàm Lambda
    ↓
v2: component là bất kỳ tiến trình nào
  → Docker, script, dịch vụ hệ thống
  → linh hoạt hơn hẳn

Ba lưu ý về bảo mật ở biên: | Lưu ý | Chi tiết | |---|---| | Mỗi thiết bị một chứng chỉ X.509 | | | Chính sách IoT giới hạn theo chủ đề | | | Mã hoá dữ liệu lưu trên thiết bị | |

Ba lưu ý về cập nhật mô hình: | Lưu ý | Chi tiết | |---|---| | Triển khai theo nhóm, thử trên nhóm nhỏ trước | | | Có cơ chế quay lui | | | Theo dõi độ chính xác sau khi cập nhật | |

⚠ Trôi mô hình là rủi ro dài hạn:

Mô hình huấn luyện trên dữ liệu năm ngoái
    → dây chuyền đổi vật liệu, đổi ánh sáng
        ↓
    Độ chính xác giảm dần mà không ai biết
    → phải thu thập kết quả thật
      và huấn luyện lại định kỳ

Ba lưu ý về phần cứng: | Lưu ý | Chi tiết | |---|---| | Suy luận thị giác thường cần GPU hoặc NPU | | | SageMaker Neo tối ưu cho chip cụ thể | | | Đo thông lượng thật trước khi triển khai rộng | |

Ba lưu ý về đồng bộ lên cloud: | Lưu ý | Chi tiết | |---|---| | Stream Manager đệm khi mất mạng | | | Chỉ gửi kết quả, không gửi mọi ảnh | | | Gửi ảnh khó phân loại để huấn luyện lại | |

⚠ Điểm giữa là quyết định về băng thông:

Gửi mọi ảnh lên cloud
    → tốn băng thông khổng lồ
        ↓
    Chỉ gửi ảnh có độ tin cậy thấp
    → dữ liệu quý nhất cho việc
      cải thiện mô hình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ngắt Internet, xem dây chuyền còn chạy | | | Đo độ trễ suy luận trên máy biên | | | So kết quả máy với kiểm định thủ công | |

Và một lời khuyên: hãy rút dây mạng của nhà máy một lần và quan sát điều gì xảy ra. Đó là kịch bản mà cả kiến trúc này được dựng lên để chịu đựng — và cũng là kịch bản gần như không ai thử cho tới ngày nó tự xảy ra.

Câu 126 Domain - Design for New Solutions

A company wants to create a new service that will complement the launch of its new product. The site must be highly-available and scalable to handle the unpredictable workload, and should also be stateless and REST compliant. The solution needs to have multiple persistent storage layers for service object metadata and durable storage for static content. All requests to the service should be authenticated and securely processed. The company also wants to keep the costs at a minimum.

Which of the following is the recommended solution that will meet the company requirements?

  1. A

    Package the REST service on a Docker-based container and run it using the AWS Fargate service. Create an Application Load Balancer in front of the Fargate service. Create a custom authenticator that will control access to the API. Store service object metadata in an Amazon DynamoDB table with Auto Scaling enabled. Create an Amazon S3 bucket to store the static content and enable secure-signed requests for the objects. Proxy the data through the REST service.
  2. B

    Configure Amazon API Gateway with the required resources and methods. Create unique Lambda functions to process each resource and configure the API Gateway methods with proxy integration to the respective Lambda functions. Control user access to the API by using the API Gateway custom authorizer. Store service object metadata in an Amazon ElastiCache Multi-AZ cluster. Create a secured Amazon S3 bucket to store the static content. Generate presigned URLs when referencing objects stored on the S3 bucket.
  3. C

    Package the REST service on a Docker-based container and run it using the AWS Fargate service. Create a cross-zone Application Load Balancer in front of the Fargate service. Control user access to the API by using Amazon Cognito user pools. Store service object metadata in an Amazon DynamoDB table with Auto Scaling enabled. Create an encrypted Amazon S3 bucket to store the static content. Generate presigned URLs when referencing objects stored on the S3 bucket.
  4. D

    Configure Amazon API Gateway with the required resources and methods. Create unique Lambda functions to process each resource and configure the API Gateway methods with proxy integration to the respective Lambda functions. Control user access to the API by using Amazon Cognito user pools. Store service object metadata in an Amazon DynamoDB table with Auto Scaling enabled. Create a secured Amazon S3 bucket to store the static content. Generate presigned URLs when referencing objects stored on the S3 bucket.
Xem giải thích

Đáp án

**D — Cấu hình API Gateway với các resource và method cần thiết, mỗi resource một Lambda qua tích hợp proxy, kiểm soát truy cập bằng Cognito user pool, lưu metadata trong DynamoDB có Auto Scaling, và tạo bucket S3 bảo mật cho nội dung tĩnh.

Vì sao đúng

Đề liệt kê sáu yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Sẵn sàng cao, co giãn | API Gateway + Lambda tự co giãn | | Tải khó đoán | không máy chủ, trả tiền theo lượt | | Stateless, tuân thủ REST | API Gateway | | Lưu metadata bền | DynamoDB | | Lưu nội dung tĩnh bền | S3 | | Mọi yêu cầu được xác thực | Cognito user pool |

⚠ Điểm phân biệt D với B nằm ở tầng lưu trữ metadata:

Phương án B dùng ElastiCache Multi-AZ
    → cache là bộ nhớ TẠM
        ↓
    Đề đòi "persistent storage layer"
    → cache mất node là mất dữ liệu
    → DynamoDB mới là lưu trữ bền

⚠ Và điểm phân biệt với A là cơ chế xác thực:

Phương án A: "custom authenticator" tự viết
    → tự lo lưu mật khẩu, xác nhận email,
      quên mật khẩu, MFA, chống dò
        ↓
    Cognito: có sẵn tất cả
    → và đề nói "giữ chi phí tối thiểu"
    → tự viết là tốn nhất về lâu dài

Cognito authorizer trên API Gateway:

aws apigateway create-authorizer --rest-api-id <id> \
  --name cognito-authorizer --type COGNITO_USER_POOLS \
  --provider-arns <arn-user-pool> \
  --identity-source 'method.request.header.Authorization'

⚠ Ba loại authorizer của API Gateway — bảng phải thuộc: | Loại | Cách | |---|---| | Cognito user pool | API Gateway tự kiểm token, không viết mã | | Lambda authorizer | tự viết logic, linh hoạt nhất | | IAM | ký SigV4, cho dịch vụ nội bộ |

Người dùng cuối đăng nhập ứng dụng
    → Cognito authorizer, ít việc nhất
        ↓
    Logic phân quyền phức tạp,
      hoặc IdP ngoài
    → Lambda authorizer

Tích hợp proxy:

aws apigateway put-integration --rest-api-id <id> \
  --resource-id <id-resource> --http-method ANY \
  --type AWS_PROXY --integration-http-method POST \
  --uri arn:aws:apigateway:<vung>:lambda:path/2015-03-31/functions/<arn-lambda>/invocations

⚠ Tích hợp proxy chuyển nguyên yêu cầu vào Lambda:

Không phải viết mapping template
    → Lambda nhận đủ path, header,
      query, body
        ↓
    Đổi logic không phải sửa API Gateway
    → đơn giản hơn nhiều so với
      tích hợp không proxy

Auto Scaling cho DynamoDB:

aws application-autoscaling register-scalable-target \
  --service-namespace dynamodb \
  --resource-id table/MetadataDichVu \
  --scalable-dimension dynamodb:table:WriteCapacityUnits \
  --min-capacity 5 --max-capacity 4000

⚠ Nhưng on-demand thường đúng hơn với "tải khó đoán":

Auto Scaling phản ứng SAU vài phút
    → đỉnh tải đột ngột vẫn bị chặn
        ↓
    On-demand: không có công suất
      để chạm trần
    → đắt hơn mỗi đơn vị, an toàn hơn

Nội dung tĩnh với yêu cầu ký:

url = s3.generate_presigned_url('get_object',
    Params={'Bucket': 'noi-dung-tinh', 'Key': khoa},
    ExpiresIn=900)

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có máy chủ nào phải vá hay theo dõi | | | Chi phí gần bằng 0 khi không có lưu lượng | | | Co giãn từ 0 tới hàng nghìn yêu cầu/giây | |

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

  • **B. Cùng kiến trúc API Gateway + Lambda + Cognito nhưng lưu metadata trong ElastiCache Multi-AZ — đây là phương án gần nhất và khác đúng một thành phần, nhưng ElastiCache là bộ nhớ đệm chứ không phải lưu trữ bền; đề đòi "persistent storage layer".
  • **A. Đóng gói bằng Fargate + ALB và custom authenticator — Fargate vẫn phải trả tiền theo thời gian chạy kể cả khi rảnh, và tự viết xác thực là phần dễ sai nhất trong bảo mật.
  • **C. Fargate + ALB với Cognito user pool — xác thực đúng, nhưng vẫn là mô hình trả tiền theo thời gian chạy; kém hơn Lambda với tải khó đoán và yêu cầu chi phí tối thiểu.

Ghi nhớ

⚠ Ba lựa chọn tính toán và khi nào chọn — bảng phải thuộc: | Lựa chọn | Chọn khi | |---|---| | Lambda | tải rời rạc, khó đoán, dưới 15 phút | | Fargate | chạy lâu, cần container, tải ổn định hơn | | EC2 | cần kiểm soát máy chủ, tải rất lớn và ổn định |

⚠ Điểm hoà vốn giữa Lambda và Fargate:

Lưu lượng rất thấp hoặc rất bất thường
    → Lambda rẻ hơn nhiều
        ↓
    Lưu lượng cao và đều 24/7
    → Fargate hoặc EC2 rẻ hơn
        ↓
    Tính bằng số lượt × thời gian chạy

Từ khoá nhận diện:

"unpredictable workload, minimise cost" → Lambda "stateless REST" → API Gateway "authenticate every request" → Cognito "persistent metadata store" → DynamoDB

Ba lưu ý về API Gateway: | Lưu ý | Chi tiết | |---|---| | REST API nhiều tính năng hơn, HTTP API rẻ hơn | | | Bật cache ở mức stage nếu đọc lặp nhiều | | | Usage plan giới hạn theo client | |

⚠ HTTP API rẻ hơn khoảng 70% nhưng thiếu vài tính năng: | Tính năng | REST API | HTTP API | |---|---|---| | Cache | có | không | | Usage plan, API key | có | không | | WAF | có | không | | JWT authorizer | qua Lambda | sẵn có |

Ba lưu ý về Cognito: | Lưu ý | Chi tiết | |---|---| | User pool: đăng nhập; identity pool: credential AWS | | | Hosted UI tuỳ biến giao diện được | | | Hỗ trợ MFA và liên kết mạng xã hội | |

Ba lưu ý về Lambda: | Lưu ý | Chi tiết | |---|---| | Khởi động nguội — dùng provisioned concurrency nếu cần | | | Reserved concurrency bảo vệ hàm khác | | | Tối đa 15 phút mỗi lượt | |

⚠ Khởi động nguội ảnh hưởng trải nghiệm ở API đồng bộ:

Hàm ít được gọi
    → mỗi lượt đầu mất vài trăm ms
      tới vài giây
        ↓
    Provisioned concurrency loại bỏ
    → nhưng tính tiền theo giờ giữ chỗ
        ↓
    Hoặc chọn runtime khởi động nhanh
      và giảm kích thước gói

Ba lưu ý về DynamoDB: | Lưu ý | Chi tiết | |---|---| | Thiết kế bảng theo mẫu truy cập | | | GSI cho truy vấn theo thuộc tính khác | | | TTL tự xoá bản ghi hết hạn | |

Ba lưu ý về bảo mật S3: | Lưu ý | Chi tiết | |---|---| | Block Public Access bật toàn bộ | | | Pre-signed URL hoặc CloudFront + OAC | | | Mã hoá SSE-KMS cho nội dung nhạy cảm | |

Ba lưu ý về giám sát: | Công cụ | Việc | |---|---| | X-Ray | theo dõi yêu cầu qua các tầng | | CloudWatch Logs Insights | truy vấn log | | Lambda Powertools | log có cấu trúc, chỉ số, tracing |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi API không có token — phải 401 | | | Đẩy tải cao xem có bị chặn không | | | Đo chi phí thật ở mức lưu lượng dự kiến | |

Và một lời khuyên: hãy dùng dịch vụ xác thực có sẵn thay vì tự viết, kể cả khi nó trông đơn giản. Phần khó của xác thực không phải là kiểm tra mật khẩu — nó là xoay token, khoá tài khoản, chống dò, khôi phục mật khẩu và mọi thứ bạn chỉ nhớ ra sau khi đã bị tấn công một lần.

Câu 127 Domain - Design for New Solutions

A leading commercial bank has multiple AWS accounts that are consolidated using AWS Organizations. They are building an online portal for foreclosed real estate properties that they own. The online portal is designed to use SSL for better security. The bank would like to implement a separation of responsibilities between the DevOps team and their cybersecurity team. The DevOps team is entitled to manage and log in to the EC2 instances while the cybersecurity team has exclusive access to the application's X.509 certificate, which contains the private key and is stored in AWS Certificate Manager (ACM).

Which of the following options would satisfy the company requirements?

  1. A

    Use the AWS Config service to configure the EC2 instances to retrieve the X.509 certificate upon boot from a CloudHSM that is managed by the cybersecurity team.
  2. B

    Set up a Service Control Policy (SCP) that authorizes access to the certificate store only for the cybersecurity team and then add a configuration to terminate the SSL on the ELB.
  3. C Configure an IAM policy that authorizes access to the certificate store only for the cybersecurity team and then add a configuration to terminate the SSL on the ELB.
  4. D

    Upload the X.509 certificate to an S3 bucket owned by the cybersecurity team and accessible only by the IAM role of the EC2 instances. Use the Systems Manager Session Manager as the HTTPS session manager for the application.
Xem giải thích

Đáp án

**C — Cấu hình chính sách IAM chỉ cho đội an ninh mạng truy cập kho chứng chỉ, và chấm dứt SSL tại ELB.

Vì sao đúng

Đề yêu cầu tách bạch trách nhiệm giữa hai đội, và phương án này làm được nhờ một đặc tính của ACM:

Đội DevOps: quản lý và đăng nhập EC2
    → nhưng KHÔNG chạm được chứng chỉ
        ↓
    Đội an ninh: nắm chứng chỉ và khoá riêng
    → nhưng không cần vào EC2
        ↓
    SSL chấm dứt tại ELB
    → chứng chỉ KHÔNG BAO GIỜ nằm
      trên máy mà DevOps đăng nhập được

⚠ Đặc tính then chốt: khoá riêng của ACM KHÔNG XUẤT ĐƯỢC:

Chứng chỉ công khai từ ACM
    → không có API nào lấy khoá riêng ra
        ↓
    Ngay cả quản trị viên tài khoản
      cũng không lấy được
    → đây là điều làm việc tách bạch
      trở nên có thật chứ không chỉ
      là quy ước

Chính sách cho đội an ninh:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Action": ["acm:RequestCertificate",
             "acm:DescribeCertificate",
             "acm:ListCertificates",
             "acm:DeleteCertificate",
             "acm:AddTagsToCertificate"],
  "Resource": "*"}]}

Chặn đội DevOps chạm ACM:

{"Effect": "Deny",
 "Action": "acm:*",
 "Resource": "*"}

⚠ Nhưng phải chú ý một quyền dễ lọt:

DevOps cần `elasticloadbalancing:*` để
  quản lý ELB
        ↓
    Trong đó có `CreateListener` và
      `ModifyListener`
    → tức là GẮN được chứng chỉ khác
      vào listener
        ↓
    Không lấy được khoá riêng
    → nhưng đổi được chứng chỉ đang dùng

Chặn cụ thể:

{"Effect": "Deny",
 "Action": ["elasticloadbalancing:ModifyListener",
            "elasticloadbalancing:AddListenerCertificates",
            "elasticloadbalancing:RemoveListenerCertificates"],
 "Resource": "*"}

⚠ Vì sao IAM policy chứ không phải SCP: | Cơ chế | Tác dụng | |---|---| | IAM policy | CẤP quyền cho một nhóm cụ thể | | SCP | đặt TRẦN cho cả tài khoản, KHÔNG cấp quyền |

Cần đội an ninh CÓ quyền
  và đội DevOps KHÔNG có
        ↓
    SCP không cấp quyền cho ai
    → nó chỉ chặn
    → phải dùng IAM policy

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

Gắn chứng chỉ vào listener:

aws elbv2 create-listener --load-balancer-arn <arn> \
  --protocol HTTPS --port 443 \
  --certificates CertificateArn=<arn-chung-chi> \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --default-actions Type=forward,TargetGroupArn=<arn-tg>

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Khoá riêng không tồn tại ở nơi DevOps chạm được | | | ACM tự gia hạn, không ai phải nhớ | | | Giảm tải mã hoá khỏi instance | |

⚠ Nếu cần mã hoá tới tận backend:

ELB chấm dứt TLS rồi mã hoá lại
  tới target
        ↓
    Target group giao thức HTTPS
    → chứng chỉ trên instance có thể
      là tự ký
    → ELB không kiểm chứng chỉ target

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

  • **B. Dùng SCP cho phép chỉ đội an ninh truy cập kho chứng chỉ và chấm dứt SSL tại ELB — đây là phương án gần nhất và phần chấm dứt SSL tại ELB hoàn toàn đúng, nhưng SCP áp cho tài khoản và OU, nó chỉ đặt trần chứ không cấp quyền cho một đội cụ thể.
  • **A. Dùng AWS Config để cấu hình EC2 lấy chứng chỉ từ CloudHSM khi khởi động — Config là dịch vụ đánh giá tuân thủ, nó không cấu hình instance; và đưa chứng chỉ lên chính EC2 là đưa nó vào tầm với của DevOps.
  • **D. Tải chứng chỉ lên S3 và dùng Session Manager làm "HTTPS session manager" — Session Manager là công cụ truy cập shell, không liên quan tới TLS; và đặt khoá riêng trong S3 là tạo ra thứ có thể tải về.

Ghi nhớ

⚠ Ba nơi có thể chấm dứt TLS — bảng phải thuộc: | Nơi | Ai giữ chứng chỉ | Ghi chú | |---|---|---| | CloudFront | ACM ở us-east-1 | gần người dùng nhất | | ALB / NLB | ACM cùng Region | phổ biến nhất | | EC2 | trên chính máy | cần khi TLS đi thẳng tới ứng dụng |

Từ khoá nhận diện:

"separate duties, team must not access private key" → ACM + chấm dứt tại ELB "end-to-end, LB must not decrypt" → NLB chế độ TCP "dedicated HSM, full key control" → CloudHSM "internal certificates" → ACM Private CA

Ba lưu ý về ACM: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ công khai miễn phí với dịch vụ tích hợp | | | Khoá riêng không xuất được | | | Xác thực DNS để tự gia hạn | |

⚠ Chứng chỉ NHẬP từ ngoài thì khác:

Import chứng chỉ mua ngoài vào ACM
    → KHÔNG tự gia hạn
        ↓
    Phải nhớ nhập lại mỗi năm
    → và ACM có cảnh báo qua EventBridge

{"source": ["aws.acm"],
 "detail-type": ["ACM Certificate Approaching Expiration"]}

Ba lưu ý về tách bạch trách nhiệm: | Lưu ý | Chi tiết | |---|---| | Dùng vai trò riêng cho từng đội | | | Deny tường minh cho việc ngoài phạm vi | | | Permission boundary chặn leo thang quyền | |

⚠ Leo thang quyền qua IAM là lỗ hổng phải chặn:

DevOps có `iam:CreateRole` và `iam:AttachRolePolicy`
    → tạo vai trò có quyền ACM
    → giả nhận nó
        ↓
    Vô hiệu hoá mọi ranh giới đã dựng
    → dùng permission boundary

{"Effect": "Deny",
 "Action": ["iam:CreateRole", "iam:AttachRolePolicy"],
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"iam:PermissionsBoundary":
     "arn:aws:iam::111122223333:policy/RanhGioiDevOps"}}}

Ba lưu ý về SSL policy: | Lưu ý | Chi tiết | |---|---| | Chọn policy TLS 1.2 trở lên | | | TLS 1.3 nếu client hỗ trợ | | | Rà soát khi có yêu cầu tuân thủ mới | |

Ba lưu ý về ACM Private CA: | Lưu ý | Chi tiết | |---|---| | Cho chứng chỉ nội bộ, mTLS | | | Trình duyệt không tin cậy | | | Chi phí đáng kể mỗi CA mỗi tháng | |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi mọi thao tác ACM | | | Cảnh báo khi có chứng chỉ bị xoá | | | Config rule kiểm ngày hết hạn | |

Ba lưu ý về Organizations: | Lưu ý | Chi tiết | |---|---| | SCP đặt trần cho cả OU | | | Kết hợp SCP và IAM policy | | | Quyền hiệu lực là giao của các tầng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Giả nhận vai trò DevOps, thử gọi ACM — phải bị từ chối | | | Thử đổi chứng chỉ trên listener — phải bị từ chối | | | Kiểm CloudTrail ghi đúng ai thao tác | |

Và một lời khuyên: hãy rà soát cả những quyền gián tiếp chứ đừng chỉ chặn API của chính dịch vụ đó. Cấm đội DevOps gọi ACM là chưa đủ nếu họ vẫn sửa được listener của ELB — ranh giới bảo mật chỉ vững bằng đường vòng lỏng nhất mà không ai nghĩ tới.

Câu 128 Domain - Accelerate Workload Migration and Modernization

A company is planning to migrate its workload to the AWS cloud. The solutions architect is looking to reduce the amount of time spent managing database instances from the on-premises data center by migrating to a managed relational database service in AWS such as Amazon Relational Database Service (RDS). In addition, the solutions architect plans to move the application hosted in the on-premises data center to a fully managed platform such as AWS Elastic Beanstalk.

Which of the following is the most cost-effective migration strategy that should be implemented to meet the above requirement?

  1. A

    Repurchase
  2. B

    Refactor / Re-architect
  3. C

    Rehost
  4. D

    Replatform
Xem giải thích

Đáp án

D — Replatform.

Vì sao đúng

Đề mô tả đúng hai thay đổi, và cả hai đều là dấu hiệu kinh điển của replatform: | Thay đổi | Bản chất | |---|---| | CSDL tại chỗ → Amazon RDS | đổi nền tảng, không đổi engine hay schema | | Ứng dụng → Elastic Beanstalk | đổi nền tảng chạy, không viết lại mã |

⚠ Định nghĩa ngắn nhất của replatform:

"Lift, tinker and shift"
    → nâng lên, chỉnh một chút, đặt xuống
        ↓
    Tận dụng dịch vụ quản lý của cloud
    → nhưng KHÔNG viết lại kiến trúc

⚠ Ranh giới với hai chiến lược lân cận: | Chiến lược | Đổi gì | |---|---| | Rehost | KHÔNG đổi gì — MySQL trên EC2 vẫn là MySQL trên máy ảo | | Replatform | đổi NỀN TẢNG — MySQL sang RDS | | Refactor | đổi KIẾN TRÚC — monolith sang microservices, RDS sang DynamoDB |

Chuyển CSDL sang EC2 trên AWS
    → rehost
        ↓
    Chuyển sang RDS (dịch vụ quản lý)
    → replatform
        ↓
    Chuyển sang DynamoDB (đổi mô hình
      dữ liệu, viết lại truy vấn)
    → refactor

⚠ Và điều làm replatform hấp dẫn:

Công sức: gần bằng rehost
    → không viết lại mã
        ↓
    Lợi ích: gần bằng refactor
    → hết việc vá lỗi, sao lưu,
      chuyển đổi thủ công
        ↓
    Tỷ lệ lợi ích trên công sức tốt nhất
      trong bảy chiến lược

Chuyển CSDL bằng DMS:

aws dms create-replication-task \
  --replication-task-identifier chuyen-sang-rds \
  --migration-type full-load-and-cdc \
  --source-endpoint-arn <arn-tai-cho> \
  --target-endpoint-arn <arn-rds> \
  --replication-instance-arn <arn-instance>

Triển khai ứng dụng lên Beanstalk:

eb init ung-dung-web --platform "Corretto 21" \
  --region ap-southeast-1
eb create moi-truong-san-xuat \
  --elb-type application --envvars DB_HOST=<endpoint-rds>

⚠ Đừng để Beanstalk quản lý CSDL:

Beanstalk tạo được RDS trong môi trường
    → nhưng xoá môi trường là XOÁ CSDL
        ↓
    Luôn tạo RDS RIÊNG bên ngoài
    → chỉ truyền endpoint vào qua biến
      môi trường

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bỏ hẳn việc vá lỗi và sao lưu thủ công | | | Multi-AZ chỉ bằng một cờ | | | Không phải viết lại ứng dụng | |

⚠ Nhưng replatform vẫn có việc phải làm:

RDS không cho quyền truy cập
  hệ điều hành
    → mọi thứ dựa vào script chạy trên
      máy chủ CSDL phải làm lại
        ↓
    Ví dụ: job cron sao lưu tự viết,
      công cụ giám sát cài trên máy
    → thay bằng cơ chế của RDS

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

  • **C. Rehost — đây là phương án gần nhất và cũng là chiến lược ít công sức, nhưng rehost nghĩa là chuyển nguyên trạng lên EC2 mà không dùng dịch vụ quản lý; đề nói rõ mục tiêu là giảm thời gian quản lý CSDL, tức là có đổi nền tảng.
  • **B. Refactor / Re-architect — đòi viết lại ứng dụng theo kiến trúc cloud; đề không nhắc gì tới việc sửa mã.
  • **A. Repurchase — nghĩa là bỏ hệ thống hiện có và mua giải pháp SaaS; đề vẫn giữ nguyên ứng dụng.

Ghi nhớ

⚠ Bảy chiến lược 7R — bảng phải thuộc: | Chiến lược | Nghĩa | Ví dụ | |---|---|---| | Retire | bỏ hẳn | máy chủ không ai dùng | | Retain | giữ tại chỗ | hệ thống sắp thay thế | | Rehost | chuyển nguyên | VM sang EC2 bằng MGN | | Relocate | chuyển nền ảo hoá | VMware sang VMware Cloud | | Repurchase | đổi sang SaaS | CRM tự viết sang Salesforce | | Replatform | đổi nền tảng, giữ mã | MySQL sang RDS | | Refactor | viết lại | monolith sang serverless |

Từ khoá nhận diện:

"managed service, no code changes" → replatform "lift and shift, as-is" → rehost "rewrite, cloud-native" → refactor "replace with SaaS" → repurchase "no longer used" → retire

⚠ Retire thường là chiến lược sinh lời nhất:

Khảo sát điển hình: 10-20% máy chủ
  không còn ai dùng
        ↓
    Application Discovery Service cho thấy
      máy nào không có kết nối mạng nào
    → tắt, tiết kiệm ngay lập tức

Ba lưu ý về replatform CSDL: | Lưu ý | Chi tiết | |---|---| | Cùng engine thì DMS đủ | | | Đổi engine thì cần SCT chuyển schema | | | Kiểm tra tính năng RDS không hỗ trợ | |

⚠ Ba tính năng RDS không hỗ trợ hay gây bất ngờ:

Truy cập hệ điều hành
Oracle RAC
Vài extension và plugin cụ thể
        ↓
    Kiểm TRƯỚC khi cam kết
    → RDS Custom lấp một phần khoảng trống

Ba lưu ý về Elastic Beanstalk: | Lưu ý | Chi tiết | |---|---| | Tự dựng ASG, ALB, health check | | | Chỉ trả tiền tài nguyên bên dưới | | | Tuỳ biến bằng .ebextensions | |

Ba lưu ý về đo lợi ích: | Lưu ý | Chi tiết | |---|---| | So chi phí trước và sau, gồm cả nhân lực | | | Migration Evaluator dựng luận chứng | | | Compute Optimizer tinh chỉnh sau khi lên | |

⚠ Chi phí nhân lực thường bị bỏ khỏi phép so sánh:

Chỉ so tiền hạ tầng
    → cloud có khi đắt hơn
        ↓
    Cộng thời gian vá lỗi, sao lưu,
      trực đêm, thay đĩa hỏng
    → bức tranh khác hẳn

Ba lưu ý về thứ tự di chuyển: | Lưu ý | Chi tiết | |---|---| | Bắt đầu với ứng dụng ít rủi ro | | | Di chuyển cả cụm phụ thuộc cùng lúc | | | Giữ đường lui trong vài tuần đầu | |

⚠ Chia nhầm đợt gây độ trễ khủng khiếp:

Ứng dụng lên cloud, CSDL còn tại chỗ
    → mỗi truy vấn đi vòng qua
      Direct Connect
        ↓
    Trang cần 50 truy vấn
    → cộng dồn thành vài giây
    → di chuyển cả cụm cùng lúc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So hiệu năng trước và sau | | | Kiểm sao lưu tự động đã chạy | | | Diễn tập chuyển đổi Multi-AZ | |

Và một lời khuyên: hãy chọn replatform làm mặc định và chỉ lệch khỏi nó khi có lý do cụ thể. Rehost giữ nguyên mọi gánh nặng vận hành mà bạn vừa trả tiền để thoát khỏi, còn refactor tiêu tốn hàng tháng công sức cho lợi ích mà phần lớn hệ thống không thật sự cần.

Câu 129 Domain - Continuous Improvement for Existing Solutions

A company has a hybrid cloud architecture where their on-premises data center and VPC are connected via multiple AWS Direct Connect ports in a single Link Aggregation Group (LAG). They have an on-premises patch management system that automatically applies the patches to the operating systems of their servers and file systems. You were given a task to synchronize the patch baselines being used on-premises to all of the EC2 instances in your VPC, as well as to automate the patching schedule.

Which of the following methods should you implement to meet the above requirement with the LEAST amount of effort?

  1. A

    Use AWS Systems Manager Session Manager to manage and deploy the security patches of your EC2 instances based on the patch baselines from your on-premises data center. Automate the patching schedule by using the AWS Systems Manager Maintenance Windows.
  2. B

    Use AWS Systems Manager Patch Manager to manage and deploy the security patches of your EC2 instances based on the patch baselines from your on-premises data center. Install the SSM Agent to all of your instances and automate the patching schedule by using AWS Systems Manager Maintenance Windows.
  3. C

    Use the AWS Systems Manager State Manager to automate the process of keeping your Amazon EC2 and hybrid infrastructure in a state that you define, which includes the OS patches that should be applied in each EC2 instance. Automate the patching schedule by using AWS Systems Manager Distributor, to package and distribute the required patches to your instances.
  4. D

    Use AWS Systems Manager Patch Manager to manage and deploy the security patches of your EC2 instances based on the patch baselines from your on-premises data center. Automate the patching schedule by setting up scheduled jobs using AWS Lambda and AWS Systems Manager Run Command.
Xem giải thích

Đáp án

**B — Dùng Systems Manager Patch Manager quản lý và triển khai bản vá theo patch baseline lấy từ trung tâm dữ liệu, cài SSM Agent lên mọi instance, và tự động hoá lịch vá bằng Systems Manager Maintenance Windows.

Vì sao đúng

Đề nêu ba việc, và phương án này là phương án duy nhất khớp cả ba: | Việc | Cách đáp ứng | |---|---| | Đồng bộ patch baseline từ tại chỗ | Patch Manager nhận baseline tuỳ chỉnh | | Vá tự động cho EC2 | Patch Manager | | Tự động hoá LỊCH vá | Maintenance Windows |

⚠ Patch Manager và Maintenance Windows là cặp đi cùng nhau:

Patch Manager: VÁ CÁI GÌ
    → baseline quyết định bản vá nào
      được duyệt
        ↓
    Maintenance Windows: VÁ KHI NÀO
    → cửa sổ thời gian, mức đồng thời,
      ngưỡng lỗi
        ↓
    Thiếu một trong hai: hoặc không có
      quy tắc, hoặc không có lịch

Baseline khớp với quy định tại chỗ:

aws ssm create-patch-baseline \
  --name baseline-dong-bo-tai-cho \
  --operating-system AMAZON_LINUX_2 \
  --approval-rules 'PatchRules=[{
    PatchFilterGroup={PatchFilters=[
      {Key=CLASSIFICATION,Values=[Security,Bugfix]},
      {Key=SEVERITY,Values=[Critical,Important]}]},
    ApproveAfterDays=7, ComplianceLevel=CRITICAL}]' \
  --approved-patches KB5001234 \
  --rejected-patches KB5009999

⚠ Hai danh sách tường minh là cách "đồng bộ" baseline tại chỗ:

`approved-patches`: bản vá nội bộ đã duyệt
`rejected-patches`: bản vá đã bị cấm
  vì gây lỗi trên hệ thống của công ty
        ↓
    Đây chính là nội dung mà baseline
      tại chỗ mang theo

Cửa sổ bảo trì:

aws ssm create-maintenance-window \
  --name cua-so-va-hang-tuan \
  --schedule "cron(0 3 ? * SUN *)" \
  --schedule-timezone "Asia/Ho_Chi_Minh" \
  --duration 4 --cutoff 1 --allow-unassociated-targets

Đăng ký việc vá vào cửa sổ:

aws ssm register-task-with-maintenance-window \
  --window-id mw-abc --task-type RUN_COMMAND \
  --task-arn AWS-RunPatchBaseline \
  --targets Key=tag:MoiTruong,Values=SanXuat \
  --max-concurrency "25%" --max-errors "5%" \
  --task-invocation-parameters \
    '{"RunCommand":{"Parameters":{"Operation":["Install"]}}}'

⚠ max-concurrency và max-errors là hai tham số bảo vệ:

Vá 25% một lúc
    → hơn 5% lỗi thì DỪNG
        ↓
    Một bản vá hỏng không hạ
      toàn bộ đội máy
    → phần còn lại vẫn phục vụ

⚠ Và cutoff bảo đảm việc đang chạy được hoàn tất:

Cửa sổ 4 giờ, cutoff 1 giờ
    → giờ cuối không nhận việc mới
        ↓
    Máy đang vá dở có thời gian xong
    → không bị cắt giữa chừng

Ba điều kiện tiên quyết của SSM — thiếu một là không chạy: | Điều kiện | Chi tiết | |---|---| | SSM Agent đang chạy | AMI của Amazon có sẵn | | Instance profile có AmazonSSMManagedInstanceCore | | | Có đường tới endpoint SSM | Internet hoặc VPC endpoint |

⚠ Ba VPC endpoint cần cho subnet riêng tư:

com.amazonaws.<vung>.ssm
com.amazonaws.<vung>.ssmmessages
com.amazonaws.<vung>.ec2messages
        ↓
    Thiếu: instance KHÔNG hiện trong
      Fleet Manager
    → và không có thông báo lỗi rõ ràng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cùng bộ quy tắc cho cả tại chỗ lẫn cloud | | | Có báo cáo tuân thủ vá lỗi sẵn | | | Không phải viết và bảo trì script nào | |

⚠ Và SSM quản lý được luôn máy chủ tại chỗ:

aws ssm create-activation \
  --default-instance-name may-tai-cho \
  --iam-role SSMServiceRole --registration-limit 100

Hybrid activation: cài agent lên máy
  ở trung tâm dữ liệu
        ↓
    MỘT công cụ vá cho cả hai môi trường
    → đây là điều đề thật sự mong muốn

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

  • **D. Dùng Patch Manager nhưng tự động hoá lịch bằng Lambda + Run Command — đây là phương án gần nhất và Patch Manager hoàn toàn đúng, nhưng tự viết Lambda để lên lịch là làm lại đúng thứ Maintenance Windows đã có sẵn; trái với yêu cầu "ít công sức nhất".
  • **A. Dùng Session Manager để quản lý và triển khai bản vá — Session Manager là công cụ mở phiên shell, nó không có khái niệm patch baseline hay tuân thủ vá lỗi.
  • **C. Dùng State Manager cho việc vá và Distributor để lên lịch — State Manager giữ cấu hình ở trạng thái mong muốn, còn Distributor phân phối gói phần mềm; cả hai đều không phải công cụ vá hệ điều hành, và Distributor không lên lịch.

Ghi nhớ

⚠ Sáu năng lực của Systems Manager hay bị lẫn — bảng phải thuộc: | Năng lực | Việc | |---|---| | Patch Manager | vá hệ điều hành theo baseline | | Maintenance Windows | lịch chạy việc bảo trì | | Run Command | chạy lệnh một lần trên nhiều máy | | State Manager | giữ cấu hình ở trạng thái mong muốn | | Session Manager | mở shell không cần SSH | | Distributor | đóng gói và phân phối phần mềm |

Từ khoá nhận diện:

"automate OS patching" → Patch Manager "schedule maintenance" → Maintenance Windows "shell access without bastion" → Session Manager "keep configuration consistent" → State Manager

⚠ Session Manager thay hẳn bastion host:

aws ssm start-session --target i-abc

Không cần cổng 22 mở
    → không cần khoá SSH
    → không cần bastion host
        ↓
    Và mọi phiên đều ghi log được
      vào S3 hoặc CloudWatch

Ba lưu ý về patch baseline: | Lưu ý | Chi tiết | |---|---| | Mỗi hệ điều hành một baseline | | | ApproveAfterDays chờ bản vá ổn định | | | Patch group gắn baseline theo tag | |

⚠ Patch group là cách áp baseline khác nhau cho từng môi trường:

aws ssm register-patch-baseline-for-patch-group \
  --baseline-id pb-abc --patch-group "SanXuat"

Tag `Patch Group = SanXuat` trên instance
    → dùng baseline thận trọng
      (ApproveAfterDays=14)
        ↓
    Tag `Patch Group = Dev`
    → baseline nhanh (ApproveAfterDays=0)
    → phát hiện bản vá hỏng ở Dev trước

Ba lưu ý về tuân thủ: | Lưu ý | Chi tiết | |---|---| | describe-instance-patch-states xem trạng thái | | | Đẩy dữ liệu tuân thủ sang Config | | | Cảnh báo khi tỷ lệ tuân thủ giảm | |

aws ssm describe-instance-patch-states \
  --instance-ids i-abc \
  --query 'InstancePatchStates[].[InstanceId,MissingCount,FailedCount]'

Ba lưu ý về vá an toàn: | Lưu ý | Chi tiết | |---|---| | Chụp ảnh EBS trước khi vá | | | Vá theo đợt, không vá toàn bộ cùng lúc | | | Kiểm thử ở môi trường thấp trước | |

Ba lưu ý về AMI thay vì vá tại chỗ: | Lưu ý | Chi tiết | |---|---| | EC2 Image Builder dựng AMI đã vá | | | Thay máy thay vì sửa máy | | | Mọi máy giống hệt nhau | |

⚠ Đây là hướng tốt hơn cho hệ thống có ASG:

Vá tại chỗ: mỗi máy có lịch sử riêng
    → sau một năm không máy nào giống nhau
        ↓
    Thay AMI: dựng ảnh mới đã vá
    → rolling update cả đội
    → luôn dựng lại được từ đầu

Ba lưu ý về máy chủ tại chỗ: | Lưu ý | Chi tiết | |---|---| | Hybrid activation để đăng ký | | | Cùng baseline với EC2 | | | Tính phí theo instance quản lý | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem báo cáo tuân thủ sau một cửa sổ | | | Kiểm bản vá thật sự được cài trên máy | | | Thử một baseline mới ở môi trường Dev | |

Và một lời khuyên: hãy dùng patch group để môi trường Dev nhận bản vá trước môi trường sản xuất vài ngày. Bản vá hỏng là chuyện có thật, và bạn muốn phát hiện nó ở nơi không ai để ý chứ không phải lúc ba giờ sáng chủ nhật trên đội máy đang phục vụ khách hàng.

Câu 130 Domain - Continuous Improvement for Existing Solutions

A clothing company is using a proprietary e-commerce platform as their online shopping website. The e-commerce platform is hosted on a fleet of on-demand EC2 instances that are launched in a public subnet. Aside from acting as web servers, these EC2 instances also fetch updates and critical security patches from the Internet. The Solutions Architect was tasked to ensure that the instances can only initiate outbound requests to specific URLs provided by the proprietary e-commerce platform while accepting all inbound requests from the online shoppers.

Which of the following is the BEST solution that the Architect should implement in this scenario?

  1. A Create a new NAT Instance in your VPC. Place the EC2 instances to the private subnet and connect it to a NAT Instance which will handle the outbound URL restriction.
  2. B Implement a Network ACL to all specific URLs by the e-commerce platform with an implicit deny rule.
  3. C Create a new NAT Gateway in your VPC. Place the EC2 instances to the private subnet and connect it to a NAT Gateway which will handle the outbound URL restriction.
  4. D

    In your VPC, launch a new web proxy server that only allows outbound access to the URLs provided by the proprietary e-commerce platform.
Xem giải thích

Đáp án

**D — Dựng một máy chủ proxy web trong VPC, chỉ cho phép đi ra tới đúng danh sách URL của nền tảng thương mại điện tử.

Vì sao đúng

Đề đặt ra một yêu cầu rất cụ thể: giới hạn đi ra theo URL, và chỉ proxy làm được điều đó: | Cơ chế | Lọc theo được | |---|---| | Security group | IP, cổng, giao thức | | Network ACL | IP, cổng, giao thức | | NAT gateway | KHÔNG lọc gì cả | | Proxy web | TÊN MIỀN và ĐƯỜNG DẪN |

⚠ Vì sao lọc theo IP không dùng được ở đây:

URL của nền tảng trỏ tới CDN
    → IP đổi liên tục, hàng trăm địa chỉ
        ↓
    Danh sách IP hôm nay đúng
    → tuần sau nhà cung cấp đổi CDN
    → cập nhật liên tục và vẫn sai

⚠ Và proxy nhìn thấy thứ mà tầng mạng không thấy:

HTTP: đọc được header `Host` và đường dẫn
HTTPS: đọc được `SNI` trong lúc bắt tay TLS
        ↓
    Đủ để quyết định cho đi hay chặn
    → mà không cần giải mã nội dung

Cấu hình Squid tối thiểu:

acl mien_cho_phep dstdomain .nencangthuongmai.com
acl mien_cho_phep dstdomain .cdn-nencang.net
acl SSL_ports port 443

http_access allow mien_cho_phep
http_access deny all
http_port 3128

⚠ Kiến trúc đặt proxy:

EC2 (subnet công khai, nhận yêu cầu vào)
    → biến môi trường HTTP_PROXY
      trỏ tới proxy
        ↓
    Proxy (subnet riêng)
    → NAT gateway → Internet
        ↓
    Bỏ tuyến mặc định 0.0.0.0/0
      khỏi bảng định tuyến của EC2
    → chỉ đi ra được QUA proxy

Ép dùng proxy bằng cấu hình hệ thống:

cat >> /etc/environment <<'EOF'
http_proxy=http://proxy.noi-bo:3128
https_proxy=http://proxy.noi-bo:3128
no_proxy=169.254.169.254,localhost,.amazonaws.com
EOF

⚠ no_proxy phải có 169.254.169.254:

Instance metadata đi qua proxy
    → SDK không lấy được credential
      của vai trò IAM
        ↓
    Ứng dụng đột nhiên mất quyền
      gọi mọi dịch vụ AWS

⚠ Nhưng phải hiểu giới hạn: proxy dựa vào sự HỢP TÁC của client:

Ứng dụng cố tình bỏ qua biến proxy
    → và bảng định tuyến vẫn có
      đường ra trực tiếp
        ↓
    Đi thẳng, không qua proxy
        ↓
    Phải GỠ tuyến mặc định
    → proxy mới là lối ra DUY NHẤT

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lọc được theo tên miền, không phải IP | | | Ghi log mọi kết nối đi ra | | | Sửa danh sách không phải sửa hạ tầng | |

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

  • **A. Đặt EC2 vào subnet riêng và nối qua NAT instance để "xử lý giới hạn URL" — đây là phương án gần nhất và NAT instance thực chất là một EC2, cài proxy lên đó được, nhưng NAT tự nó không lọc URL; ngoài ra đề nói EC2 phải nhận lưu lượng vào từ người mua hàng, chuyển vào subnet riêng là hỏng chức năng đó.
  • **C. Dùng NAT gateway để giới hạn URL — NAT gateway là dịch vụ quản lý, không có tính năng lọc nào.
  • **B. Dùng Network ACL cho các URL cụ thể — NACL làm việc ở tầng 3/4, nó không hiểu URL.

Ghi nhớ

⚠ Bốn cách kiểm soát lưu lượng đi ra — bảng phải thuộc: | Cách | Lọc theo | Vận hành | |---|---|---| | Security group | IP, cổng | AWS lo | | NACL | IP, cổng, có deny | AWS lo | | Proxy web (Squid) | tên miền, đường dẫn | bạn lo | | AWS Network Firewall | tên miền, nội dung, luật Suricata | AWS lo |

⚠ Network Firewall là câu trả lời hiện đại cho bài toán này:

Cùng khả năng lọc theo tên miền
    → nhưng là dịch vụ quản lý
    → không phải tự vá và tự lo HA
        ↓
    Ra mắt sau khi mẫu proxy phổ biến
    → đề này viết theo cách làm cũ

Luật lọc tên miền của Network Firewall:

{"RulesSourceList": {
  "Targets": [".nencangthuongmai.com"],
  "TargetTypes": ["TLS_SNI", "HTTP_HOST"],
  "GeneratedRulesType": "ALLOWLIST"}}

Từ khoá nhận diện:

"restrict outbound to specific URLs" → proxy hoặc Network Firewall "restrict outbound to specific IPs" → security group "deny a specific IP" → NACL "inspect traffic with third-party appliance" → GWLB

Ba lưu ý về proxy tự dựng: | Lưu ý | Chi tiết | |---|---| | Đặt sau ALB nội bộ cho sẵn sàng cao | | | Đặt trong ASG để tự thay máy hỏng | | | Trải nhiều AZ | |

⚠ Proxy một máy là điểm hỏng chí tử:

Proxy chết
    → MỌI kết nối đi ra dừng
        ↓
    Không cập nhật được, không gọi
      được API bên ngoài
    → luôn dựng ít nhất hai

Ba lưu ý về VPC endpoint: | Lưu ý | Chi tiết | |---|---| | Lưu lượng tới dịch vụ AWS không cần qua proxy | | | Gateway endpoint cho S3 và DynamoDB miễn phí | | | Interface endpoint cho các dịch vụ khác | |

⚠ Dùng endpoint giảm tải cho proxy rất nhiều:

Không có endpoint: gọi S3 cũng đi
  qua proxy rồi ra Internet
        ↓
    Có gateway endpoint: đi thẳng
      trong mạng AWS
    → nhanh hơn, rẻ hơn, và proxy
      chỉ lo lưu lượng thật sự ra ngoài

Ba lưu ý về HTTPS: | Lưu ý | Chi tiết | |---|---| | Proxy đọc được SNI mà không giải mã | | | Chặn theo tên miền là đủ cho hầu hết yêu cầu | | | Giải mã (MITM) cần cài CA lên client | |

⚠ Giải mã TLS ở proxy là quyết định lớn:

Muốn lọc theo ĐƯỜNG DẪN trong HTTPS
    → phải giải mã
    → phải cài CA riêng lên mọi client
        ↓
    Tăng đáng kể độ phức tạp và rủi ro
    → chỉ làm khi thật sự bắt buộc

Ba lưu ý về ghi log: | Lưu ý | Chi tiết | |---|---| | Log của proxy cho biết ai gọi đi đâu | | | Đẩy lên CloudWatch Logs để giữ lâu | | | Cảnh báo khi có yêu cầu bị chặn nhiều | |

Ba lưu ý về bảng định tuyến: | Lưu ý | Chi tiết | |---|---| | Gỡ tuyến mặc định khỏi subnet ứng dụng | | | Chỉ subnet proxy có đường ra | | | Kiểm bằng Reachability Analyzer | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl tới URL được phép — phải thông | | | curl tới URL khác — phải bị chặn | | | Bỏ biến proxy rồi thử — cũng phải bị chặn | |

Và một lời khuyên: hãy kiểm chứng bằng cách bỏ biến môi trường proxy rồi thử lại. Nếu vẫn ra được Internet thì bạn chưa có kiểm soát nào cả — bạn chỉ có một gợi ý mà mọi ứng dụng đều được tự do bỏ qua.