DEV Community: Danh Hoang Hieu Nghi

AWS GuardDuty vs OpenSearch Security Analytics: Building a Real SIEM Pipeline on AWS

Danh Hoang Hieu Nghi — Tue, 28 Jul 2026 16:00:37 +0000

Comparing AWS GuardDuty and OpenSearch Security Analytics for AWS SIEM architecture, and why centralizing AWS security findings usually means running both, not choosing one.

It's 2am and PagerDuty just fired. GuardDuty flagged an anomalous UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration finding in one account.

Meanwhile your WAF logs, three on-prem firewalls, and a fleet of custom application logs sit in a completely different system that has no idea the IAM finding exists. You need to answer one question — "has this IP touched anything else we own in the last 30 days?" — and you can't, because the answer is split across five tools with five different query languages, and none of them talk to each other.

This is the visibility problem every team running more than a handful of AWS accounts eventually hits. GuardDuty tells you something bad happened, but it wasn't built to be the place you go searching for everything that happened. That's a separate job, and AWS gives you a separate tool for it: Security Analytics on Amazon OpenSearch Service. The two get talked about as competitors more often than they should be — in practice, they're stages in the same pipeline.

What each service actually is

Amazon GuardDuty is a fully managed threat detection service — you turn it on and it starts analyzing immediately, with no infrastructure to provision or patch. It automatically ingests CloudTrail management events, VPC Flow Logs, and DNS logs, and you can layer on optional protection plans for S3 data events, EKS audit logs, RDS login activity, Lambda network activity, and Runtime Monitoring (OS, network, and file-level events on EC2, ECS on Fargate, and EKS). Detection comes from AWS-curated threat intelligence feeds combined with ML models trained across AWS's own telemetry. You don't write the rules; AWS does. It scales cleanly across an organization too — a delegated administrator account can auto-enable GuardDuty for every existing and new member account without anyone touching individual accounts by hand.

OpenSearch Security Analytics is a different animal. It's a feature layered on top of an OpenSearch Service domain that you provision, scale, and pay for like any other cluster. Nothing shows up automatically — you build the ingestion pipeline yourself, typically with Data Prepper, Kinesis Data Firehose, or Logstash, feeding in whatever you want: Windows event logs, NetFlow, CloudTrail, DNS logs, Active Directory/LDAP, custom application logs, even on-prem network gear. Detection rules are written in Sigma, an open and community-maintained format, which means you can write, tune, and share your own detections instead of relying on a fixed catalog. When a detector matches a rule against an incoming log event, it generates a finding, and alerting runs through OpenSearch's Alerting/Notifications plugin — which supports Amazon SNS as a channel alongside Slack, Chime, and custom webhooks. Underneath all of that, it's still a search engine, so you get real full-text and structured log search — the one thing GuardDuty categorically does not offer.

Where they genuinely differ

	Amazon GuardDuty	OpenSearch Security Analytics
Operational model	Fully managed, zero infrastructure	Self-managed OpenSearch domain — you size, scale, and patch it
Data sources	Fixed set: CloudTrail, VPC Flow Logs, DNS, plus optional S3, EKS, RDS, Lambda, Runtime Monitoring	Anything you pipe in — AWS logs, on-prem, custom apps, network devices
Detection logic	AWS-curated threat intel + ML, closed finding types	Sigma rules, open format, fully customizable
Log search	None — findings only, no raw log query	Native full-text/structured search across all ingested data
Multi-account	Native AWS Organizations delegated admin, auto-enable	Manual per-pipeline setup; no built-in org construct
Retention	Findings retained ~90 days (via Security Hub)	You control retention — as long as storage allows
Cost driver	Pay per GB of data analyzed, no cluster to run	Pay for the OpenSearch domain (instances, storage) plus ingestion pipeline

The pattern in that table is consistent: GuardDuty trades flexibility for zero operational overhead, and OpenSearch Security Analytics trades operational overhead for flexibility and depth. Neither trade is wrong — they're just optimized for different jobs. GuardDuty is built to catch the AWS-specific attack patterns AWS itself has the best visibility into (credential exfiltration, crypto-mining behavior, anomalous API calls) without you lifting a finger. OpenSearch Security Analytics is built for the investigation and correlation work that starts after something gets flagged, or for environments where the threats you care about live outside what GuardDuty can even see.

The real answer: they're pipeline stages, not competitors

AWS's own guidance is unusually direct about this. From the AWS Security Blog's SIEM guide: "Although Security Hub has some similarities to security information and event management (SIEM) tools, it is not designed as a standalone SIEM replacement." The same post adds the mirror-image caveat for OpenSearch: "Although the OpenSearch Service also is not a SIEM out-of-the-box tool, with some customization, you can use it for SIEM tool use cases."

Read together, those two lines describe the architecture most security teams actually land on. GuardDuty detects. Security Hub aggregates those findings — along with findings from other AWS security services — into one place. Because Security Hub only holds findings for around 90 days and isn't meant for cross-source log correlation, teams export findings out via S3 and a Lambda-based ETL step, or stream them through EventBridge, into an OpenSearch domain. From there, OpenSearch (or Kibana/OpenSearch Dashboards on top of it) handles long-term retention past that 90-day window, correlation against non-AWS log sources, and the dashboards analysts actually live in during an investigation.

A minimal version of the EventBridge routing rule that kicks this off looks like:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"]
}

That rule targets a Lambda function that reshapes the finding and writes it into an OpenSearch index — or, more commonly today, targets Security Hub first, with a second export step moving aggregated findings from Security Hub into OpenSearch on a schedule. The point isn't the exact wiring; it's that GuardDuty findings become one input stream among several feeding a system built for the search and correlation GuardDuty was never designed to do.

A decision framework, not a coin flip

If your workloads are entirely on AWS, your team is small, and what you need is "tell me when something bad happens so I can go look" — run GuardDuty organization-wide and stop there. It costs nothing to operate beyond the per-GB analysis fee, and it will catch the categories of AWS-native threats it's tuned for without anyone maintaining rules.

If you're already running GuardDuty but keep hitting the wall where you need to search raw logs, correlate a finding against something GuardDuty doesn't ingest, or retain data longer than 90 days for compliance — that's the signal to add OpenSearch Security Analytics on top, not to replace GuardDuty with it.

If you have log sources GuardDuty structurally cannot see — on-prem firewalls, custom application audit logs, non-AWS network appliances, Windows domain controllers — you need OpenSearch Security Analytics regardless of what you decide about GuardDuty, because no amount of GuardDuty configuration will ever ingest those.

And if you're running a mid-size environment — think a fintech spread across 40 AWS accounts with a mix of cloud-native and legacy on-prem systems — you'll likely end up needing both feeding a shared pipeline: GuardDuty as the always-on detection layer for AWS-native threats, Security Hub as the aggregation point, and OpenSearch as the durable, searchable, cross-source system of record underneath it all.

Where to start

Turn on GuardDuty across your organization today if it isn't already running — it's the highest-value, lowest-effort step available, and there's no good reason to delay it. Treat OpenSearch Security Analytics as the next investment, not a parallel one: reach for it once you can name the specific gap GuardDuty leaves open, whether that's log sources it can't reach, retention past 90 days, or the ability to search raw events instead of just reading findings. Building the Security Hub-to-OpenSearch pipeline before you have that gap just means paying to run and maintain a cluster you don't yet need.

Send error event of an Lambda function to SNS Topic

Danh Hoang Hieu Nghi — Tue, 19 May 2026 07:16:08 +0000

AWS Lambda Async Failure Destination: Gửi lỗi Lambda sang Amazon SNS ErrorTopic

Khi làm việc với AWS Lambda asynchronous invocation, một vấn đề rất thường gặp là: function xử lý message bị lỗi, nhưng mình cần một nơi tập trung để nhận thông báo lỗi và debug nhanh.

Trong bài lab này, chúng ta sẽ dựng một flow đơn giản:

Amazon SNS InputTopic
        ↓
AWS Lambda ProcessMessages
        ↓ nếu xử lý thất bại
Amazon SNS ErrorTopic
        ↓
Email notification

Mục tiêu là cấu hình failure destination cho Lambda function ProcessMessages, để khi function xử lý message thất bại, Lambda tự động gửi failure record sang SNS topic ErrorTopic.

Bài toán cần giải quyết

Giả sử bạn có một Lambda function tên là ProcessMessages.

Function này được invoke asynchronously khi có message được publish vào Amazon SNS topic tên là InputTopic.

Yêu cầu đặt ra:

Khi Lambda ProcessMessages xử lý message thất bại, hệ thống phải gửi thông báo lỗi đến SNS topic ErrorTopic, sau đó SNS gửi email alert cho người quản trị.

Đây là một tình huống rất thực tế trong các hệ thống event-driven trên AWS. Thay vì để lỗi nằm im trong CloudWatch Logs, chúng ta muốn đẩy lỗi ra một kênh alert tập trung.

Vì sao dùng Lambda Failure Destination?

Với Lambda asynchronous invocation, caller không chờ Lambda xử lý xong để nhận kết quả ngay lập tức. Lambda nhận event, đưa vào hàng đợi nội bộ, rồi xử lý sau.

Nếu function lỗi, Lambda có thể retry. Khi event vẫn thất bại sau các lần retry, Lambda có thể gửi failure record đến một destination, ví dụ:

Amazon SNS topic
Amazon SQS queue
Lambda function khác
Amazon EventBridge

Trong bài lab này, chúng ta dùng Amazon SNS ErrorTopic làm failure destination.

Điểm quan trọng là:

SNS InputTopic không tự biết Lambda fail.
Lambda mới là nơi biết xử lý thành công hay thất bại.

Vì vậy, cách đúng là cấu hình Destination on failure trên Lambda, trỏ đến ErrorTopic.

Kiến trúc lab

Trong lab này, chúng ta sẽ tạo và cấu hình các thành phần sau:

Tạo SNS topic InputTopic
Tạo SNS topic ErrorTopic
Subscribe email vào ErrorTopic
Tạo Lambda function ProcessMessages
Gắn InputTopic làm trigger cho Lambda
Viết code Lambda cố tình throw error
Cấu hình Lambda async failure destination trỏ về ErrorTopic
Publish message vào InputTopic
Kiểm tra email alert từ ErrorTopic

Hands-on Lab bằng AWS Console

Phần này dùng AWS Console để thao tác trực tiếp. Bạn có thể làm nhanh trong tài khoản AWS cá nhân.

Bước 1: Tạo SNS topic InputTopic

Vào AWS Console, mở dịch vụ Amazon SNS.

Đi theo đường dẫn:

Amazon SNS → Topics → Create topic

Chọn cấu hình:

Type: Standard
Name: InputTopic

Sau đó bấm:

Create topic

Sau khi tạo xong, lưu lại ARN của topic. Ví dụ:

arn:aws:sns:ap-southeast-1:123456789012:InputTopic

Bước 2: Tạo SNS topic ErrorTopic

Tiếp tục tạo topic thứ hai để nhận failure notification.

Vào:

Amazon SNS → Topics → Create topic

Chọn:

Type: Standard
Name: ErrorTopic

Bấm:

Create topic

ErrorTopic sẽ là nơi nhận failure record từ Lambda khi ProcessMessages xử lý message thất bại.

Bước 3: Subscribe email vào ErrorTopic

Vào topic ErrorTopic, chọn:

Subscriptions → Create subscription

Cấu hình subscription:

Protocol: Email
Endpoint: email của bạn

Ví dụ:

hieunghiwork123@gmail.com

Sau đó bấm:

Create subscription

Sau khi tạo subscription, mở hộp thư email và bấm Confirm subscription.

Lưu ý: email xác nhận có thể nằm trong thư mục Spam hoặc Promotions. Nếu subscription chưa được confirm, SNS sẽ không gửi email alert cho bạn.

Bước 4: Tạo Lambda function ProcessMessages

Vào AWS Lambda:

AWS Lambda → Functions → Create function

Chọn:

Author from scratch
Function name: ProcessMessages
Runtime: Python 3.12
Architecture: x86_64

Sau đó bấm:

Create function

Bước 5: Viết code Lambda cố tình fail

Để test failure destination, chúng ta sẽ viết Lambda luôn throw exception.

Trong Lambda code editor, thay code bằng:

import json

def lambda_handler(event, context):
    print("Received event:")
    print(json.dumps(event))

    # Giả lập xử lý message thất bại
    raise Exception("Simulated processing failure from ProcessMessages")

Sau đó bấm:

Deploy

Ý nghĩa của đoạn code này:

Lambda nhận event từ InputTopic
In event ra CloudWatch Logs
Cố tình throw exception
Lambda async invocation retry
Khi retry thất bại hết, Lambda gửi failure record sang ErrorTopic

Đây là cách test đơn giản để kiểm tra cơ chế Lambda async failure destination.

Bước 6: Gắn InputTopic làm trigger cho Lambda

Trong Lambda ProcessMessages, vào tab:

Configuration → Triggers → Add trigger

Chọn:

Source: SNS
SNS topic: InputTopic

Sau đó bấm:

Add

Lúc này flow đầu vào đã có:

InputTopic → ProcessMessages

Từ giờ, mỗi khi bạn publish message vào InputTopic, SNS sẽ invoke Lambda ProcessMessages.

Bước 7: Cấu hình Failure Destination cho Lambda

Đây là phần quan trọng nhất của lab.

Trong Lambda ProcessMessages, vào:

Configuration → Destinations → Add destination

Chọn:

Source: Asynchronous invocation
Condition: On failure
Destination type: SNS topic
Destination: ErrorTopic

Hoặc nếu giao diện AWS Console của bạn hiển thị theo cách khác, có thể đi theo đường dẫn:

Configuration → Asynchronous invocation → Edit
Destination on failure → SNS topic → ErrorTopic

Sau đó bấm:

Save

Sau bước này, khi Lambda xử lý event thất bại sau các lần retry, Lambda sẽ gửi failure record sang SNS topic ErrorTopic.

Bước 8: Kiểm tra IAM permission

Để Lambda gửi được message sang SNS topic ErrorTopic, execution role của Lambda cần quyền sns:Publish.

Policy tối thiểu có dạng:

{
  "Effect": "Allow",
  "Action": "sns:Publish",
  "Resource": "arn:aws:sns:REGION:ACCOUNT_ID:ErrorTopic"
}

Ví dụ:

{
  "Effect": "Allow",
  "Action": "sns:Publish",
  "Resource": "arn:aws:sns:ap-southeast-1:123456789012:ErrorTopic"
}

Nếu thiếu quyền này, Lambda có thể xử lý fail đúng như mong đợi nhưng không gửi được failure record sang ErrorTopic.

Khi debug, bạn có thể kiểm tra metric:

DestinationDeliveryFailures

Nếu metric này tăng, thường là do permission, ARN, region hoặc destination config có vấn đề.

Bước 9: Publish message vào InputTopic để test

Vào SNS topic InputTopic, chọn:

Publish message

Nhập subject:

Test Lambda Failure

Nhập message body:

{
  "orderId": "12345",
  "action": "process"
}

Sau đó bấm:

Publish message

Khi đó flow sẽ chạy như sau:

InputTopic nhận message
→ SNS invoke Lambda ProcessMessages
→ Lambda throw exception
→ Lambda retry async invocation
→ Sau khi fail hết retry
→ Lambda gửi failure record sang ErrorTopic
→ ErrorTopic gửi email alert

Bước 10: Kiểm tra CloudWatch Logs

Vào CloudWatch:

CloudWatch → Log groups

Tìm log group:

/aws/lambda/ProcessMessages

Bạn sẽ thấy log tương tự:

Received event:
...
Exception: Simulated processing failure from ProcessMessages

Điều này chứng minh Lambda đã nhận event từ SNS nhưng xử lý thất bại.

Bước 11: Kiểm tra email từ ErrorTopic

Sau một lúc, bạn sẽ nhận được email từ SNS ErrorTopic.

Nội dung email thường chứa failure record từ Lambda. Một số field quan trọng gồm:

Field	Ý nghĩa
`requestContext`	Thông tin về request Lambda async invocation
`condition`	Lý do event được gửi sang failure destination
`approximateInvokeCount`	Số lần Lambda đã cố invoke event
`requestPayload`	Event gốc được gửi vào Lambda
`responseContext`	Thông tin response sau khi Lambda xử lý
`functionError`	Loại lỗi của function
`responsePayload`	Error message và stack trace

Ví dụ khi bạn thấy:

{
  "condition": "RetriesExhausted",
  "approximateInvokeCount": 3,
  "functionError": "Unhandled"
}

Điều này nghĩa là Lambda đã xử lý thất bại sau toàn bộ retry attempts. Mặc định, bạn có thể thấy tổng cộng khoảng 3 lần invoke: 1 lần đầu và 2 lần retry.

Vì sao email alert có thể đến hơi chậm?

Đây là điểm rất dễ gây nhầm khi mới làm lab.

Với asynchronous invocation, Lambda không gửi failure record sang destination ngay sau lần fail đầu tiên. Lambda sẽ retry trước. Khi event fail hết các lần retry, lúc đó Lambda mới gửi record sang ErrorTopic.

Vì vậy nếu bạn thấy Lambda được invoke 2 lần nhưng chưa nhận mail, có thể đơn giản là Lambda chưa retry hết.

Nếu muốn test nhanh hơn, có thể chỉnh:

Lambda → Configuration → Asynchronous invocation → Edit
Retry attempts: 0

Sau đó publish message mới vào InputTopic. Khi retry attempts là 0, failure destination sẽ được kích hoạt nhanh hơn.

Vì sao đây là đáp án đúng trong AWS Exam?

Câu hỏi AWS exam thường đưa ra tình huống:

Lambda được invoke asynchronously
Lambda xử lý message thất bại
Cần gửi notification đến SNS topic
Có sẵn ErrorTopic để nhận lỗi

Trong trường hợp này, giải pháp đúng là:

Configure a failure destination for the Lambda function.
Specify the ARN of the ErrorTopic SNS topic as the destination ARN.

Lý do: failure destination là cơ chế native của Lambda dành cho asynchronous invocation failure.

Vì sao không dùng SNS filter policy?

Một nhầm lẫn phổ biến là nghĩ rằng có thể dùng SNS filter policy để bắt lỗi Lambda.

Thực tế, SNS filter policy chỉ lọc message đã được publish vào SNS topic trước khi gửi đến subscriber. Nó không tự biết Lambda function xử lý thành công hay thất bại.

Flow sai sẽ là:

ErrorTopic → ProcessMessages

Trong khi yêu cầu đúng là:

ProcessMessages fail → ErrorTopic

Vì vậy, không dùng SNS filter policy cho bài toán này.

Vì sao không dùng SNS delivery policy?

SNS delivery policy dùng để kiểm soát cách SNS retry khi gửi message đến subscriber. Nó không phải cơ chế để Lambda báo lỗi xử lý message.

Nói ngắn gọn:

SNS delivery policy = SNS gửi message ra subscriber như thế nào
Lambda failure destination = Lambda fail thì gửi failure record đi đâu

Bài này cần cơ chế thứ hai.

Dọn dẹp tài nguyên sau lab

Sau khi test xong, bạn nên xóa các resource sau để tránh phát sinh chi phí hoặc làm rối tài khoản AWS:

Lambda function: ProcessMessages
SNS topic: InputTopic
SNS topic: ErrorTopic
CloudWatch log group: /aws/lambda/ProcessMessages

Nếu không cần giữ log, vào CloudWatch và xóa log group tương ứng.

Tổng kết

Trong bài lab này, chúng ta đã cấu hình thành công flow:

SNS InputTopic
        ↓
Lambda ProcessMessages
        ↓ On failure destination
SNS ErrorTopic
        ↓
Email notification

Đây là một pattern rất hữu ích khi xây dựng hệ thống event-driven trên AWS. Thay vì chỉ xem lỗi trong CloudWatch Logs, bạn có thể đẩy failure record sang SNS để gửi email, tích hợp với hệ thống alert, hoặc fan-out sang nhiều subscriber khác.

Keyword cần nhớ cho AWS Exam:

Lambda asynchronous invocation
Failure destination
Destination on failure
SNS ErrorTopic
RetriesExhausted

Khi đề bài nói Lambda async invocation thất bại và cần gửi thông báo sang SNS topic, hãy nghĩ ngay đến:

Lambda async failure destination

Triển Khai nhiều Static Websites trên AWS với nhiều môi trường bằng AWS Amplify

Danh Hoang Hieu Nghi — Mon, 18 May 2026 14:07:32 +0000

Khi một công ty cần triển khai và duy trì nhiều static websites trên AWS, bài toán thường không chỉ là “host website ở đâu”, mà còn là:

Source code nằm ở nhiều hệ thống khác nhau như AWS CodeCommit, GitHub, Bitbucket
Có nhiều môi trường release: Development, Staging, UAT, Production
Mỗi môi trường phải tự động deploy khi merge code vào branch tương ứng
Toàn bộ traffic phải dùng HTTPS
Giải pháp phải serverless
Không được yêu cầu server chạy liên tục
Chi phí vận hành phải thấp nhất

Trong trường hợp này, lựa chọn phù hợp nhất là:

AWS Amplify Hosting

Bài toán kiến trúc

Giả sử công ty có nhiều website tĩnh:

Website A
Website B
Website C

Source code của các website này có thể nằm ở nhiều nơi:

AWS CodeCommit
GitHub
Bitbucket

Mỗi repository lại có các branch tương ứng với từng môi trường:

dev          → Development
staging      → Staging
uat          → User Acceptance Testing
production   → Production

Yêu cầu là khi developer merge code vào branch nào, website ở môi trường tương ứng phải được deploy tự động.

Ví dụ:

Merge vào dev branch        → Deploy Development
Merge vào staging branch    → Deploy Staging
Merge vào uat branch        → Deploy UAT
Merge vào production branch → Deploy Production

Kiến trúc tổng quan

Flow triển khai có thể hiểu như sau:

Source Code Repository
        ↓
Git Branch Merge
        ↓
AWS Amplify Hosting
        ↓
Automatic Build & Deploy
        ↓
Environment-specific Static Website
        ↓
HTTPS Access

AWS Amplify đóng vai trò là dịch vụ managed hosting cho static websites và frontend apps. Nó có thể kết nối trực tiếp với Git repositories, theo dõi branch, tự động build và deploy khi có thay đổi.

Vì sao dùng AWS Amplify?

AWS Amplify Hosting phù hợp vì nó giải quyết trực tiếp các yêu cầu chính của bài toán.

1. Hỗ trợ nhiều Git providers

Amplify có thể kết nối với các hệ thống source control phổ biến như:

AWS CodeCommit
GitHub
Bitbucket

Điều này giúp công ty không cần phải chuẩn hóa toàn bộ source code về một nơi duy nhất. Website nào đang ở GitHub thì vẫn giữ ở GitHub. Website nào đang ở Bitbucket thì vẫn có thể deploy được.

2. Branch-based deployment

Đây là điểm quan trọng nhất của bài toán.

Với AWS Amplify, mỗi branch có thể được map với một environment riêng.

Ví dụ:

Git Branch	AWS Environment	URL
dev	Development	dev.example.com
staging	Staging	staging.example.com
uat	User Acceptance Testing	uat.example.com
production	Production	www.example.com

Khi code được merge vào branch tương ứng, Amplify sẽ tự động trigger build và deploy.

dev branch merge
        ↓
Development deployment

production branch merge
        ↓
Production deployment

Không cần tự viết pipeline phức tạp cho từng môi trường.

3. Serverless static website hosting

Một yêu cầu quan trọng khác là:

Không được có server chạy liên tục.

Amplify Hosting là managed service. Bạn không cần tạo EC2 instance, không cần patch server, không cần quản lý web server như Nginx hay Apache.

Điều này giúp loại bỏ các thành phần vận hành như:

EC2 instances
Load balancers tự quản lý
Web servers chạy liên tục
Manual deployment scripts
Server patching

Thay vào đó, Amplify quản lý hosting, build, deployment và delivery cho bạn.

4. HTTPS được hỗ trợ sẵn

Bài toán yêu cầu:

All data exchange must use HTTPS.

AWS Amplify Hosting hỗ trợ HTTPS cho website được deploy. Khi gắn custom domain, Amplify cũng có thể xử lý SSL/TLS certificate để website được truy cập an toàn qua HTTPS.

Ví dụ:

https://dev.example.com
https://staging.example.com
https://uat.example.com
https://www.example.com

Người dùng cuối truy cập website qua browser với HTTPS lock icon, đảm bảo traffic được mã hóa.

5. Least operational overhead

Nếu nhìn theo góc độ AWS Solutions Architect exam, cụm từ quan trọng nhất trong đề thường là:

LEAST operational overhead

Điều này nghĩa là giải pháp không chỉ “chạy được”, mà phải là giải pháp cần ít cấu hình, ít vận hành, ít bảo trì nhất.

AWS Amplify phù hợp vì:

Connect trực tiếp với Git repository
Tự detect branch merge
Tự build
Tự deploy
Tự host static website
Có HTTPS
Không cần server chạy liên tục

Đây là một giải pháp managed và serverless, nên operational overhead thấp hơn nhiều so với việc tự lắp ghép nhiều dịch vụ riêng lẻ.

So sánh với các lựa chọn khác

Elastic Beanstalk

Elastic Beanstalk phù hợp hơn cho application backend hoặc web application cần runtime server.

Với static websites đơn giản, dùng Elastic Beanstalk là không tối ưu vì vẫn có nhiều operational overhead hơn.

Bạn sẽ phải quan tâm nhiều hơn đến môi trường chạy ứng dụng, scaling, platform, instance, deployment configuration.

Elastic Beanstalk = chạy được, nhưng không lý tưởng cho static sites đơn giản

S3 + CodePipeline + CodeBuild

S3 static website hosting kết hợp với CodePipeline và CodeBuild cũng có thể triển khai được.

Tuy nhiên, bạn sẽ phải tự cấu hình nhiều thứ hơn:

S3 bucket cho từng environment
CodePipeline cho từng branch
CodeBuild project
IAM roles
Artifact flow
CloudFront nếu cần HTTPS với custom domain
Invalidation logic nếu dùng CDN

Giải pháp này có thể đúng về mặt kỹ thuật, nhưng không phải lựa chọn có least operational overhead.

S3 + CodePipeline + CodeBuild = works, but more setup

EC2

EC2 là lựa chọn kém nhất cho bài toán này.

Vì EC2 yêu cầu server chạy liên tục, trái ngược hoàn toàn với yêu cầu:

No continuously running servers

Ngoài ra, dùng EC2 để host static websites sẽ kéo theo nhiều công việc vận hành:

Provision server
Install web server
Patch OS
Configure HTTPS
Monitor instance
Handle scaling
Manage availability

Đây là operational overhead cao nhất.

Kiến trúc đề xuất

Một kiến trúc hợp lý sẽ như sau:

AWS CodeCommit / GitHub / Bitbucket
        ↓
Branch merge event
        ↓
AWS Amplify Hosting
        ↓
Automatic build and deployment
        ↓
Development / Staging / UAT / Production
        ↓
HTTPS static websites

Mỗi website có thể có các environment riêng:

Website A
├── dev.example.com
├── staging.example.com
├── uat.example.com
└── www.example.com

Website B
├── dev.website-b.com
├── staging.website-b.com
├── uat.website-b.com
└── www.website-b.com

Mapping branch với environment

Một cách triển khai thường gặp:

Branch	Environment	Purpose
dev	Development	Developer testing
staging	Staging	Pre-release validation
uat	User Acceptance Testing	Business/user approval
production	Production	Live website

Khi team merge code vào staging, Amplify tự động deploy bản staging.

Khi release đã được approve, team merge vào production, Amplify tự động deploy bản production.

Key exam takeaway

Trong AWS exam, khi thấy các keyword sau:

Static websites
Multiple Git providers
Branch-based deployment
Development / Staging / UAT / Production
HTTPS
Serverless
No continuously running servers
Least operational overhead

Hãy nghĩ ngay đến:

AWS Amplify Hosting

Kết luận

AWS Amplify Hosting là lựa chọn phù hợp nhất cho bài toán deploy nhiều static websites trên AWS với nhiều môi trường release.

Nó hỗ trợ trực tiếp các yêu cầu quan trọng:

✅ Static website hosting
✅ Kết nối với CodeCommit, GitHub, Bitbucket
✅ Branch-based deployments
✅ Tự động build và deploy khi merge code
✅ HTTPS enabled
✅ Serverless
✅ Không cần EC2
✅ Không có always-on servers
✅ Least operational overhead

Với bài toán này, giải pháp tốt nhất là:

Host each website by using AWS Amplify Hosting, connect repository branches to the corresponding environments, and trigger deployments automatically when code is merged into each branch.

View Quick Chat History with CloudWatch Logs Group

Danh Hoang Hieu Nghi — Tue, 14 Apr 2026 06:30:11 +0000

In this blog, we will configure a CloudWatch Log Group to receive chat history from Quick Chat Agents based on Quick User or Agent ID.

Prerequisites

Python 3.10+
AWS CLI
Quick Account/User
Ensure your IAM user/role has the permission:
- quicksight:AllowVendedLogDeliveryForResource on resource:
- arn:aws:quicksight:us-east-1:account_id:account/account_id

Example

My Quick resource ARN:

arn:aws:quicksight:us-east-1:123412341234:account/123412341234

Create Delivery Source

Go to Cloud Watch service and click on Log Management on 'Logs" section and create a log group name "nghi-danh-test-quick-history-chat"

Next step, open AWS CloudShell to perform "configure delivery sources - delivery destination,.."

Create Delivery Source of QuickSuite:

aws logs put-delivery-source   --region us-east-1 --name quick-chat-source-nghi-danh  --resource-arn arn:aws:quicksight:us-east-1:account_id:account/account_id --log-type CHAT_LOGS

Create Delivery Destination:

aws logs put-delivery-destination \
  --region us-east-1 \
  --name quick-chat-destination-nghi-danh \
  --delivery-destination-type CWL \
  --output-format json \
  --delivery-destination-configuration destinationResourceArn="arn:aws:logs:us-east-1:account_id:log-group:nghi-danh-test-quick-history-chat:*"

Connect source and destination:

aws logs create-delivery \
  --region us-east-1 \
  --delivery-source-name quick-chat-source-nghi-danh \
  --delivery-destination-arn arn:aws:logs:us-east-1:account_id:delivery-destination:quick-chat-destination-nghi-danh \
  --record-fields resource_arn event_timestamp logType accountId user_arn user_type namespace status_code conversation_id system_message_id latency time_to_first_token message_scope user_message_id user_message agent_id flow_id system_text_message surface_type web_search user_selected_resources action_connectors cited_resource file_attachment

After few minutes, it will appear on Log Stream "QUICK_SUITE_CHAT_LOGS"

ihatesea69 / evaluation-amazon-quick-suite

Amazon Quick chat export CLI

Amazon Quick Chat Export

Simple Python script to export Amazon Quick CHAT_LOGS conversations from CloudWatch Logs Insights to CSV.

Requirements

Python 3.10+
AWS credentials with access to
- logs:DescribeLogGroups
- logs:StartQuery
- logs:GetQueryResults
- sts:GetCallerIdentity
- quicksight:ListUsers when using --quick-user

Files

download_quick_conversations.py: main CLI script
tests/test_download_quick_conversations.py: unit and stubbed integration tests

Usage

Export chat rows to CSV:

python download_quick_conversations.py `
  --region us-east-1 `
  --log-group "your-log-group" `
  --start 2026-04-01T00:00:00Z `
  --end 2026-04-02T00:00:00Z `
  --quick-user "user@example.com" `
  --output quick_chat_logs.csv

List distinct agent_id values only:

python download_quick_conversations.py `
  --region us-east-1 `
  --log-group "your-log-group" `
  --start 2026-04-01T00:00:00Z `
  --end 2026-04-02T00:00:00Z `
  --quick

…

View on GitHub

Use this github repo to download the the content to csv files

References Link AWS Doc

docs.aws.amazon.com

I need to learn CNN

Danh Hoang Hieu Nghi — Mon, 23 Mar 2026 13:48:01 +0000

I need to learn CNN for my School Project presentation.
The blogs will split into 3 parts:

High-level overview (non-coder/non-tech background)
Detail how CNN work? (with visualization website)
Python coding example with Pytorch / Tensorflow

1. High-level overview

One of the most impressive forms of ANN architecture is
that of the Convolutional Neural Network (CNN). CNNs are primarily used to solve difficult image-driven pattern recognition tasks and with their precise yet simple architecture, offers a simplified method of getting started with ANNs.
Abstraction- An Introduction to Convolutional Neural Networks paper - For the rest of this blogs, i will try to simplify this paper and summary paragraphs and connect ideas.

Simplify this abstraction: CNN is a "better type" of ANN for image pattern recognition

Keywords: Pattern recognition, artificial neural networks, machine learning, image analysis.

Introduction

Artificial Neural Networks (ANNs) mimic human brain - nervous systems operate. ANNs comprised of interconnected computational nodes (neurons) - Learn from the input in order to optimise its final output

of a input layer, a hidden layer and an output layer. This structure is the basis
of a number of common ANN architectures" width="568" height="373">

Load the input (multidimensional vector) fed the data to -> hidden layers. Then hidden layers make decisions from previous layer and weigh up how a stochastic (randomly) change within itself detriments (decrease) or improve the final output This called learning.

If many of hidden stacked upon each-order -> deep learning

SimpleMem - Lifelong Memory for Agents

Danh Hoang Hieu Nghi — Sun, 08 Mar 2026 16:38:18 +0000

I read and summarize research paper so you don't have to. Use the most simple language ever. (Not some IELTS 8.0+ vocabulary words).

Overview: This framework can use to Store, compress, retrieve long-term memories with semantic lossless compression.

Works across all MCP Client for example:

Claude Desktop
Cursor
LM Studio
PyPi Package
Any MCP Client.

SimpleMem is an efficient memory framework based on semantic lossless compression that addresses the fundamental challenge of efficient long-term memory for LLM agents. Unlike existing systems that either passively accumulate redundant context or rely on expensive iterative reasoning loops, SimpleMem maximizes information density and token utilization through a three-stage pipeline:

Instead of storing un-necessary context, SimpleMem maximize information density and token utilization through a 3-stage pipeline:

The SimpleMem Architecture

Stage 1 Semantic Structured Compression

Semantic structured compression: Distills unstructured interactions into compact, multi-view indexed memory units. Filters low-utility dialogue and coverts informative windows into compact, context-independent.

In simple words that this step will filter out "less valuable information" and only keep "important information", and then converts into short - meaningful memory units that can be re-use later context-independent.

(1) Sliding windows -> (2) Sematic Density Gating -> (3) Memory Units

(1) Sliding windows: Instead of processing the wholes conversation at once, SimpleMem splits it into small overlapping windows of dialogue. Each window contains a short local span of interaction.

*(2): Semantic Density Gating *(Information Filter): the model checks whether a window contains high-value semantic content or not. If the window is mostly noise, it is discarded, if it contains useful information, the system keeps and extracts it.

For example:

Noise = "That's cool bro", "keep it going",..
Information = "I prefer OOP over Functional programming"

(3): Convert into memory units

SimpleMem rewrites useful content into compact memory units.
This transformation includes:

Coreference resolution: Replace value references like "she", "it",.. with explicit entities.
Temporal normalization: converting relative time phrases like "yesterday" or "last week" into timestamps.
Fact atomization: turning messy dialogue into short, self-contained factual statements

Simple example

Raw dialogue:

“Yesterday I took my kids to the museum.”
“They loved the dinosaur exhibit.”
“Yeah, that sounds fun.”
“My daughter turns 8 next month.”

After Step 1, possible memory units:

[2023-07-12] Sarah took her kids to the Natural History Museum.
Sarah's kids loved the dinosaur exhibit.
Sarah's daughter turns 8 in August 2023.

One-line summary: Step 1 breaks dialogue into small windows, filters out low-value parts, and compresses useful content into clean, self-contained memory units.

Stage 2 Online Semantic Synthesis

Intra-session process that instantly integrates related context into unified abstract representations to eliminate redundancy

After Stage 1 extracts small memory units or facts, Stage 2 looks at related facts within the same session and merges them into unified abstract representations so the system does not store many fragmented pieces that mean nearly the same thing.

“Online” does not mean internet-based.
It means the synthesis happens during memory writing, in real time. SimpleMem does not wait for a later background cleanup step; it performs synthesis on-the-fly during the write phase.

What does “semantic synthesis” mean?

It means the model combines pieces of information based on meaning, not just surface wording.
If several extracted facts refer to the same preference, event, or topic, the system rewrites them into one denser and more coherent memory entry.

The paper’s example is:

“User wants coffee”
“User prefers oat milk”
“User likes it hot”

which gets consolidated into:

“User prefers hot coffee with oat milk.”

Without Stage 2, semantically related facts accumulate as fragmented entries. Then, at retrieval time, the system must gather and assemble scattered evidence

In one line:

Stage 1 = clean and extract
Stage 2 = consolidate and abstract

Step 3 Intent-Aware Retrieval Planning

Intent-Aware Retrieval Planning decides:

What to retrieve?
How much to retrieve?
From which retrieval views? When a new query arrives. Instead of always fetching a fixed number of memories, SimpleMem first infers the latent search intent of the query, then adapts the retrieval scope and retrieval depth accordingly. This helps avoid both under-retrieval for complex questions and token waste for simple ones.

What does “intent-aware” mean?

It means the system tries to understand whether the user is asking for:

a simple factual lookup,
a multi-hop reasoning query,
a temporally constrained question,
or something involving entities, preferences, or metadata. Based on that, the planner generates a structured retrieval plan:

qsem for semantic retrieval
qlex for lexical retrieval
qsym for symbolic retrieval

d for adaptive retrieval depth

Once the plan is created, SimpleMem performs parallel multi-view retrieval over three complementary indexes:

Semantic layer for conceptual similarity
Lexical layer for exact keywords and rare proper nouns
Symbolic layer for structured metadata constraints such as time or entity type.

Then it merges the results with a set union and naturally deduplicates overlapping entries, producing a context that is both compact and comprehensive.

What does “determine retrieval scope” mean?
It means deciding:

How many memory entries to fetch?
How broad the search should be?
Which retrieval paths matter most?

In the paper, the inferred depth d reflects query complexity, and the system uses a candidate limit n proportional to d. So:

simple query → shallow retrieval
complex query → deeper retrieval.

What does “construct precise context efficiently” mean?
It means building a small but highly relevant context for answer generation instead of dumping raw history into the prompt. The paper describes this as querying multiple indexes and combining their outputs through ID-based deduplication, which balances semantic relevance and structural constraints while remaining token-efficient.

Simple example
If the query is:

“What paintings has Sarah created?”

the system recognizes that it should retrieve memories related to painting/art, then searches across semantic, lexical, and symbolic indexes. In the paper’s example, the final retrieved content includes memories such as:

sunset with palm trees
horse portrait(instead of dragging in irrelevant memories like camping)

How is it different from Stage 2?

Stage 2 consolidates related memories during writing
Stage 3 selects the right memories during retrieval for answering a query.

One-line summary

Stage 3 understands what the user is really looking for, plans the right retrieval strategy, searches across multiple memory views, and builds a compact, accurate context for answering.

Its main idea is: instead of saving the full conversation history, it saves only the most useful information in a cleaner and shorter form. This helps the model remember important things for a long time without wasting too many tokens.

U-Net - CNN for Image Segmentation

Danh Hoang Hieu Nghi — Sat, 07 Mar 2026 12:43:11 +0000

This support for the this post:TransUnet

References Link:

U-Net is a convolutional neural network that was developed for image segmentation. The network is based on a fully convolutional neural network whose architecture was modified and extended to work with fewer training images and to yield more precise segmentation. Segmentation of a 512 × 512 image takes less than a second on a modern (2015) GPU using the U-Net architecture.

View on Wikipedia>

aivietnam.edu.vn

U-net : Kiến trúc mạnh mẽ cho Segmentation

1. Segmentation! Segmentation! Đôi chút về Image Processing trong Deep Learning Với Deep Learning (hay Neural Network), máy tính ngày càng có khả năng quan sát và xử lí những hình ảnh phức tạp ở nhiều...

viblo.asia

I read this paper for my graduation project (TransUnet)

Danh Hoang Hieu Nghi — Sat, 07 Mar 2026 12:42:23 +0000

Link paper: [TransUNet]: Transformers Make Strong
Encoders for Medical Image Segmentation(https://arxiv.org/pdf/2102.04306)

Field-Level Encryption in Amazon CloudFront

Danh Hoang Hieu Nghi — Fri, 13 Feb 2026 07:50:23 +0000

Field-Level Encryption in Amazon CloudFront

1. Introduction

Field-Level Encryption (FLE) is a security feature provided by

Amazon Web Services (AWS)

and implemented in

Amazon CloudFront.

It allows you to encrypt specific sensitive fields in an HTTP request instead of encrypting only the entire connection via HTTPS.

This ensures that sensitive data remains encrypted even when it travels through multiple backend components.

2. The Security Problem

HTTPS provides:

Encryption in transit
Protection against man-in-the-middle attacks

However:

Once the request reaches the backend, data is decrypted.
In multi-tier architectures (ALB, EC2, Lambda, microservices), sensitive data may be exposed internally.

Field-Level Encryption solves this by:

Encrypting only selected fields (e.g., credit card numbers).
Keeping those fields encrypted until they reach the trusted backend system with the private key.

3. How It Works

Step 1 – Client Sends Request

A user submits an HTTPS POST request containing:

name
email
credit_card_number (sensitive field)

Step 2 – Encryption at CloudFront Edge

At the CloudFront Edge Location:

CloudFront uses an RSA public key.
Only the configured sensitive field (e.g., credit_card_number) is encrypted.
Other fields remain unchanged.

Step 3 – Request Sent to Origin

The origin server receives:

name → readable
email → readable
credit_card_number → encrypted (ciphertext)

Step 4 – Decryption at Backend

The backend application:

Uses the corresponding private key
Decrypts the encrypted field
Processes the data securely

4. Key Components

Public Key
- Uploaded to CloudFront
- Used to encrypt sensitive fields
Private Key
- Stored securely at the backend
- Used to decrypt encrypted fields
Field-Level Encryption Profile
- Defines which fields must be encrypted
Field-Level Encryption Configuration
- Attached to a CloudFront distribution behavior

5. HTTPS vs Field-Level Encryption

Feature	HTTPS	Field-Level Encryption
Encrypts data in transit	Yes	Yes
Encrypts specific fields	No	Yes
Protects sensitive data across backend layers	No	Yes
Uses asymmetric encryption (RSA)	No	Yes

6. When to Use It

Online payment systems (PCI DSS compliance)
Applications collecting personal identifiable information (PII)
Multi-tier or microservices architectures
Systems requiring strict decryption access control

7. Summary

Field-Level Encryption in Amazon CloudFront:

Encrypts specific fields in HTTP requests.
Performs encryption at the Edge Location.
Ensures only trusted systems with the private key can decrypt data.
Provides stronger protection for sensitive data compared to HTTPS alone.

It is especially useful for financial systems and applications handling highly sensitive user data.

Designing Serverless Applications at Massive Scale with AWS Lambda and RDS Proxy

Danh Hoang Hieu Nghi — Thu, 12 Feb 2026 06:29:03 +0000

I love serverless architecture because i can build scalable systems without managing any infra or server, however for scaling some "provisioning" services like RDS is quite difficult.

This blogs will have you take a look at how to design and scale an serverless architecture with AWS RDS Proxy and AWS Lambda

1. Problem: The Hidden Scaling Problem

AWS Lambda can scale horizontally to thousands of concurrent executions within seconds.

But relational databases (MySQL/PostgreSQL on Amazon RDS or Aurora) have hard limits:

Limited number of concurrent connections
Each connection consumes memory and CPU
Opening/closing connections is expensive

If every Lambda invocation creates a new database connection, high concurrency can quickly exhaust the database’s max_connections limit.

The result:

Connection errors
Increased latency
Database instability

This is the core scaling bottleneck in serverless architecture

2. Solution: Amazon RDS Proxy

What Is RDS Proxy?

Amazon RDS Proxy is a managed database proxy that sits between your Lambda functions and your RDS database.

Instead of:

We should use:

Why RDS Proxy?

The main purpose is connection pooling and connection reuse.

Without proxy:

Each Lambda instance opens its own DB connection.
Thousands of Lambdas = thousands of connections.

With RDS Proxy:

Proxy maintains a pool of persistent connections to the database.
Lambda connects to the proxy endpoint.
Proxy reuses existing DB connections.

This dramatically reduces:

Database memory usage
CPU overhead
Connection storms during traffic spikes

How RDS Proxy Works Internally

There are two authentication layers:

Lambda → RDS Proxy

Lambda authenticates using either:

Username/password
IAM database authentication (recommended)

With IAM authentication:

Lambda generates a temporary auth token.
Token is valid for ~15 minutes.
No password is stored in code.
IAM policies control access.

RDS Proxy → Database

RDS Proxy retrieves database credentials from AWS Secrets Manager.

Flow:

You store DB credentials in Secrets Manager.
RDS Proxy is configured to use that secret.
Proxy establishes and maintains pooled connections to the database.

Lambda never needs the real database password when using IAM auth.

Full Authentication Flow

Removes hardcoded credentials
Enables password rotation
Improves security posture
Supports massive concurrency

3. Designing Serverless Apps for Massive Scale

Scaling Lambda is automatic.

Scaling everything else is your responsibility.

The most common architectural mistake is:

Under heavy load:

Lambda scales
Database becomes overwhelmed
System fails

The Right Pattern: Decoupled and Asynchronous

Instead of tight synchronous chains, use buffering and **event-driven **design:

SQS absorbs traffic spikes
Lambda processes messages in controlled batches
Database load becomes predictable
System becomes resilient

Key design principles:

Decouple services
Use asynchronous processing
Avoid direct scaling pressure on databases
Design for backpressure handling

4. Understanding Lambda Invocation Models

Choosing how Lambda is invoked affects performance and reliability.

AWS Lambda supports three invocation types.

Synchronous Invocation

Caller waits for response.

Examples:

API Gateway
Application Load Balancer

Characteristics:

Immediate execution
Caller handles retry
Suitable for request/response APIs

Use when:

Low latency response is required
User-facing APIs

Asynchronous Invocation

Caller sends event and does not wait.

Examples:

Characteristics:

Event is queued internally
Lambda retries automatically
Better for background tasks

Use when:

Event-driven processing
Non-blocking workflows

Poll-Based Invocation (Event Source Mapping)

Lambda polls a data source.

Examples:

SQS
Kinesis
DynamoDB Streams

Characteristics:

Batch processing
Controlled concurrency
Ideal for high-throughput workloads

This model is critical when designing for massive scale.

5. Putting Everything Together: A Production-Grade Architecture

Here is a scalable, secure serverless design:

Security:

Database credentials stored in Secrets Manager
Lambda authenticates via IAM
RDS Proxy manages pooled connections

Scalability:

SQS absorbs spikes
Lambda scales safely
RDS Proxy protects database
Aurora handles transactional workload

Reliability:

Automatic retries
Dead-letter queues
Backpressure handling

6. When Should You Use RDS Proxy?

Use RDS Proxy when:

You use Lambda with RDS/Aurora
You expect unpredictable traffic spikes
You need secure IAM-based DB authentication
You want connection pooling without managing it manually

Do not rely on direct Lambda-to-RDS connections in high-scale production systems.

7. Final Takeaways

Serverless scaling is easy for compute.

It is difficult for:

Databases
Stateful systems
Downstream dependencies

To design correctly:

Use asynchronous patterns where possible.
Protect relational databases with RDS Proxy.
Use IAM authentication instead of hardcoded credentials.
Understand Lambda invocation types before designing workflows.
Always design for backpressure and burst traffic.

Serverless is powerful — but only when architecture decisions support massive scale.

References:

Securing Sensitive S3 Data: The Problem & The Solution

Danh Hoang Hieu Nghi — Wed, 04 Feb 2026 07:56:20 +0000

Securing Sensitive S3 Data: The Problem & The Solution
In the world of cloud security, "encryption" is often the default answer. But when dealing with highly sensitive data—like customer call logs—simply scrambling the data isn't enough. You need to control who holds the keys to unscramble it.

Here is a common real-world scenario and the most efficient AWS architecture to solve it.

The Problem: Sensitive Data & Granular Access
Imagine your company stores customer call logs in an Amazon S3 bucket. This data contains PII (Personally Identifiable Information), so it must be encrypted at rest.

However, standard encryption isn't enough. You have a requirement that only specific employees (e.g., the Compliance Team) can decrypt and read these logs. Even if a system administrator has access to the S3 bucket itself, they should not be able to read this specific sensitive data.

The Challenge: How do you enforce encryption while strictly limiting who can use the decryption keys, with the least amount of operational effort?

The Solution: SSE-KMS with IAM Policies
The most effective solution is to use Server-Side Encryption with AWS KMS keys (SSE-KMS) combined with restrictive IAM policies.

How it works:

SSE-KMS: Instead of letting S3 manage the keys transparently (SSE-S3), you use AWS Key Management Service (KMS). This allows you to create a specific Customer Managed Key (CMK) for these call logs.

Key Policies: You configure the Key Policy (or an IAM policy attached to users) to explicitly allow only the specific employees (e.g., the Compliance Team) to use kms:Decrypt for that key.

The Result: If a general admin tries to download the object, S3 might let them download the file, but because they lack permission to use the KMS key, the data remains a garbled, encrypted mess.

Why this wins: It separates "storage access" from "data access." It satisfies the requirement for "Least Privilege" without requiring you to manage your own hardware (CloudHSM) or manage keys manually on your own servers (SSE-C).

How to make your 1st Open-source contribution to AWS Repo

Danh Hoang Hieu Nghi — Sun, 14 Dec 2025 15:37:24 +0000

I think you’ve probably heard about becoming an AWS Community Builder by writing articles, posts, or social media content. Another way is by contributing to AWS open-source projects.

At first, I wondered, “How can I help with anything when I’m just a junior university student?”

While learning about AWS Bedrock AgentCore, I read the documentation and did some hands-on labs using the AWS AgentCore sample. That’s when I noticed something was wrong. When I clicked on the Memory section, it redirected me to the Identity section instead.

I thought to myself, “What happened? Am I doing something wrong?”

Later, I realized that while the AWS team was writing the README file, they had simply mistyped these two sections. After that, I searched online for “How to contribute to an open-source project.”

I then forked the repository to my computer, changed two lines in the README.md file, pushed the changes to my branch, and followed their contribution guidelines. I created an issue using their template and submitted a pull request.

A few days later, I received an email saying that my pull request had been accepted. This made me incredibly happy. Such a small change to a large project can benefit the community in a meaningful way.

Checkout the Bedrock AgentCore Sample here, help me and everyone by contributing anything to it : https://github.com/awslabs/amazon-bedrock-agentcore-samples/