DEV Community: Danh Hoang Hieu Nghi

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

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/

Amazon Bedrock AgentCore Policy - Secure your "MCP Server/Tools" of your Agents using NLP

Danh Hoang Hieu Nghi — Fri, 05 Dec 2025 07:17:01 +0000

Amazon Bedrock AgentCore is AWS Developer-Oriented Platform for Building, Deploying, Scaling and Managing your AI Agent Production-Scale.

In this year re:Invent at Las Vegas, AWS announced a number of updates to Bedrock AgentCore included AgentCore Policy - secure what your Agent can do or call and AgentCore Evaluation to provide Assessment to your Agent system on tools perform specific tasks on different inputs and context. In this article, we will talk about AgentCore Policy - adding a top layer of secure your AI System (addition layer of Bedrock Guardrail (Build responsible AI applications with Amazon Bedrock Guardrails | Artificial Intelligence ).

Just imaging the Bedrock Guardrail is for security if your input and output of your agent, but agent not only "talk" but it can "do" things, so you need to put the barrier or rule that limit what your agent "can do"

“The way I think about it … is it controls what the agent is allowed to ask the tool to do. At the low level, you’ve got [identity access management], which says these are the tools that can be used. With Policy, you’ve got what you can ask the tool to do — and then with our existing Bedrock Guardrails, you can control what the LLM will say back to the end user,” Richardson explained.

Your AI Agent can call tools, execute code, automating workflows,.. to solve business problems with flexibility. But this occur a security challenge that agent may misinterpret business rules, or act outside their given permission.

For instance: You connect your customer AI Agent to their Google Drive Account with full permission to write, read and delete file, but you don't the agent "accidentally" delete some of you customer's file so you need some to limit your capabilities of your Agent

With Amazon Bedrock AgentCore Policy, developers can create policy engines, create and store deterministic policies in them and associate policy engines with gateways. AgentCore Policy intercepts all agent traffic through Amazon Bedrock AgentCore Gateways and evaluates each request against defined policies in the policy engine before allowing tool access.

Policies are constructed using Cedar language, an open source language for writing and enforcing authorization policies. This allows developers to precisely specify what agents can access and what actions they can perform.

Amazon Bedrock AgentCore Policy provides the capability to author policies using natural language by allowing developers to describe rules in plain English instead of writing formal policy code in Cedar. Natural language-based policy authoring interprets what the user intends, generates candidate policies, validates them against the tool schema, and uses automated reasoning to check safety conditions such as identifying policies that are overly permissive, overly restrictive, or contain conditions that can never be satisfied - ensuring customers catch these issues before enforcing policies.

To create a policy, you can start with a natural language description (that should include information of the authentication claims to use) or directly edit Cedar code.

Natural language-based policy authoring provides a more accessible way for you to create fine-grained policies. Instead of writing formal policy code, you can describe rules in plain English. The system interprets your intent, generates candidate policies, validates them against the tool schema, and uses automated reasoning to check safety conditions—identifying prompts that are overly permissive, overly restrictive, or contain conditions that can never be satisfied.

Unlike generic large language model (LLM) translations, this feature understands the structure of your tools and generates policies that are both syntactically correct and semantically aligned with your intent, while flagging rules that cannot be enforced. It is also available as a Model Context Protocol (MCP) server, so you can author and validate policies directly in your preferred AI-assisted coding environment as part of your normal development workflow. This approach reduces onboarding time and helps you write high-quality authorization rules without needing Cedar expertise.

permit( principal is AgentCore::OAuthUser, action == AgentCore::Action::"RefundTool__process_refund", resource == AgentCore::Gateway::"<GATEWAY_ARN>" ) when { principal.hasTag("role") && principal.getTag("role") == "refund-agent" && context.input.amount < 200 };
The following sample policy uses information from the OAuth claims in the JWT token used to authenticate to an AgentCore gateway (for the role) and the arguments passed to the tool call (context.input) to validate access to the tool processing a refund. Only an authenticated user with the refund-agent role can access the tool but for amounts (context.input.amount) lower than $200 USD.

For more examples please read AWS Bedrock Agentcore Documentation here : https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/example-policies.html

This is the end of my article about AgentCore Policy, i will make a simple demo video on my youtube video later about this services on : Thank you for your reading!!!

References :
Amazon Bedrock AgentCore adds quality evaluations and policy controls for deploying trusted AI agents | AWS News Blog

Amazon Bedrock AgentCore Policy: Evaluate your agent - Amazon Bedrock AgentCore

Build responsible AI applications with Amazon Bedrock Guardrails | Artificial Intelligence

AWS' New Policy Layer in Bedrock AgentCore Makes Sure AI Agents Can't Give Away the Store - The New Stack

Firecracker – The Virtualization Technology Behind AWS Lambda and Bedrock AgentCore Runtime

Danh Hoang Hieu Nghi — Sun, 30 Nov 2025 14:40:18 +0000

Many of you may already be familiar with AWS Lambda — a key name whenever we talk about serverless architecture. Behind this powerful service lies a virtualization technology called Firecracker.

What is Firecracker?
In November 2018, Amazon Web Services (AWS) introduced Firecracker AWS Firecracker 2018 , an open-source virtualization technology that enables service owners to operate multi-tenant, container-based services by combining the speed and resource efficiency of containers with the security and isolation of virtual machines. The result is Micro-Virtual Machines (MVMs) based on Linux’s Kernel-based Virtual Machine (KVM) technology.

Which Service Using Firecracker?
AWS Fargate tasks are also executed using Firecracker microVMs.

AWS Lambda uses Firecracker-provisioned sandboxes to run customer functions.

Bedrock AgentCore Runtime
AgentCore Runtime is the execution environment for agents within the Bedrock AgentCore ecosystem, where developers can deploy agent code, LLMs, etc., without having to worry about infrastructure management or scaling.

A fully isolated execution environment: Each user session (8 hours) in AgentCore Runtime has its own dedicated microVM with isolated compute resources, memory, and its own filesystem, preventing any agent from accessing another user’s data.

After a session ends, the entire microVM is destroyed and all session data is deleted. During the session, a user may have multiple interactions — multiple tool calls, multiple LLM invocations. (If persistent memory is needed, one can use a related ecosystem service: Bedrock AgentCore Memory Add memory to your Amazon Bedrock AgentCore agent - Amazon Bedrock AgentCore

AgentCore Runtime Session Lifecycle

Active: The runtime is either processing a synchronous invocation or performing background tasks (tracked automatically).
Idle: The runtime is not handling requests or background tasks, but remains available for future invocations.
Terminated: The execution environment provisioned for the session is destroyed — which may occur due to inactivity (15 minutes), reaching max session duration (8 hours), or failing health checks. Subsequent invocations to a terminated runtimeSessionId will result in provisioning of a new execution environment.

CPU charges: Only when actively consumed in ACTIVE or IDLE states - True idle: No CPU consumption (I/O wait, genuinely idle) = No CPU charges - Memory charges: Based on peak memory allocated

References:

New Layer of AI Engineer - on AWS Bedrock

Danh Hoang Hieu Nghi — Sat, 13 Sep 2025 03:29:37 +0000

This is my comprehensive blog presenting my perspective on building AI applications on top of Amazon Bedrock.
There are rumors that AI engineers just call some APIs and that there’s nothing much more to it.
I don’t think this is a positive view, because there’s much more to the job than just coding and making API calls.
There are countless research papers and publications that have laid the foundations we rely on today, many of them published decades ago.
Yes, most of an AI engineer’s work is building software; we use abstractions from third‑party vendors such as AWS, LangChain, and OpenAI instead of building everything from scratch.
We plan, code, experiment, and also conduct research to provide evidence to base our work on.
So, an AI engineer is roughly 5% AI (built on the contributions of AI researchers) and 95% software engineering

ClickOps and IaC Deploy Simple EC2 Wordpress on AWS

Danh Hoang Hieu Nghi — Tue, 02 Sep 2025 14:02:08 +0000

Lời nói đầu

Xin chào mọi người, bài viết hôm nay sẽ là một chia sẽ ngắn gọn về triển khai một website Wordpress trên Amazon EC2 đơn giản và nhanh nhất có thể.

Bài viết này hands-on from zero, hướng dẫn chi tiết từng khái niệm theo một cách đơn giản nhất. Phù hợp dành cho các developer mới bắt đầu hoặc tìm hiểu thêm về AWS Cloud - Muốn triển khai wordpress web application một cách nhanh chóng nhất trên nền tảng AWS để tận dụng được khả năng năng mở rộng hạ tầng server, cũng như chính sách xài nhiêu trả bấy nhiêu của AWS.

Các yêu cầu tiên quyết để follow-up thực hiện bài lab này :
Phải có account AWS để thực hành

Nếu các bạn chưa có tài khoản AWS hoặc không truy cập được thì có thể xem post sau của First Cloud Journey để hướng dẫn tạo account Hướng dẫn tạo tài khoản AWS
Không cần gì hơn, và chúng ta bắt đầu vô thôi!!!!

Một số khái niệm tiên quyết để thực hành lab

AWS EC2:
Infrastrucure as Code (IaC):
AWS Cloudformation:
Amazon Machine Images in Amazon EC2 (AMI)
Keypair:
VPC:
Internet Gateway:
Subnet:
Route Table:
Elastic IP:

Bài labs này sẽ được chia làm 2 phần, một phần là ClickOps (Thực hiện thao tác trực tiếp trên AWS Console) và phần còn lại là thực hiện triển khai bằng Cloudformation (IaC)

Triển khai website wordpress bằng AWS Console (ClickOps)

Bước 1: Tìm kiếm và truy cập vào dịch vụ AWS EC2 ở màn hình AWS Console

Bước 2: Bấm vào nút Launch Instance ở trang chủ hoặc bấm vào mục Instance bên thanh bên phải màn hình và chọn Launch Instance

Bước 3: Sau khi vào màn hình giao diện của tùy chỉnh để launch EC2 Instance. Ở mục Name and tags thì ta thực hiện việc đặt tên cho Instance (Máy ảo) của chúng ta. Ở mình đặt là HieuNghiWordpressServer

Checkpoint 1

Checkpoint 2

Checkpoint 3

Checkpoint 4

Triển khai website wordpress bằng IaC (Cloudformation)

Các đường link tham khảo:

Wordpress on AWS - FCJ - Triển khai Wordpress trên AWS Cloud của Firstcloud journey

Github Best Practice Wordpress on AWS Cloud

Reference Architecture Wordpress on AWS Cloud

Ngày thực hiện bài viết : 02/09/2025
Tác Giả : Danh Hoàng Hiếu Nghị