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

Tìm thấy 1221 câu.

Câu 81 Domain - Continuous Improvement for Existing Solutions

A company has launched a web service in the cloud that analyzes tweets filtered by keywords. This service is hosted on a fleet of on-demand EC2 instances running in multiple Availability Zones with Auto Scaling, and are load-balanced by an application load balancer. After checking the load balancer logs, the solutions architect noticed that on-demand EC2 instances in one of the AZ's are not receiving requests.

Which of the following option is the most likely cause of this issue?

  1. A

    Multi-AZ autoscaling only works in the North Virginia region.
  2. B

    The availability zone that is not receiving traffic was not associated with the application load balancer.
  3. C

    Amazon EC2 Auto scaling does not span multiple availability zones.
  4. D You have to manually add instances in each AZ for them to receive traffic.
Xem giải thích

Đáp án

**B — Vùng sẵn sàng đó chưa được gắn vào Application Load Balancer.

Vì sao đúng

Triệu chứng trong đề rất đặc trưng: | Triệu chứng | Nguyên nhân | |---|---| | Instance ở một AZ không nhận lưu lượng | AZ đó không nằm trong danh sách subnet của ALB | | Instance vẫn khoẻ, ASG vẫn tạo ra chúng | vấn đề ở ALB, không phải ở instance |

⚠ ALB chỉ gửi lưu lượng tới AZ mà nó có node ở đó:

ALB đặt một node trong mỗi subnet đã gắn
    → node đó nhận lưu lượng và chuyển tiếp
        ↓
    AZ không được gắn: KHÔNG có node
    → không có gì gửi lưu lượng vào đó

Kiểm tra ALB có những AZ nào:

aws elbv2 describe-load-balancers \
  --names alb-ung-dung \
  --query 'LoadBalancers[0].AvailabilityZones[].ZoneName'

So với AZ mà Auto Scaling group dùng:

aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names asg-ung-dung \
  --query 'AutoScalingGroups[0].AvailabilityZones'

⚠ Đây chính là chỗ lệch:

ASG: [ap-southeast-1a, 1b, 1c]
ALB: [ap-southeast-1a, 1b]
        ↓
    Instance ở 1c được tạo ra, health check
      của ASG báo khoẻ, nhưng không ai
      gửi yêu cầu tới
        ↓
    Trả tiền cho công suất không dùng

Sửa bằng cách gắn thêm subnet:

aws elbv2 set-subnets --load-balancer-arn <arn> \
  --subnets subnet-1a subnet-1b subnet-1c

⚠ Và bật cân bằng tải xuyên vùng:

aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn <arn> \
  --attributes Key=load_balancing.cross_zone.enabled,Value=true

Hai loại cân bằng tải và mặc định — bảng phải thuộc: | Loại | Cross-zone mặc định | Tính phí truyền liên AZ | |---|---|---| | ALB | BẬT, không tắt được ở mức LB | không tính | | NLB | TẮT | có tính | | GWLB | TẮT | có tính |

NLB tắt cross-zone mặc định
    → node ở AZ-a chỉ gửi tới target ở AZ-a
        ↓
    AZ-a có 2 target, AZ-b có 8 target
    → mỗi target ở AZ-a nhận tải gấp 4 lần

Ba lợi ích khi sửa đúng: | Lợi ích | Chi tiết | |---|---| | Dùng hết công suất đã trả tiền | | | Chịu lỗi thật sự trên ba AZ | | | Tải phân bố đều giữa các instance | |

⚠ Và điều nguy hiểm hơn cả lãng phí:

Tưởng đang chạy trên 3 AZ
    → thực tế chỉ 2 AZ nhận lưu lượng
        ↓
    Mất một AZ = mất 50% công suất
      chứ không phải 33%
    → khả năng chịu lỗi kém hơn tính toán

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

  • **A. Health check của target group cấu hình sai — đây là phương án gần nhất và là nguyên nhân phổ biến khiến instance không nhận lưu lượng, nhưng health check sai sẽ ảnh hưởng mọi AZ như nhau, không riêng một AZ; và target sẽ hiện unhealthy chứ không phải "không nhận lưu lượng".
  • **C. Security group của instance chặn lưu lượng — cũng ảnh hưởng mọi AZ nếu dùng chung SG; và nếu SG chặn thì health check sẽ thất bại và target bị đánh dấu unhealthy.
  • **D. Auto Scaling group cấu hình sai — ASG vẫn tạo instance đúng ở AZ đó (đề nói instance có tồn tại), nên vấn đề không nằm ở ASG.

Ghi nhớ

⚠ Danh sách kiểm tra khi instance không nhận lưu lượng — theo thứ tự:

1. AZ có nằm trong subnet của ALB không?
2. Instance đã đăng ký vào target group chưa?
3. Health check có PASS không?
4. SG của instance có cho ALB vào không?
5. NACL của subnet có chặn không?
6. Ứng dụng có nghe đúng cổng không?

Từ khoá nhận diện:

"instances in one AZ receive no traffic" → AZ chưa gắn vào ALB "all targets unhealthy" → health check hoặc security group "uneven distribution across AZs" → cross-zone tắt (NLB) "502 Bad Gateway" → ứng dụng lỗi hoặc timeout

Ba lưu ý về subnet của ALB: | Lưu ý | Chi tiết | |---|---| | Cần ít nhất 2 AZ | | | Mỗi subnet cần ít nhất /27 và 8 IP trống | | | Thêm được subnet sau, không cần tạo lại ALB | |

⚠ Yêu cầu IP trống hay gây lỗi khi mở rộng:

ALB co giãn thì cần thêm IP trong subnet
    → subnet gần đầy
        ↓
    ALB không mở rộng được
    → 503 vào lúc tải cao
    → theo dõi số IP còn trống của subnet

Ba lưu ý về health check: | Lưu ý | Chi tiết | |---|---| | Đường dẫn phải trả 200 nhanh | | | Đừng kiểm tra phụ thuộc bên ngoài trong đó | | | deregistration_delay cho kết nối đang chạy | |

⚠ Health check kiểm tra CSDL là bẫy kinh điển:

/health gọi CSDL để "kiểm tra toàn diện"
    → CSDL chậm một chút
        ↓
    MỌI instance đồng loạt unhealthy
    → ALB gỡ hết → dịch vụ sập hoàn toàn
        ↓
    Vấn đề nhỏ thành sự cố toàn hệ thống

Ba lưu ý về security group: | Lưu ý | Chi tiết | |---|---| | SG của instance nhận từ SG của ALB | | | Tham chiếu SG thay vì CIDR | | | Mở đúng cổng của health check | |

aws ec2 authorize-security-group-ingress \
  --group-id sg-instance --protocol tcp --port 8080 \
  --source-group sg-alb

Ba lưu ý về cross-zone: | Lưu ý | Chi tiết | |---|---| | ALB luôn bật | | | NLB mặc định tắt, bật được | | | Bật NLB cross-zone thì tính phí liên AZ | |

Ba lưu ý về ASG nhiều AZ: | Lưu ý | Chi tiết | |---|---| | ASG tự cân bằng số instance giữa các AZ | | | Dùng health check kiểu ELB, không phải EC2 | | | Ít nhất 3 AZ cho hệ thống quan trọng | |

⚠ Health check kiểu ELB là cấu hình phải đổi:

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name asg-ung-dung \
  --health-check-type ELB --health-check-grace-period 300

Mặc định EC2: chỉ kiểm máy có chạy không
    → ứng dụng chết mà máy vẫn sống
    → ASG không thay thế
        ↓
    ELB: dùng health check của target group
    → ứng dụng chết thì thay máy

Ba lưu ý về định cỡ nhiều AZ: | Lưu ý | Chi tiết | |---|---| | N+1: chịu được mất một AZ | | | 3 AZ tiết kiệm hơn 2 AZ cho cùng mức dự phòng | | | Kiểm tra hạn ngạch ở mọi AZ dự định dùng | |

⚠ Vì sao 3 AZ rẻ hơn 2 AZ ở cùng mức chịu lỗi:

2 AZ: mỗi AZ phải chịu 100% tải
    → tổng công suất 200%
        ↓
    3 AZ: mỗi AZ chịu 50%
    → tổng công suất 150%
    → tiết kiệm 25%

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So AZ của ALB với AZ của ASG | | | Xem HealthyHostCount theo từng AZ | | | Kiểm RequestCount phân bố đều không | |

Và một lời khuyên: hãy đặt cảnh báo trên HealthyHostCount tách theo từng AZ chứ không gộp. Con số gộp vẫn trông bình thường khi một AZ hoàn toàn không nhận lưu lượng — và đó chính là kiểu lỗi chỉ lộ ra khi bạn thật sự mất một AZ khác.

Câu 82 Domain - Design Solutions for Organizational Complexity

A company has several resources in its production environment that is shared among various business units of the company. A single business unit may have one or more AWS accounts that have resources in the production environment. There were a lot of incidents in which the developers from a specific business unit accidentally terminated the Amazon EC2 instances, Amazon EKS clusters, and Amazon Aurora Serverless databases which are owned by another business unit. The solutions architect has been tasked to come up with a solution to only allow a specific business unit that owns the EC2 instances, and other AWS resources, to terminate their own resources.

Which of the following is the most suitable multi-account strategy implementation to meet the company requirements?

  1. A

    Use AWS Organizations to centrally manage all of your accounts. Group your accounts, which belong to a specific business unit, to individual Organization Units (OU). Create an IAM Role in the production account which has a policy that allows access to the EC2 instances including resource-level permission to terminate the instances owned by a particular business unit. Provide the cross-account access and the IAM policy to every member accounts of the OU.
  2. B

    Use AWS Organizations to centrally manage all of your accounts. Group your accounts, which belong to a specific business unit, to an individual Organization Unit (OU). Create a Service Control Policy in the production account for each business unit which has a policy that allows access to the EC2 instances including resource-level permission to terminate the instances that it owns. Provide the cross-account access and the SCP to the individual member accounts to tightly control who can terminate the EC2 instances.
  3. C

    Use AWS Organizations to centrally manage all of your accounts. Group your accounts, which belong to a specific business unit, to an individual Organization Unit (OU). Create an IAM Role in the production account for each business unit which has a policy that allows access to the EC2 instances including resource-level permission to terminate the instances that it owns. Create an AWSServiceRoleForOrganizations service-linked role for the individual member accounts of the OU to enable trusted access.
  4. D

    Use AWS Organizations to centrally manage all of your accounts. Group your accounts, which belong to a specific business unit, to an individual Organization Unit (OU). Create a Service Control Policy in the production account which has a policy that allows access to the EC2 instances including resource-level permission to terminate the instances owned by a particular business unit. Provide the cross-account access and the SCP to the OUs, which will then be automatically inherited by its member accounts.
Xem giải thích

Đáp án

A — Dùng AWS Organizations với đơn vị tổ chức (OU), tạo vai trò IAM trong tài khoản sản xuất có quyền ở mức tài nguyên, để nhóm phát triển giả nhận từ tài khoản của họ.

Vì sao đúng

Đề nêu ba 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ách môi trường | mỗi môi trường một tài khoản, gom theo OU | | Nhóm phát triển truy cập được tài nguyên sản xuất cần thiết | vai trò xuyên tài khoản | | Giới hạn đúng tài nguyên | quyền ở mức tài nguyên trong chính sách |

⚠ Ranh giới tài khoản là ranh giới cô lập MẠNH NHẤT trên AWS:

Cùng tài khoản, khác VPC
    → vẫn chung hạn ngạch, chung hoá đơn,
      chung không gian tên IAM
        ↓
    Khác tài khoản
    → cô lập hoàn toàn về hạn ngạch,
      thanh toán và quyền
    → một sự cố không lan sang bên kia

Vai trò trong tài khoản sản xuất:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Principal": {"AWS":
    "arn:aws:iam::111122223333:root"},
  "Action": "sts:AssumeRole",
  "Condition": {"Bool":
    {"aws:MultiFactorAuthPresent": "true"}}}]}

⚠ Điều kiện MFA trong trust policy là bắt buộc với truy cập sản xuất:

Không có điều kiện MFA
    → chỉ cần access key rò rỉ là vào được
      thẳng môi trường sản xuất
        ↓
    Có MFA: thêm một lớp mà kẻ tấn công
      không lấy được từ mã nguồn

Chính sách giới hạn ở mức tài nguyên:

{"Effect": "Allow",
 "Action": ["s3:GetObject", "s3:ListBucket"],
 "Resource": ["arn:aws:s3:::log-san-xuat",
              "arn:aws:s3:::log-san-xuat/*"]}

Chỉ đọc, chỉ một bucket
    → không phải "quyền vào tài khoản sản xuất"
    → mà là "quyền đọc đúng thứ này"

⚠ Và SCP ở tầng OU làm trần không vượt qua được:

{"Effect": "Deny",
 "Action": ["ec2:TerminateInstances",
            "rds:DeleteDBInstance"],
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:PrincipalArn":
     "arn:aws:iam::*:role/VaiTroVanHanh"}}}

SCP không CẤP quyền, chỉ đặt TRẦN
    → dù có ai gán AdministratorAccess
      cũng không xoá được instance
        ↓
    Lớp bảo vệ không phụ thuộc việc
      cấu hình IAM đúng

Giả nhận vai trò:

aws sts assume-role \
  --role-arn arn:aws:iam::444455556666:role/DocLogSanXuat \
  --role-session-name phien-gp \
  --serial-number arn:aws:iam::111122223333:mfa/nguoi-dung \
  --token-code 123456

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Credential tạm, hết hạn tự động | | | CloudTrail ghi rõ ai giả nhận và làm gì | | | Thu hồi bằng cách sửa một trust policy | |

⚠ Lợi ích thứ hai đáng nói kỹ:

CloudTrail trong tài khoản sản xuất ghi:
    `userIdentity.arn` = vai trò
    + `sessionContext` = người gốc
        ↓
    Truy được về đúng cá nhân
    → dù họ dùng vai trò dùng chung

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

  • **B. Dùng một tài khoản với VPC riêng cho mỗi môi trường và phân quyền bằng IAM — đây là phương án gần nhất và rẻ hơn về mặt quản lý, nhưng cô lập bằng IAM trong cùng tài khoản yếu hơn nhiều: một chính sách viết sai là chạm được sản xuất, và mọi thứ chung hạn ngạch.
  • **C. Tạo IAM user trong tài khoản sản xuất cho từng người phát triển — credential tồn tại lâu, phải quản lý ở hai nơi, và không có đường thu hồi tập trung.
  • **D. Dùng VPC peering giữa tài khoản phát triển và sản xuất — peering giải quyết kết nối mạng, không giải quyết quyền truy cập API; đây là hai vấn đề khác nhau.

Ghi nhớ

⚠ Bốn cơ chế kiểm soát trong Organizations — bảng phải thuộc: | Cơ chế | Việc | |---|---| | SCP | đặt TRẦN quyền, không cấp quyền | | IAM policy | CẤP quyền trong tài khoản | | Resource policy | cấp quyền từ phía tài nguyên | | Permission boundary | trần cho một principal cụ thể |

⚠ Quyền hiệu lực là GIAO của mọi tầng:

SCP cho phép + IAM cho phép
    → được làm
        ↓
    SCP cấm
    → không được, dù IAM cho phép
    → dù là quản trị viên tài khoản

Từ khoá nhận diện:

"separate environments, strong isolation" → nhiều tài khoản + Organizations "developers access production resources" → vai trò xuyên tài khoản "prevent any user from doing X" → SCP "central login for all accounts" → IAM Identity Center

⚠ IAM Identity Center là cách hiện đại thay cho việc tự dựng vai trò:

Permission set định nghĩa một lần
    → gán cho nhóm ở nhiều tài khoản
        ↓
    Người dùng thấy danh sách tài khoản
      và vai trò trong một cổng
    → không phải nhớ ARN nào của tài khoản nào

Ba lưu ý về thiết kế OU: | Lưu ý | Chi tiết | |---|---| | Nhóm theo yêu cầu chính sách, không theo phòng ban | | | OU Sandbox tách hẳn với SCP lỏng hơn | | | OU Bảo mật cho tài khoản log và kiểm toán | |

⚠ Nhóm theo chính sách là nguyên tắc quan trọng nhất:

Nhóm theo phòng ban
    → mỗi OU cần nhiều SCP khác nhau
        ↓
    Nhóm theo "cần chính sách giống nhau"
    → một SCP cho cả OU
    → cấu trúc tự giải thích được

Ba lưu ý về SCP: | Lưu ý | Chi tiết | |---|---| | Không áp cho tài khoản quản lý | | | Không áp cho service-linked role | | | Deny mạnh hơn Allow, luôn thắng | |

⚠ "Không áp cho tài khoản quản lý" là lý do phải giữ nó sạch:

Tài khoản quản lý không bị SCP chặn
    → không đặt tài nguyên sản xuất ở đó
        ↓
    Chỉ dùng để quản lý tổ chức
    → và khoá chặt quyền truy cập vào nó

Ba lưu ý về vai trò xuyên tài khoản: | Lưu ý | Chi tiết | |---|---| | Trust policy nói AI được giả nhận | | | Permission policy nói làm được GÌ | | | External ID khi bên thứ ba giả nhận | |

Ba lưu ý về Control Tower: | Lưu ý | Chi tiết | |---|---| | Dựng landing zone theo thực hành tốt | | | Guardrail phòng ngừa và phát hiện sẵn | | | Account Factory tạo tài khoản chuẩn hoá | |

Ba lưu ý về chi phí nhiều tài khoản: | Lưu ý | Chi tiết | |---|---| | Tài khoản không tính phí | | | Thanh toán gộp, chiết khấu dùng chung | | | Cost Categories quy chi phí về nhóm | |

⚠ Chiết khấu dùng chung là lợi ích hay bị bỏ qua:

Reserved Instance và Savings Plan mua ở
  tài khoản nào cũng áp cho cả tổ chức
        ↓
    Nhiều tài khoản KHÔNG làm mất chiết khấu
    → lý do phản đối phổ biến nhất
      thật ra không đúng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử giả nhận không có MFA — phải bị từ chối | | | Thử thao tác ngoài phạm vi — phải bị từ chối | | | Xem CloudTrail có ghi đúng người gốc không | |

Và một lời khuyên: hãy cấp quyền theo tài nguyên cụ thể ngay từ đầu thay vì cấp rộng rồi định thu hẹp sau. Việc thu hẹp quyền đang được dùng luôn bị hoãn vì không ai chắc cái gì sẽ hỏng — nên trên thực tế, quyền cấp rộng ngày đầu thường là quyền tồn tại mãi mãi.

Câu 83 Domain - Accelerate Workload Migration and Modernization

A company has several NFS shares in its on-premises data center that contains millions of small log files totaling around 50TB in size. The files in these NFS shares need to be migrated to an Amazon S3 bucket. To start the migration process, the solutions architect requested an AWS Snowball Edge device that will be used to transfer the files to Amazon S3. A file interface was configured on the Snowball Edge device and is connected to the corporate network. The Solutions Architect initiated the snowball cp command to start the copying process, however, the copying of data is significantly slower than expected.

Which of the following options are the likely cause of the slow transfer speed and the recommended solution?

  1. A

    The file interface of the Snowball Edge is limited by the network interface speed. Connect the device directly using a high-speed USB 3.0 interface instead to maximize the copying throughput.
  2. B

    The file interface of the Snowball Edge has reached its throughput limit. Change the interface to an S3 Adapter instead for a significantly faster transfer speed.
  3. C

    This is due to encryption overhead when copying files to the Snowball Edge device. Open multiple sessions to the Snowball Edge device and initiate parallel copy jobs to improve the overall copying throughput.
  4. D

    Ingesting millions of files has saturated the processing power of the Snowball Edge. Request for another Snowball Edge device and cluster them together to increase the ingest throughput.
Xem giải thích

Đáp án

C — Chi phí xử lý của việc mã hoá làm chậm quá trình; hãy mở nhiều phiên sao chép song song để tăng thông lượng.

Vì sao đúng

Snowball Edge luôn mã hoá dữ liệu, và việc đó tốn CPU của máy khách chứ không phải của thiết bị:

Máy khách đọc tệp
    → mã hoá bằng khoá KMS
        ↓
    Gửi qua mạng tới Snowball
    → thiết bị ghi xuống đĩa
        ↓
    Nút thắt nằm ở CPU máy khách,
      không ở đĩa hay mạng

⚠ Và mã hoá là quá trình đơn luồng cho mỗi phiên sao chép:

Một phiên: dùng được vài lõi CPU
    → phần lớn CPU nhàn rỗi
        ↓
    Nhiều phiên song song: mỗi phiên
      một tiến trình mã hoá riêng
    → dùng hết CPU sẵn có

Chạy nhiều phiên:

# Chia dữ liệu theo thư mục, mỗi phiên một phần
for thu_muc in du-lieu/phan-*; do
  snowballEdge cp -r "$thu_muc" s3://bucket-snowball/ &
done
wait

Hoặc dùng AWS CLI với endpoint của thiết bị:

aws s3 cp du-lieu/phan-1 s3://bucket-snowball/ \
  --recursive --endpoint http://<ip-snowball>:8080 \
  --profile snowball &

Ba khuyến nghị chính thức của AWS về thông lượng: | Khuyến nghị | Lý do | |---|---| | Nhiều phiên sao chép song song | tận dụng nhiều lõi CPU | | Dùng nhiều máy khách cùng lúc | vượt giới hạn CPU một máy | | Gộp tệp nhỏ thành tệp lớn | giảm chi phí trên mỗi tệp |

⚠ Điểm thứ ba quan trọng không kém điểm thứ nhất:

Mỗi tệp có chi phí cố định:
    mở, mã hoá, ghi metadata, đóng
        ↓
    1 triệu tệp 1 KB: chi phí cố định
      áp đảo hoàn toàn
    → chậm hơn nhiều lần so với
      1.000 tệp 1 MB cùng tổng dung lượng

Gộp tệp nhỏ trước khi sao chép:

tar -cf phan-01.tar du-lieu/thu-muc-nho-01/
# hoặc giữ khả năng đọc từng tệp:
# dùng định dạng có chỉ mục như zip

Ba lợi ích khi làm đúng: | Lợi ích | Chi tiết | |---|---| | Thông lượng tăng nhiều lần | | | Hoàn tất trong thời gian thuê thiết bị | | | Không phải thuê thêm thiết bị | |

⚠ Và thời gian thuê là ràng buộc thật:

Snowball có số ngày miễn phí
    → quá hạn thì tính phí theo ngày
        ↓
    Sao chép chậm không chỉ là bất tiện
    → mà là chi phí phát sinh

Kiểm tra thông lượng thực tế:

snowballEdge describe-device --endpoint https://<ip>:9091 \
  --manifest-file manifest.bin --unlock-code <ma>

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

  • **A. Đĩa của Snowball quá chậm — đây là phương án gần nhất và nghe hợp lý, nhưng Snowball Edge dùng ổ SSD/NVMe với thông lượng cao hơn nhiều so với mức mà một phiên sao chép đơn lẻ đạt được; nút thắt không nằm ở đĩa.
  • **B. Mạng LAN quá chậm — có thể là nguyên nhân trong vài trường hợp, nhưng nếu vậy thì thêm phiên song song cũng không giúp; và đề hỏi cách cải thiện, mà câu trả lời cho mạng chậm là nâng cấp mạng chứ không phải điều chỉnh cách sao chép.
  • **D. Cần chia dữ liệu qua nhiều Snowball — thêm thiết bị không sửa được vấn đề thông lượng trên mỗi thiết bị; tốn kém mà không giải quyết gốc.

Ghi nhớ

⚠ Ba yếu tố quyết định thông lượng Snowball — bảng phải thuộc: | Yếu tố | Ảnh hưởng | |---|---| | Số phiên song song | lớn nhất | | Kích thước tệp | rất lớn với tệp nhỏ | | Băng thông mạng LAN | trần trên |

Từ khoá nhận diện:

"transfer slower than expected" → nhiều phiên song song + gộp tệp nhỏ "petabyte scale, no network" → Snowmobile (đã ngừng) hoặc nhiều Snowball "ongoing transfer over network" → DataSync "one-time bulk, limited bandwidth" → Snowball Edge

⚠ Ba dịch vụ chuyển dữ liệu — chọn theo dung lượng và đường truyền: | Dịch vụ | Hợp với | |---|---| | DataSync | có mạng đủ tốt, chuyển liên tục | | Snowball Edge | hàng chục tới hàng trăm TB, mạng yếu | | Direct Connect | cần đường riêng lâu dài |

⚠ Phép tính quyết định dùng mạng hay thiết bị:

100 TB qua đường 1 Gbps
    → lý thuyết ~9 ngày chạy hết công suất
    → thực tế 15-20 ngày
        ↓
    Snowball Edge: vài ngày kể cả vận chuyển
    → và không chiếm băng thông sản xuất

Ba lưu ý về Snowball Edge: | Lưu ý | Chi tiết | |---|---| | Storage Optimized: ~80 TB dùng được | | | Compute Optimized: có GPU, chạy EC2 tại chỗ | | | Mã hoá bằng KMS, khoá không lưu trên thiết bị | |

⚠ Khoá không nằm trên thiết bị là điểm bảo mật quan trọng:

Thiết bị bị mất trên đường vận chuyển
    → dữ liệu đã mã hoá
    → khoá nằm trong KMS của bạn
        ↓
    Không giải mã được
    → và AWS xoá sạch thiết bị sau khi nhập

Ba lưu ý về quy trình: | Bước | Chi tiết | |---|---| | Đặt hàng qua bảng điều khiển | | | Mở khoá bằng manifest + unlock code (hai kênh khác nhau) | | | Gửi trả, AWS nhập vào S3 | |

⚠ Manifest và unlock code phải đi hai đường:

Manifest tải từ bảng điều khiển
    + unlock code hiện trên màn hình
        ↓
    Ai có cả hai mới mở được thiết bị
    → đừng lưu chung một chỗ

Ba lưu ý về kiểm tra sau khi nhập: | Lưu ý | Chi tiết | |---|---| | So số tệp và tổng dung lượng | | | Kiểm tra checksum mẫu | | | Giữ bản gốc tới khi xác nhận xong | |

⚠ Điểm cuối là điều tuyệt đối không được bỏ qua:

Thiết bị đã gửi đi
    → xoá bản gốc để lấy chỗ trống
        ↓
    Nhập thiếu, hỏng, hoặc thiết bị lỗi
    → mất dữ liệu vĩnh viễn
    → CHỜ xác nhận nhập xong mới xoá

Ba lưu ý về DataSync: | Lưu ý | Chi tiết | |---|---| | Nhanh hơn nhiều so với công cụ tự viết | | | Có kiểm tra toàn vẹn tự động | | | Chạy theo lịch, đồng bộ chênh lệch | |

Ba lưu ý về tối ưu chi phí: | Lưu ý | Chi tiết | |---|---| | Snowball tính phí thuê + ngày quá hạn | | | Đưa thẳng vào lớp lưu trữ đích | | | Không tính phí nhập dữ liệu vào AWS | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo tốc độ với 1 phiên và 8 phiên rồi so | | | Theo dõi CPU máy khách khi sao chép | | | Đo riêng với tệp nhỏ và tệp lớn | |

⚠ Việc thứ hai cho câu trả lời rõ ràng nhất:

CPU máy khách gần 100%
    → mã hoá là nút thắt
    → thêm phiên hoặc thêm máy khách
        ↓
    CPU thấp mà vẫn chậm
    → nút thắt ở đĩa nguồn hoặc mạng

Và một lời khuyên: hãy chạy thử với vài trăm GB trước khi bắt đầu chép toàn bộ. Phát hiện thông lượng thấp sau ba ngày chép nghĩa là bạn đã mất ba ngày trong thời gian thuê — còn phát hiện sau nửa giờ thì chỉ mất nửa giờ.

Câu 84 Domain - Design for New Solutions
A global real estate startup is looking for an option of adding a cost-effective location-based alert to their iOS and Android mobile apps. Their users will receive alerts on their mobile device regarding real estate offers in proximity to their current location and the delivery time for the push notifications should be less than a minute. The existing mobile app has an initial 2 million users worldwide and is rapidly growing. What is the most suitable architecture to use in this scenario?
  1. A Set up an architecture where the mobile app will send the user's location to an API Gateway with Lambda functions which process and retrieve the relevant offers from an RDS database. Once the data has been processed, use Amazon Pinpoint to send out the offers to the mobile app.
  2. B

    Set up an architecture where the mobile app will send the user's location to an SQS queue and a fleet of On-Demand EC2 instances will retrieve the relevant offers from a DynamoDB table. Once the data has been processed, use AWS SNS Mobile Push to send out the offers to the mobile app.
  3. C Set up an architecture where the mobile app will send the user's location to an SQS queue and a fleet of On-Demand EC2 instances will retrieve the relevant offers from an Amazon Aurora database. Once the data has been processed, use AWS Device Farm to send out the offers to the mobile app.
  4. D Set up an architecture where there is an Auto Scaling group of On-Demand EC2 instances behind an API Gateway that retrieve the relevant offers from RDS. Once the data has been processed, use AWS AppSync to send out the offers to the mobile app.
Xem giải thích

Đáp án

B — Dùng Amazon SQS làm hàng đợi, EC2 xử lý, DynamoDB lưu trạng thái, và SNS Mobile Push gửi thông báo tới thiết bị.

Vì sao đúng

Đề mô tả một luồng xử lý bất đồng bộ có thông báo cuối, và phương án này khớp từng khâu: | Khâu | Dịch vụ | |---|---| | Nhận yêu cầu, không để mất khi tải cao | SQS | | Xử lý theo tốc độ của mình | EC2 trong ASG | | Lưu trạng thái, đọc nhanh | DynamoDB | | Đẩy thông báo tới điện thoại | SNS Mobile Push |

⚠ SQS làm bộ đệm là điều quan trọng nhất trong kiến trúc này:

Không có hàng đợi: đỉnh tải đập thẳng
  vào tầng xử lý
    → hoặc phải dự phòng công suất cho đỉnh
    → hoặc mất yêu cầu
        ↓
    Có hàng đợi: yêu cầu xếp hàng
    → tầng xử lý làm theo tốc độ ổn định
    → co giãn theo ĐỘ DÀI HÀNG ĐỢI

Co giãn theo số thông điệp chờ mỗi instance:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name asg-xu-ly \
  --policy-name theo-hang-doi \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 10.0,
    "CustomizedMetricSpecification": {
      "MetricName": "BacklogPerInstance",
      "Namespace": "UngDung",
      "Statistic": "Average"}}'

⚠ ApproximateNumberOfMessagesVisible một mình là chỉ số SAI để co giãn:

1.000 thông điệp chờ
    → nhiều hay ít?
        ↓
    Phụ thuộc số instance đang có
    → phải chia: hàng chờ / số instance
    → đó mới là chỉ số đúng

Đăng ký thiết bị với SNS:

aws sns create-platform-endpoint \
  --platform-application-arn <arn-fcm> \
  --token <token-thiet-bi>

aws sns publish --target-arn <arn-endpoint> \
  --message '{"GCM":"{\"notification\":
    {\"title\":\"Xong roi\",
     \"body\":\"Anh cua ban da xu ly xong\"}}"}' \
  --message-structure json

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chịu được đỉnh tải mà không mất yêu cầu | | | Tầng xử lý co giãn độc lập | | | Một API cho cả iOS lẫn Android | |

⚠ Và visibility timeout phải dài hơn thời gian xử lý:

Xử lý mất 5 phút, timeout đặt 30 giây
    → thông điệp hiện lại sau 30 giây
        ↓
    Instance khác nhận và xử lý CÙNG việc
    → xử lý trùng, tốn tiền, có thể sai dữ liệu

Gia hạn khi cần:

sqs.change_message_visibility(
    QueueUrl=url, ReceiptHandle=the,
    VisibilityTimeout=900)

⚠ Và luôn cần dead-letter queue:

{"RedrivePolicy": "{\"deadLetterTargetArn\":
  \"<arn-dlq>\", \"maxReceiveCount\": \"3\"}"}

Thông điệp gây lỗi mãi
    → thử lại vô hạn, chiếm chỗ
        ↓
    Sau 3 lần: chuyển sang DLQ
    → hàng đợi chính tiếp tục chạy
    → và có nơi để điều tra

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

  • **A. Dùng SNS làm hàng đợi giữa tầng nhận và tầng xử lý — đây là phương án gần nhất và SNS đúng cho khâu thông báo, nhưng SNS là phát tán không lưu trữ: người nhận không hoạt động thì thông điệp mất, không có bộ đệm cho đỉnh tải.
  • **C. Dùng Kinesis thay SQS — chạy được nhưng thừa: đề không cần giữ thứ tự, không cần nhiều consumer đọc cùng dữ liệu, không cần phát lại; SQS đơn giản và rẻ hơn.
  • **D. Dùng RDS lưu trạng thái và SES gửi thông báo — RDS không co giãn tự nhiên như DynamoDB cho mẫu tra cứu theo khoá, và SES gửi email chứ không đẩy thông báo tới ứng dụng di động.

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

⚠ Ngày nay Amazon Pinpoint là lựa chọn tốt hơn SNS Mobile Push cho thông báo đẩy có nhắm đích.

Tiêu chí SNS Mobile Push Pinpoint
Gửi thông báo đẩy có có
Phân khúc người dùng không có
Chiến dịch và lịch gửi không có
Thống kê mở, bấm không có
Đa kênh (SMS, email, in-app) một phần đầy đủ 
Thông báo giao dịch đơn giản
  ("việc của bạn đã xong")
    → SNS đủ và rẻ hơn
        ↓
    Cần biết ai đã mở, gửi theo phân khúc
    → Pinpoint

⚠ Và tầng xử lý ngày nay thường không dùng EC2 nữa:

EC2 + ASG: vẫn đúng và phổ biến
    ↓
Lambda: SQS gọi trực tiếp,
  không quản máy chủ nào
    ↓
Fargate: container không quản máy chủ,
  hợp việc chạy lâu hơn 15 phút

⚠ Nhưng Lambda có ràng buộc phải biết:

Tối đa 15 phút mỗi lần chạy
    → việc lâu hơn: Fargate hoặc EC2
        ↓
    Và đồng thời tối đa mặc định 1.000
    → hàng đợi dài có thể chạm trần

Ghi nhớ

⚠ Ba dịch vụ nhắn tin — bảng phải thuộc: | Dịch vụ | Mô hình | Lưu trữ | |---|---|---| | SQS | hàng đợi, kéo | tới 14 ngày | | SNS | phát tán, đẩy | không lưu | | EventBridge | định tuyến theo quy tắc | không lưu (có archive) |

Từ khoá nhận diện:

"decouple, buffer spikes" → SQS "push notification to mobile" → SNS Mobile Push hoặc Pinpoint "fan out to multiple subscribers" → SNS "scale based on queue depth" → backlog per instance

⚠ Mẫu fan-out kết hợp cả hai:

SNS topic
  ├─ SQS hàng đợi A → xử lý ảnh
  ├─ SQS hàng đợi B → cập nhật tìm kiếm
  └─ SQS hàng đợi C → ghi kho dữ liệu
        ↓
    Mỗi hệ thống có bộ đệm riêng
    → một hệ thống chậm không ảnh hưởng
      hai cái kia

Ba lưu ý về SQS: | Lưu ý | Chi tiết | |---|---| | Standard: thông lượng vô hạn, có thể trùng | | | FIFO: đúng thứ tự, chính xác một lần | | | Long polling giảm chi phí và độ trễ | |

⚠ Long polling nên luôn bật:

aws sqs set-queue-attributes --queue-url <url> \
  --attributes ReceiveMessageWaitTimeSeconds=20

Short polling: gọi liên tục, phần lớn rỗng
    → tốn tiền theo số lời gọi
        ↓
    Long polling: chờ tới 20 giây
    → ít lời gọi hơn, nhận thông điệp nhanh hơn

Ba lưu ý về xử lý trùng: | Lưu ý | Chi tiết | |---|---| | SQS Standard có thể giao hơn một lần | | | Thiết kế xử lý sao cho idempotent | | | Dùng DynamoDB ghi id đã xử lý | |

try:
    dynamodb.put_item(TableName='DaXuLy',
        Item={'idThongDiep': {'S': ma}},
        ConditionExpression='attribute_not_exists(idThongDiep)')
except ClientError:
    return  # da xu ly roi

Ba lưu ý về DynamoDB cho trạng thái: | Lưu ý | Chi tiết | |---|---| | Khoá chính là id công việc | | | TTL tự xoá bản ghi cũ | | | On-demand hợp với tải khó đoán | |

Ba lưu ý về SNS Mobile Push: | Lưu ý | Chi tiết | |---|---| | Hỗ trợ FCM, APNs, ADM, Baidu | | | Endpoint hỏng phải dọn định kỳ | | | Định dạng thông điệp khác nhau theo nền tảng | |

⚠ Endpoint hỏng tích tụ nếu không dọn:

Người dùng gỡ ứng dụng
    → token không còn hợp lệ
        ↓
    SNS đánh dấu endpoint Disabled
    → phải dọn định kỳ, nếu không
      danh sách phình mãi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy tải cao, xem hàng đợi có dồn không | | | Kiểm DLQ có thông điệp lạ không | | | Thử nhận thông báo trên cả iOS và Android | |

Và một lời khuyên: hãy đặt cảnh báo trên độ sâu dead-letter queue chứ đừng chỉ theo dõi hàng đợi chính. Hàng đợi chính trống rỗng trông rất giống "mọi thứ đều ổn" — kể cả khi mọi thông điệp đều đang lặng lẽ rơi vào DLQ.

Câu 85 Domain - Design for New Solutions

A company is implementing cloud best practices for its infrastructure. The Solutions Architect is using AWS CloudFormation templates for infrastructure-as-code of its two-tier web application. The application frontend is hosted on an Auto Scaling group of Amazon EC2 instances while the database is an Amazon RDS for MySQL instance. For security purposes, the database password must be rotated every 60 days.

Which of the following solutions is the MOST secure way to store and retrieve the database password for the web application?

  1. A

    On the CloudFormation template, create an AWS Secrets Manager secret resource for the database password. Add a UserData property to reference the secret resource in the initialization script of the Auto Scaling group’s launch template using the Ref intrinsic function. Use the Ref  intrinsic function to reference the secret resource as the value of the <code>MasterUserPassword property in the AWS::RDS::DBInstance resource.
  2. B

    On the CloudFormation template, create an encrypted parameter using AWS Systems Manager Parameter Store for the database password. Add a UserData property to reference the encrypted parameter in the initialization script of the Auto Scaling group’s launch template. Use the Fn::GetAtt intrinsic function to reference the encrypted parameter as the value of the MasterUserPassword property in the <code>AWS::RDS::DBInstance resource.
  3. C

    On the CloudFormation template, create a database password parameter. Add a UserData property to reference the password parameter in the initialization script of the Auto Scaling group’s launch template using the Ref intrinsic function. Save the password inside the EC2 instance upon its launch. Use the Ref intrinsic function to reference the parameter as the value of the MasterUserPassword property in the AWS::RDS::DBInstance resource.
  4. D

    On the CloudFormation template, create an AWS Secrets Manager secret resource for the database password. Modify the application to retrieve the database password from Secrets Manager when it launches. Use a dynamic reference for the secret resource to be placed as the value of the MasterUserPassword property of the AWS::RDS::DBInstance resource.
Xem giải thích

Đáp án

D — Lưu mật khẩu trong AWS Secrets Manager và dùng dynamic reference trong CloudFormation cho MasterUserPassword; ứng dụng lấy mật khẩu từ Secrets Manager lúc khởi động.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Mật khẩu không nằm trong template | dynamic reference giải quyết lúc triển khai | | Ứng dụng lấy được mật khẩu | gọi API Secrets Manager | | Xoay mật khẩu định kỳ | xoay tự động của Secrets Manager |

⚠ Dynamic reference là cơ chế duy nhất đưa bí mật vào CloudFormation an toàn:

Tham số thường: giá trị nằm trong
  lịch sử stack, ai xem stack đều thấy
        ↓
    Dynamic reference: template chỉ chứa
      ĐƯỜNG DẪN tới bí mật
    → CloudFormation lấy giá trị lúc tạo
    → không lưu lại

Cú pháp trong template:

Resources:
  CoSoDuLieu:
    Type: AWS::RDS::DBInstance
    Properties:
      Engine: mysql
      MasterUsername: quantri
      MasterUserPassword: !Sub
        '{{resolve:secretsmanager:${TenBiMat}:SecretString:password}}'

⚠ Bốn phần của dynamic reference:

{{resolve:secretsmanager:TEN:SecretString:KHOA:PHIEN_BAN}}
              ↑          ↑       ↑        ↑      ↑
           dịch vụ    tên bí mật  loại  khoá JSON  tuỳ chọn

Cách tốt hơn nữa — để CloudFormation tự sinh mật khẩu:

  BiMatCSDL:
    Type: AWS::SecretsManager::Secret
    Properties:
      Name: csdl/san-xuat
      GenerateSecretString:
        SecretStringTemplate: '{"username": "quantri"}'
        GenerateStringKey: password
        PasswordLength: 32
        ExcludeCharacters: '"@/\'

⚠ Cách này tốt hơn vì không người nào từng biết mật khẩu:

Sinh ngẫu nhiên trong Secrets Manager
    → không ai gõ nó ra
    → không nằm trong lịch sử shell
    → không nằm trong chat hay ticket
        ↓
    Chỉ ứng dụng đọc được qua IAM

Gắn bí mật với instance để xoay tự động:

  GanBiMat:
    Type: AWS::SecretsManager::SecretTargetAttachment
    Properties:
      SecretId: !Ref BiMatCSDL
      TargetId: !Ref CoSoDuLieu
      TargetType: AWS::RDS::DBInstance

Bật xoay:

aws secretsmanager rotate-secret --secret-id csdl/san-xuat \
  --rotation-lambda-arn <arn> \
  --rotation-rules AutomaticallyAfterDays=30

Ứng dụng lấy mật khẩu:

import boto3, json
sm = boto3.client('secretsmanager')
bi_mat = json.loads(sm.get_secret_value(
    SecretId='csdl/san-xuat')['SecretString'])
ket_noi = ket_noi_csdl(bi_mat['username'], bi_mat['password'])

⚠ Nhưng đọc mỗi lần dùng là sai — phải cache:

Gọi Secrets Manager mỗi truy vấn CSDL
    → thêm độ trễ, tốn tiền, chạm hạn ngạch
        ↓
    Cache trong bộ nhớ + đọc lại khi
      xác thực thất bại
    → dùng thư viện caching chính thức

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mật khẩu không ở đâu trong mã hay template | | | Xoay tự động không cần dừng ứng dụng | | | CloudTrail ghi ai đã đọc bí mật | |

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

  • **C. Lưu trong Systems Manager Parameter Store kiểu SecureString và dùng dynamic reference — đây là phương án gần nhất và an toàn, nhưng Parameter Store không có xoay tự động sẵn; đề yêu cầu xoay định kỳ thì phải tự viết cơ chế.
  • **A. Truyền mật khẩu qua tham số CloudFormation với NoEcho: true — NoEcho chỉ che trên bảng điều khiển; giá trị vẫn được lưu và người có quyền đọc stack vẫn lấy được, và không có xoay.
  • **B. Mã hoá bằng KMS rồi nhúng bản mã vào template — template nằm trong kho mã, bản mã đi kèm; ai có quyền giải mã đều lấy được, và vẫn phải tự lo việc xoay.

Ghi nhớ

⚠ Secrets Manager và Parameter Store — bảng phải thuộc: | Tiêu chí | Secrets Manager | Parameter Store | |---|---|---| | Xoay tự động | CÓ, sẵn cho RDS/Redshift/DocumentDB | không | | Chi phí | ~0,40 USD/bí mật/tháng | Standard miễn phí | | Nhân bản xuyên Region | có sẵn | không | | Kích thước | 64 KB | 4 KB (8 KB Advanced) | | Resource policy | có | không |

Cần xoay tự động → Secrets Manager
Chỉ là cấu hình, không phải bí mật
  → Parameter Store, miễn phí

Từ khoá nhận diện:

"rotate credentials automatically" → Secrets Manager "no secrets in template" → dynamic reference "configuration values, free" → Parameter Store "encrypt data at rest" → KMS

⚠ Bốn bước của Lambda xoay — phải hiểu: | Bước | Việc | |---|---| | createSecret | sinh mật khẩu mới, gắn nhãn AWSPENDING | | setSecret | đổi mật khẩu trong CSDL | | testSecret | thử kết nối bằng mật khẩu mới | | finishSecret | chuyển AWSPENDING thành AWSCURRENT |

⚠ Và cơ chế nhãn là điều làm xoay không gây gián đoạn:

AWSCURRENT: mật khẩu đang dùng
AWSPENDING: mật khẩu mới đang thử
AWSPREVIOUS: mật khẩu trước đó
        ↓
    Ứng dụng đọc AWSCURRENT
    → chỉ đổi khi mật khẩu mới đã kiểm thử xong

Ba lưu ý về xoay: | Lưu ý | Chi tiết | |---|---| | Ứng dụng phải đọc lại khi xác thực hỏng | | | Chiến lược hai người dùng an toàn hơn | | | Kiểm thử xoay ở môi trường thấp trước | |

⚠ Chiến lược hai người dùng loại bỏ khoảng gián đoạn:

Một người dùng: đổi mật khẩu
    → kết nối đang mở dùng mật khẩu cũ vẫn ổn
    → kết nối MỚI trong khoảnh khắc đó hỏng
        ↓
    Hai người dùng: luân phiên A và B
    → luôn có một tài khoản hợp lệ
    → không có khoảng trống nào

Ba lưu ý về IAM cho bí mật: | Lưu ý | Chi tiết | |---|---| | Cấp quyền theo ARN từng bí mật | | | Cần cả quyền KMS để giải mã | | | Resource policy hạn chế thêm | |

{"Effect": "Allow",
 "Action": "secretsmanager:GetSecretValue",
 "Resource": "arn:aws:secretsmanager:*:*:secret:csdl/san-xuat-*"}

⚠ Dấu -* ở cuối ARN là bắt buộc:

Secrets Manager thêm 6 ký tự ngẫu nhiên
  vào cuối ARN
        ↓
    ARN không có `-*` sẽ KHÔNG khớp
    → quyền bị từ chối mà nhìn chính sách
      thì thấy đúng

Ba lưu ý về dynamic reference: | Lưu ý | Chi tiết | |---|---| | Hỗ trợ ssm, ssm-secure, secretsmanager | | | Giải quyết lúc tạo/cập nhật stack | | | Không hoạt động với mọi thuộc tính | |

⚠ Và "giải quyết lúc triển khai" có hệ quả:

Bí mật xoay sau khi stack tạo xong
    → CloudFormation KHÔNG tự cập nhật
        ↓
    RDS đã nhận mật khẩu lúc tạo
    → xoay về sau do Lambda lo, không phải
      do CloudFormation

Ba lưu ý về xác thực IAM cho CSDL: | Lưu ý | Chi tiết | |---|---| | RDS MySQL/PostgreSQL hỗ trợ xác thực IAM | | | Không có mật khẩu nào để xoay | | | Token có hạn 15 phút | |

⚠ Đây là lựa chọn tốt nhất khi dùng được:

aws rds generate-db-auth-token \
  --hostname csdl.abc.ap-southeast-1.rds.amazonaws.com \
  --port 3306 --username ung_dung

Không có mật khẩu tồn tại
    → không có gì để rò rỉ
    → không có gì để xoay
        ↓
    Nhưng có giới hạn kết nối mỗi giây
    → không hợp mọi khối lượng công việc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem template đã đẩy lên — không được có mật khẩu | | | Chạy xoay thủ công, xem ứng dụng còn kết nối được | | | Kiểm CloudTrail xem ai đọc bí mật | |

Và một lời khuyên: hãy để Secrets Manager tự sinh mật khẩu thay vì tự đặt rồi cất vào đó. Mật khẩu do người gõ ra luôn để lại dấu vết ở đâu đó — lịch sử shell, một ticket, một tin nhắn — còn mật khẩu chưa ai từng nhìn thấy thì không.

Câu 86 Domain - Design for New Solutions

A shipping firm runs its web applications on its on-premises data center. The servers have a dependency on non-x86 hardware and the management plans to use AWS to scale its on-premises data storage. However, the backup application is only able to write to POSIX-compatible block-based storage. There is a total of 1,000 TB of data files that need to be mounted to a single folder on the file server. Existing users must also be able to access portions of this data while the backups are taking place.

Which of the following backup solutions would be most appropriate to meet the above requirements?

  1. A Use Amazon S3 as the target for your data backups.
  2. B Use Amazon Glacier as the target for your data backups.
  3. C Provision Gateway Cached Volumes from AWS Storage Gateway.
  4. D Provision Gateway Stored Volumes from AWS Storage Gateway.
Xem giải thích

Đáp án

C — Dùng Gateway Cached Volumes của AWS Storage Gateway.

Vì sao đúng

Đề nêu ba yêu cầu, và chế độ cached khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Lưu khối lượng lớn (khoảng 1.000 TB) | dữ liệu chính nằm trên S3 | | Truy cập độ trễ thấp cho dữ liệu hay dùng | cache cục bộ | | Không mở rộng lưu trữ tại chỗ | chỉ cần đĩa cho cache |

⚠ Đây là điểm khác biệt cốt lõi giữa hai chế độ volume: | Chế độ | Dữ liệu chính | Đĩa cục bộ cần | |---|---|---| | Cached | trên S3 | chỉ cho cache | | Stored | trên đĩa cục bộ | TOÀN BỘ dung lượng |

1.000 TB với chế độ stored
    → phải có 1.000 TB đĩa tại chỗ
    → đúng thứ đề muốn tránh
        ↓
    Chế độ cached: vài TB đĩa cho cache
    → phần còn lại trên S3

Luồng đọc và ghi:

Ứng dụng ghi qua iSCSI
    → gateway ghi vào upload buffer
        ↓
    Nén và tải bất đồng bộ lên S3
        ↓
    Đọc: có trong cache → trả ngay
          không có → lấy từ S3

⚠ Định cỡ cache quyết định hiệu năng:

AWS khuyến nghị cache ít nhất bằng
  20% dữ liệu đang hoạt động
        ↓
    Cache quá nhỏ: mọi lần đọc đi ra S3
    → độ trễ cao, mất hết lợi ích

Theo dõi tỷ lệ trúng cache:

aws cloudwatch get-metric-statistics \
  --namespace AWS/StorageGateway \
  --metric-name CachePercentDirty \
  --dimensions Name=GatewayId,Value=sgw-abc \
  --start-time 2026-08-30T00:00:00Z \
  --end-time 2026-08-30T23:59:59Z \
  --period 3600 --statistics Average

⚠ CachePercentDirty cao là dấu hiệu nguy hiểm:

Dữ liệu ghi vào chưa kịp tải lên S3
    → tỷ lệ dirty tăng
        ↓
    Gateway hỏng lúc này = MẤT phần chưa tải
    → nghĩa là upload buffer hoặc
      băng thông không đủ

Ảnh chụp để sao lưu:

aws storagegateway create-snapshot-from-volume-recovery-point \
  --volume-arn <arn> --snapshot-description "sao luu hang ngay"

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Dung lượng gần như không giới hạn nhờ S3 | | | Chỉ trả tiền cho dung lượng dùng thật | | | Ảnh chụp thành EBS snapshot, khôi phục lên EC2 được | |

⚠ Lợi ích thứ ba là con đường di chuyển lên cloud:

Volume gateway chụp ảnh → EBS snapshot
    → tạo volume EBS từ đó
        ↓
    Gắn vào EC2
    → dữ liệu tại chỗ dùng được trên cloud
      mà không cần chép lại

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

  • **B. Dùng Gateway Stored Volumes — đây là phương án gần nhất và cùng là volume gateway, nhưng chế độ stored giữ toàn bộ dữ liệu trên đĩa cục bộ và chỉ sao lưu lên S3; nó không giảm nhu cầu lưu trữ tại chỗ chút nào.
  • **A. Dùng Tape Gateway — thay thư viện băng từ, dành cho lưu trữ dài hạn; không cho truy cập độ trễ thấp theo kiểu volume.
  • **D. Dùng File Gateway — cũng để dữ liệu trên S3 với cache cục bộ, nhưng giao thức là NFS/SMB; đề mô tả nhu cầu volume khối (iSCSI), và mỗi tệp thành một object S3 riêng.

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

⚠ Tên gọi trong đề đã cũ, và có một giới hạn dung lượng đáng lưu ý.

Tên cũ Tên hiện tại
Gateway Cached Volumes Volume Gateway — chế độ cached
Gateway Stored Volumes Volume Gateway — chế độ stored

Và về con số 1.000 TB trong đề:

Volume gateway chế độ cached:
    tối đa 32 TiB mỗi volume
    tối đa 32 volume mỗi gateway
        ↓
    Trần khoảng 1 PiB mỗi gateway
    → 1.000 TB VỪA ĐỦ, không có nhiều dư

⚠ Ở quy mô này nên cân nhắc lựa chọn khác: | Lựa chọn | Hợp khi | |---|---| | File Gateway | dữ liệu là tệp, không cần khối | | DataSync + S3 | chuyển hẳn lên cloud | | FSx File Gateway | chia sẻ SMB doanh nghiệp | | Nhiều volume gateway | vượt trần một gateway |

Volume gateway hợp nhất với khối lượng
  cần giao thức khối và giữ tại chỗ
        ↓
    Còn nếu chỉ là tệp: File Gateway
      đơn giản hơn và không có trần 1 PiB

Ghi nhớ

⚠ Bốn loại Storage Gateway — bảng phải thuộc: | Loại | Giao thức | Dùng cho | |---|---|---| | File Gateway (S3) | NFS, SMB | tệp thành object S3 | | FSx File Gateway | SMB | cache cho FSx for Windows | | Volume Gateway | iSCSI | volume khối | | Tape Gateway | iSCSI VTL | thay thư viện băng từ |

Từ khoá nhận diện:

"block storage, low latency, unlimited capacity" → Volume Gateway cached "keep full copy on-premises, back up to cloud" → Volume Gateway stored "replace tape library" → Tape Gateway "NFS or SMB share backed by S3" → File Gateway

Ba lưu ý về định cỡ: | Lưu ý | Chi tiết | |---|---| | Cache: ít nhất 20% dữ liệu hoạt động | | | Upload buffer: theo tốc độ ghi và băng thông | | | Cả hai dùng đĩa cục bộ riêng biệt | |

⚠ Công thức tính upload buffer của AWS:

(tốc độ ghi ứng dụng − tốc độ tải lên)
  × thời gian ghi
        ↓
    Ghi 10 MB/s, tải lên 5 MB/s, ghi 12 giờ
    → (10−5) × 43.200 = 216 GB
    → tối thiểu 150 GB

Ba lưu ý về băng thông: | Lưu ý | Chi tiết | |---|---| | Đặt giới hạn băng thông theo lịch | | | Ghi nhiều hơn tải lên thì buffer đầy | | | Buffer đầy: ứng dụng bị chặn ghi | |

⚠ Đây là chế độ hỏng phải hiểu:

Upload buffer đầy
    → gateway từ chối ghi mới
        ↓
    Ứng dụng thấy đĩa "treo"
    → theo dõi `UploadBufferPercentUsed`
      và cảnh báo ở 80%

Ba lưu ý về sẵn sàng cao: | Lưu ý | Chi tiết | |---|---| | Chạy trên VMware vSphere HA được | | | Hoặc chạy gateway trên EC2 | | | Ảnh chụp định kỳ là lớp bảo vệ cuối | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Đĩa cache nên là SSD | | | Cấp đủ CPU và RAM cho máy ảo gateway | | | Theo dõi CacheHitPercent | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Dữ liệu mã hoá khi truyền và khi lưu | | | Dùng KMS khoá riêng nếu cần | | | CHAP xác thực kết nối iSCSI | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Trả tiền lưu trữ S3 thực dùng | | | Ảnh chụp tính như EBS snapshot | | | Không tính phí nhập dữ liệu | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ đọc dữ liệu trong và ngoài cache | | | Theo dõi UploadBufferPercentUsed | | | Thử khôi phục từ ảnh chụp | |

Và một lời khuyên: hãy đặt cảnh báo trên UploadBufferPercentUsed trước khi đưa gateway vào sản xuất. Buffer đầy không báo lỗi rõ ràng — nó chỉ khiến ứng dụng ghi chậm dần rồi treo, và triệu chứng đó dẫn người gỡ lỗi đi tìm ở mọi nơi trừ chỗ đúng.

Câu 87 Domain - Design Solutions for Organizational Complexity

A logistics company is developing a new application that will be used for all its departments. All of the company's AWS accounts are under OrganizationA in its AWS Organizations. A certain feature of the application must allow AWS resource access from a third-party account which is under AWS Organizations named OrganizationB. The company wants to follow security best practices and grant "least privilege" access using API or CLI to the third-party account.

Which of the following options is the recommended way to securely allow OrganizationB to access AWS resources on OrganizationA?

  1. A

    The logistics company should create an IAM role and attach an IAM policy allowing only the required access. The third-party account should then use AWS STS to assume the IAM role’s Amazon Resource Name (ARN) when requesting access to OrganizationA’s AWS resources.
  2. B

    The third-party account should create an External ID that will be given to OrganizationA. The logistics company should then create an IAM role with the required access and put the External ID in the IAM role’s trust policy. The third-party account should use the IAM role’s ARN and External ID when requesting access to OrganizationA’s AWS resources.
  3. C

    The third-party AWS Organization must integrate with the AWS Identity Center of the logistics company. Then create custom IAM policies for the third-party account to only access specific resources under OrganizationA.
  4. D

    The logistics company must create an IAM user with an IAM policy allowing only the required access. The logistics company should then send the AWS credentials to the third-party account to allow login and perform only specific tasks.
Xem giải thích

Đáp án

B — Yêu cầu bên thứ ba tự tạo External ID và đưa giá trị đó vào trust policy của vai trò IAM.

Vì sao đúng

External ID là cơ chế AWS thiết kế riêng cho tình huống này: cấp quyền cho một bên thứ ba giả nhận vai trò trong tài khoản của bạn.

⚠ Vấn đề mà External ID giải quyết gọi là "confused deputy":

Công ty giám sát X phục vụ nhiều khách hàng
    → giữ ARN vai trò của từng khách
        ↓
    Kẻ tấn công là khách hàng của X
    → đưa cho X ARN vai trò của BẠN
        ↓
    X giả nhận vai trò đó và báo cáo
      dữ liệu về cho kẻ tấn công
    → X bị lợi dụng làm "phó quan bối rối"

⚠ External ID chặn đúng điều đó:

Trust policy đòi External ID = "abc-123"
    → chỉ X biết giá trị này
      (X tự sinh, gắn với tài khoản khách hàng)
        ↓
    Kẻ tấn công không đoán được
    → và X sẽ dùng External ID của
      CHÍNH kẻ tấn công, không khớp

Trust policy đúng:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Principal": {"AWS":
    "arn:aws:iam::999988887777:root"},
  "Action": "sts:AssumeRole",
  "Condition": {"StringEquals":
    {"sts:ExternalId": "khach-hang-abc-123"}}}]}

⚠ Và điểm mấu chốt: bên thứ ba tạo External ID, KHÔNG phải bạn:

Nếu bạn tự chọn giá trị
    → hai khách hàng có thể chọn trùng
    → hoặc chọn giá trị dễ đoán
        ↓
    Bên thứ ba sinh giá trị duy nhất
      cho từng khách hàng
    → và họ chịu trách nhiệm giữ đúng

Bên thứ ba giả nhận:

aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/GiamSat \
  --role-session-name phien-giam-sat \
  --external-id khach-hang-abc-123

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chặn tấn công confused deputy | | | Không cần chia sẻ credential lâu dài | | | Thu hồi bằng cách xoá vai trò hoặc đổi điều kiện | |

⚠ Và External ID KHÔNG phải là bí mật:

Nó không thay thế xác thực
    → bên thứ ba vẫn phải có credential
      hợp lệ của tài khoản họ
        ↓
    External ID chỉ bảo đảm rằng
      họ đang hành động THAY MẶT
      đúng khách hàng

Thêm lớp bảo vệ bằng đặc quyền tối thiểu:

{"Effect": "Allow",
 "Action": ["cloudwatch:GetMetricData",
            "cloudwatch:ListMetrics"],
 "Resource": "*"}

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

  • **A. Tạo IAM user và đưa access key cho bên thứ ba — đây là phương án gần nhất và chạy được, nhưng credential tồn tại lâu dài nằm ở hệ thống bên ngoài; rò rỉ là mất quyền kiểm soát, và không có hạn dùng tự động.
  • **C. Bạn tự sinh External ID rồi đưa cho bên thứ ba — sai chiều: AWS quy định rõ bên thứ ba là bên sinh giá trị này, vì họ mới biết cách bảo đảm nó duy nhất cho từng khách hàng.
  • **D. Dùng VPC peering với tài khoản của bên thứ ba — peering là kết nối mạng, không liên quan tới việc cấp quyền gọi API.

Ghi nhớ

⚠ Ba cách cấp quyền xuyên tài khoản — bảng phải thuộc: | Cách | Dùng khi | |---|---| | Vai trò + External ID | bên thứ ba, nhiều khách hàng | | Vai trò thường | tài khoản trong cùng tổ chức | | Resource policy | cấp quyền trên một tài nguyên cụ thể |

Từ khoá nhận diện:

"third-party access to your account" → vai trò + External ID "confused deputy" → External ID hoặc aws:SourceAccount "cross-account within organization" → vai trò + điều kiện aws:PrincipalOrgID "share an S3 bucket" → bucket policy

⚠ aws:PrincipalOrgID cho nội bộ tổ chức:

{"Condition": {"StringEquals":
  {"aws:PrincipalOrgID": "o-abc123"}}}

Không phải liệt kê từng tài khoản
    → tài khoản mới tham gia tổ chức
      tự động được phép
        ↓
    Và tài khoản ngoài tổ chức
      bị chặn dù biết ARN

Ba lưu ý về External ID: | Lưu ý | Chi tiết | |---|---| | Bên thứ ba sinh, không phải bạn | | | Duy nhất cho từng khách hàng của họ | | | Không phải bí mật, nhưng không được đoán được | |

Ba lưu ý về trust policy: | Lưu ý | Chi tiết | |---|---| | Nói AI được giả nhận | | | Kết hợp điều kiện: MFA, IP, thời gian | | | Tách biệt với permission policy | |

⚠ Thêm điều kiện IP cho bên thứ ba:

{"Condition": {
  "StringEquals": {"sts:ExternalId": "abc-123"},
  "IpAddress": {"aws:SourceIp": ["203.0.113.0/24"]}}}

Bên thứ ba gọi từ dải IP cố định
    → thêm điều kiện này
        ↓
    Credential rò rỉ vẫn không dùng
      được từ nơi khác

Ba lưu ý về đặc quyền tối thiểu với bên thứ ba: | Lưu ý | Chi tiết | |---|---| | Chỉ cấp đúng API họ cần | | | Ưu tiên chỉ đọc nếu đủ | | | Rà soát khi họ đổi tính năng | |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi mọi lần giả nhận | | | Cảnh báo nếu giả nhận ngoài giờ dự kiến | | | IAM Access Analyzer phát hiện truy cập ngoài | |

⚠ IAM Access Analyzer nên bật ở mọi tài khoản:

aws accessanalyzer create-analyzer \
  --analyzer-name phan-tich-to-chuc \
  --type ORGANIZATION

Nó liệt kê MỌI tài nguyên chia sẻ ra ngoài
    → vai trò, bucket, khoá KMS, hàng đợi
        ↓
    Thường phát hiện thứ không ai nhớ
      đã chia sẻ

Ba lưu ý về thời hạn phiên: | Lưu ý | Chi tiết | |---|---| | Mặc định 1 giờ, tối đa 12 giờ | | | Đặt ngắn nhất mà vẫn dùng được | | | Chuỗi giả nhận vai trò tối đa 1 giờ | |

Ba lưu ý về thu hồi: | Lưu ý | Chi tiết | |---|---| | Xoá vai trò cắt quyền ngay | | | Hoặc thêm Deny vào permission policy | | | Phiên đang chạy vẫn hết hạn tự nhiên | |

⚠ Thu hồi phiên đang hoạt động cần chính sách theo thời điểm:

{"Effect": "Deny", "Action": "*", "Resource": "*",
 "Condition": {"DateLessThan":
   {"aws:TokenIssueTime": "2026-08-30T10:00:00Z"}}}

Từ chối mọi token phát hành trước mốc này
    → phiên đang chạy chết ngay
    → phiên mới vẫn tạo được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử giả nhận không có External ID — phải bị từ chối | | | Thử với External ID sai — phải bị từ chối | | | Xem CloudTrail có ghi externalId không | |

Và một lời khuyên: hãy rà soát danh sách vai trò cấp cho bên thứ ba mỗi quý. Các đối tác đến rồi đi, hợp đồng kết thúc, nhưng vai trò IAM thì ở lại — và một vai trò cho một nhà cung cấp bạn đã ngừng dùng từ hai năm trước vẫn là một cánh cửa mở.

Câu 88 Domain - Continuous Improvement for Existing Solutions
A health insurance company has recently adopted a hybrid cloud architecture which connects their on-premises network and their cloud infrastructure in AWS. They have an ELB which has a set of EC2 instances behind them. As the cloud engineer of the company, your manager instructed you to ensure that the SSL key used to encrypt data is always kept secure at all times. In addition, the application logs should only be decrypted by a handful of key users. In this scenario, which of the following meets all of the requirements?
  1. A

    1. Use the ELB to distribute traffic to a set of EC2 instances.

    2. Configure the ELB to perform TCP load balancing.

    3. Use an AWS CloudHSM instance to perform the SSL transactions.

    4. Persist your application server logs to a private S3 bucket using SSE.
  2. B

    1. Use the ELB to distribute traffic to a set of EC2 instances.

    2. Upload the private key to the EC2 instances and configure it to offload the SSL traffic.

    3. Persist your application server logs to an ephemeral volume that has been encrypted using a randomly generated AES key.
  3. C

    1. Use the ELB to distribute traffic to a set of EC2 instances.

    2. Use TCP load balancing on the ELB and configure your EC2 instances to retrieve the private key from a non-public S3 bucket on boot.

    3. Persist your application server logs to a private S3 bucket using SSE.
  4. D

    1. Use the ELB to distribute traffic to a set of EC2 instances.

    2. Configure the ELB to perform TCP load balancing.

    3. Use an AWS CloudHSM instance to perform the SSL transactions.

    4. Persist your application server logs to an ephemeral volume that has been encrypted using a randomly generated AES key.
Xem giải thích

Đáp án

A — Dùng Elastic Load Balancer kiểu TCP, đặt CloudHSM ở hai vùng sẵn sàng, và bật mã hoá phía máy chủ của S3.

Vì sao đúng

Đề nêu ba yêu cầu về mã hoá, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Mã hoá đầu-cuối, không giải mã ở tầng cân bằng tải | TCP listener chuyển tiếp nguyên khối | | Khoá trong thiết bị chuyên dụng, kiểm soát toàn quyền | CloudHSM | | Dữ liệu mã hoá khi lưu | SSE của S3 |

⚠ TCP listener là điểm mấu chốt — nó KHÔNG chấm dứt TLS:

HTTPS listener: giải mã ở ELB
    → gói tin ở dạng rõ trong bộ nhớ ELB
    → mã hoá lại nếu gửi tiếp bằng HTTPS
        ↓
    TCP listener: chuyển tiếp byte thô
    → TLS chấm dứt tại instance
    → không nơi nào ở giữa thấy dữ liệu rõ

Yêu cầu "không giải mã ở tầng cân bằng tải" chỉ thoả mãn được bằng cách này.

⚠ Và CloudHSM khác KMS ở chỗ ai kiểm soát khoá: | Tiêu chí | KMS | CloudHSM | |---|---|---| | Ai quản lý HSM | AWS | bạn | | Mô hình | nhiều khách chung | thiết bị riêng | | Chuẩn FIPS | 140-3 mức 3 | 140-3 mức 3 | | AWS truy cập được khoá | không, nhưng AWS vận hành | hoàn toàn không | | Giao diện | API AWS | PKCS#11, JCE, CNG |

Yêu cầu tuân thủ nói "khoá phải nằm trong
  thiết bị mà chỉ chúng tôi kiểm soát"
        ↓
    Đó là CloudHSM
    → KMS không đáp ứng được điều khoản này

⚠ Hai HSM ở hai AZ là yêu cầu tối thiểu:

Một HSM: mất AZ đó là mất khoá
    → KHÔNG khôi phục được
        ↓
    Cụm từ hai HSM trở lên: tự đồng bộ
    → mất một cái vẫn hoạt động

Tạo cụm hai AZ:

aws cloudhsmv2 create-cluster \
  --hsm-type hsm1.medium \
  --subnet-ids subnet-1a subnet-1c

aws cloudhsmv2 create-hsm --cluster-id cluster-abc \
  --availability-zone ap-southeast-1a
aws cloudhsmv2 create-hsm --cluster-id cluster-abc \
  --availability-zone ap-southeast-1c

Mã hoá S3:

aws s3api put-bucket-encryption --bucket du-lieu-nhay-cam \
  --server-side-encryption-configuration '{
    "Rules": [{"ApplyServerSideEncryptionByDefault":
      {"SSEAlgorithm": "aws:kms",
       "KMSMasterKeyID": "<arn-khoa-custom-key-store>"},
      "BucketKeyEnabled": true}]}'

⚠ Custom key store nối KMS với CloudHSM:

Khoá gốc nằm trong CloudHSM của bạn
    → nhưng dùng được qua API KMS thông thường
        ↓
    S3, EBS, RDS mã hoá như bình thường
    → mà khoá vẫn trong HSM bạn kiểm soát

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có điểm nào dữ liệu ở dạng rõ trên đường truyền | | | Toàn quyền kiểm soát khoá, đáp ứng tuân thủ khắt khe | | | Chịu được mất một AZ | |

⚠ Đổi lại là trách nhiệm hoàn toàn thuộc về bạn:

Mất mọi bản sao khoá
    → AWS KHÔNG khôi phục được
    → dữ liệu mã hoá bằng nó mất vĩnh viễn
        ↓
    Phải sao lưu khoá và giữ credential
      quản trị HSM cực kỳ cẩn thận

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

  • **B. Dùng HTTPS listener với chứng chỉ ACM trên ELB và CloudHSM phía sau — đây là phương án gần nhất và đơn giản hơn nhiều trong vận hành, nhưng HTTPS listener giải mã tại ELB, vi phạm yêu cầu không giải mã ở tầng cân bằng tải.
  • **C. Dùng một CloudHSM duy nhất — không có dự phòng; mất AZ đó là mất khoá không khôi phục được.
  • **D. Dùng KMS thay CloudHSM — KMS là dịch vụ dùng chung do AWS vận hành; đề nêu yêu cầu thiết bị chuyên dụng thì KMS không đáp ứng.

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

⚠ Câu này gần như trùng với một câu khác trong cùng bộ đề (mã #10363).

Cả hai đều là "TCP ELB + CloudHSM hai AZ + SSE của S3", chỉ khác cách diễn đạt bối cảnh. Trong bộ nguồn có nhiều cặp như vậy — đó là dấu hiệu bộ đề được gom từ nhiều lần thi khác nhau chứ không phải được biên tập lại.

Và có một điểm về dịch vụ đã đổi:

Classic Load Balancer có "TCP listener"
    ↓
Nay: Network Load Balancer
  → làm việc ở tầng 4, chuyển tiếp TCP
  → hoặc ALB không dùng được cho việc này
    vì nó luôn ở tầng 7

⚠ Chọn NLB khi cần TLS đi thẳng tới instance:

NLB chế độ TCP: chuyển tiếp thô
    → TLS chấm dứt ở instance
        ↓
    NLB chế độ TLS: chấm dứt tại NLB
    → khác nhau hoàn toàn, đọc kỹ đề

Ghi nhớ

⚠ Ba cách xử lý TLS ở tầng cân bằng tải — bảng phải thuộc: | Cách | TLS chấm dứt ở | Cân bằng tải thấy dữ liệu | |---|---|---| | TLS termination | ELB | CÓ | | TLS passthrough (TCP) | instance | không | | Re-encryption | ELB rồi mã hoá lại | CÓ ở giữa |

Từ khoá nhận diện:

"end-to-end encryption, LB must not decrypt" → NLB chế độ TCP "dedicated hardware, full key control" → CloudHSM "FIPS 140-3 Level 3" → CloudHSM hoặc KMS "managed key service" → KMS

⚠ Đánh đổi của TLS passthrough: | Mất gì | Chi tiết | |---|---| | Không định tuyến theo đường dẫn hay header | | | Không chèn X-Forwarded-For | | | Không dùng được WAF ở tầng cân bằng tải | | | Mỗi instance phải quản chứng chỉ riêng | |

Điểm cuối đáng cân nhắc nhất
    → chứng chỉ trên hàng chục instance
    → phải có quy trình triển khai và gia hạn

Ba lưu ý về CloudHSM: | Lưu ý | Chi tiết | |---|---| | Chạy trong VPC của bạn, có ENI riêng | | | Ít nhất hai HSM cho sẵn sàng cao | | | Sao lưu tự động, mã hoá bằng khoá của AWS | |

Ba lưu ý về vận hành CloudHSM: | Lưu ý | Chi tiết | |---|---| | Tự quản lý người dùng và khoá bên trong | | | Mất credential quản trị là mất cụm | | | Chi phí theo giờ mỗi HSM, không rẻ | |

⚠ Chi phí là yếu tố hay bị bỏ qua khi thiết kế:

Hai HSM chạy 24/7
    → chi phí đáng kể mỗi tháng
        ↓
    Chỉ chọn khi có yêu cầu tuân thủ
      thật sự đòi hỏi
    → KMS đáp ứng phần lớn nhu cầu
      với chi phí thấp hơn nhiều

Ba trường hợp thật sự cần CloudHSM: | Trường hợp | Lý do | |---|---| | Quy định bắt khoá trong HSM chuyên dụng | | | Cần PKCS#11 hoặc JCE | | | Vận hành CA riêng | |

Ba lưu ý về SSE của S3: | Loại | Ai giữ khoá | |---|---| | SSE-S3 | AWS hoàn toàn | | SSE-KMS | khoá trong KMS, bạn kiểm soát chính sách | | DSSE-KMS | mã hoá hai lớp |

⚠ Bật S3 Bucket Key để giảm chi phí KMS:

Mỗi object gọi KMS một lần
    → bucket lưu lượng cao tốn rất nhiều
        ↓
    Bucket Key: một khoá cấp bucket
    → giảm tới 99% lời gọi KMS

Ba lưu ý về mã hoá đường truyền nội bộ: | Lưu ý | Chi tiết | |---|---| | Lưu lượng giữa các AZ nên mã hoá | | | Nhiều loại instance mã hoá sẵn ở tầng mạng | | | Kết nối tới RDS bật SSL | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bắt gói ở tầng cân bằng tải — phải là dữ liệu mã hoá | | | Tắt một HSM, xem ứng dụng còn chạy | | | Kiểm tra object S3 có header mã hoá | |

Và một lời khuyên: hãy cân nhắc thật kỹ trước khi chọn CloudHSM thay KMS. Toàn quyền kiểm soát khoá cũng có nghĩa là toàn bộ trách nhiệm khi mất khoá — và AWS sẽ không thể giúp bạn, kể cả khi họ muốn.

Câu 89 Domain - Continuous Improvement for Existing Solutions

A leading commercial bank has a hybrid cloud architecture and is using a Volume Gateway under the AWS Storage Gateway service to store their data via the Internet Small Computer Systems Interface (ISCSI). The security team has detected a series of replay attacks to your network, which is basically a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. After their investigation, they detected that the originator of the attack is trying to intercept the data with an intention to re-transmit it, which is possibly part of a masquerade attack by IP packet substitution.

As a Solutions Architect of the bank, how can you secure your AWS Storage Gateway from these types of attacks?

  1. A Replace ISCSI with more secure protocols like Common Internet File System (CIFS) Protocol or Server Message Block (SMB).
  2. B

    Configure a Challenge-Handshake Authentication Protocol (CHAP) to authenticate NFS connections and safeguard your network from replay attacks.
  3. C Configure a Challenge-Handshake Authentication Protocol (CHAP) to authenticate iSCSI and initiator connections.
  4. D Replace the current ISCSI Block Interface with an ISCSI Virtual Tape Library Interface.
Xem giải thích

Đáp án

C — Dùng CHAP để xác thực kết nối iSCSI và các initiator.

Vì sao đúng

Đề hỏi cách bảo đảm chỉ những máy chủ được phép mới kết nối được vào volume iSCSI của Storage Gateway, và CHAP là cơ chế xác thực của chính giao thức iSCSI:

Máy chủ (initiator) kết nối tới volume (target)
    → target gửi một thử thách ngẫu nhiên
        ↓
    Initiator băm thử thách bằng bí mật chung
    → gửi kết quả về
        ↓
    Target tính lại và so
    → khớp thì cho kết nối

⚠ Điểm mạnh của CHAP là bí mật KHÔNG đi qua đường truyền:

Xác thực bằng mật khẩu thuần
    → mật khẩu bay qua mạng
        ↓
    CHAP: chỉ gửi giá trị BĂM của
      thử thách + bí mật
    → nghe lén không lấy được bí mật

Cấu hình CHAP trên volume:

aws storagegateway update-chap-credentials \
  --target-arn <arn-target> \
  --secret-to-authenticate-initiator '<bi-mat-16-toi-16-ky-tu>' \
  --initiator-name iqn.1991-05.com.microsoft:may-chu-01

⚠ CHAP hai chiều bảo vệ cả hai phía:

aws storagegateway update-chap-credentials \
  --target-arn <arn-target> \
  --secret-to-authenticate-initiator '<bi-mat-1>' \
  --secret-to-authenticate-target '<bi-mat-2>' \
  --initiator-name iqn.1991-05.com.microsoft:may-chu-01

Một chiều: target xác thực initiator
    → máy chủ giả không kết nối được
        ↓
    Hai chiều: initiator cũng xác thực target
    → chống cả target giả mạo

⚠ Bí mật CHAP có ràng buộc độ dài phải nhớ:

Bí mật xác thực initiator: 12-16 ký tự
Bí mật xác thực target: 12-16 ký tự
Và hai bí mật phải KHÁC nhau
        ↓
    Đặt sai độ dài: API từ chối

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Xác thực ở đúng tầng giao thức | | | Bí mật không truyền qua mạng | | | Cấu hình riêng cho từng initiator | |

⚠ Nhưng CHAP là một lớp, không phải toàn bộ phòng thủ:

CHAP: xác thực "anh là ai"
    + security group: giới hạn IP nào
      kết nối được cổng 3260
    + subnet riêng tư: không lộ ra Internet
        ↓
    Ba lớp cùng lúc mới đủ

Security group cho gateway:

aws ec2 authorize-security-group-ingress \
  --group-id sg-gateway --protocol tcp --port 3260 \
  --source-group sg-may-chu-ung-dung

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

  • **B. Dùng security group giới hạn IP kết nối được — đây là phương án gần nhất và là lớp bảo vệ cần có, nhưng nó kiểm soát ở tầng mạng chứ không xác thực danh tính: máy nào chiếm được IP trong dải cho phép đều kết nối được.
  • **A. Dùng IAM policy kiểm soát truy cập volume — IAM kiểm soát lời gọi API quản lý Storage Gateway, nó không nằm trên đường dữ liệu iSCSI.
  • **D. Dùng KMS mã hoá volume — mã hoá bảo vệ dữ liệu khi lưu, nó không ngăn một initiator trái phép kết nối vào và đọc volume đã được giải mã.

Ghi nhớ

⚠ Ba lớp bảo vệ volume iSCSI — bảng phải thuộc: | Lớp | Cơ chế | Bảo vệ khỏi | |---|---|---| | Mạng | security group, subnet riêng | kết nối từ nơi không mong muốn | | Xác thực | CHAP | initiator giả mạo | | Dữ liệu | mã hoá S3, TLS | đọc trộm dữ liệu |

Từ khoá nhận diện:

"authenticate iSCSI initiators" → CHAP "restrict which IPs can connect" → security group "encrypt data at rest" → KMS/SSE "control who can manage the gateway" → IAM

⚠ Phân biệt mặt phẳng quản lý và mặt phẳng dữ liệu:

Mặt phẳng quản lý: tạo/xoá volume,
  chụp ảnh — IAM kiểm soát
        ↓
    Mặt phẳng dữ liệu: đọc/ghi qua iSCSI
    → IAM KHÔNG chạm tới
    → CHAP và mạng lo phần này

Đây là lý do đáp án IAM sai.

Ba lưu ý về CHAP: | Lưu ý | Chi tiết | |---|---| | Bí mật 12-16 ký tự | | | Cấu hình cả trên gateway lẫn initiator | | | Đổi bí mật định kỳ | |

⚠ Cấu hình phía Windows initiator:

iSCSI Initiator → Discovery → Advanced
    → bật "Enable CHAP log on"
    → nhập tên và bí mật
        ↓
    Lệch một ký tự: kết nối thất bại
      với thông báo rất chung chung

Ba lưu ý về IQN: | Lưu ý | Chi tiết | |---|---| | Định danh duy nhất của initiator | | | Dạng iqn.yyyy-mm.tên-miền-đảo:tên | | | Đặt CHAP theo từng IQN | |

Ba lưu ý về mạng cho Storage Gateway: | Lưu ý | Chi tiết | |---|---| | Cổng 3260 cho iSCSI | | | Cổng 443 ra AWS | | | Cổng 80 chỉ khi kích hoạt | |

⚠ Đặt gateway trong subnet riêng tư:

Volume iSCSI lộ ra Internet
    → quét cổng 3260 tìm được
        ↓
    Subnet riêng tư + VPC endpoint
    → không có đường vào từ ngoài

aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.ap-southeast-1.storagegateway \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-rieng-tu

Ba lưu ý về mã hoá: | Lưu ý | Chi tiết | |---|---| | Dữ liệu trên S3 mã hoá mặc định | | | Dùng khoá KMS riêng nếu cần kiểm soát | | | Truyền lên AWS qua TLS | |

⚠ Nhưng iSCSI trong mạng nội bộ KHÔNG mã hoá:

CHAP xác thực nhưng không mã hoá dữ liệu
    → lưu lượng iSCSI trong LAN ở dạng rõ
        ↓
    Cần mã hoá đường này: IPsec
    → hoặc chấp nhận rằng LAN là vùng tin cậy

Ba lưu ý về ảnh chụp: | Lưu ý | Chi tiết | |---|---| | Lên lịch tự động | | | Lưu thành EBS snapshot | | | Mã hoá kế thừa từ volume | |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudWatch có chỉ số cache và buffer | | | CloudTrail ghi thao tác quản lý | | | Cảnh báo khi gateway mất kết nối | |

Ba lưu ý về sẵn sàng cao: | Lưu ý | Chi tiết | |---|---| | VMware HA cho gateway tại chỗ | | | Chạy gateway trên EC2 là lựa chọn khác | | | Ảnh chụp là lớp bảo vệ cuối | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử kết nối từ initiator không có CHAP — phải hỏng | | | Thử với bí mật sai — phải hỏng | | | Kiểm tra security group chỉ cho đúng máy chủ | |

Và một lời khuyên: hãy bật CHAP ngay khi tạo volume chứ đừng để dành làm sau. Bật CHAP trên volume đang phục vụ nghĩa là mọi initiator mất kết nối cho tới khi được cấu hình lại — và việc đó luôn khó xếp lịch hơn là làm ngay từ đầu.

Câu 90 Domain - Design for New Solutions

A company has three AWS accounts each with its own VPCs. There is a requirement for communication between the AWS resources across the accounts, so VPC peering needs to be configured. Please refer to the figure below for details of each VPC:

VPC-B and VPC-C have matching CIDR blocks. For a short-term requirement, VPC-A needs to communicate only with the database instance in VPC-B with an IP address of 10.0.0.77/32 while being able to communicate with all the resources in VPC-C. The Solutions Architect already created the necessary VPC peering links but VPC-A cannot effectively communicate to the VPC-B instance. The Solutions Architect suspects that the routes on each VPC still need proper configuration.

Which of the following solutions will allow VPC-A to communicate with the database instance in VPC-B while being able to communicate with all resources on VPC-C?

  1. A

    On VPC-A, add a static route for VPC-B CIDR (10.0.0.77/32) with the target pcx-aaaabbbb and another static route for VPC-C CIDR (10.0.0.0/16) with the target pcx-aaaacccc. On VPC-B, add a static route for VPC-A CIDR (172.16.0.0/16) with the target pcx-aaaabbbb. On VPC-C, add a static route for VPC-A CIDR (172.16.0.0/16) with the target pcx-aaaacccc.
  2. B

    On VPC-A, add a static route for VPC-B CIDR (10.0.0.0/24) with the target pcx-aaaabbbb and another static route for VPC-C CIDR (10.0.0.0/16) with the target pcx-aaaacccc. On VPC-B, add a static route for VPC-A CIDR (172.16.0.0/24) with the target pcx-aaaabbbb. On VPC-C, add a static route for VPC-A CIDR (172.16.0.0/24) with the target pcx-aaaacccc.
  3. C

    Enable dynamic route propagation in VPC-A with the peering targets pcx-aaaabbbb and pcx-aaaacccc respectively. On VPC-B, enable dynamic route propagation with peering target pcx-aaaabbbb and add a network access control list (NACL) that allows only connections to IP address 10.0.0.77/32 from pcx-aaaabbbb. On VPC-C, enable dynamic route propagation with the peering target pcx-aaaacccc.
  4. D

    On VPC-A, add a static route for VPC-B CIDR (10.0.0.0/24) with the target pcx-aaaabbbb and another static route for VPC-C CIDR (10.0.0.0/24) with the target pcx-aaaacccc. Add a network access control list (NACL) on VPC-A to deny all connections to VPC-B except for the IP address 10.0.0.77/32. On VPC-B, add a static route for VPC-A CIDR (172.16.0.0/24) with the target pcx-aaaabbbb. On VPC-C, add a static route for VPC-A CIDR (172.16.0.0/24) with the target pcx-aaaacccc.
Xem giải thích

Đáp án

A — Thêm tuyến tĩnh 10.0.0.77/32 trỏ tới VPC-B và tuyến 10.0.0.0/16 trỏ tới VPC-C.

Vì sao đúng

Đề mô tả tình huống hai VPC có dải địa chỉ chồng lấn, và cách giải quyết là dựa vào quy tắc tiền tố dài nhất của bảng định tuyến:

Gói tin gửi tới 10.0.0.77
    → khớp cả hai tuyến:
      10.0.0.77/32 (32 bit)
      10.0.0.0/16  (16 bit)
        ↓
    Chọn tuyến CÓ TIỀN TỐ DÀI HƠN
    → /32 thắng → đi VPC-B

Gói tin gửi tới 10.0.0.99
    → chỉ khớp 10.0.0.0/16
    → đi VPC-C

⚠ Đây là quy tắc nền tảng của mọi bảng định tuyến IP:

Tiền tố dài hơn = cụ thể hơn = thắng
    /32 (một địa chỉ) > /24 > /16 > /8 > /0
        ↓
    Không phụ thuộc thứ tự khai
    → không phụ thuộc "độ ưu tiên"

Thêm tuyến:

aws ec2 create-route --route-table-id rtb-abc \
  --destination-cidr-block 10.0.0.77/32 \
  --vpc-peering-connection-id pcx-vpc-b

aws ec2 create-route --route-table-id rtb-abc \
  --destination-cidr-block 10.0.0.0/16 \
  --vpc-peering-connection-id pcx-vpc-c

⚠ Nhưng phải hiểu rõ giới hạn của cách này:

Chỉ đi tới ĐÚNG MỘT máy chủ trong VPC-B
    → mọi địa chỉ 10.0.0.x khác đi VPC-C
        ↓
    Cần thêm máy chủ ở VPC-B
    → thêm một tuyến /32 nữa
    → không mở rộng được

⚠ Và VPC peering có ràng buộc tuyệt đối:

KHÔNG peering được hai VPC có CIDR
  chồng lấn NHAU
        ↓
    Nghĩa là VPC-B và VPC-C phải không
      chồng lấn với VPC gốc
    → tình huống trong đề chỉ hợp lệ khi
      B và C chồng lấn với NHAU, không phải
      với VPC đang định tuyến

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Giải quyết ngay bằng cấu hình định tuyến | | | Không cần đổi địa chỉ VPC nào | | | Chỉ vài dòng cấu hình | |

⚠ Nhưng đây là giải pháp tình thế, không phải thiết kế:

Mỗi máy chủ cần truy cập = một tuyến /32
    → 50 máy chủ = 50 tuyến
        ↓
    Bảng định tuyến có hạn ngạch
      (mặc định 50 tuyến, tăng lên 100)
    → và không ai bảo trì nổi

Ba giải pháp bền vững hơn: | Giải pháp | Cách làm | |---|---| | Đánh lại địa chỉ VPC | sạch nhất, tốn công nhất | | PrivateLink | lộ dịch vụ qua endpoint, không cần định tuyến | | NAT ở giữa | dịch địa chỉ chồng lấn |

⚠ PrivateLink là câu trả lời hiện đại cho CIDR chồng lấn:

Bên cung cấp tạo endpoint service (NLB)
    → bên tiêu thụ tạo interface endpoint
        ↓
    Endpoint có IP TRONG VPC người dùng
    → CIDR hai bên chồng lấn cũng không sao
    → vì không có định tuyến giữa hai VPC

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

  • **B. Thêm 10.0.0.0/16 trỏ VPC-B và 10.0.0.77/32 trỏ VPC-C — đây là phương án gần nhất và cấu trúc giống hệt, nhưng đảo ngược đích: máy chủ .77 sẽ đi VPC-C thay vì VPC-B, sai với yêu cầu.
  • **C. Thêm cả hai tuyến /16 cho hai VPC — bảng định tuyến không cho phép hai tuyến trùng CIDR; API sẽ từ chối.
  • **D. Dùng VPC peering không cần tuyến tĩnh — peering luôn cần tuyến tường minh; nó không tự sinh đường đi nào.

Ghi nhớ

⚠ Quy tắc chọn tuyến trong VPC — theo thứ tự:

1. Tuyến local (CIDR của chính VPC) — LUÔN thắng
2. Tiền tố dài nhất
3. Tuyến tĩnh trước tuyến động (BGP)
4. Với BGP: Direct Connect trước VPN

⚠ Điểm 1 là điều tuyệt đối:

Tuyến local không xoá được, không đè được
    → gói tin tới địa chỉ trong VPC
      luôn ở lại VPC
        ↓
    Đây là lý do CIDR chồng lấn
      không peering được

Từ khoá nhận diện:

"overlapping CIDR, reach one specific host" → tuyến /32 "overlapping CIDR, general solution" → PrivateLink "connect many VPCs" → Transit Gateway "most specific route wins" → tiền tố dài nhất

⚠ Transit Gateway cũng không giải được CIDR chồng lấn:

TGW đơn giản hoá kết nối nhiều VPC
    → nhưng vẫn định tuyến theo IP
        ↓
    Hai VPC cùng 10.0.0.0/16 gắn vào TGW
    → bảng định tuyến TGW không phân biệt được
    → vẫn phải PrivateLink hoặc NAT

Ba lưu ý về VPC peering: | Lưu ý | Chi tiết | |---|---| | Không bắc cầu — A-B và B-C không cho A-C | | | Cần tuyến ở CẢ HAI phía | | | CIDR không được chồng lấn | |

⚠ "Cần tuyến ở cả hai phía" là lỗi hay gặp:

Thêm tuyến ở VPC-A
    → gói tin đi được sang VPC-B
        ↓
    VPC-B không có tuyến về
    → phản hồi không quay lại
    → triệu chứng là timeout

Ba lưu ý về Transit Gateway: | Lưu ý | Chi tiết | |---|---| | Mô hình hub-and-spoke, có bắc cầu | | | Nhiều bảng định tuyến để phân đoạn | | | Tính phí theo attachment và dữ liệu | |

Ba lưu ý về PrivateLink: | Lưu ý | Chi tiết | |---|---| | Một chiều: người tiêu thụ gọi nhà cung cấp | | | CIDR chồng lấn không thành vấn đề | | | Cần NLB ở phía nhà cung cấp | |

⚠ Tính một chiều là điểm phải hiểu:

Người tiêu thụ khởi tạo kết nối
    → nhà cung cấp KHÔNG gọi ngược được
        ↓
    Cần hai chiều: dựng hai endpoint service
      ngược nhau

Ba lưu ý về hạn ngạch định tuyến: | Lưu ý | Chi tiết | |---|---| | 50 tuyến mỗi bảng, tăng được lên 100 | | | Nhiều tuyến /32 là dấu hiệu thiết kế sai | | | Gộp CIDR khi có thể | |

Ba lưu ý về quy hoạch địa chỉ: | Lưu ý | Chi tiết | |---|---| | Cấp phát từ một sơ đồ trung tâm | | | Chừa chỗ mở rộng | | | IPAM quản lý tập trung | |

⚠ IPAM là công cụ ngăn chồng lấn từ gốc:

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

Mọi VPC xin CIDR từ pool
    → IPAM bảo đảm không trùng
        ↓
    Chi phí nhỏ so với việc đánh lại
      địa chỉ một VPC sản xuất

Ba lưu ý về gỡ lỗi định tuyến: | Công cụ | Việc | |---|---| | Reachability Analyzer | kiểm đường đi có thông không | | VPC Flow Logs | xem gói bị chặn ở đâu | | describe-route-tables | xem tuyến thực tế |

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

Ba việc kiểm chứng: | Việc | Cách | |---|---| | ping hoặc curl tới .77 và một địa chỉ khác | | | Kiểm tuyến ở cả hai phía peering | | | Chạy Reachability Analyzer | |

Và một lời khuyên: hãy coi mỗi tuyến /32 là một khoản nợ kỹ thuật cần trả. Nó giải quyết được vấn đề trước mắt, nhưng bảng định tuyến đầy những địa chỉ đơn lẻ là dấu hiệu rõ ràng rằng quy hoạch địa chỉ cần được làm lại — và càng để lâu thì càng đắt.