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

Tìm thấy 2194 câu.

Câu 661 Design Resilient Architectures

A SaaS analytics company is deploying a microservices-based application on Amazon ECS using the Fargate launch type. The application requires access to a shared, POSIX-compliant file system that is available across multiple Availability Zones for redundancy and availability. To meet compliance requirements, the system must support regional backups and cross-Region data recovery with a recovery point objective (RPO) of no more than 8 hours. A backup strategy will be implemented using AWS Backup to automate replication across Regions. As the lead cloud architect, you are evaluating file storage solutions that align with these requirements.

Which option best meets the application’s availability, durability, and RPO objectives?

  1. A

    Use Amazon Elastic File System (Amazon EFS) with the Standard storage class and configure AWS Backup to create cross-Region backups on a scheduled basis
  2. B

    Deploy Amazon FSx for Lustre and configure a backup plan using AWS Backup for cross-Region replication of the file system metadata
  3. C

    Configure Amazon S3 with the S3 Standard storage class and mount it in containers using Mountpoint for Amazon S3. Use AWS Backup to replicate objects to another Region
  4. D

    Use Amazon FSx for NetApp ONTAP with a Multi-AZ deployment and rely on its native high availability and AWS Backup integration to replicate the file system to another Region automatically
Xem giải thích

Đáp án

A — Dùng Amazon EFS lớp lưu trữ Standard và cấu hình AWS Backup tạo bản sao lưu xuyên Region theo lịch.

Vì sao đúng

Đề nêu bốn ràng buộc, và ràng buộc đầu tiên loại bỏ hầu hết các phương án: | Ràng buộc | Kết luận | |---|---| | **Chạy trên ECS FARGATE | Fargate CHỈ mount được EFS | | Hệ thống tệp POSIX chia sẻ | EFS là NFS, đúng POSIX | | Nhiều AZ | EFS Standard trải ≥ 3 AZ | | RPO ≤ 8 giờ, backup xuyên Region | AWS Backup theo lịch |

Ràng buộc Fargate là điểm quyết định:

ECS trên FARGATE hỗ trợ volume:
    ✓ Amazon EFS
    ✓ bind mount tạm thời
    ✗ FSx for Lustre
    ✗ FSx for NetApp ONTAP
        ↓
    Mọi phương án dùng FSx đều KHÔNG chạy được trên Fargate

(FSx for Windows và FSx for ONTAP dùng được với ECS trên EC2, không dùng được với Fargate.)

Cấu hình volume EFS trong task definition:

{"volumes": [{
   "name": "du-lieu-chung",
   "efsVolumeConfiguration": {
     "fileSystemId": "fs-0abc123",
     "transitEncryption": "ENABLED",
     "authorizationConfig": {"accessPointId": "fsap-0abc", "iam": "ENABLED"}}}]}

Và AWS Backup lo phần RPO 8 giờ:

aws backup create-backup-plan --backup-plan '{
  "BackupPlanName": "efs-xuyen-region",
  "Rules": [{
    "RuleName": "moi-6-gio",
    "TargetBackupVaultName": "vault-chinh",
    "ScheduleExpression": "cron(0 */6 * * ? *)",
    "CopyActions": [{
      "DestinationBackupVaultArn": "arn:aws:backup:us-west-2:...:backup-vault:vault-du-phong"}]}]}'

Backup mỗi 6 giờ → RPO tối đa 6 giờ, thoả yêu cầu ≤ 8 giờ.

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

  • **D. Dùng FSx for NetApp ONTAP Multi-AZ và dựa vào tính sẵn sàng cao dựng sẵn cùng tích hợp AWS Backup — đây là phương án gần nhất và là hệ thống tệp rất mạnh với sẵn sàng cao thật sự, nhưng nó không mount được từ ECS Fargate. Với ECS trên EC2 thì đây sẽ là lựa chọn tốt.
  • **B. Dùng FSx for Lustre với AWS Backup sao chép metadata xuyên Region — hai lỗi: Fargate không mount được Lustre, và sao lưu chỉ metadata thì không khôi phục được dữ liệu.
  • **C. Dùng S3 với Mountpoint for Amazon S3 — không phải POSIX đầy đủ: Mountpoint hỗ trợ một tập con thao tác tệp, không có sửa tại chỗ và không có khoá tệp. Và Mountpoint không dùng được trên Fargate.

Ghi nhớ

Volume được hỗ trợ theo loại triển khai ECS — bảng phải thuộc: | Loại volume | Fargate | EC2 | |---|---|---| | Amazon EFS | ✅ | ✅ | | Bind mount | ✅ | ✅ | | Docker volume | ❌ | ✅ | | FSx for Windows File Server | ❌ | ✅ | | FSx for NetApp ONTAP | ❌ | ✅ | | FSx for Lustre | ❌ | ✅ |

Quy tắc: Fargate + lưu trữ chia sẻ = EFS. Không có ngoại lệ.

Ba lớp lưu trữ của EFS và số AZ: | Lớp | Số AZ | |---|---| | Standard | ≥ 3 ← câu này | | Standard-IA | ≥ 3 | | One Zone | 1 ⚠ | | One Zone-IA | 1 ⚠ |

Yêu cầu "available across multiple AZs" loại bỏ One Zone.

Ba khái niệm của AWS Backup: | Khái niệm | Việc | |---|---| | Backup plan | lịch, thời gian giữ, quy tắc sao chép | | Backup vault | nơi chứa, có thể khoá bằng Vault Lock | | Backup selection | tài nguyên nào được sao lưu |

Ba cách chọn tài nguyên: | Cách | Chi tiết | |---|---| | Theo ARN cụ thể | | | Theo TAG | linh hoạt nhất | | Theo loại tài nguyên | |

{"ListOfTags": [{"ConditionType":"STRINGEQUALS",
                 "ConditionKey":"sao-luu","ConditionValue":"co"}]}

Gắn tag là tài nguyên tự vào kế hoạch sao lưu — không phải cập nhật danh sách.

Ba dịch vụ AWS Backup hỗ trợ: | Nhóm | Dịch vụ | |---|---| | Lưu trữ | EFS, FSx, S3, Storage Gateway | | Database | RDS, Aurora, DynamoDB, DocumentDB, Neptune, Redshift | | Tính toán | EC2, EBS |

Ba khái niệm về mục tiêu khôi phục: | Khái niệm | Nghĩa | |---|---| | RPO (Recovery Point Objective) | mất TỐI ĐA bao nhiêu dữ liệu ← đề nói 8 giờ | | RTO (Recovery Time Objective) | khôi phục trong bao lâu | | — | RPO quyết định TẦN SUẤT backup |

Tính tần suất backup từ RPO:

RPO 8 giờ → backup ít nhất mỗi 8 giờ
    → nên đặt 6 giờ để có biên an toàn
        ↓
    Và phải tính cả thời gian sao chép xuyên Region

Ba lưu ý về sao chép xuyên Region: | Lưu ý | Chi tiết | |---|---| | Sao chép mất thời gian | tính vào RPO thực tế | | Tốn phí truyền dữ liệu | | | Vault đích phải tồn tại trước | |

Ba tính năng bảo mật của AWS Backup: | Tính năng | Chi tiết | |---|---| | Vault Lock | backup KHÔNG XOÁ được, kể cả root | | Mã hoá bằng KMS | | | Sao chép sang tài khoản khác | chống mất cả tài khoản |

Vault Lock chống ransomware:

aws backup put-backup-vault-lock-configuration   --backup-vault-name vault-chinh   --min-retention-days 30 --max-retention-days 365   --changeable-for-days 3

Sau 3 ngày, cấu hình khoá vĩnh viễn.

Ba đặc điểm của EFS phù hợp với container: | Đặc điểm | Chi tiết | |---|---| | Nhiều task mount đồng thời | chia sẻ thật sự | | Tự co giãn dung lượng | không cấp phát trước | | Access Point cách ly từng ứng dụng | thư mục gốc và POSIX user riêng |

Access Point rất hữu ích với container:

aws efs create-access-point --file-system-id fs-0abc   --posix-user Uid=1000,Gid=1000   --root-directory 'Path=/ung-dung-a,CreationInfo={OwnerUid=1000,OwnerGid=1000,Permissions=0755}'

Mỗi ứng dụng một access point:
    → chỉ thấy thư mục của mình
    → POSIX user cố định, không phụ thuộc container

Ba lưu ý về hiệu năng EFS với Fargate: | Lưu ý | Chi tiết | |---|---| | Dùng Elastic throughput | tự co giãn | | Mount target ở mọi AZ có task | giảm độ trễ | | Bật transitEncryption | mã hoá đường truyền |

Ba lưu ý về IAM: | Vai trò | Việc | |---|---| | Task role | quyền của ứng dụng, gồm elasticfilesystem:ClientMount | | Task execution role | kéo image, ghi log | | Backup service role | quyền cho AWS Backup |

Và một lời khuyên: hãy thử khôi phục ở Region đích ít nhất một lần. Backup xuyên Region chạy im lặng và có vẻ ổn cho tới lúc cần dùng — và những thứ như thiếu khoá KMS ở Region đích hoặc thiếu VPC để mount file system khôi phục chỉ lộ ra khi bạn thật sự bấm nút khôi phục.

Câu 662 Design Secure Architectures

An e-commerce company uses a two-tier architecture with application servers in the public subnet and an Amazon RDS MySQL DB in a private subnet. The development team can use a bastion host in the public subnet to access the MySQL database and run queries from the bastion host. However, end-users are reporting application errors. Upon inspecting application logs, the team notices several "could not connect to server: connection timed out" error messages.

Which of the following options represent the root cause for this issue?

  1. A

    The security group configuration for the database instance does not have the correct rules to allow inbound connections from the application servers
  2. B

    The database user credentials (username and password) configured for the application are incorrect
  3. C

    The database user credentials (username and password) configured for the application do not have the required privilege for the given database
  4. D

    The security group configuration for the application servers does not have the correct rules to allow inbound connections from the database instance
Xem giải thích

Đáp án

A — Cấu hình security group của database không có quy tắc cho phép kết nối vào từ các application server.

Vì sao đúng

Đề cho một nghịch lý và một thông báo lỗi cụ thể, cả hai đều chỉ về một nguyên nhân.

Nghịch lý:

Đội phát triển từ BASTION HOST → truy vấn được ✓
Application server → "connection timed out" ✗
        ↓
    Database HOẠT ĐỘNG BÌNH THƯỜNG
    → vấn đề nằm ở ĐƯỜNG ĐI từ application server

Và thông báo lỗi nói rõ tầng nào hỏng:

"could not connect to server: connection TIMED OUT"
        ↓
    TIMEOUT = gói tin KHÔNG TỚI ĐÍCH
    → tầng MẠNG chặn
        ↓
    Nếu là sai mật khẩu, thông báo sẽ là:
        "password authentication failed"
    Nếu là thiếu quyền:
        "permission denied for table ..."

Đây là cách phân biệt quan trọng: | Thông báo | Tầng có vấn đề | |---|---| | connection timed out | MẠNG — security group, NACL, route | | connection refused | tới được máy nhưng không có gì nghe ở cổng đó | | authentication failed | thông tin đăng nhập | | permission denied | quyền trong database |

Và security group của bastion đã được cho phép, nhưng của application server thì chưa:

sg-rds inbound:
    ✓ cổng 3306 từ sg-bastion   ← đó là lý do bastion vào được
    ✗ cổng 3306 từ sg-app        ← THIẾU

Sửa:

aws ec2 authorize-security-group-ingress --group-id sg-rds   --protocol tcp --port 3306 --source-group sg-app

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

  • **D. Security group của application server thiếu quy tắc cho phép kết nối VÀO từ database — đây là phương án gần nhất vì cũng nói về security group, nhưng nó sai chiều: ứng dụng gọi tới database, nên cần quy tắc inbound trên security group của DATABASE. Và security group stateful nên phản hồi tự động được phép.
  • **B. Sai tên đăng nhập hoặc mật khẩu — thông báo lỗi sẽ khác: sai thông tin đăng nhập cho lỗi xác thực, không phải timeout. Timeout nghĩa là chưa tới được database.
  • **C. Thiếu quyền trên database — cùng lý do: thiếu quyền cho lỗi "permission denied" sau khi đã kết nối thành công.

Ghi nhớ

Đọc thông báo lỗi kết nối database — bảng chẩn đoán: | Thông báo | Nguyên nhân | Kiểm tra | |---|---|---| | connection timed out | mạng chặn | security group, NACL, route table | | connection refused | không có gì nghe ở cổng | database chưa chạy, sai cổng | | authentication failed | sai thông tin đăng nhập | user, password | | permission denied | thiếu quyền | GRANT trong database | | no pg_hba.conf entry | database từ chối nguồn | cấu hình của PostgreSQL |

Bảng này tiết kiệm rất nhiều thời gian gỡ lỗi.

Mẫu chuẩn cho kiến trúc ba tầng: | Security group | Inbound cho phép | |---|---| | sg-alb | 0.0.0.0/0 cổng 443 | | sg-app | sg-alb cổng ứng dụng | | sg-rds | sg-app cổng database ← thiếu ở đây | | — | và sg-bastion cho quản trị |

Ba đặc điểm của security group: | Đặc điểm | Chi tiết | |---|---| | STATEFUL | phản hồi tự động được phép | | CHỈ có Allow | không có Deny | | Tham chiếu SG khác được | ← khuyến nghị |

Tính stateful giải thích vì sao phương án D sai:

Ứng dụng gọi database:
    → outbound của sg-app (mặc định mở hết) ✓
    → inbound của sg-rds phải cho phép ← ĐÂY là chỗ cần
        ↓
    Phản hồi từ database đi ngược lại TỰ ĐỘNG được phép
    → KHÔNG cần quy tắc inbound trên sg-app

Ba cổng database phổ biến: | Database | Cổng | |---|---| | MySQL / MariaDB / Aurora MySQL | 3306 | | PostgreSQL / Aurora PostgreSQL | 5432 | | SQL Server | 1433 | | Oracle | 1521 | | Redis | 6379 | | MongoDB / DocumentDB | 27017 |

Ba bước chẩn đoán kết nối:

# ① Kiểm tra tới được cổng không (từ application server)
nc -zv db.abc.rds.amazonaws.com 3306
# hoặc
timeout 5 bash -c "</dev/tcp/db.abc.rds.amazonaws.com/3306" && echo "thong"

# ② Xem quy tắc security group
aws ec2 describe-security-groups --group-ids sg-rds   --query 'SecurityGroups[].IpPermissions'

# ③ Kiểm tra đường đi bằng Reachability Analyzer
aws ec2 create-network-insights-path --source i-0app   --destination <eni-cua-rds> --destination-port 3306 --protocol tcp

Ba nguyên nhân timeout ngoài security group: | Nguyên nhân | Kiểm tra | |---|---| | NACL chặn | stateless — cần mở cả cổng ephemeral chiều ra | | Route table thiếu đường | giữa hai subnet | | Database ở AZ hoặc VPC khác không nối được | |

NACL hay bị bỏ sót:

NACL cho phép inbound 3306 ✓
    nhưng KHÔNG cho phép outbound cổng 1024–65535
        ↓
    Phản hồi không ra được → kết nối TREO → timeout

Ba công cụ chẩn đoán mạng: | Công cụ | Việc | |---|---| | VPC Reachability Analyzer | chỉ ra chính xác thành phần chặn | | VPC Flow Logs | thấy gói REJECT | | nc, telnet, traceroute | thử thủ công |

Đọc VPC Flow Log:

2 123456789012 eni-abc 10.0.1.5 10.0.2.10 45678 3306 6 1 40 ... REJECT OK
                                                              ↑
                                          gói bị TỪ CHỐI — mạng chặn

Ba nguyên tắc thiết kế security group cho database: | Nguyên tắc | Chi tiết | |---|---| | CHỈ cho phép từ SG của tầng ứng dụng | không dùng CIDR | | Database trong PRIVATE subnet | không public | | Bastion hoặc Session Manager cho quản trị | |

Ba cách thay thế bastion host: | Cách | Chi tiết | |---|---| | Systems Manager Session Manager + port forwarding | không cần máy bastion nào | | EC2 Instance Connect Endpoint | | | RDS Proxy | cho ứng dụng |

Port forwarding qua Session Manager:

aws ssm start-session --target i-0app   --document-name AWS-StartPortForwardingSessionToRemoteHost   --parameters '{"host":["db.abc.rds.amazonaws.com"],
                 "portNumber":["3306"],"localPortNumber":["3306"]}'

✓ không cần bastion host
✓ không mở cổng nào ra Internet
✓ mọi phiên có log trong CloudTrail

Ba lưu ý về kết nối database từ ứng dụng: | Lưu ý | Chi tiết | |---|---| | Dùng connection pool | tránh mở đóng liên tục | | Đặt timeout kết nối hợp lý | phát hiện sự cố nhanh | | Có logic thử lại | chịu được chuyển đổi Multi-AZ |

Và một lời khuyên: hãy đọc kỹ thông báo lỗi trước khi động vào cấu hình. "Timed out" và "authentication failed" dẫn tới hai hướng điều tra hoàn toàn khác nhau, và nhầm hướng ở bước đầu thường tốn nhiều thời gian hơn cả việc sửa lỗi thật.

Câu 663 Chọn nhiều đáp án Design Secure Architectures

An enterprise is developing an internal compliance framework for its cloud infrastructure hosted on AWS. The enterprise uses AWS Organizations to group accounts under various organizational units (OUs) based on departmental function. As part of its governance controls, the security team mandates that all Amazon EC2 instances must be tagged to indicate the level of data classification — either 'confidential' or 'public'. Additionally, the organization must ensure that IAM users cannot launch EC2 instances without assigning a classification tag, nor should they be able to remove the tag from running instances. A solutions architect must design a solution to meet these compliance controls while minimizing operational overhead.

Which combination of steps will meet these requirements? (Select two)

  1. A

    Use AWS Identity and Access Management (IAM) permission boundaries to restrict EC2-related actions unless the dataClassification tag is present. Apply these boundaries to all IAM roles used for EC2 provisioning
  2. B

    Create a service control policy (SCP) that denies the ec2:RunInstances API action unless the required tag key is present in the request. Create a second SCP that denies the ec2:DeleteTags action for EC2 resources. Attach both SCPs to the relevant OU in AWS Organizations
  3. C

    Enable AWS Config rules to detect noncompliant EC2 instances. Trigger an AWS Systems Manager Automation runbook to reapply missing tags automatically when noncompliance is detected
  4. D

    Create a tag enforcement Lambda function that runs on a schedule to identify EC2 instances without the required tag. The function sends a notification to administrators and optionally shuts down noncompliant resources
  5. E

    Define a tag policy in AWS Organizations that enforces the dataClassification key and restricts values to 'confidential' and 'public'. Attach this tag policy to the applicable organizational unit (OU) to enforce uniform tagging behavior across accounts
Xem giải thích

Đáp án

B và E.

  • B — SCP chặn ec2:RunInstances khi thiếu tag key và chặn ec2:DeleteTags, gắn vào OU
  • E — Tag policy của AWS Organizations ép key dataClassification với giá trị confidential hoặc public, gắn vào OU

Vì sao đúng

Đề nêu ba yêu cầu, và hai đáp án phân chia rõ ràng: | Yêu cầu | Cơ chế | |---|---| | KHÔNG được tạo instance thiếu tag | SCP chặn RunInstances | | KHÔNG được xoá tag khỏi instance đang chạy | SCP chặn DeleteTags | | Giá trị chỉ được là confidential hoặc public | tag policy ép giá trị |

Vì sao cần CẢ HAI:

SCP:        chặn HÀNH ĐỘNG khi thiếu tag
            → nhưng khó ép DANH SÁCH GIÁ TRỊ hợp lệ

Tag policy: định nghĩa key và GIÁ TRỊ hợp lệ
            → chuẩn hoá cách viết hoa thường
        ↓
    Hai công cụ bù đắp cho nhau

SCP chặn tạo instance thiếu tag:

{"Effect": "Deny",
 "Action": "ec2:RunInstances",
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"Null": {"aws:RequestTag/dataClassification": "true"}}}

Và SCP chặn xoá tag:

{"Effect": "Deny",
 "Action": "ec2:DeleteTags",
 "Resource": "*",
 "Condition": {"ForAnyValue:StringEquals":
   {"aws:TagKeys": "dataClassification"}}}

Tag policy ép giá trị:

{"tags": {
  "dataClassification": {
    "tag_key": {"@@assign": "dataClassification"},
    "tag_value": {"@@assign": ["confidential", "public"]},
    "enforced_for": {"@@assign": ["ec2:instance"]}}}}

Và enforced_for là chi tiết quan trọng:

Không có enforced_for:
    → tag policy chỉ BÁO CÁO không tuân thủ
    → không chặn gì

Có enforced_for:
    → CHẶN thao tác gắn tag với giá trị sai
        ↓
    Đây là khác biệt giữa "biết" và "ngăn"

Và SCP là biện pháp mạnh nhất:

SCP áp cho MỌI principal trong tài khoản
    → kể cả tài khoản ROOT của tài khoản thành viên
        ↓
    Không ai lách được, kể cả quản trị viên

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

  • **A. Dùng IAM permission boundary hạn chế thao tác EC2 khi thiếu tag, gắn vào mọi role dùng để tạo instance — đây là phương án gần nhất và có cơ chế điều kiện tương tự, nhưng nó yếu hơn và nhiều công vận hành hơn: permission boundary phải gắn vào từng role, ai tạo role mới mà quên gắn là lọt. SCP áp cho cả OU tự động.
  • **C. AWS Config phát hiện rồi dùng SSM Automation gắn lại tag — phản ứng SAU KHI vi phạm: instance đã chạy một khoảng thời gian không có tag. Đề yêu cầu ngăn chặn, không phải sửa sau.
  • **D. Lambda theo lịch tìm instance thiếu tag rồi thông báo hoặc tắt — cùng vấn đề, và tệ hơn: chạy theo lịch nên độ trễ lớn hơn, phải tự viết và bảo trì mã, và việc tự động tắt instance là hành động nguy hiểm.

Ghi nhớ

Bốn cơ chế quản trị của AWS Organizations — bảng phải thuộc: | Cơ chế | Việc | |---|---| | Service Control Policy (SCP) | giới hạn quyền TỐI ĐA — chỉ Deny hoặc giới hạn Allow | | Tag policy | chuẩn hoá tag key và giá trị | | Backup policy | kế hoạch sao lưu tập trung | | AI services opt-out policy | từ chối dùng dữ liệu để cải thiện dịch vụ |

Ba đặc điểm quan trọng của SCP: | Đặc điểm | Chi tiết | |---|---| | KHÔNG cấp quyền | chỉ giới hạn | | Áp cho MỌI principal, kể cả root | trừ tài khoản quản lý | | Deny của SCP THẮNG mọi Allow của IAM | |

Dòng cuối là điểm mấu chốt:

SCP Deny + IAM Allow = TỪ CHỐI
    → không có cách nào lách
        ↓
    Đây là biện pháp mạnh nhất trong AWS

Ba khoá điều kiện về tag — bảng cần thuộc: | Khoá | Dùng khi | |---|---| | aws:RequestTag/<key> | tag được gửi TRONG request (lúc tạo) | | aws:ResourceTag/<key> | tag ĐANG CÓ trên tài nguyên | | aws:TagKeys | danh sách key trong request |

Ba toán tử điều kiện hay dùng với tag: | Toán tử | Việc | |---|---| | Null | kiểm tra tag CÓ TỒN TẠI không | | StringEquals | so giá trị chính xác | | ForAnyValue:StringEquals | với danh sách nhiều giá trị |

Null là toán tử đúng để bắt buộc có tag:

{"Null": {"aws:RequestTag/dataClassification": "true"}}

"true" nghĩa là "khoá này KHÔNG tồn tại"
    → kết hợp với Deny = "từ chối nếu thiếu tag"

Ba đặc điểm của tag policy: | Đặc điểm | Chi tiết | |---|---| | Chuẩn hoá cách viết KEY | phân biệt hoa thường | | Giới hạn danh sách GIÁ TRỊ | | | enforced_for để CHẶN, không có thì chỉ báo cáo | |

Ba lưu ý khi viết SCP cho RunInstances: | Lưu ý | Chi tiết | |---|---| | RunInstances tạo NHIỀU loại tài nguyên | instance, volume, ENI | | Chỉ áp điều kiện cho instance/* | không thì chặn nhầm | | Thử ở OU thử nghiệm trước | |

Dòng đầu gây lỗi khó hiểu nếu bỏ qua:

SCP Deny RunInstances khi thiếu tag, Resource: "*"
    → chặn cả việc tạo VOLUME và ENI đi kèm
    → mà những cái đó không nhận tag của instance
        ↓
    Mọi lần khởi động đều thất bại, kể cả khi có tag đúng

Ba cấp gắn SCP: | Cấp | Ảnh hưởng | |---|---| | Root của tổ chức | mọi tài khoản | | OU | mọi tài khoản trong OU ← câu này | | Tài khoản | một tài khoản |

SCP là GIAO của mọi cấp — bị chặn ở bất kỳ cấp nào là bị chặn.

Ba lưu ý quan trọng về SCP: | Lưu ý | Chi tiết | |---|---| | KHÔNG áp cho tài khoản QUẢN LÝ | kể cả gắn ở root | | KHÔNG áp cho service-linked role | | | Phải bật "all features" trong Organizations | |

Dòng đầu là lý do không nên chạy tải trong tài khoản quản lý.

Ba công cụ bổ trợ: | Công cụ | Việc | |---|---| | AWS Config | phát hiện tài nguyên đã có mà chưa tuân thủ | | Resource Groups Tag Editor | gắn tag hàng loạt cho tài nguyên cũ | | Cost allocation tag | quy chi phí theo tag |

SCP ngăn vi phạm MỚI, nhưng tài nguyên CŨ vẫn thiếu tag — cần Config và Tag Editor để dọn.

Ba lợi ích của chiến lược gắn tag tốt: | Lợi ích | Chi tiết | |---|---| | Quy chi phí theo đội hoặc dự án | | | Phân quyền theo tag (ABAC) | | | Tự động hoá theo tag | backup, tắt máy ngoài giờ |

ABAC dựa hoàn toàn vào tag:

{"Effect": "Allow", "Action": "ec2:StopInstances", "Resource": "*",
 "Condition": {"StringEquals":
   {"aws:ResourceTag/doi": "${aws:PrincipalTag/doi}"}}}

Người dùng chỉ thao tác được với tài nguyên của đội mình — một policy cho mọi đội.

Ba bước triển khai: | Bước | Chi tiết | |---|---| | Định nghĩa chuẩn tag và ghi tài liệu | | | Áp tag policy ở chế độ BÁO CÁO trước | xem mức tuân thủ | | Rồi mới bật enforced_for và SCP | |

Và một lời khuyên: hãy chạy tag policy ở chế độ báo cáo ít nhất một tháng trước khi bật cưỡng chế. Báo cáo tuân thủ sẽ cho thấy những cách viết tag mà bạn không ngờ tới — và bật cưỡng chế trước khi biết điều đó sẽ chặn đứng những quy trình tự động đang chạy tốt bằng một cách đặt tên hơi khác.

Câu 664 Design High-Performing Architectures

A digital media startup allows users to submit images through its web portal. These images are uploaded directly into an Amazon S3 bucket. On average, around 200 images are uploaded daily. The company wants to automatically generate a smaller preview version (thumbnail) of each new image and store the resulting thumbnails in a separate Amazon S3 bucket. The team prefers a design that is low-cost, requires minimal infrastructure management, and automatically reacts to new uploads.

Which solution will meet these requirements MOST cost-effectively?

  1. A

    Set up a step-based processing workflow using AWS Glue jobs triggered on a regular interval. Use the jobs to scan the primary S3 bucket for new files and generate thumbnails for any that lack them. Write the thumbnails to a second S3 bucket
  2. B

    Deploy a containerized application on AWS Fargate that polls the S3 bucket every minute to detect new uploads. Configure the container to generate thumbnails and save them in the second bucket
  3. C

    Configure the S3 bucket to send an event notification to an AWS Lambda function each time a new image is uploaded. Use the Lambda function to process the image, create a thumbnail, and store the thumbnail in the second S3 bucket
  4. D

    Enable Amazon S3 Access Analyzer and configure it to call an AWS Lambda function whenever a new image is added. Use the Lambda function to generate and store the thumbnail
Xem giải thích

Đáp án

C — Cấu hình S3 event notification gọi AWS Lambda mỗi khi có ảnh mới; Lambda tạo thumbnail và lưu vào bucket thứ hai.

Vì sao đúng

Đề nêu ba yêu cầu, và cặp S3 event + Lambda đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Chi phí thấp | chỉ trả khi có ảnh — 200 lần/ngày | | Ít quản lý hạ tầng nhất | serverless hoàn toàn | | Tự phản ứng với ảnh mới | S3 event notification kích hoạt ngay |

Phép tính chi phí với 200 ảnh mỗi ngày:

200 ảnh/ngày × 30 ngày = 6.000 lần gọi/tháng
    → Lambda free tier: 1 triệu request/tháng
    → chi phí Lambda: gần như BẰNG 0
        ↓
    So với container chạy 24/7: hàng chục USD/tháng

Và event-driven nghĩa là không có gì chạy khi không có ảnh:

Không có ảnh tải lên → KHÔNG có gì thực thi → KHÔNG tốn tiền
    ↓
    Khác hẳn container polling mỗi phút:
    → 43.200 lần kiểm tra/tháng
    → hầu hết không tìm thấy gì
    → mà vẫn trả tiền đủ 24/7

Cấu hình event notification:

aws s3api put-bucket-notification-configuration --bucket anh-goc   --notification-configuration '{
    "LambdaFunctionConfigurations": [{
      "LambdaFunctionArn": "arn:aws:lambda:ap-northeast-1:...:function:tao-thumbnail",
      "Events": ["s3:ObjectCreated:*"],
      "Filter": {"Key": {"FilterRules": [{"Name": "suffix", "Value": ".jpg"}]}}}]}'

Và cấp quyền cho S3 gọi Lambda:

aws lambda add-permission --function-name tao-thumbnail   --statement-id s3-goi --action lambda:InvokeFunction   --principal s3.amazonaws.com --source-arn arn:aws:s3:::anh-goc

⚠ Và ghi thumbnail vào bucket KHÁC là bắt buộc:

Ghi thumbnail vào CÙNG bucket:
    → tạo object mới → kích hoạt lại Lambda
    → tạo thumbnail của thumbnail
    → VÒNG LẶP VÔ TẬN, hoá đơn tăng không kiểm soát
        ↓
    Đề đã nói đúng: lưu vào bucket THỨ HAI

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

  • **B. Container trên Fargate polling bucket mỗi phút — đây là phương án gần nhất vì cũng tự động, nhưng nó tốn tiền liên tục và có độ trễ: container chạy 24/7 dù chỉ có 200 ảnh mỗi ngày, và ảnh phải chờ tới lần kiểm tra tiếp theo.
  • **A. AWS Glue job chạy theo lịch quét bucket tìm ảnh chưa có thumbnail — sai công cụ và có độ trễ: Glue là dịch vụ ETL cho dữ liệu lớn, quá nặng cho việc tạo thumbnail. Và quét toàn bucket mỗi lần chạy ngày càng chậm khi số ảnh tăng.
  • **D. Bật S3 Access Analyzer gọi Lambda khi có ảnh mới — hiểu sai dịch vụ: IAM Access Analyzer phân tích chính sách truy cập để tìm tài nguyên chia sẻ ra ngoài. Nó không phát ra sự kiện khi có object mới.

Ghi nhớ

Bốn đích của S3 event notification — bảng phải thuộc: | Đích | Đặc điểm | |---|---| | Lambda | xử lý ngay bằng mã ← câu này | | SQS | đệm, xử lý theo lô | | SNS | phát tán cho nhiều đích | | EventBridge | định tuyến phong phú, nhiều đích |

Ba loại sự kiện hay dùng: | Loại | Khi nào | |---|---| | s3:ObjectCreated:* | mọi cách tạo object | | s3:ObjectCreated:Put | chỉ PutObject | | s3:ObjectRemoved:* | xoá object | | s3:ObjectRestore:* | khôi phục từ Glacier |

Ba bộ lọc của event notification: | Bộ lọc | Ví dụ | |---|---| | Prefix | anh-goc/ | | Suffix | .jpg, .png | | — | không lọc được theo kích thước hay metadata |

Lọc bằng suffix tránh xử lý nhầm tệp không phải ảnh.

⚠ Ba cách tránh vòng lặp vô tận: | Cách | Chi tiết | |---|---| | Ghi vào bucket KHÁC | an toàn nhất ← câu này | | Lọc theo prefix khác | goc/ vào, thumb/ ra | | Kiểm tra trong mã trước khi ghi | dễ sai sót |

Đây là lỗi kinh điển với S3 + Lambda — và hậu quả là một hoá đơn rất lớn.

Ba lưu ý về S3 event notification: | Lưu ý | Chi tiết | |---|---| | Giao ÍT NHẤT một lần | Lambda có thể được gọi hai lần | | Thường dưới một giây | nhưng không đảm bảo | | Không đảm bảo THỨ TỰ | |

Dòng đầu đòi hỏi hàm phải idempotent:

def xu_ly(khoa_anh):
    khoa_thumb = f'thumb/{khoa_anh}'
    try:
        s3.head_object(Bucket='anh-thumbnail', Key=khoa_thumb)
        return  # đã có rồi, bỏ qua
    except s3.exceptions.ClientError:
        pass
    tao_thumbnail(khoa_anh, khoa_thumb)

S3 event notification và EventBridge — bảng phân biệt: | | Event notification | EventBridge | |---|---|---| | Cấu hình | trên bucket | quy tắc riêng | | Bộ lọc | prefix, suffix | phong phú (kích thước, metadata) | | Số đích | một cấu hình một đích | nhiều đích | | Cần bật riêng | không | ✅ EventBridgeConfiguration | | Lưu trữ và phát lại sự kiện | ❌ | ✅ |

Ba cấu hình quan trọng cho Lambda xử lý ảnh: | Cấu hình | Chi tiết | |---|---| | Bộ nhớ đủ lớn | ảnh lớn cần nhiều bộ nhớ, và CPU tỷ lệ thuận | | Timeout hợp lý | 30–60 giây thường đủ | | Thư viện xử lý ảnh trong Layer | Pillow, sharp |

Bộ nhớ ảnh hưởng cả tốc độ:

Lambda 512 MB → xử lý ảnh 5 MB mất ~3 giây
Lambda 1769 MB (1 vCPU đầy đủ) → mất ~1 giây
        ↓
    Nhiều khi bộ nhớ CAO HƠN lại RẺ HƠN
    → dùng AWS Lambda Power Tuning để tìm điểm tối ưu

Ba cách xử lý lỗi: | Cách | Chi tiết | |---|---| | Dead letter queue | sự kiện thất bại vào SQS | | Lambda Destinations | đích riêng cho thành công và thất bại | | Retry tự động | 2 lần cho lời gọi bất đồng bộ |

Ba lựa chọn thay thế cho việc tạo thumbnail: | Lựa chọn | Đặc điểm | |---|---| | Lambda | ← câu này, đơn giản nhất | | S3 Object Lambda | biến đổi khi ĐỌC, không lưu bản thứ hai | | CloudFront Functions + Lambda@Edge | biến đổi ở biên |

S3 Object Lambda đáng cân nhắc:

Thay vì tạo và lưu thumbnail:
    → biến đổi ảnh NGAY LÚC ĐỌC
        ↓
    ✓ không tốn dung lượng lưu trữ
    ✓ đổi kích thước bất kỳ lúc nào
    ✗ tốn tính toán mỗi lần đọc

Phù hợp khi cần nhiều kích thước khác nhau.

Ba lưu ý về quyền: | Quyền | Chi tiết | |---|---| | S3 được phép gọi Lambda | add-permission | | Lambda role đọc bucket nguồn | s3:GetObject | | Lambda role ghi bucket đích | s3:PutObject |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | Errors của Lambda | thumbnail không tạo được | | Duration | gần timeout là dấu hiệu xấu | | Throttles | vượt concurrency |

Và một lời khuyên: hãy đặt reserved concurrency cho hàm này. Nếu ai đó tải lên vài nghìn ảnh cùng lúc, Lambda sẽ mở rộng ồ ạt và có thể chiếm hết concurrency của cả tài khoản — với 200 ảnh mỗi ngày, đặt trần ở mức vài chục là quá đủ và bảo vệ mọi hàm khác khỏi bị ảnh hưởng.

Câu 665 Design Resilient Architectures

An e-commerce company uses Amazon Simple Queue Service (Amazon SQS) queues to decouple their application architecture. The engineering team has observed message processing failures for some customer orders.

As a solutions architect, which of the following solutions would you recommend for handling such message failures?

  1. A

    Use a dead-letter queue to handle message processing failures
  2. B

    Use short polling to handle message processing failures
  3. C

    Use long polling to handle message processing failures
  4. D

    Use a temporary queue to handle message processing failures
Xem giải thích

Đáp án

A — Dùng dead-letter queue (DLQ) để xử lý thông điệp lỗi.

Vì sao đúng

Đề nêu vấn đề rõ: một số đơn hàng xử lý thất bại, và DLQ là cơ chế được thiết kế đúng cho việc này.

Không có DLQ:
    Thông điệp lỗi → thử lại → lỗi tiếp → thử lại...
        ↓
    ✗ chặn hàng đợi
    ✗ tiêu tài nguyên vô ích
    ✗ tới khi hết thời gian giữ (mặc định 4 ngày) thì BIẾN MẤT
      → không ai biết đơn hàng nào đã mất

Có DLQ:

Thông điệp thất bại đủ maxReceiveCount lần
    → SQS TỰ ĐỘNG chuyển sang DLQ
        ↓
    ✓ hàng đợi chính thông suốt
    ✓ thông điệp lỗi được GIỮ LẠI để điều tra
    ✓ xử lý lại được sau khi sửa lỗi

Cấu hình:

# ① Tạo DLQ
aws sqs create-queue --queue-name don-hang-dlq

# ② Trỏ hàng đợi chính vào DLQ
aws sqs set-queue-attributes --queue-url <url-hang-doi-chinh>   --attributes '{"RedrivePolicy":
    "{\"deadLetterTargetArn\":\"<arn-dlq>\",\"maxReceiveCount\":\"3\"}"}'

maxReceiveCount là tham số quan trọng:

maxReceiveCount = 3
    → thông điệp được nhận 3 lần mà không bị xoá
    → lần thứ 4 chuyển sang DLQ
        ↓
    Đủ để vượt qua lỗi tạm thời
    Không quá nhiều để chặn hàng đợi

Và đưa thông điệp trở lại sau khi sửa:

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

Tính năng redrive dựng sẵn — không phải tự viết công cụ chuyển.

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

  • **C. Dùng long polling — đây là phương án gần nhất vì cũng là tính năng của SQS, nhưng nó giải quyết vấn đề khác: long polling giảm số lời gọi API rỗng và giảm chi phí bằng cách chờ tới 20 giây khi hàng đợi trống. Hoàn toàn không liên quan tới việc xử lý thất bại.
  • **B. Dùng short polling — cũng chỉ là cách lấy thông điệp, và còn kém hiệu quả hơn long polling.
  • **D. Dùng temporary queue — sai mục đích: temporary queue (qua Temporary Queue Client) dùng cho mẫu request–response, không phải để xử lý thất bại.

Ghi nhớ

Cơ chế DLQ — sơ đồ cần hiểu:

Producer → Hàng đợi chính → Consumer
                  ↓ (thất bại maxReceiveCount lần)
              Dead-letter queue
                  ↓
          Điều tra → sửa lỗi → redrive về hàng đợi chính

Ba lợi ích của DLQ: | Lợi ích | Chi tiết | |---|---| | Cách ly thông điệp lỗi | hàng đợi chính thông suốt | | Giữ lại để điều tra | không mất âm thầm | | Xử lý lại được sau khi sửa | redrive |

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

Dòng giữa quan trọng:

Thời gian giữ tính từ lúc thông điệp vào HÀNG ĐỢI GỐC
    → không đặt lại khi chuyển sang DLQ
        ↓
    Đặt DLQ giữ 14 ngày (tối đa) để có thời gian xử lý

Ba thông số quan trọng của SQS: | Thông số | Mặc định | Ghi chú | |---|---|---| | Visibility timeout | 30 giây | phải ≥ thời gian xử lý | | Message retention | 4 ngày | tối đa 14 ngày | | Receive wait time | 0 (short polling) | đặt 20 để dùng long polling |

Visibility timeout sai gây xử lý trùng:

Xử lý mất 60 giây, visibility timeout 30 giây
    → sau 30 giây thông điệp hiện lại
    → consumer khác nhận và xử lý LẠI
        ↓
    Đơn hàng bị xử lý hai lần
    → và maxReceiveCount tăng dù không có lỗi thật

Short polling và long polling — bảng phân biệt: | | Short polling | Long polling | |---|---|---| | Chờ khi hàng đợi trống | trả về ngay | tới 20 giây | | Số lời gọi API rỗng | nhiều | ít | | Chi phí | cao hơn | thấp hơn | | Độ trễ | thấp | tương đương |

AWS khuyến nghị long polling cho hầu hết trường hợp.

Hai loại hàng đợi SQS: | | Standard | FIFO | |---|---|---| | Thứ tự | không đảm bảo | đảm bảo trong group | | Trùng lặp | có thể | xử lý đúng một lần | | Thông lượng | gần như vô hạn | 300 hoặc 3.000 msg/giây (có batch) | | — | | high throughput mode: tới ~70.000/giây |

Ba nguyên nhân xử lý thất bại phổ biến: | Nguyên nhân | Xử lý | |---|---| | Thông điệp sai định dạng | DLQ — không bao giờ xử lý được | | Dịch vụ phụ thuộc tạm thời hỏng | thử lại rồi mới DLQ | | Lỗi logic trong consumer | sửa mã rồi redrive |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible của DLQ | có lỗi cần điều tra | | ApproximateAgeOfOldestMessage | consumer tụt lại | | NumberOfMessagesReceived | thông lượng |

Đặt alarm cho DLQ là việc bắt buộc:

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

Không có alarm:
    → DLQ đầy lên âm thầm
    → đơn hàng thất bại nằm đó không ai biết
        ↓
    DLQ chỉ có giá trị nếu CÓ NGƯỜI XEM

Ba mẫu xử lý lỗi khác: | Mẫu | Chi tiết | |---|---| | Exponential backoff | thử lại với khoảng cách tăng dần | | Circuit breaker | ngừng gọi dịch vụ đang hỏng | | Idempotency | xử lý trùng không gây hậu quả |

Idempotency là yêu cầu bắt buộc với SQS Standard:

def xu_ly_don(id_don):
    if da_xu_ly(id_don):     # kiểm tra trong DynamoDB
        return
    thuc_hien(id_don)
    ghi_nhan_da_xu_ly(id_don)

SQS Standard giao ít nhất một lần — không idempotent là đơn hàng bị tính tiền hai lần.

Ba dịch vụ khác cũng có DLQ: | Dịch vụ | DLQ | |---|---| | Lambda (bất đồng bộ) | SQS hoặc SNS | | SNS | SQS | | EventBridge | SQS |

Ba việc nên làm khi có thông điệp trong DLQ: | Việc | Chi tiết | |---|---| | Xem nội dung để hiểu nguyên nhân | | | Sửa lỗi ở consumer hoặc dữ liệu | | | Redrive về hàng đợi chính | |

Và một lời khuyên: hãy đặt alarm cho DLQ ngay khi tạo nó. Một DLQ không có cảnh báo chỉ chuyển vấn đề từ "đơn hàng biến mất" sang "đơn hàng nằm trong một hàng đợi không ai mở" — và về phía khách hàng, hai tình huống đó giống hệt nhau.

Câu 666 Chọn nhiều đáp án Design High-Performing Architectures

A global enterprise is modernizing its hybrid IT infrastructure to improve both availability and network performance. The company operates a TCP-based application hosted on Amazon EC2 instances that are deployed across multiple AWS Regions, while a secondary UDP-based component of the application is hosted in its on-premises data centers. These application components must be accessed by customers around the world with minimal latency and consistent uptime.

Which combination of options should a solutions architect implement for the given use case? (Select two)

  1. A

    Set up AWS Direct Connect connections to route all TCP and UDP traffic through a single Region, using static routes and BGP failover
  2. B

    Create a Network Load Balancer (NLB) in each Region to handle the EC2-based TCP traffic. For the UDP-based on-premises workload, configure NLBs in each Region to route to the on-premises endpoints via IP-based target groups
  3. C

    Create a Network Load Balancer (NLB) in each Region to handle the EC2-based TCP traffic. For the UDP-based on-premises workload, configure Application Load Balancers in each Region to route to the on-premises endpoints via IP-based target groups
  4. D

    Configure an AWS Global Accelerator standard accelerator, and register the TCP-based EC2 workloads behind the load balancers
  5. E

    Deploy AWS PrivateLink to connect each on-premises UDP workload to the AWS Regions through interface endpoints exposed by the Network Load Balancers
Xem giải thích

Đáp án

B và D.

  • B — Tạo NLB ở mỗi Region cho lưu lượng TCP của EC2; với tải UDP tại chỗ, cấu hình NLB ở mỗi Region định tuyến tới endpoint tại chỗ qua target group kiểu IP
  • D — Cấu hình AWS Global Accelerator standard và đăng ký các tải TCP phía sau load balancer

Vì sao đúng

Đề nêu ba yêu cầu, và cặp NLB + Global Accelerator đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Ứng dụng TCP trên EC2 nhiều Region | NLB mỗi Region | | Thành phần UDP tại chỗ | NLB hỗ trợ UDP, target group kiểu IP trỏ tới on-premises | | Độ trễ thấp và ổn định toàn cầu | Global Accelerator |

B — NLB là load balancer DUY NHẤT hỗ trợ UDP:

ALB: chỉ HTTP/HTTPS (tầng 7)
NLB: TCP, UDP, TLS (tầng 4)
        ↓
    Tải UDP BẮT BUỘC dùng NLB

Và target group kiểu IP trỏ được tới on-premises:

Target type = ip
    → khai địa chỉ IP bất kỳ trong VPC
    → HOẶC địa chỉ tại chỗ qua VPN / Direct Connect
        ↓
    NLB trong AWS định tuyến tới máy chủ trong trung tâm dữ liệu

aws elbv2 create-target-group --name tg-udp-tai-cho   --protocol UDP --port 5000 --vpc-id vpc-abc --target-type ip

aws elbv2 register-targets --target-group-arn <arn>   --targets Id=192.168.10.20,Port=5000,AvailabilityZone=all

AvailabilityZone=all là bắt buộc cho IP ngoài VPC.

D — Global Accelerator cho hiệu năng và chuyển vùng:

Global Accelerator:
    ✓ 2 IP anycast tĩnh toàn cầu
    ✓ lưu lượng vào mạng riêng của AWS ở edge gần nhất
    ✓ định tuyến tới Region khoẻ mạnh gần nhất
    ✓ chuyển vùng ~30 giây khi Region hỏng
        ↓
    Đúng "minimal latency and consistent uptime"

Và Global Accelerator hỗ trợ CẢ TCP lẫn UDP:

Khác CloudFront (chỉ HTTP/HTTPS)
    → Global Accelerator là lựa chọn duy nhất cho UDP toàn cầu

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

  • **C. NLB cho TCP, nhưng dùng Application Load Balancer cho tải UDP tại chỗ — đây là phương án gần nhất và đúng hoàn toàn ở vế TCP, nhưng nó sai ở vế UDP: ALB hoạt động ở tầng 7 và CHỈ hỗ trợ HTTP/HTTPS. Nó không định tuyến được UDP.
  • **A. Dùng Direct Connect định tuyến mọi lưu lượng TCP và UDP qua MỘT Region với static route và BGP failover — tạo điểm hỏng đơn và tăng độ trễ: dồn lưu lượng toàn cầu về một Region đi ngược yêu cầu độ trễ thấp, và Region đó hỏng là mất tất cả.
  • **E. Dùng AWS PrivateLink nối tải UDP tại chỗ với các Region qua interface endpoint của NLB — sai chiều và sai mục đích: PrivateLink cho phép người tiêu dùng trong AWS truy cập dịch vụ riêng tư. Nó không phải cơ chế phân phối lưu lượng toàn cầu tới on-premises.

Ghi nhớ

Giao thức được hỗ trợ theo load balancer — bảng phải thuộc: | Load balancer | Giao thức | |---|---| | Application Load Balancer | CHỈ HTTP, HTTPS, gRPC | | Network Load Balancer | TCP, UDP, TLS, TCP_UDP | | Gateway Load Balancer | mọi giao thức IP (tầng 3) |

Câu hỏi nào nhắc UDP thì đáp án là NLB, không có ngoại lệ.

Global Accelerator và CloudFront — bảng phân biệt: | | Global Accelerator | CloudFront | |---|---|---| | Giao thức | TCP và UDP, mọi cổng | chỉ HTTP/HTTPS | | Caching | ❌ | ✅ | | Địa chỉ | 2 IP anycast tĩnh | tên miền | | Chuyển vùng Region | ~30 giây | theo origin | | Phù hợp | game, VoIP, IoT, API, IP tĩnh | web, nội dung tĩnh |

Từ khoá nhận diện:

"UDP", "static IP", "non-HTTP", "gaming", "fast regional failover" → Global Accelerator "cache", "HTTP content", "reduce origin load" → CloudFront

Ba loại target type của NLB: | Loại | Định tuyến tới | |---|---| | instance | EC2 trong VPC | | ip | IP bất kỳ — kể cả ON-PREMISES qua VPN/DX ← câu này | | alb | ALB làm target |

Target type ip là cách nối AWS với on-premises qua load balancer.

Ba điều kiện để target ip tới on-premises hoạt động: | Điều kiện | Chi tiết | |---|---| | Kết nối mạng | VPN hoặc Direct Connect | | Route table có đường tới dải on-premises | | | AvailabilityZone=all khi đăng ký | bắt buộc cho IP ngoài VPC |

Ba khái niệm của Global Accelerator: | Khái niệm | Việc | |---|---| | Accelerator | mang 2 IP tĩnh | | Listener | cổng và giao thức (TCP/UDP) | | Endpoint group | một Region, có traffic dial |

Hai loại accelerator: | Loại | Đặc điểm | |---|---| | Standard | định tuyến theo độ trễ và sức khoẻ ← câu này | | Custom routing | ánh xạ cố định IP+cổng → instance cụ thể |

Custom routing dùng cho game nhiều người:

Mỗi người chơi cần vào ĐÚNG instance chứa phiên chơi của họ
    → custom routing ánh xạ cố định
        ↓
    Standard accelerator không làm được điều này

Ba đặc điểm của UDP ảnh hưởng thiết kế: | Đặc điểm | Hệ quả | |---|---| | Không kết nối, không xác nhận | ứng dụng tự lo mất gói | | Health check của NLB cho UDP dùng TCP hoặc HTTP | không có health check UDP thuần | | Giữ IP nguồn quan trọng với UDP | |

Dòng giữa cần lưu ý:

Target group UDP:
    → health check phải dùng giao thức KHÁC (TCP, HTTP, HTTPS)
    → nghĩa là ứng dụng phải mở thêm một cổng cho health check
        ↓
    Thiết kế từ đầu, không phải sửa sau

Ba lợi ích của IP anycast tĩnh: | Lợi ích | Chi tiết | |---|---| | Đưa vào danh sách trắng tường lửa | | | Không phụ thuộc bộ đệm DNS | chuyển vùng tức thì | | Thêm Region không đổi IP | |

Ba yếu tố quyết định định tuyến của Global Accelerator: | Yếu tố | Chi tiết | |---|---| | Sức khoẻ endpoint | không gửi tới endpoint hỏng | | Traffic dial | tỷ lệ lưu lượng mỗi Region | | Vị trí client | Region gần nhất khoẻ mạnh |

Traffic dial cho triển khai dần và rút Region:

aws globalaccelerator update-endpoint-group   --endpoint-group-arn <arn> --traffic-dial-percentage 0

Đặt 0 để rút một Region ra ngay lập tức.

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Global Accelerator cố định | ~0,025 USD/giờ | | Phí truyền dữ liệu cao cấp | theo GB và Region | | NLB mỗi Region | giờ + LCU |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | HealthyEndpointCount | Region nào đang phục vụ | | NewFlowCount | kết nối mới | | ProcessedBytesIn/Out | lưu lượng |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | AWS Shield Standard tự động | chống DDoS tầng 3/4 | | WAF KHÔNG gắn vào Global Accelerator được | | | NLB nay hỗ trợ security group | từ 2023 |

Và một lời khuyên: hãy thiết kế endpoint health check riêng cho tải UDP ngay từ đầu. NLB không kiểm tra được UDP trực tiếp, nên nếu ứng dụng chỉ nghe UDP, bạn sẽ phải thêm một cổng TCP hoặc HTTP chỉ để phục vụ health check — và phát hiện điều đó sau khi đã triển khai nghĩa là phải sửa chính ứng dụng.

Câu 667 Chọn nhiều đáp án Design Resilient Architectures

A digital media company runs its content rendering service on Amazon EC2 instances that are registered with an Application Load Balancer (ALB) using IP-based target groups. The company relies on AWS Systems Manager to manage and patch these instances regularly. According to new compliance requirements, EC2 instances must be safely removed from production traffic during patching to prevent user disruption and maintain application integrity. However, during the most recent patch cycle, the operations team noticed application failures and API timeouts, even though patching succeeded on the instances. You are asked to suggest a reliable and scalable way to ensure safe patching while preserving service availability.

Which solution will best meet the new compliance and operational requirements? (Select two)

  1. A

    Use Amazon CloudWatch Logs Insights to monitor patching success and then manually adjust ALB target group registrations before and after each patch window
  2. B

    Configure a custom Lambda function triggered by an Amazon EventBridge rule that disables the EC2 instance's network interface during the patching window and re-enables it after patching completes
  3. C

    Modify the load balancer configuration to attach EC2 instances using instance ID-based target groups instead of IP-based targets, allowing Systems Manager to directly communicate with instance metadata
  4. D

    Configure Systems Manager Maintenance Windows to coordinate patching and instance removal from the ALB during the defined window
  5. E

    Use AWS Systems Manager Automation with the AWSEC2-PatchLoadBalancerInstance document to manage patching
Xem giải thích

Đáp án

D và E.

  • D — Dùng Systems Manager Maintenance Windows để điều phối việc vá lỗi và việc rút instance khỏi ALB trong khung thời gian đã định
  • E — Dùng Systems Manager Automation với runbook AWSEC2-PatchLoadBalancerInstance

Vì sao đúng

Đề nêu vấn đề rõ: vá lỗi thành công nhưng ứng dụng lỗi và API timeout — nghĩa là instance vẫn nhận lưu lượng trong lúc đang vá.

Vá lỗi mà không rút khỏi ALB:
    → dịch vụ khởi động lại giữa lúc đang xử lý request
    → hoặc máy khởi động lại
        ↓
    Request đang chạy bị đứt → API timeout

E — runbook AWSEC2-PatchLoadBalancerInstance làm đúng việc đó:

Runbook này thực hiện tuần tự:
    ① Rút instance khỏi target group (deregister)
    ② CHỜ deregistration delay — request đang chạy hoàn tất
    ③ Vá lỗi bằng AWS-RunPatchBaseline
    ④ Khởi động lại nếu cần
    ⑤ Đăng ký lại vào target group
    ⑥ Chờ health check báo khoẻ
        ↓
    Không có request nào bị đứt

D — Maintenance Window điều phối theo lịch:

Maintenance Window:
    ✓ khung giờ cố định (ví dụ 2h sáng chủ nhật)
    ✓ chọn instance theo tag
    ✓ giới hạn số máy vá đồng thời
    ✓ dừng nếu tỷ lệ lỗi vượt ngưỡng
        ↓
    Vá theo đợt, luôn còn máy phục vụ

aws ssm create-maintenance-window --name va-loi-hang-tuan   --schedule "cron(0 2 ? * SUN *)" --duration 4 --cutoff 1   --allow-unassociated-targets

aws ssm register-task-with-maintenance-window   --window-id mw-abc --task-arn AWSEC2-PatchLoadBalancerInstance   --task-type AUTOMATION --max-concurrency "25%" --max-errors "1"

max-concurrency 25% là tham số quan trọng:

Vá 25% số máy mỗi lượt
    → 75% còn lại vẫn phục vụ
        ↓
    Không bao giờ mất năng lực phục vụ

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

  • **C. Đổi từ IP-based target group sang instance ID-based để Systems Manager giao tiếp trực tiếp với metadata — đây là phương án gần nhất vì nó nói về target group, nhưng nó dựa trên tiền đề sai: Systems Manager làm việc qua SSM Agent, hoàn toàn không liên quan tới loại target group. Đổi target type không giải quyết được việc rút máy khỏi lưu lượng.
  • **B. Lambda kích hoạt bởi EventBridge vô hiệu hoá network interface của instance trong lúc vá — cách làm thô bạo và nguy hiểm: tắt ENI cắt đứt mọi kết nối đang chạy (đúng vấn đề cần tránh), và còn cắt luôn kết nối của SSM Agent nên việc vá cũng không chạy được.
  • **A. Dùng CloudWatch Logs Insights theo dõi rồi điều chỉnh đăng ký target group THỦ CÔNG — không mở rộng được: đề yêu cầu "reliable and scalable", mà thao tác thủ công trước và sau mỗi lần vá là đi ngược lại.

Ghi nhớ

Ba thành phần của AWS Systems Manager cho việc vá lỗi: | Thành phần | Việc | |---|---| | Patch Manager | định nghĩa patch baseline, quét và cài | | Maintenance Windows | khung giờ và điều phối | | Automation | runbook nhiều bước ← câu này |

Ba runbook Automation hay dùng: | Runbook | Việc | |---|---| | AWSEC2-PatchLoadBalancerInstance | rút khỏi LB → vá → đăng ký lại | | AWS-RunPatchBaseline | chỉ vá, không đụng LB | | AWS-UpdateSSMAgent | cập nhật agent |

Ba tham số quan trọng của Maintenance Window: | Tham số | Việc | |---|---| | duration | tổng thời gian cửa sổ | | cutoff | ngừng bắt đầu tác vụ mới trước khi hết bao lâu | | max-concurrency | bao nhiêu máy cùng lúc | | max-errors | dừng nếu lỗi vượt ngưỡng |

Hai tham số cuối là cơ chế an toàn:

max-concurrency 25%, max-errors 1
    → vá 25% mỗi lượt
    → có 1 máy lỗi là DỪNG HẲN
        ↓
    Một bản vá hỏng không lan ra cả đội máy

Ba cấu hình liên quan tới việc rút máy êm ái: | Cấu hình | Chi tiết | |---|---| | Deregistration delay | thời gian chờ request đang chạy hoàn tất (mặc định 300 giây) | | Connection draining | tên cũ của cùng cơ chế | | ASG lifecycle hook | chạy hành động trước khi chấm dứt |

aws elbv2 modify-target-group-attributes --target-group-arn <arn>   --attributes Key=deregistration_delay.timeout_seconds,Value=120

Deregistration delay quá ngắn vẫn gây lỗi:

Request dài 60 giây, deregistration delay 30 giây
    → ALB cắt kết nối khi request chưa xong
        ↓
    Đặt bằng thời gian request dài nhất + biên

Ba yêu cầu để Systems Manager quản lý được instance: | Yêu cầu | Chi tiết | |---|---| | SSM Agent đã cài và chạy | có sẵn trên hầu hết AMI của AWS | | Instance profile có AmazonSSMManagedInstanceCore | | | Kết nối tới endpoint của SSM | NAT Gateway hoặc VPC endpoint |

VPC endpoint cho instance ở private subnet:

Cần 3 interface endpoint:
    com.amazonaws.<region>.ssm
    com.amazonaws.<region>.ssmmessages
    com.amazonaws.<region>.ec2messages
        ↓
    Thiếu một cái là instance không hiện trong Fleet Manager

Ba khái niệm của Patch Manager: | Khái niệm | Việc | |---|---| | Patch baseline | quy tắc bản vá nào được duyệt | | Patch group | nhóm instance theo tag Patch Group | | Compliance | báo cáo máy nào đã vá |

Ba chiến lược triển khai bản vá: | Chiến lược | Đặc điểm | |---|---| | Vá tại chỗ theo đợt | ← câu này | | Thay máy (immutable) | AMI mới, thay toàn bộ instance | | Blue/green | môi trường song song |

Chiến lược thay máy đáng cân nhắc:

Thay vì vá máy đang chạy:
    → dựng AMI mới đã vá
    → ASG instance refresh thay dần
        ↓
    ✓ mọi máy giống hệt nhau
    ✓ quay lại dễ (đổi về AMI cũ)
    ✓ không có "máy đã vá một nửa"

aws autoscaling start-instance-refresh   --auto-scaling-group-name asg-web   --preferences '{"MinHealthyPercentage":75,"InstanceWarmup":300}'

Ba lưu ý khi vá máy đứng sau load balancer: | Lưu ý | Chi tiết | |---|---| | Luôn rút khỏi target group trước | | | Chờ deregistration delay hết | | | Chờ health check báo khoẻ trước khi vá máy tiếp theo | |

Ba cách theo dõi việc vá lỗi: | Cách | Việc | |---|---| | Patch compliance report | máy nào thiếu bản vá | | CloudWatch Logs của Automation | chi tiết từng bước | | EventBridge khi Automation thất bại | cảnh báo |

Ba lưu ý về lịch bảo trì: | Lưu ý | Chi tiết | |---|---| | Chọn giờ thấp điểm thật sự | theo múi giờ người dùng | | Chừa đủ thời gian cho toàn bộ đội máy | | | Thử ở môi trường staging trước | |

Và một lời khuyên: hãy đo thời gian request dài nhất của ứng dụng rồi đặt deregistration delay lớn hơn con số đó. Đây là nguyên nhân phổ biến nhất khiến việc vá lỗi "đúng quy trình" vẫn gây lỗi cho người dùng — máy đã được rút khỏi ALB, nhưng chưa đủ lâu để những request đang chạy kịp hoàn tất.

Câu 668 Design Resilient Architectures

A company's cloud architect has set up a solution that uses Amazon Route 53 to configure the DNS records for the primary website with the domain pointing to the Application Load Balancer (ALB). The company wants a solution where users will be directed to a static error page, configured as a backup, in case of unavailability of the primary website.

Which configuration will meet the company's requirements, while keeping the changes to a bare minimum?

  1. A

    Set up Amazon Route 53 active-passive type of failover routing policy. If Amazon Route 53 health check determines the Application Load Balancer endpoint as unhealthy, the traffic will be diverted to a static error page, hosted on Amazon S3 bucket
  2. B

    Set up Amazon Route 53 active-active type of failover routing policy. If Amazon Route 53 health check determines the Application Load Balancer endpoint as unhealthy, the traffic will be diverted to a static error page, hosted on Amazon S3 bucket
  3. C

    Use Amazon Route 53 Weighted routing to give minimum weight to Amazon S3 bucket that holds the error page to be displayed. In case of primary failure, the requests get routed to the error page
  4. D

    Use Amazon Route 53 Latency-based routing. Create a latency record to point to the Amazon S3 bucket that holds the error page to be displayed
Xem giải thích

Đáp án

A — Cấu hình Route 53 failover routing policy kiểu active-passive: khi health check xác định ALB không khoẻ, lưu lượng chuyển sang trang lỗi tĩnh trên S3.

Vì sao đúng

Đề nêu ba yêu cầu, và failover routing đáp ứng chính xác: | Yêu cầu | Cơ chế | |---|---| | Trang lỗi là BẢN DỰ PHÒNG | active-passive: chỉ dùng khi primary hỏng | | Chuyển khi website chính không khả dụng | health check của Route 53 | | Thay đổi TỐI THIỂU | chỉ thêm bản ghi DNS và health check |

Cấu hình gồm ba phần:

① Health check theo dõi ALB
② Bản ghi PRIMARY  → ALB, gắn health check
③ Bản ghi SECONDARY → S3 static website
        ↓
    Primary khoẻ  → mọi lưu lượng tới ALB
    Primary hỏng  → Route 53 trả bản ghi secondary

Tạo health check:

aws route53 create-health-check --caller-reference kiem-tra-alb   --health-check-config '{
    "Type": "HTTPS", "FullyQualifiedDomainName": "alb.example.com",
    "Port": 443, "ResourcePath": "/health",
    "RequestInterval": 30, "FailureThreshold": 3}'

Và hai bản ghi failover:

{"Changes": [
  {"Action": "UPSERT", "ResourceRecordSet": {
     "Name": "www.example.com", "Type": "A",
     "SetIdentifier": "chinh", "Failover": "PRIMARY",
     "HealthCheckId": "<id-health-check>",
     "AliasTarget": {"DNSName": "<dns-alb>", "HostedZoneId": "<zone-alb>",
                     "EvaluateTargetHealth": true}}},
  {"Action": "UPSERT", "ResourceRecordSet": {
     "Name": "www.example.com", "Type": "A",
     "SetIdentifier": "du-phong", "Failover": "SECONDARY",
     "AliasTarget": {"DNSName": "s3-website-ap-northeast-1.amazonaws.com",
                     "HostedZoneId": "<zone-s3>", "EvaluateTargetHealth": false}}}]}

⚠ Điều kiện bắt buộc với S3 static website:

Tên BUCKET phải TRÙNG với tên miền
    → bucket tên "www.example.com"
        ↓
    Đây là yêu cầu của S3 website endpoint,
    và là lỗi cấu hình hay gặp nhất trong mẫu này

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

  • **B. Dùng failover routing kiểu ACTIVE-ACTIVE — đây là phương án gần nhất vì cùng là failover routing, nhưng nó sai kiểu: active-active gửi lưu lượng tới mọi endpoint khoẻ mạnh đồng thời, nghĩa là một phần người dùng sẽ thấy trang lỗi ngay cả khi website hoạt động bình thường. (Và nói chặt thì "active-active failover" trong Route 53 được thực hiện bằng weighted hoặc latency routing, không phải bằng failover policy.)
  • **C. Dùng weighted routing với trọng số nhỏ cho S3 — vẫn gửi một phần lưu lượng tới trang lỗi khi mọi thứ bình thường: trọng số nhỏ nghĩa là ít, không phải bằng không.
  • **D. Dùng latency-based routing trỏ tới S3 — hoàn toàn không phải cơ chế dự phòng: latency routing chọn endpoint có độ trễ thấp nhất, và S3 gần người dùng có thể được chọn ngay cả khi ALB khoẻ.

Ghi nhớ

Bảy chính sách định tuyến của Route 53 — bảng phải thuộc: | Chính sách | Việc | |---|---| | Simple | một bản ghi, không health check | | Failover | active-passive — chính và dự phòng ← câu này | | Weighted | chia theo tỷ lệ | | Latency-based | Region có độ trễ thấp nhất | | Geolocation | theo vị trí địa lý của người dùng | | Geoproximity | theo khoảng cách, có bias | | Multivalue answer | tới 8 bản ghi khoẻ mạnh | | IP-based | theo dải IP của client |

Từ khoá nhận diện:

"backup site", "standby", "when primary fails" → failover "canary", "blue/green", "percentage of traffic" → weighted "lowest latency", "closest Region" → latency-based "comply with regulations by country" → geolocation

Ba loại health check của Route 53: | Loại | Kiểm tra | |---|---| | Endpoint | gọi HTTP/HTTPS/TCP tới địa chỉ | | Calculated | kết hợp nhiều health check khác | | CloudWatch alarm | dựa trên trạng thái alarm |

Calculated health check hữu ích:

Kết hợp: ALB khoẻ VÀ database khoẻ
    → chỉ một trong hai hỏng là chuyển vùng
        ↓
    Phản ánh sức khoẻ của cả HỆ THỐNG

Ba tham số của health check: | Tham số | Mặc định | |---|---| | RequestInterval | 30 giây (hoặc 10 giây, tính phí cao hơn) | | FailureThreshold | 3 lần liên tiếp | | — | thời gian phát hiện ≈ interval × threshold |

Tính thời gian chuyển vùng:

Phát hiện:      30 giây × 3 = 90 giây
TTL của DNS:    60 giây (nếu đặt vậy)
        ↓
    Tổng: khoảng 2,5 phút trước khi người dùng thấy trang dự phòng

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | TTL thấp = chuyển vùng nhanh | 60 giây là hợp lý | | TTL thấp = nhiều truy vấn DNS hơn | tốn hơn chút ít | | Trình phân giải có thể bỏ qua TTL rất thấp | |

Ba điều kiện cho S3 static website: | Điều kiện | Chi tiết | |---|---| | Tên bucket TRÙNG tên miền | ← bắt buộc | | Bật static website hosting | | | Block Public Access phải TẮT + bucket policy công khai | |

aws s3 website s3://www.example.com/ --index-document index.html   --error-document error.html

Ba lưu ý về alias record: | Lưu ý | Chi tiết | |---|---| | MIỄN PHÍ (khác CNAME) | | | Dùng được ở đỉnh tên miền (zone apex) | CNAME KHÔNG dùng được | | EvaluateTargetHealth tự kiểm tra sức khoẻ ALB | |

Dòng cuối là chi tiết hay bị bỏ qua:

EvaluateTargetHealth = true với alias trỏ tới ALB
    → Route 53 tự biết ALB có target khoẻ không
    → không cần health check riêng trong một số trường hợp
        ↓
    Nhưng health check riêng vẫn tốt hơn — nó kiểm tra
      đường đi thật của ứng dụng

Ba lưu ý về trang lỗi tĩnh: | Lưu ý | Chi tiết | |---|---| | Giữ thật đơn giản | không phụ thuộc gì bên ngoài | | Có thông tin liên hệ và thời gian dự kiến | | | Đặt CloudFront trước nếu cần HTTPS | S3 website endpoint CHỈ HTTP |

Dòng cuối rất quan trọng:

S3 static website endpoint không hỗ trợ HTTPS
    → người dùng đang ở HTTPS sẽ nhận cảnh báo bảo mật
        ↓
    Đặt CloudFront trước S3 để có HTTPS

Ba cách cải thiện thiết kế này: | Cách | Lợi ích | |---|---| | CloudFront trước S3 | HTTPS và độ trễ thấp | | Calculated health check | phản ánh cả tầng dữ liệu | | Cảnh báo SNS khi chuyển vùng | biết ngay khi xảy ra |

aws cloudwatch put-metric-alarm --alarm-name website-chinh-hong   --metric-name HealthCheckStatus --namespace AWS/Route53   --dimensions Name=HealthCheckId,Value=<id>   --statistic Minimum --period 60 --threshold 1   --comparison-operator LessThanThreshold   --alarm-actions <arn-sns>

Ba việc nên làm định kỳ: | Việc | Chi tiết | |---|---| | THỬ chuyển vùng thật | vô hiệu hoá health check tạm thời | | Kiểm tra trang lỗi hiển thị đúng | | | Đo thời gian chuyển vùng thực tế | |

Và một lời khuyên: hãy thử chuyển vùng bằng cách đảo ngược health check (--inverted) thay vì chờ sự cố thật. Đó là cách duy nhất biết chắc trang dự phòng hiển thị đúng, tên bucket khớp tên miền, và thời gian chuyển vùng đúng như bạn tính — cả ba thứ đều có thể sai mà không có dấu hiệu nào cho tới lúc cần dùng.

Câu 669 Chọn nhiều đáp án Design Secure Architectures

A pharmaceutical company is considering moving to AWS Cloud to accelerate the research and development process. Most of the daily workflows would be centered around running batch jobs on Amazon EC2 instances with storage on Amazon Elastic Block Store (Amazon EBS) volumes. The CTO is concerned about meeting HIPAA compliance norms for sensitive data stored on Amazon EBS.

Which of the following options outline the correct capabilities of an encrypted Amazon EBS volume? (Select three)

  1. A

    Data at rest inside the volume is NOT encrypted
  2. B

    Any snapshot created from the volume is NOT encrypted
  3. C

    Any snapshot created from the volume is encrypted
  4. D

    Data moving between the volume and the instance is NOT encrypted
  5. E

    Data at rest inside the volume is encrypted
  6. F

    Data moving between the volume and the instance is encrypted
Xem giải thích

Đáp án

C, E và F.

  • C — Mọi snapshot tạo từ volume đều được mã hoá
  • E — Dữ liệu at rest bên trong volume được mã hoá
  • F — Dữ liệu di chuyển giữa volume và instance được mã hoá

Vì sao đúng

Mã hoá EBS bảo vệ dữ liệu ở ba nơi, và ba đáp án chính là ba nơi đó.

① Dữ liệu AT REST trong volume        → mã hoá ✓ (đáp án E)
② Dữ liệu TRÊN ĐƯỜNG giữa volume và instance → mã hoá ✓ (đáp án F)
③ Mọi SNAPSHOT tạo từ volume          → mã hoá ✓ (đáp án C)
④ Mọi VOLUME tạo từ snapshot đó       → mã hoá ✓

Vế thứ hai hay bị bỏ qua:

Nhiều người nghĩ mã hoá EBS chỉ là mã hoá at rest
    → thực tế nó cũng mã hoá dữ liệu giữa máy chủ EC2 và tầng lưu trữ
        ↓
    Đây là điểm quan trọng cho tuân thủ HIPAA —
    tiêu chuẩn đòi bảo vệ dữ liệu ở CẢ HAI trạng thái

Và tính "lan truyền" của mã hoá là đặc điểm thiết kế:

Volume mã hoá → snapshot mã hoá → volume mới mã hoá → AMI mã hoá
        ↓
    KHÔNG có cách nào tạo bản sao KHÔNG mã hoá
    từ một volume đã mã hoá

Bật mã hoá:

aws ec2 create-volume --availability-zone ap-northeast-1a   --size 500 --volume-type gp3 --encrypted --kms-key-id <arn-khoa>

Và bật mã hoá mặc định cho cả Region:

aws ec2 enable-ebs-encryption-by-default
aws ec2 modify-ebs-default-kms-key-id --kms-key-id <arn-khoa>

Sau đó MỌI volume mới đều được mã hoá tự động
    → không phụ thuộc người tạo có nhớ hay không
        ↓
    Đây là việc nên làm đầu tiên cho tài khoản có yêu cầu tuân thủ

Và mã hoá hoàn toàn trong suốt:

✓ không cần sửa ứng dụng
✓ không ảnh hưởng IOPS hay thông lượng đáng kể
✓ hệ điều hành không biết có mã hoá

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

  • **B. Snapshot tạo từ volume KHÔNG được mã hoá — đây là phương án gần nhất vì nó nói đúng chủ đề snapshot, nhưng ngược với sự thật: snapshot của volume mã hoá luôn được mã hoá. Đây chính là điểm câu hỏi kiểm tra.
  • **A. Dữ liệu at rest KHÔNG được mã hoá — trái ngược với chính định nghĩa của volume mã hoá.
  • **D. Dữ liệu giữa volume và instance KHÔNG được mã hoá — cũng sai: đường truyền đó được mã hoá.

Ghi nhớ

Bốn thứ được mã hoá khi bật mã hoá EBS — bảng phải thuộc: | Thứ | Mã hoá | |---|---| | Dữ liệu at rest trong volume | ✅ | | Dữ liệu giữa volume và instance | ✅ | | Mọi snapshot từ volume đó | ✅ | | Mọi volume tạo từ snapshot đó | ✅ |

Ba đặc điểm của mã hoá EBS: | Đặc điểm | Chi tiết | |---|---| | Trong suốt hoàn toàn | không sửa ứng dụng | | Ảnh hưởng hiệu năng không đáng kể | | | Dùng khoá KMS | AWS managed hoặc customer managed |

Ba lưu ý quan trọng về việc bật mã hoá: | Lưu ý | Chi tiết | |---|---| | KHÔNG mã hoá được volume ĐANG CÓ trực tiếp | | | Phải: snapshot → copy CÓ mã hoá → tạo volume mới | | | KHÔNG gỡ mã hoá được | một chiều |

Quy trình mã hoá volume đã có:

aws ec2 create-snapshot --volume-id vol-cu --description "truoc khi ma hoa"
aws ec2 copy-snapshot --source-snapshot-id snap-cu   --source-region ap-northeast-1 --encrypted --kms-key-id <arn>
aws ec2 create-volume --snapshot-id snap-ma-hoa   --availability-zone ap-northeast-1a --volume-type gp3
# rồi tháo volume cũ, gắn volume mới

Ba loại khoá KMS dùng được: | Loại | Đặc điểm | |---|---| | aws/ebs (AWS managed) | mặc định, miễn phí lưu khoá | | Customer managed key | kiểm soát policy, audit, xoay vòng | | — | với HIPAA, customer managed key được khuyến nghị |

Ba lợi ích của customer managed key: | Lợi ích | Chi tiết | |---|---| | Key policy riêng | kiểm soát ai dùng được | | Audit qua CloudTrail | ai giải mã, khi nào | | Xoay vòng cấu hình được | |

Ba yêu cầu HIPAA liên quan tới EBS: | Yêu cầu | Cơ chế | |---|---| | Mã hoá at rest | mã hoá EBS | | Mã hoá in transit | mã hoá EBS + TLS ở tầng ứng dụng | | Kiểm soát truy cập và audit | IAM + CloudTrail |

Và cần ký BAA với AWS:

Business Associate Addendum (BAA):
    → thoả thuận pháp lý bắt buộc cho tải HIPAA
    → chỉ dùng dịch vụ trong danh sách HIPAA-eligible
        ↓
    Mã hoá là điều kiện cần, không phải điều kiện đủ

Ba lưu ý về snapshot mã hoá: | Lưu ý | Chi tiết | |---|---| | Chia sẻ được nhưng phải chia sẻ CẢ KHOÁ KMS | | | KHÔNG chia sẻ công khai được | snapshot mã hoá | | Sao chép xuyên Region cần khoá của Region ĐÍCH | |

Chia sẻ snapshot mã hoá cần hai bước:

# ① Cho phép tài khoản kia dùng khoá KMS (trong key policy)
# ② Chia sẻ snapshot
aws ec2 modify-snapshot-attribute --snapshot-id snap-abc   --attribute createVolumePermission --operation-type add   --user-ids 123456789012

Thiếu bước một thì tài khoản kia thấy snapshot nhưng không tạo volume được.

Ba loại instance store và mã hoá: | Loại | Mã hoá | |---|---| | NVMe instance store | mã hoá TỰ ĐỘNG, không tắt được | | EBS volume | tuỳ chọn | | — | instance store luôn mất dữ liệu khi stop |

Ba lớp mã hoá nên có cho tải HIPAA: | Lớp | Cơ chế | |---|---| | Lưu trữ (EBS, S3, RDS) | KMS | | Đường truyền | TLS cho mọi kết nối | | Ứng dụng | mã hoá trường nhạy cảm nếu cần |

Ba cách kiểm tra tuân thủ: | Cách | Việc | |---|---| | AWS Config rule encrypted-volumes | phát hiện volume chưa mã hoá | | Security Hub | tổng hợp theo chuẩn | | AWS Audit Manager | khung HIPAA dựng sẵn |

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "volume-phai-ma-hoa",
  "Source": {"Owner":"AWS","SourceIdentifier":"ENCRYPTED_VOLUMES"}}'

Ba biện pháp ngăn tạo volume chưa mã hoá: | Biện pháp | Chi tiết | |---|---| | Bật ebs-encryption-by-default | đơn giản nhất | | SCP chặn tạo volume không mã hoá | mạnh nhất | | Config rule + remediation | phản ứng sau |

SCP chặn:

{"Effect": "Deny", "Action": "ec2:CreateVolume", "Resource": "*",
 "Condition": {"Bool": {"ec2:Encrypted": "false"}}}

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Mã hoá EBS KHÔNG tính phí thêm | | | Customer managed key: ~1 USD/tháng | | | Lời gọi KMS khi gắn volume | không đáng kể |

Và một lời khuyên: hãy bật ebs-encryption-by-default cho mọi Region đang dùng, không chỉ Region chính. Nó là cấu hình theo Region, và một volume tạo ở Region ít dùng vẫn là một volume không mã hoá trong báo cáo tuân thủ — mà không ai nghĩ tới việc kiểm tra ở đó cho tới khi kiểm toán viên hỏi.

Câu 670 Design Resilient Architectures

A fintech company currently operates a real-time search and analytics platform on-premises. This platform ingests streaming data from multiple data-producing systems and provides immediate search capabilities and interactive visualizations for end users. As part of its cloud migration strategy, the company wants to rearchitect the solution using AWS-native services.

Which of the following represents the most efficient solution?

  1. A

    Ingest and process the streaming data using Amazon Kinesis Data Streams, then index the data with Amazon OpenSearch Service for real-time search capabilities. Use Amazon QuickSight to build interactive dashboards and visualizations based on the indexed data
  2. B

    Deploy Amazon EC2 instances to handle the ingestion and processing of streaming data, storing the results in Amazon S3. Utilize Amazon Athena to search the stored data, and use Amazon Managed Grafana to generate dashboards and visual insights
  3. C

    Use Amazon Elastic Container Service (Amazon ECS) with AWS Fargate to ingest the data into Amazon DynamoDB to facilitate full text search. Use Amazon CloudWatch to create dashboards and query the data
  4. D

    Use AWS Glue streaming ETL to process data streams and load the data into Amazon Redshift. Use Amazon Redshift’s full-text search capabilities for querying. Use Amazon QuickSight for data visualizations
Xem giải thích

Đáp án

A — Kinesis Data Streams nạp và xử lý luồng, Amazon OpenSearch Service lập chỉ mục cho tìm kiếm thời gian thực, Amazon QuickSight dựng bảng điều khiển trực quan.

Vì sao đúng

Đề nêu ba chức năng, và mỗi chức năng có dịch vụ AWS tương ứng: | Chức năng trong đề | Dịch vụ | |---|---| | Nạp dữ liệu luồng từ nhiều nguồn | Kinesis Data Streams | | Tìm kiếm TỨC THÌ | OpenSearch Service | | Trực quan hoá tương tác | QuickSight (hoặc OpenSearch Dashboards) |

Và đây chính là bản đối chiếu một-một với nền tảng tại chỗ:

Nền tảng tại chỗ điển hình:
    Logstash / Kafka  →  Elasticsearch  →  Kibana
        ↓ chuyển sang AWS
    Kinesis Data Streams → OpenSearch Service → QuickSight/Dashboards

Vì sao OpenSearch là mảnh ghép quyết định:

"provides IMMEDIATE SEARCH capabilities"
        ↓
    Cần chỉ mục ngược (inverted index) cho tìm kiếm toàn văn
    → OpenSearch được thiết kế đúng cho việc này
        ↓
    Không có dịch vụ AWS nào khác làm tìm kiếm toàn văn
      với độ trễ thấp ở quy mô luồng

Kiến trúc triển khai:

aws kinesis create-stream --stream-name giao-dich --stream-mode-details StreamMode=ON_DEMAND

aws opensearch create-domain --domain-name tim-kiem-giao-dich   --engine-version OpenSearch_2.11   --cluster-config InstanceType=r6g.large.search,InstanceCount=3,ZoneAwarenessEnabled=true   --ebs-options EBSEnabled=true,VolumeType=gp3,VolumeSize=100

Và có hai cách đưa dữ liệu từ Kinesis vào OpenSearch: | Cách | Đặc điểm | |---|---| | Kinesis Data Firehose | được quản lý hoàn toàn, không viết mã | | Lambda consumer | linh hoạt, tự biến đổi dữ liệu | | OpenSearch Ingestion | pipeline được quản lý, mới hơn |

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

  • **B. EC2 nạp dữ liệu → S3 → Athena tìm kiếm → Managed Grafana — đây là phương án gần nhất vì cũng dựng được đường ống phân tích, nhưng nó không cho tìm kiếm TỨC THÌ: Athena quét tệp trên S3 và mất vài giây tới vài phút mỗi truy vấn, không phải tìm kiếm toàn văn độ trễ thấp. Và tự vận hành EC2 đi ngược "AWS-native, most efficient".
  • **C. ECS Fargate → DynamoDB để tìm kiếm toàn văn — DynamoDB KHÔNG hỗ trợ tìm kiếm toàn văn: nó tra cứu theo khoá, không có chỉ mục ngược. Và CloudWatch không phải công cụ trực quan hoá dữ liệu nghiệp vụ.
  • **D. Glue streaming ETL → Redshift, dùng full-text search của Redshift — Redshift KHÔNG có tìm kiếm toàn văn thật sự: nó là kho dữ liệu phân tích cột, hỗ trợ LIKE và biểu thức chính quy chứ không có xếp hạng liên quan hay phân tích ngôn ngữ.

Ghi nhớ

Bản đối chiếu ELK sang AWS — nên thuộc: | Tại chỗ | AWS | |---|---| | Kafka / Logstash | Kinesis Data Streams, MSK | | Elasticsearch | Amazon OpenSearch Service | | Kibana | OpenSearch Dashboards (kèm sẵn) | | Grafana | Amazon Managed Grafana |

Ba dịch vụ luồng dữ liệu của AWS: | Dịch vụ | Đặc điểm | |---|---| | Kinesis Data Streams | giữ 1–365 ngày, NHIỀU consumer đọc lại | | Kinesis Data Firehose | nạp vào đích, KHÔNG giữ lại | | Amazon MSK | Kafka được quản lý |

Chọn giữa Streams và Firehose:

Nhiều ứng dụng cùng đọc, cần phát lại → Data Streams
Chỉ nạp vào một đích, chấp nhận độ trễ ~60 giây → Firehose

Ba công cụ truy vấn dữ liệu trên AWS — bảng phân biệt: | Công cụ | Phù hợp | |---|---| | OpenSearch | tìm kiếm toàn văn, log, độ trễ thấp | | Athena | SQL đặc biệt trên S3, không cần hạ tầng | | Redshift | kho dữ liệu, truy vấn phân tích phức tạp |

Từ khoá nhận diện:

"full-text search", "immediate search", "log analytics" → OpenSearch "ad-hoc SQL on S3", "serverless query" → Athena "data warehouse", "complex joins on structured data" → Redshift

Ba đặc điểm của Amazon OpenSearch Service: | Đặc điểm | Chi tiết | |---|---| | Có OpenSearch Dashboards sẵn | không phải cài Kibana riêng | | Multi-AZ với dedicated master node | sẵn sàng cao | | UltraWarm và Cold storage | lưu log cũ rẻ hơn nhiều |

Ba tầng lưu trữ của OpenSearch: | Tầng | Đặc điểm | |---|---| | Hot (EBS/NVMe) | truy vấn nhanh nhất, đắt nhất | | UltraWarm | dữ liệu trên S3, rẻ hơn ~90% | | Cold | rẻ nhất, phải "hâm nóng" trước khi truy vấn |

Với dữ liệu tài chính giữ lâu, phân tầng tiết kiệm rất nhiều.

Ba lựa chọn triển khai OpenSearch: | Lựa chọn | Đặc điểm | |---|---| | Managed cluster | chọn cỡ node, kiểm soát nhiều nhất | | OpenSearch Serverless | tự co giãn, không quản node | | — | Serverless đơn giản hơn nhưng đắt hơn ở quy mô nhỏ |

Ba cách nạp dữ liệu vào OpenSearch: | Cách | Chi tiết | |---|---| | Firehose | không viết mã, đệm và thử lại tự động | | Lambda từ Kinesis | biến đổi tuỳ ý | | OpenSearch Ingestion | pipeline được quản lý, dựa trên Data Prepper |

Ba lưu ý về QuickSight: | Lưu ý | Chi tiết | |---|---| | Kết nối được nhiều nguồn | OpenSearch, Athena, Redshift, RDS, S3 | | SPICE là bộ nhớ đệm trong RAM | truy vấn rất nhanh | | Tính phí theo người dùng | tác giả và người xem giá khác nhau |

Ba lưu ý về bảo mật cho dữ liệu tài chính: | Lưu ý | Chi tiết | |---|---| | OpenSearch trong VPC | không expose ra Internet | | Mã hoá at rest và in transit | bật lúc tạo domain | | Fine-grained access control | phân quyền tới cấp chỉ mục và trường |

Fine-grained access control quan trọng với fintech:

Phân quyền tới từng TRƯỜNG:
    → nhân viên hỗ trợ thấy giao dịch nhưng KHÔNG thấy số thẻ
        ↓
    Không phải tách chỉ mục riêng cho từng vai trò

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ClusterStatus.yellow/red | shard chưa gán được | | FreeStorageSpace | đầy đĩa là ngừng ghi | | SearchLatency, IndexingLatency | hiệu năng |

ClusterStatus.red là sự cố nghiêm trọng nhất — có shard chính không khả dụng, nghĩa là mất dữ liệu tạm thời.

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | OpenSearch tính theo instance-giờ | như EC2 | | UltraWarm giảm mạnh chi phí log cũ | | | Kinesis on-demand tiện nhưng đắt hơn provisioned | khi tải ổn định |

Và một lời khuyên: hãy thiết kế chính sách vòng đời chỉ mục (ISM) ngay từ đầu. Dữ liệu luồng tài chính tích tụ rất nhanh, và một cụm OpenSearch không có quy tắc chuyển sang UltraWarm sẽ đầy đĩa trong vài tháng — lúc đó việc ngừng ghi xảy ra đột ngột và khắc phục giữa lúc đang chạy khó hơn nhiều so với việc đặt quy tắc từ trước.