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

Tìm thấy 2194 câu.

Câu 701 Design Resilient Architectures

A media streaming company expects a major increase in user activity during the launch of a highly anticipated live event. The streaming platform is deployed on AWS and uses Amazon EC2 instances for the application layer and Amazon RDS for persistent storage. The operations team needs to proactively monitor system performance to ensure a smooth user experience during the event. Their monitoring setup must provide data visibility with intervals of no more than 2 minutes, and the team prefers a solution that is quick to implement and low-maintenance.

Which solution should the team implement?

  1. A

    Install the CloudWatch agent on all EC2 instances. Configure the agent to collect high-resolution custom metrics and stream them to CloudWatch Logs for analysis via Amazon Athena
  2. B

    Enable detailed monitoring on all EC2 instances and use Amazon CloudWatch metrics to track performance
  3. C

    Stream EC2 system logs to an Amazon OpenSearch Service domain for real-time indexing and visualization. Use OpenSearch Dashboards to monitor CPU and memory metrics
  4. D

    Use Amazon EventBridge to collect EC2 state changes and publish them to Amazon SNS. Subscribe a monitoring dashboard to the SNS topic to visualize metrics
Xem giải thích

Đáp án

B — Bật detailed monitoring trên mọi EC2 instance và dùng CloudWatch metrics để theo dõi hiệu năng.

Vì sao đúng

Đề nêu ba yêu cầu, và detailed monitoring đáp ứng chính xác: | Yêu cầu | Cơ chế | |---|---| | Khoảng thời gian KHÔNG QUÁ 2 PHÚT | detailed monitoring = 1 phút | | Triển khai NHANH | một công tắc, hiệu lực ngay | | Ít bảo trì | không có agent, không có hạ tầng |

Con số là điểm quyết định:

Basic monitoring (mặc định):    5 PHÚT
Detailed monitoring:            1 PHÚT
        ↓
    Yêu cầu "no more than 2 minutes"
    → basic KHÔNG đạt, detailed ĐẠT

Bật:

aws ec2 monitor-instances --instance-ids i-0abc i-0def

Hoặc trong launch template để mọi máy mới đều có:

{"Monitoring": {"Enabled": true}}

Và RDS cũng có tuỳ chọn tương ứng:

aws rds modify-db-instance --db-instance-identifier db-streaming   --monitoring-interval 1 --monitoring-role-arn <arn-role>   --apply-immediately

Enhanced Monitoring của RDS cho tới 1 giây.

Vì sao đây là lựa chọn "quick to implement, low-maintenance":

✓ không cài agent lên máy nào
✓ không dựng cụm nào
✓ hiệu lực trong vài phút
✓ dùng chung CloudWatch alarm và dashboard đã có

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

  • **A. Cài CloudWatch agent, thu thập metric tuỳ chỉnh độ phân giải cao, đẩy vào CloudWatch Logs rồi phân tích bằng Athena — đây là phương án gần nhất và cho độ phân giải cao hơn nữa (tới 1 giây), nhưng nó nhiều công vận hành hơn hẳn: phải cài và cấu hình agent trên mọi máy. Và đẩy metric vào Logs rồi phân tích bằng Athena là đường vòng kỳ lạ — metric thuộc về CloudWatch Metrics, không phải Logs.
  • **C. Đẩy system log sang OpenSearch rồi dùng OpenSearch Dashboards theo dõi CPU và bộ nhớ — nặng và chậm triển khai: phải dựng cụm OpenSearch, cấu hình đường ống log, và log hệ thống không chứa sẵn metric CPU dưới dạng có thể vẽ biểu đồ.
  • **D. Dùng EventBridge thu thập thay đổi trạng thái EC2 rồi đẩy qua SNS — hiểu sai loại dữ liệu: EventBridge bắt sự kiện thay đổi trạng thái (running, stopped), không phải metric hiệu năng.

Ghi nhớ

Basic và Detailed monitoring — bảng phải thuộc: | | Basic (mặc định) | Detailed | |---|---|---| | Chu kỳ | 5 phút | 1 phút | | Chi phí | miễn phí | ~2,10 USD/instance/tháng | | Cần agent | ❌ | ❌ | | Bật bằng | — | một tham số |

Câu hỏi nào nêu ngưỡng thời gian thì so với hai con số 5 phút và 1 phút.

Ba mức độ phân giải metric của CloudWatch: | Mức | Chu kỳ | Nguồn | |---|---|---| | Standard | 60 giây | detailed monitoring, hầu hết dịch vụ | | High resolution | 1–30 giây | metric tuỳ chỉnh do bạn đẩy lên | | Basic | 5 phút | mặc định của EC2 |

Ba metric EC2 KHÔNG có sẵn — điểm quan trọng: | Metric | Vì sao | |---|---| | Sử dụng BỘ NHỚ | hypervisor không nhìn thấy | | Dung lượng đĩa còn trống | | | Số tiến trình, kết nối | |

Ba metric này CHỈ có khi cài CloudWatch agent
    → detailed monitoring KHÔNG cho chúng
        ↓
    Nếu cần theo dõi RAM, phải cài agent

Cài agent:

sudo yum install -y amazon-cloudwatch-agent
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl   -a fetch-config -m ec2 -s -c ssm:/cau-hinh/cloudwatch-agent

Ba metric EC2 có sẵn: | Metric | Ý nghĩa | |---|---| | CPUUtilization | | | NetworkIn, NetworkOut | | | StatusCheckFailed | sức khoẻ instance và hệ thống | | EBSReadOps, EBSWriteOps | với instance EBS-optimized |

Ba metric RDS cần theo dõi: | Metric | Ý nghĩa | |---|---| | CPUUtilization | | | DatabaseConnections | gần trần là ứng dụng bị từ chối | | FreeableMemory | | | ReadLatency, WriteLatency | |

Ba mức giám sát của RDS: | Mức | Chu kỳ | |---|---| | CloudWatch metric thường | 1 phút | | Enhanced Monitoring | tới 1 GIÂY, metric ở tầng OS | | Performance Insights | truy vấn nào tốn tài nguyên nhất |

Performance Insights rất hữu ích cho sự kiện lớn:

Nó cho biết TRUY VẤN NÀO đang gây tải
    → không chỉ "CPU cao" mà "câu SQL này chiếm 60% thời gian"
        ↓
    Bật miễn phí với 7 ngày lưu trữ

Ba việc nên chuẩn bị trước sự kiện lớn: | Việc | Chi tiết | |---|---| | Bật detailed monitoring | ← câu này | | Dựng dashboard tập trung | mọi metric quan trọng một chỗ | | Đặt alarm với ngưỡng phù hợp | và kiểm tra kênh thông báo |

Ba loại alarm nên có: | Alarm | Ngưỡng gợi ý | |---|---| | CPU của EC2 | trên 80% trong 2 chu kỳ | | DatabaseConnections | trên 80% giới hạn | | TargetResponseTime của ALB | vượt SLA | | HTTPCode_Target_5XX_Count | trên 0 |

Ba lưu ý về CloudWatch dashboard: | Lưu ý | Chi tiết | |---|---| | Ba dashboard đầu miễn phí | | | Chia sẻ được cho người không có tài khoản AWS | | | Đặt khoảng làm mới ngắn khi theo dõi trực tiếp | |

Ba lưu ý về chi phí giám sát: | Khoản | Giá tham khảo | |---|---| | Detailed monitoring | ~2,10 USD/instance/tháng | | Metric tuỳ chỉnh | ~0,30 USD/metric/tháng | | Alarm tiêu chuẩn | ~0,10 USD/tháng |

Metric tuỳ chỉnh dễ đội chi phí:

100 máy × 10 metric tuỳ chỉnh = 1.000 metric
    → 1.000 × 0,30 = 300 USD/tháng
        ↓
    Dùng dimension hợp lý, đừng tạo metric theo từng instance
    khi không cần

Ba công cụ giám sát bổ sung: | Công cụ | Việc | |---|---| | CloudWatch Synthetics | canary mô phỏng người dùng thật | | CloudWatch RUM | trải nghiệm thật của trình duyệt | | X-Ray | truy vết request qua các dịch vụ |

Synthetics đặc biệt hữu ích cho sự kiện trực tiếp:

Canary chạy mỗi phút từ nhiều Region
    → phát hiện sự cố TRƯỚC khi người dùng phàn nàn
    → và biết sự cố ảnh hưởng khu vực nào

Và một lời khuyên: hãy bật detailed monitoring trong launch template chứ không phải trên từng máy. Trong sự kiện lớn, Auto Scaling sẽ liên tục tạo máy mới — và những máy đó sẽ quay về chu kỳ 5 phút nếu cấu hình chỉ được áp cho các instance đang chạy tại thời điểm bạn bật.

Câu 702 Design Secure Architectures

A tech company runs a web application that includes multiple internal services deployed across Amazon EC2 instances within a VPC. These services require communication with a third-party SaaS provider's API for analytics and billing, which is also hosted on the AWS infrastructure. The company is concerned about minimizing public internet exposure while maintaining secure and reliable connectivity. The solution must ensure private access without allowing unsolicited incoming traffic from the SaaS provider.

Which solution will best meet these requirements?

  1. A

    Use AWS CloudFront to route requests from the application’s internal services to the SaaS provider through edge locations
  2. B

    Establish a VPN connection using AWS Site-to-Site VPN to create a secure tunnel between the internal services and the third-party SaaS provider
  3. C

    Use AWS PrivateLink to create a private endpoint within the application’s VPC that connects securely to the SaaS provider’s VPC
  4. D

    Set up VPC peering between the application VPC and the SaaS provider’s VPC to allow direct communication
Xem giải thích

Đáp án

C — Dùng AWS PrivateLink tạo endpoint riêng trong VPC của ứng dụng, kết nối an toàn tới VPC của nhà cung cấp SaaS.

Vì sao đúng

Đề nêu ba yêu cầu, và PrivateLink đáp ứng chính xác cả ba: | Yêu cầu | Cơ chế | |---|---| | Giảm tối đa phơi ra Internet công cộng | lưu lượng đi hoàn toàn trong mạng AWS | | Kết nối riêng tư và tin cậy | interface endpoint có IP riêng trong VPC | | KHÔNG cho phép lưu lượng vào từ phía SaaS | PrivateLink là MỘT CHIỀU |

Vế thứ ba là điểm phân biệt quyết định:

PrivateLink:
    → người tiêu dùng KHỞI TẠO kết nối tới dịch vụ
    → nhà cung cấp KHÔNG khởi tạo được kết nối ngược lại
        ↓
    Đúng "without allowing unsolicited incoming traffic"

Và VPC peering thì ngược lại:

VPC peering:
    → nối HAI MẠNG với nhau
    → cả hai bên đều khởi tạo kết nối được
        ↓
    Nhà cung cấp SaaS thấy được toàn bộ dải IP của bạn
    → và gọi vào được nếu security group cho phép

Cơ chế của PrivateLink:

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

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

Tạo endpoint:

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

Ba lợi ích nữa: | Lợi ích | Chi tiết | |---|---| | KHÔNG cần CIDR không chồng lấn | khác peering | | Chỉ expose MỘT dịch vụ | không mở cả mạng | | Gắn security group được | kiểm soát chi tiết |

Dòng đầu là ưu điểm thực tế lớn:

VPC peering đòi CIDR không được trùng
    → với nhà cung cấp SaaS bên ngoài, rất dễ trùng
        ↓
    PrivateLink KHÔNG quan tâm CIDR

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

  • **D. Thiết lập VPC peering giữa VPC ứng dụng và VPC của nhà cung cấp SaaS — đây là phương án gần nhất và cũng cho kết nối riêng tư, nhưng nó nối HAI MẠNG thay vì expose một dịch vụ: nhà cung cấp thấy toàn bộ dải IP của bạn và khởi tạo được kết nối vào, trái yêu cầu "no unsolicited incoming traffic". Và CIDR không được chồng lấn.
  • **B. Dựng Site-to-Site VPN giữa dịch vụ nội bộ và nhà cung cấp SaaS — sai công cụ: Site-to-Site VPN dùng để nối on-premises với AWS. Cả hai bên ở đây đều đã trong AWS.
  • **A. Dùng CloudFront định tuyến request tới nhà cung cấp SaaS qua edge location — sai mục đích: CloudFront là mạng phân phối nội dung cho người dùng cuối, không phải cơ chế kết nối riêng tư giữa hai VPC. Và lưu lượng vẫn đi qua Internet công cộng.

Ghi nhớ

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

Từ khoá nhận diện:

"expose a single service", "one-way", "SaaS provider", "overlapping CIDR" → PrivateLink "connect networks", "many VPCs" → Transit Gateway "two VPCs, simple" → VPC Peering

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

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

Phía nhà cung cấp tạo endpoint service:

aws ec2 create-vpc-endpoint-service-configuration   --network-load-balancer-arns <arn-nlb>   --acceptance-required   --supported-ip-address-types ipv4

Và cấp quyền cho người tiêu dùng:

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

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

Private DNS là tính năng quan trọng:

Không có private DNS:
    → phải gọi vpce-0abc-xyz.ap-northeast-1.vpce.amazonaws.com
    → phải sửa mã ứng dụng

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

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Gắn security group cho endpoint | giới hạn ai gọi được | | Endpoint policy giới hạn hành động | với dịch vụ AWS | | Bật VPC Flow Logs | audit lưu lượng |

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

So với NAT Gateway:

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

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

Trường hợp thứ ba đáng biết:

Đội A có một API dùng chung
    → tạo endpoint service
    → các đội khác tạo endpoint trong VPC của họ
        ↓
    Không phải peering mọi VPC với nhau

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

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

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

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

An online gaming company wants to block access to its application from specific countries; however, the company wants to allow its remote development team (from one of the blocked countries) to have access to the application. The application is deployed on Amazon EC2 instances running under an Application Load Balancer with AWS Web Application Firewall (AWS WAF).

As a solutions architect, which of the following solutions can be combined to address the given use-case? (Select two)

  1. A

    Use Application Load Balancer IP set statement that specifies the IP addresses that you want to allow through
  2. B

    Create a deny rule for the blocked countries in the network access control list (network ACL) associated with each of the Amazon EC2 instances
  3. C

    Use AWS WAF geo match statement listing the countries that you want to block
  4. D

    Use AWS WAF IP set statement that specifies the IP addresses that you want to allow through
  5. E

    Use Application Load Balancer geo match statement listing the countries that you want to block
Xem giải thích

Đáp án

C và D.

  • C — Dùng AWS WAF geo match statement liệt kê các quốc gia cần chặn
  • D — Dùng AWS WAF IP set statement khai các địa chỉ IP được phép đi qua

Vì sao đúng

Đề nêu hai yêu cầu đối nghịch nhau, và hai statement của WAF giải quyết đúng từng cái: | Yêu cầu | Cơ chế | |---|---| | Chặn truy cập từ một số quốc gia | geo match statement | | Nhưng CHO PHÉP đội phát triển ở một trong các nước đó | IP set statement, ưu tiên cao hơn |

Điểm mấu chốt là THỨ TỰ ưu tiên của rule:

Priority 1: Allow — IP set của đội phát triển
Priority 2: Block — geo match các quốc gia bị chặn
        ↓
    WAF đánh giá theo thứ tự, DỪNG ở rule đầu tiên khớp
        ↓
    IP của đội phát triển khớp rule 1 → ĐƯỢC PHÉP
    → không bao giờ tới rule 2

Đảo thứ tự là hỏng:

Priority 1: Block — geo match
Priority 2: Allow — IP set
        ↓
    Đội phát triển ở nước bị chặn khớp rule 1 trước
    → BỊ CHẶN, không bao giờ tới rule 2

Cấu hình:

aws wafv2 create-ip-set --name ip-doi-phat-trien --scope REGIONAL   --ip-address-version IPV4 --addresses 203.0.113.10/32 203.0.113.11/32

aws wafv2 create-web-acl --name acl-ung-dung --scope REGIONAL   --default-action Allow={}   --rules '[
    {"Name":"cho-phep-doi-phat-trien","Priority":1,
     "Statement":{"IPSetReferenceStatement":{"ARN":"<arn-ip-set>"}},
     "Action":{"Allow":{}},
     "VisibilityConfig":{"SampledRequestsEnabled":true,
       "CloudWatchMetricsEnabled":true,"MetricName":"chophep"}},
    {"Name":"chan-quoc-gia","Priority":2,
     "Statement":{"GeoMatchStatement":{"CountryCodes":["XX","YY"]}},
     "Action":{"Block":{}},
     "VisibilityConfig":{"SampledRequestsEnabled":true,
       "CloudWatchMetricsEnabled":true,"MetricName":"changeo"}}]'   --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=aclUngDung

Và gắn vào ALB:

aws wafv2 associate-web-acl --web-acl-arn <arn-acl>   --resource-arn <arn-alb>

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

  • **A. Dùng IP set statement CỦA APPLICATION LOAD BALANCER — đây là phương án gần nhất vì nội dung đúng, nhưng nó gán sai tính năng cho sai dịch vụ: ALB không có khái niệm "IP set statement". (ALB có điều kiện source-ip trong rule, nhưng đó là cơ chế khác và không kết hợp được với lọc theo quốc gia.)
  • **E. Dùng geo match statement CỦA ALB — cùng lỗi: ALB không có tính năng lọc theo quốc gia. Geo match là tính năng của WAF.
  • **B. Tạo deny rule trong NACL cho các quốc gia bị chặn — NACL chỉ làm việc với dải CIDR, không biết quốc gia: bạn sẽ phải tự duy trì danh sách hàng nghìn dải IP cho mỗi nước, mà chúng thay đổi liên tục. Và NACL có giới hạn số quy tắc rất thấp.

Ghi nhớ

Ba loại statement hay dùng của AWS WAF: | Statement | Việc | |---|---| | Geo match | chặn hoặc cho phép theo QUỐC GIA | | IP set | theo danh sách địa chỉ IP | | Rate-based | giới hạn số request mỗi IP | | Byte match, regex | theo nội dung request | | Size constraint | kích thước phần request |

Ba hành động của rule: | Hành động | Chi tiết | |---|---| | Allow | cho qua, DỪNG đánh giá | | Block | chặn, DỪNG đánh giá | | Count | chỉ đếm, TIẾP TỤC đánh giá | | CAPTCHA / Challenge | thử thách người dùng |

Count là công cụ quan trọng để thử rule an toàn:

Đặt rule mới ở chế độ Count trước
    → xem nó KHỚP bao nhiêu request thật
    → xác nhận không chặn nhầm người dùng hợp lệ
        ↓
    Rồi mới chuyển sang Block

Quy tắc vàng về thứ tự rule:

Rule NGOẠI LỆ (allow) phải có priority NHỎ HƠN rule chặn. WAF dừng ở rule đầu tiên khớp với hành động Allow hoặc Block.

Ba tài nguyên gắn được WAF: | Tài nguyên | Scope | |---|---| | CloudFront | CLOUDFRONT (phải tạo ở us-east-1) | | Application Load Balancer | REGIONAL | | API Gateway | REGIONAL | | AppSync, Cognito user pool, App Runner | REGIONAL |

Lưu ý: WAF KHÔNG gắn được vào NLB hay EC2 trực tiếp.

Ba lưu ý về geo match: | Lưu ý | Chi tiết | |---|---| | Dùng mã quốc gia ISO 3166-1 alpha-2 | VN, JP, US | | Dựa trên cơ sở dữ liệu GeoIP | không chính xác 100% | | VPN và proxy vượt qua được | |

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

Geo blocking chặn được người dùng thông thường
    → nhưng ai dùng VPN sẽ hiện ra ở nước khác
        ↓
    Đây là biện pháp GIẢM RỦI RO, không phải tường chắn tuyệt đối

Ba cách khai IP set: | Cách | Ví dụ | |---|---| | IP đơn | 203.0.113.10/32 | | Dải CIDR | 203.0.113.0/24 | | IPv6 | tạo IP set riêng cho IPv6 |

Cần IP set riêng cho IPv4 và IPv6 — một IP set chỉ chứa một loại.

Ba nhóm rule dựng sẵn của AWS: | Nhóm | Chống lại | |---|---| | AWSManagedRulesCommonRuleSet | các tấn công web phổ biến (OWASP) | | AWSManagedRulesSQLiRuleSet | SQL injection | | AWSManagedRulesAmazonIpReputationList | IP có tiếng xấu | | AWSManagedRulesBotControlRuleSet | bot |

Nên dùng managed rule group làm nền, thêm rule riêng ở trên.

Ba lưu ý về rate-based rule: | Lưu ý | Chi tiết | |---|---| | Đếm theo IP trong cửa sổ 5 phút | | | Ngưỡng tối thiểu 10 request | | | Kết hợp với scope-down statement được | chỉ áp cho một đường dẫn |

{"RateBasedStatement": {"Limit": 2000, "AggregateKeyType": "IP",
  "ScopeDownStatement": {"ByteMatchStatement": {
    "SearchString": "/dang-nhap", "FieldToMatch": {"UriPath": {}},
    "PositionalConstraint": "STARTS_WITH",
    "TextTransformations": [{"Priority":0,"Type":"LOWERCASE"}]}}}}

Giới hạn riêng cho trang đăng nhập — chống dò mật khẩu mà không ảnh hưởng phần còn lại.

Ba lưu ý về log của WAF: | Lưu ý | Chi tiết | |---|---| | Gửi được vào S3, CloudWatch Logs, hoặc Firehose | | | Che được trường nhạy cảm | mật khẩu trong body | | Dùng Athena phân tích log | |

aws wafv2 put-logging-configuration --logging-configuration   '{"ResourceArn":"<arn-acl>",
    "LogDestinationConfigs":["<arn-firehose>"],
    "RedactedFields":[{"SingleHeader":{"Name":"authorization"}}]}'

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Web ACL | ~5 USD/tháng | | Mỗi rule | ~1 USD/tháng | | Mỗi triệu request | ~0,60 USD |

Ba biện pháp bổ sung: | Biện pháp | Chi tiết | |---|---| | AWS Shield Advanced | chống DDoS nâng cao, có đội hỗ trợ | | Firewall Manager | áp WAF policy cho nhiều tài khoản | | CloudFront trước ALB | chặn ở biên, gần người tấn công hơn |

Và một lời khuyên: hãy đặt rule mới ở chế độ Count trong vài ngày trước khi chuyển sang Block. Với lọc theo quốc gia, cơ sở dữ liệu GeoIP không hoàn hảo — và bạn sẽ muốn biết chính xác bao nhiêu người dùng hợp lệ bị xếp nhầm quốc gia trước khi chặn họ thật.

Câu 704 Design High-Performing Architectures

You have built an application that is deployed with Elastic Load Balancing and an Auto Scaling Group. As a Solutions Architect, you have configured aggressive Amazon CloudWatch alarms, making your Auto Scaling Group (ASG) scale in and out very quickly, renewing your fleet of Amazon EC2 instances on a daily basis. A production bug appeared two days ago, but the team is unable to SSH into the instance to debug the issue, because the instance has already been terminated by the Auto Scaling Group. The log files are saved on the Amazon EC2 instance.

How will you resolve the issue and make sure it doesn't happen again?

  1. A

    Disable the Termination from the Auto Scaling Group any time a user reports an issue
  2. B

    Make a snapshot of the Amazon EC2 instance just before it gets terminated
  3. C

    Use AWS Lambda to regularly SSH into the Amazon EC2 instances and copy the log files to Amazon S3
  4. D

    Install an Amazon CloudWatch Logs agents on the Amazon EC2 instances to send logs to Amazon CloudWatch
Xem giải thích

Đáp án

D — Cài CloudWatch Logs agent trên các EC2 instance để đẩy log lên CloudWatch.

Vì sao đúng

Đề nêu vấn đề rõ: log nằm trên máy, máy bị ASG chấm dứt, log mất theo.

Log lưu trên đĩa cục bộ của EC2
    → ASG chấm dứt instance
    → volume bị xoá (mặc định `DeleteOnTermination = true`)
        ↓
    Log biến mất VĨNH VIỄN
    → không gỡ được lỗi đã xảy ra

CloudWatch Logs agent giải quyết triệt để:

Agent đọc tệp log và ĐẨY LIÊN TỤC lên CloudWatch Logs
    → log ra khỏi máy gần như ngay lập tức
        ↓
    Máy bị chấm dứt → log VẪN CÒN trong CloudWatch
    → tra cứu bất cứ lúc nào

Cài và cấu hình:

sudo yum install -y amazon-cloudwatch-agent

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl   -a fetch-config -m ec2 -s -c ssm:/cau-hinh/cloudwatch-agent

Cấu hình mẫu:

{"logs": {"logs_collected": {"files": {"collect_list": [
  {"file_path": "/var/log/ung-dung/*.log",
   "log_group_name": "/ung-dung/san-xuat",
   "log_stream_name": "{instance_id}",
   "retention_in_days": 30}]}}}}

{instance_id} trong tên stream là chi tiết quan trọng:

Mỗi instance có log stream riêng
    → biết log nào của máy nào
    → kể cả khi máy đã bị chấm dứt

Và nướng agent vào AMI để mọi máy mới đều có:

Máy mới do ASG tạo tự động chạy agent
    → không phải cài thủ công
        ↓
    Đây là điểm khiến giải pháp thật sự bền vững

Và có thêm hai lợi ích: | Lợi ích | Chi tiết | |---|---| | CloudWatch Logs Insights truy vấn được | tìm lỗi qua mọi máy cùng lúc | | Metric filter tạo cảnh báo từ log | báo ngay khi có lỗi |

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 50

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

  • **B. Chụp snapshot của EC2 ngay trước khi nó bị chấm dứt — đây là phương án gần nhất và về lý thuyết giữ được dữ liệu, nhưng nó phức tạp và không thực dụng: cần lifecycle hook, cần logic chụp snapshot, và để đọc log phải tạo volume từ snapshot rồi gắn vào máy khác. Với ASG thay máy hằng ngày, số snapshot tích tụ rất nhanh.
  • **C. Dùng Lambda SSH định kỳ vào EC2 và chép log lên S3 — nhiều vấn đề: Lambda phải nằm trong VPC, phải quản lý khoá SSH, và chép định kỳ nghĩa là log giữa hai lần chép vẫn mất. Đây là cách làm AWS khuyến nghị tránh.
  • **A. Tắt việc chấm dứt instance của ASG mỗi khi có báo lỗi — không giải quyết gì: sự cố đã xảy ra hai ngày trước, máy đã biến mất. Và tắt chấm dứt làm hỏng cơ chế co giãn.

Ghi nhớ

Nguyên tắc cốt lõi với hạ tầng co giãn:

Instance là TẠM THỜI. Mọi thứ cần giữ lại phải nằm NGOÀI instance.

Dữ liệu Đưa ra đâu
Log CloudWatch Logs ← câu này
Tệp người dùng tải lên S3
Phiên đăng nhập ElastiCache hoặc DynamoDB
Metric CloudWatch
Dữ liệu nghiệp vụ RDS, DynamoDB

Ba loại dữ liệu CloudWatch agent thu thập: | Loại | Ví dụ | |---|---| | Log tệp | log ứng dụng, /var/log/messages | | Metric hệ thống | RAM, đĩa — thứ EC2 KHÔNG có sẵn | | Log sự kiện Windows | |

Metric RAM là lý do thứ hai nên cài agent:

CloudWatch KHÔNG có metric bộ nhớ của EC2
    → hypervisor không nhìn thấy bên trong hệ điều hành
        ↓
    Chỉ có agent mới lấy được

Ba khái niệm của CloudWatch Logs: | Khái niệm | Nghĩa | |---|---| | Log group | nhóm log cùng loại, đặt retention ở đây | | Log stream | một nguồn — thường là một instance | | Log event | một dòng log |

Ba lưu ý về retention: | Lưu ý | Chi tiết | |---|---| | Mặc định là GIỮ MÃI MÃI | tốn tiền vô hạn | | Đặt retention ngay khi tạo log group | | | Xuất sang S3 nếu cần giữ lâu | rẻ hơn nhiều |

aws logs put-retention-policy   --log-group-name /ung-dung/san-xuat --retention-in-days 30

Đây là khoản chi phí âm thầm phổ biến nhất của CloudWatch Logs.

Ba công cụ phân tích log: | Công cụ | Việc | |---|---| | CloudWatch Logs Insights | truy vấn tương tác, trả kết quả trong giây | | Metric filter | biến mẫu log thành metric và alarm | | Xuất sang S3 + Athena | phân tích dài hạn, rẻ hơn |

Metric filter rất hữu ích:

aws logs put-metric-filter --log-group-name /ung-dung/san-xuat   --filter-name dem-loi --filter-pattern "ERROR"   --metric-transformations     metricName=SoLoiUngDung,metricNamespace=UngDung,metricValue=1

Rồi đặt alarm trên metric đó
    → biết ngay khi tỷ lệ lỗi tăng
    → thay vì phát hiện sau hai ngày như trong đề

Ba lưu ý về quyền: | Quyền | Chi tiết | |---|---| | Instance profile cần CloudWatchAgentServerPolicy | | | Thêm quyền đọc SSM Parameter nếu lấy cấu hình từ đó | | | Cần đường ra tới endpoint CloudWatch | NAT Gateway hoặc VPC endpoint |

Ba cách triển khai agent lên toàn đội máy: | Cách | Chi tiết | |---|---| | Nướng vào golden AMI | đơn giản và nhanh nhất | | User data cài lúc khởi động | thêm thời gian khởi động | | Systems Manager State Manager | áp cho máy đang chạy |

Ba lưu ý về chi phí CloudWatch Logs: | Khoản | Giá tham khảo | |---|---| | Nạp log | ~0,50 USD/GB | | Lưu trữ | ~0,03 USD/GB-tháng | | Logs Insights truy vấn | ~0,005 USD/GB quét |

Ba cách giảm chi phí log: | Cách | Tiết kiệm | |---|---| | Đặt retention hợp lý | rất nhiều | | Không đẩy log DEBUG lên production | | | Xuất sang S3 cho lưu trữ dài hạn | ~0,023 vs 0,03 USD/GB |

Ba lưu ý khi ASG thay máy: | Lưu ý | Chi tiết | |---|---| | Lifecycle hook cho phép đẩy nốt log trước khi tắt | | | Agent đẩy gần thời gian thực nên ít mất | | | {instance_id} trong tên stream để truy nguyên | |

Lifecycle hook cho phần log còn lại:

aws autoscaling put-lifecycle-hook   --auto-scaling-group-name asg-ung-dung   --lifecycle-hook-name day-not-log   --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING   --heartbeat-timeout 120

Ba việc nên làm cho khả năng quan sát: | Việc | Chi tiết | |---|---| | Log tập trung | ← câu này | | Metric tập trung | CloudWatch | | Truy vết phân tán | AWS X-Ray |

Và một lời khuyên: hãy đặt retention cho log group ngay khi tạo, đừng để mặc định. Mặc định là giữ vĩnh viễn, và một đội máy đẩy log liên tục sẽ tích tụ chi phí đều đặn suốt nhiều năm — khoản này không bao giờ gây sự cố nên cũng không bao giờ được ai chú ý tới.

Câu 705 Design Secure Architectures

A global media company uses a fleet of Amazon EC2 instances (behind an Application Load Balancer) to power its video streaming application. To improve the performance of the application, the engineering team has also created an Amazon CloudFront distribution with the Application Load Balancer as the custom origin. The security team at the company has noticed a spike in the number and types of SQL injection and cross-site scripting attack vectors on the application.

As a solutions architect, which of the following solutions would you recommend as the MOST effective in countering these malicious attacks?

  1. A

    Use Amazon Route 53 with Amazon CloudFront distribution
  2. B

    Use AWS Security Hub with Amazon CloudFront distribution
  3. C

    Use AWS Web Application Firewall (AWS WAF) with Amazon CloudFront distribution
  4. D

    Use AWS Firewall Manager with CloudFront distribution
Xem giải thích

Đáp án

C — Dùng AWS WAF cùng CloudFront distribution.

Vì sao đúng

Đề nêu chính xác loại tấn công mà WAF được thiết kế để chặn: | Tấn công | WAF xử lý | |---|---| | SQL injection | AWSManagedRulesSQLiRuleSet | | Cross-site scripting (XSS) | AWSManagedRulesCommonRuleSet |

Và gắn WAF vào CloudFront là vị trí tốt nhất:

Gắn ở CloudFront (biên):
    → chặn tấn công tại edge location gần người tấn công
    → lưu lượng độc hại KHÔNG bao giờ tới ALB hay EC2
        ↓
Gắn ở ALB:
    → cũng chặn được
    → nhưng lưu lượng đã đi qua Internet tới Region rồi

Cấu hình:

# Scope CLOUDFRONT phải tạo ở us-east-1
aws wafv2 create-web-acl --name acl-streaming --scope CLOUDFRONT   --region us-east-1 --default-action Allow={}   --rules '[
    {"Name":"chan-sqli","Priority":1,
     "Statement":{"ManagedRuleGroupStatement":{
       "VendorName":"AWS","Name":"AWSManagedRulesSQLiRuleSet"}},
     "OverrideAction":{"None":{}},
     "VisibilityConfig":{"SampledRequestsEnabled":true,
       "CloudWatchMetricsEnabled":true,"MetricName":"sqli"}},
    {"Name":"quy-tac-chung","Priority":2,
     "Statement":{"ManagedRuleGroupStatement":{
       "VendorName":"AWS","Name":"AWSManagedRulesCommonRuleSet"}},
     "OverrideAction":{"None":{}},
     "VisibilityConfig":{"SampledRequestsEnabled":true,
       "CloudWatchMetricsEnabled":true,"MetricName":"chung"}}]'   --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=aclStreaming

Và gắn vào distribution:

aws cloudfront update-distribution --id E1ABC   --distribution-config '{..., "WebACLId": "<arn-web-acl>", ...}'

Managed rule group được AWS cập nhật liên tục:

Đề nói "SPIKE in the NUMBER AND TYPES of attack vectors"
        ↓
    Kiểu tấn công MỚI liên tục xuất hiện
    → tự viết rule sẽ luôn chạy theo sau
        ↓
    AWS managed rule group tự cập nhật
    → không phải theo dõi thủ công

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

  • **D. Dùng AWS Firewall Manager với CloudFront — đây là phương án gần nhất và thật sự liên quan tới WAF, nhưng nó là công cụ QUẢN LÝ chứ không phải công cụ CHẶN: Firewall Manager áp và thực thi WAF policy trên nhiều tài khoản trong AWS Organizations. Ở đây chỉ có một ứng dụng, dùng WAF trực tiếp là đủ.
  • **B. Dùng AWS Security Hub với CloudFront — Security Hub tổng hợp phát hiện bảo mật, không chặn lưu lượng: nó thu thập kết quả từ GuardDuty, Inspector, Macie và trình bày tập trung.
  • **A. Dùng Route 53 với CloudFront — hoàn toàn không liên quan: Route 53 là dịch vụ DNS, không kiểm tra nội dung request.

Ghi nhớ

Các dịch vụ bảo mật của AWS — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | AWS WAF | lọc lưu lượng TẦNG 7 — SQLi, XSS, bot | | AWS Shield | chống DDoS (tầng 3/4 và 7) | | AWS Firewall Manager | quản lý WAF/Shield/SG trên NHIỀU tài khoản | | Network Firewall | tường lửa cấp VPC (tầng 3–7) | | Security Hub | TỔNG HỢP phát hiện, không chặn | | GuardDuty | phát hiện hành vi đe doạ | | Inspector | lỗ hổng phần mềm |

Từ khoá nhận diện:

"SQL injection", "XSS", "bad bots", "rate limiting by IP" → WAF "DDoS", "volumetric attack" → Shield "enforce WAF across many accounts" → Firewall Manager "aggregate security findings" → Security Hub

Ba tài nguyên gắn được WAF: | Tài nguyên | Scope | |---|---| | CloudFront | CLOUDFRONT — tạo ở us-east-1 | | Application Load Balancer | REGIONAL | | API Gateway | REGIONAL | | AppSync, Cognito, App Runner, Verified Access | REGIONAL |

Lưu ý: WAF KHÔNG gắn vào NLB hay EC2 trực tiếp được.

Gắn ở CloudFront hay ALB — bảng so sánh: | | CloudFront | ALB | |---|---|---| | Vị trí chặn | tại edge, gần người tấn công | tại Region | | Bảo vệ khi bị bỏ qua CloudFront | ❌ | ✅ | | Phù hợp | ứng dụng có CloudFront | ứng dụng chỉ có ALB |

Nên làm cả hai lớp:

WAF trên CloudFront: chặn phần lớn ở biên
    + ALB chỉ nhận lưu lượng TỪ CloudFront
        ↓
    Kẻ tấn công không gọi thẳng ALB để bỏ qua WAF được

Cách chặn truy cập thẳng vào ALB:

① Security group của ALB chỉ cho phép prefix list của CloudFront
② Hoặc CloudFront gửi header bí mật, WAF trên ALB kiểm tra

aws ec2 authorize-security-group-ingress --group-id sg-alb   --ip-permissions 'IpProtocol=tcp,FromPort=443,ToPort=443,
    PrefixListIds=[{PrefixListId=pl-58a04531}]'

AWS tự cập nhật prefix list của CloudFront — không phải theo dõi IP thủ công.

Ba nhóm managed rule quan trọng: | Nhóm | Chống lại | |---|---| | AWSManagedRulesCommonRuleSet | OWASP Top 10, gồm XSS | | AWSManagedRulesSQLiRuleSet | SQL injection | | AWSManagedRulesKnownBadInputsRuleSet | mẫu tấn công đã biết | | AWSManagedRulesAmazonIpReputationList | IP có tiếng xấu | | AWSManagedRulesBotControlRuleSet | bot (có phí thêm) |

Ba hành động của rule: | Hành động | Chi tiết | |---|---| | Allow | cho qua, dừng đánh giá | | Block | chặn, dừng đánh giá | | Count | chỉ đếm — dùng để THỬ rule an toàn | | CAPTCHA / Challenge | thử thách người dùng |

Luôn thử bằng Count trước:

aws wafv2 update-web-acl ...   --rules '[{"Name":"chan-sqli","Priority":1,
    "OverrideAction":{"Count":{}}, ...}]'

Managed rule có thể chặn nhầm request hợp lệ
    → chạy Count vài ngày, xem sampled request
    → xác nhận rồi mới bật Block

Ba tính năng khác của WAF nên dùng: | Tính năng | Việc | |---|---| | Rate-based rule | giới hạn request mỗi IP — chống dò mật khẩu | | Geo match | chặn theo quốc gia | | Size constraint | chặn body quá lớn |

Ba lưu ý về log của WAF: | Lưu ý | Chi tiết | |---|---| | Gửi vào S3, CloudWatch Logs hoặc Firehose | | | Che trường nhạy cảm | mật khẩu, token | | Sampled requests xem ngay trong console | không cần bật log |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Web ACL | ~5 USD/tháng | | Mỗi rule | ~1 USD/tháng | | Mỗi triệu request | ~0,60 USD | | Bot Control | phí thêm đáng kể |

Ba biện pháp bổ sung cho ứng dụng streaming: | Biện pháp | Chi tiết | |---|---| | CloudFront signed URL | chỉ người có quyền xem được video | | AWS Shield Advanced | nếu bị DDoS nhắm mục tiêu | | Origin access control | ALB chỉ nhận từ CloudFront |

Shield Standard tự động và miễn phí; Shield Advanced có phí ~3.000 USD/tháng nhưng kèm đội hỗ trợ và bảo vệ chi phí khi bị DDoS.

Và một lời khuyên: hãy bật managed rule group ở chế độ Count trước, rồi xem sampled requests trong console. Bộ quy tắc SQLi và Common đôi khi khớp với request hợp lệ có chứa ký tự đặc biệt — và biết trước điều đó tốt hơn nhiều so với việc phát hiện qua báo cáo người dùng không đăng nhập được.

Câu 706 Design Resilient Architectures

A company hosts a Microsoft SQL Server database on Amazon EC2 instances with attached Amazon EBS volumes. The operations team takes daily snapshots of these EBS volumes as backups. However, a recent incident occurred in which an automated script designed to clean up expired snapshots accidentally deleted all available snapshots, leading to potential data loss. The company wants to improve the backup strategy to avoid permanent data loss while still ensuring that old snapshots are eventually removed to optimize cost. A solutions architect needs to implement a mechanism that prevents immediate and irreversible deletion of snapshots.

Which solution will best meet these requirements with the least development effort?

  1. A

    Set up a 7-day EBS snapshot retention rule in Recycle Bin and apply the rule for all snapshots
  2. B

    Enable AWS Backup Vault Lock on the backup vault and store EBS snapshots in that vault to enforce deletion protection
  3. C

    Set up the IAM policy of the user to deny EBS snapshot deletion
  4. D

    Implement a Lambda-based backup automation workflow that archives snapshot metadata in DynamoDB and stores backups in Amazon S3 Glacier Deep Archive for long-term recovery
Xem giải thích

Đáp án

A — Đặt quy tắc giữ lại snapshot EBS 7 ngày trong Recycle Bin và áp cho mọi snapshot.

Vì sao đúng

Đề nêu ba yêu cầu, và Recycle Bin đáp ứng chính xác cả ba: | Yêu cầu | Cơ chế | |---|---| | Ngăn xoá VĨNH VIỄN ngay lập tức | snapshot vào thùng rác, khôi phục được | | Snapshot cũ VẪN được dọn để tiết kiệm | hết thời gian giữ thì xoá thật | | Ít công phát triển nhất | một quy tắc, không viết mã |

Cơ chế Recycle Bin:

Ai đó xoá snapshot (kể cả script tự động)
    → snapshot KHÔNG mất ngay
    → chuyển vào Recycle Bin, giữ N ngày
        ↓
    Trong N ngày đó: khôi phục được
    Sau N ngày:      xoá thật, ngừng tính phí

Tạo quy tắc:

aws rbin create-rule   --resource-type EBS_SNAPSHOT   --retention-period RetentionPeriodValue=7,RetentionPeriodUnit=DAYS   --description "Giu snapshot 7 ngay sau khi xoa"

Khôi phục:

aws rbin list-rules --resource-type EBS_SNAPSHOT
aws ec2 list-snapshots-in-recycle-bin
aws ec2 restore-snapshot-from-recycle-bin --snapshot-id snap-0abc123

Và vì sao đây là cân bằng đúng:

Script dọn snapshot vẫn chạy như bình thường
    → không phải sửa script
    → không phải đổi quy trình
        ↓
    Chỉ thêm một lớp lưới an toàn 7 ngày
    → đủ để phát hiện sự cố và khôi phục

Điểm quan trọng: --resource-type EBS_SNAPSHOT và loại quy tắc.

Có hai loại rule:
    Tag-level:   chỉ áp cho snapshot có tag khớp
    Region-level: áp cho MỌI snapshot trong Region
        ↓
    Đề nói "apply the rule for ALL snapshots"
    → dùng region-level rule

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

  • **B. Bật AWS Backup Vault Lock và lưu snapshot trong vault đó — đây là phương án gần nhất và thật sự chống xoá rất mạnh, nhưng nó mâu thuẫn với yêu cầu thứ hai: Vault Lock ở chế độ tuân thủ khiến backup KHÔNG XOÁ ĐƯỢC cho tới hết thời hạn, trong khi đề nói rõ snapshot cũ vẫn phải được dọn để tối ưu chi phí. Và nó đòi chuyển sang AWS Backup — thay đổi quy trình đáng kể.
  • **C. Đặt IAM policy từ chối xoá snapshot — chặn cả việc dọn dẹp hợp lệ: không xoá được snapshot nào nữa, chi phí tăng vô hạn. Và không cứu được snapshot đã bị xoá.
  • **D. Dựng workflow Lambda lưu metadata vào DynamoDB, backup vào Deep Archive — công phát triển cao nhất: phải viết, kiểm thử và bảo trì toàn bộ đường ống, trong khi AWS đã có tính năng dựng sẵn.

Ghi nhớ

Recycle Bin của AWS — bảng cần biết: | Đặc điểm | Chi tiết | |---|---| | Tài nguyên hỗ trợ | EBS snapshot, AMI (EBS-backed) | | Thời gian giữ | 1 ngày – 1 năm | | Hai loại rule | tag-level và region-level | | Chi phí | vẫn tính phí lưu trữ snapshot trong thời gian giữ |

Dòng cuối là đánh đổi cần biết:

Snapshot trong Recycle Bin VẪN tính phí
    → giữ 7 ngày = trả thêm 7 ngày lưu trữ
        ↓
    Cân bằng giữa an toàn và chi phí
    → 7 ngày thường là lựa chọn hợp lý

Ba lớp bảo vệ snapshot — bảng so sánh: | Lớp | Chống lại | Vẫn dọn được | |---|---|---| | Recycle Bin | xoá NHẦM | ✅ sau thời gian giữ | | IAM/SCP deny | xoá trái phép | ❌ chặn cả xoá hợp lệ | | AWS Backup Vault Lock | xoá cố ý, kể cả root | ❌ trong thời hạn khoá |

Chọn theo mục tiêu:

"chống xoá nhầm, vẫn muốn dọn định kỳ" → Recycle Bin "tuân thủ, KHÔNG AI được xoá" → Vault Lock chế độ Compliance "giới hạn ai được xoá" → IAM/SCP

Ba tính năng tương tự ở dịch vụ khác: | Dịch vụ | Tính năng | |---|---| | S3 | versioning + MFA Delete + Object Lock | | RDS | --deletion-protection | | DynamoDB | deletion protection | | EC2 | disableApiTermination |

Ba đặc điểm của EBS snapshot: | Đặc điểm | Chi tiết | |---|---| | Tăng dần (incremental) | chỉ lưu khối thay đổi | | Xoá snapshot cũ không hỏng snapshot mới | AWS giữ khối còn tham chiếu | | Lưu trong S3 do AWS quản lý | |

Dòng giữa giải thích vì sao dọn snapshot cũ an toàn:

Xoá snapshot #1 khi #2 và #3 còn
    → AWS chỉ xoá khối KHÔNG còn snapshot nào tham chiếu
        ↓
    #2 và #3 vẫn khôi phục được đầy đủ

Ba cách tự động hoá vòng đời snapshot: | Cách | Chi tiết | |---|---| | Data Lifecycle Manager (DLM) | chính sách theo tag, MIỄN PHÍ | | AWS Backup | quản lý tập trung nhiều dịch vụ | | Script tự viết | ← nguyên nhân sự cố trong đề |

DLM đáng thay cho script tự viết:

{"ResourceTypes": ["VOLUME"],
 "TargetTags": [{"Key": "sao-luu", "Value": "hang-ngay"}],
 "Schedules": [{
   "Name": "hang-ngay",
   "CreateRule": {"Interval": 24, "IntervalUnit": "HOURS", "Times": ["03:00"]},
   "RetentionRule": {"Count": 14}}]}

DLM tự tạo VÀ tự xoá theo số lượng hoặc tuổi
    → không có script tự viết nào để hỏng
        ↓
    Kết hợp với Recycle Bin là hai lớp bảo vệ

Ba lưu ý về tính nhất quán của snapshot SQL Server: | Lưu ý | Chi tiết | |---|---| | Snapshot khi đang ghi có thể KHÔNG nhất quán | | | Dùng AWS Backup với VSS | nhất quán ở tầng ứng dụng trên Windows | | Hoặc dừng ghi tạm thời khi chụp | |

VSS là chi tiết quan trọng với SQL Server:

aws ssm send-command --document-name "AWSEC2-CreateVssSnapshot"   --instance-ids i-0abc   --parameters "ExcludeBootVolume=False"

VSS yêu cầu SQL Server flush dữ liệu ra đĩa
    → snapshot ở trạng thái nhất quán
        ↓
    Snapshot thường có thể khôi phục ra database hỏng

Ba lưu ý về chi phí snapshot: | Khoản | Giá tham khảo | |---|---| | Snapshot tiêu chuẩn | ~0,05 USD/GB-tháng (phần thay đổi) | | Snapshot Archive | ~0,0125 USD/GB-tháng | | Recycle Bin | tính như snapshot thường |

Snapshot Archive cho bản giữ lâu:

aws ec2 modify-snapshot-tier --snapshot-id snap-0abc   --storage-tier archive

Rẻ hơn ~75%, nhưng khôi phục mất 24–72 giờ
    → và tối thiểu 90 ngày lưu trữ
        ↓
    Phù hợp cho bản lưu trữ hằng tháng, hằng năm

Ba việc nên làm sau sự cố như trong đề: | Việc | Chi tiết | |---|---| | Bật Recycle Bin | ← ngay lập tức | | Rà soát và thử script dọn dẹp | hoặc thay bằng DLM | | Đặt alarm khi số snapshot giảm bất thường | |

Ba lưu ý về Recycle Bin: | Lưu ý | Chi tiết | |---|---| | Rule tạo THEO REGION | phải tạo ở mọi Region | | Áp cho snapshot xoá SAU khi tạo rule | không cứu được cái đã mất | | Khoá được rule để không ai tắt | lock-rule |

aws rbin lock-rule --identifier <id-rule>   --lock-configuration UnlockDelay={UnlockDelayValue=7,UnlockDelayUnit=DAYS}

Khoá rule để chính script hay kẻ tấn công không tắt được nó trước khi xoá.

Và một lời khuyên: hãy khoá rule của Recycle Bin sau khi tạo. Một lớp bảo vệ mà kẻ tấn công (hoặc một script khác) có thể tắt trước khi xoá thì không phải là bảo vệ — và độ trễ mở khoá bảy ngày cho bạn đủ thời gian phát hiện nếu có ai đó thử làm điều đó.

Câu 707 Design Cost-Optimized Architectures

A medical devices company uses Amazon S3 buckets to store critical data. Hundreds of buckets are used to keep the data segregated and well organized. Recently, the development team noticed that the lifecycle policies on the Amazon S3 buckets have not been applied optimally, resulting in higher costs.

As a Solutions Architect, can you recommend a solution to reduce storage costs on Amazon S3 while keeping the IT team's involvement to a minimum?

  1. A

    Configure Amazon EFS to provide a fast, cost-effective and sharable storage service
  2. B

    Use Amazon S3 Intelligent-Tiering storage class to optimize the Amazon S3 storage costs
  3. C

    Use Amazon S3 One Zone-Infrequent Access, to reduce the costs on Amazon S3 storage
  4. D

    Use Amazon S3 Outposts storage class to reduce the costs on Amazon S3 storage by storing the data on-premises
Xem giải thích

Đáp án

B — Dùng lớp lưu trữ S3 Intelligent-Tiering để tối ưu chi phí.

Vì sao đúng

Đề nêu ba dữ kiện, và Intelligent-Tiering là câu trả lời cho cả ba: | Dữ kiện | Kết luận | |---|---| | HÀNG TRĂM bucket | đặt lifecycle cho từng cái là việc khổng lồ | | Lifecycle hiện tại đặt KHÔNG tối ưu | con người đoán sai mẫu truy cập | | Giảm tối đa sự tham gia của đội IT | Intelligent-Tiering TỰ ĐỘNG hoàn toàn |

Vấn đề gốc là gì:

Lifecycle policy đòi bạn BIẾT TRƯỚC:
    → sau bao nhiêu ngày thì dữ liệu ngừng được đọc
        ↓
    Với hàng trăm bucket, mỗi cái một mẫu khác nhau
    → đoán sai là chuyện tất yếu
        ↓
    Đoán quá sớm: phí truy xuất tăng
    Đoán quá muộn: trả tiền lưu trữ đắt lâu hơn cần thiết

Intelligent-Tiering bỏ hẳn việc đoán:

S3 theo dõi truy cập THẬT của từng object
    → tự chuyển tầng theo hành vi thực tế
    → object được đọc lại thì TỰ QUAY VỀ tầng nóng
        ↓
    Không có tham số nào để đặt sai

Bốn tầng: | Tầng | Chuyển sau | Giá tham khảo | |---|---|---| | Frequent Access | — | ~0,023 USD/GB | | Infrequent Access | 30 ngày không đọc | ~0,0125 USD/GB | | Archive Instant Access | 90 ngày không đọc | ~0,004 USD/GB | | Archive / Deep Archive (tuỳ chọn) | 90 / 180 ngày | rẻ hơn nữa |

Ba tầng đầu đều truy xuất TỨC THÌ — không ảnh hưởng ứng dụng.

Và điểm quan trọng nhất: KHÔNG có phí truy xuất.

Standard-IA: rẻ hơn nhưng có phí truy xuất ~0,01 USD/GB
    → đọc nhiều thì ĐẮT HƠN Standard

Intelligent-Tiering: KHÔNG có phí truy xuất
    → đoán sai cũng không bị phạt
        ↓
    Đây là lý do nó an toàn cho dữ liệu không rõ mẫu truy cập

Áp cho toàn bộ bucket:

aws s3api put-bucket-intelligent-tiering-configuration   --bucket kho-du-lieu --id tu-phan-tang   --intelligent-tiering-configuration '{
    "Id":"tu-phan-tang","Status":"Enabled","Filter":{},
    "Tierings":[{"Days":90,"AccessTier":"ARCHIVE_ACCESS"},
                {"Days":180,"AccessTier":"DEEP_ARCHIVE_ACCESS"}]}'

Hoặc đặt làm lớp mặc định khi ghi:

aws s3 cp tep.dat s3://kho-du-lieu/ --storage-class INTELLIGENT_TIERING

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

  • **C. Dùng S3 One Zone-IA để giảm chi phí — đây là phương án gần nhất và thật sự rẻ hơn Standard-IA khoảng 20%, nhưng nó giảm ĐỘ BỀN xuống một AZ: với công ty thiết bị y tế lưu "dữ liệu quan trọng", mất dữ liệu khi một AZ hỏng là rủi ro không chấp nhận được. Và nó vẫn đòi đoán mẫu truy cập.
  • **A. Cấu hình Amazon EFS làm dịch vụ lưu trữ chia sẻ — đắt hơn nhiều và sai bài toán: EFS đắt hơn S3 khoảng 13 lần, và đề không nói tới nhu cầu hệ thống tệp.
  • **D. Dùng S3 Outposts để lưu dữ liệu tại chỗ — hoàn toàn ngược mục tiêu: Outposts đòi mua và vận hành phần cứng AWS đặt tại trung tâm dữ liệu của bạn, đắt hơn rất nhiều và tăng công vận hành.

Ghi nhớ

Quy tắc chọn giữa Lifecycle và Intelligent-Tiering: | Tình huống | Chọn | |---|---| | Mẫu truy cập ĐOÁN ĐƯỢC | Lifecycle (rẻ hơn, không phí giám sát) | | Mẫu truy cập KHÔNG đoán được | Intelligent-Tiering | | Nhiều bucket, ít nhân lực quản lý | Intelligent-Tiering ← câu này |

Ba đặc điểm của Intelligent-Tiering: | Đặc điểm | Chi tiết | |---|---| | Phí giám sát ~0,0025 USD/1.000 object/tháng | | | KHÔNG có phí truy xuất | ưu điểm lớn nhất | | Object tự quay về tầng nóng khi được đọc | |

Tính điểm hoà vốn:

Phí giám sát: 0,0025 USD mỗi 1.000 object/tháng
Tiết kiệm khi xuống IA: ~0,0105 USD/GB/tháng
        ↓
    Object trung bình phải lớn hơn ~250 KB
        ↓
    Kho ảnh y tế, tệp DICOM → rất phù hợp
    Kho hàng triệu tệp JSON nhỏ → KHÔNG phù hợp

Ba trường hợp KHÔNG nên dùng Intelligent-Tiering: | Trường hợp | Lý do | |---|---| | Rất nhiều object nhỏ | phí giám sát vượt tiết kiệm | | Dữ liệu chắc chắn không bao giờ đọc lại | Deep Archive rẻ hơn nhiều | | Dữ liệu sống ngắn (dưới 30 ngày) | không kịp xuống tầng |

Các lớp lưu trữ S3 — bảng nhắc lại: | Lớp | Số AZ | Phí truy xuất | Giá tham khảo | |---|---|---|---| | Standard | ≥3 | ❌ | ~0,023 USD/GB | | Intelligent-Tiering | ≥3 | ❌ | ~0,023 + giám sát | | Standard-IA | ≥3 | ✅ | ~0,0125 USD/GB | | One Zone-IA | 1 ⚠ | ✅ | ~0,01 USD/GB | | Glacier Instant | ≥3 | ✅ cao | ~0,004 USD/GB | | Deep Archive | ≥3 | ✅ cao | ~0,00099 USD/GB |

Ba công cụ phân tích để quyết định: | Công cụ | Việc | |---|---| | S3 Storage Lens | tổng quan MỌI bucket, có khuyến nghị | | S3 Storage Class Analysis | phân tích mẫu truy cập theo tuổi | | Cost Explorer | chi phí theo lớp |

Storage Lens rất phù hợp với hàng trăm bucket:

Dashboard mặc định MIỄN PHÍ:
    ✓ dung lượng theo bucket
    ✓ phân bố lớp lưu trữ
    ✓ object chưa hoàn tất multipart
    ✓ khuyến nghị tiết kiệm
        ↓
    Bức tranh toàn cảnh trong một màn hình

Ba việc dọn dẹp nên làm ở mọi bucket: | Việc | Lợi ích | |---|---| | AbortIncompleteMultipartUpload | dọn phần dở dang — chi phí ẩn | | Xoá phiên bản cũ nếu bật versioning | thường chiếm rất nhiều | | Xoá delete marker mồ côi | |

{"Rules": [{"ID":"don-dep","Status":"Enabled","Filter":{},
  "AbortIncompleteMultipartUpload":{"DaysAfterInitiation":7},
  "NoncurrentVersionExpiration":{"NoncurrentDays":90}}]}

Ba cách áp cấu hình cho hàng trăm bucket: | Cách | Chi tiết | |---|---| | Script với AWS CLI lặp qua danh sách | đơn giản | | CloudFormation StackSets | có kiểm soát phiên bản | | AWS Config remediation | tự sửa bucket chưa tuân thủ |

aws s3api list-buckets --query 'Buckets[].Name' --output text |   tr '\t' '\n' | while read b; do
    aws s3api put-bucket-intelligent-tiering-configuration       --bucket "$b" --id auto --intelligent-tiering-configuration file://cau-hinh.json
  done

Ba lưu ý cho dữ liệu thiết bị y tế: | Lưu ý | Chi tiết | |---|---| | Kiểm tra yêu cầu lưu giữ theo quy định | có thể cấm xoá sớm | | Mã hoá bằng SSE-KMS | và bật S3 Bucket Keys | | Cân nhắc Object Lock nếu cần bất biến | |

Ba metric cần theo dõi sau khi bật: | Metric | Ý nghĩa | |---|---| | Phân bố dung lượng theo tầng | qua Storage Lens | | Chi phí lưu trữ hằng tháng | xác nhận có giảm | | Số object bị tính phí giám sát | |

Và một lời khuyên: hãy bật S3 Storage Lens trước khi làm bất cứ thay đổi nào. Với hàng trăm bucket, rất có thể phần lớn chi phí tập trung ở vài bucket — và biết được điều đó cho phép tập trung công sức đúng chỗ thay vì áp một chính sách chung cho tất cả rồi hy vọng.

Câu 708 Design High-Performing Architectures

A financial data processing company runs a workload on Amazon EC2 instances that fetch and process real-time transaction batches from an Amazon SQS queue. The application needs to scale based on unpredictable message volume, which fluctuates significantly throughout the day. The system must process messages with minimal delay and no downtime, even during peak spikes. The company is seeking a solution that balances cost-efficiency with availability and elasticity.

Which EC2 purchasing strategy best meets these requirements in the most cost-effective manner?

  1. A

    Purchase EC2 Reserved Instances to match peak capacity and assign all message processing tasks to these instances regardless of load variations
  2. B

    Use EC2 Reserved Instances for the baseline workload and configure EC2 Auto Scaling to launch On-Demand Instances for all traffic spikes
  3. C

    Use EC2 Spot Instances exclusively with Auto Scaling enabled to match message volume fluctuations and save on compute costs
  4. D

    Use Reserved Instances for the baseline level of traffic and configure EC2 Auto Scaling with Spot Instances to handle spikes in message volume
Xem giải thích

Đáp án

D — Dùng Reserved Instance cho mức tải NỀN và cấu hình EC2 Auto Scaling với Spot Instance để xử lý phần đỉnh.

Vì sao đúng

Đề nêu bốn yêu cầu, và mô hình lai đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Có tải nền ổn định | Reserved Instance — tiết kiệm tới 72% | | Đỉnh tải khó đoán, dao động mạnh | Spot qua Auto Scaling | | KHÔNG được ngừng dịch vụ | RI đảm bảo phần nền luôn có | | Tiết kiệm chi phí nhất | kết hợp hai mô hình rẻ nhất |

Vì sao phải kết hợp:

Chỉ Reserved Instance:
    → phải cam kết cho mức ĐỈNH
    → trả tiền cho năng lực không dùng phần lớn thời gian

Chỉ Spot:
    → rẻ nhất
    → nhưng đợt thiếu năng lực có thể thu hồi TOÀN BỘ
    → vi phạm "no downtime"

Kết hợp:
    → RI cho nền: đảm bảo luôn có máy phục vụ
    → Spot cho đỉnh: rẻ, và mất cũng không sập

Và SQS làm cho Spot an toàn:

Đề nói ứng dụng đọc từ SQS
    → Spot bị thu hồi giữa lúc xử lý
    → thông điệp quay lại hàng đợi sau visibility timeout
    → instance khác nhận và làm lại
        ↓
    KHÔNG mất giao dịch nào

Cấu hình mixed instances policy:

aws autoscaling create-auto-scaling-group   --auto-scaling-group-name asg-xu-ly-giao-dich   --min-size 4 --desired-capacity 4 --max-size 40   --vpc-zone-identifier "subnet-a,subnet-c"   --mixed-instances-policy '{
    "LaunchTemplate":{
      "LaunchTemplateSpecification":{"LaunchTemplateName":"lt-xu-ly"},
      "Overrides":[{"InstanceType":"m6i.large"},{"InstanceType":"m5.large"},
                   {"InstanceType":"m5a.large"},{"InstanceType":"m6a.large"}]},
    "InstancesDistribution":{
      "OnDemandBaseCapacity":4,
      "OnDemandPercentageAboveBaseCapacity":0,
      "SpotAllocationStrategy":"price-capacity-optimized"}}'

OnDemandBaseCapacity: 4 chính là phần nền được Reserved Instance phủ.

Và co giãn theo độ dài hàng đợi:

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

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

  • **B. Reserved Instance cho nền + On-Demand cho mọi đỉnh — đây là phương án gần nhất và hoàn toàn an toàn về mặt sẵn sàng, nhưng nó đắt hơn đáng kể: On-Demand không có ưu đãi nào, trong khi tải xử lý từ SQS chịu được gián đoạn nên hoàn toàn dùng Spot được. Đề hỏi "MOST cost-effective".
  • **C. Dùng HOÀN TOÀN Spot với Auto Scaling — rủi ro ngừng dịch vụ: một đợt thiếu năng lực Spot có thể thu hồi toàn bộ đội máy trong vài phút, vi phạm yêu cầu "no downtime".
  • **A. Mua Reserved Instance đủ cho mức ĐỈNH và giao mọi việc cho chúng — lãng phí lớn nhất: cam kết 1–3 năm cho năng lực chỉ dùng vài giờ mỗi ngày, và không co giãn khi đỉnh vượt dự kiến.

Ghi nhớ

Các mô hình mua EC2 — bảng phải thuộc: | Mô hình | Tiết kiệm | Cam kết | Rủi ro | |---|---|---|---| | On-Demand | 0% | không | không | | Savings Plans | tới 72% | 1–3 năm theo USD/giờ | không | | Reserved Instances | tới 72% | 1–3 năm theo loại | không | | Spot | tới 90% | không | bị thu hồi |

Mẫu kết hợp được khuyến nghị:

Phần NỀN (luôn chạy):     Savings Plans hoặc RI
Phần ĐỈNH (dao động):     Spot (nếu chịu gián đoạn) hoặc On-Demand
        ↓
    Đây là mẫu tối ưu chi phí kinh điển

Savings Plans và Reserved Instances — bảng phân biệt: | | Savings Plans | Reserved Instances | |---|---|---| | Cam kết theo | USD/giờ | loại instance cụ thể | | Linh hoạt | cao — đổi loại, cỡ, Region | thấp hơn | | Áp cho Lambda và Fargate | ✅ (Compute SP) | ❌ | | Bán lại trên marketplace | ❌ | ✅ (Standard RI) |

AWS khuyến nghị Savings Plans cho hầu hết trường hợp — linh hoạt hơn với cùng mức tiết kiệm.

Hai loại Savings Plans: | Loại | Tiết kiệm | Linh hoạt | |---|---|---| | Compute Savings Plans | tới 66% | EC2, Fargate, Lambda; mọi Region, mọi họ | | EC2 Instance Savings Plans | tới 72% | một họ instance, một Region |

Ba điều kiện dùng Spot: | Điều kiện | Đề có? | |---|---| | Ứng dụng stateless | ✅ đọc từ SQS | | Chịu được gián đoạn | ✅ thông điệp quay lại hàng đợi | | Nhiều loại instance thay thế | cần cấu hình |

Ba chiến lược phân bổ Spot: | Chiến lược | Đặc điểm | |---|---| | price-capacity-optimized | cân bằng — KHUYẾN NGHỊ | | capacity-optimized | ít bị thu hồi nhất | | lowest-price | rẻ nhất, hay bị thu hồi |

Ba yếu tố tăng khả năng có Spot: | Yếu tố | Chi tiết | |---|---| | Nhiều loại instance | quan trọng nhất — ít nhất 4 loại | | Nhiều AZ | | | Linh hoạt về thế hệ và cỡ | |

Ba cơ chế xử lý thu hồi Spot: | Cơ chế | Chi tiết | |---|---| | Thông báo trước 2 phút | metadata /spot/instance-action | | Rebalance recommendation | cảnh báo sớm hơn | | Capacity Rebalancing của ASG | tự thay máy trước khi bị thu hồi |

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-xu-ly-giao-dich --capacity-rebalance

Ba thông số SQS quan trọng với Spot: | Thông số | Chi tiết | |---|---| | Visibility timeout ≥ thời gian xử lý | tránh xử lý trùng | | Message retention đủ dài | chịu được lúc thiếu máy | | DLQ với maxReceiveCount | thông điệp hỏng không chặn hàng đợi |

Ba metric để co giãn: | Metric | Dùng cho | |---|---| | ApproximateNumberOfMessagesVisible | độ sâu hàng đợi | | ApproximateAgeOfOldestMessage | chỉ báo trải nghiệm tốt nhất | | Backlog per instance | công thức khuyến nghị của AWS |

Công thức backlog per instance:

Mục tiêu = (thời gian chờ chấp nhận được) ÷ (thời gian xử lý mỗi việc)

Chấp nhận chờ 5 phút, mỗi việc 15 giây
    → 300 ÷ 15 = 20 việc mỗi instance

Ba cách giảm chi phí thêm: | Cách | Tiết kiệm | |---|---| | Graviton (ARM) | ~20% cho cùng hiệu năng | | Kích thước instance đúng nhu cầu | Compute Optimizer | | AWS Batch thay ASG tự dựng | ít việc quản lý hơn |

Ba lưu ý về Reserved Instance: | Lưu ý | Chi tiết | |---|---| | Mua SAU KHI đã tối ưu kích thước | không khoá lãng phí | | Bắt đầu với cam kết 1 năm | linh hoạt hơn 3 năm | | Theo dõi mức phủ trong Cost Explorer | |

Và một lời khuyên: hãy tối ưu kích thước instance trước khi mua bất kỳ cam kết nào. Mua Reserved Instance cho một loại máy đang cấp thừa nghĩa là khoá khoản lãng phí đó suốt một tới ba năm — và đó là sai lầm tốn kém nhất trong toàn bộ chủ đề tối ưu chi phí.

Câu 709 Design Secure Architectures

A retail enterprise is expanding its hybrid IT infrastructure and plans to securely connect its on-premises corporate network to its AWS environment. The company wants to ensure that all data exchanged between on-premises systems and AWS is encrypted at both the network and session layers. Additionally, the solution must incorporate granular security controls that restrict unnecessary or unauthorized access between the cloud and on-premises environments. A solutions architect must recommend a scalable and secure approach that supports these goals.

Which solution best meets these requirements?

  1. A

    Set up AWS Site-to-Site VPN to connect the on-premises network to the AWS VPC. Use route tables to manage traffic flow and configure security groups and network ACLs to allow only authorized communication between systems
  2. B

    Set up a bastion host in a public subnet of the VPC to provide SSH-based access to AWS resources from the corporate network. Use security groups to control access
  3. C

    Use AWS Client VPN to allow corporate users to connect to the VPC individually. Manage access controls with security groups and IAM policies
  4. D

    Establish a dedicated AWS Direct Connect connection between the corporate network and AWS. Configure VPC route tables to control traffic flow and use security groups and network ACLs to restrict access as needed
Xem giải thích

Đáp án

A — Dựng AWS Site-to-Site VPN nối mạng công ty với VPC; dùng route table điều khiển luồng, dùng security group và network ACL cho phép chỉ những kết nối được uỷ quyền.

Vì sao đúng

Đề nêu ba yêu cầu, và Site-to-Site VPN đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Mã hoá ở tầng MẠNG và tầng PHIÊN | IPsec mã hoá sẵn | | Kiểm soát chi tiết, chặn truy cập không cần thiết | security group + NACL + route table | | Mở rộng được và an toàn | |

Vế mã hoá là điểm phân biệt quyết định:

Site-to-Site VPN dùng IPsec:
    → mã hoá là ĐẶC TÍNH GỐC của giao thức
    → mọi gói tin giữa hai bên đều được mã hoá
        ↓
Direct Connect:
    → là đường RIÊNG, nhưng KHÔNG MÃ HOÁ
    → dữ liệu đi ở dạng bản rõ trên đường đó

Đây là hiểu lầm phổ biến: "riêng tư" không đồng nghĩa với "được mã hoá".

Triển khai:

aws ec2 create-customer-gateway --type ipsec.1   --public-ip 203.0.113.10 --bgp-asn 65000

aws ec2 create-vpn-gateway --type ipsec.1
aws ec2 attach-vpn-gateway --vpn-gateway-id vgw-abc --vpc-id vpc-abc

aws ec2 create-vpn-connection --type ipsec.1   --customer-gateway-id cgw-abc --vpn-gateway-id vgw-abc   --options '{"TunnelOptions":[
    {"Phase1EncryptionAlgorithms":[{"Value":"AES256"}],
     "Phase2EncryptionAlgorithms":[{"Value":"AES256"}]},
    {"Phase1EncryptionAlgorithms":[{"Value":"AES256"}],
     "Phase2EncryptionAlgorithms":[{"Value":"AES256"}]}]}'

Và ba lớp kiểm soát chi tiết: | Lớp | Việc | |---|---| | Route table | quyết định dải nào đi qua VPN | | Security group | stateful, theo ENI | | Network ACL | stateless, theo subnet |

Route table cho phép kiểm soát ở mức thô nhất:

# Chỉ định tuyến dải cần thiết qua VPN, không phải toàn bộ
aws ec2 create-route --route-table-id rtb-abc   --destination-cidr-block 192.168.10.0/24 --gateway-id vgw-abc

Chỉ khai dải cụ thể của on-premises
    → không mở toàn bộ mạng công ty vào VPC

Và bật route propagation:

aws ec2 enable-vgw-route-propagation   --route-table-id rtb-abc --gateway-id vgw-abc

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

  • **D. Dùng AWS Direct Connect, kiểm soát bằng route table, security group và NACL — đây là phương án gần nhất và đúng hoàn toàn ở phần kiểm soát truy cập, nhưng nó KHÔNG mã hoá theo mặc định: Direct Connect là đường riêng chứ không phải đường mã hoá. Đề nói rõ dữ liệu phải được mã hoá ở tầng mạng và phiên.
  • **C. Dùng AWS Client VPN cho người dùng kết nối cá nhân — sai mô hình: Client VPN dành cho từng người dùng kết nối vào VPC (làm việc từ xa), không phải để nối cả mạng công ty với AWS.
  • **B. Dựng bastion host ở public subnet cho truy cập SSH — chỉ giải quyết truy cập quản trị, không phải kết nối mạng giữa hai môi trường. Và nó phơi một máy ra Internet.

Ghi nhớ

Ba cách kết nối on-premises với AWS — bảng phải thuộc: | Cách | Mã hoá mặc định | Băng thông | Thời gian dựng | |---|---|---|---| | Site-to-Site VPN | ✅ IPsec | ~1,25 Gbps mỗi tunnel | vài giờ | | Direct Connect | ❌ | 1–400 Gbps, ổn định | vài tuần–tháng | | DX + VPN qua nó | ✅ | như DX | như DX |

Từ khoá nhận diện:

"encrypted", "fastest to set up" → Site-to-Site VPN "consistent bandwidth", "low latency", "large transfers" → Direct Connect "private AND encrypted", "compliance" → Direct Connect + VPN

Mẫu kết hợp cho doanh nghiệp:

Direct Connect: băng thông và độ trễ ổn định
    + IPsec VPN chạy TRÊN Direct Connect: mã hoá
        ↓
    Đáp ứng cả yêu cầu hiệu năng lẫn tuân thủ

Ba thành phần của Site-to-Site VPN: | Thành phần | Việc | |---|---| | Customer Gateway | đại diện thiết bị tại chỗ | | Virtual Private Gateway | phía AWS, gắn một VPC | | Transit Gateway | thay VGW khi nối NHIỀU VPC |

Với nhiều VPC, Transit Gateway là lựa chọn mở rộng được:

VGW: một VPN cho MỘT VPC
    → 10 VPC = 10 kết nối VPN

Transit Gateway: một VPN cho MỌI VPC gắn vào
    → mở rộng tuyến tính

Ba đặc điểm của Site-to-Site VPN: | Đặc điểm | Chi tiết | |---|---| | HAI tunnel mỗi kết nối | dư thừa — phải cấu hình CẢ HAI | | Đi qua Internet công cộng | độ trễ biến động | | Hỗ trợ BGP động hoặc static route | |

Cấu hình chỉ một tunnel là mất dư thừa — lỗi hay gặp khi triển khai.

Ba tầng kiểm soát trong VPC — bảng nhắc lại: | Tầng | Phạm vi | Trạng thái | |---|---|---| | Route table | subnet | quyết định đường đi | | Network ACL | subnet | STATELESS, có Deny | | Security group | ENI | STATEFUL, chỉ Allow |

Ba nguyên tắc kiểm soát chi tiết: | Nguyên tắc | Chi tiết | |---|---| | Chỉ định tuyến dải THẬT SỰ cần | không mở toàn bộ | | Security group theo vai trò | web, app, db | | NACL chặn dải IP xấu ở cấp subnet | |

Ba tham số IPsec nên khai rõ: | Tham số | Giá trị khuyến nghị | |---|---| | Thuật toán mã hoá | AES256 | | Thuật toán băm | SHA2-256 trở lên | | Nhóm Diffie-Hellman | 14 trở lên |

aws ec2 modify-vpn-tunnel-options   --vpn-connection-id vpn-abc   --vpn-tunnel-outside-ip-address 52.x.x.x   --tunnel-options '{"Phase1EncryptionAlgorithms":[{"Value":"AES256"}],
                     "Phase2EncryptionAlgorithms":[{"Value":"AES256"}],
                     "Phase1IntegrityAlgorithms":[{"Value":"SHA2-256"}],
                     "Phase2IntegrityAlgorithms":[{"Value":"SHA2-256"}]}'

Ba cách tăng băng thông VPN: | Cách | Chi tiết | |---|---| | Nhiều kết nối VPN với ECMP | qua Transit Gateway | | Accelerated Site-to-Site VPN | qua mạng Global Accelerator | | Chuyển sang Direct Connect | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | TunnelState | 0 = DOWN, 1 = UP | | TunnelDataIn/Out | lưu lượng | | — | đặt alarm khi MỘT tunnel xuống |

aws cloudwatch put-metric-alarm --alarm-name tunnel-vpn-xuong   --metric-name TunnelState --namespace AWS/VPN   --dimensions Name=VpnId,Value=vpn-abc   --statistic Minimum --period 300 --threshold 1   --comparison-operator LessThanThreshold --evaluation-periods 1

Ba lưu ý khi cấu hình thiết bị tại chỗ: | Lưu ý | Chi tiết | |---|---| | AWS cung cấp file cấu hình mẫu theo hãng | | | Cấu hình cả hai tunnel | | | Kiểm tra MTU và MSS clamping | tránh phân mảnh |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | VPN connection | ~0,05 USD/giờ (~36 USD/tháng) | | Truyền dữ liệu ra | theo GB | | Direct Connect | cao hơn nhiều |

Và một lời khuyên: hãy đặt alarm cho TunnelState của cả hai tunnel riêng biệt. Kết nối vẫn hoạt động bình thường khi một tunnel xuống, nên sự cố đó hoàn toàn im lặng — và bạn chỉ phát hiện khi tunnel thứ hai cũng xuống, tức là lúc mất kết nối hoàn toàn.

Câu 710 Design High-Performing Architectures

A DevOps team is tasked with enabling secure and temporary SSH access to Amazon EC2 instances for developers during deployments. The team wants to avoid distributing long-term SSH key pairs and instead prefers ephemeral access that can be audited and revoked immediately after the session ends. The team wants direct access via the AWS Management Console.

What do you recommend?

  1. A

    Use an EC2 Instance Connect Endpoint to reach the instances even though they already have public IP addresses, because Instance Connect requires an endpoint for all SSH sessions
  2. B

    Use EC2 Instance Connect to inject a static SSH key and connect via the instance's private IP address directly from the internet
  3. C

    Use EC2 Instance Connect with Systems Manager Agent disabled, and connect via private IP using an internal proxy endpoint
  4. D

    Use EC2 Instance Connect to inject a temporary public key and establish SSH access using the instance’s public IP address
Xem giải thích

Đáp án

D — Dùng EC2 Instance Connect để tiêm khoá công khai TẠM THỜI và thiết lập SSH qua địa chỉ IP công cộng của instance.

Vì sao đúng

Đề nêu ba yêu cầu, và EC2 Instance Connect đáp ứng chính xác: | Yêu cầu | Cơ chế | |---|---| | KHÔNG phân phát khoá SSH dài hạn | khoá tạm chỉ sống 60 GIÂY | | Truy cập tạm thời, audit và thu hồi được | ghi vào CloudTrail, kiểm soát bằng IAM | | Truy cập trực tiếp từ AWS Console | có nút "Connect" ngay trong console |

Cơ chế của EC2 Instance Connect:

Người dùng bấm Connect trong console (hoặc chạy CLI)
    → AWS TIÊM khoá công khai TẠM THỜI vào instance
    → khoá đó có hiệu lực 60 GIÂY
    → phiên SSH được thiết lập
        ↓
    Sau 60 giây, khoá tự hết hiệu lực
    → không có khoá dài hạn nào tồn tại

Và kiểm soát bằng IAM:

{"Effect": "Allow",
 "Action": "ec2-instance-connect:SendSSHPublicKey",
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"StringEquals": {
   "ec2:osuser": "ec2-user",
   "aws:ResourceTag/moi-truong": "trien-khai"}}}

Thu hồi truy cập = gỡ IAM policy
    → hiệu lực NGAY LẬP TỨC
        ↓
    Khác hẳn khoá SSH tĩnh, phải gỡ từ authorized_keys của TỪNG máy

Dùng từ dòng lệnh:

aws ec2-instance-connect ssh --instance-id i-0abc123

Và audit trong CloudTrail:

aws cloudtrail lookup-events --lookup-attributes   AttributeKey=EventName,AttributeValue=SendSSHPublicKey

Mỗi lần cấp khoá đều có bản ghi: ai, khi nào, máy nào.

Điều kiện để hoạt động qua IP công cộng: | Điều kiện | Chi tiết | |---|---| | Instance có IP công cộng và ở public subnet | | | Security group cho phép cổng 22 từ prefix list EC2_INSTANCE_CONNECT | | | AMI hỗ trợ | Amazon Linux 2 trở lên, Ubuntu 20.04 trở lên |

aws ec2 authorize-security-group-ingress --group-id sg-abc   --ip-permissions 'IpProtocol=tcp,FromPort=22,ToPort=22,
    PrefixListIds=[{PrefixListId=pl-0e4bcff02b13bef1e}]'

Prefix list của EC2 Instance Connect — chỉ mở cổng 22 cho dịch vụ của AWS, không cho cả Internet.

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

  • **A. Dùng EC2 Instance Connect Endpoint dù instance đã có IP công cộng, "vì Instance Connect BẮT BUỘC có endpoint cho mọi phiên SSH" — đây là phương án gần nhất và Instance Connect Endpoint là tính năng có thật, nhưng mệnh đề giải thích SAI: endpoint chỉ cần thiết cho instance ở PRIVATE subnet không có IP công cộng. Với instance có IP công cộng, Instance Connect hoạt động trực tiếp.
  • **B. Dùng EC2 Instance Connect tiêm khoá SSH TĨNH và kết nối qua IP RIÊNG từ Internet — hai lỗi: Instance Connect tiêm khoá TẠM THỜI chứ không phải tĩnh, và không kết nối tới IP riêng từ Internet được.
  • **C. Dùng Instance Connect với SSM Agent bị tắt, kết nối qua IP riêng bằng "internal proxy endpoint" — mô tả một cấu hình không tồn tại: EC2 Instance Connect không phụ thuộc SSM Agent, và không có thứ gọi là "internal proxy endpoint" trong ngữ cảnh này.

Ghi nhớ

Ba cách truy cập EC2 không cần khoá dài hạn — bảng phải thuộc: | Cách | Cần cổng 22 mở | Instance ở private subnet | |---|---|---| | EC2 Instance Connect | ✅ (từ prefix list của AWS) | ❌ cần endpoint | | EC2 Instance Connect Endpoint | ❌ | ✅ | | Systems Manager Session Manager | ❌ hoàn toàn | ✅ |

Session Manager là lựa chọn an toàn nhất:

aws ssm start-session --target i-0abc123

✓ KHÔNG mở cổng nào
✓ KHÔNG cần IP công cộng
✓ KHÔNG cần key pair
✓ log toàn bộ phiên vào S3 hoặc CloudWatch
✓ kiểm soát bằng IAM
        ↓
    Đây là cách AWS khuyến nghị nhất

(Đề nói rõ muốn truy cập "trực tiếp qua AWS Management Console" bằng SSH, nên Instance Connect phù hợp; nhưng Session Manager cũng có giao diện console.)

Ba đặc điểm của EC2 Instance Connect: | Đặc điểm | Chi tiết | |---|---| | Khoá công khai sống 60 GIÂY | | | Ghi vào CloudTrail | SendSSHPublicKey | | Miễn phí | |

Ba yêu cầu để Instance Connect hoạt động: | Yêu cầu | Chi tiết | |---|---| | AMI được hỗ trợ hoặc tự cài gói | ec2-instance-connect | | Security group cho phép từ prefix list AWS | | | IAM policy cho phép SendSSHPublicKey | |

Ba điều kiện IAM hữu ích: | Điều kiện | Việc | |---|---| | ec2:osuser | giới hạn user hệ điều hành được dùng | | aws:ResourceTag/... | chỉ máy có tag nhất định | | aws:SourceIp | chỉ từ mạng công ty |

EC2 Instance Connect Endpoint đáng biết:

aws ec2 create-instance-connect-endpoint --subnet-id subnet-private
aws ec2-instance-connect ssh --instance-id i-0abc --connection-type eice

Cho phép SSH tới instance ở PRIVATE subnet
    → KHÔNG cần bastion host
    → KHÔNG cần IP công cộng
    → KHÔNG cần NAT

Ba cách so sánh phương án truy cập: | | Bastion host | Instance Connect | Session Manager | |---|---|---|---| | Máy phải duy trì | ✅ | ❌ | ❌ | | Cổng mở ra Internet | ✅ | ✅ (hạn chế) | ❌ | | Khoá dài hạn | ✅ | ❌ | ❌ | | Log phiên | tự dựng | không | ✅ dựng sẵn |

Ba tính năng của Session Manager: | Tính năng | Chi tiết | |---|---| | Ghi log toàn bộ phiên | vào S3 hoặc CloudWatch Logs | | Port forwarding | truy cập RDS qua đó | | Chạy lệnh không cần phiên tương tác | Run Command |

Ba yêu cầu của Session Manager: | Yêu cầu | Chi tiết | |---|---| | SSM Agent chạy | có sẵn trên AMI của AWS | | Instance profile có AmazonSSMManagedInstanceCore | | | Đường tới endpoint SSM | 3 VPC endpoint hoặc NAT |

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 lưu ý về bảo mật khi truy cập máy chủ: | Lưu ý | Chi tiết | |---|---| | Không dùng key pair dùng chung | không truy nguyên được ai | | Bật log phiên nếu có yêu cầu tuân thủ | | | Rà soát authorized_keys định kỳ | tìm khoá còn sót |

Ba lưu ý về audit: | Nguồn | Ghi gì | |---|---| | CloudTrail | ai xin khoá, khi nào, máy nào | | Session Manager log | toàn bộ lệnh gõ trong phiên | | Log hệ điều hành | /var/log/secure |

Và một lời khuyên: hãy cân nhắc Session Manager thay vì SSH ngay cả khi Instance Connect đủ dùng. Nó không mở cổng nào, không cần IP công cộng, và ghi lại toàn bộ nội dung phiên — ba thứ mà một đội DevOps sẽ cần đúng vào lúc phải trả lời câu hỏi "ai đã chạy lệnh gì trên máy sản xuất".