DEV Community: Hung____

Document Processing Using Amazon Bedrock Data Automation (BDA)

Hung____ — Wed, 14 Jan 2026 08:53:37 +0000

AWS Bedrock Data Automation (BDA) is a cloud-based service designed to make it easier to get insights from unstructured data such as documents, images, video, and audio. .

Here are some example use cases:

Document processing: BDA helps automate intelligent document processing (IDP) at scale without requiring complex steps such as document classification, data extraction, normalization, or validation.
Media analysis: BDA enriches unstructured video content by generating scene-level summaries, detecting unsafe or explicit material, extracting on-screen text, and classifying content based on advertisements or brands.
Generative AI assistants: BDA improves retrieval-augmented generation (RAG)–based question-answering systems by supplying detailed, specific information extracted from documents, images, video, and audio.

In this blog I want to walk through the AWS BDA workshop

Here is the official workshop: https://catalog.us-east-1.prod.workshops.aws/workshops/c64e3606-ab68-4521-81ea-b2eb36c993b9/en-US

And here is my forked repo that have the updated template and notebooks with all the results: https://github.com/Hung-00/sample-document-processing-with-amazon-bedrock-data-automation

Because the original template in the workshop have some problems (outdated LLM) when deploy so I update my own template, you can use it instead of the original template: https://github.com/Hung-00/sample-document-processing-with-amazon-bedrock-data-automation/blob/main/bda.yaml

You should also complete the workshop with the updated notebooks in my forked repo, there is some change in LLM, for example I use

Understanding the Core Concepts

BDA's standard output feature provides immediate value with least configuration. Simply send your file to BDA, and it returns commonly required information based on the data type:

Documents: Page-level text extraction, element detection (tables, figures, charts), structural analysis with markdown formatting, and document summaries
Images: Content moderation, text detection, and image summaries
Video: Scene summaries, transcripts, and content moderation
Audio: Transcriptions and audio summaries

What makes standard output powerful is its flexibility. You can configure:

Response Granularity: Choose from document, page, element, line, or word-level extraction
Text Formats: Get results in plaintext, markdown, HTML, or CSV
Bounding Boxes: Extract precise element locations on pages
Generative Fields: Enable AI-generated summaries and descriptions for figures and charts

And when you need specific information extracted from documents or images, custom output with blueprints is your solution. A blueprint is essentially a schema that defines exactly what fields you want to extract, their data types, and validation rules.

Key Features of Blueprints:

Catalog Blueprints: Pre-built blueprints for common documents like forms, paystubs, receipts, driver's licenses, bank statements, and medical insurance cards
Custom Blueprints: Define your own schemas with fields, groups, and tables
Automatic Matching: When processing files with multiple document types, BDA automatically matches each document to the appropriate blueprint
Normalization: Apply natural language context for data validation and normalization

Explore the notebooks in the repository to:

11_getting_started_with_bda.ipynb: Learn BDA basics and API workflow
12_standard_output_extended.ipynb: Deep dive into standard output configuration
13_custom_outputs_and_blueprints.ipynb: Master custom blueprints and projects
21_mortgage_and_lending.ipynb: Build a mortgage document processing solution
22_medical_claims_processing.ipynb: Create an end-to-end claims processing workflow

I will go through 2 real-world use cases in the workshop.

Mortgage and Lending: Accelerating Loan Processing

The mortgage industry handles massive volumes of documentation for each loan application. A typical lending package includes:

Identity verification documents (driver's licenses, passports)
Financial documents (bank statements, W-2 forms, paystubs, checks)
Property documents (homeowner insurance applications, appraisals)

The Challenge: Manual review of these documents is slow, expensive, and error-prone. Loan officers spend hours verifying information across multiple document types.

The BDA Solution: By creating a project with multiple blueprints (both catalog and custom), BDA can:

Automatically split multi-page PDF packages into individual documents
Classify each document type (driver's license, bank statement, W-2, etc.)
Match documents to the appropriate blueprint
Extract structured data from each document
Validate information consistency across documents

Each document is processed with its specific blueprint, extracting exactly the fields needed for loan verification. Processing time drops from hours to minutes, with higher accuracy and consistency.

Using this custom blueprint to process a Homeowner Insurance Form

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "description": "This blueprint will process a homeowners insurance applicatation form",
    "class": "default",
    "type": "object",
    "properties": {
        "Insured Name":{
           "type":"string",
           "inferenceType":"explicit",
           "instruction":"Insured's Name",
        },
           "Insurance Company":{
           "type":"string",
           "inferenceType":"explicit",
           "instruction":"insurance company name",
        },  
           "Insured Address":{
           "type":"string",
           "inferenceType":"explicit",
           "instruction":"the address of the insured property",
        },
           "Email Address":{
           "type":"string",
           "inferenceType":"explicit",
           "instruction":"the primary email address",
        }
        }
    }

Invoke data automation with code like this:

response = run_client.invoke_data_automation_async(
    inputConfiguration={'s3Uri':  f"s3://{bucket_name}/{object_name}"},
    outputConfiguration={'s3Uri': f"s3://{bucket_name}/{output_name}"},
    blueprints=[{'blueprintArn': blueprint_arn, 'stage': 'LIVE'}],
    dataAutomationProfileArn = dataAutomationProfileArn)

A lending package is a single PDF file that contains multiple documents needed to apply for a loan and BDA can also handle that.

When processing a 50-page lending package, BDA automatically detects:

A driver's license on pages 1-2
Bank statements on pages 3-15
W-2 forms on pages 16-18
Paystubs on pages 19-30
A check image on page 31
Insurance documents on pages 32-50

Medical Claims Processing

Healthcare organizations process millions of insurance claims annually. Each claim involves multiple documents, data validation, and policy verification.

The medical claims solution demonstrates BDA's power when integrated with Amazon Bedrock Agents and Knowledge Bases:

Document Ingestion: Medical claim forms (CMS 1500) are submitted and stored in S3
BDA Processing: A custom blueprint extracts all claim fields including patient information, provider details, diagnosis codes, procedure codes, and charges
Agent Orchestration: A Bedrock Agent receives the extracted data and orchestrates the verification workflow
Action Groups: The agent uses Lambda-backed action groups to:
- Query member and patient information from Aurora PostgreSQL
- Validate coverage eligibility
- Check claim data consistency
Knowledge Base Integration: The agent queries a Bedrock Knowledge Base containing Evidence of Coverage (EoC) documents to verify:
- Treatment coverage under the patient's plan
- Policy limits and exclusions
- Pay requirements
Report Generation: The agent generates a comprehensive verification report and stores it in S3

Key Innovation: By combining BDA's extraction capabilities with Bedrock Agents' orchestration and Knowledge Bases' RAG capabilities, the solution provides:

Best accuracy in field extraction
Automated verification against policy documents
Consistent decision-making based on documented coverage rules
Complete audit trails for compliance

Ingest Evidence of Coverage Documents directly into Knowledge Base.

From this health insurance claim form:

BDA can extract information base on blueprint:

Now we invoke AI agent for claim verification. Everything is done pretty perfect.

Conclusion

I think Amazon Bedrock Data Automation represents a innovative shift in how organizations handle unstructured data. By combining powerful extraction capabilities with flexible configuration options and integration with other AWS services, BDA can:

Mortgage lenders to process loan applications 10x faster
Healthcare providers to automate claims processing with agent-based verification
Financial institutions to extract insights from complex reports
Legal teams to process and analyze large document sets
... and many more use cases.

I think this is amazing, go have a look at this service.

AWS DevOps Agent Demo: Investigating ALB Health Check Failures

Hung____ — Fri, 12 Dec 2025 11:14:51 +0000

AWS DevOps Agent is a service that autonomously investigates incidents and identifies root causes.
In this demo, I'll try to simulate a scenario where EC2 instances behind an Application Load Balancer start failing health checks, and watch AWS DevOps Agent diagnose the problem.

Demo

In production environments, one of the most common incidents is ALB targets becoming unhealthy. This can happen for many reasons:

Application crashes
Database connection failures
Memory exhaustion
Dependency timeouts
Misconfigured health checks

In this demo, I'll deploy a Flask web application behind an ALB and simulate a database connection failure that causes the health endpoint to return 503 errors. The ALB will mark the targets as unhealthy, trigger CloudWatch alarms, and AWS DevOps Agent will investigate the root cause.

Here is the diagram, just a simple ELB, two instances and alarms. I recommend deploy this stack to us-east-1 cause at this time writing this, AWS DevOps Agent service is only available there.

I have also included a Lambda function that auto shut down instance after 2 hours, no worry about unexpected cost.

CloudFormation template: https://gist.github.com/Hung-00/e53f4c980baf13d9bb8902fd36a79a6b

Check the output of the stacks after successfully created.

Go ahead connect to the two instances. You can connect through Session Manager

Run this command to check heatlh status:

curl http://localhost/health

Server is healthy.

Now use this command to interrupt both servers:

curl -s http://localhost/simulate/unhealthy

or 

curl http://localhost/simulate/crash

The alarm had triggered.

Now let's head to AWS DevOps Agent.

You can learn how to create an Agent Space, the process is straightforward and simple.

Open Operator Access.

Have a look at your system in tab DevOps Center. You can see the stack's resources.

Change to tab Incident Response and let's investigate latest alarm.

You can watch the Investigation Progress. The agent shows its reasoning as it investigates:

It is interesting that AWS DevOps Agent can actually know the user did interrupt the server. As you can see below:

Each investigation has it own chat session, you can ask the agent about it.

Go to tab Prevention and run. Agent will analyze and give you some recommendations to improve based on investigation in history.

AWS DevOps Agent can not resolve the incidents by itself. You need to fix the root cause and implement the recommendations on your own.

Finally, run this command to restore healthy status:

curl -s http://localhost/simulate/healthy

Remember to delete the stack if you don't want to continue.

Conclusion

In this demo, we saw how AWS DevOps Agent cuts down resolution time, finds root causes quickly, and suggests ways to prevent similar issues.

The agent works best when it understands your full environment — AWS accounts, external tools, everything. Adding MCP servers for custom integrations could make it even more powerful.

It's free during preview, with some usage limits. Security is administrator-controlled through IAM permissions.

I think DevOps Agent is a tool, not a replacement. Engineers are still essential for implementing fixes, designing infrastructure improvements, and making critical decisions when rollbacks are needed

This is just a simple scenario to have a first look at AWS DevOps Agent, I will try to stimulate more scenarios in the future.

Thank you.

Kiroween 2025 - Haunting coding extension

Hung____ — Fri, 05 Dec 2025 20:20:22 +0000

Haunting Extension 🩸👻🎃

Inspiration

Developers spend countless hours staring at code editors—why not make it fun? With Halloween spirit in mind, we wanted to transform the mundane coding experience into something memorable. What if errors didn't just show red squiggles, but actually bled? What if deleting code felt like a dramatic horror movie moment? That spark of "what if coding was spooky?" became Blood Drip.

What it does

Blood Drip is a VS Code extension that adds horror-themed visual effects to your coding environment:

🩸 Blood Drip Animation: Error lines drip blood (5 drops reducing to 1, then repeating)
👻 Ghost Cursor: Random Halloween emojis (👻🎃💀🦇🕷️🧛🧟) follow your cursor
🪓 Code Killer: Delete 3+ lines and get dramatic murder notifications ("MASSACRE! 20 lines slaughtered!")
💀 Spooky TODO Icons: Skull, ghost, or tombstone icons replace boring TODO markers
🕯️ Candlelight Mode: Lines away from cursor dim, creating a spotlight effect

How we built it

Kiro is amazing. We used the VS Code Extension API with JavaScript. The architecture follows a controller pattern:

EffectManager: Central coordinator that initializes and manages all effects
Individual Controllers: BloodDripController, GhostCursorController, CodeKillerController, etc.
Configuration Manager: Handles user settings and real-time config changes
Decoration API: VS Code's system for adding visual elements to the editor

Challenges we ran into

Animation Performance: Our first blood drip implementation created and disposed decoration types every frame—causing flickering and memory leaks. Solution: decoration pooling.
VS Code Decoration Limitations: You can't directly animate decorations. We had to swap between pre-created decoration types to simulate animation.
Emoji Consistency: Emojis render differently across operating systems. We tested and selected widely-supported Halloween emojis.
Resource Management: Extensions run in VS Code's process. Poor cleanup = sluggish editor. We implemented proper disposal patterns and pause-on-focus-loss.
Feature Conflicts: Some effects (like fog and candlelight) competed visually. We had to make tough decisions about which features to keep.

Accomplishments that we're proud of

Smooth Animations: The blood drip effect runs at consistent frame rates without impacting editor performance
Code Killer Feature: The escalating murder messages (eliminated → MURDER → CARNAGE → MASSACRE → GENOCIDE) add genuine fun to refactoring
Random Ghost Cursor: 12 different Halloween emojis keep every cursor movement surprising
Zero-Config Fun: Works immediately on install with sensible defaults
Full Customization: Every feature can be toggled independently via VS Code settings

What we learned

VS Code's Extension API is powerful but quirky—understanding decoration types and their lifecycle is crucial
Performance matters in extensions—debouncing, pooling, and pausing are essential patterns
Users want control—every feature needs an on/off switch
Simple ideas can be technically complex—"make blood drip" sounds easy until you're debugging animation frame timing
Fun features drive engagement—the Code Killer feature gets the most reactions

What's next for Haunting Extension

Future features we're excited about:

🕸️ Cobweb Corners: Decorative cobwebs appear on stale/unchanged code
⚡ Lightning Flash: Brief screen flash when saving files with errors
👁️ Watching Eyes: Blinking eyes in the gutter on long functions (code smell indicator)
🦴 Skeleton Comments: Bone emojis on commented-out dead code
🐀 Creepy Crawlies: Spiders crawl across unused imports
🎭 Haunted Line Numbers: Spooky symbols on Friday the 13th or Halloween
Seasonal Themes: Christmas horror mode, Valentine's bleeding hearts

Have a look: https://github.com/Hung-00/kiroween-haunting-extension

Thank you!

Understanding Multi-Agent Patterns in Strands Agent: Graph, Swarm, and Workflow

Hung____ — Fri, 21 Nov 2025 18:24:40 +0000

Building complex, useful AI applications often requires more than a single agent. When you need multiple AI agents to collaborate, the question becomes: how should they work together?

Strands Agent offers three distinct orchestration patterns, each designed for different scenarios.

In this post, we'll explore the Graph, Swarm, and Workflow patterns through simple, practical examples using AWS Bedrock and Amazon Nova.

The Three Patterns at a Glance

Pattern	Execution Flow	Best For
Graph	LLM decides routing	Conditional branching & decision trees
Swarm	Agents hand off autonomously	Collaborative problem-solving
Workflow	Pre-defined DAG	Repeatable processes with parallel tasks

The key difference? Who controls the flow:

Graph: Developer defines the map, LLM chooses the path
Swarm: Agents decide who to hand off to next
Workflow: System executes a fixed dependency graph

Pattern 1: Graph

When to use: The Graph pattern is ideal when you have a structured process with conditional branches based on inputs. Specifically, use Graph when:

You need intelligent routing where the LLM evaluates context and decides the best path forward
Your process has multiple possible paths but the correct path depends on input characteristics (complexity, urgency, user type, content category)
You want cycles and loops for retry logic, escalation paths, or iterative refinement when initial attempts fail
You need human-in-the-loop approval gates or decision points embedded in the flow
You want to maintain control over possible outcomes while allowing AI flexibility within those boundaries

Example Architecture - Pizza Ordering System

Order Taker
    ├─→ Simple Processor → Confirmer
    └─→ Custom Processor → Confirmer

The LLM at the Order Taker node decides whether to route to the simple or custom processor based on order complexity.

from strands import Agent, Graph
from strands.models import BedrockModel

nova_model = BedrockModel(
    model_id="amazon.nova-pro-v1:0",
    region_name="us-east-1"
)

# Define agents
order_taker = Agent(
    model=nova_model,
    system_prompt="Route to 'simple_processor' for standard orders,
                   'custom_processor' for special requests",
    tools=[take_order]
)

# Create graph
graph = Graph()
graph.add_agent("order_taker", order_taker)
graph.add_agent("simple_processor", simple_processor)
graph.add_agent("custom_processor", custom_processor)

# Define possible routing paths
graph.add_edge("order_taker", "simple_processor")
graph.add_edge("order_taker", "custom_processor")

result = graph("I want a large pepperoni pizza")

Real-World Use Cases

Customer support routing
Loan approval workflows with risk assessment branches
Multi-step troubleshooting systems
Insurance claim processing
Medical imaging analysis with specialist referral paths
In content moderation, automatic approval for clearly safe content, flagging for review, and immediate blocking for violations

Key advantage: Combines structure with flexibility - you define the possible paths, but the AI makes intelligent routing decisions. This prevents unpredictable behavior while enabling sophisticated decision-making.

Pattern 2: Swarm

When to use:

You have distinct specializations where each agent brings unique expertise to the problem
Tasks require iterative collaboration with multiple rounds of back-and-forth between agents
Agents need to self-organize and determine when their contribution is complete
The optimal sequence of work isn't always predictable upfront
The problem is too complex for a single agent but doesn't fit a fixed pipeline

Example Architecture - Blog Post Creation

Researcher → Writer → Editor

Each agent decides when its work is complete and hands off to the next agent.

from strands import Agent, Swarm

researcher = Agent(
    model=nova_model,
    system_prompt="Research the topic, then hand off to 'writer'",
    tools=[research_topic]
)

writer = Agent(
    model=nova_model,
    system_prompt="Write the draft, then hand off to 'editor'",
    tools=[write_draft]
)

# Create swarm
swarm = Swarm()
swarm.add_agent("researcher", researcher)
swarm.add_agent("writer", writer)
swarm.add_agent("editor", editor)
swarm.set_entry_agent("researcher")

result = swarm("Create a blog post about AI multi-agent systems")

Real-World Use Cases

Code review systems where security, performance, and style specialists each contribute feedback
Content creation pipelines
Legal document review and drafting
Sales process

Key advantage: Natural collaboration that mimics human teams. Agents autonomously determine when to hand off based on task completion. The system can handle unexpected complexities as agents self-coordinate.

Pattern 3: Workflow

When to use: The Workflow pattern is perfect for repeatable processes with clear dependencies. Deploy Workflow when:

You have a well-defined, repeatable process that doesn't change between executions
You need parallel execution to maximize efficiency and reduce total runtime
Process steps have clear inputs and outputs that flow between tasks
You want predictable, deterministic behavior every single time
You need audit trails and visibility into each step's execution
Failure handling requires retry logic for specific tasks without restarting everything

Example Architecture - Email Campaign Pipeline

Load Data → Segment Customers → ┌─→ VIP Emails  ──┐
                                ├─→ Regular Emails├─→ Schedule Campaign
                                └─→ New Emails ───┘
                                    (parallel)

The workflow executes tasks based on a dependency graph (DAG), running independent tasks in parallel.

from strands import Agent, Workflow

# Create workflow
workflow = Workflow()

# Add tasks
workflow.add_task("load", load_agent)
workflow.add_task("segment", segment_agent)
workflow.add_task("vip_email", vip_email_agent)
workflow.add_task("regular_email", regular_email_agent)
workflow.add_task("schedule", schedule_agent)

# Define dependencies
workflow.add_dependency("segment", "load")
workflow.add_dependency("vip_email", "segment")
workflow.add_dependency("regular_email", "segment")
workflow.add_dependency("schedule", "vip_email")
workflow.add_dependency("schedule", "regular_email")

result = workflow("Create personalized email campaign")

Real-World Use Cases

Data ETL pipelines
Batch processing jobs
Employee onboarding automation
Report generation systems

Key advantage: Deterministic execution with automatic parallelization. Perfect for predictable, repeatable processes where efficiency and reliability are most important.

Pattern Combinations

These patterns aren't mutually exclusive. You can:

Use a Workflow as a tool within a Graph node
Have a Swarm agent invoke a Workflow for a specific task
Embed a Graph within a larger Workflow pipeline

Shared State Across Multi-Agent Patterns

Both Graph and Swarm patterns support passing shared state to all agents through the invocation_state parameter. This enables sharing context and configuration across agents without exposing it to the LLM.

How Shared State Works

The invocation_state is automatically propagated to:

All agents in the pattern via their **kwargs
Tools via ToolContext when using @tool(context=True)
Tool-related hooks (BeforeToolCallEvent, AfterToolCallEvent)

Example Usage

from strands import Agent, Graph, Swarm, tool, ToolContext
from strands.models import BedrockModel

nova_model = BedrockModel(
    model_id="amazon.nova-pro-v1:0",
    region_name="us-east-1"
)

# Define shared state with configuration and context
shared_state = {
    "user_id": "user123",
    "session_id": "sess456",
    "debug_mode": True,
    "api_key": "secret_key_789",
    "database_connection": db_connection_object
}

# Use with Graph pattern
graph = Graph()
graph.add_agent("analyzer", analyzer_agent)
graph.add_agent("processor", processor_agent)

result = graph(
    "Analyze customer data",
    invocation_state=shared_state
)

# Use with Swarm pattern (same shared_state)
swarm = Swarm()
swarm.add_agent("researcher", researcher_agent)
swarm.add_agent("writer", writer_agent)
swarm.set_entry_agent("researcher")

result = swarm(
    "Create customer report",
    invocation_state=shared_state
)

Accessing Shared State in Tools

@tool(context=True)
def query_customer_data(query: str, tool_context: ToolContext) -> str:
    """Query customer database using shared configuration."""
    # Access invocation_state from tool context
    user_id = tool_context.invocation_state.get("user_id")
    debug_mode = tool_context.invocation_state.get("debug_mode", False)
    db_conn = tool_context.invocation_state.get("database_connection")

    if debug_mode:
        print(f"Querying for user: {user_id}")

    # Use shared context for personalized queries
    results = db_conn.execute(query, user_id=user_id)
    return results

@tool(context=True)
def send_notification(message: str, tool_context: ToolContext) -> str:
    """Send notification using shared API key."""
    api_key = tool_context.invocation_state.get("api_key")
    session_id = tool_context.invocation_state.get("session_id")

    # Use API key from shared state
    notification_service.send(
        message=message,
        api_key=api_key,
        session=session_id
    )
    return "Notification sent successfully"

Important Distinctions

Shared State (invocation_state):

Configuration and objects passed behind the scenes
Not visible to the LLM in prompts
Used for: API keys, database connections, user context, debug flags

Pattern-Specific Data Flow:

Data that the LLM should reason about
Visible in conversation context
Graph: Explicit state dictionary passed between agents
Swarm: Shared conversation history and context from handoffs

Best Practice: Use invocation_state for context and configuration that shouldn't appear in prompts, while using each pattern's specific data flow mechanisms for data the LLM should reason about.

Key Takeaways

Graph = Structured routing with AI-driven decisions
Swarm = Autonomous collaboration between specialists
Workflow = Fixed dependencies with parallel execution

Choose based on:

How predictable your process is (Workflow > Graph > Swarm)
How much AI do you want (Swarm > Graph > Workflow)
Whether you need parallel execution (Workflow best, Swarm/Graph sequential)
Start simple, scale complexity
Consider maintenance and debugging
Performance considerations

The right pattern isn't about which is "best" in absolute terms—it's about matching your specific requirements. Many systems will use all three patterns in different parts of their architecture.

AWS Agent built with Strand Agent framework and deployed to Bedrock Agentcore

Hung____ — Mon, 29 Sep 2025 03:53:35 +0000

In this post, I will show you how I created my AWS Agent built with Strand Agent framework and deployed to Bedrock Agentcore.

First you need to create an execution role for AgentCore Runtime.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ECRImageAccess",
            "Effect": "Allow",
            "Action": [
                "ecr:BatchGetImage",
                "ecr:GetDownloadUrlForLayer"
            ],
            "Resource": [
                "arn:aws:ecr:us-east-1:123456789012:repository/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogStreams",
                "logs:CreateLogGroup"
            ],
            "Resource": [
                "arn:aws:logs:us-east-1:123456789012:log-group:/aws/bedrock-agentcore/runtimes/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogGroups"
            ],
            "Resource": [
                "arn:aws:logs:us-east-1:123456789012:log-group:*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:us-east-1:123456789012:log-group:/aws/bedrock-agentcore/runtimes/*:log-stream:*"
            ]
        },
        {
            "Sid": "ECRTokenAccess",
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "xray:PutTraceSegments",
                "xray:PutTelemetryRecords",
                "xray:GetSamplingRules",
                "xray:GetSamplingTargets"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Resource": "*",
            "Action": "cloudwatch:PutMetricData",
            "Condition": {
                "StringEquals": {
                    "cloudwatch:namespace": "bedrock-agentcore"
                }
            }
        },
        {
            "Sid": "GetAgentAccessToken",
            "Effect": "Allow",
            "Action": [
                "bedrock-agentcore:GetWorkloadAccessToken",
                "bedrock-agentcore:GetWorkloadAccessTokenForJWT",
                "bedrock-agentcore:GetWorkloadAccessTokenForUserId"
            ],
            "Resource": [
                "arn:aws:bedrock-agentcore:us-east-1:123456789012:workload-identity-directory/default",
                "arn:aws:bedrock-agentcore:us-east-1:123456789012:workload-identity-directory/default/workload-identity/agent*"
            ]
        },
        {
            "Sid": "BedrockModelInvocation",
            "Effect": "Allow",
            "Action": [
                "bedrock:InvokeModel",
                "bedrock:InvokeModelWithResponseStream"
            ],
            "Resource": [
                "arn:aws:bedrock:*::foundation-model/*",
                "arn:aws:bedrock:us-east-1:123456789012:*"
            ]
        }
    ]
}

The import part is in "arn:aws:bedrock-agentcore:us-east-1:123456789012:workload-identity-directory/default/workload-identity/agent*", agent* is set here so that you can create agent starts with agent and then just atttach this policy, you don't need to create a new policy or role for new agent.

Also you need some more policy so that the tools from AWS MCP server can have access to your resource and do the task.

For this project, I want to create a supervisor agent that control other AWS MCP agents using Strands Agents framework and deploy Bedrock AgentCore.

The only LLM is use is us.anthropic.claude-3-7-sonnet-20250219-v1:0.

bedrock_model = BedrockModel(
        model_id="us.anthropic.claude-3-7-sonnet-20250219-v1:0",
        region_name="us-east-1",
    )

Here is the prompt I use for my orchestrator agent, it works pretty well:

SUPERVISOR_AGENT_PROMPT = """
You are Orchestrator Agent, a sophisticated orchestrator designed to coordinate support across AWS services.
Your role is to analyze incoming queries and route them to the most appropriate specialized agent.

Available Specialized Agents:

SPECIALIZED SERVICES:
- AWS CloudTrail Assistant: Security auditing, compliance monitoring, API call tracking, and forensic analysis
- AWS CloudWatch Assistant: Monitoring, logging, observability, alarm management, and performance analysis
- AWS Cost Assistant: Cost analysis, spend reports, billing optimization, and usage tracking
- AWS Diagram Assistant: Architecture visualization, AWS diagram generation, and infrastructure mapping
- AWS Documentation Researcher: Search AWS documentation for technical information and best practices
- AWS DynamoDB Assistant: NoSQL database operations, data modeling, and performance optimization
- AWS IAM Assistant: Identity and access management, policy analysis, and security audits
- AWS Nova Canvas: AI image generation and creative visual content
- AWS Terraform Assistant: Infrastructure as code, Terraform best practices, and security compliance

Key Responsibilities:
- Accurately classify and route queries to appropriate specialized agents
- Maintain conversation context using memory for personalized responses
- Coordinate multi-step problems requiring multiple agents
- Provide cohesive responses when multiple agents are needed

Decision Protocol:
- Security audits/compliance/API tracking → AWS CloudTrail Assistant
- Monitoring/logging/observability/alarms → AWS CloudWatch Assistant
- Cost/billing/usage analysis → AWS Cost Assistant
- Architecture diagrams/visualization → AWS Diagram Assistant
- Documentation/research/best practices → AWS Documentation Researcher
- NoSQL/DynamoDB/data modeling → AWS DynamoDB Assistant
- IAM/security/permissions/policies → AWS IAM Assistant
- Image creation/AI art → AWS Nova Canvas
- Infrastructure/Terraform/IaC → AWS Terraform Assistant


Always leverage user context from memory to provide personalized assistance. Just give me enough answer, do not overthinking.
"""

I have created 9 agents for 9 diferrent AWS MCP servers:

Here is the list of all AWS MCP servers: https://github.com/awslabs/mcp/tree/main

Here is an example of an agent:

import os

from mcp import StdioServerParameters, stdio_client
from strands import Agent, tool
from strands.models import BedrockModel
from strands.tools.mcp import MCPClient
from strands_tools import file_write, think


@tool
def aws_cost_assistant(query: str) -> str:
    bedrock_model = BedrockModel(
        model_id="us.anthropic.claude-3-7-sonnet-20250219-v1:0",
        region_name="us-east-1",
    )

    response = str()

    try:
        env = {}
        cost_mcp_server = MCPClient(
            lambda: stdio_client(
                StdioServerParameters(
                    command="uvx",
                    args=["awslabs.cost-explorer-mcp-server@latest"],
                    env=env,
                )
            )
        )

        with cost_mcp_server:

            tools = cost_mcp_server.list_tools_sync() + [think]

            cost_agent = Agent(
                model=bedrock_model,
                system_prompt="""You are a AWS account cost analyst. You can do the following tasks:
                - Amazon EC2 Spend Analysis: View detailed breakdowns of EC2 spending for the last day
                - Amazon Bedrock Spend Analysis: View breakdown by region, users and models over the last 30 days
                - Service Spend Reports: Analyze spending across all AWS services for the last 30 days
                - Detailed Cost Breakdown: Get granular cost data by day, region, service, and instance type
                - Interactive Interface: Use Claude to query your cost data through natural language
                """,
                tools=tools,
            )
            response = str(cost_agent(query))
            print("\n\n")

        if len(response) > 0:
            return response

        return "I apologize, but I couldn't properly analyze your question. Could you please rephrase or provide more context?"

    except Exception as e:
        return f"Error processing your query: {str(e)}"


if __name__ == "__main__":
    aws_cost_assistant("Get my cost usage of this month. I just the number of money.")

For every agent, I use think tool from Strand Agent so that the agent can brainstorm better.

At the end of every agent file, I added:

if __name__ == "__main__":
    aws_cost_assistant("Get my usage of last 7 days per service")

I added this code so that I can test the agent independently just by running the file, check that my agent is working or not:

py .\aws_cost_assistant.py

You don't have to invoke the agent through orchestrator agent.

I've also created the memory hook using AgentCore memory. The memory hook provides:

OrchestratorMemoryHooks

User Context Retrieval: Automatically retrieves relevant context before processing queries
Interaction Storage: Saves user-agent interactions for personalized responses
Multi-Strategy Memory: Supports user preferences and semantic memory storage
Session Management: Maintains context across conversation sessions

MemoryManager

Resource Management: Creates and manages AgentCore Memory resources
Strategy Configuration: Configures user preference and semantic memory strategies
Actor-Specific Memory: Isolated memory namespaces for different users
Automatic Expiry: 90-day event expiry for data management

Start Docker and run commands to launch your agent AgentCore Runtime:

agentcore configure -e agent.py --execution-role arn:aws:iam::123456789012:role/agentcore_role

agentcore launch

I've prepared a simple chat app to visualize the agent. You can find it in chat_app folder and run:

streamlit run agent_chat_app.py --server.headless true

Go to View invocation code on your agent console, get agentRuntimeArn and runtimeSessionId. Paste them in the settings:

Now you can start working with the agent. Try asking this:

Get my cost usage of this month. I just the number of money.

The response you get from the agent also have token usage, tool used and I also visualize that:

All of the above is created based on the formatted response from the agent. I've included everything I could.

Here is an example I told my agent to create a DynamoDB table

You can test the agent in agent sandbox on console:
Here is an example with aws_diagram_assistant:

Here I was asking about my chat history. As you can see that the agent can access the memory, everything is working as expected:

That is all for my AWS Agent built with Strand Agent framework and deployed to Bedrock Agentcore.
Have fun coding your agent!

Reference:

Create and manage inference profiles on Amazon Bedrock

Hung____ — Sun, 17 Aug 2025 12:44:53 +0000

Amazon Bedrock Inference Profiles is a powerful feature that allows you to track costs and usage metrics when invoking foundation models on Bedrock. Think of them as custom aliases for your models that provide detailed insights into how your AI applications consume resources. In this tutorial, I'll show you how to manage inference profiles.

What Are Inference Profiles?

Inference profiles in Amazon Bedrock serve two main purposes:

Cost Tracking: Monitor expenses per application, team, or project.
Usage Analytics: Track invocation patterns and resource consumption.

There are two types:

System-defined profiles: Created by AWS for cross-region inference.

Application profiles: Custom profiles you create for your specific needs. You can't view application inference profiles in the Amazon Bedrock console, only through CLI or API.

Each model have different inference types supported. Here is the model inference types supported breakdown:

inferenceTypesSupported is ['ON_DEMAND'] or ['ON_DEMAND', 'PROVISIONED']

✅ Can invoke directly
✅ Can create application inference profiles from these

inferenceTypesSupported: ['INFERENCE_PROFILE'] or ['PROVISIONED']

❌ Cannot invoke directly
❌ Cannot create application inference profiles directly
✅ Can only access through system-defined profiles

If you want to create inference profile, inferenceTypesSupported ** must have **ON_DEMAND.

You can use the function below to all the model that have ON_DEMAND in your selected region.

Remember that each region have different *inferenceTypesSupported * for each models.

import boto3
import json
from botocore.exceptions import ClientError

def list_available_models():
    bedrock_client = boto3.client('bedrock', region_name='us-east-1')
    try:
        response = bedrock_client.list_foundation_models()
        models = response.get('modelSummaries', [])
        available_models = []
        for model in models:
            if 'ON_DEMAND' in model.get('inferenceTypesSupported', []):
                model_info = {
                    'modelId': model.get('modelId'),
                    'modelArn': model.get('modelArn'),
                    'modelName': model.get('modelName'),
                    'inferenceTypes': model.get('inferenceTypesSupported', [])
                }
                available_models.append(model_info)
        print(available_models)
        return available_models

    except ClientError as e:
        print(f"Error listing models: {e}")
        return []

In us-east-1, you can create profile for almost every model, from every provider, even Amazon Nova:

But in ap-southeast-1, you can only create for 8 models from Anthropic and Cohere:

Currently, you can only create an inference profile using the Amazon Bedrock API. You can use this function here to create profile:

def create_inference_profile(
    region,
    profile_name,
    model_arn,
    model_name,
    tags=None,
    description=None
):
    bedrock_client= boto3.client('bedrock', region_name=region)

    try:
        params = {
            'inferenceProfileName': profile_name,
            'modelSource': {
                'copyFrom': model_arn
            }
        }

        if description:
            params['description'] = description

        if tags:
            params['tags'] = tags

        response = bedrock_client.create_inference_profile(**params)

        profile_info = {
            'inferenceProfileArn': response['inferenceProfileArn'],
            'inferenceProfileId': response.get('inferenceProfileId'),
            'status': response.get('status'),
            'profileName': profile_name,
            'region': region,
            'model': model_name,
            'modelArn': model_arn
        }

        print(f"Profile's ARN: {profile_info['inferenceProfileArn']}")

        return profile_info
    except ClientError as e:
        print(f"ErrorCode: {e.response['Error']['Code']}")
        print(f"Error: {e.response['Error']['Message']}")

        return None

For example, here I'm trying to create profile for Amazon Nova in us-east-1, also remember to add your desired tags:

profile = create_inference_profile(
    region="us-east-1",
    profile_name="Nova Pro Production",
    model_arn="arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-pro-v1:0",
    model_name="Nova Pro",
    tags= [
        {
            'key': 'region',
            'value': 'us-east-1'
        },
        {
            'key': 'project',
            'value': 'my-project'
        },
        {
            'key': 'env',
            'value': 'production'
        },
    ],
    description="Nova Pro for my application running on production"
)

if profile:
    print(f"Inference Profile Created Successfully!")
    print(f"Name: {profile['profileName']}")
    print(f"ARN: {profile['inferenceProfileArn']}")
    print(f"Region: {profile['region']}")
    print(f"Model: {profile['model']}")

Unfortunately, right now at August 2025, you can not view the inference profile on AWS console. Then you can check all the profiles with this command:

aws bedrock list-inference-profiles --region us-east-1 --type-equals APPLICATION

Get more details and tags for your inference profile:

# Get detailed information about a specific profile
aws bedrock get-inference-profile --region us-east-1 --inference-profile-identifier arn:aws:bedrock:us-east-1:xxxxxxx:application-inference-profile/xxxxxxx

# View tags for your profile
aws bedrock list-tags-for-resource --region us-east-1 --resource-arn arn:aws:bedrock:us-east-1:xxxxxxx:application-inference-profile/xxxxxxxx

Now let's try to invoke with the newly created inference profile:

bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1")

try:
    request_body = {
        "messages": [
            {
                "role": "user",
                "content": [
                    {
                        "text": "What is the capital of Canada?"
                    }
                ]
            }
        ],
    }

    response = bedrock_runtime.invoke_model(
        modelId="arn:aws:bedrock:us-east-1:151182331915:application-inference-profile/xxxxxxx",
        body=json.dumps(request_body),
        contentType="application/json",
    )

    response_body = json.loads(response["body"].read())
    print(response_body)
except ClientError as e:
    print(e.response['Error']['Code'])
    print(e.response['Error']['Message'])

As you can see that it works:

Now all the cost using this inference profile will be tagged. You now can manage the cost of your application more efficent.

You can delete the profile with this command:

aws bedrock delete-inference-profile --inference-profile-identifier "arn:aws:bedrock:us-east-1:xxxxxx:application-inference-profile/xxxxxx"  --region us-east-1

There is also this AWS Bedrock Inference Profile Management Tool to have you more with managing inference profiles, have a look!

Create inference profile with AWS CDK

from aws_cdk import (
    Stack,
    custom_resources as cr,
    aws_iam as iam,
    CfnOutput,
    # aws_logs as logs,
)
from constructs import Construct


class BedrockInferenceProfileStack(Stack):
    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        self.profile_name = "inference-profile"
        self.inference_profile = cr.AwsCustomResource(
            self,
            "BedrockInferenceProfile",
            on_create=cr.AwsSdkCall(
                service="Bedrock",
                action="createInferenceProfile",
                parameters={
                    "inferenceProfileName": self.profile_name,
                    "description": "Claude Inference Profile",
                    "modelSource": {
                        "copyFrom": "arn:aws:bedrock:ap-southeast-1::foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0"
                    },
                },
                physical_resource_id=cr.PhysicalResourceId.of(self.profile_name),
            ),
            on_update=cr.AwsSdkCall(
                service="Bedrock",
                action="getInferenceProfile",
                parameters={"inferenceProfileIdentifier": self.profile_name},
                physical_resource_id=cr.PhysicalResourceId.of(self.profile_name),
            ),
            on_delete=cr.AwsSdkCall(
                service="Bedrock",
                action="deleteInferenceProfile",
                parameters={
                    "inferenceProfileIdentifier": self.profile_name
                },
            ),
            policy=cr.AwsCustomResourcePolicy.from_statements(
                [
                    iam.PolicyStatement(
                        actions=[
                            "bedrock:CreateInferenceProfile",
                            "bedrock:DeleteInferenceProfile",
                            "bedrock:GetInferenceProfile",
                        ],
                        resources=["*"],
                    )
                ]
            ),
        )

        self.profileARN = self.inference_profile.get_response_field(
            "inferenceProfileArn"
        )

        CfnOutput(
            self,
            "ProfileARN",
            value=self.profileARN,
            description="Inference Profile",
        )

Hope you can create your inference profile successfully!

Reference:

Create training job for YOLO model on Amazon SageMaker with AWS Lambda

Hung____ — Tue, 12 Aug 2025 18:12:57 +0000

In this blog, I will show you how to create a training job for YOLO11x model on Amazon SageMaker through a Lambda function, and then deploy it into an enpoint.

I have prepared a repo that have all the code I use, please have a look:
https://github.com/Hung-00/Amazon-SageMaker-YOLO-training-job

The process

First, you need to have an image that contains all the packages and code files for training.

Making the image from scratch is kinda tricky, so that I have made this simple Dockerfile, you can have a look and give it a try.

FROM pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime

# Set timezone to avoid interactive prompt
ENV DEBIAN_FRONTEND=noninteractive
ENV TZ=UTC

# Install system dependencies
RUN apt-get update && apt-get install -y \
    git \
    python3-pip \
    libglib2.0-0 \
    libsm6 \
    libxext6 \
    libxrender-dev \
    libgomp1 \
    libgl1-mesa-glx \
    tzdata \
    && rm -rf /var/lib/apt/lists/*

# Upgrade pip
RUN pip install --upgrade pip

# Create requirements.txt with pinned versions
RUN echo "numpy==1.24.4\n\
sagemaker-training\n\
ultralytics==8.3.170\n\
albumentationsx\n\
opencv-python-headless==4.9.0.80\n\
pillow==10.1.0\n\
pandas==2.0.3\n\
matplotlib==3.7.2\n\
seaborn==0.12.2\n\
tqdm==4.66.1\n\
pyyaml==6.0.1\n\
scipy==1.10.1" > /requirements.txt

# Install all dependencies at once
RUN pip install -r /requirements.txt

# Set up the working directory
WORKDIR /opt/ml/code

# Copy training script
COPY train.py /opt/ml/code/train.py
COPY code/inference.py /opt/ml/code/inference.py
COPY code/requirements.txt /opt/ml/code/requirements.txt
# Only for testing
COPY debug.py /opt/ml/code/debug.py 

# Set the entrypoint to the training script
ENV SAGEMAKER_PROGRAM train.py

Notice the version ultralytics==8.3.170, latest verion at July 2025, you may need to upgrade to a higher version to access YOLO12 or later YOLO version.
And albumentationsx is an upgrade version of albumentations, it gives you better augmentations when training your model.
All the steps copying code files is important because we are using sagemaker-training-toolkit. Read more about it here: https://github.com/aws/sagemaker-training-toolkit

I have also created a script upload_image_to_ECR.py to build and upload the image straight to ECR, just make sure you have Docker running.

The image will be around 3.8GB.

Or you can test on local first, here is the commands you can use to test the image on local

docker build -t yolo .

docker run --rm -it \
  --gpus all \
  -v $(pwd)/local_test/input/data:/opt/ml/input/data \
  -v $(pwd)/local_test/model:/opt/ml/model \
  -v $(pwd)/local_test/output:/opt/ml/output \
  -e SM_MODEL_DIR=/opt/ml/model \
  -e SM_CHANNEL_TRAIN=/opt/ml/input/data/train \
  -e SM_CHANNEL_VALIDATION=/opt/ml/input/data/validation \
  -e SM_OUTPUT_DATA_DIR=/opt/ml/output/data \
  yolo \
  /bin/bash

Your local_test folder should looks like this structure so that you can bring it to container, you have to prepare training data by yourself:

Alsp, the dataset.yaml should looks like this:

names:
- class_0
- class_1
- class_2
- class_3
nc: 4
path: /opt/ml/input/data
train: train
val: validation

Test installation success or not

python debug.py

Test result:

Start training in container:

python train.py --epochs 1 --batch-size 2 --imgsz 640

Training results:

My train.py will put model,pt and other result images into 2 folder:

/opt/ml/model/
/opt/ml/output/data/
Everything in these two directories gets uploaded to S3.
This is where you should save your trained model artifacts and other results when training.
You can read about this here: https://nono.ma/sagemaker-model-dir-output-dir-and-output-data-dir-parameters

In model folder:

In output/data folder:

After the training job finish, inside the S3 bucket will have these 2 zip files. contains all of the above:

Now you know how the code inside the image works, then let's create training job with Lambda.

Go to 2_create training_job\trigger_training.py in my GitHub repo, take that function and deploy a new Lambda function with it.

Go to IAM create a role so that SageMaker can assume like below:

Set up SAGEMAKER_ROLE_ARN with the role above and ECR_IMAGE_URI with the URI of the latest image in your ECR repo, like ***********.dkr.ecr.ap-southeast-1.amazonaws.com/yolo11-training:latest

Your S3 bucket that has data should looks like this:

s3://your-data-bucket/
├── train/
│   ├── images/
│   │   ├── image1.jpg
│   │   ├── image2.jpg
│   │   └── ...
│   ├── labels/
│   │   ├── image1.txt
│   │   ├── image2.txt
│   │   └── ...
│   └── dataset.yaml
└── val/
    ├── images/
    │   └── ...
    └── labels/
        └── ...

Create a test event like format below, replace S3 path with the correct S3 URI, also give it an output bucket:

    {
        "training_data_s3": "s3://your-bucket/path/to/train",
        "validation_data_s3": "s3://your-bucket/path/to/val",
        "output_s3": "s3://your-bucket/path/to/output",
        "instance_type": "ml.g4dn.xlarge",
        "hyperparameters": {
            "epochs": 200,
            "batch-size": 16,
            "learning-rate": 0.01,
            "imgsz": 640
        }
    }

Click the test event to create a training job, the job will took around 35 minutes for 200 epochs with my settings:

The result will be create in your output bucket:

Now go to 3_create_endpoint\create_endpoint.py, take the code and deploy a Lambda function to create endpoint

Create an IAM role for SageMaker to assume with S3FullAccess policy. Save it to SAGEMAKER_ENPOINT_ROLE_ARN envirment variable.

Create test event, replace with your output bucket:

{
        "bucket_and_train_folder": "s3://your-output-bucket/trained-model/yolo11x-20250807-093817",
        "instance_type": "ml.c5.xlarge"
}

Test the event to deploy the endpoint, it may take up to 5 minutes.

You can test the endpoint with the simple code below:

!pip install opencv-python
import boto3, cv2, time, base64, json, os


infer_start_time = time.time()

# Read the image into a numpy array
orig_image = cv2.imread('images-test/a.jpg')

# Conver the array into jpeg
jpeg = cv2.imencode('.jpg', orig_image)[1]
# Serialize the jpg using base 64
payload = base64.b64encode(jpeg).decode('utf-8')

conf = 0.85
iou = 0.8
payload = f"{payload},{conf},{iou}"

runtime= boto3.client('runtime.sagemaker')
response = runtime.invoke_endpoint(EndpointName="your-yolo11x-endpoint", ContentType='text/csv', Body=payload)

response_body = response['Body'].read()
result = json.loads(response_body.decode('ascii'))

infer_end_time = time.time()

print(f"Inference Time = {infer_end_time - infer_start_time:0.4f} seconds")

print(result)

Hope this would be a helpful document.

Reference:

Create open-cv Python layer for AWS Lambda

Hung____ — Sun, 13 Jul 2025 16:34:31 +0000

AWS Lambda allows you to run code without provisioning or managing servers. One common use case is to handle image processing tasks such as object detection, image transformation, and computer vision tasks with OpenCV.

However, OpenCV is a large library, and packaging it with your Lambda function code can be tricky because Lambda has a size limit for deployment packages.

A better and only approach is to use Lambda Layers, which enable you to reuse common libraries across multiple functions. I have struggled a lot when trying to create a layer for opencv-python so that I can use cv2 and numpy in my code. There are some documents, repos out there but they are all outdated.

In this blog post, I will show you how to create an OpenCV layer for AWS Lambda in 2025.

Step by step

First let's make a folder. The important thing is the python version here. You need to change the version based on the version of the Lambda function.
Here I'm using Python 3.11:

mkdir -p opencv-layer/python/lib/python3.11/site-packages/
cd opencv-layer

Next, you download all packages. Remember to change the Python version.
You need to change both versions in the command below.

Change between pip and pip3 based on your enviroment.

The key part here is using the --platform manylinux2014_x86_64 flag which ensures compatibility with Lambda's environment, which is Linux.

Package opencv-python is too big, over the limit 150MB.
Use opencv-python-headless instead of the standard opencv-python package since Lambda doesn't need GUI components, the size of the layer will be reduced a lot which is good.

pip3 install --platform manylinux2014_x86_64 --implementation cp --python-version 3.11 --only-binary=:all: --upgrade --target python/lib/python3.11/site-packages/ opencv-python-headless

Then you will have a folder look liek this, for this one I use Python 3.11:

Create a ZIP file of the layer contents.
If you are on Window, you can manually zip the python folder.

zip -r opencv-layer.zip python/

Publish the layer.
You can also upload the zip file to S3 and create the layer manually with AWS console.

aws lambda publish-layer-version \
    --layer-name opencv-layer \
    --description "OpenCV layer" \
    --zip-file fileb://opencv-layer.zip \
    --compatible-runtimes python3.11

Finally now you just need to add the layer to the Lambda function you want. Make sure that they have the same Python version.

Test the layer

You can use this simple code to make sure that the layer is working.

import cv2
import numpy

def lambda_handler(event, context):
    print(cv2.__version__)
    print(numpy.__version__)

Hope this blog would be helpful!
Thank you for reading!

AWS RDS Tutorial

Hung____ — Wed, 22 May 2024 07:28:49 +0000

Please have a look at this first: https://dev.to/hungrushb/amazon-rds-create-database-deep-dive-2m8j

I. Preparation

Create VPC

1 . Create a simple VPC with name labRDS. Keep everything as default and create.

2 . Update Enable auto-assign public IPv4 address for 2 public subnets.

Repeat for public subnet 2.

Create EC2 security group

3 . Head to EC2 console, choose Security Groups, and Create security group.

Choose your VPC.

Add inbound rules:

HTTP (80): Select HTTP from the list or enter port 80.
HTTPS (443): Select HTTPS from the list or enter port 443.
Custom TCP Rule (5000): Select Custom TCP Rule and enter port 5000.
SSH (22): Select SSH from the list or enter port 22.

All source is Anywhere IPv4

Scroll down and create.

Create a Security Group for a DB Instance

4 . Create another SG with name labRDS-DB-SG.

Choose MYSQL/Aurora and port 3306.
For source, choose the EC2 SG we've created from last step.

Scroll down and create.

Creating a DB Subnet Group

5 . Go to RDS console, create a new subnet group.

6 . Enter name labRDS-subnet-group and choose VPC correctly.

Select 2 AZs that had 2 private subnet we created.

Scroll down and create.

An Amazon Relational Database Service (RDS) Subnet Group is an Amazon Virtual Private Cloud (VPC) resource used to define a particular set of network addresses that are accessible by an RDS instance. The subnet group defines the IP ranges for each Availability Zone, which allows for increased availability and reliability of the database instance. It also ensures that only authorized databases can access the associated subnets and prevents any unauthorized access from outside sources. Additionally, by using a Subnet Group, the user has full control over which resources have access to their database instances.

II. Create EC2 instance

7 . Go to EC2 console and launch a new instance.

Enter name labRDS-server. From the Amazon Machine Image (AMI), choose an HVM version of Amazon Linux 2023.

Under the Instance type section, choose the t2.micro instance type, which is pre-selected by default.

8 . Create a new key pair labRDS, download the key and choose it from the options.

9 . Edit Networking, choose VPC, Subnet, enable public IP and security group exactly like in picture.

Check again and launch.

10 . Access EC2 instance with the downloaded keypair. You can use MobaXTerm or Putty.

III. Creating a RDS DB Instance

Install Git and NodeJS

11 . First, update your system packages to make sure you’re using the latest version.
Find Git Packages.
Install Git.
Finally, check the Git version was successfully installed.

sudo dnf update -y
sudo dnf search git
sudo dnf install git -y
git --version

12 . Install Node.js with the script below.

#!/bin/bash

# Color for formatting
GREEN='\033[0;32m'
NC='\033[0m' # Colorless

# Check if NVM is installed
if ! command -v nvm &> /dev/null; then
  # Step 1: Install nvm
  curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
  source ~/.nvm/nvm.sh
fi

# Verify nvm installation
nvm --version

# Install the LTS version of Node.js
nvm install --lts

# Use the installed LTS version
nvm use --lts

# Verify Node.js and npm installation
node -v
npm -v

# Step 4: Create package.json file (if it doesn't exist yet)
if [ ! -f package.json ]; then
  npm init -y
  echo -e **${GREEN}Created file package.json.${NC}**
fi

#Step 5: Install necessary npm packages
echo -e **Installing required npm packages...**
npm install express dotenv express-handlebars body-parser mysql

#Step 6: Install nodemon as a development dependency
echo -e **Installing nodemon as a development dependency...**
npm install --save-dev nodemon
npm install -g nodemon

# Step 7: Add npm start script to package.json
if ! grep -q '**start**:' package.json; then
  npm set-script start **index.js** # Replace **your-app.js** with your entry point file
  echo -e **${GREEN}Added npm start script to package.json.${NC}**
fi

echo -e **${GREEN}Installation completed. You can now start building and running your Node.js application using 'npm start'.${NC}**

Create RDS DB Instance

13 . Navigate to RDS console to create a new database.

14 . Choose Standard.

Choose MySQL.

For Templates, choose Dev/Test.

Choose Single DB instance.

Enter database-labRDS for DB indentifier.
Open Credential Settings. If you want to specify a password, uncheck the Auto generate a password box if it’s already selected.
Change the Master username value if you want.
Enter the same password in both Master password and Confirm password.

For configuration, choose Burstable classes and db.t3.micro.

For Storage, choose General purpose (gp2), change Allocated storage to 20 GiB.

For Connectivity, choose Connect to an EC2 compute resource, then choose your server instance.

In Additional VPC security group, choose your DB security group.

Keep the rest default like below.

Scroll down and create.

View your connection detail.

15 . Inspect your new database

Viewing Logs and Events on AWS RDS

16 . Click on the Log & events tab. Here, you can view various logs such as:

Error log: Records errors that occur on the instance.
General log: Records general activities on the instance.
Slow query log: Records slow queries.
Event log: Displays important events related to the instance.

Choose one log and view it.

Viewing Maintenance Information

Here, you will see information about the maintenance schedule, including the times when the DB instance will be automatically backed up and maintenance tasks will be performed. You can also view the history of previous maintenance events.

You can also view automatic backups and manual backups. You can also configure and manage backup settings.

IV. Deploy the application

17 . Clone this repo.

git clone https://github.com/AWS-First-Cloud-Journey/AWS-FCJ-Management

18 . Install MySQL.

First, go save your database endpoint.

Note: To execute this script, you need to have sudo permissions and make sure you have provided the correct database information (RDS Endpoint, database name, username and password) before run script.

#!/bin/bash

# Set variables for MySQL RPM and database information
MYSQL_RPM_URL="https://dev.mysql.com/get/mysql80-community-release-el9-1.noarch.rpm"
DB_HOST="replace this with your database endpoint"
DB_NAME="first_cloud_users"
DB_USER="admin"
DB_PASS="12341234"

# Check if MySQL Community repository RPM already exists
if [ ! -f mysql80-community-release-el9-1.noarch.rpm ]; then
  sudo wget $MYSQL_RPM_URL
fi

# Install MySQL Community repository
sudo dnf install -y mysql80-community-release-el9-1.noarch.rpm

# You need the public key of mysql to install the software.
sudo rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2023

# Install MySQL server
sudo dnf install -y mysql-community-server

# Start MySQL server
sudo systemctl start mysqld

# Enable MySQL to start on boot
sudo systemctl enable mysqld

# Check MySQL version
mysql -V

# Create or update the .env file with database information
echo "DB_HOST=$DB_HOST" >> .env
echo "DB_NAME=$DB_NAME" >> .env
echo "DB_USER=$DB_USER" >> .env
echo "DB_PASS=$DB_PASS" >> .env

# Connect to MySQL
mysql -h $DB_HOST -P 3306 -u $DB_USER -p

Then enter your password to login.

CREATE DATABASE IF NOT EXISTS first_cloud_users;

USE first_cloud_users;

CREATE TABLE `user`
(
    `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    `first_name` VARCHAR(45) NOT NULL,
    `last_name` VARCHAR(45) NOT NULL,
    `email` VARCHAR(100) NOT NULL UNIQUE,
    `phone` VARCHAR(15) NOT NULL,
    `comments` TEXT NOT NULL,
    `status` ENUM('active', 'inactive') NOT NULL DEFAULT 'active'
) ENGINE = InnoDB;

INSERT INTO `user`
(`first_name`, `last_name`, `email`, `phone`, `comments`, `status`)
VALUES
('Amanda', 'Nunes', 'anunes@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Alexander', 'Volkanovski', 'avolkanovski@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Khabib', 'Nurmagomedov', 'knurmagomedov@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Kamaru', 'Usman', 'kusman@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Israel', 'Adesanya', 'iadesanya@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Henry', 'Cejudo', 'hcejudo@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Valentina', 'Shevchenko', 'vshevchenko@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Tyron', 'Woodley', 'twoodley@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Rose', 'Namajunas', 'rnamajunas@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Tony', 'Ferguson', 'tferguson@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Jorge', 'Masvidal', 'jmasvidal@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Nate', 'Diaz', 'ndiaz@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Conor', 'McGregor', 'cmcGregor@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Cris', 'Cyborg', 'ccyborg@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Tecia', 'Torres', 'ttorres@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Ronda', 'Rousey', 'rrousey@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Holly', 'Holm', 'hholm@ufc.com', '012345 678910', 'I love AWS FCJ', 'active'),
('Joanna', 'Jedrzejczyk', 'jjedrzejczyk@ufc.com', '012345 678910', 'I love AWS FCJ', 'active');

SHOW DATABASES;
USE first_cloud_users;

SHOW TABLES;
DESCRIBE user;

19 .

Go to application directory.

cd AWS-FCJ-Management/

Once you are in the application directory, run the following command to start the application:

npm start

Get your instance's public IPv4, access it with http through port 5000 and you should see the app is running:

Try to add new user and check.

VI. Clean up

Terminate EC2 instance
Delete DB Instance, also release the Elastic IP addresses if there is any left.
Delete DB Snapshots
Delete VPC

Congratulation!

20 . You can go and check log to see the difference:

V. Create snapshot and restore

Create a snapshot.

Wait for it to be Available.

Choose Restore.

Enter labRDS-restore. Also remember to choose Burstable classes and db.t3.micro. Then Restore DB instance.

You then can return to step 18 to set up a new database connection to labRDS-restore. Re-run the app and you will see it can fetch data normally again.

Amazon RDS - A closer look when create database

Hung____ — Tue, 21 May 2024 07:19:01 +0000

Amazon Relational Database Service (RDS)

Amazon Relational Database Service (RDS) is a managed database service that lets you run relational database systems in the cloud. RDS takes care of setting up the database system, performing backups, ensuring high availability, and patching the database software and the underlying operating system. RDS also makes it easy to recover from database failures, restore data, and scale your databases to achieve the level of performance and availability that your application requires.

Amazon RDS was first released on 22 October 2009, supporting MySQL databases. This was followed by support for Oracle Database in June 2011, Microsoft SQL Server in May 2012, *PostgreSQL **in November 2013, and **MariaDB *(a fork of MySQL) in October 2015, and an additional 80 features during 2017.

In November 2014, AWS announced Amazon Aurora, a MySQL-compatible database offering enhanced high availability and performance, and in October 2017 a PostgreSQL-compatible database offering was launched.

In March 2019 AWS announced support of **PostgreSQL **11 in RDS, five months after official release.

To deploy a database using RDS, you start by configuring a database instance, which is an isolated database environment. A database instance exists in a virtual private cloud (VPC) that you specify, but unlike an EC2 instance, AWS fully manages database instances. You can’t establish an SSH session to them, and they don’t show up under your EC2 instances.

------

Database Engines

A database engine is simply the software that stores, organizes, and retrieves data in a database. Each database instance runs only one database engine. RDS offers the following six database engines to choose from:

Amazon Aurora Aurora is Amazon’s drop-in binary replacement for MySQL and PostgreSQL. Aurora offers better write performance than both by using a virtualized storage layer that reduces the number of writes to the underlying storage. It provides two editions:
- MySQL compatible
- PostgreSQL compatible

Depending on the edition you choose, Aurora is compatible with PostgreSQL or MySQL import and export tools and snapshots. Aurora is designed to let you seamlessly migrate from an existing deployment that uses either of those two open source databases. For MySQL-compatible editions, Aurora supports only the InnoDB storage engine. Also, the Aurora Backtrack feature for MySQL lets you, within a matter of seconds, restore your database to any point in time within the last 72 hours. In addition, the Amazon Aurora Serverless feature can automatically scale your database up and down on- demand. You pay compute costs only for when the database in active, potentially saving you large sums of money in the long run.
- Automatic allocation of storage space in 10 GB increments up to 64 TBs
- Fivefold performance increase over the vanilla MySQL version
- Automatic six-way replication across availability zones to improve availability and fault tolerance

MySQL MySQL is designed for OLTP applications such as blogs and e- commerce. RDS offers the latest MySQL Community Edition versions. MySQL offers two storage engines— MyISAM and InnoDB — but you should use the latter with RDS- managed automatic backups.
MariaDB MariaDB is a drop- in binary replacement for MySQL. It was created due to concerns about MySQL’s future after Oracle acquired the company that developed it. MariaDB supports the XtraDB and InnoDB storage engines, but AWS recommends using the latter for maximum compatibility with RDS.
PostgreSQL PostgreSQL advertises itself as the most Oracle- compatible open source database. This is a good choice when you have in- house applications that were developed for Oracle but want to keep costs down.
Oracle Oracle is one of the most widely deployed relational database management systems. Some applications expressly require an Oracle database.
Microsoft SQL Server RDS offers multiple Microsoft SQL Server versions, ranging from 2012 SP4 GDR to the present. For the edition, you can choose Express, Web, Standard, or Enterprise. The variety of flavors makes it possible to migrate an existing SQL Server database from an on- premises deployment to RDS without having to perform any database upgrades.
IBM Db2 RDS offers multiple IBM Db2 versions, mostly 11.5.9.0 version. For the edition, you can choose Standard, or Advanced. Amazon RDS for Db2 supports most of the features and capabilities of the IBM Db2 database. Some features might have limited support or restricted privileges.

Licensing Considerations

RDS provides two models for licensing the database engine software you run. The license included model covers the cost of the license in the pricing for an RDS instance. The bring your own license (BYOL) model requires you to obtain a license for the database engine you run.

License Included MariaDB and MySQL use the GNU General Public License (GPL) v2.0, and PostgreSQL uses the PostgreSQL license, all of which allow for free use of the respective software. All versions and editions of Microsoft SQL Server that you run on RDS include a license, as does Oracle Database Standard Edition Two (SE2). Bring Your Own License Only the Oracle database engine supports this licensing model. The following Oracle Database editions allow you to bring your own license:

Enterprise Edition (EE)
Standard Edition Two (SE2)

Database Instance Classes

When launching a database instance, you must decide how much processing power, memory, network bandwidth, and disk throughput it needs. RDS offers a variety of database instance classes to meet the diverse performance needs of different databases. If you get it wrong or if your needs change, you can switch your instance to a different class. RDS divides database instance classes into the following three types.

Standard Standard instance classes meet the needs of most databases. The latest- generation instance class is db.m6i, which provides up to:
- 512 GB of memory
- 128 vCPU
- 40 Gbps network bandwidth
- 50,000 Mbps (6,250 MBps) disk throughput
Memory Optimized Memory-optimized instance classes are for databases that have hefty performance require- ments. Providing more memory to a database allows it to store more data in memory, which can result in faster query times. The most memory- optimized instance class is db.x1e, and it provides up to:
- 3,904 GB of memory
- 128 vCPU
- 25 Gbps network bandwidth
- 14,000 Mbps (1,750 MBps) disk throughput Database instances use EBS storage. Both the standard and memory- optimized instance class types are EBS optimized, meaning they provide dedicated bandwidth for transfers to and from EBS storage.
Burstable Performance Burstable performance instances are for development, test, and other nonproduction data- bases. The latest burstable performance instance class available is db.t4g, and it gives you up to:
- 32 GB of memory
- 8 vCPU
- 5 Gbps network bandwidth
- 2,048 Mbps (256 MBps) disk throughput The db.t3, db.m5, and db.r5 classes are based on the AWS Nitro System, accounting for significantly improved performance over older generation instance classes. Note that disk reads and writes count against the maximum disk throughput on these instance classes.

Storage

Understanding Input/Output Operations per Second

IOPS (Input/output operations per second) is a performance indicator that measures the speed and efficiency of a storage device based on the number of read/write operations it can complete within a second. It is also a standard performance benchmark for storage systems, such as hard disk drives (HDD), flash drives, and solid-state drives (SSD).

AWS measures storage performance in input/output operations per second (IOPS). An input/ output (I/O) operation is either a read from or write to storage. All things being equal, the more IOPS you can achieve, the faster your database can store and retrieve data. RDS allocates you a number of IOPS depending on the type of storage you select, and you can’t exceed this threshold. The speed of your database storage is limited by the number of IOPS allocated to it. The amount of data you can transfer in a single I/O operation depends on the page size that the database engine uses.

Example:

MySQL and MariaDB have a page size of 16 KB. Hence, writing 16 KB of data to disk would constitute one I/O operation. Oracle, PostgreSQL, and Microsoft SQL Server, IBM Db2 use a page size of 8 KB. Writing 16 KB of data using one of those database engines would consume two I/O operations. The larger the page size, the more data you can transfer in a single I/O operation.

Assuming a 16 KB page size, suppose your database needed to read 102,400 KB (100 MB) of data every second. To achieve this level of performance, your database would have to be able to read 6,400 16 KB pages every second. Because each page read counts as one I/O operation, your storage and instance class would need to be able to sustain 6,400 IOPS. Notice the inverse relationship between IOPS and page size: the larger your page size, the fewer IOPS you need to achieve the same level of throughput.

Things get interesting when you move beyond a 32 KB page size. If your database engine writes more than 32 KB in a single I/O operation, AWS counts that as more than one I/O operation. For example, reading or writing a 64 KB page would count as two I/O operations. A 128 KB page would count as four I/O operations.

Amazon RDS DB instance storage

The number of IOPS you can achieve depends on the type of storage you select. RDS offers the following three different types of storage.

General Purpose SSD – General Purpose SSD volumes offer cost-effective storage that is ideal for a broad range of workloads running on medium-sized DB instances. General Purpose storage is best suited for development and testing environments.
Provisioned IOPS SSD – Provisioned IOPS storage is designed to meet the needs of I/O-intensive workloads, particularly database workloads, that require low I/O latency and consistent I/O throughput. Provisioned IOPS storage is best suited for production environments.
Magnetic – Amazon RDS also supports magnetic storage for backward compatibility. We recommend that you use General Purpose SSD or Provisioned IOPS SSD for any new storage needs. The maximum amount of storage allowed for DB instances on magnetic storage is less than that of the other storage types. For more information, see Magnetic storage.

Storage autoscaling

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.Autoscaling

If your workload is unpredictable, you can enable storage autoscaling for an Amazon RDS DB instance.

Using a dedicated log volume (DLV) (Only for Provisioned IOPS volume)

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.dlv

You can use a dedicated log volume (DLV) for a DB instance that uses Provisioned IOPS (PIOPS) storage. A DLV moves PostgreSQL database transaction logs and MySQL/MariaDB redo logs and binary logs to a storage volume that's separate from the volume containing the database tables. A DLV makes transaction write logging more efficient and consistent. DLVs are ideal for databases with large allocated storage, high I/O per second (IOPS) requirements, or latency-sensitive workloads.

DLVs are supported for PIOPS storage (io1 and io2 Block Express) and are created with a fixed size of 1,000 GiB and 3,000 Provisioned IOPS.

Availability & durability

Multi-AZ deployments in RDS provide improved availability and durability for database instances, making them an ideal choice for production database workloads.
With Multi-AZ DB instances, RDS synchronously replicates data to a standby instance in a different Availability Zone (AZ) for enhanced resilience. You can change your environment from
Single-AZ to Multi-AZ at any time. Each AZ runs on its own distinct, independent infrastructure and is built to be highly dependable.

In the event of an infrastructure failure, RDS initiates an automatic failover to the standby instance, allowing you to resume database operations as soon as the failover is complete. Additionally, the endpoint for your DB instance remains the same after a failover, eliminating manual administrative intervention and enabling your application to resume database operations seamlessly.

Connectivity

IPv4 Your resources can communicate with your databases only over the IPv4 addressing protocol. Resources include clients and AWS resources, such as EC2 instances.
Dual-stack mode Your resources can communicate over the IPv4 addressing protocol, the IPv6 addressing protocol, or both. If you have any resources that must communicate with your database over IPv6, use dual-stack mode.

Specify the TCP/IP port that the DB instance will use for application connections. The connection string of any application connecting to the DB instance must specify the port number of the DB instance. Both the security group applied to the DB instance and your company’s firewalls must allow connections to the port.

Password authentication Manage your database user credentials through your DB engine's native password authentication features. To learn more, see the documentation for your DB engine.
Password and IAM database authentication Manage your database user credentials through your DB engine's native password authentication features and IAM users and roles. IAM helps an administrator securely control access to AWS resources. IAM administrators control who can be authenticated and authorized for RDS resources.

Monitoring

Monitoring DB load with Performance Insights on Amazon RDS

Performance Insights is an advanced database performance monitoring feature that makes it easy to diagnose and solve performance challenges on Amazon RDS databases.

After you enable this feature for a database instance, you get access to over 50 new CPU, memory, file system, and disk I/O metrics. You can enable these features on a per-instance basis, and you can choose the granularity (all the way down to 1 second).

Additional configuration

Overview of parameter groups

A DB parameter group acts as a container for engine configuration values that are applied to one or more DB instances.

DB cluster parameter groups apply to Multi-AZ DB clusters only. In a Multi-AZ DB cluster, the settings in the DB cluster parameter group apply to all of the DB instances in the cluster. The default DB parameter group for the DB engine and DB engine version is used for each DB instance in the DB cluster.

Working with option groups

Different database engines offer various features or options to help you manage your databases and improve security. Option groups let you specify these features and apply them to one or more instances. Options require more memory, so make sure your instances have ample memory and enable only the options you need.
The options available for a database option group depend on the engine. Oracle offers Amazon S3 integration. Both Microsoft SQL Server and Oracle offer transparent data encryption (TDE), which causes the engine to encrypt data before writing it to storage.
MySQL and MariaDB offer an audit plug- in that lets you log user logons and queries run against your databases.

The backup retention period determines the period for which you can perform a point-in-time recovery

Replicating automated backups to another AWS Region

You can replicate automated backups to another AWS Region to help with disaster recovery. Snapshots and transaction logs are replicated immediately after they are available in the source.

Choose to encrypt the given instance. Master key ids and aliases appear in the list after they have been created using the Key Management Service (KMS) console.

The AWS KMS key is used to protect the encryption key that is used to encrypt this replicated automated backup in the destination AWS Region.

Specifying the logs to publish to CloudWatch Logs

Specify Yes to enable automatic upgrades to new minor versions as they are released. The automatic upgrades occur during the maintenance window for the DB instance.

Protects the database from being deleted accidentally. While this option is enabled, you can’t delete the database.

AWS Pricing Calculator

Amazon RDS pricing

Amazon Route53

Hung____ — Mon, 20 May 2024 09:43:15 +0000

DNS Basic

The record type you enter in a zone file’s resource record will determine how the record’s data is formatted and how it should be used. There are currently around 40 types in active use. Here is some common DNS record types:

An ALIAS record generally maps a name onto an AWS resource.

You can use ALIAS records to route traffic to a resource — such as an elastic load balancer - without specifying its IP address. Although the use of alias records has not yet been standardized across providers, Route 53 makes them available within record sets, allowing you to connect directly with network-facing resources running on AWS.

Amazon Route53

With those DNS basics out of the way, it’s time to turn our attention back to AWS. Route 53 provides more than just basic DNS services. In fact, it focuses on four distinct areas:

Domain registration
DNS management
Availability monitoring (health checks)
Traffic management (routing policies)

Route 53 now also provides an Application Recovery Controller through which you can configure recovery groups, readiness checks, and routing control.

In case you’re curious, the “53” in Route 53 reflects the fact that DNS traffic uses TCP or UDP port 53.

A user opens a web browser, enters www.example.com in the address bar, and presses Enter.
The request for www.example.com is routed to a DNS resolver, which is typically managed by the user's internet service provider (ISP), such as a cable internet provider, a DSL broadband provider, or a corporate network.
The DNS resolver for the ISP forwards the request for www.example.com to a DNS root name server.
The DNS resolver forwards the request for www.example.com again, this time to one of the TLD name servers for .com domains. The name server for .com domains responds to the request with the names of the four Route 53 name servers that are associated with the example.com domain.
The DNS resolver caches (stores) the four Route 53 name servers. The next time someone browses to example.com, the resolver skips steps 3 and 4 because it already has the name servers for example.com. The name servers are typically cached for two days.
The DNS resolver chooses a Route 53 name server and forwards the request for www.example.com to that name server.
The Route 53 name server looks in the example.com hosted zone for the www.example.com record, gets the associated value, such as the IP address for a web server, 192.0.2.44, and returns the IP address to the DNS resolver.
The DNS resolver finally has the IP address that the user needs. The resolver returns that value to the web browser.

The DNS resolver also caches the IP address for example.com for an amount of time that you specify so that it can respond more quickly the next time someone browses to example.com. For more information, see time to live (TTL).
The web browser sends a request for www.example.com to the IP address that it got from the DNS resolver. This is where your content is, for example, a web server running on an Amazon EC2 instance or an Amazon S3 bucket that's configured as a website endpoint.
The web server or other resource at 192.0.2.44 returns the web page for www.example.com to the web browser, and the web browser displays the page.

In Route 53, AWS assigns four name servers for all domains, as shown in the screenshot: one for .com, one for .net, one for .co.uk, and one for .org. Why? For higher availability! If there is an issue with the .net DNS services, the other three continue to provide high availability for your domains.

Amazon Route 53 health checks

You create a health check and specify values that define how you want the health check to work, such as the following:
- The IP address or domain name of the endpoint, such as a web server, that you want Route 53 to monitor. (You can also monitor the status of other health checks, or the state of a CloudWatch alarm.)
- The protocol that you want Amazon Route 53 to use to perform the check: HTTP, HTTPS, or TCP.
- How often you want Route 53 to send a request to the endpoint. This is the request interval.
- How many consecutive times the endpoint must fail to respond to requests before Route 53 considers it unhealthy. This is the failure threshold.
- Optionally, how you want to be notified when Route 53 detects that the endpoint is unhealthy. When you configure notification, Route 53 automatically sets a CloudWatch alarm. CloudWatch uses Amazon SNS to notify users that an endpoint is unhealthy.
Route 53 starts to send requests to the endpoint at the interval that you specified in the health check.
- If the endpoint responds to the requests, Route 53 considers the endpoint to be healthy and takes no action.
If the endpoint doesn't respond to a request, Route 53 starts to count the number of consecutive requests that the endpoint doesn't respond to:
- If the count reaches the value that you specified for the failure threshold, Route 53 considers the endpoint unhealthy.
- If the endpoint starts to respond again before the count reaches the failure threshold, Route 53 resets the count to 0, and CloudWatch doesn't contact you.
If Route 53 considers the endpoint unhealthy and if you configured notification for the health check, Route 53 notifies CloudWatch.
- If you didn't configure notification, you can still see the status of your Route 53 health checks in the Route 53 console. For more information, see Monitoring health check status and getting notifications.
If you configured notification for the health check, CloudWatch triggers an alarm and uses Amazon SNS to send notification to the specified recipients.

Public and private hosted zones

Route 53 supports both public **and private **hosted zones. Public hosted zones have a route to internet-facing resources and resolve from the internet using global routing policies. Meanwhile, private hosted zones have a route to VPC resources and resolve from inside the VPC. It helps to integrate with on-premises private zones using forwarding rules and endpoints.

Routing policy

Route 53 provides the following seven types of routing policies for traffic:

Simple routing policy – This is used for a single resource (for example, a web server cre- ated for the www.example.com website). The limitation of simple routing is that it doesn’t support health checks. There are no checks that the resource being pointed out by the record is actually operational.

Failover routing policy – This is used to configure active-passive failover. A failover routing policy will direct traffic to the resource you identify as primary as long as health checks confirm that the resource is running properly. Should the primary resource go offline, subsequent traffic will be sent to the resource defined within a second record set and designated as secondary. As with other policies, the desired relationship between record sets is established by using matching set ID values for each set.

Geoproximity routing policy – This is used for geolocation when users are shifting from one location to another. Geoproximity routing lets Amazon Route 53 route traffic to your resources based on the geographic location of your users and your resources. It routes traffic to the closest resource that is available. You can also optionally choose to route more traffic or less traffic to a given resource by specifying a value, known as a bias. A bias expands or shrinks the size of the geographic region from which traffic is routed to a resource.

Latency routing policy – This optimizes the best latency for the resources deployed in multiple AWS Regions. Latency- based routing lets you leverage resources running in multiple AWS regions to provide service to clients from the instances that will deliver the best experience. Practically this means that, for an application used by clients in both Asia and Europe, you could place parallel resources in, say, the ap-southeast-1 and eu-west-1 regions. You then create a record set for each resource using latency- based policies in Route 53, with one pointing to your ap-southeast-1 resource and the other to eu-west-1. Assuming you gave both record sets the same value for Set ID, Route 53 will know to direct requests for those resources to the instance that will provide the lowest latency for each client.

Geolocation routing policy – This routes traffic based on the user’s location. Unlike latency policies that route traffic to answer data requests as quickly as possible, geolocation uses the continent, country, or U.S. state where the request originated to decide what resource to send. This can help you focus your content delivery, allowing you to deliver web pages in customer-appropriate languages, restrict content to regions where it’s legally permitted, or generate parallel sales campaigns. You should be aware that Route 53 will sometimes fail to identify the origin of a requesting IP address (particularly when the requests come from VPN users). You might want to configure a default record to cover those cases.

Multivalue answer routing policy – This is used to respond to DNS queries with up to eight healthy, randomly selected records. It’s possible to combine a health check configuration with multivalue routing to make a deployment more highly available. Each multivalue-based record set points to a single resource and can be associated with a health check. As many as 8 records can be pointed to parallel resources and connected to one another through matching set ID values. Route 53 will use the health checks to monitor resource status and randomly route traffic among the healthy resources.

It’s not a substitute for a load balancer, which handles the actual connection process from a network perspective. But the ability to return multiple heal checkable IP addresses is a way to use DNS to improve availability of an application.

Weighted routing policy – This is used to route traffic to multiple resource properties as defined by you (for example, you want to say 80% traffic to site A and 20% to site B). A weighted policy will route traffic among multiple resources according to the ratio you set. To explain that better, imagine you have three servers (or load balancers representing three groups of servers), all hosting instances of the same web application. One of the servers (or server groups) has greater unused compute and memory capacity and can therefore handle far more traffic. It would be inefficient to send equal numbers of users to each of the servers. Instead, you can assign the larger server a numeric weight of, say, 50 and then 25 to the other two. That would result in half of all requests being sent to the larger server and 25 percent to each of the others. To configure a weighted policy in Route 53, you create a separate record set for each of your servers, give the same value for the set ID of each of the record sets, and then enter an instance- appropriate numeric value for the weight. The matching set IDs tell Route 53 that those record sets are meant to work together.

IP-based routing - With IP-based routing, you can create a series of Classless Inter-Domain Routing (CIDR) blocks that represent the client IP network range and associate these CIDR blocks with locations. IP-based routing gives you granular control to optimize performance or reduce network costs by uploading your data to Route 53 in the form of user-IP-to-endpoint mappings.

Geolocation and latency-based routing is based on data that Route 53 collects and keeps up to date. This approach works well for the majority of customers, but IP-based routing offers you the additional ability to optimize routing based on specific knowledge of your customer base. For example, a global video content provider might want to route end users from a particular internet service provider (ISP).

Some common use cases for IP-based routing are the following:
- You want to route end users from certain ISPs to specific endpoints so you can optimize network transit costs or performance.
- You want to add overrides to existing Route 53 routing types, such as geolocation routing, based on your knowledge of your clients' physical locations.

Route 53 Traffic Flow

https://aws.amazon.com/blogs/aws/new-route-53-traffic-flow/

Route 53 Traffic Flow is a console-based graphical interface that allows you to visualize complex combinations of routing policies as you build them.

Because it integrates routing policies with all the possible resource endpoints associated with your AWS account, Traffic Flow can make it simple to quickly build a sophisticated routing structure. You can also use and customize routing templates.
Traffic Flow offers geoproximity routing, which gives you the precision of geolocation routing but at a far finer level. Geoproximity routing rules can specify geographic areas by their relationship either to a particular longitude and latitude or to an AWS region. In both cases, setting a bias score will define how widely beyond your endpoint you want to apply your rule.

Route 53 Resolver

You can now extend Route 53’s powerful routing tools across your hybrid infrastructure using Route 53 Resolver. Resolver can manage bidirectional address queries between servers running in your AWS account and on- premises resources. This can greatly simplify workloads that are meant to seamlessly span private and public platforms.

Comparing EC2 Purchasing Options

Hung____ — Fri, 17 May 2024 10:15:02 +0000

On-Demand Instances With On-Demand Instances, you pay for compute capacity by the hour or by the second depending on which instances you run. No longer-term commitments or upfront payments are needed. You can increase or decrease your compute capacity depending on the demands of your application and only pay the specified rates for the instance you use.

On-Demand Instances are recommended for the following:

Users who prefer the low cost and flexibility of Amazon EC2 without any upfront payment or long-term commitment
Applications with short-term, irregular, or unpredictable workloads that cannot be interrupted
Applications being developed or tested on Amazon EC2 for the first time

Sample use cases for On-Demand Instances include developing and testing applications and running applications that have unpredictable usage patterns. On-Demand Instances are not recommended for workloads that last a year or longer because these workloads can experience greater cost savings using Reserved Instances.

Savings Plans are a flexible pricing model offering lower prices compared to On-Demand pricing, in exchange for a s*pecific usage commitment* (measured in $/hour) for a 1- or 3-year period. Savings Plans offer the flexibility to evolve your usage and continue to save money. For example, if you have a Compute Savings Plan, lower prices will apply automatically when you take advantage of new instance types.

AWS offers three types of Savings Plans:

Compute Savings Plans apply to usage across Amazon EC2, AWS Lambda, and AWS Fargate.
EC2 Instance Savings Plans apply to EC2 usage.
Amazon SageMaker Savings Plans apply to Amazon SageMaker usage.

With Amazon EC2 Savings Plans, you can reduce your compute costs by committing to a consistent amount of compute usage for a 1- or 3-year term. This term commitment results in savings of up to 66 percent over On-Demand costs.

Any usage up to the commitment is charged at the discounted plan rate (for example, $10 an hour). Any usage beyond the commitment is charged at regular On-Demand rates.

Reserved Instances (RIs) are a billing discount applied to the use of On-Demand Instances in your account. You can purchase Standard RIs and Convertible RIs for a 1- or 3-year term. You realize greater cost savings with the 3-year option.

There are two types of RIs to choose from:

-** Standard RIs**: These provide the most significant discount (up to 72 percent off On-Demand) and are best suited for steady-state usage.

Convertible RIs: These provide a discount (up to 54 percent off On-Demand) and the capability to change instance families, OS types, and tenancies while benefitting from RI pricing. Like Standard RIs, Convertible RIs are best suited for steady-state usage.

RIs are recommended for the following:

Steady-state loads and long-running systems
Core components with minimal high peaks and valleys of usage

At the end of an RI term, you can continue using the Amazon EC2 instance without interruption. However, you are charged On-Demand rates until you do one of the following:

Terminate the instance.
Purchase a new RI that matches the instance attributes (instance type, Region, tenancy, and platform).

Spot Instances With Amazon EC2 Spot Instances, you can request spare Amazon EC2 computing capacity for up to 90 percent off the On-Demand price.

Spot Instances are recommended for the following:

Applications that have flexible start and end times and can tolerate interruptions
Applications that you want to run or test only when the compute prices are in your price range
Applications that are a lower priority in your environment
Users with urgent computing needs for large amounts of additional capacity at a price they determine

Suppose that you have a background processing job that can start and stop as needed (such as the data processing job for a customer survey). You want to start and stop the processing job without affecting the overall operations of your business. If you make a Spot request and Amazon EC2 capacity is available, your Spot Instance launches. However, if you make a Spot request and Amazon EC2 capacity is unavailable, the request is not successful until capacity becomes available. The unavailable capacity might delay the launch of your background processing job.

After you have launched a Spot Instance, if capacity is no longer available or demand for Spot Instances increases, your instance may be interrupted. This might not pose any issues for your background processing job.

A Dedicated Host is a physical EC2 server dedicated for your use. Dedicated Hosts can help you reduce costs by letting you use your existing server-bound software licenses, including Windows Server, SQL Server, and SUSE Linux Enterprise Server (subject to your license terms). They can also help you meet compliance requirements.

Features of Dedicated Hosts

Can be purchased On-Demand (hourly)
Can be purchased as a Reservation for up to 70 percent off the On-Demand price

Dedicated Hosts are recommended for the following:

Workloads that require server-bound software licenses
Security and regulatory compliance where your workload cannot share hardware with other tenants

Dedicated Instances

You can use Dedicated Hosts and Dedicated Instances to launch Amazon EC2 instances on physical servers that are dedicated for your use. With Dedicated Instances, all of your instances reside on one single host that is allocated to your AWS account so that no other AWS accounts can place instances on this host.

An important difference between a Dedicated Host and a Dedicated instance is that a Dedicated Host gives you additional visibility and control over how instances are placed on a physical server and you can consistently deploy your instances to the same physical server over time. As a result, with Dedicated Hosts, you can use your existing server-bound software licenses and address corporate compliance and regulatory requirements.

Clarify what a Spot Instance is

Use Case Examples

Spot Instances are recommended for stateless, fault-tolerant, flexible applications. For example, Spot Instances work well for big data, containerized workloads, continuous integration and continuous delivery (CI/CD), stateless web servers, high performance computing (HPC), and rendering workloads.

While running, Spot Instances are exactly the same as On-Demand Instances. However, Spot does not guarantee that you can keep your running instances long enough to finish your workloads. Spot also does not guarantee that you can get immediate availability of the instances that you are looking for, or that you can always get the aggregate capacity that you requested. Moreover, Spot Instance interruptions and capacity can change over time because Spot Instance availability varies based on supply and demand, and past performance isn’t a guarantee of future results.

Spot Instances are not suitable for workloads that are inflexible, stateful, fault intolerant, or tightly coupled between instance nodes.
They're also not recommended for workloads that are intolerant of occasional periods when the target capacity is not completely available.
We strongly warn against using Spot Instances for these workloads or attempting to fail over to On-Demand Instances to handle interruptions.

Ways to request Spot Instances

To use Spot Instances, you create a Spot Instance request that includes the desired number of instances, the instance type, the Availability Zone, and the maximum price that you are willing to pay per instance hour. If your maximum price exceeds the current Spot price, Amazon EC2 fulfills your request immediately if capacity is available. Otherwise, Amazon EC2 waits until your request can be fulfilled or until you cancel the request. There are two request types: one-time and persistent.

A one-time Spot Instance request remains active until Amazon EC2 launches the Spot Instance, the request expires, or you cancel the request. If the Spot price exceeds your maximum price or capacity is not available, your Spot Instance is terminated and the Spot Instance request is closed.

A persistent Spot Instance request remains active until it expires or you cancel it, even if the request is fulfilled. If the Spot price exceeds your maximum price or capacity is not available, your Spot Instance is interrupted. After your instance is interrupted, when your maximum price exceeds the Spot price or capacity becomes available again, the Spot Instance is started if stopped or resumed if hibernated. You can stop a Spot Instance and start it again if capacity is available and your maximum price exceeds the current Spot price. If the Spot Instance is terminated, the Spot Instance request is opened again and Amazon EC2 launches a new Spot Instance.

The previous illustration shows how Spot Instance requests work. Notice that the request type (one-time or persistent) determines whether the request is opened again when the instance is interrupted or if you stop a Spot Instance. If the request is persistent, the request is opened again after your Spot Instance is interrupted. If the request is persistent and you stop your Spot Instance, the request only opens after you start your Spot Instance.

Key takeaways

On-Demand Instances – You pay full price by the second when you launch.
Savings Plans – You commit to a certain amount of usage over a 1–3-year period.
Reserved Instances – You agree to a specific instance configuration for a period of 1–3 years.
Spot Instances – This refers to unused instance resources that you can bid on. Your price is determined by market availability.
Dedicated Hosts – You get a full physical server.
Dedicated Instances - Instances are placed on a single host with no access to the underlying host.