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

Tìm thấy 1221 câu.

Câu 101 Chọn nhiều đáp án Domain - Design for New Solutions

An international insurance company has clients all across the globe. The company has financial files that are stored in an Amazon S3 bucket which is behind CloudFront. At present, their clients can access their data by directly using an S3 URL or using their CloudFront distribution. The company wants to deliver their content to a specific client in California and they need to make sure that only that client can access the data.

Which of the following options is a valid solution that meets the above requirements? (Select TWO.)

  1. A

    Create a new S3 bucket in US West (N. California) region and upload the files. Set up an origin access control (OAC) and give it permission to read the files in the bucket. Enable HTTPS in your CloudFront distribution.
  2. B

    Use CloudFront signed URLs to ensure that only their client can access the files. Create an origin access control (OAC) and give it permission to read the files in the bucket. Remove permission to use Amazon S3 URLs to read the files for anyone else.
  3. C

    Create a new S3 bucket in US West (N. California) region and upload the files. Use S3 pre-signed URLs to ensure that only their client can access the files. Remove permission to use Amazon S3 URLs to read the files for anyone else.
  4. D

    Use CloudFront signed URLs to ensure that only their client can access the files. Enable field-level encryption in your CloudFront distribution.
  5. E

    Use CloudFront Signed Cookies to ensure that only their client can access the files. Enable HTTPS in your CloudFront distribution.
Xem giải thích

Đáp án

**B và C — Dùng CloudFront signed URL kèm origin access control (OAC) và gỡ quyền đọc bằng URL S3 của mọi người khác; hoặc tạo bucket mới ở US West (N. California), dùng S3 pre-signed URL và gỡ quyền đọc trực tiếp.

Vì sao đúng

Đề nêu hai yêu cầu, và cả hai phương án đều thoả: | Yêu cầu | Signed URL + OAC | Pre-signed URL | |---|---|---| | Chỉ một khách hàng truy cập được | URL ký, có hạn | URL ký, có hạn | | Chặn đường S3 trực tiếp | OAC + bucket policy | gỡ quyền công khai |

⚠ Hai cơ chế ký URL — bảng phải thuộc: | Tiêu chí | CloudFront signed URL | S3 pre-signed URL | |---|---|---| | Ai ký | key pair của CloudFront | credential IAM | | Đi qua | mạng biên CloudFront | thẳng tới S3 | | Giới hạn IP | CÓ | không | | Thời hạn tối đa | tuỳ đặt | 7 ngày (SigV4) |

Đề nói khách hàng ở California
    → CloudFront signed URL giới hạn
      được theo dải IP
    → đây là lợi thế của phương án B

Chính sách tuỳ chỉnh giới hạn IP:

{"Statement": [{
  "Resource": "https://tenmien.com/tai-lieu/*",
  "Condition": {
    "DateLessThan": {"AWS:EpochTime": 1725062400},
    "IpAddress": {"AWS:SourceIp": "203.0.113.0/24"}}}]}

⚠ OAC là cơ chế thay cho OAI đã cũ: | Tiêu chí | OAI (cũ) | OAC (nay) | |---|---|---| | Hỗ trợ SSE-KMS | không | CÓ | | Hỗ trợ mọi Region | hạn chế | có | | Hỗ trợ POST/PUT | không | có |

Tài liệu mới đều dùng OAC
    → OAI vẫn chạy nhưng không nên
      dùng cho thiết kế mới

Bucket policy chỉ cho CloudFront đọc:

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::tai-lieu-tai-chinh/*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn":
     "arn:aws:cloudfront::111122223333:distribution/E1ABC"}}}

Sinh pre-signed URL:

import boto3
s3 = boto3.client('s3')
url = s3.generate_presigned_url('get_object',
    Params={'Bucket': 'tai-lieu', 'Key': 'bao-cao.pdf'},
    ExpiresIn=3600)

⚠ Pre-signed URL kế thừa quyền của người ký:

Người ký không có quyền đọc object
    → URL sinh ra vẫn hợp lệ về hình thức
    → nhưng dùng thì bị từ chối
        ↓
    Và URL hết hiệu lực nếu credential
      của người ký bị thu hồi trước hạn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không cần tài khoản AWS cho khách hàng | | | URL tự hết hạn | | | Không lộ bucket ra công khai | |

⚠ Đặt bucket ở California là tối ưu phụ, không phải điều kiện:

Bucket gần khách hàng: giảm độ trễ
      cho đường S3 trực tiếp
        ↓
    Nhưng với CloudFront thì vị trí
      bucket ít quan trọng hơn
    → vì nội dung được cache ở biên

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

  • **E. Dùng CloudFront signed cookie và bật HTTPS — đây là phương án gần nhất và signed cookie là cơ chế hợp lệ, nhưng nó dành cho việc cấp quyền nhiều tệp cùng lúc khi không đổi được URL; đề nói về việc giao các tệp cụ thể cho một khách hàng, và phương án này thiếu bước chặn đường S3 trực tiếp.
  • **A. Tạo bucket mới ở California, đặt OAC và bật HTTPS — có OAC chặn đường S3 nhưng không có cơ chế giới hạn AI được xem; ai có URL CloudFront đều tải được.
  • **D. Dùng signed URL và bật field-level encryption — mã hoá ở mức trường dành cho dữ liệu POST lên từ biểu mẫu, không liên quan tới việc giới hạn người tải tệp.

Ghi nhớ

⚠ Ba cách hạn chế truy cập nội dung CloudFront: | Cách | Dùng khi | |---|---| | Signed URL | từng tệp riêng lẻ | | Signed cookie | nhiều tệp, không đổi URL được | | Geo restriction | chặn theo quốc gia |

Từ khoá nhận diện:

"only one specific client can access" → signed URL "entire subscriber content library" → signed cookie "block a country" → geo restriction "prevent direct S3 URL access" → OAC + bucket policy

Ba lưu ý về signed URL của CloudFront: | Lưu ý | Chi tiết | |---|---| | Cần key group và public key | | | Chính sách canned đơn giản, custom linh hoạt | | | Chỉ custom mới giới hạn được IP | |

aws cloudfront create-public-key --public-key-config \
  'CallerReference=k1,Name=khoa-ky,EncodedKey=<pem>'
aws cloudfront create-key-group --key-group-config \
  'Name=nhom-khoa,Items=[<id-khoa>]'

⚠ Trước đây phải dùng CloudFront key pair của tài khoản gốc:

Cách cũ: root account tạo key pair
    → không xoay được, không phân quyền
        ↓
    Nay: public key + key group
    → xoay khoá được, không cần root

Ba lưu ý về pre-signed URL: | Lưu ý | Chi tiết | |---|---| | Tối đa 7 ngày với SigV4 | | | Vai trò tạm giới hạn thêm theo phiên | | | Không thu hồi được URL đã phát | |

⚠ "Không thu hồi được" là rủi ro phải cân nhắc:

URL đã sinh, đặt hạn 7 ngày
    → phát nhầm người
        ↓
    Cách duy nhất: xoá object,
      đổi khoá, hoặc thu hồi credential
      của người ký
        ↓
    Nên đặt hạn NGẮN nhất dùng được

Ba lưu ý về OAC: | Lưu ý | Chi tiết | |---|---| | Ký yêu cầu bằng SigV4 tới S3 | | | Hỗ trợ bucket mã hoá SSE-KMS | | | Bucket phải chặn mọi truy cập công khai | |

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 ảnh hưởng OAC | | | Nên bật mặc định cho mọi bucket | |

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

Ba lưu ý về ghi nhận truy cập: | Lưu ý | Chi tiết | |---|---| | CloudFront standard log vào S3 | | | Data event của CloudTrail cho S3 | | | Biết ai tải gì, lúc nào | |

Ba lưu ý về mã hoá: | Lưu ý | Chi tiết | |---|---| | SSE-KMS cho tài liệu tài chính | | | Bật Bucket Key giảm chi phí KMS | | | Bắt buộc HTTPS bằng bucket policy | |

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": "arn:aws:s3:::tai-lieu/*",
 "Condition": {"Bool": {"aws:SecureTransport": "false"}}}

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử URL S3 trực tiếp — phải 403 | | | Thử URL đã hết hạn — phải bị từ chối | | | Thử từ IP ngoài dải cho phép | |

Và một lời khuyên: hãy đặt thời hạn URL ngắn nhất mà quy trình chịu được. Một URL ký hạn bảy ngày về bản chất là một tệp công khai trong bảy ngày — vì bất cứ ai nhận được đường link đó, dù qua đường nào, đều dùng được nó.

Câu 102 Domain - Design Solutions for Organizational Complexity

A manufacturing company is developing a system to monitor and analyze equipment performance using IoT devices. They plan to use AWS IoT Core to collect data from 500 sensors across their production lines.

The collected data must be enriched with additional context before being stored in an Amazon S3 data lake. Sensor data is collected every 10 seconds. The enriched data should be available in the data lake within 20 minutes of collection.

Which approach would best fulfill these requirements in the MOST cost-effective and scalable manner?

  1. A

    Use AWS IoT Core Basic Ingest to forward sensor data to Amazon Kinesis Data Streams. Deploy an Auto Scaling group of EC2 instances to enrich and process the data, and use the S3 PutObject API to upload the processed data in Amazon S3.
  2. B

    Ingest data over MQTT protocol using AWS IoT Core. Use an IoT rule action to trigger an AWS Step Functions workflow that enriches data using an AWS Lambda function and delivers results to Amazon S3.
  3. C

    Use AWS IoT Core Basic Ingest for data collection. Configure an AWS IoT rule action to send data to Amazon Data Firehose. Set up Data Firehose with an AWS Lambda function for data enrichment and a buffer interval of 300 seconds.
  4. D

    Use AWS IoT Core to send data to an Amazon Timestream table for temporary storage. Deploy an AWS Lambda function to query Timestream, enrich the data, and upload it to Amazon S3.
Xem giải thích

Đáp án

**C — Dùng AWS IoT Core Basic Ingest để thu thập, cấu hình IoT rule action gửi dữ liệu sang Amazon Data Firehose, và đặt Firehose có Lambda làm giàu dữ liệu với buffer interval 300 giây.

Vì sao đúng

Đề cho đủ số liệu để kiểm chứng từng ràng buộc: | Ràng buộc | Phương án C đáp ứng | |---|---| | 500 cảm biến, 10 giây/lần | 50 thông điệp/giây — Firehose thừa sức | | Làm giàu dữ liệu | Lambda transformation của Firehose | | Có mặt trong data lake trong 20 phút | buffer 300 giây = 5 phút | | Rẻ và co giãn nhất | không máy chủ nào phải quản |

⚠ Basic Ingest bỏ qua message broker và tiết kiệm đáng kể:

Đường thường: thiết bị → message broker
  → rule engine → đích
    → tính phí CẢ kết nối, tin nhắn VÀ rule
        ↓
    Basic Ingest: thiết bị → thẳng rule
    → BỎ chi phí messaging
    → khi không cần pub/sub giữa các thiết bị

Gửi qua Basic Ingest:

Chủ đề dành riêng:
  $aws/rules/<ten-rule>/<phan-tuy-y>
        ↓
    Thiết bị publish vào đó
    → rule chạy ngay, không qua broker

Tạo rule đẩy sang Firehose:

aws iot create-topic-rule --rule-name gui_sang_firehose \
  --topic-rule-payload '{
    "sql": "SELECT * FROM \"$aws/rules/gui_sang_firehose\"",
    "actions": [{"firehose": {
      "deliveryStreamName": "luong-cam-bien",
      "roleArn": "<arn-vai-tro>",
      "separator": "\n"}}]}'

⚠ Buffer của Firehose là chỗ đánh đổi độ trễ và chi phí:

Buffer nhỏ (60 giây): dữ liệu tới nhanh
    → nhiều tệp NHỎ trong S3
    → truy vấn Athena chậm và tốn
        ↓
    Buffer 300 giây: tệp lớn hơn
    → vẫn trong hạn 20 phút của đề
    → rẻ và hiệu quả hơn khi truy vấn

Lambda làm giàu trong Firehose:

import base64, json

def handler(su_kien, ngu_canh):
    ket_qua = []
    for ban_ghi in su_kien['records']:
        d = json.loads(base64.b64decode(ban_ghi['data']))
        d['tenDayChuyen'] = tra_cuu(d['maCamBien'])
        d['nguong'] = nguong_canh_bao(d['maCamBien'])
        ket_qua.append({
            'recordId': ban_ghi['recordId'],
            'result': 'Ok',
            'data': base64.b64encode(
                (json.dumps(d) + '\n').encode()).decode()})
    return {'records': ket_qua}

⚠ Ba giá trị result mà Lambda phải trả đúng: | Giá trị | Nghĩa | |---|---| | Ok | đã xử lý, ghi vào đích | | Dropped | cố ý bỏ, không ghi | | ProcessingFailed | lỗi, đưa vào tiền tố processing-failed/ |

Trả sai giá trị hoặc thiếu `recordId`
    → Firehose coi cả lô là lỗi
    → dữ liệu vào thư mục lỗi
      chứ không vào data lake

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có máy chủ nào phải vận hành | | | Firehose tự gom, nén và phân vùng | | | Chi phí theo lượng dữ liệu thật | |

⚠ Bật phân vùng động để Athena truy vấn hiệu quả:

{"DynamicPartitioningConfiguration": {"Enabled": true},
 "Prefix": "du-lieu/day-chuyen=!{partitionKeyFromQuery:dayChuyen}/nam=!{timestamp:yyyy}/thang=!{timestamp:MM}/ngay=!{timestamp:dd}/",
 "ErrorOutputPrefix": "loi/"}

Không phân vùng: Athena quét toàn bộ
    → truy vấn một ngày cũng đọc cả năm
        ↓
    Có phân vùng: chỉ đọc thư mục cần
    → nhanh hơn và rẻ hơn nhiều lần

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

  • **B. Dùng IoT rule kích hoạt Step Functions gọi Lambda rồi ghi S3 — đây là phương án gần nhất và hoàn toàn chạy được, nhưng Step Functions tính phí theo bước chuyển trạng thái: 50 thông điệp/giây là hơn 4 triệu lượt mỗi ngày, chi phí cao hơn Firehose rất nhiều mà không thêm giá trị gì.
  • **A. Đẩy vào Kinesis Data Streams rồi dùng đội EC2 trong ASG để làm giàu — phải quản lý máy chủ, phải tự viết consumer, và tự gọi PutObject; nhiều việc hơn hẳn.
  • **D. Ghi tạm vào Timestream rồi Lambda truy vấn và đẩy sang S3 — Timestream là CSDL chuỗi thời gian để truy vấn, dùng làm nơi trung chuyển là sai vai trò và tốn kém.

Ghi nhớ

⚠ Kinesis Data Streams và Data Firehose — bảng phải thuộc: | Tiêu chí | Data Streams | Data Firehose | |---|---|---| | Cần viết consumer | CÓ | không | | Độ trễ | dưới 1 giây | tối thiểu 60 giây | | Giữ lại và phát lại | có | không | | Đích | bất kỳ | S3, Redshift, OpenSearch, Splunk | | Biến đổi dữ liệu | tự viết | Lambda tích hợp sẵn |

Đích là S3 và độ trễ phút là đủ
    → Firehose, ít việc hơn hẳn
        ↓
    Cần xử lý dưới giây hoặc nhiều consumer
    → Data Streams

Từ khoá nhận diện:

"deliver to S3 with no code" → Firehose "enrich data in flight" → Lambda transformation của Firehose "sub-second processing" → Kinesis Data Streams "IoT without pub/sub" → Basic Ingest

Ba lưu ý về IoT Core: | Lưu ý | Chi tiết | |---|---| | Thiết bị xác thực bằng chứng chỉ X.509 | | | Rule engine dùng cú pháp giống SQL | | | Device Shadow giữ trạng thái khi thiết bị offline | |

⚠ Rule engine lọc được ngay tại nguồn:

SELECT maCamBien, nhietDo, apSuat
FROM '$aws/rules/loc_bat_thuong'
WHERE nhietDo > 80 OR apSuat < 10

Chỉ đẩy đi bản ghi đáng quan tâm
    → giảm chi phí ở mọi tầng phía sau

Ba lưu ý về Firehose: | Lưu ý | Chi tiết | |---|---| | Buffer theo kích thước HOẶC thời gian, cái nào tới trước | | | Nén GZIP, Snappy hoặc ZIP | | | Chuyển sang Parquet/ORC được | |

⚠ Chuyển sang Parquet giảm chi phí truy vấn rất nhiều:

JSON: Athena đọc toàn bộ mỗi cột
    ↓
Parquet: cột hoá, nén tốt
    → truy vấn 3 cột trong 50 cột
      chỉ đọc 3 cột
    → giảm dữ liệu quét hàng chục lần

Ba lưu ý về Lambda trong Firehose: | Lưu ý | Chi tiết | |---|---| | Kích thước lô tối đa 6 MB | | | Thời gian chạy nên dưới 1 phút | | | Bản ghi lỗi vào tiền tố riêng | |

Ba lưu ý về data lake: | Lưu ý | Chi tiết | |---|---| | Phân vùng theo thời gian và chiều hay lọc | | | Glue Crawler cập nhật catalog | | | Lifecycle chuyển dữ liệu cũ sang lớp rẻ | |

Ba lưu ý về chi phí IoT: | Lưu ý | Chi tiết | |---|---| | Tính theo phút kết nối và số tin nhắn | | | Basic Ingest bỏ phí messaging | | | Gộp nhiều số đo trong một tin nhắn | |

⚠ Gộp số đo là cách giảm chi phí lớn nhất:

Mỗi cảm biến gửi riêng mỗi 10 giây
    → 500 tin nhắn mỗi 10 giây
        ↓
    Gateway gom 10 cảm biến một tin
    → giảm 10 lần số tin nhắn
    → mà độ trễ không đổi đáng kể

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo thời gian từ cảm biến tới S3 | | | Kiểm tiền tố processing-failed/ có rỗng không | | | Truy vấn Athena xem trường làm giàu có đủ | |

Và một lời khuyên: hãy kiểm tra thư mục processing-failed/ ngay trong tuần đầu chạy. Firehose không báo lỗi khi Lambda trả sai định dạng — nó lặng lẽ chuyển bản ghi sang thư mục lỗi, và data lake trông vẫn hoạt động bình thường trong khi thiếu dữ liệu.

Câu 103 Domain - Design for New Solutions

A company has an Oracle Real Application Clusters (RAC) database on their on-premises data center which they want to migrate to AWS. The Chief Information Security Officer (CISO) instructed the solutions architects to automate the patch management process of the operating system in which the database runs, as well as to set up scheduled backups to comply with the company's disaster recovery plan.

Which of the following should the solutions architect implement to meet the company requirements with the least amount of effort?

  1. A

    Migrate the database to Amazon RDS which provides a multi-AZ failover feature for your RAC cluster. This will also reduce the RPO and RTO in the event of system failure since RDS offers features such as patch management and maintenance of the underlying host.
  2. B

    Migrate the database to a cluster of EBS-backed Amazon EC2 instances across multiple AZs. Automate the creation of EBS snapshots from EBS volumes of the EC2 instance by using Amazon Data Lifecycle Manager. Install the SSM Agent to the EC2 instance and automate the patch management process using AWS Systems Manager Patch Manager.
  3. C

    Migrate the database to Amazon Aurora and enable automated backups for your Aurora RAC cluster. Patching is automatically handled in Aurora during the system maintenance window.
  4. D

    Launch a Lambda function that would automate the creation of snapshots of the database in the EC2 instance. Use the CodeDeploy and CodePipeline service to automate the patch management process of the database.
Xem giải thích

Đáp án

**B — Chuyển CSDL sang cụm EC2 dùng EBS trải trên nhiều AZ, tự động chụp ảnh EBS bằng Amazon Data Lifecycle Manager, cài SSM Agent và tự động hoá vá lỗi bằng Systems Manager Patch Manager.

Vì sao đúng

Điểm quyết định nằm ở một sự thật về sản phẩm:

Amazon RDS KHÔNG hỗ trợ
  Oracle Real Application Clusters (RAC)
        ↓
    RAC cần lưu trữ dùng chung giữa nhiều node
      (Oracle ASM, shared storage)
    → RDS không cung cấp mô hình đó
        ↓
    Muốn giữ RAC: phải tự chạy trên EC2

Đây là lý do mọi phương án nhắc tới RDS hay Aurora đều sai.

⚠ Và "Aurora RAC cluster" trong phương án C là thứ KHÔNG tồn tại:

Aurora có cụm với writer và reader
    → nhưng đó KHÔNG phải RAC
        ↓
    Aurora là công nghệ riêng của AWS,
      tương thích MySQL/PostgreSQL
    → không chạy Oracle

Tự động chụp ảnh bằng Data Lifecycle Manager:

aws dlm create-lifecycle-policy \
  --description "Chup anh CSDL Oracle" \
  --state ENABLED --execution-role-arn <arn> \
  --policy-details '{
    "ResourceTypes": ["VOLUME"],
    "TargetTags": [{"Key":"SaoLuu","Value":"HangNgay"}],
    "Schedules": [{
      "Name": "hang-ngay",
      "CreateRule": {"Interval": 24, "IntervalUnit": "HOURS",
                     "Times": ["18:00"]},
      "RetainRule": {"Count": 30},
      "CopyTags": true}]}'

⚠ Nhưng ảnh chụp EBS của CSDL đang chạy cần một bước nữa:

Chụp volume trong lúc CSDL đang ghi
    → ảnh chụp "crash-consistent"
    → khôi phục được nhưng có thể
      phải phục hồi giao dịch dở
        ↓
    Đúng cách: đặt CSDL vào chế độ backup
      (`ALTER DATABASE BEGIN BACKUP`)
      hoặc đóng băng hệ thống tệp
      TRƯỚC khi chụp

Dùng Run Command để đóng băng trước khi chụp:

aws ssm send-command --document-name "AWS-RunShellScript" \
  --targets Key=tag:Vaitro,Values=CSDL \
  --parameters 'commands=["fsfreeze -f /oradata"]'

Vá lỗi bằng Patch Manager:

aws ssm create-patch-baseline --name baseline-oracle \
  --operating-system ORACLE_LINUX \
  --approval-rules 'PatchRules=[{
    PatchFilterGroup={PatchFilters=[
      {Key=CLASSIFICATION,Values=[Security]}]},
    ApproveAfterDays=7}]'

aws ssm create-maintenance-window --name cua-so-va \
  --schedule "cron(0 3 ? * SUN *)" --duration 4 --cutoff 1

⚠ Ba điều kiện tiên quyết của SSM — thiếu một là không chạy:

1. SSM Agent đang chạy
2. Instance profile có
   `AmazonSSMManagedInstanceCore`
3. Đường ra tới endpoint SSM
   (Internet hoặc VPC endpoint)
        ↓
    Thiếu bất kỳ cái nào: instance
      KHÔNG hiện trong Fleet Manager
    → và không có thông báo lỗi rõ ràng

Ba VPC endpoint cần cho subnet riêng tư: | Endpoint | Vai trò | |---|---| | ssm | kênh chính | | ssmmessages | Session Manager | | ec2messages | Run Command |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Giữ được RAC, không phải viết lại ứng dụng | | | Vá lỗi và sao lưu đều tự động | | | Trải nhiều AZ cho khả năng chịu lỗi | |

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

  • **A. Chuyển sang RDS với Multi-AZ cho cụm RAC — đây là phương án gần nhất và RDS thật sự tự lo vá lỗi và sao lưu, đúng như đề mong muốn, nhưng RDS không chạy được Oracle RAC; câu "Multi-AZ failover cho cụm RAC của bạn" mô tả một thứ không tồn tại.
  • **C. Chuyển sang Aurora và bật sao lưu tự động cho cụm Aurora RAC — Aurora không chạy Oracle, và không có khái niệm "Aurora RAC".
  • **D. Dùng Lambda chụp ảnh và CodeDeploy/CodePipeline để vá lỗi — CodeDeploy và CodePipeline là công cụ triển khai ứng dụng, không phải công cụ vá hệ điều hành; và Lambda tự viết là nhiều việc hơn DLM.

Ghi nhớ

⚠ Ba mức trách nhiệm khi chạy CSDL trên AWS — bảng phải thuộc: | Cách chạy | AWS lo | Bạn lo | |---|---|---| | Aurora | gần như mọi thứ | schema, truy vấn | | RDS | vá, sao lưu, chuyển đổi | schema, tinh chỉnh | | CSDL trên EC2 | phần cứng | HỌ ĐIỀU HÀNH, CSDL, sao lưu, HA |

Chọn EC2 khi có tính năng CSDL mà
  dịch vụ quản lý không hỗ trợ
        ↓
    Oracle RAC là ví dụ điển hình
    → đổi lại: nhận toàn bộ gánh nặng vận hành

Từ khoá nhận diện:

"Oracle RAC" → EC2, KHÔNG phải RDS "automate OS patching" → Patch Manager "automate EBS snapshots" → Data Lifecycle Manager hoặc AWS Backup "least effort, managed database" → RDS nếu tính năng cho phép

Ba tính năng Oracle mà RDS không hỗ trợ: | Tính năng | Ghi chú | |---|---| | Real Application Clusters (RAC) | cần chạy EC2 | | Automatic Storage Management (ASM) | | | Truy cập hệ điều hành trực tiếp | |

⚠ Nhưng RDS Custom for Oracle lấp một phần khoảng trống:

RDS Custom: có quyền truy cập
  hệ điều hành và CSDL
    → cài agent, sửa tham số hệ thống
        ↓
    Vẫn KHÔNG hỗ trợ RAC
    → nhưng lo được nhiều việc vận hành
      hơn EC2 thuần

Ba lưu ý về Data Lifecycle Manager: | Lưu ý | Chi tiết | |---|---| | Chọn volume theo tag | | | Đặt số bản giữ lại hoặc thời gian | | | Sao chép ảnh chụp sang Region khác | |

⚠ AWS Backup là lựa chọn rộng hơn DLM: | Tiêu chí | DLM | AWS Backup | |---|---|---| | Phạm vi | EBS, EC2 AMI | EBS, RDS, EFS, DynamoDB, FSx... | | Vault Lock chống xoá | không | CÓ | | Báo cáo tuân thủ | hạn chế | có |

Cần chống xoá bản sao lưu (ransomware)
    → AWS Backup với Vault Lock
      chế độ compliance
    → không ai xoá được, kể cả root

Ba lưu ý về sao lưu CSDL nhất quán: | Lưu ý | Chi tiết | |---|---| | Ảnh chụp lúc đang ghi là crash-consistent | | | Đóng băng hoặc dùng chế độ backup của CSDL | | | Kiểm thử khôi phục định kỳ | |

Ba lưu ý về HA cho Oracle trên EC2: | Lưu ý | Chi tiết | |---|---| | RAC cần lưu trữ dùng chung — dùng EBS Multi-Attach hoặc FSx | | | Data Guard là lựa chọn thay thế đơn giản hơn | | | Placement group ảnh hưởng độ trễ giữa node | |

⚠ EBS Multi-Attach có ràng buộc phải biết:

Chỉ io1/io2, chỉ trong CÙNG một AZ
    → RAC trải nhiều AZ không dùng được
        ↓
    Muốn nhiều AZ: Data Guard
      hoặc FSx for NetApp ONTAP

Ba lưu ý về giấy phép Oracle: | Lưu ý | Chi tiết | |---|---| | BYOL trên EC2 phải theo quy định của Oracle | | | Dedicated Host giúp đếm lõi vật lý | | | RAC cần giấy phép riêng, đắt | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm instance hiện trong Fleet Manager | | | Xem báo cáo tuân thủ vá lỗi | | | Khôi phục thử từ ảnh chụp và bấm giờ | |

Và một lời khuyên: hãy hỏi xem có thật sự cần Oracle RAC không trước khi cam kết vận hành nó trên EC2. Rất nhiều hệ thống dùng RAC vì lý do lịch sử chứ không vì yêu cầu kỹ thuật — và với những hệ thống đó, RDS Multi-AZ cho khả năng sẵn sàng tương đương với một phần nhỏ công sức vận hành.

Câu 104 Domain - Accelerate Workload Migration and Modernization

An analytics company plans to create a self-service solution that will provide a safe and cost-effective way for data scientists to access Amazon SageMaker AI on the company’s AWS accounts. The data scientists have limited knowledge of the AWS cloud, so the complex setup requirements for its ML models should not be exposed. The company wants the data scientists to be able to launch a Jupyter notebook instance if needed. The data at rest on the storage volume of the notebook instance must be encrypted with a preconfigured AWS KMS key.

Which of the following solutions will meet the company requirements with the LEAST amount of operational overhead?

  1. A

    Create a self-service portal using AWS Proton and upload standardized service templates to Amazon S3. Add IAM permissions to the data scientist IAM group to use Proton. Write a custom AWS CLI script that will take input parameters from the data scientist for the requested Jupyter notebook instance with the pre-configured KMS key. Have the data scientists execute the script locally on their computers.
  2. B

    Write an AWS CloudFormation template that contains the AWS::SageMaker::NotebookInstance resource type to launch a Jupyter notebook instance with a preconfigured KMS key. On the Outputs section of the CloudFormation template, reference the URL of the notebook instance. Rename this template to be more user-friendly and upload it to a shared Amazon S3 bucket for distribution to the data scientists.
  3. C

    Create a self-service portal using AWS Proton and upload standardized service templates to Amazon S3. Add IAM permissions to the data scientist IAM group to use AWS Proton. Write a custom AWS CLI script that will take input parameters from the data scientist for the requested Jupyter notebook instance with the pre-configured AWS KMS key. Have the data scientists execute the script locally on their computers.
  4. D

    Create an Amazon S3 bucket with website hosting enabled. Create a simple form as a front-end website hosted on the S3 bucket that allows the data scientist to input their request for Jupyter notebook creation. Send the request to an Amazon API Gateway that will invoke an AWS Lambda function with an IAM role permission to create the Jupyter notebook instance with a preconfigured KMS key. Have the Lambda function reply the URL of the notebook instance for display on the front-end website.
Xem giải thích

Đáp án

**A — Tạo cổng tự phục vụ bằng AWS Proton, tải mẫu dịch vụ chuẩn hoá lên S3, cấp quyền IAM cho nhóm nhà khoa học dữ liệu dùng Proton, và viết script AWS CLI nhận tham số để tạo Jupyter notebook với khoá KMS đã cấu hình sẵn.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Tự phục vụ, an toàn | cổng có mẫu chuẩn hoá | | Giấu độ phức tạp khỏi người dùng | họ chỉ điền vài tham số | | Tự tạo được notebook | script nhận tham số | | Ổ đĩa mã hoá bằng khoá KMS định sẵn | khoá nằm trong mẫu, không phải người dùng chọn |

⚠ Ý tưởng cốt lõi: đội hạ tầng định nghĩa mẫu, người dùng chỉ chọn:

Đội nền tảng viết mẫu MỘT LẦN
    → khoá KMS, VPC, IAM role,
      cấu hình bảo mật nằm trong đó
        ↓
    Nhà khoa học dữ liệu chỉ khai
      tên notebook và loại máy
    → không thể cấu hình sai cái họ
      không nhìn thấy

Tạo notebook có mã hoá:

aws sagemaker create-notebook-instance \
  --notebook-instance-name nb-nhom-ml \
  --instance-type ml.t3.medium \
  --role-arn <arn-vai-tro> \
  --kms-key-id <arn-khoa-kms> \
  --direct-internet-access Disabled \
  --subnet-id subnet-rieng-tu \
  --security-group-ids sg-ml

⚠ --kms-key-id mã hoá ổ đĩa của notebook:

Không khai: SageMaker dùng khoá
  do AWS quản lý
        ↓
    Khai khoá riêng: kiểm soát được
      ai giải mã, và xoay khoá được
    → yêu cầu tuân thủ thường đòi cái này

⚠ Và --direct-internet-access Disabled là cấu hình quan trọng không kém:

Mặc định notebook có đường ra Internet
    → dữ liệu nhạy cảm có thể đi ra ngoài
        ↓
    Tắt đi + VPC endpoint cho S3 và SageMaker
    → notebook làm việc được mà không
      chạm Internet

Chặn tạo notebook không mã hoá bằng chính sách:

{"Effect": "Deny",
 "Action": "sagemaker:CreateNotebookInstance",
 "Resource": "*",
 "Condition": {"Null":
   {"sagemaker:VolumeKmsKey": "true"}}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Người dùng không cần biết AWS | | | Cấu hình bảo mật áp đồng nhất | | | Đội nền tảng sửa mẫu là mọi nơi cập nhật | |

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

⚠ Câu này có hai vấn đề nghiêm trọng.

Thứ nhất: phương án A và C gần như trùng nhau từng chữ. Cả hai đều là "AWS Proton + mẫu lên S3 + quyền IAM + script CLI nhận tham số + khoá KMS định sẵn". Khác biệt duy nhất tìm được là cách viết tắt "AWS KMS" so với "KMS". Đây là lỗi soạn đề: hai phương án không phân biệt được thì không có cách nào chọn đúng bằng lập luận.

Thứ hai: AWS Proton đã ngừng nhận khách hàng mới. Và ngay cả khi còn, nó không phải công cụ đúng cho việc này: | Dịch vụ | Vai trò thật | |---|---| | AWS Proton | quản lý mẫu hạ tầng cho đội nền tảng cấp cho đội phát triển | | AWS Service Catalog | danh mục sản phẩm tự phục vụ có kiểm soát | | SageMaker Studio + domain | môi trường ML có sẵn kiểm soát tập trung |

"Cổng tự phục vụ có mẫu chuẩn hoá"
    → đây là mô tả của Service Catalog
        ↓
    Và với riêng SageMaker, cách hiện đại
      là SageMaker Studio với user profile
    → quản trị viên đặt sẵn khoá KMS,
      VPC, IAM ở mức domain

⚠ SageMaker Studio domain giải quyết trọn vẹn yêu cầu này:

aws sagemaker create-domain --domain-name mien-ml \
  --auth-mode IAM --vpc-id vpc-abc \
  --subnet-ids subnet-a subnet-b \
  --kms-key-id <arn-khoa> \
  --app-network-access-type VpcOnly

Mã hoá, mạng, quyền đặt MỘT LẦN ở domain
    → mọi user profile kế thừa
        ↓
    Nhà khoa học dữ liệu chỉ bấm mở Studio
    → không có script, không có mẫu

Và một chi tiết nữa: notebook instance là thế hệ cũ; SageMaker Studio là giao diện được khuyến nghị hiện nay.

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

  • **B. Viết CloudFormation template với AWS::SageMaker::NotebookInstance, đổi tên cho thân thiện rồi để lên S3 dùng chung — đây là phương án gần nhất và kỹ thuật hoàn toàn đúng, nhưng nó vẫn bắt nhà khoa học dữ liệu tự chạy CloudFormation; đề nói rõ họ có kiến thức AWS hạn chế và không được lộ độ phức tạp.
  • C. Trùng nội dung với A — xem phần chất lượng câu hỏi ở trên.
  • **D. Dựng web tĩnh trên S3 + API Gateway + Lambda tự viết — đây là tự xây một cổng tự phục vụ từ đầu; nhiều việc vận hành nhất trong các phương án, trái với yêu cầu "ít công sức nhất".

Ghi nhớ

⚠ Ba công cụ tự phục vụ hạ tầng — bảng phải thuộc: | Công cụ | Dành cho | |---|---| | Service Catalog | danh mục sản phẩm được duyệt cho người dùng cuối | | Proton | mẫu hạ tầng cho ứng dụng (ngừng nhận khách mới) | | CloudFormation / CDK | hạ tầng dạng mã cho kỹ sư |

Từ khoá nhận diện:

"self-service portal, approved products" → Service Catalog "hide complexity from non-technical users" → Service Catalog hoặc Studio domain "ML environment with central controls" → SageMaker Studio domain "encrypt notebook volume" → --kms-key-id

Ba lưu ý về Service Catalog: | Lưu ý | Chi tiết | |---|---| | Sản phẩm là CloudFormation template có phiên bản | | | Launch constraint cho phép người dùng ít quyền tạo tài nguyên nhiều quyền | | | Chia sẻ danh mục qua Organizations | |

⚠ Launch constraint là cơ chế then chốt:

Người dùng không có quyền tạo notebook
    → nhưng launch constraint cho Service
      Catalog dùng một vai trò có quyền
        ↓
    Họ tạo được ĐÚNG sản phẩm trong danh mục
    → và không tạo được gì khác

Ba lưu ý về bảo mật SageMaker: | Lưu ý | Chi tiết | |---|---| | Tắt truy cập Internet trực tiếp | | | Mã hoá ổ đĩa và dữ liệu S3 bằng KMS | | | Dùng VPC endpoint cho SageMaker API | |

Ba lưu ý về chi phí notebook: | Lưu ý | Chi tiết | |---|---| | Tính tiền khi đang chạy, kể cả không dùng | | | Đặt lifecycle config tự tắt khi rảnh | | | Theo dõi bằng tag theo nhóm | |

⚠ Notebook quên tắt là khoản lãng phí kinh điển:

# lifecycle config: tat sau 60 phut khong hoat dong
IDLE_TIME=3600
/usr/bin/python3 auto-stop-idle.py --time $IDLE_TIME

Một notebook ml.p3.2xlarge quên tắt
    → hơn 2.000 USD một tháng
        ↓
    Tự tắt khi rảnh là cấu hình
      phải có ngay từ đầu

Ba lưu ý về KMS: | Lưu ý | Chi tiết | |---|---| | Key policy quyết định ai giải mã | | | Bật xoay khoá tự động | | | Khoá phải cùng Region với tài nguyên | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạo thử với vai trò nhà khoa học dữ liệu | | | Kiểm ổ đĩa notebook có mã hoá đúng khoá | | | Thử tạo notebook không mã hoá — phải bị chặn | |

Và một lời khuyên: hãy đặt các ràng buộc bảo mật ở tầng nền tảng chứ đừng dựa vào việc người dùng khai đúng tham số. Một script yêu cầu người dùng truyền đúng khoá KMS sẽ hoạt động cho tới ngày ai đó bỏ qua tham số đó — còn một domain đã cấu hình sẵn thì không có tham số nào để bỏ qua.

Câu 105 Domain - Design Solutions for Organizational Complexity

A company has a team of data analysts that uploads generated data points to an Amazon S3 bucket. The data points are used by other departments, so the objects on this primary S3 bucket need to be replicated to other S3 buckets on several AWS Accounts owned by the company. The Solutions Architect created an AWS Lambda function that is triggered by S3 PUT events on the primary bucket. This Lambda function will replicate the newly uploaded object to other destination buckets. Since there will be thousands of object uploads on the primary bucket every day, the company is concerned that this Lambda function may affect other critical Lambda functions because of the regional concurrency limit in AWS Lambda. The replication of the objects does not need to happen in real-time. The company needs to ensure that this Lambda function will not affect the execution of other critical Lambda functions.

Which of the following options will meet the requirements in the LEAST amount of development effort?

  1. A

    Decouple the Amazon S3 event notifications and send the events to an Amazon SQS queue in a separate AWS account. Create the new Lambda function on this account too. Invoke the Lambda function whenever an event message is received in the SQS queue.
  2. B

    Implement an exponential backoff algorithm in the new Lambda function to ensure that it will not run if the concurrency limit is reached. Use Amazon CloudWatch alarms to monitor the Throttles metric for Lambda functions to check if the concurrency limit is reached.
  3. C

    Set the execution timeout of the new Lambda function to 5 minutes. This will allow it to wait for other Lambda function executions to finish in case the concurrency limit is reached. Use Amazon CloudWatch alarms to monitor the Throttles metric for Lambda functions to check if the concurrency limit is reached.
  4. D

    Configure a reserved concurrency limit for the new function to ensure that its executions will not exceed this limit. Use Amazon CloudWatch alarms to monitor the Throttles metric for Lambda functions to ensure that the concurrency limit is not being reached.
Xem giải thích

Đáp án

**D — Đặt reserved concurrency cho hàm mới để số lượt chạy đồng thời của nó không vượt quá giới hạn đó; dùng CloudWatch alarm trên chỉ số Throttles để theo dõi.

Vì sao đúng

Đề nêu đúng một nỗi lo và một ràng buộc: | Nỗi lo | Cách giải | |---|---| | Hàm nhân bản chiếm hết đồng thời của Region | reserved concurrency đặt TRẦN cho nó | | Ít công sức phát triển nhất | một dòng cấu hình, không sửa mã |

⚠ Reserved concurrency có HAI tác dụng cùng lúc — đây là điểm mấu chốt:

1. ĐẶT TRẦN: hàm này không bao giờ
   vượt quá N lượt đồng thời
        ↓
2. DÀNH RIÊNG: N lượt đó được giữ
   cho riêng nó, không ai lấy mất
        ↓
    Đề cần tác dụng thứ nhất
    → nhưng phải hiểu cả hai

Đặt trần:

aws lambda put-function-concurrency \
  --function-name nhan-ban-object \
  --reserved-concurrent-executions 50

⚠ Và đây là hệ quả phải tính trước:

Hạn ngạch Region: 1.000 lượt đồng thời
    → đặt reserved 50 cho hàm nhân bản
        ↓
    Còn 950 cho MỌI hàm khác
    → 50 kia bị KHOÁ, dù hàm nhân bản
      không chạy

Kiểm tra hạn ngạch còn lại:

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

⚠ AWS bắt buộc chừa 100 lượt không dành riêng:

Tổng reserved của mọi hàm
    ≤ hạn ngạch Region − 100
        ↓
    Đặt vượt: API từ chối
    → 100 lượt đó dành cho hàm
      chưa cấu hình reserved

Cảnh báo khi bị chặn:

aws cloudwatch put-metric-alarm \
  --alarm-name lambda-bi-chan \
  --namespace AWS/Lambda --metric-name Throttles \
  --dimensions Name=FunctionName,Value=nhan-ban-object \
  --statistic Sum --period 300 --threshold 100 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1

⚠ Bị chặn ở đây KHÔNG mất dữ liệu, vì S3 tự thử lại:

S3 event notification gọi Lambda
    → bị chặn (429)
        ↓
    S3 thử lại với backoff, tới 24 giờ
    → và đề nói "không cần thời gian thực"
    → chậm là chấp nhận được

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một dòng cấu hình, không sửa mã | | | Bảo vệ được các hàm quan trọng khác | | | Đảo ngược ngay nếu cần | |

⚠ Nhưng đặt trần quá thấp có rủi ro:

Hàng nghìn object mỗi ngày
    + trần quá thấp
        ↓
    S3 thử lại quá 24 giờ vẫn không xử lý kịp
    → sự kiện bị BỎ, không có DLQ
        ↓
    Đặt trần theo lượng thật + có biên

⚠ An toàn hơn: chèn SQS vào giữa:

S3 → SQS → Lambda
        ↓
    Thông điệp nằm trong hàng đợi tới 14 ngày
    → Lambda bị chặn cũng không mất gì
    → và có DLQ cho thông điệp lỗi

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

  • **A. Đưa sự kiện S3 sang SQS ở một tài khoản AWS riêng và chạy Lambda ở đó — đây là phương án gần nhất và thật sự cô lập triệt để (hạn ngạch Lambda tính theo tài khoản), nhưng nó đòi dựng tài khoản mới, cấu hình quyền xuyên tài khoản và chuyển hạ tầng — nhiều việc hơn hẳn một dòng cấu hình.
  • **B. Cài thuật toán exponential backoff trong hàm để nó không chạy khi chạm giới hạn — hàm chỉ biết mình bị chặn sau khi đã chiếm suất đồng thời; không ngăn được việc chiếm chỗ, và phải viết mã.
  • **C. Đặt timeout 5 phút để hàm chờ các lượt khác xong — timeout dài làm tình hình tệ hơn: mỗi lượt giữ suất đồng thời lâu hơn, chiếm nhiều hơn chứ không ít đi.

Ghi nhớ

⚠ Ba khái niệm đồng thời của Lambda — bảng phải thuộc: | Khái niệm | Nghĩa | |---|---| | Unreserved concurrency | phần chung, hàm nào cũng dùng | | Reserved concurrency | TRẦN cho một hàm, đồng thời dành riêng cho nó | | Provisioned concurrency | giữ sẵn môi trường ĐÃ KHỞI ĐỘNG |

⚠ Reserved và Provisioned giải quyết hai vấn đề khác nhau:

Reserved: giải quyết bài toán CHIA PHẦN
    → ai được bao nhiêu suất
        ↓
    Provisioned: giải quyết KHỞI ĐỘNG NGUỘI
    → môi trường sẵn sàng, không phải
      chờ khởi tạo
    → tính tiền theo giờ giữ chỗ

Từ khoá nhận diện:

"prevent one function from consuming all concurrency" → reserved concurrency "eliminate cold starts" → provisioned concurrency "function must never run" → reserved = 0 "decouple and buffer" → SQS ở giữa

⚠ Reserved bằng 0 là công tắc tắt hàm:

aws lambda put-function-concurrency \
  --function-name ham-co-van-de \
  --reserved-concurrent-executions 0

Hàm đang gây sự cố
    → đặt 0 là dừng ngay lập tức
    → không phải xoá hàm hay gỡ trigger

Ba lưu ý về hạn ngạch: | Lưu ý | Chi tiết | |---|---| | Mặc định 1.000 mỗi Region mỗi tài khoản | | | Tăng được qua Service Quotas | | | Burst concurrency có giới hạn riêng | |

⚠ Burst concurrency là giới hạn riêng hay bị quên:

Từ 0 lên nghìn lượt trong một giây
    → Lambda chỉ mở thêm theo tốc độ
      burst cho phép
        ↓
    Vượt: bị chặn dù chưa chạm
      hạn ngạch tổng

Ba lưu ý về S3 event notification: | Lưu ý | Chi tiết | |---|---| | Giao ít nhất một lần, có thể trùng | | | Thử lại tới 24 giờ khi đích lỗi | | | EventBridge cho luật định tuyến phức tạp hơn | |

Ba lưu ý về SQS trước Lambda: | Lưu ý | Chi tiết | |---|---| | Đệm khi Lambda bị chặn | | | maximum-concurrency giới hạn ngay ở event source | | | DLQ giữ thông điệp hỏng | |

aws lambda update-event-source-mapping --uuid <id> \
  --scaling-config MaximumConcurrency=50

⚠ Tính năng này ra sau và tốt hơn reserved trong nhiều trường hợp:

Reserved: giới hạn hàm ở MỌI nguồn gọi
        ↓
    `MaximumConcurrency` của event source:
      chỉ giới hạn phần gọi từ SQS đó
    → hàm vẫn phục vụ nguồn khác bình thường

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | Throttles | bị chặn bao nhiêu lượt | | ConcurrentExecutions | đang dùng bao nhiêu suất | | IteratorAge | với nguồn dạng luồng: chậm bao nhiêu |

Ba lưu ý về nhân bản S3: | Lưu ý | Chi tiết | |---|---| | S3 Replication làm sẵn việc này, không cần Lambda | | | Hỗ trợ nhiều đích và xuyên tài khoản | | | Có chỉ số và cảnh báo sẵn | |

⚠ Đây là điều đáng nói nhất về câu này:

aws s3api put-bucket-replication --bucket nguon \
  --replication-configuration '{"Role":"<arn>","Rules":[{
    "Status":"Enabled","Priority":1,
    "Filter":{},"DeleteMarkerReplication":{"Status":"Disabled"},
    "Destination":{"Bucket":"arn:aws:s3:::dich-1",
                   "Account":"999988887777",
                   "AccessControlTranslation":{"Owner":"Destination"}}}]}'

S3 Replication nhân bản sang nhiều bucket
  ở nhiều tài khoản
    → không có Lambda, không có
      bài toán đồng thời nào cả
        ↓
    Bài toán trong đề vốn không cần tồn tại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy hàng nghìn object, xem ConcurrentExecutions | | | Kiểm các hàm khác có bị chặn không | | | Đo thời gian nhân bản hoàn tất | |

Và một lời khuyên: hãy kiểm tra xem S3 Replication có làm được việc đó không trước khi viết Lambda nhân bản. Tính năng có sẵn không có bài toán đồng thời, không có mã để bảo trì, và có sẵn chỉ số cho biết nó đang chạy đến đâu.

Câu 106 Domain - Design Solutions for Organizational Complexity

A weather forecasting agency established a network of IoT devices in the ocean to help predict incoming typhoons. The IoT devices monitor the sea surface temperature and atmospheric pressure and send the data as messages to AWS IoT Core, which updates an Amazon DynamoDB table. On the weekly monitoring report, a system administrator notices that no new database updates are happening.

What should the administrator do to troubleshoot the issue?

  1. A

    Use AWS IoT SiteWise to collect the data directly from the IoT devices and send the aggregated data to IoT Core.
  2. B

    Register the IoT devices to AWS IoT Device Management and monitor the devices' health and ensure the devices are connected to AWS IoT Core.
  3. C

    Use AWS IoT Device Defender to add the Certificate Authority of the X.509 certificates used by the devices when connecting to AWS IoT Core, and establish connectivity.
  4. D

    Trigger a Lambda function adding updates to the DynamoDB table by integrating the IoT devices with IoT 1-Click.
Xem giải thích

Đáp án

**B — Đăng ký thiết bị vào AWS IoT Device Management, theo dõi tình trạng thiết bị và xác nhận chúng còn kết nối tới AWS IoT Core.

Vì sao đúng

Đề mô tả triệu chứng "không có bản ghi mới", và bước gỡ lỗi đầu tiên phải là xác định thiết bị có còn gửi dữ liệu hay không:

Không có bản ghi mới trong DynamoDB
    ↓
Nguyên nhân nằm ở một trong ba chặng:
    1. Thiết bị không gửi (mất điện,
       mất sóng, chứng chỉ hết hạn)
    2. Rule không khớp hoặc lỗi
    3. Ghi DynamoDB thất bại
        ↓
    Phải xác định chặng nào TRƯỚC
      khi sửa bất cứ thứ gì

⚠ IoT Device Management là công cụ đúng cho bước một: | Tính năng | Việc | |---|---| | Fleet Indexing | tìm kiếm thiết bị theo trạng thái kết nối | | Fleet Metrics | đếm bao nhiêu thiết bị đang online | | Jobs | cập nhật phần mềm hàng loạt | | Secure Tunneling | truy cập thiết bị ở xa để gỡ lỗi |

Bật đánh chỉ mục đội thiết bị:

aws iot update-indexing-configuration \
  --thing-indexing-configuration \
    thingIndexingMode=REGISTRY_AND_SHADOW,\
thingConnectivityIndexingMode=STATUS

Tìm thiết bị đã mất kết nối:

aws iot search-index --index-name AWS_Things \
  --query-string "connectivity.connected:false"

⚠ Đây là câu lệnh trả lời thẳng câu hỏi trong đề:

Trả về danh sách rỗng
    → thiết bị vẫn kết nối
    → vấn đề nằm ở rule hoặc DynamoDB
        ↓
    Trả về toàn bộ đội
    → thiết bị đã mất kết nối
    → tìm nguyên nhân ở phía thiết bị

Theo dõi bằng chỉ số đội:

aws iot create-fleet-metric --metric-name so-thiet-bi-online \
  --query-string "connectivity.connected:true" \
  --aggregation-type name=Statistics \
  --period 300 --aggregation-field registry.version

⚠ Và nên cảnh báo TRƯỚC khi ai đó đọc báo cáo tuần:

Đề nói phát hiện qua "báo cáo giám sát tuần"
    → sự cố đã kéo dài tới bảy ngày
        ↓
    Cảnh báo trên số thiết bị online
    → biết trong vài phút

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Thấy ngay chặng nào hỏng | | | Không phải đoán mò giữa ba tầng | | | Có Secure Tunneling để vào tận thiết bị | |

⚠ Ba nguyên nhân phổ biến khiến thiết bị IoT mất kết nối: | Nguyên nhân | Dấu hiệu | |---|---| | Chứng chỉ hết hạn hoặc bị vô hiệu hoá | kết nối bị từ chối ngay | | Chính sách IoT thiếu quyền publish | kết nối được nhưng không gửi được | | Mất nguồn hoặc mất sóng | im lặng hoàn toàn |

Kiểm tra log của IoT Core:

aws iot set-v2-logging-options \
  --default-log-level ERROR --role-arn <arn>

Log ghi rõ lý do từ chối kết nối
    → chứng chỉ, chính sách, hay mạng

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

  • **C. Dùng AWS IoT Device Defender để thêm CA của chứng chỉ X.509 và thiết lập kết nối — đây là phương án gần nhất và chứng chỉ là một nguyên nhân có thật, nhưng Device Defender là công cụ kiểm toán và phát hiện bất thường về bảo mật; nó không dùng để đăng ký CA (đó là việc của IoT Core) và không thiết lập kết nối.
  • **A. Dùng IoT SiteWise thu thập dữ liệu rồi gửi sang IoT Core — SiteWise dành cho thiết bị công nghiệp qua OPC-UA; nó không chẩn đoán được vấn đề hiện có và là thay đổi kiến trúc chứ không phải gỡ lỗi.
  • **D. Kích hoạt Lambda qua IoT 1-Click — IoT 1-Click dành cho nút bấm đơn giản, và dịch vụ này đã ngừng hoạt động từ tháng 12/2021.

Ghi nhớ

⚠ Bốn dịch vụ IoT hay bị lẫn — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | IoT Core | kết nối, xác thực, định tuyến thông điệp | | IoT Device Management | kiểm kê, theo dõi, cập nhật đội thiết bị | | IoT Device Defender | kiểm toán bảo mật, phát hiện bất thường | | IoT Greengrass | chạy logic ngay tại thiết bị biên |

Từ khoá nhận diện:

"are the devices still connected?" → Device Management, Fleet Indexing "detect abnormal device behaviour" → Device Defender "run inference locally, offline" → Greengrass "industrial equipment, OPC-UA" → IoT SiteWise

Ba lưu ý về Device Defender: | Lưu ý | Chi tiết | |---|---| | Audit kiểm cấu hình: chứng chỉ, chính sách quá rộng | | | Detect phát hiện hành vi lạ: lưu lượng bất thường | | | ML Detect tự học ngưỡng bình thường | |

⚠ Audit của Device Defender bắt được lỗi cấu hình nguy hiểm:

aws iot start-on-demand-audit-task \
  --target-check-names \
    DEVICE_CERTIFICATE_EXPIRING_CHECK \
    IOT_POLICY_OVERLY_PERMISSIVE_CHECK

Chứng chỉ sắp hết hạn
    + chính sách cho phép `iot:*` trên `*`
        ↓
    Hai lỗi này gây ra phần lớn sự cố
      và rủi ro bảo mật IoT

Ba lưu ý về chứng chỉ thiết bị: | Lưu ý | Chi tiết | |---|---| | X.509, mỗi thiết bị một chứng chỉ riêng | | | Vô hiệu hoá được từng cái | | | Có hạn — phải có kế hoạch xoay | |

⚠ Chứng chỉ hết hạn hàng loạt là sự cố có thể đoán trước:

Cả đội thiết bị cấp chứng chỉ cùng ngày
    → hết hạn cùng ngày
        ↓
    Toàn bộ đội mất kết nối cùng lúc
    → dùng Fleet Provisioning để xoay
      chứng chỉ tự động

Ba lưu ý về chính sách IoT: | Lưu ý | Chi tiết | |---|---| | Giới hạn iot:Publish theo chủ đề | | | Dùng biến ${iot:Connection.Thing.ThingName} | | | Tránh cấp * cho tài nguyên | |

{"Effect": "Allow", "Action": "iot:Publish",
 "Resource": "arn:aws:iot:*:*:topic/cam-bien/${iot:Connection.Thing.ThingName}/*"}

Ba lưu ý về Device Shadow: | Lưu ý | Chi tiết | |---|---| | Giữ trạng thái mong muốn và trạng thái thật | | | Thiết bị đồng bộ khi online lại | | | Hữu ích với thiết bị kết nối chập chờn | |

Ba lưu ý về rule action ghi DynamoDB: | Lưu ý | Chi tiết | |---|---| | Vai trò IAM của rule phải có quyền ghi | | | Cấu hình error action để không mất thông điệp | | | Chú ý WCU của bảng khi đội thiết bị lớn | |

⚠ Error action là thứ luôn nên khai:

{"errorAction": {"republish": {
  "topic": "loi/ghi-dynamodb",
  "roleArn": "<arn>"}}}

Ghi DynamoDB thất bại (hết WCU, quyền sai)
    → không có error action: thông điệp
      biến mất, không dấu vết
        ↓
    Có: chuyển sang chủ đề lỗi để điều tra

Ba việc kiểm chứng: | Việc | Cách | |---|---| | search-index xem bao nhiêu thiết bị online | | | Dùng MQTT test client xem thông điệp có tới | | | Kiểm CloudWatch metric của rule | |

Và một lời khuyên: hãy đặt cảnh báo trên số thiết bị đang kết nối ngay từ ngày triển khai đầu tiên. Hệ thống IoT hỏng theo kiểu im lặng — không có lỗi nào, không có ngoại lệ nào, chỉ đơn giản là dữ liệu ngừng đến, và không ai nhận ra cho tới lần đọc báo cáo tiếp theo.

Câu 107 Domain - Design for New Solutions

A popular news website that uses an Oracle database is currently deployed in the company's on-premises network. Due to its growing number of readers, the company decided to move its infrastructure to AWS where they can further improve the performance of the website. The company earns from the advertisements placed on the website so you were instructed to ensure that the website remains available in case of database server failures. Their team of content writers constantly upload new articles every day including the wee hours of the morning to cover breaking news.

In this scenario, how can you implement a highly available architecture to meet the requirement?

  1. A Create an Oracle database in RDS with Read Replicas.
  2. B Create an Oracle Real Application Clusters (RAC) in RDS which provides a shared cache architecture that overcomes the limitations of traditional shared-nothing and shared-disk approaches to provide highly scalable and available database solutions for the news website.
  3. C Create an Oracle database in RDS with Multi-AZ deployments.
  4. D

    Create an Oracle database instance in RDS with Recovery Manager (RMAN) which performs backup and recovery tasks on your database and automates the administration of your backup strategies.
Xem giải thích

Đáp án

**C — Tạo CSDL Oracle trên RDS với triển khai Multi-AZ.

Vì sao đúng

Đề nêu đúng một yêu cầu: website phải còn sống khi máy chủ CSDL hỏng, và Multi-AZ là tính năng dành riêng cho việc đó:

Instance chính ở AZ-a
    → nhân bản ĐỒNG BỘ sang bản dự phòng
      ở AZ-b
        ↓
    AZ-a hỏng: RDS tự chuyển sang AZ-b
    → cùng một endpoint DNS
    → ứng dụng kết nối lại là xong

⚠ Nhân bản ĐỒNG BỘ là lý do không mất dữ liệu:

Mỗi giao dịch commit ở instance chính
    → chỉ báo thành công SAU KHI
      bản dự phòng đã ghi xong
        ↓
    RPO = 0
    → đúng cho website liên tục
      đăng bài kể cả rạng sáng

⚠ Và đây là điểm phân biệt với Read Replica: | Tiêu chí | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | CO GIÃN ĐỌC | | Nhân bản | đồng bộ | bất đồng bộ | | Đọc từ bản kia | KHÔNG | có | | Chuyển đổi | tự động | thủ công | | Mất dữ liệu khi hỏng | không | có thể |

Read Replica bất đồng bộ
    → có độ trễ nhân bản
    → instance chính chết đột ngột
      thì giao dịch chưa kịp sang bị mất
        ↓
    Với website tin tức thì mất vài bài
    → với hệ thống giao dịch thì nghiêm trọng

Bật Multi-AZ:

aws rds modify-db-instance \
  --db-instance-identifier csdl-tin-tuc \
  --multi-az --apply-immediately

⚠ Chuyển đổi mất khoảng 60-120 giây, và ứng dụng phải chịu được:

DNS endpoint không đổi
    → nhưng IP phía sau đổi
        ↓
    JVM cache DNS vĩnh viễn theo mặc định
    → đặt `networkaddress.cache.ttl=60`
    → nếu không, ứng dụng kết nối mãi
      vào IP cũ đã chết

Kiểm thử chuyển đổi:

aws rds reboot-db-instance \
  --db-instance-identifier csdl-tin-tuc --force-failover

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tự động, không cần ai can thiệp lúc 3 giờ sáng | | | Không mất dữ liệu | | | Vá lỗi và sao lưu không gây gián đoạn | |

⚠ Lợi ích thứ ba đáng nói riêng:

Không Multi-AZ: vá lỗi = ngừng dịch vụ
        ↓
    Có Multi-AZ: AWS vá bản dự phòng trước,
      chuyển đổi, rồi vá bản kia
    → gián đoạn chỉ bằng một lần chuyển đổi

⚠ Và Multi-AZ DB cluster là lựa chọn mới hơn: | Tiêu chí | Multi-AZ instance | Multi-AZ DB cluster | |---|---|---| | Số bản | 1 chính + 1 dự phòng | 1 writer + 2 reader | | Đọc từ bản dự phòng | không | CÓ | | Thời gian chuyển đổi | 60-120 giây | dưới 35 giây | | Hỗ trợ Oracle | có | không (chỉ MySQL, PostgreSQL) |

Với Oracle: chỉ có Multi-AZ instance
    → cụm ba node không áp dụng được

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

  • **A. Tạo Oracle trên RDS với Read Replica — đây là phương án gần nhất và Read Replica là tính năng có thật của RDS Oracle, nhưng nó dành cho co giãn đọc chứ không phải sẵn sàng cao: nhân bản bất đồng bộ, và chuyển đổi phải làm thủ công.
  • **B. Tạo Oracle RAC trên RDS — RDS không hỗ trợ RAC; muốn RAC phải tự chạy trên EC2.
  • **D. Dùng Recovery Manager (RMAN) để sao lưu và khôi phục — sao lưu là lớp bảo vệ cuối, không phải cơ chế sẵn sàng cao; khôi phục từ backup mất hàng giờ.

Ghi nhớ

⚠ Bốn cấp bảo vệ CSDL trên RDS — bảng phải thuộc: | Cấp | Bảo vệ khỏi | Thời gian phục hồi | |---|---|---| | Multi-AZ | hỏng instance hoặc AZ | 1-2 phút, tự động | | Read Replica xuyên Region | mất cả Region | vài phút, thủ công | | Ảnh chụp tự động (PITR) | xoá nhầm dữ liệu | hàng chục phút tới giờ | | Ảnh chụp thủ công | giữ lâu dài | tương tự |

⚠ Multi-AZ KHÔNG bảo vệ khỏi xoá nhầm:

`DROP TABLE` chạy trên instance chính
    → nhân bản ĐỒNG BỘ sang bản dự phòng
      ngay lập tức
        ↓
    Cả hai đều mất bảng
    → chỉ point-in-time recovery cứu được

Từ khoá nhận diện:

"survive database server failure" → Multi-AZ "offload read traffic" → Read Replica "recover from accidental deletion" → PITR "survive Region failure" → Read Replica xuyên Region hoặc cross-region backup

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Bản dự phòng KHÔNG phục vụ đọc | | | Chi phí gấp đôi (hai instance) | | | Bật/tắt được trên instance đang chạy | |

⚠ Chi phí gấp đôi là điều phải nói rõ với người quyết định:

Bản dự phòng chạy 24/7 và không phục vụ gì
    → nghe như lãng phí
        ↓
    Nhưng đó là giá của việc không mất
      doanh thu quảng cáo trong lúc
      khôi phục thủ công

Ba lưu ý về Read Replica: | Lưu ý | Chi tiết | |---|---| | Tối đa 5 bản (15 với Aurora) | | | Thăng cấp thành instance độc lập được | | | Có thể đặt ở Region khác | |

Ba lưu ý về sao lưu: | Lưu ý | Chi tiết | |---|---| | Tự động, giữ tối đa 35 ngày | | | PITR tới bất kỳ giây nào trong khoảng giữ | | | Ảnh chụp thủ công giữ tới khi bạn xoá | |

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier csdl-tin-tuc \
  --target-db-instance-identifier csdl-khoi-phuc \
  --restore-time 2026-08-30T02:15:00Z

Ba lưu ý về kết nối ứng dụng: | Lưu ý | Chi tiết | |---|---| | Luôn dùng endpoint DNS, không dùng IP | | | Đặt TTL cache DNS ngắn | | | Cài logic thử lại khi mất kết nối | |

⚠ RDS Proxy giải quyết trọn vẹn vấn đề kết nối:

Proxy giữ pool kết nối
    → chuyển đổi xảy ra ở phía sau proxy
        ↓
    Ứng dụng gần như không thấy gián đoạn
    → giảm thời gian chuyển đổi
      thấy được tới hơn 60%

Ba lưu ý về bảo trì: | Lưu ý | Chi tiết | |---|---| | Đặt maintenance window vào giờ ít người | | | Nâng cấp phiên bản chính phải kiểm thử trước | | | Bật auto-minor-version-upgrade | |

Ba lưu ý về giám sát: | Chỉ số | Cảnh báo khi | |---|---| | DatabaseConnections | gần chạm max_connections | | ReadLatency / WriteLatency | tăng bất thường | | FreeStorageSpace | dưới 20% |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Buộc chuyển đổi và bấm giờ | | | Xem ứng dụng có tự kết nối lại không | | | Kiểm sự kiện RDS ghi lại lần chuyển đổi | |

Và một lời khuyên: hãy buộc chuyển đổi một lần ở môi trường thật trước khi tin rằng Multi-AZ đã hoạt động. Phần AWS lo thì luôn chạy — phần hay hỏng là ứng dụng của bạn, thứ vẫn đang giữ một kết nối tới IP không còn tồn tại.

Câu 108 Domain - Design Solutions for Organizational Complexity

A call center company uses its custom application to process and store call recordings in its on-premises data center. The recordings are stored on an NFS share. An offshore team is contracted to transcribe about 2% of the call recordings to be used for quality assurance purposes. It could take up to 3 days before the recordings are completely transcribed. The application that processes the calls and manages the transcription queue is hosted on Linux servers. A web portal is available for the quality assurance team to review the call recordings. After 90 days, the recordings are sent to an offsite location for long-term storage. The company plans to migrate the system to the AWS cloud to reduce storage costs and automate the transcription of the recordings.

Which of the following options is the recommended solution to meet the company’s requirements?

  1. A

    Create an Auto Scaling group of Amazon EC2 instances to host the web portal. Provision an Application Load Balancer in front of the Auto Scaling group. Store all recordings in an Amazon EFS share that is mounted on all instances. After 90 days, archive all call recordings using AWS Backup and use Amazon Transcribe to transcribe the recordings.
  2. B

    Store all recordings in an Amazon S3 bucket. Create an S3 lifecycle policy to move objects older than 90 days to Amazon S3 Glacier. Create an AWS Lambda trigger to start a transcription job using Amazon Transcribe. Update the web portal so it can be hosted on an Amazon S3 bucket, Amazon API Gateway, and AWS Lambda.
  3. C

    Store all recordings in an Amazon S3 bucket. Create an S3 lifecycle policy to move objects older than 90 days to Amazon S3 Glacier. Create an AWS Lambda trigger to start a transcription job using AWS IQ. Create an Auto Scaling group of Amazon EC2 instances to host the web portal. Provision an Application Load Balancer in front of the Auto Scaling group.
  4. D

    Store all recordings in an Amazon S3 bucket and send the object key to an Amazon SQS queue. Create an S3 lifecycle policy to move objects older than 90 days to Amazon S3 Glacier. Create an Auto Scaling group of Amazon EC2 instances to push the recordings to Amazon Translate for transcription. Set the Auto Scaling policy based on the number of objects on the SQS queue. Update the web portal so it can be hosted on an Amazon S3 bucket, Amazon API Gateway, and AWS Lambda.
Xem giải thích

Đáp án

**B — Lưu bản ghi âm trong S3, dùng lifecycle policy chuyển object cũ hơn 90 ngày sang S3 Glacier, tạo trigger Lambda khởi động công việc phiên âm bằng Amazon Transcribe, và chuyển cổng web sang chạy trên S3 + API Gateway + Lambda.

Vì sao đúng

Đề nêu bốn nhu cầu, và phương án này khớp từng cái: | Nhu cầu | Cách đáp ứng | |---|---| | Giảm chi phí lưu trữ | S3 + lifecycle sang Glacier sau 90 ngày | | Tự động phiên âm | Amazon Transcribe | | Kích hoạt khi có bản ghi mới | S3 event → Lambda | | Cổng web cho đội kiểm định | S3 tĩnh + API Gateway + Lambda |

⚠ Amazon Transcribe là dịch vụ DUY NHẤT chuyển giọng nói thành văn bản:

Transcribe: âm thanh → văn bản
Translate: văn bản ngôn ngữ A → ngôn ngữ B
Polly:     văn bản → giọng nói
Comprehend: văn bản → ý nghĩa, cảm xúc
        ↓
    Nhầm Translate với Transcribe là lỗi
      hay gặp nhất trong nhóm dịch vụ này

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

Khởi động công việc phiên âm:

import boto3, urllib.parse
transcribe = boto3.client('transcribe')

def handler(su_kien, ngu_canh):
    for ban_ghi in su_kien['Records']:
        bucket = ban_ghi['s3']['bucket']['name']
        khoa = urllib.parse.unquote_plus(
            ban_ghi['s3']['object']['key'])
        transcribe.start_transcription_job(
            TranscriptionJobName=khoa.replace('/', '-'),
            Media={'MediaFileUri': f's3://{bucket}/{khoa}'},
            MediaFormat='wav',
            LanguageCode='vi-VN',
            OutputBucketName='ban-phien-am',
            Settings={'ShowSpeakerLabels': True,
                      'MaxSpeakerLabels': 2})

⚠ ShowSpeakerLabels rất quan trọng với bản ghi tổng đài:

Không bật: một khối văn bản liền
    → không biết ai nói câu nào
        ↓
    Bật: tách theo người nói
    → đội kiểm định đọc được hội thoại
      giữa nhân viên và khách hàng

Vòng đời lưu trữ:

{"Rules": [{
  "ID": "chuyen-sang-glacier",
  "Status": "Enabled",
  "Filter": {"Prefix": "ban-ghi/"},
  "Transitions": [
    {"Days": 90, "StorageClass": "GLACIER"}]}]}

⚠ Nhưng chỉ 2% bản ghi cần phiên âm — đừng chạy hết:

Kích hoạt Lambda cho MỌI object
    → phiên âm 100% trong khi chỉ
      cần 2%
        ↓
    Transcribe tính phí theo phút âm thanh
    → lãng phí 50 lần
        ↓
    Đúng: chỉ khởi động khi đội kiểm định
      CHỌN bản ghi, hoặc lọc theo tiền tố

Lọc theo tiền tố ở event notification:

{"LambdaFunctionConfigurations": [{
  "Events": ["s3:ObjectCreated:*"],
  "Filter": {"Key": {"FilterRules": [
    {"Name": "prefix", "Value": "can-kiem-dinh/"}]}},
  "LambdaFunctionArn": "<arn>"}]}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không còn máy chủ nào phải vận hành | | | Chi phí lưu trữ giảm mạnh sau 90 ngày | | | Phiên âm tự động, không thuê đội ngoài | |

⚠ Và đây là điểm đề nhấn mạnh: cổng web không cần EC2:

Cổng chỉ để duyệt và nghe lại bản ghi
    → trang tĩnh trên S3 + CloudFront
    + API Gateway + Lambda cho phần động
        ↓
    Không có máy chủ chạy 24/7
    → chi phí gần bằng 0 khi không ai dùng

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

  • **D. Lưu S3, đẩy khoá object vào SQS, dùng ASG EC2 gửi bản ghi sang Amazon Translate — đây là phương án gần nhất và kiến trúc hàng đợi + ASG hoàn toàn hợp lý, nhưng Translate là dịch thuật văn bản, không phải phiên âm giọng nói; và ASG EC2 là nhiều việc vận hành hơn mức cần thiết.
  • **A. Lưu trên EFS với ASG + ALB, lưu trữ dài hạn bằng AWS Backup — EFS đắt hơn S3 rất nhiều cho dữ liệu chỉ đọc lại thỉnh thoảng, và trái với mục tiêu giảm chi phí lưu trữ.
  • **C. Dùng AWS IQ để khởi động công việc phiên âm — AWS IQ là sàn kết nối với chuyên gia tư vấn, không phải dịch vụ xử lý dữ liệu.

Ghi nhớ

⚠ Bốn dịch vụ AI xử lý ngôn ngữ — bảng phải thuộc: | Dịch vụ | Vào | Ra | |---|---|---| | Transcribe | âm thanh | văn bản | | Polly | văn bản | âm thanh | | Translate | văn bản | văn bản ngôn ngữ khác | | Comprehend | văn bản | thực thể, cảm xúc, chủ đề |

⚠ Ghép chuỗi bốn dịch vụ này là mẫu rất mạnh:

Bản ghi tổng đài
    → Transcribe: ra văn bản
    → Comprehend: phân tích cảm xúc
        ↓
    Phát hiện cuộc gọi khách hàng bực bội
    → không cần ai nghe lại thủ công

Từ khoá nhận diện:

"transcribe call recordings" → Transcribe "analyse customer sentiment" → Comprehend "contact centre analytics, end to end" → Amazon Connect + Contact Lens "archive after N days" → S3 lifecycle

⚠ Contact Lens for Amazon Connect làm sẵn cả chuỗi:

Phiên âm + phân tích cảm xúc
  + phát hiện từ khoá + chấm điểm cuộc gọi
        ↓
    Nếu tổng đài chuyển sang Amazon Connect
    → không phải ghép Transcribe và
      Comprehend bằng tay

Ba lưu ý về Transcribe: | Lưu ý | Chi tiết | |---|---| | Custom vocabulary cho thuật ngữ ngành | | | Tự động lọc từ nhạy cảm | | | Nhận diện và che thông tin cá nhân (PII) | |

⚠ Che PII là tính năng quan trọng với bản ghi tổng đài:

Settings={'VocabularyName': 'thuat-ngu-nganh'},
ContentRedaction={'RedactionType': 'PII',
                  'RedactionOutput': 'redacted'}

Khách hàng đọc số thẻ qua điện thoại
    → bản phiên âm chứa số thẻ
        ↓
    Bật che PII: thay bằng [PII]
    → đội kiểm định vẫn đọc được nội dung

Ba lưu ý về lớp lưu trữ S3: | Lớp | Hợp với | |---|---| | Standard | truy cập thường xuyên | | Standard-IA | ít truy cập, cần ngay khi cần | | Glacier Instant Retrieval | lưu trữ, lấy trong mili giây | | Glacier Deep Archive | rất hiếm khi lấy, rẻ nhất |

⚠ Chọn lớp Glacier phải xét thời gian lấy:

Đội kiểm định có thể cần bản ghi cũ
    → Deep Archive mất 12-48 giờ
        ↓
    Glacier Instant Retrieval: mili giây
    → đắt hơn chút nhưng dùng được

Ba lưu ý về lifecycle: | Lưu ý | Chi tiết | |---|---| | Object nhỏ hơn 128 KB không nên chuyển | | | Có phí chuyển lớp cho mỗi object | | | Intelligent-Tiering tự chuyển theo mẫu dùng | |

⚠ Intelligent-Tiering hợp khi mẫu truy cập khó đoán:

Không chắc bản ghi nào sẽ được xem lại
    → Intelligent-Tiering tự theo dõi
      và chuyển lớp
        ↓
    Phí giám sát nhỏ mỗi object
    → nhưng không bao giờ chọn sai lớp

Ba lưu ý về kiến trúc không máy chủ cho cổng web: | Lưu ý | Chi tiết | |---|---| | S3 + CloudFront cho phần tĩnh | | | API Gateway + Lambda cho phần động | | | Cognito cho đăng nhập | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải lên một bản ghi, xem công việc phiên âm chạy | | | Kiểm object cũ đã chuyển sang Glacier | | | Đo chi phí Transcribe theo tháng | |

Và một lời khuyên: hãy chỉ phiên âm những bản ghi thật sự cần thay vì phiên âm tất cả cho tiện. Transcribe tính tiền theo phút âm thanh — với tỷ lệ 2% trong đề, phiên âm toàn bộ tốn gấp năm mươi lần mà không ai đọc phần dư ra.

Câu 109 Chọn nhiều đáp án Domain - Design for New Solutions

A leading media company is building a collaborative news website that is expected to have over 5 million readers per month globally. Each article contains a cover image and has at least 200 words. Based on the trend of their other websites, the new articles are highly browsed in the first 2 months and the authors tend to frequently update the articles on the first month after its publication. The readership is also expected to drop on the 3rd month and the articles are usually rarely accessed after a year. The readers are also leaving a lot of comments within the first 3 months of publishing.

In this scenario, which of the following items can you use to build a durable, highly available, and scalable architecture for the news website? (Select TWO.)

  1. A

    Use Amazon RDS Multi-AZ deployments with Read Replicas. Use S3 to store the static data such as the cover images and other media.
  2. B Launch an RDS Oracle Real Application Clusters (RAC) with Read Replicas.
  3. C Use CloudFront as a Content Delivery Network to load the articles much faster anywhere in the globe.
  4. D Use EBS Volumes in RAID 0 configuration to store the static data such as the cover images and other media.
  5. E

    Use Lambda with Auto-Healing enabled.
Xem giải thích

Đáp án

**A và C — Dùng RDS Multi-AZ kèm Read Replica, lưu nội dung tĩnh như ảnh bìa trên S3; và dùng CloudFront làm mạng phân phối nội dung.

Vì sao đúng

Đề mô tả một trang tin toàn cầu, và hai phương án lo hai tầng khác nhau: | Yêu cầu | Cách đáp ứng | |---|---| | CSDL bền, sẵn sàng cao, chịu tải đọc lớn | Multi-AZ (HA) + Read Replica (đọc) | | Ảnh bìa và media | S3, bền 11 số 9 | | 5 triệu độc giả toàn cầu | CloudFront |

⚠ Multi-AZ và Read Replica giải quyết hai bài toán khác nhau — dùng CẢ HAI:

Multi-AZ: nếu instance chính chết
    → tự chuyển sang bản dự phòng
    → nhưng bản dự phòng KHÔNG phục vụ đọc
        ↓
    Read Replica: chia tải ĐỌC
    → bài viết được đọc nhiều gấp hàng nghìn
      lần số lần ghi

⚠ Và tỷ lệ đọc/ghi của trang tin biện minh cho Read Replica:

Tác giả cập nhật bài trong tháng đầu
    → vài chục lượt ghi mỗi bài
        ↓
    Độc giả đọc bài
    → hàng chục nghìn lượt đọc mỗi bài
        ↓
    Tỷ lệ đọc/ghi rất lệch
    → tách đọc sang replica là đúng

Tạo Read Replica:

aws rds create-db-read-replica \
  --db-instance-identifier replica-doc-1 \
  --source-db-instance-identifier csdl-tin-tuc \
  --db-instance-class db.r6g.large

⚠ Nhưng ứng dụng phải tự định tuyến, RDS không làm hộ:

Endpoint chính: mọi thao tác ghi
    + endpoint replica: thao tác đọc
        ↓
    Ứng dụng phải biết gọi endpoint nào
    → hoặc dùng RDS Proxy với
      read/write splitting

⚠ Và phải chấp nhận độ trễ nhân bản:

Tác giả sửa bài rồi bấm xem
    → đọc từ replica chưa kịp đồng bộ
        ↓
    Thấy nội dung cũ
    → thao tác vừa ghi phải đọc từ
      instance CHÍNH

CloudFront cho cả nội dung tĩnh lẫn động:

{"CacheBehaviors": {"Items": [
  {"PathPattern": "/anh/*", "TargetOriginId": "s3-media",
   "CachePolicyId": "<toi-uu-cho-tinh>"},
  {"PathPattern": "/api/*", "TargetOriginId": "alb",
   "CachePolicyId": "<khong-cache>"}]},
 "DefaultCacheBehavior": {"TargetOriginId": "alb"}}

⚠ Bài viết cũ là ứng viên hoàn hảo cho cache dài:

Đề nói: sau 6 tháng gần như không sửa nữa
        ↓
    Bài mới: TTL ngắn (vài phút)
    Bài cũ hơn 6 tháng: TTL rất dài
        ↓
    Phần lớn lưu lượng phục vụ từ biên

Vòng đời cho ảnh:

{"Rules": [{
  "ID": "anh-cu-sang-lop-re",
  "Status": "Enabled",
  "Transitions": [
    {"Days": 90, "StorageClass": "STANDARD_IA"},
    {"Days": 365, "StorageClass": "GLACIER_IR"}]}]}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | CSDL chịu được hỏng AZ mà không mất dữ liệu | | | Tải đọc chia sang replica | | | Ảnh phục vụ từ điểm gần độc giả | |

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

  • **B. Dùng RDS Oracle RAC với Read Replica — đây là phương án gần nhất và cũng nói về replica, nhưng RDS không hỗ trợ Oracle RAC; đó là thứ không tồn tại trên dịch vụ này.
  • **D. Dùng EBS RAID 0 để lưu ảnh — RAID 0 không có dự phòng nào: mất một volume là mất toàn bộ; trái ngược với yêu cầu "bền".
  • **E. Dùng Lambda với Auto-Healing — Lambda không có tính năng tên là "Auto-Healing"; và nó không phải nơi lưu trữ nội dung.

Ghi nhớ

⚠ Bốn tầng của trang tin toàn cầu — bảng phải thuộc: | Tầng | Lựa chọn | |---|---| | Phân phối | CloudFront | | Nội dung tĩnh | S3 | | Ứng dụng | ASG + ALB, hoặc container | | CSDL | RDS Multi-AZ + Read Replica |

Từ khoá nhận diện:

"global readers, low latency" → CloudFront "durable static content" → S3 "survive AZ failure, no data loss" → Multi-AZ "heavy read traffic" → Read Replica hoặc ElastiCache

⚠ ElastiCache là lớp nên cân nhắc trước cả Read Replica:

Bài viết được đọc hàng nghìn lần
    → cùng một truy vấn lặp lại
        ↓
    Cache trong Redis: độ trễ micro giây
    → giảm tải CSDL nhiều hơn replica
    → và rẻ hơn

Ba lưu ý về Read Replica: | Lưu ý | Chi tiết | |---|---| | Nhân bản bất đồng bộ, có độ trễ | | | Tối đa 5 bản với RDS, 15 với Aurora | | | Thăng cấp thành instance độc lập được | |

⚠ Theo dõi độ trễ nhân bản:

aws cloudwatch put-metric-alarm \
  --alarm-name replica-tre --namespace AWS/RDS \
  --metric-name ReplicaLag --statistic Average \
  --period 300 --threshold 30 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=DBInstanceIdentifier,Value=replica-doc-1

Độ trễ tăng dần
    → replica không theo kịp instance chính
    → độc giả đọc dữ liệu ngày càng cũ

Ba lưu ý về Aurora so với RDS: | Tiêu chí | Aurora | |---|---| | Độ trễ replica | thường dưới 100ms | | Số replica | tới 15 | | Lưu trữ | tự mở rộng, sáu bản trên ba AZ | | Chuyển đổi | thường dưới 30 giây |

Trang tin có tải đọc lớn và toàn cầu
    → Aurora hợp hơn RDS thường
    → và Aurora Global Database cho
      đọc ở Region khác

Ba lưu ý về S3 cho media: | Lưu ý | Chi tiết | |---|---| | Độ bền 99,999999999% | | | Dùng OAC để bucket không công khai | | | Lifecycle chuyển ảnh cũ sang lớp rẻ | |

Ba lưu ý về CloudFront: | Lưu ý | Chi tiết | |---|---| | TTL theo tuổi bài viết | | | Nén Brotli cho HTML và JSON | | | Origin Shield giảm tải origin thêm một tầng | |

Ba lưu ý về bình luận: | Lưu ý | Chi tiết | |---|---| | Đọc nhiều, ghi vừa — hợp DynamoDB | | | Hoặc bảng riêng trong RDS để không đụng bài viết | | | Cache danh sách bình luận với TTL ngắn | |

⚠ Đề nói bình luận tập trung trong 3 tháng đầu:

Bình luận cũ gần như không đổi
    → cache rất dài
        ↓
    Bình luận bài mới: cache 30 giây
    → vẫn giảm được phần lớn truy vấn

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | CloudFront rẻ hơn truyền thẳng từ ALB | | | Savings Plan cho phần tải nền | | | Lifecycle S3 giảm chi phí ảnh cũ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ từ nhiều châu lục | | | Theo dõi ReplicaLag | | | Buộc chuyển đổi Multi-AZ và bấm giờ | |

Và một lời khuyên: hãy thêm một lớp cache trước khi thêm read replica. Replica là một instance CSDL nữa phải trả tiền và theo dõi, còn cache giải quyết cùng vấn đề với chi phí thấp hơn nhiều — và với nội dung tin tức thì phần lớn lưu lượng vốn là cùng vài trăm bài viết.

Câu 110 Domain - Continuous Improvement for Existing Solutions

An enterprise plans to create a new cloud deployment that will be used by several project teams. The network must be designed so that it allows autonomy for the administrators of the individual AWS accounts to modify their route tables freely. However, the company wants to monitor outbound traffic so it is required to have a centralized and controlled egress Internet connection for all accounts. As more teams are expected to join this deployment, the organization is expected to grow into thousands of AWS accounts.

Which of the following options should the Solutions Architect implement to meet the company requirements?

  1. A

    Create a shared services VPC. On this VPC, host the central assets which include a fleet of firewalls that have a route to the public Internet. Have each spoke VPC connect to the central VPC using VPC peering.
  2. B

    Create a centralized shared VPC. On this VPC, create a subnet that will be associated with each AWS account. Use a fleet of proxy servers to control the outbound Internet traffic.
  3. C

    Create a shared transit gateway. Have each spoke VPC connect to the transit gateway. In a central VPC, deploy a Gateway Load Balancer (GWLB) that fronts a fleet of firewall appliances with routing to the public internet.
  4. D

    Create a centralized transit VPC. Have the VPCs on each AWS account connect to the transit VPC using a VPN connection. Control the outbound Internet traffic using firewall appliances.
Xem giải thích

Đáp án

**C — Tạo Transit Gateway dùng chung, cho mỗi VPC nhánh gắn vào đó, và ở một VPC trung tâm triển khai Gateway Load Balancer (GWLB) đứng trước đội tường lửa có đường ra Internet.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Quản trị viên từng tài khoản tự sửa bảng định tuyến | mỗi VPC vẫn độc lập | | Đường ra Internet tập trung và kiểm soát được | VPC trung tâm có tường lửa | | Giám sát lưu lượng ra | tường lửa ghi log | | Mở rộng tới hàng nghìn tài khoản | Transit Gateway |

⚠ Transit Gateway là lựa chọn duy nhất co giãn tới hàng nghìn VPC: | Cách kết nối | Số kết nối cho N VPC | |---|---| | VPC peering lưới đầy đủ | N × (N−1) / 2 | | Transit Gateway | N |

1.000 VPC với peering
    → 499.500 kết nối
    → vượt xa mọi hạn ngạch
        ↓
    Transit Gateway: 1.000 attachment
    → hạn ngạch mặc định 5.000

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

⚠ Và GWLB là dịch vụ sinh ra cho đúng mẫu này:

Tường lửa của bên thứ ba (Palo Alto,
  Fortinet, Check Point...)
        ↓
    GWLB phân phối lưu lượng tới đội tường lửa
    → dùng giao thức GENEVE, giữ nguyên
      gói tin gốc
        ↓
    Tường lửa thấy IP nguồn và đích thật
    → và GWLB tự thay thế node hỏng

Tạo Transit Gateway và chia sẻ:

aws ec2 create-transit-gateway \
  --description "TGW trung tam" \
  --options DefaultRouteTableAssociation=disable,\
DefaultRouteTablePropagation=disable

aws ram create-resource-share --name chia-se-tgw \
  --resource-arns <arn-tgw> \
  --principals o-abc123 --allow-external-principals false

⚠ Tắt liên kết và lan truyền mặc định là thực hành quan trọng:

Bật mặc định: mọi VPC nói chuyện được
  với mọi VPC
        ↓
    Tắt: phải khai tường minh ai nối ai
    → phân đoạn mạng theo chủ đích
    → VPC phát triển không chạm được
      VPC sản xuất

Định tuyến đường ra qua VPC kiểm tra:

# bang dinh tuyen cua cac VPC nhanh
aws ec2 create-transit-gateway-route \
  --transit-gateway-route-table-id tgw-rtb-nhanh \
  --destination-cidr-block 0.0.0.0/0 \
  --transit-gateway-attachment-id tgw-attach-kiem-tra

Bảng định tuyến trong VPC kiểm tra:

Subnet TGW attachment:
    0.0.0.0/0 → GWLB endpoint
        ↓
Subnet GWLB endpoint:
    0.0.0.0/0 → NAT gateway
        ↓
Subnet NAT:
    0.0.0.0/0 → Internet gateway

⚠ Đây là chỗ hay cấu hình sai nhất — lưu lượng phải đi qua đủ ba chặng:

Thiếu một bảng định tuyến
    → gói tin đi thẳng ra Internet
      KHÔNG qua tường lửa
        ↓
    Không có lỗi nào, mọi thứ vẫn chạy
    → chỉ là việc kiểm soát không hề xảy ra

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một điểm kiểm soát cho mọi đường ra | | | NAT gateway dùng chung, giảm chi phí | | | Thêm tài khoản mới chỉ cần một attachment | |

⚠ Chi phí NAT gateway là lý do kinh tế mạnh cho mô hình này:

Mỗi VPC có NAT riêng: 1.000 NAT gateway
    → chi phí giờ chạy khổng lồ
        ↓
    Tập trung: vài NAT trong VPC kiểm tra
    → tiết kiệm rất lớn

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

  • **D. Tạo transit VPC và cho các VPC nối vào bằng VPN — đây là phương án gần nhất và là kiến trúc chuẩn TRƯỚC KHI có Transit Gateway, nhưng nó đòi tự vận hành đội router ảo, băng thông bị giới hạn bởi VPN, và không co giãn tới hàng nghìn tài khoản.
  • **A. VPC dịch vụ dùng chung với các nhánh nối bằng VPC peering — peering không bắc cầu: lưu lượng không đi xuyên qua VPC trung tâm để ra Internet được.
  • **B. Một VPC dùng chung tập trung với mỗi tài khoản một subnet — trái với yêu cầu "quản trị viên tự do sửa bảng định tuyến"; trong VPC dùng chung, chỉ chủ VPC sửa được định tuyến.

Ghi nhớ

⚠ Bốn cách kết nối VPC — bảng phải thuộc: | Cách | Bắc cầu | Quy mô | |---|---|---| | VPC peering | KHÔNG | vài VPC | | Transit Gateway | CÓ | hàng nghìn | | PrivateLink | không áp dụng | lộ một dịch vụ | | VPC sharing | cùng một VPC | nhiều tài khoản, một mạng |

Từ khoá nhận diện:

"thousands of accounts, centralised egress" → Transit Gateway + GWLB "third-party firewall appliances" → GWLB "AWS-native firewall" → Network Firewall "expose one service privately" → PrivateLink

⚠ AWS Network Firewall là lựa chọn không cần thiết bị bên thứ ba: | Tiêu chí | Network Firewall | GWLB + thiết bị | |---|---|---| | Vận hành | AWS lo | bạn lo | | Luật | Suricata | của nhà cung cấp | | Dùng khi | không có ràng buộc nhà cung cấp | đã đầu tư vào một hãng |

Đội bảo mật đã quen Palo Alto
    → GWLB giữ được công cụ và quy trình
        ↓
    Bắt đầu từ đầu
    → Network Firewall ít việc hơn nhiều

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

pass tls $HOME_NET any -> $EXTERNAL_NET 443
  (tls.sni; content:"cap-nhat.nhacungcap.com";
   startswith; nocase; sid:1;)
drop tls $HOME_NET any -> $EXTERNAL_NET 443 (sid:2;)

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

⚠ Phân đoạn bằng nhiều bảng định tuyến:

Bảng "sản xuất": chỉ tới VPC kiểm tra
Bảng "phát triển": chỉ tới VPC kiểm tra
        ↓
    Hai môi trường KHÔNG thấy nhau
    → mà vẫn dùng chung đường ra

Ba lưu ý về GWLB: | Lưu ý | Chi tiết | |---|---| | Dùng GENEVE cổng 6081 | | | Giữ nguyên gói tin gốc | | | Endpoint đặt trong VPC cần kiểm tra | |

Ba lưu ý về VPC endpoint tập trung: | Lưu ý | Chi tiết | |---|---| | Interface endpoint chia sẻ được qua TGW | | | Cần Route 53 private hosted zone | | | Giảm chi phí so với endpoint mỗi VPC | |

Ba lưu ý về giám sát: | Công cụ | Việc | |---|---| | VPC Flow Logs | luồng ở mức gói | | Network Manager | sơ đồ toàn mạng | | Reachability Analyzer | kiểm đường đi |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | TGW tính phí mỗi attachment mỗi giờ | | | Cộng phí mỗi GB xử lý | | | NAT tập trung tiết kiệm hơn NAT mỗi VPC | |

⚠ Nhưng lưu lượng đi qua TGW bị tính hai lần:

VPC-A → TGW → VPC-B
    → tính phí xử lý ở cả hai chặng
        ↓
    Hai VPC nói chuyện rất nhiều với nhau
    → peering trực tiếp rẻ hơn
    → dùng TGW cho kết nối chung,
      peering cho cặp lưu lượng lớn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Từ VPC nhánh gọi ra một URL bị cấm — phải bị chặn | | | Xem log tường lửa có ghi lưu lượng | | | Chạy Reachability Analyzer từ nhánh ra Internet | |

Và một lời khuyên: hãy kiểm chứng rằng lưu lượng thật sự đi qua tường lửa chứ đừng tin vào sơ đồ. Một bảng định tuyến thiếu sẽ khiến gói tin đi thẳng ra Internet, mọi thứ vẫn chạy bình thường, và bạn chỉ phát hiện ra khi đọc log tường lửa và thấy nó trống rỗng một cách khó hiểu.