DEV Community: Muhammad Umair Ashraf

Building a Serverless Multi-Agent Robotics Platform on AWS

Muhammad Umair Ashraf — Wed, 28 Oct 2026 07:16:37 +0000

Imagine telling a robot:

Move forward, turn right, and wave.

Instead of writing a separate program for every instruction, what if an AI-powered application could understand the request, create an action plan, validate it, and communicate with the robot through cloud services?

That is an interesting use case for combining AI agents, serverless architecture, and IoT messaging on AWS.

Inspired by the topic discussed in Building a Serverless Multi-Agent Robotics Platform on AWS — Lessons from AWS Community Day Shenzhen, this article explores a practical reference architecture for building such a system.

The design and code snippets are illustrative examples, not a claim that a complete robotics platform has been deployed or tested.

Why combine AI agents with serverless robotics?

A robotics application needs more than a language model. It must interpret requests, manage tasks, communicate with devices, track execution, handle errors, and enforce safety rules.

A useful architecture separates these responsibilities instead of putting everything inside one application.

For example:

An intent agent interprets the user's request.
A planning agent proposes a sequence of actions.
A safety layer checks whether those actions are permitted.
An execution component sends approved commands.
Event handlers track the robot's actual status.

AWS managed services can support the application and communication layers without requiring you to operate every supporting server yourself.

1. Architecture overview

Here is the proposed architecture:

User / Web Application
          |
          v
Amazon Cognito + API Gateway
          |
          v
AWS Lambda — Request Handler
          |
          v
Agent Orchestration
(Strands Agents + Amazon Bedrock)
          |
          +--> Intent Interpretation
          |
          +--> Action Planning
          |
          +--> Safety Validation
          |
          v
Approved Command Tool
          |
          v
AWS IoT Core
          |
          v
       Robot Device
          |
          v
Status and Telemetry Events
          |
          v
AWS Lambda --> Amazon DynamoDB
          |
          v
Amazon CloudWatch

Amazon Bedrock provides foundation-model access, while Amazon Bedrock AgentCore can provide managed capabilities for deploying and operating agent workloads. Strands Agents can be used to define agent behavior and tool interactions.

The exact integration depends on the selected AgentCore components and the requirements of the robot.

2. Choose AWS services for specific responsibilities

AWS service	Purpose
Amazon Bedrock	Natural-language understanding and action planning
Strands Agents	Agent workflows and tool use
Amazon Bedrock AgentCore	Managed agent runtime and supporting capabilities
Amazon API Gateway	Application API endpoints
AWS Lambda	Request handling, validation, and event processing
Amazon Cognito	User authentication
AWS IoT Core	Device connectivity and messaging
Amazon DynamoDB	Session, task, and command state
Amazon CloudWatch	Logs, metrics, and operational monitoring
AWS Step Functions	Optional orchestration for durable multi-step workflows

You do not need every service in the first version. Start with the smallest architecture that can demonstrate a complete and safe command lifecycle.

3. Create specialized agents

A multi-agent system is most useful when responsibilities are clearly separated.

Intent agent

The intent agent converts a natural-language request into a structured action proposal.

For example:

{
  "robot_id": "robot-001",
  "action": "turn_right",
  "duration_ms": 500
}

This is an example application schema, not an AWS-defined robot command format.

Planning agent

For a multi-step task, the planning agent can propose an ordered list of supported actions.

For example:

Move forward.
Turn right.
Stop.
Report the result.

The planner should use a known capability registry instead of assuming that every robot supports the same operations.

Safety validator

The safety validator checks the proposed actions against deterministic application rules.

It should verify:

The user is authorized to control the selected robot.
The requested action is supported.
Parameters are within configured limits.
The device is in an acceptable state.
Human approval is provided when required.

Its decision might be ALLOW, REJECT, or REQUIRE_APPROVAL.

Important: AI-generated plans are proposals, not authorization to control physical hardware. Enforce safety rules in trusted application code and the robot's local controller.

Execution coordinator

The execution component sends approved commands, tracks their status, and handles failures.

Give it access only to specific, validated tools. Avoid giving an AI agent unrestricted permission to publish arbitrary commands to robot devices.

4. Connect the robot using AWS IoT Core

AWS IoT Core can support MQTT-based communication with compatible robot devices.

One possible topic structure is:

robots/robot-001/commands
robots/robot-001/status
robots/robot-001/telemetry
robots/robot-001/events

A command might look like this:

{
  "command_id": "cmd-1001",
  "robot_id": "robot-001",
  "action": "move_forward",
  "duration_ms": 1000
}

The robot-side controller should validate the message before acting on it. It should reject expired or duplicate commands, enforce local limits, and report the actual execution outcome.

Do not assume that successful message delivery means the physical action completed.

For a reliable implementation, define:

Command IDs and duplicate detection.
Acknowledgements and execution status.
Timeouts and bounded retry behavior.
Device authentication and least-privilege IoT policies.
Behavior during network disconnection.

Cloud-based AI is suitable for high-level planning and coordination. Time-critical motor control and emergency stopping should remain local to the robot.

5. Store task state in DynamoDB

Amazon DynamoDB can store the state needed to track a robotics workflow.

For example:

Entity	Example data
Robot	ID, supported actions, connection status
Session	Session ID, user ID, selected robot
Task	Task ID, action sequence, current step
Command	Command ID, approval state, execution result

A command lifecycle could be:

REQUESTED
    |
    v
VALIDATED
    |
    v
APPROVED
    |
    v
SENT
    |
    v
COMPLETED

Other outcomes can include REJECTED, FAILED, and EXPIRED.

Use application-level state-transition checks and conditional writes where appropriate to avoid conflicting updates.

For high-volume sensor telemetry, choose a storage design based on data volume and query requirements rather than placing every sensor reading into the same table as session state.

6. Build a simple capability validator

Before connecting an AI agent to a real robot, define exactly which actions each device supports.

Here is a small Python example:

ROBOT_CAPABILITIES = {
    "robot-001": {
        "move_forward",
        "turn_right",
        "turn_left",
        "stop",
    }
}


def validate_action(robot_id, action):
    capabilities = ROBOT_CAPABILITIES.get(robot_id)

    if capabilities is None:
        return False, "Unknown robot"

    if action not in capabilities:
        return False, "Unsupported action"

    return True, "Action is supported"


allowed, message = validate_action(
    "robot-001",
    "turn_right",
)

print(allowed, message)

This is a minimal illustration, not a production safety system. A real implementation also needs authentication, authorization, parameter validation, device health checks, movement limits, and local safety controls.

The key idea is to validate every proposed action before it reaches the command interface.

7. Handle failures before scaling

Robots and cloud services can fail independently. A robust system must account for both.

Robot offline: Mark the robot unavailable and report the status to the user.

Duplicate command: Use unique command IDs and device-side duplicate detection.

Agent timeout: Apply execution deadlines and bounded retries.

Partial task completion: Record completed steps and determine whether the task can safely resume.

Out-of-order events: Use command IDs, timestamps, and sequence checks to reject stale updates.

Emergency stop: Ensure that protective stopping does not depend on an AI model or a working cloud connection.

For workflows involving multiple durable steps, retries, and recovery branches, AWS Step Functions may be useful. A simpler workflow can use Lambda and event-driven processing.

8. Secure and monitor the platform

Security should be part of the architecture from the beginning.

Use least-privilege IAM permissions, unique device identities, restricted IoT policies, and server-side authorization. Require explicit approval for high-impact actions where appropriate.

Maintain an audit trail showing who requested a task, what was proposed, which checks passed, which command was sent, and what the robot reported.

Use Amazon CloudWatch to monitor:

API and Lambda errors.
Agent latency and invocation counts.
Device connectivity.
Command acknowledgement and completion rates.
Safety rejections and failed tasks.
Estimated cost per completed task.

Remember that serverless does not automatically mean free. Model inference, agent runtime, Lambda, messaging, storage, and monitoring can all contribute to the total cost.

9. Build it in stages

I would approach implementation incrementally:

Stage 1: Connect one simulated or test robot and implement a few deterministic commands.

Stage 2: Add an API and authentication.

Stage 3: Introduce an AI agent to translate natural-language requests into structured proposals.

Stage 4: Add deterministic validation and an explicit approval workflow.

Stage 5: Persist command state and process device status events.

Stage 6: Add monitoring, error recovery, and additional agents only where they provide measurable value.

Stage 7: Expand to multiple robots with device-specific permissions, concurrency limits, and capability discovery.

This approach makes it easier to test the entire request-to-execution lifecycle before adding more complexity.

Final thoughts

A serverless multi-agent robotics platform is not simply a chatbot connected to a robot. It is a system that combines AI reasoning, cloud services, device communication, state management, observability, and physical safety.

AWS provides building blocks for these responsibilities through Amazon Bedrock, Strands Agents, Amazon Bedrock AgentCore, AWS Lambda, AWS IoT Core, and DynamoDB.

My main takeaway is this:

Let AI plan the action. Let trusted software authorize it. Let the robot's local controller enforce physical safety.

Start with one robot, a small set of supported actions, and a clear validation process. Once that workflow is reliable, expand toward more sophisticated agents and multi-robot coordination.

References

Build an Agentic Application Modernization Platform with Strands Agents and AWS Transform Custom

Muhammad Umair Ashraf — Tue, 27 Oct 2026 02:34:42 +0000

What if you could submit 100 application repositories to one platform, analyze their modernization needs, reuse approved code transformations, and track execution results from a single dashboard?

That is the idea behind ModernizeHub, a project architecture for agentic application modernization on AWS.

Modernizing one application can be challenging. Modernizing hundreds of applications introduces a different level of complexity: repository discovery, dependency upgrades, code transformation, testing, execution capacity, and reporting.

In this article, we'll explore how to design a practical modernization platform using:

Strands Agents for agent orchestration
AWS Transform custom for reusable code transformations
Amazon Bedrock AgentCore for running and operating agents
AWS Batch for parallel repository jobs
Amazon S3 for artifacts and reports
Amazon DynamoDB for job tracking
React, Amazon CloudFront, API Gateway, and Lambda for the application interface and backend

Note: ModernizeHub is a project name used for this walkthrough. The architecture is inspired by AWS's public sample implementation. The examples and results shown below are illustrative, not claimed production test results.

1. The problem: Modernization doesn't scale easily

Imagine a company with 200 applications.

Some use older Python runtimes. Others depend on legacy Java frameworks, outdated SDKs, or configurations that need to change before migration.

The engineering team needs to:

Understand each repository.
Identify the required changes.
Find an existing transformation or create a new one.
Apply the transformation.
Run builds and tests.
Review failures and approve changes.
Report the outcome.

Doing all this manually for every application consumes time and creates inconsistent results.

An agentic workflow can help coordinate these activities, while reusable transformations and automated tests make the process more repeatable.

The goal is not to let AI change everything without supervision. The goal is to automate repetitive work while keeping engineers in control.

2. What are we building?

ModernizeHub is a web application where developers can submit one repository or upload a CSV file containing many repositories.

The workflow analyzes each application, identifies an appropriate transformation, routes missing transformations for review, executes approved jobs, and displays the results.

The platform includes:

Repository analysis
Transformation discovery
Custom transformation creation
Single-repository execution
CSV batch processing
Parallel job execution
Build and test validation
A dashboard for status and logs
Human approval for sensitive changes

3. Architecture

Here's the high-level design.

Developer / Platform Engineer
            |
            v
     React Dashboard
            |
     CloudFront + S3
            |
            v
      API Gateway
            |
            v
       AWS Lambda
            |
            v
 Amazon Bedrock AgentCore
            |
            v
    Strands Orchestrator
            |
    +-------+--------+
    |       |        |
    v       v        v
 Analysis Discovery Custom
  Agent    Agent   Creation
                    Agent
                       |
                 Human Review
                       |
                       v
             Approved Transformation
                       |
                       v
                 AWS Batch
                       |
                       v
            AWS Transform Custom CLI
                       |
                       v
               Source Repository
                       |
                +------+------+
                |             |
                v             v
             Amazon S3    DynamoDB
            Artifacts    Job Tracking
                |             |
                +------+------+
                       |
                       v
                 Web Dashboard

This is a logical architecture. The application code must implement the API integrations, permissions, job submission, status updates, and result retrieval.

What does each service do?

React, S3, and CloudFront

Provide the user interface for repository submission, batch uploads, transformation review, and job tracking.

Amazon API Gateway and AWS Lambda

Receive requests, validate input, create job records, check authorization, and initiate the asynchronous workflow.

Strands Agents

Coordinate specialized agents and tools. The orchestrator decides which step should happen next based on validated results.

Amazon Bedrock AgentCore

Provides infrastructure for running and operating agents. AgentCore Runtime can host the orchestrator, while supporting capabilities can help with context and observability.

AWS Transform custom

Provides reusable code transformation capabilities for supported modernization tasks.

AWS Batch

Runs independent repository jobs according to the configured queue, compute resources, and concurrency limits.

Amazon S3 and DynamoDB

Store output artifacts and job metadata so developers can retrieve results and track progress.

4. Why use multiple agents?

Instead of asking one agent to analyze code, invent transformations, execute shell commands, and validate everything, we can separate the responsibilities.

Agent 1: Repository Analysis Agent

This agent inspects a repository and identifies its technology stack, dependencies, build system, tests, and potential modernization blockers.

An illustrative output could be:

{
  "language": "Java",
  "build_tool": "Maven",
  "framework": "Spring Boot",
  "target": "Spring Boot 3",
  "tests_detected": true,
  "manual_review_recommended": true
}

These values are examples. A real implementation must derive them from repository evidence.

Agent 2: Transformation Discovery Agent

This agent checks whether a suitable transformation already exists.

If an approved transformation matches the repository and target, the workflow can use it. Otherwise, the orchestrator can request a candidate transformation.

Agent 3: Custom Transformation Creation Agent

This agent helps translate a modernization requirement into a candidate transformation definition.

For example:

Create a reusable transformation for supported Spring Boot 2 to Spring Boot 3 migration patterns. Identify dependency changes, update supported configuration patterns, and flag unsupported cases for manual review.

The candidate must be tested and reviewed before it is added to a shared transformation catalog.

Never treat generated transformation logic as automatically trusted production code.

Agent 4: Execution Agent

This agent coordinates the execution request and submits approved work to the execution system.

AWS Batch runs the configured transformation container. The job's exit code and validation results determine the actual outcome.

The orchestrator

The Strands orchestrator coordinates the workflow:

Validate the request.
Analyze the repository.
Find an appropriate transformation.
Request a new candidate if needed.
Route it for approval.
Submit approved work.
Collect execution and test results.
Update the job record.

This division makes the workflow easier to understand, test, and govern.

5. Design the web application

A useful platform needs a clear interface, not just an agent that responds to prompts.

Screen 1: Dashboard

The dashboard shows the status of the modernization portfolio.

+--------------------------------------------------+
| ModernizeHub                         Account      |
+--------------------------------------------------+
| Total Repositories: 200                           |
| Completed: 142        Running: 18                 |
| Failed: 12             Awaiting Review: 28        |
|                                                  |
| [Analyze Repository]      [Upload CSV Batch]      |
|                                                  |
| Repository          Transformation       Status  |
| payments-service    Java Upgrade         Complete|
| customer-api        Python Upgrade       Running |
| billing-worker      Custom Migration     Review  |
+--------------------------------------------------+

These are mock numbers for illustrating the interface, not real execution results.

The production dashboard should retrieve actual data from the backend.

Screen 2: Analyze a repository

A developer enters a repository URL and selects the modernization target.

Repository URL:
https://github.com/example-org/payments-service

Modernization Goal:
Upgrade supported Spring Boot 2 patterns to Spring Boot 3

Validation Profile:
Maven build and unit tests

[Analyze Repository]

The API validates the request, creates a job ID, and starts the asynchronous workflow.

The example repository URL is illustrative.

Screen 3: Custom transformation builder

If no suitable transformation exists, the developer can provide a natural-language requirement.

Transformation Name:
spring-boot-3-modernization

Requirements:
- Identify supported dependency changes
- Update compatible configuration patterns
- Flag unsupported changes
- Produce a reviewable transformation

[Generate Candidate]

The application displays the generated candidate so an engineer can inspect, test, approve, or reject it.

Screen 4: Batch processing

The developer uploads a CSV file, previews the repositories, fixes invalid rows, and submits the batch.

Each accepted repository becomes an independent job.

Screen 5: Job details

Each job should display:

Repository and revision
Transformation name and version
Current status
Execution logs
Build and test results
Output artifact location
Failure details
Approval history

This makes it easier to troubleshoot one application without losing visibility into the rest of the batch.

6. Example: Submit multiple repositories with CSV

Create a file named sample-batch.csv:

repository_url,transformation_name,validation_profile,context
https://github.com/example-org/service-a,python-runtime-upgrade,python-tests,Upgrade supported Python patterns
https://github.com/example-org/service-b,spring-boot-modernization,maven-tests,Review framework dependencies
https://github.com/example-org/service-c,aws-sdk-migration,java-tests,Update supported SDK usage

These are example rows. The repositories must be accessible, and the transformation names and validation profiles must exist in the deployed platform.

What happens after upload?

Step 1 — Validate the input

Check required fields, repository policies, transformation names, duplicate submissions, and file size.

Step 2 — Preview the batch

Show the parsed rows and allow the user to fix errors.

Step 3 — Create job records

Create a unique ID for each accepted repository.

Step 4 — Resolve transformations

Find approved transformations and route missing or newly generated definitions through the appropriate review process.

Step 5 — Execute jobs

Submit approved jobs to AWS Batch, respecting concurrency limits.

Step 6 — Validate changes

Run the configured build and test commands.

Step 7 — Report results

Update each job's status and expose available logs and artifacts.

An illustrative outcome might be:

Repository	Status	Next step
service-a	Completed	Review validation report
service-b	Failed validation	Investigate build error
service-c	Awaiting approval	Review proposed transformation

These results are examples, not claimed test results.

A failure in one repository should not automatically mark every other job in the batch as failed.

7. Validate the transformed code

An agent saying "completed" does not prove that the application works.

Each execution should:

Check out an approved repository revision.
Prepare an isolated working environment.
Run the selected transformation.
Capture logs and the exit code.
Run approved build and test commands.
Store the patch and reports.
Update the job status.
Flag failures for investigation.

For a Maven-based Java application, a test step might be:

mvn -B test

For a Python application, it might be:

python -m pytest

These are examples only. Use commands appropriate to the repository and toolchain.

Do not execute arbitrary commands supplied by an untrusted repository or model output in a privileged environment.

For more complete validation, add static analysis, dependency security scanning, integration tests, and application-specific acceptance tests.

A successful build is useful evidence, but it does not guarantee that all application behavior remains correct.

8. Infrastructure as code: CDK, SAM, or Terraform?

Infrastructure as code makes the deployment reproducible.

The platform needs resources for the frontend, API, agent runtime, execution environment, storage, tracking, and monitoring.

A project might organize its code like this:

modernizehub/
├── frontend/
├── api/
├── agents/
│   ├── orchestrator.py
│   ├── analyze_agent.py
│   ├── discovery_agent.py
│   ├── create_agent.py
│   └── execute_agent.py
├── batch/
│   ├── Dockerfile
│   └── entrypoint.sh
├── transformations/
├── tests/
├── samples/
│   └── sample-batch.csv
└── infrastructure/
    ├── cdk-sam/
    └── terraform/

This is a suggested structure, not the exact structure of the AWS sample.

AWS's public repository contains an implementation under agentic-atx-platform and documents deployment using AWS CDK and AWS SAM.

Explore it here:

https://github.com/aws-samples/aws-transform-custom-samples/tree/main/agentic-atx-platform

If your team uses Terraform, you can build an equivalent Terraform implementation for supported AWS resources and deployment steps. However, the linked sample should not be mistaken for a ready-made Terraform deployment.

Before deploying, review current service availability, model access, IAM permissions, network requirements, and cleanup instructions.

9. Security considerations

A modernization platform can read source code and execute build tools. Security must be part of the design.

Least privilege: Give each component only the permissions it needs.

Secure credentials: Do not embed repository tokens in prompts, logs, or container images.

Isolated execution: Run jobs in controlled environments with resource limits and restricted network access where practical.

Human approval: Review new transformation definitions before publishing them for reuse.

Reviewable changes: Preserve the original revision and make patches easy to inspect.

Safe retries: Track job IDs, transformation versions, and outputs to prevent blind repeat execution.

Auditability: Record the requester, repository revision, transformation version, approval status, and validation results.

Cost controls: Limit concurrency and monitor model usage, compute, storage, and logging costs.

The goal is to automate repetitive work without removing engineers from important decisions.

10. Try the public AWS sample

You do not have to build every component from scratch.

Start with the public repository:

https://github.com/aws-samples/aws-transform-custom-samples

Then:

Review the agentic-atx-platform README and architecture.
Check the current prerequisites, AWS Region, model access, and IAM requirements.
Configure the required AWS credentials and development tools.
Deploy the sample using its documented instructions.
Test with one repository that you control.
Verify job status, transformation output, logs, and validation results.
Test a small CSV batch.
Increase concurrency only after reviewing reliability and cost.
Follow the documented cleanup procedure when finished.

Deployment commands and requirements can change, so use the repository's current instructions.

11. How do we measure success?

Measure the platform using actual outcomes rather than the number of agents.

Useful metrics include:

Number of repositories submitted and completed
Percentage matched to existing transformations
Custom transformations approved or rejected
Transformation execution success rate
Build and test pass rate
Average processing time per repository
Manual intervention rate
Cost per completed repository
Changes successfully reviewed and merged

Compare these metrics with your existing modernization process before claiming productivity improvements.

Conclusion

Modernizing hundreds of applications is a coordination challenge involving code analysis, transformation selection, execution, testing, and governance.

Strands Agents can coordinate the workflow. AWS Transform custom provides reusable transformation capabilities. Amazon Bedrock AgentCore supports the agent runtime, while AWS Batch enables independent repository jobs to run in parallel.

A dashboard, API, S3, DynamoDB, and infrastructure as code bring these capabilities together into an application that engineers can monitor and extend.

The most important lesson is this:

Don't give AI unrestricted control over every repository. Let agents help plan the work, use approved transformations to make changes, validate the results, and keep engineers in control of important decisions.

Start with one repository. Prove the workflow. Test a small batch. Then scale based on evidence.

References

Building REST APIs on AWS with API Gateway, Lambda, and DynamoDB

Muhammad Umair Ashraf — Mon, 26 Oct 2026 02:35:55 +0000

Modern applications depend on APIs to exchange data. A web application retrieves products, a mobile app submits orders, and an internal dashboard fetches operational information.

REST APIs provide a standard way for these applications to communicate over HTTP.

On AWS, you can build a serverless REST API using Amazon API Gateway, AWS Lambda, and Amazon DynamoDB. This approach reduces infrastructure management while giving you managed services for API routing, application logic, and data storage.

In this tutorial, we'll explore the architecture and build a simple product endpoint using Python.

1. What Is a REST API?

A REST API exposes resources through URLs and uses HTTP methods to perform operations.

Imagine you're building a product catalog API:

Method	Endpoint	Purpose
`GET`	`/products`	List products
`GET`	`/products/101`	Retrieve one product
`POST`	`/products`	Create a product
`PUT`	`/products/101`	Replace a product
`PATCH`	`/products/101`	Update selected fields
`DELETE`	`/products/101`	Delete a product

A response might look like this:

{
  "id": "101",
  "name": "Cloud Fundamentals Guide",
  "category": "Education",
  "available": true
}

A good REST API uses consistent resource names, appropriate HTTP methods, meaningful status codes, input validation, and predictable response formats.

2. The AWS Architecture

Our example uses four primary services:

Amazon API Gateway: Receives HTTP requests and routes them to the backend.
AWS Lambda: Executes the application logic.
Amazon DynamoDB: Stores product records.
Amazon CloudWatch: Collects logs and metrics to help troubleshoot problems.

The request flow is:

Client → API Gateway → Lambda → DynamoDB

The response travels back to the client through API Gateway.

IAM controls the permissions that allow Lambda to access DynamoDB and allow API Gateway to invoke Lambda.

This separation makes the application easier to maintain and scale without managing API servers.

3. Create a Lambda Function

Let's begin with a simple endpoint that returns a sample product.

In the AWS Lambda console, create a function named GetProductFunction using a supported Python runtime.

Add the following code:

import json

def lambda_handler(event, context):
    product = {
        "id": "101",
        "name": "Cloud Fundamentals Guide",
        "category": "Education",
        "available": True
    }

    return {
        "statusCode": 200,
        "headers": {
            "Content-Type": "application/json"
        },
        "body": json.dumps(product)
    }

This function returns a JSON response with an HTTP status code of 200.

For now, the product is hard-coded. That keeps the first example focused on the API request and response flow.

4. Configure Amazon API Gateway

Next, expose the Lambda function through an API endpoint.

Open the Amazon API Gateway console.
Choose Create API.
Select REST API and choose Build.
Name the API ProductManagementAPI.
Create a resource named /products.
Add a GET method.
Configure the method to invoke GetProductFunction.
Save the configuration.

Make sure API Gateway has permission to invoke the Lambda function. Verify the function's resource-based policy if you encounter an invocation error.

Deploy the API

Deploy the API to a stage named dev.

The invoke URL will look similar to this:

https://{api-id}.execute-api.{region}.amazonaws.com/dev/products

Replace {api-id} and {region} with the values from your API.

Test the endpoint

You can use curl to send an HTTP request:

curl -i \
  "https://{api-id}.execute-api.{region}.amazonaws.com/dev/products"

If the integration is configured correctly, the response should contain 200 OK and the product JSON.

You've now created a basic serverless API endpoint on AWS.

Official walkthrough: Using AWS Lambda with Amazon API Gateway.

5. Connect the API to DynamoDB

Hard-coded data is useful for a first test, but real applications need persistent storage.

Create a DynamoDB table named Products with a string partition key named id.

Now configure a GET resource at /products/{id} and connect it to a Lambda function like this:

import json
import os
import boto3

dynamodb = boto3.resource("dynamodb")
table = dynamodb.Table(os.environ["PRODUCTS_TABLE"])

def lambda_handler(event, context):
    path_parameters = event.get("pathParameters") or {}
    product_id = path_parameters.get("id")

    if not product_id:
        return {
            "statusCode": 400,
            "headers": {"Content-Type": "application/json"},
            "body": json.dumps({
                "message": "Product ID is required"
            })
        }

    try:
        response = table.get_item(
            Key={"id": product_id}
        )

        product = response.get("Item")

        if product is None:
            return {
                "statusCode": 404,
                "headers": {"Content-Type": "application/json"},
                "body": json.dumps({
                    "message": "Product not found"
                })
            }

        return {
            "statusCode": 200,
            "headers": {"Content-Type": "application/json"},
            "body": json.dumps(product)
        }

    except Exception:
        print("Product lookup failed")

        return {
            "statusCode": 500,
            "headers": {"Content-Type": "application/json"},
            "body": json.dumps({
                "message": "Internal server error"
            })
        }

Before testing this version:

Set the Lambda environment variable PRODUCTS_TABLE to Products.
Give the Lambda execution role dynamodb:GetItem permission on the specific table.
Ensure the table's partition key is the string attribute id.
Deploy the updated Lambda function and API configuration.

The function returns 404 when a product doesn't exist and avoids exposing internal exception details to the caller.

For production use, add structured logging, tests, and appropriate exception classification. Avoid logging sensitive information.

6. REST API or HTTP API?

Amazon API Gateway offers both REST APIs and HTTP APIs.

REST API is worth considering when you need features such as usage plans, API keys, configurable request validation, or supported AWS WAF integration.

HTTP API can be a good fit for simpler applications that need HTTP routing and backend integrations without the full REST API feature set.

Compare the current feature set and pricing before deciding.

Documentation: Amazon API Gateway Developer Guide.

7. Secure Your API

A working API isn't necessarily a secure API. Build security into the design from the beginning.

Authentication and authorization

Depending on your application, API Gateway can use IAM authorization, Amazon Cognito user pools, or Lambda authorizers.

Authentication identifies the caller. Authorization determines which operations and resources that caller may access.

Least-privilege permissions

A Lambda function that reads products should not have unrestricted access to every AWS resource.

Grant only the permissions required for its task. Use separate permissions for functions that create, update, or delete data where appropriate.

Input validation

Validate path parameters, query strings, request bodies, data types, and allowed values. Reject invalid requests before they reach sensitive application logic.

Throttling and abuse protection

Configure throttling limits appropriate for the workload. AWS WAF can provide additional filtering for supported API Gateway REST API configurations.

Protect sensitive information

Use HTTPS, avoid putting credentials in URLs, keep secrets out of source code, and review logging policies to prevent accidental exposure of tokens or personal information.

8. Monitor and Troubleshoot

Amazon CloudWatch provides logs and metrics that help you understand API behavior.

Pay attention to these signals:

Signal	Possible cause
`4XX` responses	Invalid requests, missing resources, or authorization problems
`5XX` responses	Backend errors or integration failures
High latency	Slow Lambda execution or downstream operations
Lambda errors	Application exceptions
DynamoDB throttling	Capacity constraints or access-pattern problems

These metrics help narrow down issues, but they don't always identify the root cause. Correlate API Gateway metrics with Lambda logs and DynamoDB metrics to investigate failures.

For production systems, consider structured logging, request IDs, CloudWatch alarms, and appropriate log retention.

9. Manage Costs and Scaling

Serverless services reduce infrastructure management, but they still incur costs.

Your bill may include API requests, Lambda execution duration, DynamoDB usage, CloudWatch logs, and optional security services.

A few practical ways to manage costs:

Choose the API type based on actual requirements.
Optimize Lambda execution duration through testing.
Design DynamoDB keys and indexes around your access patterns.
Configure log retention.
Monitor usage and establish budgets.
Test expected traffic before production deployment.

Review Amazon API Gateway pricing and the pricing for other services in your architecture.

10. Production Readiness Checklist

Before releasing your API, check the following:

[ ] Use consistent resource names and HTTP methods.
[ ] Validate incoming requests.
[ ] Return meaningful HTTP status codes.
[ ] Configure authentication and authorization.
[ ] Apply least-privilege IAM permissions.
[ ] Set appropriate throttling and abuse protection.
[ ] Configure logs, metrics, and alarms.
[ ] Test invalid requests and backend failures.
[ ] Plan deployment stages and API versioning.
[ ] Review cost estimates and test realistic traffic.

Final Thoughts

Building a REST API on AWS involves more than creating an endpoint. It requires a thoughtful combination of routing, application logic, data storage, permissions, monitoring, and operational controls.

Amazon API Gateway, AWS Lambda, and DynamoDB provide a practical foundation for serverless APIs. Start with a simple GET endpoint, connect it to persistent data, and then add the security and monitoring your application requires.

Question for the community: For a new AWS application, would you choose API Gateway REST API or HTTP API? What requirements influence your choice?

AWS #Serverless #Python #APIs

PHP2Shell: How AI Is Transforming Vulnerability Discovery and AWS Cloud Security

Muhammad Umair Ashraf — Sun, 25 Oct 2026 08:52:00 +0000

AI is changing how developers write code, test applications, and operate cloud infrastructure. It is also changing how security researchers discover vulnerabilities hidden deep inside mature software.

In October 2026, two critical PHP vulnerabilities brought this shift into focus: CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell.

The incident raises an important question for developers, DevOps engineers, and cloud security teams:

If AI can help discover vulnerabilities in software that has existed for years, how should we redesign our security workflows to keep up?

The answer is not simply to add another AI tool. We need reliable asset inventories, fast patch deployment, defense in depth, and AI-assisted workflows with clear safety boundaries.

Important: This article discusses defensive security, vulnerability remediation, and secure cloud architecture. Always validate current vulnerability status against official advisories and your software vendor's guidance.

1. What Is PHP2Shell?

PHP2Shell refers to two critical vulnerabilities affecting memory handling in the PHP runtime.

CVE-2026-109618: A memory-corruption issue associated with out-of-memory handling.
CVE-2026-109619: A use-after-free issue involving stale internal state.

Both issues have been reported as potentially enabling unauthenticated remote code execution in affected environments. Each received a CVSS v4.0 score of 9.2.

References: OpenAI's coordinated disclosure report and Cyber Security Agency of Singapore advisory.

Why should developers care?

Many web vulnerabilities originate in application code, such as an authorization mistake or unsafe input handling.

PHP2Shell is different because it involves the underlying runtime.

Even a well-designed application may remain exposed if it executes a vulnerable PHP version. Updating application code alone does not necessarily fix a defect in the runtime itself.

This is a reminder that application security includes the entire software stack:

Application code
Frameworks and dependencies
Language runtimes
Container images
Operating systems
Cloud infrastructure and identity permissions

2. How AI Can Help Find Vulnerabilities

Security researchers traditionally combine code review, debugging, fuzzing, static analysis, and specialized testing to identify difficult defects.

AI can help accelerate parts of this work.

For example, an AI-assisted research workflow can help engineers:

Understand an unfamiliar codebase.
Identify suspicious memory-management patterns.
Trace how external input reaches sensitive functions.
Generate focused test cases.
Summarize crash reports and execution traces.
Review proposed fixes for possible gaps.
Draft regression tests and remediation documentation.

In the PHP2Shell case, OpenAI reported AI-assisted vulnerability discovery through its Patch the Planet initiative. Wiz independently discovered and reported both vulnerabilities, and PHP maintainers and security partners coordinated remediation.

Source: OpenAI — Coordinated disclosure of critical vulnerabilities.

However, AI-generated suspicion is not the same as a confirmed vulnerability.

A researcher still needs to reproduce the behavior safely, establish its security impact, validate the fix, and communicate the findings responsibly.

AI is best treated as a force multiplier for experienced security engineers—not as an unquestionable security authority.

3. AWS Architecture: Defend in Multiple Layers

Suppose you operate a PHP application on AWS. It may run on Amazon EC2 or in containers on Amazon ECS or Amazon EKS.

A defensive architecture could look like this:

                 Internet
                    |
                    v
             Amazon CloudFront
                    |
                    v
                AWS WAF
                    |
                    v
          Application Load Balancer
                    |
                    v
          PHP Runtime on EC2 / ECS
                    |
              +-----+-----+
              |           |
              v           v
        Private Data   Application Logs
        and Services         |
                             v
                    Amazon CloudWatch

CloudFront is optional; the architecture should match your actual deployment.

Each layer serves a different purpose:

Layer	Security purpose
AWS WAF	Filters requests using configured rules
Load balancer	Routes traffic to application targets
Security groups	Restrict network access
IAM	Limits access to AWS resources
CloudWatch	Supports logging, metrics, and alerts
Patch pipeline	Deploys fixed runtime versions

AWS has published guidance on using AWS WAF to mitigate PHP2Shell attack paths. Such controls can reduce exposure, but they do not replace upgrading the affected PHP runtime.

Reference: AWS Security Blog — PHP2Shell mitigation guidance.

Security principle: Network controls, WAF rules, and monitoring are additional defenses. They are not substitutes for fixing vulnerable software.

4. Immediate Remediation Checklist

When a critical runtime vulnerability is disclosed, speed matters—but so does verification.

Step 1: Inventory PHP versions

On a Linux host, start by checking:

php -v

This is only a starting point. For containerized workloads, inspect the PHP version inside the actual image or running container.

Include:

EC2 instances
ECS and EKS workloads
CI/CD build images
Development and staging systems
Legacy applications
Third-party software that bundles PHP

Step 2: Upgrade affected environments

The PHP fixes reported for supported branches include:

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

Check the PHP2Shell security research and official PHP or distribution advisories to confirm the correct fixed release for your environment. Vendors may backport fixes, so version comparisons must account for package-specific guidance.

For containers, rebuild and redeploy the image. Updating the host does not automatically update PHP embedded in an existing container image.

Step 3: Apply temporary mitigations

If patching is delayed, follow official vendor guidance for temporary protections. AWS WAF may provide an additional defensive layer, but no WAF configuration should be assumed to block every possible attack path.

Step 4: Investigate potential compromise

Review relevant application, web server, operating system, and security logs.

Investigate unusual processes, unexpected file changes, suspicious outbound connections, and possible credential exposure. If compromise is suspected, follow your incident response process and preserve evidence.

Step 5: Verify remediation

Confirm that every affected instance and container is running a fixed runtime. Run application tests and retain evidence of the deployed version.

A successful build does not prove that every production replica has been updated.

5. Build an AI-Assisted Vulnerability Remediation Workflow

We can use AWS services to coordinate vulnerability findings, AI-assisted analysis, approval, and verification.

Here is one possible design:

     Asset Inventory and Security Scans
                    |
                    v
         EventBridge / Lambda
                    |
                    v
          Normalize Findings
                    |
                    v
       AI-Assisted Triage (Optional)
             Amazon Bedrock
                    |
                    v
        Deterministic Policy Checks
                    |
                    v
             Human Approval
                    |
                    v
             CI/CD Pipeline
                    |
                    v
       Verify Runtime and Deployment
                    |
                    v
          Audit Evidence and Alerts

This is a proposed architecture, not a built-in integration automatically provided by these services.

Possible AWS service responsibilities

Service	Example responsibility
Amazon S3	Store scan reports and remediation evidence
AWS Lambda	Process findings and trigger bounded tasks
Amazon EventBridge	Route relevant events
AWS Step Functions	Coordinate multi-step workflows
Amazon Bedrock	Summarize findings and suggest remediation plans
AWS Security Hub	Aggregate supported findings from integrated sources
Amazon CloudWatch	Monitor workflow activity and alerts
AWS IAM	Enforce least-privilege permissions

Start small. A team may initially need only a reliable scanner, a runtime inventory, and a patch-verification script. Add AI orchestration when it solves a clear problem.

What should AI handle?

An AI component can help:

Explain technical findings to developers.
Group related issues by application.
Draft remediation tickets.
Suggest upgrade paths using approved advisory data.
Summarize test results.
Identify missing evidence in a remediation report.

What should deterministic code handle?

Use trusted tools and ordinary code to:

Compare installed versions against authoritative advisories.
Enforce risk policies.
Require approvals.
Control deployment permissions.
Verify that a patch is deployed.
Record audit evidence.

A language model should not be the sole authority deciding whether a production environment is secure.

6. Example: A Simple PHP Inventory Check

You can start with a basic shell script that reports the PHP version on a Linux host.

#!/usr/bin/env bash

set -euo pipefail

if command -v php >/dev/null 2>&1; then
    echo "PHP executable: $(command -v php)"
    php -v | head -n 1
else
    echo "PHP is not available in the current PATH."
fi

Save this as check-php-version.sh, then run:

chmod +x check-php-version.sh
./check-php-version.sh

This script reports a version; it does not determine whether the system is vulnerable.

For a real remediation workflow, collect runtime inventory from approved asset-management systems and compare it with authoritative vendor advisories. Account for vendor backports, custom builds, and multiple PHP installations.

For containerized applications, run equivalent checks against the deployed image or container rather than relying on the host version.

7. What Could AI Security Look Like Next?

These are projections, not guaranteed timelines.

Near term: Faster triage

AI-assisted code review, test generation, and remediation drafting can help teams investigate findings more efficiently.

Medium term: Continuous security testing

AI may help generate tests for code changes, examine infrastructure configurations, and identify inconsistencies between security policies and deployed environments.

Longer term: Bounded autonomous remediation

Security agents may coordinate asset discovery, patch preparation, staged testing, and verification with less manual intervention.

But granting an AI agent unrestricted production permissions would introduce significant operational and security risks.

A safer design combines:

Read-only analysis by default
Least-privilege permissions
Human approval for high-impact changes
Staging validation
Independent post-deployment checks
Audit trails and rollback procedures

The goal is not unlimited autonomy. It is faster, safer, and measurable remediation.

8. The Bigger Risk: AI Is Dual-Use

The same tools that help defenders analyze code can also help attackers investigate software and automate parts of an attack.

As vulnerability discovery accelerates, organizations need to reduce the time between disclosure and verified remediation.

That means maintaining accurate asset inventories, automating patch delivery, improving monitoring, and rehearsing incident response before an incident occurs.

Longer term, secure-by-design engineering matters too. Memory-safe technologies can reduce entire classes of memory errors, while fuzzing, regression tests, and formal verification can improve confidence in critical components.

AI can assist these efforts, but it cannot guarantee bug-free software.

Conclusion

PHP2Shell is a useful case study in the changing relationship between AI and cybersecurity.

AI can help researchers investigate complex software and identify defects. But finding a vulnerability is only the beginning. The actual security outcome depends on validation, responsible disclosure, patch delivery, and verification.

For AWS engineers, the practical takeaway is straightforward:

Combine AI-assisted analysis with reliable inventory, least privilege, layered defenses, controlled remediation, and independent verification.

The future of cloud security will not be measured only by how quickly AI finds vulnerabilities. It will also be measured by how reliably engineering teams turn those discoveries into secure and resilient systems.

References

What do you think? Should AI-powered security agents eventually be allowed to deploy low-risk patches automatically, or should every production change require human approval?

I'd be interested to hear how your team is approaching AI-assisted vulnerability management.

Building a Data Fabric on AWS: Connect Data, Improve Governance, and Power AI

Muhammad Umair Ashraf — Sat, 24 Oct 2026 02:50:54 +0000

Modern organizations store data across databases, applications, data lakes, and streaming platforms. The challenge is making all that data discoverable, secure, and useful without building a completely separate integration solution for every team.

Data Fabric on AWS offers an architectural approach to connecting data sources, managing metadata, enforcing governance, and enabling analytics and AI applications.

In this tutorial, we'll explore an AWS data fabric architecture and build a small customer analytics project using Amazon S3, AWS Glue, and Amazon Athena.

What Is Data Fabric?

A data fabric is an architecture that connects data discovery, integration, metadata management, and governance across distributed systems.

On AWS, you can use services such as:

Amazon S3: Store raw and curated datasets.
AWS Glue: Discover, catalog, and transform data.
AWS Glue Data Catalog: Maintain metadata and table definitions.
AWS Lake Formation: Manage permissions for supported data lake resources.
Amazon Athena: Query data in S3 using SQL.
Amazon Redshift: Support data warehousing and analytical workloads.
Amazon DataZone: Help teams discover, share, and govern data assets.
Amazon Bedrock: Build generative AI applications that use approved business information through controlled retrieval and data-access layers.

These services are building blocks. A data fabric is an architecture you design and configure, not a single AWS service that automatically connects everything.

Why Does It Matter?

Imagine an e-commerce company with:

Customer records in Amazon RDS.
Order history in S3 files.
Website events arriving through streaming services.

Without a coordinated approach, different teams may duplicate datasets, define metrics differently, and manage permissions inconsistently.

A data fabric can help teams improve data discovery, reduce repeated integration work, and establish more consistent governance.

Reference Architecture

       DATA SOURCES
  ┌────────┬─────────┬───────────┐
  │ RDS    │ S3 Files│ Event Data│
  └────┬───┴────┬────┴─────┬─────┘
       └────────┼──────────┘
                ▼
         DATA INGESTION
        AWS Glue / Streams
                │
                ▼
           AMAZON S3
       Raw → Clean → Curated
                │
        ┌───────┴────────┐
        ▼                ▼
   Glue Catalog     Lake Formation
        │                │
        └───────┬────────┘
                ▼
          QUERY LAYER
        Athena / Redshift
                │
                ▼
       Analytics / Reports / AI

This is a conceptual design. Each source needs an appropriate ingestion process, and access policies must be configured for the services involved.

Hands-On Project: Customer Order Analytics

Let's create a simple data pipeline and query customer orders using SQL.

Step 1: Create a sample CSV file

Create orders.csv:

order_id,customer_id,region,amount,status
1001,C101,Asia,250,COMPLETED
1002,C102,Europe,180,COMPLETED
1003,C101,Asia,90,PENDING
1004,C103,North America,420,COMPLETED
1005,C104,Europe,120,CANCELLED
1006,C102,Europe,310,COMPLETED

Upload it to an S3 location such as:

s3://your-data-fabric-bucket/raw/orders/orders.csv

Replace your-data-fabric-bucket with your own bucket name. Keep public access blocked and configure appropriate encryption and permissions.

Step 2: Catalog the dataset with AWS Glue

Open the AWS Glue console and:

Create a database named customer_analytics.
Create a crawler that points to your S3 raw/orders/ prefix.
Configure an IAM role with the required S3 read and Data Catalog permissions.
Run the crawler.
Review the table schema and confirm the column types.

The crawler can discover the CSV structure and register a table in the Glue Data Catalog. Always verify inferred types before relying on them in production.

Step 3: Query the data with Athena

Open Amazon Athena and configure an S3 query-results location. Then execute:

SELECT
    region,
    COUNT(*) AS completed_orders,
    SUM(amount) AS total_revenue,
    AVG(amount) AS average_order_value
FROM customer_analytics.orders
WHERE status = 'COMPLETED'
GROUP BY region
ORDER BY total_revenue DESC;

Expected output:

Region	Completed orders	Total revenue	Average order value
Europe	2	490	245
North America	1	420	420
Asia	1	250	250

The query filters out pending and cancelled orders and calculates revenue by region.

Note: Your actual database and table names depend on your Glue configuration.

Step 4: Add Governance

A useful data platform must control access as well as provide discovery.

For this project:

Give analysts access only to the datasets they need.
Separate engineering and administrative permissions.
Configure Lake Formation permissions where applicable.
Protect sensitive customer information.
Review access logs and test permissions using a restricted analyst identity.

A catalog entry does not automatically grant permission to query the underlying data. Configure the required catalog, storage, query, IAM, and Lake Formation permissions consistently.

Step 5: Extend the Architecture

Once the basic project works, you can improve it by adding:

AWS Glue ETL jobs to validate and transform records.
Parquet datasets to improve query efficiency for suitable workloads.
Amazon Redshift for more demanding warehouse analytics.
Amazon DataZone to improve discovery and sharing across teams.
Amazon Bedrock for an AI assistant that answers business questions using approved data through a controlled retrieval or query layer.

For AI applications, validate generated queries and enforce permissions in the data-access layer. Do not give an AI model unrestricted access to every dataset.

Data Fabric vs. Data Lake vs. Data Mesh

Concept	Purpose
Data lake	Stores large amounts of data in formats such as CSV, JSON, and Parquet.
Data fabric	Connects data discovery, integration, metadata, and governance.
Data mesh	Organizes data ownership around business domains and data products.

These approaches can complement each other. Amazon S3 can provide the storage foundation, a data fabric architecture can connect and govern datasets, and a data mesh operating model can define domain ownership.

Production Best Practices

Before scaling your implementation:

Improve metadata quality: Document schemas, owners, and dataset descriptions.
Enforce least privilege: Keep administrative, engineering, and analyst permissions separate.
Validate data: Check missing values, duplicates, and schema changes.
Monitor pipelines: Track failures, processing time, and data freshness.
Optimize costs: Use appropriate partitioning and file formats to reduce unnecessary Athena scans.
Document lineage: Record where data originates and how it changes.
Secure AI access: Use controlled tools, authorization, and query validation.
Start small: Prove value with one business use case before connecting every source.

Final Thoughts

Data Fabric on AWS is not about moving all your data into one database. It is about making distributed data easier to discover, integrate, govern, and use.

With Amazon S3, AWS Glue, the Glue Data Catalog, Lake Formation, and Athena, you can build a foundation for reliable analytics and future AI applications.

Start with one dataset, catalog it, secure it, and demonstrate a useful business query. Then expand as your organization's needs grow.

The goal is simple: make the right data available to the right people and applications, securely.

Official AWS Resources

AWS Agentic AI Services: Build an Intelligent Architecture Workflow on AWS

Muhammad Umair Ashraf — Fri, 23 Oct 2026 03:55:17 +0000

What if you could describe an application in plain English and have an AI-powered workflow help you design its AWS architecture, review security requirements, identify cost drivers, and prepare infrastructure code?

That is the idea behind agentic AI.

A traditional AI chatbot can recommend AWS services and explain how they work. An agentic workflow can go further by coordinating tasks, using approved tools, checking intermediate results, and revising its recommendations when problems are found.

In this article, we'll explore how to build an AWS Architecture Copilot using Amazon Bedrock, Bedrock AgentCore, Strands Agents, AWS Lambda, and other AWS services.

We'll also create a small Python validation example and discuss how to keep the workflow secure.

1. What Makes Agentic AI Different?

Consider this request:

Design a secure and cost-effective AWS architecture for an online store with a web frontend, product API, relational database, and product-image storage.

A basic chatbot might suggest Amazon S3, Amazon RDS, and compute services.

An agentic workflow could coordinate several additional steps:

Analyze the application requirements.
Retrieve relevant architecture standards.
Propose an AWS architecture.
Review the design against security requirements.
Identify missing information for cost estimation.
Generate an infrastructure-as-code proposal.
Request approval before deployment.

The important difference is not simply using a more advanced model. It is coordinating reasoning, tool use, validation, and controlled actions.

These capabilities must be implemented in the application; they are not automatically provided as one complete workflow by a single AWS service.

2. AWS Services for an Agentic Workflow

Here are the main building blocks.

Amazon Bedrock

Amazon Bedrock provides access to foundation models for generative AI applications. A model can interpret requirements, generate structured recommendations, summarize technical documentation, and help an agent choose among its available tools.

Documentation: https://docs.aws.amazon.com/bedrock/

Amazon Bedrock AgentCore

AgentCore provides modular capabilities for deploying, connecting, securing, and monitoring agents.

Depending on your architecture, you may use:

Runtime to run agents.
Gateway to connect agents to approved tools and APIs.
Memory to retain relevant context.
Identity and Policy capabilities to support controlled access and actions.
Observability and Evaluations to inspect and assess agent behavior.

You can use the capabilities that fit your application instead of adopting every component at once.

Documentation: https://docs.aws.amazon.com/bedrock-agentcore/

Strands Agents

Strands Agents is an open-source SDK for building AI agents. It helps developers define agent behavior and connect models to tools.

It can be used to implement an architecture planner, a security reviewer, or a coordinator for a multi-step workflow.

GitHub: https://github.com/strands-agents

Other AWS Services

Service	Role in the workflow
Amazon S3	Store architecture documents and generated artifacts
Amazon Bedrock Knowledge Bases	Retrieve relevant approved technical information
AWS Lambda	Run bounded validation and helper functions
AWS Step Functions	Coordinate predictable steps, retries, and approvals
AWS IAM	Apply least-privilege access
Amazon CloudWatch	Collect logs, metrics, and alarms
AWS CloudFormation or AWS CDK	Define infrastructure as code

A useful design principle is to use agents for flexible analysis and conventional software for deterministic rules and controlled execution.

3. Reference Architecture

The following is a proposed architecture for an AI Architecture Copilot.

Developer
   |
   v
Web Application / API
   |
   v
Workflow Coordinator
   |
   v
AgentCore Runtime + Strands Agents
   |
   +------------------+------------------+
   |                  |                  |
   v                  v                  v
Architecture       Security             Cost
Planner            Reviewer             Analyst
   |                  |                  |
   +------------------+------------------+
                      |
                      v
             Schema and Rule Checks
                      |
             +--------+--------+
             |                 |
             v                 v
        Needs Changes      Ready for Review
             |                 |
             v                 v
         Revise Plan       Human Approval
                               |
                               v
                     Controlled Deployment
                               |
                               v
                         AWS Resources

The application can use Amazon Bedrock for model access, AgentCore for agent operations, S3 and Knowledge Bases for reference information, Lambda for validation, and Step Functions for workflow coordination.

The deployment stage can use CloudFormation or CDK through a controlled pipeline.

This is a reference design, not a deployed solution. The integrations and permissions must be implemented and tested.

4. Design the Agent Roles

You do not necessarily need four separate agents. These roles can be implemented as independent agents or as stages within one agentic application.

Architecture Planner

Extracts requirements.
Recommends AWS services.
Identifies dependencies.
Produces a structured architecture specification.

Security Reviewer

Reviews network and identity assumptions.
Checks whether data-protection requirements are addressed.
Identifies missing evidence.
Returns findings and remediation recommendations.

Cost Analyst

Identifies compute, storage, database, and data-transfer cost drivers.
Requests missing workload assumptions.
Uses verified pricing data where available.
Clearly labels estimates and unknowns.

Infrastructure Planner

Prepares CloudFormation or CDK artifacts.
Validates generated files.
Summarizes proposed infrastructure changes.
Waits for approval before deployment.

The benefit is separation of responsibility. A security reviewer should independently examine the architecture instead of simply repeating the planner's recommendations.

Multiple agents do not automatically mean better results, so test their outputs and measure their performance.

5. Mini Project: Validate Architecture Requirements with Python

Before sending a request to an AI agent, validate the input. Missing or inconsistent requirements can lead to poor recommendations.

Create a file named requirements.json:

{
  "application": "online-store",
  "region": "us-east-1",
  "frontend": "web",
  "api": true,
  "relational_database": true,
  "product_image_storage": true,
  "requirements": {
    "private_database": true,
    "monitoring": true,
    "human_approval_before_deployment": true
  }
}

Now create validate_requirements.py:

import json
import sys

REQUIRED_FIELDS = {
    "application",
    "region",
    "frontend",
    "api",
    "relational_database",
    "product_image_storage",
    "requirements",
}


def validate_requirements(filename):
    with open(filename, encoding="utf-8") as file:
        data = json.load(file)

    missing = REQUIRED_FIELDS - data.keys()

    if missing:
        raise ValueError(
            f"Missing fields: {', '.join(sorted(missing))}"
        )

    requirements = data["requirements"]

    if not isinstance(requirements, dict):
        raise ValueError("'requirements' must be an object.")

    required_controls = (
        "private_database",
        "monitoring",
        "human_approval_before_deployment",
    )

    missing_controls = [
        key for key in required_controls
        if key not in requirements
    ]

    if missing_controls:
        raise ValueError(
            "Missing controls: "
            + ", ".join(missing_controls)
        )

    if requirements[
        "human_approval_before_deployment"
    ] is not True:
        raise ValueError(
            "Human approval must be enabled before deployment."
        )

    print("PASS: Required input fields are present.")
    print("PASS: Human approval is enabled.")
    print("Next: Generate and review the architecture proposal.")


if __name__ == "__main__":
    filename = (
        sys.argv[1] if len(sys.argv) > 1
        else "requirements.json"
    )

    try:
        validate_requirements(filename)
    except (
        OSError,
        json.JSONDecodeError,
        ValueError,
    ) as error:
        print(f"FAIL: {error}")
        sys.exit(1)

Run the script:

python validate_requirements.py requirements.json

Expected output:

PASS: Required input fields are present.
PASS: Human approval is enabled.
Next: Generate and review the architecture proposal.

This example validates input fields and the approval setting. It does not verify that the proposed architecture is secure, correctly configured, or deployable.

For production, add JSON Schema validation, type checks, allowed-value checks, and tests for malformed input.

6. Give the Architecture Agent a Defined Task

Once the input is validated, an agent can analyze the requirements and produce a structured proposal.

For example:

You are the Architecture Planner for an AWS Architecture Copilot.

Analyze the supplied requirements and approved architecture references.

Return a structured proposal containing:
1. Recommended AWS services
2. Purpose of each service
3. Network and data-flow relationships
4. Security assumptions
5. Availability and scaling considerations
6. Missing requirements
7. Validation checks

Rules:
- Do not invent requirements.
- Mark assumptions and unknowns explicitly.
- Use approved architecture references when available.
- Do not claim checks passed without evidence.
- Do not deploy or modify AWS infrastructure.
- Return machine-readable JSON.

Your application should validate the returned JSON before passing it to the security-review stage.

The Security Reviewer can then return a status such as PASS, FAIL, or UNKNOWN, along with findings and supporting evidence.

Never treat UNKNOWN as PASS. If important information is missing, stop and request clarification.

7. Cost Analysis and Infrastructure Generation

After the architecture passes its required checks, the workflow can prepare cost and infrastructure artifacts.

The Cost Analyst should identify inputs such as:

AWS Region.
Expected request volume.
Compute requirements.
Database size and availability.
Storage consumption.
Data transfer.
Logging and monitoring usage.

Use verified AWS pricing data and document the assumptions behind the estimate. A model-generated number alone is not a verified price.

The Infrastructure Planner can then prepare a CloudFormation template or CDK application. Validate the generated artifacts and review the proposed changes before allowing a deployment pipeline to execute them.

8. Security Controls for Production

Giving an AI agent access to cloud tools introduces risks. Build the controls into the architecture from the beginning.

Least privilege: Give each component only the permissions it requires.
Approved tools: Expose narrowly scoped operations instead of unrestricted AWS access.
Human approval: Require explicit authorization for impactful changes.
Input and output validation: Reject malformed or incomplete data.
Secrets management: Never place credentials in prompts or generated source files.
Auditability: Record tool calls, validation results, approvals, and deployment outcomes.
Bounded execution: Apply timeouts, retry limits, and resource limits.
Evaluation: Test for incorrect recommendations, prompt injection, and unsafe tool use.
Rollback planning: Define a recovery path for unsuccessful deployments.

Amazon Bedrock Guardrails can provide additional safeguards for supported model interactions. They do not replace IAM, application authorization, infrastructure validation, or security testing.

9. When Should You Use Agentic AI?

Agentic workflows are useful when tasks involve multiple steps, changing context, tool usage, and decisions that may need revision.

Potential use cases include:

AWS architecture recommendation.
Cloud migration planning.
Infrastructure troubleshooting.
Cost-optimization analysis.
Documentation and compliance preparation.
Developer workflow automation.

However, a simple deterministic task may be better handled by a Lambda function or conventional workflow. Agents introduce additional latency, cost, complexity, and evaluation requirements.

A strong production architecture combines flexible AI reasoning with deterministic controls.

Conclusion

Agentic AI can help developers move beyond one-off AI responses toward workflows that coordinate architecture design, security review, cost analysis, and infrastructure preparation.

Using Amazon Bedrock, Bedrock AgentCore, Strands Agents, AWS Lambda, Step Functions, Amazon S3, IAM, and controlled deployment pipelines, teams can build an Architecture Copilot that turns natural-language requirements into a reviewable technical proposal.

Start small, validate every important output, and measure the quality of the results before expanding the workflow.

The goal isn't to give AI unrestricted access to AWS. It's to let AI handle more of the analysis while engineers stay in control of critical decisions.

Official AWS Resources

AWS AI Agent Migration Planning: Build a Smarter Cloud Migration Roadmap with AWS Transform

Muhammad Umair Ashraf — Thu, 22 Oct 2026 06:09:30 +0000

Cloud migration is not just about moving servers from one environment to another. The real challenge is understanding application dependencies, choosing the right migration strategy, grouping workloads, and planning migration waves without disrupting business operations.

This is where AI-assisted migration planning can help.

In this article, we’ll explore how AWS Transform can support migration planning, how to validate infrastructure inventory with Python, and how to use an AI agent to create a structured migration roadmap while keeping engineers in control of critical decisions.

Why Does Cloud Migration Planning Need Improvement?

Many teams still plan migrations using spreadsheets, manual dependency analysis, and disconnected documentation.

This can lead to several problems:

Application dependencies are missed.
Databases and applications are scheduled in different migration waves.
Teams underestimate testing and rollback requirements.
Migration priorities are based on assumptions instead of evidence.
Infrastructure and security requirements are discovered too late.

A better approach combines reliable inventory data, dependency analysis, AI-assisted recommendations, and human approval.

What Is AWS Transform?

AWS Transform is an AI-powered service designed to help organizations accelerate IT transformation, including cloud migration and modernization.

For migration planning, AWS Transform can help teams work through activities such as:

Scope and analyze: Review the migration scope and available discovery information.
Group applications: Identify workloads that belong together based on dependencies and business context.
Create move groups: Organize related infrastructure into manageable migration units.
Build migration waves: Arrange workloads into a sequence that supports migration execution.

The exact capabilities available depend on the transformation workflow and the data provided.

The important point is that AI can help accelerate planning, but the resulting recommendations still need technical validation.

A Practical AI-Assisted Migration Workflow

A useful migration-planning workflow can be organized into five steps.

Step 1: Collect the infrastructure inventory

Start by collecting information about servers, applications, databases, and their dependencies.

For example:

Workload	Type	Depends On	Priority
portal-app	Application	portal-db	High
portal-db	Database	None	High
reporting-app	Application	reporting-db	Medium
reporting-db	Database	None	Medium

This is synthetic example data for demonstration, not an actual AWS discovery report.

In a real project, inventory data might come from existing configuration management systems, discovery tools, application owners, or AWS migration assessment workflows.

Step 2: Validate the inventory before using AI

AI recommendations are only as reliable as the information supplied to them. First, validate the inventory for missing fields, duplicate workload IDs, invalid resource values, and dependencies that reference nonexistent workloads.

Create a file named inventory.csv:

workload_id,name,type,depends_on,cpu,ram_gb,priority
1,portal-app,application,portal-db,2,4,high
2,portal-db,database,,4,16,high
3,reporting-app,application,reporting-db,2,8,medium
4,reporting-db,database,,4,16,medium

Now create validate_inventory.py:

import csv
import sys

REQUIRED_FIELDS = {
    "workload_id",
    "name",
    "type",
    "depends_on",
    "cpu",
    "ram_gb",
    "priority",
}


def validate_inventory(filename):
    errors = []
    workloads = []

    with open(filename, newline="", encoding="utf-8") as file:
        reader = csv.DictReader(file)

        if not reader.fieldnames:
            return ["CSV file is empty or has no header."]

        missing = REQUIRED_FIELDS - set(reader.fieldnames)
        if missing:
            return [
                f"Missing required columns: {', '.join(sorted(missing))}"
            ]

        for line_number, row in enumerate(reader, start=2):
            row = {
                key: (value or "").strip()
                for key, value in row.items()
            }

            if any(not row[field] for field in (
                "workload_id", "name", "type", "priority"
            )):
                errors.append(
                    f"Line {line_number}: required value is missing."
                )
                continue

            try:
                cpu = float(row["cpu"])
                ram_gb = float(row["ram_gb"])

                if cpu <= 0 or ram_gb <= 0:
                    raise ValueError
            except ValueError:
                errors.append(
                    f"Line {line_number}: CPU and RAM must be positive numbers."
                )
                continue

            workloads.append(row)

    ids = [row["workload_id"] for row in workloads]
    names = [row["name"] for row in workloads]

    if len(ids) != len(set(ids)):
        errors.append("Duplicate workload IDs found.")

    if len(names) != len(set(names)):
        errors.append("Duplicate workload names found.")

    known_names = set(names)

    for row in workloads:
        dependencies = [
            item.strip()
            for item in row["depends_on"].split(";")
            if item.strip()
        ]

        for dependency in dependencies:
            if dependency not in known_names:
                errors.append(
                    f"{row['name']}: unknown dependency '{dependency}'."
                )

    return errors


if __name__ == "__main__":
    filename = sys.argv[1] if len(sys.argv) > 1 else "inventory.csv"
    validation_errors = validate_inventory(filename)

    if validation_errors:
        print("Inventory validation failed:")
        for error in validation_errors:
            print(f"- {error}")
        sys.exit(1)

    print("Inventory validation passed.")
    print("Ready for migration-planning review.")

Run the script:

python validate_inventory.py inventory.csv

Expected output:

Inventory validation passed.
Ready for migration-planning review.

This small validation step catches common data-quality issues before they affect migration planning. For production use, add schema validation, dependency-cycle detection, and tests for malformed input.

Step 3: Ask an AI agent to propose migration waves

After validating the inventory, provide the data to your approved AI-assisted planning workflow.

For example, use this prompt with an appropriate AI assistant or agent:

You are assisting a cloud migration planning team.

Analyze the supplied infrastructure inventory.

Your tasks:
1. Identify application and database dependencies.
2. Propose logical migration groups.
3. Recommend a sequence of migration waves.
4. Explain the reasoning behind each recommendation.
5. Identify missing information and migration risks.
6. Suggest testing and rollback checkpoints.

Rules:
- Do not invent dependencies or infrastructure details.
- Clearly label assumptions and unknown information.
- Do not execute AWS changes.
- Do not approve production migration decisions.
- Flag workloads requiring additional discovery.
- Keep dependent workloads together when appropriate,
  or explain how their dependency will be maintained.

Return a table containing:
Workload, Proposed Wave, Dependencies, Risks,
Validation Required, and Reasoning.

For AWS-specific migration planning, use the relevant AWS Transform workflow and its supported inputs rather than assuming that a generic AI assistant has access to your AWS inventory.

Step 4: Review an illustrative migration plan

For the sample inventory, an initial plan might look like this:

Wave	Workloads	Why
Wave 1	reporting-db, reporting-app	Lower-priority example workload for validating the migration process
Wave 2	portal-db, portal-app	Higher-priority application group requiring careful testing

These waves are illustrative, not an AWS Transform-generated result. A real plan must consider application criticality, dependency evidence, compatibility, downtime tolerance, network connectivity, data replication, and business approval.

Before approving a wave, confirm:

Application and database dependencies are understood.
The target architecture is validated.
Data migration and consistency checks are defined.
Security controls and connectivity are tested.
Rollback procedures are documented.
Business owners have approved the migration window.

Step 5: Track the results

Once planning and pilot migrations begin, measure whether the approach is actually helping.

Useful metrics include:

Time required to create a migration plan.
Number of dependency issues discovered before migration.
Percentage of workloads with validated owners and inventory data.
Migration success and rollback rates.
Unplanned downtime.
Estimated versus actual migration costs.

AI-generated plans should be evaluated against engineering-reviewed plans and actual migration outcomes, not just the speed at which the recommendations are produced.

Security and Governance Considerations

Migration planning often involves sensitive infrastructure details. Treat inventory files and AI prompts as potentially sensitive data.

Follow these practices:

Use approved services and access controls.
Apply least-privilege permissions.
Avoid including credentials, secrets, or unnecessary personal data.
Keep a record of recommendations and human approvals.
Require explicit authorization before production changes.
Verify cost estimates against current AWS pricing and the intended Region.
Test migrations in controlled environments before expanding the rollout.

A useful rule: let AI assist with analysis and recommendations, while accountable engineers retain control over production decisions.

Final Thoughts

AI-assisted migration planning can help teams turn fragmented infrastructure information into a more structured migration roadmap. AWS Transform provides migration-focused capabilities that can support this process, while inventory validation and human review help improve the quality of the resulting plan.

Start with a small, well-understood application group. Validate the inventory, review the proposed dependencies and waves, and measure the results before scaling the approach across a larger portfolio.

The goal is not simply to migrate faster. It is to make migration decisions more traceable, better informed, and safer to execute.

Official AWS Resources

AWS PyTorch: Build, Train, and Deploy Deep Learning Models in the Cloud

Muhammad Umair Ashraf — Wed, 21 Oct 2026 02:34:59 +0000

PyTorch makes it easier to experiment with neural networks, computer vision, natural language processing, and deep learning.

But building a model is only one part of a machine learning project.

When it's time to move from experimentation to production, you need reliable compute, data storage, repeatable training, model artifacts, deployment, monitoring, and cost controls.

This is where AWS can help.

By combining PyTorch, Amazon SageMaker AI, Amazon S3, and Amazon CloudWatch, developers can build machine learning workflows that move from local experiments toward scalable cloud deployments.

In this article, we'll build a simple image classifier and explore how to extend the project into an AWS-based machine learning pipeline.

1. What Is PyTorch on AWS?

PyTorch is an open-source deep learning framework that provides tensor operations, automatic differentiation, GPU acceleration, and tools for creating neural networks.

AWS provides several services that can support PyTorch workloads:

Amazon SageMaker AI: Run managed training jobs and deploy machine learning models.
Amazon S3: Store datasets, model artifacts, and training outputs.
Amazon EC2: Run PyTorch on virtual machines, including suitable GPU instances.
AWS Deep Learning Containers: Use supported, preconfigured machine learning environments.
Amazon CloudWatch: Monitor supported metrics, logs, and application behavior.
AWS IAM: Control access to training data, infrastructure, and model artifacts.

You don't need all these services for every project. Start with what your workload requires and add complexity when it provides a clear benefit.

2. Understand the Architecture

A typical workflow looks like this:

        Training Dataset
               |
               v
         Amazon S3
               |
               v
      Amazon SageMaker AI
          Training Job
               |
               v
         PyTorch Model
               |
               v
       Model Artifacts in S3
               |
               v
       Deployment / Inference
               |
               v
       Application Predictions

Amazon S3 provides durable storage for datasets and artifacts. SageMaker AI can run managed training jobs, while a suitable inference service can expose the trained model to applications.

CloudWatch and related AWS monitoring capabilities help you investigate failures, latency, and resource usage.

For small experiments, you can train locally first. For larger workloads, managed training can reduce infrastructure-management overhead.

3. Hands-On Project: Build a Digit Classifier

We'll train a small neural network on the MNIST handwritten-digit dataset.

Our model will learn to classify grayscale images into one of ten categories, representing the digits from 0 to 9.

Prerequisites

You'll need:

Python 3.
Basic Python knowledge.
An internet connection to download the dataset.
An AWS account only when you move to the cloud steps.

The first part runs locally and does not require AWS resources.

Step 1: Create a project environment

Create a project directory and enter it:

mkdir aws-pytorch-demo
cd aws-pytorch-demo
python -m venv .venv

Activate the virtual environment on Windows:

.venv\Scripts\Activate.ps1

On Linux or macOS:

source .venv/bin/activate

Install the dependencies:

pip install torch torchvision

For GPU training, install a PyTorch build compatible with your GPU and CUDA configuration. Follow the official installation instructions: https://pytorch.org/get-started/locally/.

Step 2: Create the training script

Create train.py:

import torch
from torch import nn
from torch.utils.data import DataLoader
from torchvision import datasets, transforms

device = torch.device(
    "cuda" if torch.cuda.is_available() else "cpu"
)

print(f"Training device: {device}")

transform = transforms.ToTensor()

train_data = datasets.MNIST(
    root="data",
    train=True,
    download=True,
    transform=transform,
)

test_data = datasets.MNIST(
    root="data",
    train=False,
    download=True,
    transform=transform,
)

train_loader = DataLoader(
    train_data,
    batch_size=64,
    shuffle=True,
)

test_loader = DataLoader(
    test_data,
    batch_size=256,
    shuffle=False,
)


class DigitClassifier(nn.Module):
    def __init__(self):
        super().__init__()

        self.network = nn.Sequential(
            nn.Flatten(),
            nn.Linear(28 * 28, 128),
            nn.ReLU(),
            nn.Linear(128, 10),
        )

    def forward(self, x):
        return self.network(x)


model = DigitClassifier().to(device)

criterion = nn.CrossEntropyLoss()
optimizer = torch.optim.Adam(
    model.parameters(),
    lr=0.001,
)

# Training loop
for epoch in range(3):
    model.train()
    total_loss = 0.0

    for images, labels in train_loader:
        images = images.to(device)
        labels = labels.to(device)

        optimizer.zero_grad()

        outputs = model(images)
        loss = criterion(outputs, labels)

        loss.backward()
        optimizer.step()

        total_loss += loss.item()

    average_loss = total_loss / len(train_loader)

    print(
        f"Epoch {epoch + 1}/3, "
        f"Loss: {average_loss:.4f}"
    )

# Evaluation
model.eval()
correct = 0
total = 0

with torch.no_grad():
    for images, labels in test_loader:
        images = images.to(device)
        labels = labels.to(device)

        outputs = model(images)
        predictions = outputs.argmax(dim=1)

        correct += (predictions == labels).sum().item()
        total += labels.size(0)

accuracy = 100 * correct / total
print(f"Test accuracy: {accuracy:.2f}%")

# Save model parameters
torch.save(
    model.state_dict(),
    "digit_classifier.pth",
)

print("Saved digit_classifier.pth")

Step 3: Train the model

Run:

python train.py

The script downloads MNIST, trains the neural network, evaluates it against the test dataset, and saves the learned parameters.

Your output should include:

Training device: cpu
Epoch 1/3, Loss: ...
Epoch 2/3, Loss: ...
Epoch 3/3, Loss: ...
Test accuracy: ...
Saved digit_classifier.pth

The loss and accuracy values depend on the training run. If a compatible GPU is available, the script can use it automatically.

Step 4: Make a prediction

Create predict.py:

import torch
from torch import nn
from torchvision import datasets, transforms


class DigitClassifier(nn.Module):
    def __init__(self):
        super().__init__()

        self.network = nn.Sequential(
            nn.Flatten(),
            nn.Linear(28 * 28, 128),
            nn.ReLU(),
            nn.Linear(128, 10),
        )

    def forward(self, x):
        return self.network(x)


device = torch.device(
    "cuda" if torch.cuda.is_available() else "cpu"
)

model = DigitClassifier().to(device)

state = torch.load(
    "digit_classifier.pth",
    map_location=device,
    weights_only=True,
)

model.load_state_dict(state)
model.eval()

dataset = datasets.MNIST(
    root="data",
    train=False,
    download=True,
    transform=transforms.ToTensor(),
)

image, actual_label = dataset[0]

with torch.no_grad():
    logits = model(image.unsqueeze(0).to(device))
    predicted_label = logits.argmax(dim=1).item()

print(f"Predicted digit: {predicted_label}")
print(f"Actual digit: {actual_label}")

Run the prediction:

python predict.py

Example output:

Predicted digit: 7
Actual digit: 7

These values are illustrative. The actual result depends on your trained model.

You now have a basic end-to-end deep learning workflow: train, evaluate, save, reload, and predict.

4. Move the Project to AWS

Once the model works locally, you can move the workflow to AWS.

Step 1: Create an S3 bucket

Choose a globally unique bucket name:

aws s3 mb s3://YOUR-UNIQUE-PYTORCH-BUCKET \
  --region us-east-1

Replace the placeholder with your actual bucket name.

Upload the training script:

aws s3 cp train.py \
  s3://YOUR-UNIQUE-PYTORCH-BUCKET/code/train.py

For this example, the script downloads MNIST directly. A production pipeline should manage dataset preparation, storage, and versioning more explicitly.

Step 2: Run training with SageMaker AI

Amazon SageMaker AI supports PyTorch training jobs using supported framework environments and training configurations.

At a high level, you need to:

Configure an execution role with appropriate permissions.
Prepare your training script and dependencies.
Select a supported PyTorch environment.
Configure the training input and output locations.
Choose an appropriate instance type.
Set runtime limits and launch the job.
Review the training logs and saved artifacts.

Use the current official guide for the SDK version you install:

https://docs.aws.amazon.com/sagemaker/latest/dg/pytorch.html

SageMaker SDK interfaces evolve, so use examples matching your installed SDK version rather than mixing older estimator APIs with newer SDK workflows.

Step 3: Store model artifacts in S3

For a locally trained model, you can upload the saved parameters:

aws s3 cp digit_classifier.pth \
  s3://YOUR-UNIQUE-PYTORCH-BUCKET/models/digit_classifier.pth

For a managed training job, configure the output location so SageMaker AI saves the model artifacts automatically.

Keep a record of the dataset version, source-code version, training parameters, framework version, and evaluation metrics. This makes it easier to reproduce and audit experiments.

5. Deploy the Model for Inference

Training and inference are separate stages.

For an application to request predictions, you need a serving interface that loads the model, validates input, executes inference, and returns a response.

With Amazon SageMaker AI, you can deploy supported PyTorch models to a managed endpoint. The required model packaging and inference code depend on the selected deployment approach.

A typical inference flow is:

Load the approved model artifact.
Convert the input into the tensor format expected by the model.
Run the model in evaluation mode.
Convert the output into a response your application can consume.
Log relevant errors and operational metrics.

For the MNIST model, input should represent a grayscale image with dimensions of 28 × 28 pixels. Validate the request before running inference.

For workloads that don't need immediate responses, consider batch inference instead of keeping an online endpoint available continuously.

6. Production Best Practices

A model that works locally isn't automatically production-ready.

Cost optimization

Start with CPU training for small models when practical.
Use GPU instances when benchmarks show a meaningful benefit.
Set job time limits.
Stop endpoints and compute resources when they are no longer required.
Evaluate batch inference for offline workloads.
Include storage, logging, data transfer, and supporting services in cost estimates.

Security

Apply least-privilege IAM policies.
Keep S3 buckets private.
Encrypt sensitive datasets and artifacts.
Avoid embedding credentials in source code.
Restrict access to training data and deployed models.

Reproducibility

Track dataset versions, dependencies, training parameters, random seeds, and model artifacts. Store code in version control and preserve evaluation results for each model version.

Monitoring

Monitor training failures, compute utilization, inference latency, and application errors using supported AWS monitoring capabilities.

Also evaluate model quality over time. A service can remain operational while its predictions become less accurate because real-world data has changed.

Model evaluation

Don't rely on training loss alone.

For classification tasks, consider precision, recall, F1 score, confusion matrices, and performance on representative held-out data. Select metrics based on the real business problem.

7. Where Can You Use PyTorch on AWS?

Common applications include:

Computer vision: Image classification and defect detection.
Natural language processing: Text classification and domain-specific model fine-tuning.
Recommendation systems: Ranking and personalization.
Forecasting: Demand prediction and time-series analysis.
Generative AI: Training or fine-tuning compatible neural network models.

For large-scale distributed training, additional planning is needed for GPU memory, network communication, checkpointing, and data loading.

Final Thoughts

PyTorch provides the flexibility to build deep learning models, while AWS offers several ways to run training workloads, store model artifacts, and deploy predictions.

Start with a small experiment, validate the results, and then introduce cloud infrastructure where it provides measurable value.

The real goal is not just to train a model in the cloud. It's to create a secure, reproducible, observable machine learning workflow that can grow with your application.

Official Resources

AWS #PyTorch #MachineLearning #DeepLearning #AmazonSageMaker

AWS Lambda Web Functions: Build and Scale Web Apps Without Managing Servers

Muhammad Umair Ashraf — Tue, 20 Oct 2026 02:21:48 +0000

What if you could build a web application using a familiar Node.js framework, deploy it to AWS Lambda, and let AWS manage much of the infrastructure behind it?

That is the idea behind AWS Lambda Web Functions.

Traditionally, running a web application means thinking about servers, scaling, deployment configuration, availability, and infrastructure maintenance. Serverless computing reduces some of that operational work, but web developers still need a deployment model that fits their application.

Lambda Web Functions are designed to make that experience more natural for supported web applications.

In this article, we'll explore the architecture, deploy a small example, and discuss what to consider before using this approach in production.

What Are AWS Lambda Web Functions?

AWS Lambda Web Functions provide a way to run web applications on Lambda using familiar HTTP application patterns.

Instead of managing a traditional application server, you deploy your application to a managed environment that handles incoming HTTP requests and adjusts execution capacity according to demand.

The approach is especially relevant to developers building with supported Node.js frameworks, such as Express and Hono.

Some potential benefits include:

Less server management: Spend more time on application code and less time maintaining infrastructure.
Managed scaling: Adjust execution capacity as traffic changes.
Concurrent requests: An execution environment can handle multiple requests concurrently, within service and configuration limits.
HTTPS endpoints: Expose your application through a managed HTTPS endpoint.
Familiar development patterns: Build web applications without having to design every route around a custom event handler.

Always check the latest AWS documentation for supported runtimes, frameworks, limits, and regional availability.

How Does the Architecture Work?

The basic request flow looks like this:

Build a web application using a supported Node.js framework.
Deploy the application as a Lambda Web Function.
A browser or API client sends an HTTP request to the application's endpoint.
The application processes the request and returns an HTTP response.
AWS manages the underlying execution capacity and scaling behavior.

For applications serving users in multiple geographic locations, you can also evaluate Amazon CloudFront as an additional layer for custom domains, caching, and edge security controls.

The right design depends on latency requirements, traffic patterns, security needs, and application state.

Lambda Web Functions vs. Traditional Hosting

Feature	Traditional hosting	Lambda Web Functions
Infrastructure	Servers or containers must be configured and managed	AWS manages the underlying execution environment
Scaling	Often requires capacity and scaling configuration	Designed for managed, demand-based scaling
Application model	Runs on a configured web server or platform	Uses the Lambda Web Functions execution model
Quiet periods	Capacity may remain allocated	Can scale down as demand falls
Operations	More infrastructure responsibilities may apply	Reduced server-management overhead
Cost	Depends on hosting resources and usage	Depends on requests, compute, memory, data transfer, and supporting services

Serverless isn't automatically cheaper for every workload. Applications with steady, high utilization or specialized infrastructure needs may be better suited to another hosting model.

Hands-On: Deploy a Simple Web Application

Let's walk through a small deployment workflow.

Step 1: Prepare your environment

You'll need:

An AWS account with access to Lambda Web Functions in a supported Region.
AWS CLI configured with appropriate credentials.
The required deployment tooling.
A compatible Node.js development environment.
IAM permissions to deploy and manage the resources involved.

Follow the current AWS getting-started guide for the exact prerequisites.

Step 2: Deploy a starter application

The documented workflow includes deploying a sample application. The following illustrates the command format:

aws lambda-web deploy \
  --name my-web-app \
  --hello-world

Review the current AWS documentation for installation and authentication instructions, as service tooling can evolve.

After deployment, use the endpoint returned by the deployment process.

Step 3: Test the endpoint

curl https://YOUR-APPLICATION-ENDPOINT

Replace YOUR-APPLICATION-ENDPOINT with the actual hostname provided by AWS.

A successful request should return an HTTP response from the sample application.

Step 4: Create a simple Express route

Here is an illustrative Node.js example:

import express from "express";

const app = express();

app.get("/", (req, res) => {
  res.json({
    service: "Lambda Web Functions",
    status: "running",
    message: "Hello from AWS!"
  });
});

export default app;

This route returns a JSON response when a client requests /.

Make sure your project uses the correct module format, entry point, and packaging structure required by the current Lambda Web Functions tooling. The example is not a substitute for the official framework setup instructions.

Step 5: Deploy your application code

The documented workflow also illustrates deploying code from a local directory:

aws lambda-web deploy \
  --name my-web-app \
  --code ./my-web-app

Prepare the directory according to the current deployment requirements, then run the appropriate deployment command.

Step 6: Verify the result

Send a request to the root route:

curl https://YOUR-APPLICATION-ENDPOINT/

For the example route above, the expected JSON body is:

{
  "service": "Lambda Web Functions",
  "status": "running",
  "message": "Hello from AWS!"
}

If the request fails, inspect the deployment output, application logs, IAM permissions, and framework configuration.

Step 7: Clean up

When you're finished experimenting, follow the current AWS cleanup instructions and remove resources you no longer need. Check for supporting resources that may continue to incur charges.

Production Considerations

A successful deployment is only the beginning. Production applications need to be designed for concurrency, security, reliability, and cost.

1. Handle concurrent requests safely

Don't assume every HTTP request gets its own isolated, permanent process.

Avoid storing user-specific information in shared global variables. Keep request data isolated and use an appropriate external store for persistent state.

Review the concurrency limits and configuration options for the service before deploying high-traffic workloads.

2. Keep application state external

For durable application data, use an appropriate database or object store rather than relying on temporary execution-environment files.

Use a suitable session-management strategy, and protect session identifiers and credentials.

3. Apply least-privilege security

For production deployments:

Grant only the IAM permissions the application requires.
Validate incoming data and handle errors safely.
Store secrets in a dedicated secrets-management service.
Protect downstream databases and APIs.
Consider CloudFront and AWS WAF where caching, custom domains, or web traffic filtering are needed.

4. Monitor the application

Monitor request volume, latency, errors, and downstream dependencies. Use the logging and monitoring options supported by the service to investigate slow requests and unexpected behavior.

Managed infrastructure reduces operational effort, but it doesn't eliminate the need for observability.

Understanding the Cost

Before migrating an application, evaluate the complete cost rather than focusing on a single service.

Depending on the architecture, costs may include:

Requests and compute usage.
Memory consumption over the applicable environment lifetime.
Data transfer.
Logging and monitoring.
CloudFront, databases, and other supporting services.

Estimate traffic volume, average response time, memory requirements, and response sizes. Then test with realistic traffic and compare actual usage with your estimates.

When Should You Consider Lambda Web Functions?

This approach may be worth exploring for:

Node.js web applications and APIs.
Internal dashboards and developer tools.
Prototypes and small web products.
Applications with changing traffic levels.
Teams that want to reduce server-management overhead.

It may not fit applications that require an unsupported runtime, a different execution model, or infrastructure behavior the service doesn't provide.

Verify current framework and runtime support before planning a migration.

Final Thoughts

AWS Lambda Web Functions offer another option for building web applications on AWS: use familiar web development patterns while relying on managed infrastructure for execution and scaling.

The real value isn't simply removing servers. It's reducing unnecessary operational work while keeping the application reliable, secure, observable, and cost-effective.

Start with a small application, test its HTTP behavior, review its concurrency characteristics, and compare the results with your current hosting approach before moving production workloads.

Official AWS Resources

AWS #Serverless #NodeJS #WebDevelopment #CloudComputing

AWS Context: How Knowledge Graphs Give AI Agents Governed Enterprise Context

Muhammad Umair Ashraf — Sat, 17 Oct 2026 02:52:46 +0000

AI agents can generate answers, write code, and automate workflows. But when they work with enterprise data, one important challenge remains: understanding how information connects across different systems.

Imagine asking an AI agent:

"Why is this customer's order delayed, and are they eligible for a refund?"

The answer may require customer records, order details, shipment status, refund policies, and business rules from multiple systems.

Access to those sources is not enough. The agent needs to identify the correct relationships, retrieve relevant evidence, and follow the organization's access and approval rules.

This is the problem AWS Context is designed to address.

AWS introduced AWS Context in June 2026 as a forthcoming service designed to map relationships across enterprise data into a knowledge graph, helping agents retrieve governed context at runtime.

Check the latest AWS announcements for current service availability and supported capabilities before planning a deployment.

What Is AWS Context?

AWS Context is designed to connect enterprise data, business concepts, and organizational knowledge through a shared knowledge graph.

Its announced approach includes several capabilities:

Relationship discovery: Identify relationships between data assets and business entities.
Knowledge graphs: Represent connections between datasets, entities, and business concepts.
Curated business knowledge: Allow data stewards to review relationships and attach trusted definitions and rules.
Governed retrieval: Help agents retrieve context while respecting the access boundaries established for the requesting identity.
Interoperability: AWS has described publishing key context metadata in Apache Iceberg format in Amazon S3 Tables for use with compatible tools.

The goal is to make enterprise knowledge reusable across multiple AI applications instead of embedding the same assumptions in every prompt.

Official announcement: https://aws.amazon.com/blogs/machine-learning/context-intelligence-for-your-data-and-ai-agents-at-scale/

Why Do AI Agents Need a Knowledge Graph?

Traditional retrieval-augmented generation (RAG) often retrieves documents or passages that match a question. This is useful, but individual documents do not always reveal all the relationships needed to answer a business question.

Consider this simplified knowledge graph:

Customer
   |
   | places
   v
Order
   |
   | has
   v
Shipment
   |
   | has status
   v
Delivery Delay

Order
   |
   | evaluated under
   v
Refund Policy

The graph connects the customer, order, shipment, and policy.

An agent can use these relationships to investigate a question rather than treating each record as an isolated piece of information.

For example, finding a refund policy is not enough. The agent must identify the relevant order, retrieve the current shipment status, and apply the correct policy.

A knowledge graph helps organize these relationships. The underlying data must still be reliable, and the agent must validate its findings before making decisions.

How AWS Context Fits into an AI Architecture

A simplified conceptual architecture looks like this:

           User Request
                |
                v
          AI Application
                |
                v
              AI Agent
                |
                v
            AWS Context
                |
                v
      Governed Knowledge Graph
                |
       +--------+--------+
       |        |        |
       v        v        v
    Customer  Orders  Policies
      Data     Data   and Rules
                |
                v
      Evidence-Based Response
                |
                v
      Approval Before Action

This diagram illustrates the intended workflow, not a deployed AWS Context configuration.

The agent identifies the context required for a task, retrieves relevant relationships through configured interfaces, and uses the resulting evidence to prepare an answer.

Access controls are essential. An agent should not retrieve restricted records simply because they are connected to another accessible entity.

Mini-Project: Build a Context-Aware Customer Support Agent

Let's design a small customer-support workflow that connects customer information, order records, shipment status, and refund policies.

Project goal

The agent should:

Identify the relevant customer and order.
Retrieve the latest shipment status.
Find the applicable refund policy.
Explain the situation using evidence.
Request human approval before executing a refund.

The following example uses fictional data. It demonstrates the intended workflow rather than a live AWS Context deployment or an executed integration test.

Step 1: Prepare sample data

Customer and order records:

Customer ID	Order ID	Status
C101	O501	Shipped
C102	O502	Processing

Shipment records:

Shipment ID	Order ID	Shipment status
S801	O501	Delayed
S802	O502	Awaiting dispatch

Sample business rule:

Refund eligibility depends on order status, product category, delivery conditions, and the applicable return window. A delayed shipment alone does not automatically guarantee a refund.

In production, these records should come from authoritative systems, and the refund rule should come from an approved policy source.

Step 2: Model the relationships

The context model might contain:

Customer C101
    |
    | owns
    v
Order O501
    |
    | has shipment
    v
Shipment S801
    |
    | current status
    v
Delayed

Order O501
    |
    | evaluated against
    v
Refund Policy

Where supported, record the source, freshness, and review status of important relationships. This helps distinguish verified facts from assumptions.

Step 3: Give the agent a task

Use this prompt in your prototype:

A customer wants an update on a delayed order. Identify the relevant order, retrieve its latest shipment status, locate the applicable refund policy, and explain the available options. Use only authorized data and approved rules. If required information is missing, state what is missing. Do not initiate a refund or modify the order.

The intended workflow is:

Resolve the customer and order identifiers.
Retrieve the authorized shipment record.
Retrieve the applicable policy.
Evaluate the available evidence.
Produce an explanation with source references.
Escalate if the evidence is incomplete or human review is required.

The exact retrieval APIs and implementation steps depend on the interfaces available in your environment. Check the current AWS documentation before implementing a specific SDK call or endpoint.

Step 4: Define the expected output

For fictional order O501, the agent could produce a response like this:

{
  "order_id": "O501",
  "shipment_status": "Delayed",
  "policy_check": "Additional information required",
  "explanation": "A shipment delay alone does not establish refund eligibility.",
  "next_step": "Check the applicable return window and order conditions.",
  "refund_execution": "NOT_EXECUTED",
  "human_review_required": true
}

This is an illustrative response schema, not actual output from AWS Context.

The key behavior is that the agent does not invent a refund entitlement. It explains what is known, identifies missing information, and avoids executing an unapproved action.

Step 5: Add security and governance

For a production implementation, enforce controls outside the language model wherever possible.

Least privilege: Give the agent only the access it needs.
Identity-aware retrieval: Ensure user permissions constrain accessible data.
Human approval: Require approval for refunds and other consequential actions.
Source traceability: Preserve references to the data and policies behind an answer.
Audit logging: Record relevant retrieval and execution activity.
Freshness checks: Revalidate the order status before taking action.
Safe failure handling: Escalate when records conflict or evidence is insufficient.

The goal is not simply to make an agent more knowledgeable. It is to make its decisions more explainable and controllable.

AWS Context vs. Traditional RAG

These approaches solve related but different problems.

Capability	Traditional document RAG	AWS Context's announced approach
Main focus	Retrieve relevant document passages	Connect relationships and business context
Data representation	Documents, chunks, and metadata	Knowledge graph across connected data
Business definitions	Often supplied through documents or application logic	Can be curated in the context layer
Cross-source relationships	May require custom joins and retrieval logic	Relationship discovery is a core design goal
Governance	Depends on implementation	Designed around governed context retrieval

They can complement each other. A knowledge graph might identify the correct refund policy and order, while a RAG system retrieves the detailed policy paragraphs.

A production architecture may benefit from both structured relationships and unstructured document retrieval.

Where Can This Make a Difference?

Customer support

Connect customer profiles, orders, shipments, support cases, and policies to provide more relevant answers.

Financial operations

Relate transactions, accounts, approval rules, and audit records to support investigations while preserving access controls.

Enterprise analytics

Connect metrics, data assets, ownership information, and definitions so agents can better understand what a metric means and where it originates.

Internal knowledge discovery

Help employees navigate relationships between teams, projects, systems, and documentation rather than searching for isolated documents.

The actual value depends on the quality of the data, the accuracy of the relationships, and the effectiveness of governance controls.

What Should Teams Evaluate Before Production?

Before adopting a context layer, ask:

Data quality: Are source records accurate and consistently identified?
Relationship quality: Can inferred relationships be reviewed before they affect important decisions?
Authority: Which system is authoritative when sources disagree?
Permissions: Does the user's identity constrain the context available to the agent?
Freshness: How quickly are changes in data and policies reflected?
Traceability: Can the team identify the sources and rules behind an answer?
Evaluation: Are agent responses tested against known scenarios and conflicting evidence?
Failure handling: Does the agent ask for clarification or escalate when context is incomplete?

A knowledge graph alone does not guarantee correct answers. Source quality, retrieval behavior, access controls, and testing remain essential.

Getting Started with AWS

AWS introduced AWS Context in June 2026 as a forthcoming service. Check the latest announcements and documentation for availability, supported regions, prerequisites, and integration details.

Useful resources:

AWS Context announcement: https://aws.amazon.com/blogs/machine-learning/context-intelligence-for-your-data-and-ai-agents-at-scale/
AWS Summit New York 2026: https://www.aboutamazon.com/news/aws/aws-summit-nyc-2026-ai-agents
Context Ontology Accelerator: https://aws.github.io/context-ontology-accelerator/
AWS Prescriptive Guidance on knowledge bases for agentic AI: https://docs.aws.amazon.com/prescriptive-guidance/latest/govern-architect-agentic-ai/core-services-knowledge-bases.html

If you want to experiment with knowledge graphs before a managed AWS Context deployment is available to you, explore the open-source Context Ontology Accelerator. It provides an alternative approach to modeling business entities and relationships, with human review and components such as Amazon Neptune, Amazon OpenSearch Serverless, and Amazon Bedrock.

Its setup is different from the managed service.

Conclusion

AI agents need more than access to data. They need to understand relationships, business definitions, and the rules that determine which information is relevant.

AWS Context is designed to address this challenge through a shared knowledge graph and governed context retrieval at runtime.

For teams building enterprise agents, the opportunity is to move from isolated answers toward decisions grounded in connected business information.

Start with a small workflow, validate the relationships and source data, enforce least-privilege access, and keep human approval in place for consequential actions.

The future of enterprise AI is not just about smarter models. It is about giving those models the right context, with the right controls, at the right time.

What enterprise workflow would benefit most from a shared knowledge graph in your organization?

aws #ai #cloud #dataengineering

Redshift in the Agent Toolkit: Build, Query, and Troubleshoot with AI Coding Agents

Muhammad Umair Ashraf — Fri, 16 Oct 2026 03:08:43 +0000

AI coding agents are changing how developers interact with cloud infrastructure and databases. Instead of manually searching documentation and writing every query from scratch, developers can describe a task in natural language and use an AI assistant to help explore schemas, generate SQL, and investigate database problems.

With Agent Toolkit for AWS and Amazon Redshift integration, developers can bring these workflows into coding environments such as Claude Code, Kiro, and Cursor.

In this tutorial, we'll explore the concept and build a small sales analytics project using Amazon Redshift and SQL.

What is Redshift in the Agent Toolkit?

Amazon Redshift is an AWS cloud data warehouse designed for analytics and SQL-based workloads.

Agent Toolkit for AWS provides integrations and specialized skills that help supported AI coding agents work with AWS services. For Redshift-related workflows, these capabilities can help developers:

Discover tables, columns, and database metadata.
Generate and explain SQL queries.
Analyze sales and reporting data.
Troubleshoot SQL errors and performance issues.
Review analytical query patterns and materialized views.
Assist with data warehouse migration and validation workflows.

The agent helps developers understand and work with the data warehouse. It does not eliminate the need to review SQL, validate results, or control permissions.

Official announcement: https://aws.amazon.com/about-aws/whats-new/2026/08/redshift-agenttoolkit-for-ai-assisted-datawarehouse-mgmt/

How the workflow works

A simplified architecture looks like this:

Developer
   |
   v
AI Coding Agent
(Claude Code / Kiro / Cursor)
   |
   v
Agent Toolkit for AWS
   |
   v
Configured AWS Tools and Permissions
   |
   v
Amazon Redshift
   |
   v
Query Results and Recommendations

The developer describes a task, the agent uses its configured capabilities to help perform it, and Redshift returns the query results.

Actual functionality depends on the installed integrations, AWS credentials, region, and database permissions.

Project: Investigate a sales revenue decline

Imagine your business team reports that revenue is declining in one region. You want to analyze daily sales and identify where the change occurred.

For this demonstration, we'll use fictional sales data.

Prerequisites

You'll need:

An Amazon Redshift Serverless workgroup or provisioned cluster.
A database and schema where you can create a sample table.
Appropriate AWS credentials and database permissions.
A supported coding agent with Agent Toolkit for AWS configured.

For learning, use a development environment and non-sensitive data.

Getting started with Redshift: https://docs.aws.amazon.com/redshift/latest/gsg/getting-started.html

Step 1: Create a sales table

Run this SQL in your authorized Redshift query editor:

CREATE TABLE sales_orders (
    order_id     INTEGER,
    order_date   DATE,
    region       VARCHAR(50),
    revenue      DECIMAL(12, 2),
    status       VARCHAR(20)
);

Step 2: Insert sample records

INSERT INTO sales_orders
    (order_id, order_date, region, revenue, status)
VALUES
    (1, '2026-10-01', 'North', 1200.00, 'completed'),
    (2, '2026-10-01', 'South',  900.00, 'completed'),
    (3, '2026-10-02', 'North', 1500.00, 'completed'),
    (4, '2026-10-02', 'South',  650.00, 'completed'),
    (5, '2026-10-03', 'North',  800.00, 'completed'),
    (6, '2026-10-03', 'South',  400.00, 'completed');

We now have a small dataset with two regions and three days of sales.

Step 3: Ask your AI coding agent to inspect the schema

Try this prompt in your configured coding agent:

Inspect the accessible Amazon Redshift database and identify the tables and columns relevant to sales reporting. Explain which columns contain the order date, region, revenue, and status. Do not modify any data.

This is a useful starting point because the agent can work with actual database metadata rather than relying entirely on assumptions.

Step 4: Generate a daily revenue report

Next, ask:

Write a Redshift SQL query to calculate completed revenue by day and region. Exclude non-completed orders and sort the output by date and region. Explain the query before execution.

A suitable query is:

SELECT
    order_date,
    region,
    SUM(revenue) AS total_revenue
FROM sales_orders
WHERE status = 'completed'
GROUP BY
    order_date,
    region
ORDER BY
    order_date,
    region;

Expected observations:

North revenue on October 1: $1,200
North revenue on October 2: $1,500
North revenue on October 3: $800
South revenue on October 1: $900
South revenue on October 2: $650
South revenue on October 3: $400

These values are based on the sample records above. The report makes daily changes visible without manually calculating totals.

Step 5: Find the percentage change

Now ask the agent:

Compare daily completed revenue for each region. Calculate the percentage change from the previous available date, and explain any limitations in the analysis. Generate a read-only query first.

Here is one way to implement that analysis:

WITH daily_revenue AS (
    SELECT
        order_date,
        region,
        SUM(revenue) AS revenue
    FROM sales_orders
    WHERE status = 'completed'
    GROUP BY
        order_date,
        region
),
revenue_comparison AS (
    SELECT
        order_date,
        region,
        revenue,
        LAG(revenue) OVER (
            PARTITION BY region
            ORDER BY order_date
        ) AS previous_revenue
    FROM daily_revenue
)
SELECT
    order_date,
    region,
    revenue,
    previous_revenue,
    ROUND(
        100.0 * (revenue - previous_revenue)
        / NULLIF(previous_revenue, 0),
        2
    ) AS percentage_change
FROM revenue_comparison
ORDER BY
    region,
    order_date;

The LAG() window function retrieves the previous available revenue value for the same region. NULLIF() prevents division by zero.

This helps identify when revenue decreased. It does not establish the underlying cause. To investigate further, you might need order volumes, refunds, product categories, inventory data, or application logs.

Troubleshooting Redshift with AI

AI coding agents can also help review queries and explain possible performance problems.

Try this prompt:

Review this Redshift query for correctness and performance. Identify potentially inefficient joins, unnecessary scans, filtering problems, and opportunities to improve the query. Explain each recommendation and do not execute changes.

Depending on the available tools and information, an agent can help you investigate:

SQL syntax and incorrect joins.
Filters that change the meaning of a report.
Table distribution and sort-key choices.
Repeated analytical queries that may benefit from materialized views.
Query plans and relevant performance metadata.

For meaningful performance tuning, provide actual query plans and workload evidence. Test the proposed query against representative data and verify that the output remains correct.

Setting up Agent Toolkit for AWS

Use the current official documentation to configure the toolkit and your preferred coding agent.

Quick start: https://docs.aws.amazon.com/agent-toolkit/latest/userguide/quick-start.html

The documented setup flow includes configuring your AWS environment and installing the integrations appropriate to your editor. A documented CLI setup command is:

aws configure agent-toolkit

Verify the required AWS CLI version and current setup instructions before running it.

For editor-specific steps, see the AWS Builder Center setup guide for Kiro, Claude Code, and Cursor.

Installing an integration does not automatically grant database access. Your AWS identity, Redshift configuration, and database permissions must be set up appropriately.

Security practices you should follow

Connecting an AI coding agent to a database requires careful permission management.

Start with read-only access. Allow only the metadata inspection and queries needed for the task.
Review SQL before execution. Check filters, joins, aggregation, and data scope.
Require approval for mutations. Treat data changes, schema changes, and permission changes as higher-risk operations.
Protect sensitive data. Avoid exposing credentials or unnecessary confidential records in prompts.
Apply least privilege. Configure AWS IAM and database-level permissions appropriately.
Audit activity. Use available AWS and database logging to investigate access and execution.
Verify every result. Compare agent-generated reports with trusted queries and known totals.

The goal is to make database development more productive while keeping humans accountable for important decisions.

What should you measure?

If you're introducing agent-assisted workflows to your team, measure the impact rather than assuming it will be positive.

Useful metrics include:

Time to create a report.
Time to diagnose a query error.
Percentage of generated queries accepted after review.
Query execution time before and after optimization.
Accuracy against an established reporting baseline.
Unsafe operations prevented through approval controls.

Conclusion

Amazon Redshift and Agent Toolkit for AWS create new opportunities for AI-assisted data engineering.

Developers using Claude Code, Kiro, and Cursor can explore schemas, generate analytical SQL, investigate data patterns, and review troubleshooting recommendations through a more conversational workflow.

Start with a small read-only project, validate every query, and introduce broader capabilities only after you have reliable security and review processes.

Useful resources

aws #redshift #ai #sql #dataengineering #devtools

Build Enterprise RAG on AWS with Managed Knowledge Bases, Smart Parsing, and Agentic Retrieval

Muhammad Umair Ashraf — Thu, 15 Oct 2026 04:31:12 +0000

Enterprise AI assistants need more than a language model. They need access to the right documents, reliable retrieval, and answers that users can verify.

Imagine asking an internal assistant:

Which team owns our ML platform, what is its annual cloud budget, and does our purchasing policy allow annual prepayment?

The answer may be spread across a team ownership document, a budget file, and an expense policy. A basic retrieval pipeline might find only one of them, leaving the answer incomplete.

Amazon Bedrock Managed Knowledge Base helps simplify enterprise Retrieval-Augmented Generation (RAG) with managed ingestion and retrieval, native data connectors, Smart Parsing, and agentic retrieval.

In this tutorial, we'll explore these capabilities and build a Python demo that retrieves evidence from multiple enterprise documents.

1. What is Amazon Bedrock Managed Knowledge Base?

RAG combines document retrieval with a generative AI model. Instead of relying only on information learned during training, an application retrieves relevant information from configured sources and uses it to generate an answer.

A typical RAG pipeline includes:

Data source connections
Document parsing and chunking
Embeddings and indexing
Retrieval and ranking
Answer generation
Source references and evaluation

Managing each component independently can add operational complexity.

Amazon Bedrock Managed Knowledge Base provides a managed approach to knowledge ingestion and retrieval, helping developers focus on the application rather than building every RAG component themselves.

Official documentation: Amazon Bedrock Managed Knowledge Base

2. Native data connectors

Enterprise knowledge is often distributed across different platforms.

Managed Knowledge Base supports native connectors for supported sources such as:

Amazon S3
Microsoft SharePoint
Atlassian Confluence
Google Drive
Microsoft OneDrive
Web Crawler

These connectors can reduce the amount of custom ingestion code required to bring enterprise content into a knowledge base.

For example, a company could retrieve engineering runbooks from S3 and business policies from a supported collaboration platform, then use that information to answer internal questions.

Connectors still require appropriate permissions, synchronization, and access-control configuration. Always confirm the currently supported sources and prerequisites in the AWS documentation.

Reference: Managed Knowledge Base announcement

3. Smart Parsing for complex documents

Not all enterprise data is plain text.

PDFs, reports, presentations, and technical documents may contain tables, diagrams, screenshots, or complex layouts. Basic text extraction can lose important relationships between these elements.

Smart Parsing helps process supported content so that it can be used more effectively during retrieval.

Potential use cases include:

Architecture documentation
Technical reports
Business policies
Documents containing tables and diagrams
Supported scanned or visual content

Parsing quality should still be tested with representative documents. Important figures, table relationships, and diagram details may need verification.

Reference: Amazon Bedrock Managed Knowledge Base announcement

4. Agentic retrieval: Handle multi-part questions

Traditional retrieval typically searches for content relevant to a query. This works well for straightforward questions, but more complex questions may require multiple searches.

Consider:

Compare our platform budget with the purchasing policy. Is annual prepayment permitted, and what approvals are required?

The application needs to retrieve the budget, find the policy, connect the relevant conditions, and generate an answer grounded in the available evidence.

Agentic retrieval uses a foundation model to plan and refine retrieval across configured knowledge base retrievers. It can decompose a complex question into sub-queries, retrieve information iteratively, and assess whether enough evidence is available.

This can help with:

Enterprise policy assistants
Technical support
Internal documentation search
Cross-document comparisons
Questions with multiple related parts

Agentic retrieval can improve the retrieval process, but it does not guarantee correct answers. Validate the results and citations before relying on them in production.

Reference: Use agentic retrieval to query a knowledge base

5. Demo architecture

We'll create an enterprise policy assistant using three fictional documents.

Enterprise Documents
       |
       v
Amazon S3
       |
       v
Amazon Bedrock Managed Knowledge Base
       |
       v
Document Parsing and Indexing
       |
       v
Agentic Retrieval
       |
       +--> Team ownership
       +--> Cloud budget
       +--> Expense policy
       |
       v
Generated answer + source references

Amazon Bedrock manages much of the underlying ingestion and retrieval infrastructure. The application still needs permissions, error handling, and security controls.

6. Build the Python demo

Prerequisites

You'll need:

An AWS account
Access to Amazon Bedrock in a supported Region
A Managed Knowledge Base
An S3 bucket containing the sample documents
An appropriate IAM identity and permissions
Python 3 and Boto3

Step 1: Create the project

enterprise-rag-demo/
├── documents/
│   ├── team-ownership.md
│   ├── cloud-budget.md
│   └── expense-policy.md
└── query_enterprise_kb.py

Step 2: Add sample documents

Create documents/team-ownership.md:

# ML Platform Team Ownership

The ML Platform team owns the internal machine learning
platform and its shared deployment infrastructure.

The team supports model deployment, platform monitoring,
and infrastructure reliability.

The team reports to the Engineering organization.

Create documents/cloud-budget.md:

# ML Platform Cloud Budget

The ML Platform team has an illustrative annual cloud
infrastructure budget of $120,000.

The budget covers approved compute, storage, networking,
monitoring, and platform infrastructure expenses.

Purchases must follow the company expense policy and
the organization's approval process.

Create documents/expense-policy.md:

# Cloud Expense and Prepayment Policy

Annual cloud prepayment may be considered when the
purchase meets procurement requirements and has the
required financial approval.

The request must include the business justification,
contract terms, expected savings, and budget confirmation.

Having sufficient budget does not automatically approve
a purchase.

The responsible finance approver must review the request
before a commitment is made.

These are fictional examples. The budget is not an AWS pricing estimate.

Step 3: Upload documents to S3

Create an S3 bucket in a supported Region and upload the three files to a prefix such as:

s3://YOUR-BUCKET-NAME/enterprise-rag-demo/

Replace YOUR-BUCKET-NAME with your bucket name.

Step 4: Create the Managed Knowledge Base

Open the Amazon Bedrock console and:

Navigate to Knowledge Bases.
Create a Managed Knowledge Base.
Configure the name and supported Region.
Select Amazon S3 as the source.
Configure the bucket or prefix containing your documents.
Review the IAM permissions and role configuration.
Complete creation and synchronize the data source.
Wait for ingestion to finish successfully.

Save the knowledge base ID. We'll use it in the Python application.

See the official setup guide for current requirements and console options.

Step 5: Install Boto3

python -m pip install --upgrade boto3

Configure credentials through an appropriate IAM identity, CLI profile, or execution role.

For a local AWS CLI setup, you can use:

aws configure

Avoid hardcoding AWS access keys in your application.

Step 6: Query the knowledge base

Create query_enterprise_kb.py:

import os
import boto3

REGION = os.getenv("AWS_REGION", "us-east-1")
KNOWLEDGE_BASE_ID = os.environ["KNOWLEDGE_BASE_ID"]

client = boto3.client(
    "bedrock-agent-runtime",
    region_name=REGION
)

question = (
    "Which team owns the ML platform, what is its annual "
    "cloud budget, and does the expense policy allow annual "
    "prepayment? Explain the conditions and identify what "
    "must happen before a commitment is made."
)

response = client.agentic_retrieve_stream(
    messages=[
        {
            "role": "user",
            "content": {
                "text": question
            }
        }
    ],
    retrievers=[
        {
            "description": "Enterprise policies and platform documents",
            "configuration": {
                "knowledgeBase": {
                    "knowledgeBaseId": KNOWLEDGE_BASE_ID
                }
            }
        }
    ],
    agenticRetrieveConfiguration={
        "foundationModelType": "MANAGED",
        "rerankingModelType": "MANAGED"
    },
    generateResponse=True
)

for event in response["stream"]:
    if "responseEvent" in event:
        print(
            event["responseEvent"].get("text", ""),
            end="",
            flush=True
        )

    elif "traceEvent" in event:
        print("\n[Retrieval trace event received]")

    elif "result" in event:
        result = event["result"]

        print("\n\n--- Retrieved Sources ---")

        for index, item in enumerate(
            result.get("results", []),
            start=1
        ):
            content = item.get("content", {})
            metadata = item.get("metadata", {})

            print(f"\nSource {index}")
            print("Retriever:", item.get("sourceRetriever"))
            print("Metadata:", metadata)
            print("Content:", content.get("text", ""))

        generated = result.get("generatedResponse", {})

        print("\n--- Citation Mappings ---")
        print(generated.get("citations", []))

The example uses managed retrieval planning and reranking. The returned documents, response text, trace events, and citation mappings depend on the service configuration and available evidence.

For production, send traces to structured logging rather than printing sensitive document contents.

API reference: AgenticRetrieveStream

Step 7: Run the demo

In PowerShell:

$env:AWS_REGION = "us-east-1"
$env:KNOWLEDGE_BASE_ID = "YOUR_KNOWLEDGE_BASE_ID"

python query_enterprise_kb.py

In Bash:

export AWS_REGION="us-east-1"
export KNOWLEDGE_BASE_ID="YOUR_KNOWLEDGE_BASE_ID"

python query_enterprise_kb.py

Use your actual knowledge base ID and the Region in which it was created. Ensure the identity running the script has the required permissions for the agentic retrieval API and configured managed functionality.

7. What should the answer contain?

Based on the sample documents, a successful response should identify:

Team ownership: The ML Platform team owns the internal ML platform.
Annual budget: The illustrative annual cloud infrastructure budget is $120,000.
Prepayment policy: Annual prepayment may be considered, but is not automatically approved.
Required conditions: The request needs a business justification, contract terms, expected savings, budget confirmation, and financial review before a commitment is made.

The response should include source references so that users can verify important claims.

This is the expected result based on the example documents, not output from a live AWS execution. Run the demo and validate the actual response and citations in your environment.

8. Production considerations

Before deploying an enterprise RAG application, consider these areas.

Access control: Ensure users retrieve only documents they are authorized to access. Test supported access-control mechanisms and identity behavior.

Data freshness: Monitor synchronization and ingestion failures.

Grounded answers: Require evidence for important claims and allow the assistant to say when information is missing.

Prompt injection: Treat retrieved content as untrusted input. A document must not be able to override your application's security rules.

Observability: Track failed queries, retrieval traces, latency, and source coverage while protecting sensitive information.

Cost and latency: Agentic retrieval may involve multiple retrieval steps. Measure whether the additional work improves results enough to justify the cost.

Evaluation: Test against representative questions with known answers and expected sources. Measure answer accuracy, citation quality, and retrieval completeness.

9. When should you use agentic retrieval?

Use agentic retrieval when questions need information from multiple sources or involve several related steps.

For straightforward lookups, conventional retrieval may be simpler and faster. Compare both approaches with a representative evaluation set before choosing the production design.

Next, you can extend this demo by adding a second supported data connector, testing documents containing tables and diagrams, comparing retrieval approaches, and creating a simple web interface for employees.

Conclusion

Enterprise RAG is about more than searching document chunks. It requires connecting knowledge, processing documents, retrieving the right evidence, and generating answers that users can verify.

Amazon Bedrock Managed Knowledge Base brings native data connectors, Smart Parsing, managed indexing, and agentic retrieval into an integrated experience.

The demo illustrates how Python can query a knowledge base, retrieve information across documents, and expose source references for validation.

My takeaway: Build AI assistants that do not just answer questions—they find evidence, connect information, and make their conclusions verifiable.

What would you build first: an internal policy assistant, a technical documentation assistant, or a customer support knowledge agent?

DEV Community: Muhammad Umair Ashraf

Building a Serverless Multi-Agent Robotics Platform on AWS

Why combine AI agents with serverless robotics?

1. Architecture overview

2. Choose AWS services for specific responsibilities

3. Create specialized agents

Intent agent

Planning agent

Safety validator

Execution coordinator

4. Connect the robot using AWS IoT Core

5. Store task state in DynamoDB

6. Build a simple capability validator

7. Handle failures before scaling

8. Secure and monitor the platform

9. Build it in stages

Final thoughts

References

Build an Agentic Application Modernization Platform with Strands Agents and AWS Transform Custom

1. The problem: Modernization doesn't scale easily

2. What are we building?

3. Architecture

What does each service do?

4. Why use multiple agents?

Agent 1: Repository Analysis Agent

Agent 2: Transformation Discovery Agent

Agent 3: Custom Transformation Creation Agent

Agent 4: Execution Agent

The orchestrator

5. Design the web application

Screen 1: Dashboard

Screen 2: Analyze a repository

Screen 3: Custom transformation builder

Screen 4: Batch processing

Screen 5: Job details

6. Example: Submit multiple repositories with CSV

What happens after upload?

7. Validate the transformed code

8. Infrastructure as code: CDK, SAM, or Terraform?

9. Security considerations

10. Try the public AWS sample

11. How do we measure success?

Conclusion

References

Building REST APIs on AWS with API Gateway, Lambda, and DynamoDB

1. What Is a REST API?

2. The AWS Architecture

3. Create a Lambda Function

4. Configure Amazon API Gateway

Deploy the API

Test the endpoint

5. Connect the API to DynamoDB

6. REST API or HTTP API?

7. Secure Your API

Authentication and authorization

Least-privilege permissions

Input validation

Throttling and abuse protection

Protect sensitive information

8. Monitor and Troubleshoot

9. Manage Costs and Scaling

10. Production Readiness Checklist

Final Thoughts

Further Reading

AWS #Serverless #Python #APIs

PHP2Shell: How AI Is Transforming Vulnerability Discovery and AWS Cloud Security

1. What Is PHP2Shell?

Why should developers care?

2. How AI Can Help Find Vulnerabilities

3. AWS Architecture: Defend in Multiple Layers

4. Immediate Remediation Checklist

Step 1: Inventory PHP versions

Step 2: Upgrade affected environments

Step 3: Apply temporary mitigations

Step 4: Investigate potential compromise

Step 5: Verify remediation

5. Build an AI-Assisted Vulnerability Remediation Workflow

Possible AWS service responsibilities

What should AI handle?

What should deterministic code handle?