DEV Community: AWS Community On Air

Making Cloud Cost Analysis Smarter: Building FinOps Intelligent Agents with Strands and AgentCore

Eliana Lam — Sun, 23 Nov 2025 11:46:06 +0000

Speaker: Xiaofei Li @ AWS Amarathon 2025

Summary by Amazon Nova

The year 2025 is known as the "Year One of AI Agents," and it's just two months away.

Users have already developed their own AI Agents.
Programming agents are a type of AI agent.
AI agents are various "smart-looking applications" that utilize AI.
Examples include: meeting minutes agents, interview preparation agents, and programming agents.

Characteristics of "AI Agents" in the LLM era:

Role profiling: can define roles or personalities, achieving personalized behavior and responses.
Planning and reflection: to achieve goals, agents can formulate plans and make adjustments based on execution results.
Long-term memory: can retain long-term interaction information or experiences like humans.
Tool execution: can not only generate text but also call various external tools or APIs to perform operations.
AI Agents can help solve practical problems, such as cost analysis agents.
How to use Amazon Web Services to develop cost analysis agents.

How to build AI Agents:

Bedrock Agents
AgentCore: deploy self-developed agents in a serverless manner, providing authentication, tools, observability, and other functions.
Strands Agents: a framework for Python, requiring only a minimum of 3 lines of ultra-concise code to implement an AI agent.
Building FinOps agents with Strands Agents.

Open-source AI Agent framework—Strands Agents

Create AI agents with just 3 lines of Python code
Advantages: simple, lightweight, good development experience
Applied to Amazon Web Services, such as Amazon Q Developer
Strands core concept: combining "models" and "tools"
With the improvement of LLM capabilities, building AI agents only requires specifying models and tools
Agent creation: set LLM and system prompts, and call by providing prompts
Equip agents with tool capabilities: Strands provides built-in tools, such as calculation and file operations
You can write your own tools by adding @tool to Python functions
Obtain tools provided by MCP servers, compatible with local and remote MCP servers
Build multiple agents: Agent as Tools, Swarm, Graphs, Workflows
Agent as Tools example: supervisor-subordinate model, where the supervisor agent assigns sub-tasks, calls sub-agents to execute, and summarizes results
Popular trend after MCP: A2A (Agent to Agent) support
A2A on Strands construction example: there are specialized classes that can call remote agents using Tool Use
Agent deployment: quickly deploy through Bedrock AgentCore

Troubles of AI Agent deployment:

Complicated deployment process
Authentication and authorization issues
Maintenance and monitoring challenges
Running cost issues
Whether streaming output is supported

What is Bedrock AgentCore?

It is a "convenient component set" dedicated to AI agents
Includes functions such as Runtime (serverless infrastructure), Memory (memory management), Gateway (tool integration), Identity (authentication/authorization), and Observability (maintenance and monitoring)
Can be used with any preferred agent framework, selecting functions as needed, and easily integrated through APIs

The core of the entire system is the runtime

Regardless of the framework used to develop AI agents, they can be easily deployed in a serverless environment
Similar to containerized Lambda specifically prepared for AI agents
With the help of a dedicated CLI toolkit, deployment operations can be easily completed
The backend part is completed, and the next step is to consider the implementation plan for the frontend

Streamlit for the frontend page:

Beginner-friendly
You can easily write a beautiful interface with Python
Simply associate code repositories such as Next.js or React to achieve automatic deployment
For backend engineers who are not proficient in JavaScript, this is a good choice
The Gen2 version has achieved significant evolution and performance improvement.

Key Takeaway

Cloud cost analysis is crucial for both enterprises and individuals. In the Year One of AI Agents, you can quickly build AI agents that help analyze cloud costs using Amazon Web Services' technology stack.
Strands Agents is a framework for flexibly building multi-agent systems, requiring only 3 lines of Python code to set up AI agents, featuring extreme simplicity and high scalability.
Strands Agents support MCP and A2A protocols, enabling collaboration and tool sharing among agents.
Strands Agents can seamlessly integrate with Bedrock AgentCore to achieve production-level deployment.
Using AgentCore can simplify the deployment and maintenance process. The Runtime component provides a serverless runtime environment with automatic scaling.
Components such as Memory, Identity, Gateway, and Observability provide integrated capabilities for memory, authentication, tool integration, and monitoring.
Automatic packaging and deployment through CLI can quickly enter the production environment.

Amazon Bedrock AgentCore architecture

Core Services

AgentCore Runtime: A secure, serverless execution environment that hosts your AI agent or tool code. It offers complete session isolation for security and supports long-running asynchronous tasks up to 8 hours.
Framework: Supports popular open-source agent frameworks (e.g., LangGraph, CrewAI) and any foundation model.
Agent Instructions: Defines the behavior and capabilities of the agent.
Agent Local Tools: Tools that are local to the specific agent for performing tasks.
Agent Context: Manages the ephemeral, session-specific state within a conversation.
AgentCore Gateway: Provides a secure way for agents to discover and connect with tools and resources. It can transform existing APIs (like Lambda functions or OpenAPI specs) into agent-compatible tools, minimizing custom integration work.
AgentCore Memory: Enables agents to have context-aware conversations by managing both short-term and long-term memory. It stores conversational context and extracts persistent knowledge like user preferences across sessions.
AgentCore Identity: Offers secure, scalable identity and access management for agents. It handles authentication and authorization, allowing agents to securely access AWS resources and third-party services on behalf of users.
CloudWatch GenAI Observability (AgentCore Observability): Provides comprehensive monitoring, tracing, and debugging capabilities for agent performance in production. It offers deep operational insights into the agent's workflow, powered by Amazon CloudWatch and OpenTelemetry compatible telemetry.

Built-in Tools

AgentCore Code Interpreter: Allows agents to write and execute code securely in isolated sandbox environments for complex tasks like data analysis or calculations.
AgentCore Browser: Provides a fast, secure, cloud-based browser runtime for agents to interact with and extract information from websites at scale.

External Interactions

App & Models: The agent system interacts with user applications and various foundation models (FMs) from Amazon Bedrock or other providers to perform its tasks.

Amazon Bedrock AgentCore starter toolkit

Code: The process starts with the source code for the AI agent.
Build: The "agentcore launch" command within the toolkit automatically triggers an AWS CodeBuild project.
Container: CodeBuild compiles the agent code into a container image, optimized for the environment (e.g., ARM64 architecture).
ECR (Elastic Container Registry): The built container image is "Pushed" to an Amazon ECR repository, which serves as persistent storage for the image.
AgentCore Runtime: The image is then deployed to the secure, serverless Amazon Bedrock AgentCore Runtime, the execution environment for the AI agent.
X-Ray: The system integrates with AWS X-Ray for observability, providing tracing and debugging capabilities for the agent's performance in production.
Automation: The bottom text indicates that the agentcore-starter-toolkit automatically handles these configuration and deployment steps.

Team:

Accelerating Large-Scale Robot Strategy Training: An Automated Closed-Loop Architecture Based on Kiro, Trainium, and EKS

Eliana Lam — Sun, 23 Nov 2025 10:03:25 +0000

Speaker: Junjie Tang @ AWS Amarathon 2025

Summary by Amazon Nova

Guidance for AI-Driven Robotics

Overview of objectives and benefits: integrate

Scalable Robotic

1: NVIDIA Isaac Sim for physics-based
2: Amazon EC2/EKS & Amazon Batch for scalable, parallel execution
3: Amazon Bedrock foundation models, and agents via MCP server for AI
4: Hugging Face LeRobot (LeRobot aims to provide models, datasets, and tools for real-world robotics in PyTorch. The goal is to lower the barrier to entry to robotics.)
5: Outcome: parallel simulations
Cloud-native pipeline combining NVIDIA Isaac Sim, Amazon compute, Bedrock models, MCP agents

Significance and Impact of

Faster training Scalable fleets Real-time reasoning Continuous
Drastically reduces
Enables parallel
Supports real-time
Continuous
Outcome: iterative

Target Industries for

Where simulation-driven training delivers safer, faster, tailored
Manufacturing Automation: Safer Commissioning, Reduced
Warehouse & Logistics, Robotics
Retail & Delivery: Efficient
Healthcare Assistive Robotics: Safer Patient
Agricultural & Environmental Robotics

Delivery Agent from

Amazon Professional Services
A comprehensive agent system across the consulting cycle

Enterprise-Grade Quality and Security

Multiple validation layers mitigate AI hallucinations
Secure, customer-controlled environments
Human oversight at strategic checkpoints
Comprehensive security controls and protocols

AWS Professional Services (ProServe) agents

A multi-agent AI system architecture, for software development and delivery, associated with AWS Professional Services (ProServe) agents. The agents interact to create and manage software solutions.
Sales Agent: The starting point, which initiates the process by feeding requirements or information into the workflow.
Delivery Agent: The central orchestrator that analyzes requirements, builds AI applications directly, and coordinates specialized work by delegating tasks to other agents.
Project Artifacts: An output generated from the initial input, likely documentation or initial plans, used by the Design Agent.
Design Agent: Takes "Project Artifacts" and produces a "Spec Package". It can also provide "Feedback" back to the Delivery Agent or the "Project Artifacts" step.
Spec Package: The output from the Design Agent, containing specifications for the build process.
Build Agent: Uses the "Spec Package" (guided by "Autopilot", an internal mechanism) to generate "Coding Artifacts".
Coding Artifacts: The generated code or application components resulting from the Build Agent's work.
Custom agents on AWS Transform: A separate, connected process that integrates with the main flow.
Security Agent: A persistent layer of the architecture, monitoring or enforcing security policies throughout the process.
Amazon Cloud stage/dev: Represents AWS environments (staging and development) where the resulting artifacts are deployed or managed.
Coding Artifacts are sent to the "dev" environment.
The "stage" environment appears to be an output or endpoint for the "Custom agents" process.
The system uses intelligent agents to potentially automate and accelerate the software development lifecycle, improving efficiency and quality.

Team:

Accelerating Migration Projects with Kiro using Spec Driven Development

Eliana Lam — Sun, 23 Nov 2025 09:17:11 +0000

Speaker: Sanchit Dilip Jain @ AWS Amarathon 2025

Summary by Amazon Nova

What is Amazon Kiro?

Compatible with VS Code
Utilizes cutting-edge Claude models
Enterprise-grade security

Closing the Idea-to-Code Gap

Addresses the challenge of product ideas losing fidelity when passed from PM to engineer
Kiro acts as an AI co-author, converting informal briefs into living, version-controlled specifications
Eliminates ambiguity before coding starts, accelerating delivery cycles

Traditional Static Docs vs. Kiro's Living Specs

Traditional static docs are prone to staleness and lead to high rework and surprises
Kiro's Living Specs auto-update with code, sync with tests & metrics, and result in measurable gains in velocity

Amazon Kiro Workflow

SDLC in Amazon Kiro Way!
Ingest: Product brief intake
Expand: AI expands user stories
Iterate: Collaborative editing
Lock & Stub: Spec finalization
Every step is traceable, commentable, and under Git control

Prompt Engineering for Precision

Concise, context-rich prompts yield the most accurate and useful specifications

Fill-in-the-Blank Template:

Persona: Who is the user?
Problem: What do they need to do?
Outcome: What does success look like?
Non-Goals: What is out of scope?

Iterative Refinement Process:

Human Prompts
AI Suggests
Human Validates
This cycle repeats until the spec passes all internal quality gates

Modernizing Legacy with Amazon Kiro

Prescriptive pattern to migrate critical COBOL, PL/I, and Assembler to manage Java on Graviton without rewriting core business logic
Automated Transformation: Converts legacy code to modern Java microservices
Data Replication: Syncs mainframe data to cloud databases in real-time
DevOps Integration: Establishes CI/CD pipelines for rapid, reliable releases

Automated Code Transformation Engine

Parse: Legacy source is converted into an Abstract Syntax Tree (AST)
Refactor: Rule-based transformations are applied to modernize the code structure
Emit: Idiomatic Java code is generated as Spring Boot microservices
Preserves data formats, transaction boundaries, and audit trails

Data Sync & Mainframe Off-Loading

AWS DMS and Kiro agents replicate mainframe data to Aurora PostgreSQL in near-real time
Bidirectional Sync: Mainframe remains authoritative during pilot phases
Zero-Downtime Cut-Over: Traffic is switched to the cloud via a simple DNS flip

Zero-Trust Security

Every microservice is isolated and secured by default
Least-Privilege IAM: Unique IAM role with minimal permissions
Encryption: KMS encrypts data at rest and in transit
Continuous Monitoring: CloudTrail and Guard Duty provide audit evidence for SOX, PCI, and HIPAA

Role-Based Access & Reviews:

[ 1 ] Product Manager: Owns the narrative and user-facing requirements
[ 2 ] Tech Lead: Owns the system architecture and technical design
[ 3 ] QA Engineer: Owns the acceptance criteria and test plans
Amazon Kiro tracks approvals, surfaces unresolved comments, and blocks merge until all roles sign off

Real-World Impact Case Study: Global Bank

A top-20 bank used Kiro to migrate 14 million lines of COBOL for retail payments
Seamless cut-over over a single weekend with zero failed transactions
68% cost reduction in infrastructure
90% reduction in MIPS (Mainframe load)
Release frequency rose from quarterly to weekly, freeing budget for AI initiatives

Your Migration Roadmap

6-Week Pilot Blueprint:
- Week 1-2: Provision & Transform
- Week 3: Validate Parity
- Week 4: CI/CD Pipeline
- Week 5: 5% Traffic
- Week 6: Metrics & Review

Team:

A Developer’s Roadmap to Architecting for Agents

Eliana Lam — Sun, 23 Nov 2025 07:21:10 +0000

Speaker: Donnie Prakoso @ AWS Amarathon 2025

Summary by Amazon Nova

Developer’s roadmap

future-architect
Content generation
Learning RAG
Amplifying development skills
Building AI Agent
Integrating MCP
Agentic communication

It’s growing at a fast pace...

Agentic Development

Developing WITH agent
Code generation
AI-DLC (AI-Driven Development Lifecycle, a modern software development methodology that positions artificial intelligence as a central collaborator)
Agentic IDE
Vibe coding
Spec-driven

Developing FOR agent

Scaling
Deployment

Developing Agent

Single-agent vs Multi-Agent
MCP
Guardrails
Observability
Best practices
API

Agentic AI Systems

Built Using
Agent
Autonomous Decision Making
Iterative Problem Solving
Goal-Oriented Behavior

Agentic Patterns

Pattern Types
Reflection
Tool Use
Planning
Multi-Agent

Content Generation

Choose your models
Prompt engineering
Parameters
How to interact with Bedrock API

RAG with Amazon Bedrock Knowledge Base

Use RetrieveAndGenerate API
Setup your RAG
Choose suitable model

KIRO

The AI IDE for prototype to production
Spec based Development
Steering ( the process of guiding or controlling an AI system's behavior, responses, and development in a desired direction. This can involve fine-tuning models for specific tasks)
Automate with Agent Hooks (automated triggers within a development environment (IDE) that execute predefined AI agent actions in response to specific events, such as saving or creating a file. They are designed to automate repetitive tasks, ensure consistency, and streamline the development workflow)
Checkpointning
Property-based testing - PBT (software testing methodology that focuses on verifying general properties or invariants of a system under test, rather than checking specific examples with predefined inputs and expected outputs. PBT utilizes a generative engine to automatically create diverse and randomized inputs to thoroughly explore the input space.)

AI through agent is changing development

Agentic Development
Developing WITH agent
Developing FOR agent
Developing Agent

Multi-agent patterns landscape

Graph
Workflow
Swarm (allows specialized agents to work together by handing off control to one another, creating more complex and robust workflows than a single agent could achieve alone.)

Multi-agent — Swarm

Dynamic handoffs between specialized agents
Emergent paths - agents decide who to hand off to next
Shared context and working memory across all agents
Autonomous collaboration with minimal orchestration
Use Case: Development projects, research projects

“What’s the future look like with GenAI?”

The future of microservices isn't just about better APIs - It's about intelligent services that communicate through AI agents
GenAI can write your code and run your workflows, but it can't replace your understanding of why the system needs to exist in the first place.

Agentic communication proof of concept

This architecture diagram illustrates an AWS-based system for agentic AI applications using Amazon Bedrock AgentCore Runtime and Strands Agents SDK. The system utilizes the Model Context Protocol (MCP) to integrate with various microservices implemented via AWS Lambda and Amazon DynamoDB.

AgentCore Runtime: The core execution platform for running AI agents with enterprise-grade features such as session isolation (using microVMs), scalability, and observability.
Strands Agents: An open-source, code-first Python SDK for building the agent's logic, including handling state, tool orchestration, and multi-step reasoning.
AgentCore Gateway: Provides secure ingress connectivity and a unified interface for agents to access tools, including existing MCP servers, REST APIs, and Lambda functions.
Model Context Protocol (MCP): An open standard and client-server architecture that enables AI models to communicate with external data sources and tools.
MCP Servers: Lightweight programs that expose specific capabilities (tools) to the AI agent.
Microservices: The system is composed of several serverless microservices), each implemented using AWS Lambda functions and backed by Amazon DynamoDB for data persistence.
Workflow: The Strands Agents running in AgentCore Runtime can make decisions and use tools by communicating through the AgentCore Gateway to invoke the various MCP servers, which in turn trigger the relevant microservices.

Team:

From Vibe to Viable with spec driven development

Eliana Lam — Sat, 22 Nov 2025 05:35:03 +0000

Speaker: Ricardo Sueiras @ AWS Amarathon 2025

Summary by Amazon Nova

Beyond Borders

AI is changing software

2023: Helping developers write code faster
2024: Generating larger pieces of code and answering questions
2025: Completing development tasks end-to-end with human in the loop

Challenges with AI development

Scaling AI development: AI coding tools excel at small tasks but can fail with complex projects
Limited control: Existing tools make it difficult to collaborate with and manage agents
Code quality: Getting a project from proof-of-concept to production while maintaining quality control becomes increasingly difficult

The Vibe

Rapid, conversational code generation (CHOP)
Iterative, back and forth
Ephemeral
Point in time prompts
Transient context

The path to spec driven development

Good practices

Break down large problems: Developers learned how to manually break down large problems into smaller units and build incrementally
Specificity and Clarity: Precision and clarity are key in directing AI coding assistants to generate good outputs
Context and Prompt engineering: Providing the right context is key to producing consistency and control

Taskmaster

A task management system for AI-driven development with Clauide, designed to work seamlessly with Cursor AI
[ 1 ] Documentation:
Configuration Guide: Set up environment variables and customize Task Master
Tutorial: Step-by-step guide to getting started with Task Master
Command Reference: Complete list of all available commands
Task Structure: Understanding the task format and features
Example Interactions: Common Cursor AI interaction examples
Migration Guide: Guide to migrating to the new project structure
[ 2 ] Quick Install for Cursor 1.0+ (One-Click):
Click the copy button (top-right of code block) then paste into your browser: cursor://anysphere.cursor-deeplink/mc/install?name=taskmaster-aiconfig-eyJjIjI1biWSkI1joibnB4I
Note: After clicking the link, you'll still need to add your API keys to the configuration. The link installs the MCP server with placeholder keys that you'll need to replace with your actual API keys
[ 3 ] Requirements:
Taskmaster utilizes AI across several commands, and those require a separate API key. You can use a variety of models from different AI providers provided you add your API keys. For example if you want to use Clauide 3.7

The Calm Coding Philosophy

Code not with stress, but with structure.
Prompt not with noise, but with intent.
Build not just fast — but with flow.

Chat is a bad UI pattern for development tools

Code forces humans to be precise. That's good—computers need precision. But it also forces humans to think like machines.
For decades we tried to fix this by making programming more human-friendly. Higher-level languages. Visual interfaces. Each step helped, but we were still translating human thoughts into computer instructions.
AI was supposed to change everything. Finally, plain English could be a programming language—one everyone already knows. No syntax. No rules. Just say what you want.
The first wave of AI coding tools squandered this opportunity. They make flashy demos but produce garbage software. People call them “great for prototyping,” which means “don’t use this for anything real.”
Many blame the AI models, saying we just need them to get smarter. This is wrong. Yes, better AI will make better guesses about what you mean. But when you’re building serious software, you need a better approach.

A written specification aligns humans

The use of EARS notation helps provide precise and structured instructions to the underlying LLMs

What is spec driven development?

Spec Driven Development: Clarity before code, iterative refinement, code via persistent docs
Invest time to understand what you are trying to build
Iterate and capture evolution of what you are trying to build
From ephemeral chat to persistent documents that can be shared with your stakeholders

Spec Driven Development

Define the vision: Create clear requirements and design specifications.
Make architectural decisions: Choose technologies, patterns, and approaches upfront.
Implement with context: Use AI to generate code that fulfills your documented specifications.

The Vibe

Prompts to chase implementations
Rapid, conversational AI code generation (CHOP)
Iterative, back and forth
Ephemeral
Point in time

Spec driven

Focus on upfront planning and intent
Break down requests into discrete tasks
Steering documents ground agentic

The AI IDE for prototype to production

Kiro helps you do your best work by bringing structure to AI coding with spec-driven development.

Team:

Building Streaming Iceberg Tables for Real-Time Logistics Analytics

Eliana Lam — Sat, 22 Nov 2025 05:33:02 +0000

Speaker: Fahad Shah @ AWS Amarathon 2025

Summary by Amazon Nova

Modern Logistics Challenges:

Managing multiple streams for trucks, drivers, routes, fuel, maintenance, shipments, and warehouses.
Need for real-time operational views and long-term analytics.

Data Storage Requirements:

Fresh, joined views for immediate operations.
Use of Apache Iceberg for long-term analytics.

Technology Stack:

RisingWave: Data platform for streaming capabilities.
Lakekeeper: Open REST catalog for data management.
Kafka: Event backbone for streaming data.
Object Storage (e.g., MinIO): Storage solution for data.

Objective:

Demonstrate how to build streaming Iceberg tables using the specified open stack.
Provide a simple and effective solution for modern logistics data management.

The Logistics Analytics Problem

Today's logistics platforms generate:
Trucks: fleet inventory and locations
Drivers: rosters and assignments
Shipments: origin, destination, and weight
Warehouses: capacity and sites
Routes: ETAs and distances
Fuel & Maintenance: cost and reliability signals
The challenge:
Operational teams need fresh, joined views across all of these streams.
Data teams need the same data in Iceberg for BI, AI, and historical analysis.

What We’ll Build (Streaming Iceberg Pattern)

Kafka feeds seven logistics topics into RisingWave.
A multi-way streaming join is expressed in SQL and materialized continuously inside RisingWave.
The result is persisted from RisingWave as a native Apache Iceberg table in S3-compatible object store like MinIO.
Engines like Spark, Trino, and DuckDB query the same Iceberg tables via an open REST catalog.

Why Streaming Iceberg Tables with RisingWave?

[ 1 ] Batch-first workflows:
Periodic jobs, stale joins, and heavy pipelines.
Separate ETL tools to write into Iceberg.
[ 2 ] RisingWave + streaming Iceberg tables:
Continuously updated joins and aggregates in RisingWave MVs.
Iceberg snapshots that are always “almost current.”
One RisingWave pipeline that serves both real-time dashboards and offline analytics.
Goal: Make Iceberg feel like a database by letting RisingWave own the streaming pipeline and Iceberg writes.

High-Level Architecture

Our end-to-end stack:
Kafka — event backbone for 7 logistics topics.
RisingWave (streaming database) — ingest, join, and aggregate in SQL; manage materialized views.
RisingWave Iceberg Table Engine + Lakekeeper — open REST catalog over Iceberg tables.
MinIO — S3-compatible object storage.
Pattern: Kafka → RisingWave → Iceberg in MinIO → Query from any engine via REST catalog.

Logistics streams in RisingWave & multi-way streaming joins

The Seven Logistics Streams in RisingWave
Our running example uses seven Kafka topics that become sources in RisingWave:
trucks — fleet inventory, capacity, current location.
driver — driver details and assigned_truck_id.
shipments — origin, destination, weight, truck binding.
warehouses — warehouse location and capacity.
route — route_id, truck_id, driver_id, ETD/ETA, distance_km.
fuel — refueling events (time, liters, station).
maint — maintenance history and costs.
RisingWave treats each one as a streaming table, ready to be joined with simple PostgreSQL-style SQL.

Pattern 1: Multi-Way Streaming Join in RisingWave

In RisingWave, we express the core logistics logic as one multi-way streaming join.
LEFT JOIN drivers → trucks to keep unmatched drivers visible.
JOIN shipments to attach workload and destinations.
JOIN warehouses to bring in capacity and location.
JOIN route for ETD/ETA and distance.
JOIN fuel and maint for cost and reliability signals.
This becomes logistics_joined_mv — a continuously updated, denormalized logistics record per truck/driver/route inside RisingWave.

Fleet KPIs, native Iceberg tables & cross-engine reads

Pattern 2: Fleet KPIs View in RisingWave

On top of the joined MV, we define another RisingWave MV for fleet KPIs:
Capacity utilization (%) per truck.
Total fuel cost and maintenance cost per truck.
Combined total operational cost.
Current route context (ID, ETD, ETA, distance_km).
Associated driver details. overview in RisingWave becomes a live fleet performance table — for Grafana and operational dashboards.

Pattern 3: Streaming to Native Iceberg from RisingWave

Instead of a custom writer service:
[ 1 ] We define logistics_joined_iceberg as a native Iceberg table managed by RisingWave.
[ 2 ] The schema mirrors logistics_joined_mv.
[ 3 ] A small config in RisingWave controls how often streaming changes are committed as Iceberg snapshots.

Pattern 4: Cross-Engine Reads via REST Catalog

With the Iceberg table created by RisingWave and registered in a Lakekeeper REST catalog:
[ 1 ] Spark attaches lakekeeper as a catalog
[ 2 ] Trino / DuckDB / Dremio can use their Iceberg connectors to read the same table.
[ 3 ] All engines see the same Iceberg data that RisingWave continuously updates.
No copies, no proprietary table formats — just plain Iceberg, written by RisingWave.

From local laptop to production cluster: deployment options

Deployment Options: From Laptop to Cluster
[ 1 ] Local (for learning and prototyping):
Run RisingWave, Kafka, MinIO, and Lakekeeper with Docker.
Perfect for experimenting with streaming joins and Iceberg tables on your laptop.
[ 2 ] Production (for real workloads):
Deploy RisingWave and the rest of the stack via Kubernetes + Helm.
Use storage classes, resource limits, and persistence suitable for your environment.
Same SQL and patterns in RisingWave — just more durable, scalable, and automated.

Simplifying the Traditional Iceberg Stack

Traditional Iceberg deployments often require:
A separate stream processing engine.
Standalone Iceberg writer jobs.
External compaction and maintenance workflows.
Extra glue to keep catalogs, writers, and storage aligned.
With RisingWave:
[ 1 ] The streaming database handles ingestion, joins, materialized views, and Iceberg writes.
[ 2 ] The REST catalog + MinIO keep everything fully open and interoperable.
Fewer moving parts, less operational overhead.

Reference architecture with RisingWave

Think of the system in three layers, centered on RisingWave:
[ 1 ] Streams → RisingWave Tables.
Kafka topics become streaming tables in RisingWave.
[ 2 ] Tables → RisingWave Materialized Views.
Streaming joins and aggregates become live MVs (logistics_joined_mv, truck_fleet_overview).
[ 3 ] Views → Streaming Iceberg Tables.
RisingWave turns an MV into a streaming Iceberg table with a small config and an INSERT....SELECT.
Once you see RisingWave as the “streaming SQL + Iceberg engine”, you can reuse this model in many domains.

Reusable Patterns Beyond Logistics

The RisingWave + Iceberg pattern applies to:
E-commerce: orders, inventory, pricing, customer events.
FinTech: transactions, balances, risk signals.
Industrial IoT: machines, sensors, alerts, maintenance.
Telecom: sessions, usage, QoS metrics.
Anywhere you have multiple real-time streams plus a need for open, long-term storage, you can use RisingWave MVs and Iceberg tables the same way.

Key Takeaways (RisingWave + Iceberg)

A reference architecture combining Kafka, RisingWave, REST catalog, MinIO, and Iceberg.
Practical patterns: multi-way streaming joins, KPI views, and native Iceberg writes from RisingWave.
Get real-time logistics analytics without custom writers, ad-hoc compaction jobs, or tight vendor lock-in.

Team:

Connecting the World Through Open Source: Practical Journey of Technology, Community and Global Developer Relations

Eliana Lam — Sat, 22 Nov 2025 05:31:27 +0000

Speaker: Richard Lin @ AWS Amarathon 2025

Summary by Amazon Nova

Open source is characterized as a cross-border collaboration method rather than a mere technical option.
Engineers from different parts of the world can become collaborators through open source, despite never having met.
For hackers, open source represents a shared journey and a means to contribute to a collective effort.
For commercial projects, open source signifies an opportunity to engage with a global community and enhance product-market fit.
The globalization of technology is driven by reputation, relationships, and trust, emphasizing "actions speak louder than words."
The concept of "Community Over Code" highlights the importance of long-term community building.
Developers are influenced more by neutral, transparent, and credible sources rather than marketing efforts.
Free access is a critical factor in the success and adoption of open source projects.
A truly open source project allows for global participation by strangers, making it inherently international.
Open source is presented as an invitation to collaborate on building the future, combining technical transparency, clear governance, and low barriers to participation.
The discussion questions whether community size is more important than community structure in the context of growth and governance.
The acronym M (Market Demand) signifies unmet needs, while P (Product/Service) indicates a lack or mismatch of existing solutions.
PMF (Product-Market Fit) is crucial for initiating or engaging in open source projects to address demand.
The combination of PMF and open source creates a flywheel effect, leading to increased market share.
Acknowledging one's position as "no one" in the market can lead to omnipotence through open source contributions.
Community adoption is driven by PMF rather than mere numbers, and community productivity is a result of structure, not size.
The value of 30 core contributors is emphasized over 3000 passive spectators in the context of open source projects.

An open source contribution starter roadmap is provided with the following steps:

Identify an open source project of interest to participate in.
Fork the project and set it up to run locally.
Ensure a genuine interest and willingness to invest in the chosen project.
Begin contributing with minor modifications such as bug fixes, documentation enhancements, comment optimizations, and submitting Pull Requests.
Verify the project's open source license and understand its contribution rules, as different licenses may have varying requirements.
Gain an understanding of the project's background and structure by reading the README, documentation, and contribution guidelines.
Create a GitHub account and become comfortable with its basic functionalities.
Be open to feedback and willing to make changes based on community suggestions.
Keep the forked project and the main repository in sync by regularly updating with the latest changes from the upstream project.

Team:

Architecting for Efficiency and Reliability with Performance Testing at Scale

Eliana Lam — Sat, 22 Nov 2025 05:25:04 +0000

Speaker: Luis Guirigay @ AWS Amarathon 2025

Summary by Amazon Nova

Testing Categories:

Code Testing: Code Analysis, Unit Testing
Integration & Interface: Contract Testing, Interface Testing
Functional: User Acceptance, Regression Testing
Non-Functional: Performance Testing, Chaos Engineering
End-to-end Testing: Comprehensive testing covering all aspects

Performance Metrics:

Load: System performance under expected usage
Stress: Evaluate system behavior under extreme load conditions
Endurance: Sustained load testing to identify long-term issues
Scalability: Measuring performance under growing user/transaction volume
Spike: Rapidly increasing or decreasing load to assess resilience and behavior
Volume: Evaluates the impact of handling large amounts of data

Measurement Criteria:

Percentiles: 50th, 90th, 95th, 99th, 99.9th, 100th
Counts & Averages: Total Transactions, Success, Failures, Response Times, Latency, Connection Time, Bandwidth
Errors: All errors, prioritize critical
Resources: CPU usage, Memory consumption, Disk I/O, Network Traffic

Testing Strategies:

Early: Incorporate testing early in the development lifecycle
After: Testing post-infrastructure changes
Always: Continuous testing throughout the development process
Development: Testing integrated into the development workflow
Infrastructure Changes: Testing following any infrastructure modifications
Staging: Testing in a staging environment before production
Major Events: Testing prior to significant system events
Post-Production: Post-deployment performance validation
Milestones: Testing at specific project milestones

Benefits:

Efficiency: Improved system efficiency
Reliability: Enhanced system reliability
Better User Experience: Superior user experience through optimized performance
Scalability: Improved system scalability
Cost Optimization: Reduced costs through optimized resource utilization

Amazon Web Services Solutions:

1M+ Deployments: Extensive deployment experience
Vetted, Supported: Thoroughly vetted and professionally supported solutions
Solutions Library: Comprehensive library of vetted solutions
Pay for what you use: Flexible pricing model based on usage
Single Tenant: Solutions designed for single tenant environments
100% Open Source: Commitment to open source solutions

Team:

Serverless MediaOps: Automating Video Workflows with AI on Amazon Web Services

Eliana Lam — Sat, 22 Nov 2025 05:23:39 +0000

Speaker: Luis Valdivia @ AWS Amarathon 2025

Summary by Amazon Nova

Problem Overview

Manual video processing
Slow turnaround time
Hard to scale or automate
Heavy ops / server maintenance

Traditional Video Workflow Summary

[ 1 ] Input:
Content is manually managed through initial operations.
Manual tasks
Long processing time
Servers utilized
Transcoding backlog
[ 2 ] Operations Flow:
Input goes to a Cron Job (a scheduling utility).
The cron job triggers Encoding.
Metadata is generated and stored on EC2 Servers.
After encoding/storage, the content undergoes Content Review.
The reviewed content is then pushed to the audience.
[ 3 ] Output:
The final consumption stage on a computer monitor, representing distribution.

----

What is MediaOps?

MediaOps = DevOps for video workflows
Automates ingest → processing → delivery
Reduces manual steps
Ensures consistent, scalable pipelines
Improves quality, speed, and reliability

A four-step Media Operations (MediaOps) workflow:

Ingest: The process of taking in media content.
Process: The stage where media is prepared or modified.
Quality/Metadata: The step involving quality control and adding relevant data about the media.
Delivery: The final stage where the media is distributed or made available to its destination.

Core Amazon Web Services

S3 – ingest & storage
Lambda – event-driven logic
Step Functions – orchestration
MediaConvert – transcoding
Rekognition / Bedrock – analysis & AI metadata
CloudFront – global delivery

AI Automation Layer

Scene analysis (Rekognition)
Auto-generated metadata (Bedrock)
Intelligent decisions: reprocess, flag, publish
Event-driven orchestration (Lambda + Step Functions)

AI Automation Layer Workflow Summary

AI-driven video content workflow:

Input: A Video Output is directed into the automation system.
AI Automation: The core processing uses AI services, Rekognition and Bedrock.
Outputs/Actions: Based on the AI analysis, the system can trigger one of three actions:
[ 1 ] Reprocess: Send the content back for further processing.
[ 2 ] Flag: Mark the content for manual review or attention.
[ 3 ] Publish: Distribute the content live.

Key Benefits

Key benefits encompass eliminating 80% of manual operations
Accelerating publish time by 10 times
Achieving automatic scalability, enhancing discoverability and compliance with AI-generated consistent quality and metadata.

Team: