Câu hỏi thường gặp về đám mây AWS

– Đơn giản là em có 2 account, tại acc A e có một eventbridge rule put event sang cho một event bus ở acc B

Điều em muốn hỏi là tại sao lại put event cho event bus mà không phải trực tiếp đến Eventbridge rule ạ?

Bản chất của event bus là đường truyền phải không ạ?

Trả lời: 

Cross access event bus có nghĩa là:

1. Cross-Access Event Bus: cho phép cấu hình EventBridge để gửi và nhận sự kiện giữa các event bus thuộc các tài khoản AWS khác nhau. Điều này giúp tạo ra một mô hình tương tác giữa các hệ thống và ứng dụng trong các tài khoản AWS khác nhau.

2. Quản lý Quyền Truy Cập: Khi cấu hình EventBridge để gửi và nhận sự kiện giữa các tài khoản, chúng ta có thể quản lý quyền truy cập bằng cách thiết đặt các chính sách IAM và roles phù hợp. Việc này bao gồm quyền truy cập vào các event bus và các quy tắc (rules) liên quan.

3. Xác định Người Gửi và Người Nhận: Chúng ta có thể xác định rõ ràng tài khoản AWS nào có quyền gửi sự kiện đến event bus của chúngta và tài khoản nào có quyền nhận sự kiện từ event bus của của chúng ta.

4. Kiểm Soát Các Quy Tắc (rules) và Nguồn events: Chúng ta có thể kiểm soát quyền truy cập đến event bus và các sự kiện thông qua việc thiết lập allow hoặc deny cho các quy tắc cụ thể và các nguồn events cụ thể.

– Vậy event bus Chúng ta có thể hiểu nó  là nơi mà các sự kiện được tập trung và quản lý. Và nó có thể phân phối sự kiện đến nhiều đích khác nhau, tùy thuộc vào cách chúng ta cấu hình quy tắc và điều kiện xử lý sự kiện.

Trong trường hợp cross-account, event bus có thể được cấu hình để nhận sự kiện từ nhiều tài khoản khác nhau và chuyển giao chúng đến các quy tắc xử lý trong tài khoản đích.

Việc em put event cho event bus mà không phải trực tiếp đến EventBridge rules, là giúp giảm độ phức tạp và tăng tính linh hoạt trong quản lý events.

VD: Các quy tắc xử lý trong EventBridge rules thường được cấu hình với các điều kiện và bộ lọc(filters) để xác định xem events có nên kích hoạt rules hay không. Bằng cách chúng ta put event trực tiếp vào event bus, chúng ta có thể giảm bớt filters và điều kiện, giúp đơn giản hóa quá trình xử lý sự kiện (event).

Vậy em có thể tham khảo VD này để hiểu rõ hơn nhé: https://aws.amazon.com/vi/blogs/compute/simplifying-cross-account-access-with-amazon-eventbridge-resource-policies/

32. Hỏi: Cho em hỏi, em đang thiết lập static web trên s3 nhưng truy cập thông qua cloudfront sử dụng CFn. Vấn đề em gặp phải là e tạo cloudfront và webacl ở 2 file khác nhau, ở trong phần cloudfront WEBACLID em có sử dụng !Ref WebaclName để trỏ đc WEBACL Arn đến đó nhưng mà khi dùng như vậy lại báo lỗi “Invalid webACL identifier provided” không biết em dùng sai ở đâu a nhỉ, em có đỗi scope của webacl thành CLOUDFRONT để có thể truy cập global rồi. Hay là e phải dùng GetAtt Webacl.Arn a nhỉ?

Trả lời:

Anh cũng không rõ về 2 files mà em tạo ra, vì em không cung cấp nội dung của 2 files ở đây để anh có thể xem. Tuy nhiên a nghĩ là có thể em gặp phải vấn đề với cách em tham chiếu đến WebACL khi sử dụng !Ref. Để giải quyết vấn đề này, em thử  sử dụng hàm Fn::Sub hoặc Fn::GetAtt để trỏ đến ARN của WebACL xem sao nhé.

VD: # Tham chiếu đến WebACL ARN WebACLId: !Sub “arn:aws:wafv2:${AWS::Region}:${AWS::AccountId}:regional/webacl/${WebACLName}/WEBACL-ID

33. Hỏi: Ủa sao lưu trữ không giới hạn lại có giới hạn là 5TB nhỉ?

Trả lời:

Có nghĩa là tổng số lượng objects mà chúng ta có thể lưu trữ trên S3 là không giới hạn “The total volume of data and number of objects you can store in Amazon S3 are unlimited“. Và S3 có cho phép lưu trữ dung lượng S3 Objects lên đến 5 TB em nhé. https://aws.amazon.com/vi/s3/faqs/#:~:text=The%20total%20volume%20of%20data,single%20PUT%20is%205%20GB.

34. Hỏi: Không thấy “Import managed policy” ở bài 13. Em chào thầy, Ở phút 8:27, sau khi click vào “Create inline policy”, màn hình của em không có “Import managed policy” để làm theo như hướng dẫn của thầy. Vậy em có thể chọn “Attach policies” và chọn các Policy giống như trên màn hình mà thầy đã chọn được không ạ?

Trả lời:

Em Click vào Action, và chọn Import policy như hình dưới nhé.

35. Hỏi: Anh cho em hỏi xíu về thiết lập custom matrics để monitor những thứ cần thiết với ạ. Giả sử em có 1 api với method GET được deploy trên API Gateway, các logs về response của api đó được đẩy vào Cloudwatch. Hiện tại thì em đã tạo 1 alarm gắn với cái metrics default là 4xx, cái alarm đó sẽ gửi email về thông qua SNS, nên là các lỗi 4xx đều gửi tất về email. Bây giờ em muốn lọc những cái lỗi thoả mãn điều kiện là param của api phải có thuộc tính là “type_id=null” và httpStatus thuộc lỗi 4xx, nếu lỗi đủ 5 lần trong 1 phút thì mới send email. Còn lại các lỗi khác 4xx thì vẫn gửi như bthg. Anh giúp em case này với ạ ?

Trả lời:

Vấn đề này có thể được giải quyết bằng cách cấu hình CloudWatch Alarm để lọc và gửi thông báo chỉ khi điều kiện cụ thể được đáp ứng. Dưới đây là cách em có thể thực hiện việc này:

1. Tạo CloudWatch Metric Filter:

Bắt đầu bằng việc tạo một Metric Filter trong CloudWatch để lọc log dựa trên yêu cầu của em. Metric Filter này sẽ theo dõi dòng log để kiểm tra xem liệu nó có “type_id=null”  và “httpStatus” thuộc loại lỗi 4xx không(Nhớ đảm bảo là emđã bật việc xuất log tương ứng từ API Gateway trong Settings>Logs/Tracing Tab).

2. Tạo Metric từ Metric Filter:

Sau khi e cần tạo Metric Filter, việc này sẽ tạo ra  một Metric trong CloudWatch, dựa trên dữ liệu được lọc từ các log của e.

Ví dụ Filter pattern: [uuid, level, timestamp, statusCode=%4[0-9]{2}%, type_id=null]

3.Tạo CloudWatch Alarm:

Sau khi e đã tạo ra một Metric cho điều kiện lọc dữ liệu cụ thể của em, e có thể tạo CloudWatch Alarm như sau:

Chọn Metric em đã tạo từ Metric Filter.

Thiết lập ngưỡng 5 lần cho “Threshold”.

Thiết lập khoảng thời gian 1 phút (60 giây) cho “Period”.

Chọn hành động cảnh báo, em có thể chọn gửi thông báo qua SNS khi alarm được cảnh báo.

– Sau Khi em đã hoàn thành các bước trên thì có thể đáp ứng được với yêu cầu của em.

Good luck.

36. Hỏi: làm sao để biết tài khoản AWS có Free tier. Chào Thầy Phương, mình có 1 tài khoản AWS được tạo cách đây vài năm ( mình nhớ lúc đó là loại Free Tier), hiện nay mình muốn dùng lại tài khoản này để thực hành tiếp, nhưng không rõ là còn Free Tier ko, lúc đó mình chỉ tạo ra và để đó không sử dụng. Thầy hướng dẫn giúp cách xác định xem thông tin Free Tier ở đâu trên AWS. Cám ơn?

Trả lời:

– Bạn có thể đăng ký tạo tài khoản, và thao khảo thông tin AWS miễn phí theo Link này nhé: https://aws.amazon.com/vi/free/?trk=947f595b-f07f-42a1-bfc4-acf832730bac&sc_channel=ps&ef_id=Cj0KCQjwj5mpBhDJARIsAOVjBdr2XAtTUOGWhTT9GDGQtOxG76F7AJ1WGC4BNOS1p6Vx-Knvd5JNnpkaAv-aEALw_wcB:G:s&s_kwcid=AL!4422!3!566333972317!p!!g!!t%C3%A0i%20kho%E1%BA%A3n%20aws!15461586425!133325774289&all-free-tier.sort-by=item.additionalFields.SortRank&all-free-tier.sort-order=asc&awsf.Free%20Tier%20Types=*all&awsf.Free%20Tier%20Categories=*all

– Về cơ bản thì sau khi mình đăng ký xong, thì mình có thể sử dụng miễn phí :

750 giờ sử dụng phiên bản t2.micro hoặc t3.micro trên Linux, RHEL hoặc SLES tùy theo khu vực mỗi tháng

750 giờ sử dụng phiên bản t2.micro hoặc t3.micro trên Windows tùy theo khu vực mỗi tháng

Amazon S3 5GB,

750 Giờ sử dụng các Phiên bản db.t2.micro, db.t3.micro và db.t4g.micro một vùng sẵn sàng của Amazon RDS chạy cơ sở dữ liệu MySQL, MariaDB, PostgreSQL mỗi tháng (các công cụ DB được áp dụng)

Và các dịch vụ khác như SNS, VPC, DynamoDB..

– Để học và thực hành AWS, tốt nhất chúng ta chọn Region Us-east-1 để triển khai các tài nguyên nhé, vì Region này có mức chi phí gần như thấp nhất trong tất cả các Region:

– Khi bạn tạo tài khoản AWS xong, bạn sẽ thấy mình có thể tạo EC2 miễn phí Free Tier nhé:

 37. Hỏi: Anh cho em hỏi xíu phần SQS. Theo như bài giảng video em thấy SQS nằm giữa FE và BE. Giả sử em có sử dụng ALB và AutoScaling cho ứng dụng web phía BE của em, vậy thì thg SQS này sẽ nằm ở chỗ nào trong mô hình trên ạ?

Trả lời:

– Amazon Simple Queue Service (SQS) thường được sử dụng để xử lý các tác vụ xử lý nền (background processing) trong mô hình ứng dụng. SQS không nằm trực tiếp trong phần front-end (FE) hoặc back-end (BE) của ứng dụng, mà nó thường được đặt ở giữa FE và BE, tại nơi nó làm nhiệm vụ xử lý các tác vụ không đồng bộ.

– Vậy Với mô hình như em nói là sử dụng Application Load Balancer (ALB) và Auto Scaling cho phía BE, thì SQS thường sẽ nằm ở phần BE của ứng dụng. Cụ thể, khi một yêu cầu từ FE gửi đến để yêu cầu BE xử lý và cần thực hiện các tác vụ xử lý nền (VD như xử lý hàng đợi công việc hoặc gửi email xác nhận, xử lý dữ liệu lớn), BE có thể đặt các thông điệp(messages) vào trong SQS. Sau đó, các máy chủ hoặc workers trong BE có thể lấy các thông điệp từ SQS và thực hiện xử lý không đồng bộ.

– Cách mà SQS (Amazon Simple Queue Service) thường được sử dụng trong mô hình sử dụng Application Load Balancer (ALB) và Auto Scaling cho phía back-end (BE). Cụ thể như sau:

Yêu cầu từ phía trước (FE): Yêu cầu ban đầu từ phía người dùng hoặc ứng dụng client được gửi đến BE thông qua ALB và các máy chủ BE.

Xử lý hàng đợi công việc(jobs): BE có thể đặt các thông điệp (messages) vào trong SQS thay vì thực hiện xử lý công việc (VD như:  xử lý hàng đợi công việc, gửi email xác nhận, xử lý dữ liệu lớn) ngay lập tức. Việc này giúp giảm thời gian xử lý yêu cầu(requets) và đảm bảo là BE sẽ không bị quá tải.

Workers trong BE: Các máy chủ hoặc workers trong BE có thể lấy các thông điệp từ SQS để thực hiện xử lý không đồng bộ. Việc này giúp tạo ra một mô hình xử lý chia tải (load balancing) và có khả năng mở rộng khi có nhiều thông điệp đang chờ xử lý.

Xử lý không đồng bộ: Việc sử dụng SQS cho phép BE xử lý các công việc mà cần thời gian  xử lý lâu hơn mà không cần chờ đợi trong quá trình xử lý yêu cầu chính. Việc này giúp cải thiện hiệu suất và khả năng đáp ứng của ứng dụng.

– Note: workers là các thành phần hoặc tiến trình trong hệ thống đảm nhiệm nhiệm vụ lấy các công việc từ hàng đợi (queue) và thực hiện xử lý chúng

Vậy thì các workers thường sẽ là các server tách biệt hoàn toàn với BE ( chỉ xử lý messages trong queue ) đúng ko ạ? vì nếu các workers đó chính là các server chạy BE luôn thì việc dùng SQS nó hơi thừa đúng ko ạ?

Trả lời:

OK e đã hiểu đúng. Vậy nếu em đã có các máy chủ workers để xử lý các tác vụ không đồng bộ và chúng được quản lý một cách hiệu quả, thì em có thể không cần sử dụng Amazon Simple Queue Service (SQS) trong trường hợp này. SQS thường được sử dụng để quản lý hàng đợi thông điệp và giúp phân phối các tác vụ đến các workers một cách phân tán và bảo đảm tính nhất quán.

Nếu trường hợp em đã có cơ chế quản lý hàng đợi hoặc các giải pháp khác để đảm bảo phân phối công việc(jobs) và không muốn sử dụng SQS, em có thể tiếp tục sử dụng cơ chế đó. Tuy nhiên, nếu em đang tìm kiếm một giải pháp quản lý hàng đợi đám mây và muốn sử dụng dịch vụ đã được quản lý, SQS là một lựa chọn tốt.

Tuy nhiên, nếu hệ thống của em đã triển khai load balancing và auto scaling một cách hiệu quả và không gặp phải vấn đề về tải quá lớn hoặc tính nhất quán dữ liệu, em có thể không cần sử dụng SQS. Quyết định cuối cùng nên dựa trên yêu cầu cụ thể của ứng dụng và kiến trúc hệ thống của em.

Và việc sử dụng Amazon Simple Queue Service (SQS) có thể tiết kiệm chi phí so với việc triển khai và quản lý các máy chủ workers, do nó loại bỏ được chi phí về hạ tầng hệ thống. Nếu tải công việc cao

Nhưng trong trường hợp tải công việc thấp, việc triển khai và duy trì một số máy chủ workers có thể có chi phí thấp hơn.

38. Hỏi: Anh cho em hỏi về phần Auto Scaling với ạ. Giả sử em mà đẩy code mới nhất lên các nơi lưu trữ mã nguồn như Git chẳng hạn, thì cấu hình hay là làm cách nào để Auto Scaling nó biết để nó cập nhật lại các tài nguyên trong EC2 để nó nhận code mới nhất vậy ạ? Anh có thể chia sẻ thêm về luồng hoạt động trong trường hợp này ko ạ?

Trả lời:

-Trong AWS e có thể Sử dụng các dịch vụ như AWS CodePipeline hoặc Jenkins, và có thể xây dựng quy trình Continuous Integration/Continuous Deployment (CI/CD) để tự động xây dựng và triển khai code mới vào môi trường EC2.

–  Ngoài ra Trong quá trình triển khai, e có thể sử dụng dịch vụ AWS CodeDeploy để cập nhật code trên các EC2 trong Auto Scaling Group. CodeDeploy cho phép em tự động triển khai code mới và quản lý việc ngừng(stop), khởi động lại(restart), và cập nhật(update) các EC2.

– Vậy về việc tự động cập nhật code cho các EC2 chạy trong Auto Scaling Group, thì có thể sử dụng phương pháp cấu hình blue/green deployment. Blue/green deployment là một phương pháp triển khai app code cho phép em có thể  triển khai EC2 instance mới của ứng dụng (gọi là “green”) trong khi các EC2 hiện tại (gọi là “blue”) vẫn đang chạy và cung cấp dịch vụ cho người dùng. Sau khi  EC2 mới đã đc triển khai thành công và được kiểm tra, em có thể chuyển dịch vụ hoặc traffic (có thể sử dụng chuyển traffic trong dịch vụ DNS route53 từ EC2 cũ sang EC2 mới)từ EC2 cũ sang EC2 mới một cách an toàn.

Em có thể tham khảo Link này để hiểu về Blue/green deployment nhé: https://aws.amazon.com/vi/blogs/devops/bluegreen-infrastructure-application-deployment-blog/

+ Cái Link tiếng Nhật này CI/CD for EC2(Auto Scaling)e dùng google tool dịch ra tiếng anh là ok: https://blog.serverworks.co.jp/cicd-autoscaling-blue-green-deploy

+ E có thể Xem 1 video trên Youtube về AWS EC2 &  Autoscaling & Load Balancer & CodeDeploy | Deploy Code At Scale để có thể hiểu hơn về AWS CodeDeploy, LINK sau : https://youtu.be/Ekgi2HfnJcw?t=5

– Và e có thể tham khảo thêm về Triển khai CI/CD cho ứng dụng Java với Github, AWS Codebuild, Codepipeline, Route 53, ECR, ECS EC2, hỗ trợ AutoScaling, Blue green deployment, để có thêm kiến thức trong Link: https://nobodycodewithme.com/004-trien-khai-ci-cd-cho-ung-dung-java-voi-github-aws-codebuild-codepipeline-route-53-ecr-ecs-ec2-ho-tro-autoscaling-blue-green-deployment/

39. Hỏi: Phần Edge Location hình như bị nhầm. Mục đích làm giảm thời gian xử lý (giảm độ trễ) 1 request mới đúng chứ không phải làm giảm tốc độ xử lý?

Trả lời:

Thanks bạn vì đã có ý kiến về bài giảng. Đúng, bạn đã hiểu đúng. Edge Location không ảnh hưởng đến tốc độ xử lý trên máy chủ web server. Mục đích chính của Edge Location là giảm thời gian độ trễ (latency) trong việc truy cập dữ liệu từ máy tính người dùng đến các máy chủ web servers. Khi người dùng yêu cầu truy cập dữ liệu, Edge Location sẽ cung cấp dữ liệu từ các điểm gần nhất với người dùng cuối, giúp giảm thời gian mà dữ liệu phải đi qua qua mạng và tới đích. Việc này giúp cải thiện trải nghiệm người dùng bằng cách giảm độ trễ và tăng tốc độ truy cập.

Và trong bài giảng mình cũng nói rõ là Edge Location giúp giảm thời gian độ trễ (latency). Tuy nhiên trong slide thì có để câu: “Giúp tăng tốc độ trong việc xử lý thông tin cho hệ thống AWS”. Có thể gây hiểu lầm chút nhé!

40. Hỏi: e muốn hỏi anh là, tầm mới sử dụng aws đươc vài tháng nhưu em,,, thì có khóa associate nào phù hợp với level của em không ạ?

Trả lời:

Hello em,

– Em nên bắt đầu với khóa AWS Solution Architect Associate của anh, vì khóa này phù hợp cho người mới và sẽ nâng cao dần mức độ chuyên sâu.

Tuy nhiên khóa này cũng cần 1 số kiến thức liên quan đến Linux, nên nếu được em có thể học Linux trước, rồi sau đó học AWS và Azure.

Để xây dựng nền tảng tốt cho công việc, em nên đặt mục tiêu thi các chứng chỉ như LPIC-1 (Linux), AWS Solution Architect Associate, hoặc Azure AZ-104.

Những chứng chỉ này sẽ giúp tăng cơ hội xin việc với mức lương cao hơn nhé  (đây cũng là kinh nghiệm của anh trong quá trình đi xin việc nên anh chia sẻ với em).

– Về cách học thì trong quá trình học thì em cần tuân thủ làm theo chính xác các bước như trong tài liệu và trong các videos hướng dẫn ( ko bỏ qua bất kỳ bước nào),

mà không cần lo lắng về việc phải hiểu chi tiết về bài học. Vì sau khi em đã thực hiện làm thành thạo các bước (Khi đã quen tay), hiểu biết của em sẽ tự nhiên dần dần cải thiện

và em sẽ hiểu rõ hơn về các vấn đề kỹ thuật.

1. Cần làm các bài thực hành Hand-On Labs nhiều lần để để nắm vững kiến thức.

2. Sau khi em đã làm thành thạo các bài demo và thực hành, em có thể thử điều chỉnh làm theo cách làm của riêng em.

Good luck,

Phương.

41. Hỏi:hỏi câu 1 Practice Exam 1. Em chào anh, anh cho em hỏi câu 1 Practice Exam 1.đề bài có hỏi là How many minutes after the first instance is launched will Auto Scaling accept another scaling actMty request? tức là sau bao nhiêu phút sau khi instance đầu tiên khởi động xong thì sẽ nhận request mới. mà instance đầu tiên khởi động ở phút 3, đến phút 10 hết cool down nên em đang hiểu đáp án là 10-3 = 7 phút, chứ không phải đến phút 11 như đáp án. anh giải thích giúp em ạ?

Trả lời:

Hello Thắng,
Đây là câu hỏi thường gây nhầm lẫn trong các bài practice exam AWS. Vậy tính toán như sau:
Instance được launch ở phút 3 Scaling tiếp theo được phép vào phút 13. Vậy thời gian chờ là: 13-3=10 phút.
Vậy tại sao câu trả lời là: 11 phút.
Vì họ tính theo mốc “hoàn thành cooldown” = đầu phút 14, nên lấy: Bắt đầu: phút 3 Và Kết thúc: phút 14, vậy 14-3=11 phút. Vì tính phút bắt đầu là phút thứ 3 và phút cuối là đầu phút 14-> 11 phút. Và đọc kỹ Câu hỏi thì câu hỏi không hỏi về “phút bao nhiêu sẽ được phép scale tiếp”, mà hỏi “bao nhiêu phút SAU khi instance đầu tiên launch” thì mới scale tiếp được
Chúc e học và thi tốt nhé..
Regards,
Phương.

42. Câu 48 trong phần Practice Exam 1. Đáp án là không thể thay đổi Security Groups khi đang chạy EC2. Tuy nhiên, theo như em tìm hiểu ở: docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html thì vẫn cho phép.
“When you launch an instance in a VPC, you must specify a security group that’s created for that VPC. After you launch an instance, you can change its security groups.”

Trả lời:

Câu này là về EC2-Classic em: “EC2-Classic is the original release of Amazon EC2. With this platform, instances run in a single, flat network that is shared with other customers. With EC2-VPC, instances run in a virtual private cloud (VPC) that is logically isolated to only one AWS account“. Do đó câu trả lời là đúng em nhé. E có thể tham khảo về EC2 classic trong link: https://docs.rightscale.com/faq/clouds/aws/What_is_an_EC2-Classic_network.html#:~:text=EC2%2DClassic%20is%20the%20original,to%20only%20one%20AWS%20account.

43. Khi em đăng nhập EC2 bằng key .pem thành công qua Git Bash, nhưng sau khi tắt máy (máy local), hôm sau vào lại thì phải cấu hình lại key hay làm lại từ đầu. Có cách nào vào lại nhanh hơn không?

Chào em, đây là câu hỏi rất hay và cũng là vấn đề nhiều bạn mới gặp phải. Anh sẽ giải thích chi tiết nhé:

1. Key .pem không cần cấu hình lại nếu em đã lưu đúng Key .pem dùng để xác thực khi SSH vào EC2.

Một khi đã có file .pem và quyền truy cập phù hợp, em không cần cấu hình lại mỗi lần login.

Em chỉ cần chạy lại lệnh SSH như sau:

ssh -i “ten_file.pem” ec2-user@<Public-IP>

Lưu ý: thay ten_file.pem và Public-IP theo thông tin của em.

2. Trường hợp mất kết nối hoặc tắt Git Bash thì sao?

Khi em tắt máy local hoặc tắt Git Bash, thì máy EC2 trên AWS vẫn chạy bình thường, trừ khi:

Em stop hoặc terminate instance từ AWS Console.

Instance dùng Elastic IP hay Dynamic IP: Nếu không gán Elastic IP (Là 1 kiểu thuê IP public tĩnh phải trả tiền cho IP này), mỗi lần EC2 restart sẽ có IP mới → em cần sửa lại IP trong lệnh SSH.

3. Làm thế nào để đăng nhập vào EC2 instance nhanh hơn?

Có cách giúp em đăng nhập nhanh mà không phải gõ lại lệnh dài mỗi lần login đó là tạo file script SSH.

Em tạo file connect.sh trong Git Bash với nội dung như sau:

#!/bin/bash

ssh -i “/path/to/key.pem” ec2-user@<Public-IP>

Sau đó chỉ cần chạy:  ./connect.sh

Tóm lại:

+ Không cần cấu hình lại key .pem mỗi lần nếu đã có sẵn file.

+ EC2 chắc chắn không bị mất đi trừ khi bị stop hoặc terminate.

+ Nên dùng Elastic IP và alias/script để đăng nhập nhanh hơn.

Chúc em học tốt và thành công nhé!

44. Trường hợp tạo 1 bản sao S3 backup đích thì hệ thống có tính thêm tiền không thầy ơi? Trường hợp Thư mục nguồn và đích mình có thể chọn chung 1 Region có được không thầy ơi? hay bắt buộc phải chọn thư mục đích khác Region và tại sao phải thế? xin vui lòng giải thích?

Trả lời:

Có thể chọn cùng Region, không bắt buộc phải khác Region em nhé.

· AWS hỗ trợ cả:

o Same-Region Replication (SRR) – Replication trong cùng một region.

o Cross-Region Replication (CRR) – Replication sang region khác.

1. Same-Region Replication (SRR):

Sao chép dữ liệu từ một bucket này sang một bucket khác trong cùng một Region.

Ví dụ: từ bucket-a sang bucket-b, đều ở ap-southeast-1 (Singapore).

• Mục đích SRR:

Phân quyền truy cập (khách hàng khác nhau dùng bucket khác nhau).

Phân tách môi trường PROD và DEV.

Giữ bản sao backup riêng biệt trong cùng region nhưng tách biệt về bảo mật.

• Ưu điểm:

Không bị tính phí transfer giữa region.

Chi phí thấp hơn CRR.

2. Cross-Region Replication (CRR):

Sao chép dữ liệu sang bucket tại một Region khác.

Ví dụ: từ Singapore sang Tokyo.

 – Mục đích CRR:

Disaster Recovery (DR): nếu cả region Singapore gặp sự cố, dữ liệu vẫn còn ở Tokyo.

Tuân thủ quy định pháp lý hoặc chính sách dữ liệu (ví dụ dữ liệu phải nằm ở quốc gia cụ thể).

Tối ưu độ trễ truy cập nếu người dùng ở nhiều khu vực khác nhau.

  – Nhược điểm:

Tính phí truyền dữ liệu liên region (data transfer) – có thể chi phí truyền dữ liệu cao.

✅ Kết luận

• Không bắt buộc phải khác Region.

• Nếu mục tiêu chỉ là backup nội bộ, tách quyền hoặc môi trường, thì nên dùng SRR cho tiết kiệm chi phí.

• Nếu cần Disaster Recovery thực sự hoặc tuân thủ bảo mật cao hơn, hãy chọn CRR sang Region khác.

45. Trong bài trước khi Thầy tạo máy EC2 thầy Dùng GIT Bash để login vào. Cho em hỏi trong các bài đầu tiên thầy Dùng GIT để login vào máy EC2, trong bài này mình thực hành trên web? vậy có sự khác nhau như thế nào ạ?

Trả lời:

Tôi dùng GIT để login vào máy EC2 để trình bày cho các bạn biết cách sử dụng key pair aws từ PC của mình và SSH vào EC2. Và tôi login vào EC2 trên Web cũng là để cho các bạn biết cách login vào EC2 trên Web, và cách Login vào EC2 trên web thì nó đơn giản và tiện hơn cho chúng ta.

46. Nếu delete data trong Bucket nguồn? Cho em hỏi khi đã cấu hình Backup Relication xong, việc xóa data trong Bucket nguồn có ảnh hưởng tới Bucket đích không? nếu có xin cho giải pháp khắc phục?

Trả lời:

Không bị mất dữ liệu em nhé, mặc định xóa dữ liệu ở bucket nguồn không ảnh hưởng đến bucket đích, trừ khi em kích hoạt tính năng “delete marker replication” trong cấu hình link: https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-marker-replication.html .

47. Trường hợp tạo 1 bản sao S3 backup đích thì hệ thống có tính thêm tiền không thầy ơi?

Trả lời:

Có, khi em tạo một bản sao backup đích (replica) của một bucket S3, AWS sẽ tính thêm chi phí (VD: khoảng $0.0125/GB mỗi tháng cho S3 Standard‑Infrequent Access (IA)) cụ thể là các khoản phí sau:

1. Chi phí lưu trữ tại vùng đích

Khi em sao chép dữ liệu từ bucket nguồn sang bucket đích (có thể là ở cùng region hoặc khác region), AWS sẽ tính phí lưu trữ riêng biệt cho bucket đích.

Ví dụ: Nếu em sao chép từ S3 Standard ở ap-southeast-1 sang S3 Standard ở us-east-1, thì mỗi bên đều bị tính phí lưu trữ như nhau.

2. Chi phí truyền dữ liệu (data transfer)

Nếu bucket đích trong một region khác (Cross-Region Replication – CRR) với bucket nguồn, thì AWS sẽ tính phí truyền dữ liệu giữa các region. Ví dụ: truyền dữ liệu từ Singapore sang Hoa Kỳ sẽ bị tính thêm chi phí outbound từ Singapore.

Nếu bucket đích trong cùng một region (Same-Region Replication – SRR) với bucket nguồn thì không tính phí truyền dữ liệu, nhưng vẫn tính chi phí lưu trữ như bình thường.

3. Chi phí PUT request

Mỗi đối tượng được sao chép sang bucket đích sẽ tạo ra một PUT request, và AWS tính phí cho từng request này.

48. Hỏi đáp về Read Preplicas: Thưa thầy cho em hỏi trưởng hơp tạo Read Replicas có tốn tiền không?việc người quản trị có thể tạo được bao nhiêu Read Replicas? và việc Backup nó như thế nào?

Trả lời:

Chào em, câu hỏi này liên quan đến Amazon RDS (hoặc Aurora) và tính năng Read Replica, vậy tôi giải thích từng ý một nhé:

1. Tạo Read Replica có tốn tiền không?

– Có tốn phí, vì khi tạo Read Replica, AWS sẽ tạo ra một instance RDS mới độc lập để xử lý các truy vấn đọc (read) dữ liệu từ instance này.

Phí sẽ bao gồm:

+ Chi phí compute (giống như instance RDS thông thường, tính theo loại server, vCPU, RAM)

    + Chi phí storage (theo dung lượng lưu trữ dữ liệu)

    + Chi phí I/O, backup cho Replica

    + Chi phí truyền dữ liệu (nếu Replica khác Region)

– Nếu Replica ở cùng Region với DB gốc thì không mất phí Data Transfer nội region, nhưng vẫn mất phí vận hành instance.

– Ví dụ: Nếu DB gốc là db.m5.large thì Replica cũng sẽ tính tiền giống như một instance db.m5.large.

2. Người quản trị có thể tạo được bao nhiêu Read Replicas?

– Số lượng Read Replicas tối đa phụ thuộc vào engine:

   + Với RDS MySQL, MariaDB, PostgreSQL trên RDS: Tối đa được tạo 15 Read Replicas cho mỗi DB gốc.

+ Với Aurora: Có thể tạo tới 15 Aurora Replicas trong cùng cluster.

– Nếu muốn hơn giới hạn mặc định, có thể gửi yêu cầu tăng hạn mức Số lượng Read Replicas cho AWS Support, nhưng  hiếm khi cần.

3. Backup Read Replica như thế nào?

– Thông thường, backup dữ liệu được thực hiện trên DB gốc, vì Replica chỉ là bản sao để đọc dữ liệu.

– Nếu em muốn backup từ Replica:

+ Trên RDS MySQL/PostgreSQL: Có thể promote Replica thành một DB độc lập, sau đó bật tính năng backup.

+ Trên Aurora: Replica nằm trong cùng cluster nên backup áp dụng cho toàn cluster, không cần cấu hình riêng.

Lưu ý:
+ Nếu mục đích chính là tăng khả năng chịu tải đọc (read scalability) dữ liệu từ các ứng dụng, thì chúng ta dùng Read Replica là hợp lý.
+ Nếu mục đích chính là backup, thì không nên dùng Replica thay backup — hãy dùng tính năng Automated Backup hoặc Manual Snapshot của AWS.

49. Tại sao tài khoản User IAM không tạo được RDS : Thưa thầy tại sao mình không dùng user IAM để tạo RDS mà phải dùng User root để tạo? xin thầy giải thích?

Trả lời:

Không bắt buộc phải dùng root để tạo RDS em nhé, và AWS còn khuyến cáo không dùng root cho công việc hàng ngày vì rủi ro bảo mật.

Chỉ cần IAM user hoặc IAM role có đủ quyền liên quan tới RDS, VPC, IAM PassRole, KMS (nếu mã hóa) là tạo được.

Root chỉ dùng cho các tác vụ như cấp tài khoản như thanh toán, đóng account, bật MFA…

Để tạo một IAM user với quyền toàn quyền quản lý RDS, em chỉ cần:

1. Tạo IAM user (qua Console, CLI, hoặc API)

2. Gán policy quản lý có tên: AmazonRDSFullAccess cho user đó

Đây là cách nhanh – an toàn – chuẩn AWS để cấp quyền cho 1 user có quyền quản trị dịch vụ AWS RDS đầy đủ.

50. Về Cách Lưu Trữ Database: Trường hợp 2 Data base cùng lưu Az bị lỗi thì phải làm sao ạ, cách sao lưu như thế nào để phục hồi thảm hoạ ví dự data ngày 15 bị hư thì Máy A hư sẽ syn qua May B thì làm sao ạ? vì vậy em có thể backup ra từng ngày hay sao? nếu backup từng ngày thì cách lưu 2 máy A và B sẽ không có tác dụng? xin cho giải pháp?

Trả lời:

1. Vì sao 2 DB cùng AZ bị lỗi là nguy hiểm
Nếu cả Primary và Standby (Multi-AZ) đều nằm trong cùng Availability Zone, thì khi AZ đó gặp sự cố (mất điện, mất mạng, lỗi phần cứng diện rộng), cả 2 DB sẽ cùng bị ảnh hưởng , chúng ta có thể suy ra là DB không còn khả năng failover.
Thực tế Multi-AZ của RDS luôn đặt bản sao standby ở AZ khác để tránh rủi ro này, nên tình huống “2 DB cùng AZ” chỉ xảy ra nếu mình tự cài DB trên EC2 và cấu hình sai kiến trúc.

2. Giải pháp Backup để phục hồi thảm hoạ (DR)

– Tự động sao lưu hàng ngày (Automated Backups):
AWS RDS hỗ trợ backup hàng ngày + lưu giữ từ 1–35 ngày. Nếu DB ngày 15 bị hỏng, có thể restore về snapshot của ngày 14 hoặc trước đó. Dùng tùy chọn Point-in-Time Recovery (PITR) để khôi phục tới thời điểm ngay trước khi lỗi xảy ra.

– Snapshot thủ công (Manual Snapshot):
Có thể tạo snapshot bất kỳ lúc nào (trước khi nâng cấp, deploy…) và snapshot này không bị xóa khi DB bị delete.

– Cross-Region Snapshot Copy:
Để chống rủi ro nếu cả Region gặp sự cố, em có thể copy snapshot sang region khác hoặc lưu trữ offline.

3. Về việc “Máy A hư sẽ sync qua Máy B”

– Nếu dùng replication theo thời gian thực (Multi-AZ, Read Replica), khi DB instance A hỏng dữ liệu mà đã sync sang DB instance B thì cả B cũng hỏng → đây là replication dữ liệu DB không phải là backup DB data.

– Backup theo ngày không bị ảnh hưởng bởi data replication, vì snapshot là dữ liệu “đóng băng” tại thời điểm backup, không phải là sync tiếp dữ liệu hỏng.

– Về Replication (máy A và B) và Backup là hai mục đích khác nhau:

· Replication (A ↔ B): đảm bảo tính sẵn sàng (HA). Nếu A hỏng phần cứng hoặc AZ down → B lên thay ngay. Nhưng replication không bảo vệ khỏi lỗi logic (xoá nhầm, ghi sai dữ liệu), vì lỗi đó sẽ sync data ngay lập tức.

· Backup theo ngày: đảm bảo tính phục hồi (DR). Nếu ngày 15 dữ liệu hỏng → có thể khôi phục lại snapshot ngày 14 hoặc   trước đó. Lúc này replication không giúp gì, chỉ backup mới cứu được.

4. Trong thực tế công việc

Luôn bật Multi-AZ để chống lỗi phần cứng + backup hàng ngày để chống lỗi dữ liệu.

Nếu yêu cầu DR cao → thêm Cross-Region Backup hoặc Read Replica ở region khác.

Luôn kiểm tra RPO (Recovery Point Objective) và RTO (Recovery Time Objective) để thiết kế phù hợp.

51. MongoDB: Chào Thầy cho em hỏi?em đã buil 1 Mongodb trên máy Local Thây vì em import data từ máy Local lên AWS thì em Application Migration cả cụm có được không ạ?

Trả lời:

Hi em,

AWS Application Migration Service (MGN) là dịch vụ để dịch chuyển nguyên toàn bộ server, không phù hợp để migrate cụm MongoDB. Vậy nếu em muốn chuyển dữ liệu MongoDB từ máy local lên AWS, em nên dùng AWS DMS (Database Migration Service) để chuyển dữ liệu hoặc cấu hình đồng bộ. Nếu target là MongoDB Atlas, có thể dùng Atlas Live Migration Service để tiếp tục đồng bộ và giảm downtime nhé.

Em có thể tham khảo tài liệu “Using MongoDB as a source for AWS DMS“:  https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MongoDB.html

53. Cho em hỏi máy Data server thông qua 1 Nat gateways để ra internet vậy bên ngoài có thể ping được ra internet vậy bên ngoài có ping vào máy đó được không?

Trả lời:

Không em nhé!. NAT Gateway chỉ cho phép EC2 trong private subnet đi ra ngoài Internet, chứ không cho phép kết nối từ Internet vào trong. Vì vậy bên ngoài không thể ping hay truy cập trực tiếp vào Data server qua NAT Gateway được.

Muốn bên ngoài truy cập thì phải  truy cập thông qua Bastion Host, VPN…hay có thể truy cập từ một EC2 trong public subnet cùng VPC với private subnet nhé.

54. Em có 1 con Data base kết nối với một con Primary web server, trường hợp Failover thêm 2 con nữa thì có cần tạo thêm vài server data base không? hay chỉ cần tạo kết nối các server Failover tới 1 con data base? xin thầy giải thích giúp trường hợp này?

Trả lời:

Chỉ cần một database (RDS) thôi em . Các web server (primary + failover) đều kết nối chung vào database đó, không cần tạo thêm database khác. RDS đã có cơ chế Multi-AZ để tự động failover cho DB nếu cần.

Và cần cấu hình bật tính năng Multi-AZ cho RDS, để AWS tự tạo một bản sao standby trong AZ khác và tự động failover khi cần em nhé.

55. Dear Thầy, trong bài tạo loadbalancer thấy thầy chỉ tạo service mà không thấy tạo ingress. Vậy khi nào ingress được tạo vậy thầy. Thầy có thể giải thích rõ thêm về điểm này không ạ?

Trả lời:

Hi em,

– Service type=LoadBalancer: khi tạo Service kiểu này, Kubernetes (qua cloud-provider) sẽ tạo một Load Balancer riêng và gán public IP/endpoint cho Service đó — không sinh Ingress.

– Ingress chỉ xuất hiện khi: Chúng ta tạo object Ingress và trong cluster có Ingress Controller (ví dụ: Nginx Ingress Controller, AWS ALB Ingress Controller). Controller này mới đi xử lý Ingress và (trên cloud) thường tự tạo 1 LB cho toàn bộ Ingress.

– Khi nào dùng Ingress? Khi chúng ta muốn gom nhiều service qua một điểm vào (một LB) và routing theo host/path (HTTP/HTTPS). Nếu chỉ expose 1 service nhanh gọn, dùng LoadBalancer service là đủ em nhé.

56. Hi thầy, em làm bài 17, Khi tạo policy S3RestrictedPolicy xong thì Access Level là Limitted, không như trong video là full access. Nên không truy cập được. Có sai xót gì ở đây không thầy?

Trả lời:

Em khi click vào nút Create policy em chọn service S3, sau đó tick chọn All S3 actions (s3:*), thì em sẽ thấy Access level chắc chắn là full access như trong Video (có nghĩa là Nếu trong IAM Policy em chọn Service: S3 và tick All S3 actions (s3:*) thì theo logic nó phải là Full access ). Lỗi ở đây có thể do account em đang sử dụng không có quyền admin, vậy em cần đảm bảo tài khoản aws đang sử dụng có quyền admin quản trị tất cả các tài nguyên để có quyền tạo IAM Policy nhé.

57. Cho em hỏi máy Data server thông qua 1 Nat gateways để ra internet vậy bên ngoài có thể ping được ra internet vậy bên ngoài có ping vào máy đó được không?

Không em nhé!. NAT Gateway chỉ cho phép EC2 trong private subnet đi ra ngoài Internet, chứ không cho phép kết nối từ Internet vào trong. Vì vậy bên ngoài không thể ping hay truy cập trực tiếp vào Data server qua NAT Gateway được.

Muốn bên ngoài truy cập thì phải  truy cập thông qua Bastion Host, VPN…hay có thể truy cập từ một EC2 trong public subnet cùng VPC với private subnet nhé.

58. Combine 2 phương pháp multi-AZ và Read Replica: Mình có thể kết hợp 2 phương pháp để đảm bảo tính toàn vẹn và đọc data không thầy?

Trả lời:

Em hoàn toàn có thể kết hợp Multi-AZ + Read Replica, và đó cũng là mô hình rất phổ biến: dùng Multi-AZ để đảm bảo tính toàn vẹn dữ liệu & HA, và dùng Read Replica để scale cho các tác vụ đọc dữ liệu của apps từ database nhé:

– Có thể và nên kết hợp:

• Thiết lập instance Multi-AZ làm primary (writer) để bảo toàn dữ liệu & failover.
• Tạo Read Replica(s) từ primary để xử lý các truy vấn đọc nặng.
• Ứng dụng viết (writes) cần được truy cập qua writer endpoint.
• Ứng dụng đọc (reads) cần được truy cập qua reader endpoints (replicas) nếu có thể chấp nhận độ trễ nhỏ trong đồng bộ dữ liệu , do dữ liệu trên replica có thể không hoàn toàn update đồng bộ dữ liệu lập tức.

{

“Version”: “2012-10-17”,

“Statement”: [

{

“Sid”: “VisualEditor0”,

“Effect”: “Allow”,

“Action”: [

“s3:ListAccessPointsForObjectLambda”,

“s3:GetAccessPoint”,

“s3:PutAccountPublicAccessBlock”,

“s3:ListAccessPoints”,

“s3:CreateStorageLensGroup”,

“s3:ListJobs”,

“s3:PutStorageLensConfiguration”,

“s3:ListMultiRegionAccessPoints”,

“s3:ListStorageLensGroups”,

“s3:ListStorageLensConfigurations”,

“s3:GetAccountPublicAccessBlock”,

“s3:ListAllMyBuckets”,

“s3:ListAccessGrantsInstances”,

“s3:PutAccessPointPublicAccessBlock”,

“s3:CreateJob”

],

“Resource”: “*”

},

{

“Sid”: “VisualEditor1”,

“Effect”: “Allow”,

“Action”: “s3:*”,

“Resource”: [

“arn:aws:s3::138383657684:accesspoint/*”,

“arn:aws:s3:*:138383657684:accesspoint/*/object/*”

]

},

{

“Sid”: “VisualEditor2”,

“Effect”: “Allow”,

“Action”: “s3:*”,

“Resource”: [

“arn:aws:s3-object-lambda:*:138383657684:accesspoint/*”,

“arn:aws:s3:::appconfig01tungpvkg”,

“arn:aws:s3:*:138383657684:access-grants/default”,

“arn:aws:s3:::appconfig01tungpvkg /appconfig01tungpvkg “,

“arn:aws:s3:::appconfig02tungpvkg /appconfig02tungpvkg “,

“arn:aws:s3:*:138383657684:accesspoint/*”,

“arn:aws:s3:us-west-2:138383657684:async-request/mrap/*/*”,

“arn:aws:s3:*:138383657684:job/*”,

“arn:aws:s3:*:138383657684:access-grants/default/grant/*”,

“arn:aws:s3:*:138383657684:access-grants/default/location/*”,

“arn:aws:s3:*:138383657684:storage-lens-group/*”,

“arn:aws:s3:*:138383657684:storage-lens/*”

]

}

]

}

Ở Slide 28, 4 phút 13s về nội dung S3 có dung lượng tối đa 5TB là chưa chính xác.
– S3 cung cấp không gian lưu trữ không giới hạn -> việc có dung lượng tối đa là không đúng.

– Thông tin dung lượng tối đa 5TB là cho 1 lần put đơn lẻ (thông tin thêm: AWS khuyến nghị với file trên 100MB thì sử dụng trình Miltipart Upload để có thể đạt được giới hạn cho phép). Thầy cập nhật lại nội dung cho các bạn học sinh khác không bị confused ạ.

Trả lời:

Hello em,

Cảm ơn em đã góp ý rất kỹ, và em nhận xét như vậy là đúng về mặt kỹ thuật.Vậy anh làm rõ lại để em (và các bạn khác) không bị hiểu nhầm nhé:

1. S3 có “không giới hạn” hay tối đa 5TB?

Cả hai thông tin không mâu thuẫn, vì cả 2 cái này nói về 2 khái niệm khác nhau:

–  Thứ nhất: S3 cung cấp không gian lưu trữ gần như không giới hạn, có nghĩa là tổng dung lượng bucket có thể lưu trữ là không giới hạn (theo thiết kế dịch vụ).

– Thứ 2: 5TB là dung lượng lưu trữ tối đa của một object, vì vậy mỗi một object trong S3 có thể có dung lượng đạt mức tối đa là 5TB.

2. Về phần Put Object, Em nói đúng: 5TB là giới hạn cho một object.

AWS khuyến nghị dùng Multipart Upload cho file lớn (thường từ >100MB trở lên), Multipart Upload cho phép upload nhiều phần của file để đạt đến giới hạn 5TB

3. Vậy Slide có sai không?

Nội dung trong slide là : “S3 có dung lượng tối đa 5TB”. Vậy cách diễn đạt này dễ gây hiểu nhầm là tổng dung lượng lưu trữ dữ liệu trên S3 chỉ có 5TB.

Cách nói đúng phải là: “Mỗi object trong S3 có dung lượng tối đa cho phép là 5TB, còn tổng dung lượng lưu trữ dữ liệu cho S3 là gần như không giới hạn.”

Vậy anh sẽ sẽ chỉnh lại slide để tránh gây nhầm lẫn cho các bạn khác!

Cảm ơn em đã học rất kỹ.