DEV Community: Kishore Karumanchi

AWS Transform migration assessment: build a data driven AWS migration business case (step by step)

Kishore Karumanchi — Thu, 19 Mar 2026 05:27:16 +0000

Cloud migration is no longer just a technical initiative, it is a business decision. While many organizations recognize the long term benefits of moving to AWS, leadership teams often ask fundamental questions before committing: What exactly are we migrating? What will it cost? And what business value will we gain?

A structured migration assessment and a data driven business case help answer these questions with confidence.

In this blog, I’ll walk through how AWS Transform can be used to perform a migration assessment and create a data driven AWS migration business case, based on real inventory data and transparent cost modeling.

Why start with a migration assessment
Migration programs frequently slow down when early planning is based on assumptions rather than data. Common challenges include limited visibility into the existing infrastructure footprint, over provisioned servers, unclear licensing implications, and business cases that fail to stand up to financial scrutiny.
A migration assessment establishes a factual baseline. AWS Transform simplifies this process by analyzing workload inventory at scale and translating it into actionable insights that can be used for both technical planning and financial decision making.

Discover and analyze your current workloads
Every migration business case begins with a clear understanding of the current environment.

AWS Transform supports multiple inventory input formats, allowing teams to get started quickly without deploying new discovery tooling. Supported inputs include RVTools exports from VMware environments, Migration Portfolio Assessment (MPA) exports, vCenter inventory files, and the AWS Transform assessment data template.

Once the inventory is uploaded, AWS Transform analyzes server configurations, operating systems, and workload characteristics to produce a consolidated view of the environment.

Build a data driven AWS migration business case
With a clear understanding of the existing environment, AWS Transform generates a comprehensive migration business case grounded in real data.

The business case provides a Total Cost of Ownership (TCO) view that compares the current on premises cost baseline with projected AWS run costs. It includes multiple pricing scenarios, such as on demand and commitment based models, and highlights opportunities for licensing optimization.

Because the business case is derived directly from inventory data rather than assumptions, it resonates strongly with finance teams, procurement stakeholders, and executive leadership. It also creates a shared, objective reference point for migration discussions across technical and business teams.

Step by step walkthrough: building the business case using AWS Transform
The following steps outline a typical workflow for creating a migration business case using AWS Transform.

Step 1: Create a migration assessment job
Start by creating a new migration assessment job in AWS Transform and provide a meaningful name that reflects the scope or business unit being assessed.
1.1 Open AWS Console and search for “AWS Transform” service

1.2 Choose Settings and open the “Web application URL” to create workspace

1.3 Click on “Create Workspace” and provide a meaningful name

1.4 You will get the below screen once the workspace created
Now, you need to create a Job, Select Job type as Migration from the list highlighted in red color below

1.5 Choose Assessment as type of transformation you want to work on

1.6 You should be able to see the Job plan and select the storage information to upload the inventory

Step 2: Upload inventory data
Upload supported inventory files, such as RVTools, Migration Evaluator exports, or the AWS Transform assessment data template.
AWS Transform validates and processes the uploaded data.

In this blog example, I am using the “AWS Transform assessment data template”
Download the template and update your inventory information in the sheets “Servers”, “FileNAS Storage”, “Block Storage”, “Object Storage”

Review and fill the applicable sheets within this template based on your assessment requirements. Check the sheet “Glossary” for required (green), desired (yellow) and optional (white) fields information to fill the file.

2.1 Upload the on-premises server data

Step 3: Select the target AWS Region
Once uploaded, Choose the AWS Region where workloads are expected to run after migration. This selection ensures that pricing and service availability are accurately reflected in the business case.
click on “Generate business case” button.

Step 4: Generate the migration business case
Allow 10-20 minutes for AWS Transform to generate the migration business case, including cost projections, licensing scenarios, and savings estimates.

Step 5: Review insights and define next steps
Download business case and use the generated insights to identify migration priorities, validate financial assumptions, and plan follow on activities such as dependency analysis and migration wave planning.

Open “Business_case document to view the generated insights.

You should be able to see all the insights

Benefits of using AWS Transform
Using AWS Transform for migration assessments and business case development provides several key benefits.

Faster modernization
Organizations can modernize applications up to five times faster by using AI powered automation for complex transformation tasks. This reduces manual effort and significantly shortens planning and execution timelines.

Cost savings
Migration and modernization agents help reduce the cost of complex transformation projects by automating high effort analysis and planning activities, allowing teams to focus on execution and value delivery.

Confidence through consistency
A consistent, data driven approach across discovery, cost modeling, and planning builds confidence among stakeholders and reduces the risk of rework later in the migration journey.

Pricing considerations:
AWS Transform currently offers migration and modernization capabilities for enterprise workloads such as Windows, VMware, and mainframe at no additional cost. Custom transformations for code, APIs, frameworks, and other advanced scenarios are available as paid features.
You only pay for the AWS resources you create to run your applications, such as Amazon EC2 instances and storage. There are no minimum fees and no upfront commitments you pay only for what you use.

For the latest pricing details, please check:
https://aws.amazon.com/transform/pricing/

Thank you!

AgentCore Explained: AWS’s Serverless Runtime for Production Grade AI Agents

Kishore Karumanchi — Sat, 20 Dec 2025 02:54:59 +0000

What Is AgentCore?

AgentCore is the execution layer for running AI agents on AWS.
Building AI agents that operate reliably in enterprise environments requires far more than a language model and a prompt. Teams need security boundaries, execution control, observability, structured memory, and integration with operational systems all without managing underlying infrastructure. AgentCore addresses these needs by serving as the execution layer for running production ready AI agents on AWS through a fully serverless runtime. This means developers no longer need to manage Docker images, container registries, ECS clusters, or Kubernetes environments. AgentCore removes this operational burden, allowing teams to deploy, test, and scale agents quickly and consistently.

One of the strengths of AgentCore is its framework agnostic design. Developers can bring agents built with Amazon Bedrock Agents, AWS Strands, LangChain, LangGraph, OpenAI’s Agents SDK, CrewAI, or any other agent framework. While Strands integrates natively, AgentCore does not limit teams to a specific ecosystem. AWS also provides a starter toolkit that simplifies packaging, deployment, and connectivity across AWS services. This toolkit includes reusable components and built in tools that can be inserted directly into agent workflows, accelerating the journey from prototype to production.

Image Source: AWS Service Documentation

AgentCore Capabilities:

At the foundation of AgentCore are several core capabilities that together establish a robust, enterprise ready agent architecture. Agent Identity defines who the agent is, how it authenticates, and what systems it is allowed to interact with, ensuring that every action is governed by explicit permissions and access policies. The **Tools **layer allows agents to call modular functions ranging from API integrations and database lookups to operational workflows, so that agents can take meaningful actions instead of simply generating output. **Memory **acts as structured state management, enabling agents to retain context across multi step tasks, store intermediate computations, reason over conversation history, and integrate with long term knowledge sources. **Gateways **provide controlled pathways for receiving input or interacting with external applications, ensuring secure communication channels. The **Runtime **orchestrates the agent’s reasoning loops, manages tool selection, handles errors, and executes multi step workflows deterministically. Finally, **Observability **brings step level visibility through logs, traces, and metrics, helping developers understand how an agent behaves in production.

These elements work together to give AgentCore the stability and predictability necessary for enterprise deployment. Instead of building identity layers, orchestration engines, or observability frameworks from scratch, developers can rely on the platform’s built in primitives while concentrating on business logic, tool design, and workflow outcomes.

AgentCore **excels in **scenarios **where agents must perform repeatable, auditable, multi step operations. In **customer support automation, for example, agents can classify issues, retrieve order details, assess refund eligibility, and trigger workflows in CRM or ticketing platforms while the runtime ensures each step is validated and executed safely. In IT operations, agents can parse error logs, analyze CloudWatch metrics, run diagnostic commands, and create or resolve incidents with continuous context provided by memory and tools. Supply chain environments benefit from agents that assess product availability, recommend alternative suppliers, update inventory systems, and escalate disruptions, all within tightly controlled access boundaries defined by Agent Identity.

Knowledge assistants within enterprises can use memory to retrieve documents, summarize internal policies, and support employee queries, while gateways integrate directly with internal apps and portals. Agents designed to orchestrate multi system workflows reading from one system, transforming data, updating another, and validating outcomes with a third gain reliability and traceability through the runtime and observability layers.

Organizations should choose AgentCore when their workloads require deterministic multi step workflows, structured memory, fine grained control over tool execution, and real time decision loops that interact with APIs or databases. AgentCore is particularly well suited for environments that demand rigorous governance, repeatability, and transparency. It also supports a broad range of frameworks, providing flexibility for teams already invested in agent ecosystems such as LangChain, LangGraph, Strands, or OpenAI Agents.

The advantages of AgentCore extend across the development lifecycle. Its framework agnostic nature allows teams to adopt their preferred tooling without rewriting agents for a new runtime. The serverless architecture removes infrastructure management overhead, enabling AWS to handle scaling, concurrency, and execution performance. Enterprises benefit from a strong security model powered by IAM integration, fine grained permissions, and auditable actions. The **deterministic runtime **ensures predictable agent behavior across workflows, and **observability **features give developers deep operational insight. **Deployment **becomes straightforward through the starter toolkit, which handles packaging and orchestration without additional manual steps.

Like any emerging technology, AgentCore comes with certain limitations. Because it is still evolving, some APIs and patterns may mature over time. It is not optimized for simple single turn chat use cases, where a lightweight model invocation is sufficient. It is designed for cloud hosted serverless execution rather than offline or local environments. Effective tool design is essential to maintain predictability, and complex multi step agent behaviors may require thorough testing to fully understand their execution paths.

Conclusion:
AgentCore introduces structure, governance, and operational reliability to a domain that has traditionally relied on experimental patterns. By organizing agent development around clear architectural pillars Identity, Tools, Memory, Gateways, Runtime, and Observability, AWS provides a predictable foundation for building and operating enterprise grade AI systems. Instead of managing infrastructure or building orchestration layers from scratch, teams can focus on secure workflows, well designed tools, and meaningful business outcomes. As agentic systems continue to move from prototype to production, platforms like AgentCore will play a central role in helping organizations scale their AI initiatives with confidence.

Kiro - From Prompt to Production: A Developer’s Blog to AWS’s Agentic IDE

Kishore Karumanchi — Sat, 20 Dec 2025 02:40:33 +0000

Introduction
Developers today are familiar with the excitement of generating code instantly through AI powered tools, ask for a “user registration endpoint,” and code appears within seconds. While this is ideal for rapid prototyping, the reality of long term development often tells a different story. Three months later, teams find themselves navigating through dense boilerplate, missing tests, incomplete documentation, and architectural drift that becomes increasingly difficult to manage.

Kiro changes that experience entirely. Introduced by AWS in public preview, Kiro moves far beyond autocomplete style coding. It serves as a full stack, lifecycle aware development environment designed to produce real, maintainable, production grade applications. It brings together specification, architecture, code, tests, infrastructure scaffolding, and documentation, ensuring they evolve in parallel rather than becoming fragmented over time.

This blog explores why Kiro matters, the problems it solves, how it integrates with AWS services, and what the developer workflow looks like when building real applications using Kiro.

The Problem Kiro Solves
Traditional AI coding tools excel at generating quick snippets or prototypes, but they often create long term challenges for engineering teams. Systems built this way frequently lack clear reasoning behind architectural choices, fail to include consistent testing, and accumulate technical debt as new features are added without a guiding specification. Over time, teams experience gaps in documentation, inconsistent coding patterns, fragmented architectures, and onboarding challenges for new developers who must decipher how and why certain decisions were made.

Kiro addresses these challenges through a spec driven, agent supported development model that brings structure into every phase of the workflow. Instead of generating isolated code fragments, Kiro anchors development in requirements, decisions, and documentation that remain visible and synchronized with the codebase.

Kiro at a Glance: Features and the Developer Workflow
Kiro begins by generating structured artifacts before any code is written. When a developer requests a new capability such as adding an inventory reservation API, Kiro produces a set of specification files that capture the intent behind the feature. These include detailed requirements with user stories and acceptance criteria, architectural guidance with diagrams and data models, and a tasks file outlining the work to be done across tests, documentation, and infrastructure.

This spec driven workflow ensures that every feature is grounded in a clear, traceable foundation. Kiro then augments this process using automated agent hooks that respond to development activities. These hooks can generate unit tests when files are updated, refresh documentation when endpoints are introduced, or enforce team defined standards encoded through Kiro’s steering configuration. Over time, Kiro integrates seamlessly into a team’s development rhythm, elevating consistency and predictability across the codebase.

How Kiro Fits Into AWS Centric Architectures
When developers adopt Kiro for AWS based projects, the platform becomes a powerful companion throughout the build and deploy pipeline. Kiro begins by converting a developer’s prompt into specifications, producing artifacts such as requirements, design decisions, and implementation tasks. It then extends this workflow by generating infrastructure scaffolding through AWS CDK or Terraform, provisioning typical AWS components such as Amazon API Gateway, AWS Lambda, and Amazon DynamoDB.

As development continues, Kiro uses its hooks and runtime logic to synchronize code, standards, tests, and documentation, reducing gaps between design intent and implementation. It integrates naturally with CI/CD pipelines, enabling automated deployment and connecting applications to logging, monitoring, and metrics services across AWS. Whenever specifications or code change, Kiro updates corresponding design artifacts, preventing architectural drift and reinforcing alignment between planned and implemented systems.

Example: Building a Simple Application with Kiro
To illustrate how Kiro operates, consider a prompt requesting the creation of an event ticketing microservice. The developer asks Kiro to generate requirements, design documents, tasks, coding standards, hooks, and an MCP server capable of interacting with DynamoDB and CloudWatch. The service includes endpoints for creating and retrieving tickets and relies on AWS Lambda, Amazon API Gateway, and DynamoDB as its core components.

Kiro responds by generating the entire structure of the project requirements files, architectural design documentation, tasks for implementation, and all supporting artifacts. It provides a fully traceable workflow that mirrors AWS best practices for microservice development. The interface highlights generated components, making it easy for developers to review, refine, and progress through the build process with clarity.

Based on the prompt Kiro works on and create all the needed components (in this example, requirements, design, tasks and specs etc.)

Current Limitations and Developer Considerations
Kiro is currently in public preview, and some capabilities are still evolving. Model usage - such as selecting models like Claude Sonnet or Claude Haiku may incur cost or quota considerations. Large codebases may require a more capable local environment to maintain smooth performance during extended interactions.

Developers working with Kiro benefit from using context rich files such as diagrams, previous code, or documentation to improve accuracy and quality. The kiro status command helps track agent activity, and teams can define custom hooks to enforce security requirements, policy checks, or internal standards. Starting with a small project is often a helpful way to learn Kiro’s workflow before applying it to mission critical systems.

Conclusion
Kiro represents a shift from ad hoc AI generated code toward a structured, agentic development model that supports real enterprise applications. By grounding development in specifications, automating lifecycle tasks, and integrating deeply with AWS services, Kiro transforms how teams approach architecture, development, documentation, and deployment. It enhances developer productivity, reduces technical debt, and gives engineering teams the confidence to build, scale, and maintain production systems with clarity and consistency.
As AI supported tooling continues to evolve, platforms like Kiro will play a pivotal role in shaping the next generation of software development bringing together intelligent assistance with enterprise grade rigor, security, and maintainability.

P2A Security & Governance: Building Enterprise Ready Guardrails for AWS Process to Agent Systems

Kishore Karumanchi — Sat, 22 Nov 2025 16:18:34 +0000

Agentic systems are becoming a core component of how enterprises automate decision driven processes on AWS. With the Process to Agents (P2A) pattern, organizations can transform everyday operations into intelligent agents capable of understanding context, making decisions, and performing tasks across multiple applications and data sources. This shift introduces tremendous opportunity, yet it also introduces significant responsibility. Enterprise adoption depends not only on how well the agents perform but also on the strength of their security, governance, and operational controls. Without these foundations, the risks may outweigh the benefits.

This blog outlines an architectural blueprint for building a secure, well governed P2A environment on AWS. It is designed to help architects, platform teams, and security leaders implement agentic workloads with confidence and operational discipline.

Why Security and Governance Are Foundational in P2A
Agentic workflows have the ability to interpret data, trigger actions, call internal and external tools, execute decisions without human intervention, and orchestrate multi system operations. This level of autonomy while powerful means that even small misconfigurations can cause outsized impact. Without proper controls, agents may access unauthorized systems, leak sensitive information through prompts or logs, incur unexpected token costs, or trigger the wrong operational workflows. Compliance teams may block rollout if controls are unclear, and hallucinated outputs can lead to operational, reputational, or financial damage.

To mitigate these risks, enterprises must anchor their P2A architecture on zero trust identity principles, tightly scoped permissions, controlled tool execution, strong encryption, clear data governance, comprehensive observability, safety guardrails, and defined human in the loop patterns. Everything else in a P2A system builds on these fundamentals.

Identity and Access Control
Identity forms the base of a secure agentic architecture. Treating every agent as its own service identity provides the traceability and containment necessary for controlled operations. IAM Identity Center is an appropriate mechanism for managing these identities without mixing agent credentials with human accounts. Each agent or agent family should be assigned a dedicated identity with a narrowly defined permission set that aligns with its responsibilities.

Create a dedicated identity or a small group for each agent or agent family, then attach a permission set with only the exact permissions it requires.

Short session durations help reduce credential exposure, and workflows requiring human participation should enforce MFA for the elevated steps.

Permissions must remain tight and purpose built. Most agents interact with only a small set of AWS services, perhaps a few S3 prefixes, selected Lambda functions, specific DynamoDB partitions, Step Functions workflows, or Bedrock models. Defining fine grained IAM policies and combining them with permission boundaries or attribute based access controls prevents scope drift as systems evolve.

Larger organizations operating multiple AWS accounts should apply cross account controls using AWS Resource Access Manager and targeted IAM roles. Service Control Policies act as a safeguard to enforce organizational restrictions and ensure neither human nor agent identities exceed defined access rules.

Specify least-privilege permission using SCP's

Create Role in other AWS account

Create a new service control policy

Data Protection and Governance
Agentic systems frequently exchange large volumes of sensitive data. Safeguarding these flows is as important as securing the agent itself. A best practice is to create and use customer managed AWS KMS keys across all components, whether storing prompts, logs, decisions, workflow outputs, or intermediate data in services such as S3, Step Functions, or CloudWatch. Using a dedicated CMK provides clearer visibility into key usage and allows teams to control rotation, auditing, and access boundaries.

Encrypt Data at Rest and In Transit

Choose one or more IAM Roles or Group

Review Policy and create. now have a customer-managed KMS CMK that your agentic system can use.

Before passing data to a model, inputs should be sanitized and minimized. Lambda functions or Step Functions preprocessing steps can remove unnecessary fields and redact sensitive attributes such as personal data. Guardrails configured in Amazon Bedrock can then enforce PII filtering and content safety rules to ensure models operate only on governed, compliant input.

Replace the default code with something like this to mask the PII data

Configure PII Filtering configuration, review and create Guardrail.

Logs and outputs must also be protected. Prompts, inference results, and decision traces should be stored in encrypted S3 buckets with strict access controls and lifecycle policies to ensure cost efficient, secure retention.

Tool Access Control
Tools represent the mechanisms through which an agent interacts with the real world, updating systems, modifying records, initiating workflows, or calling external APIs. Because these actions have direct operational consequences, tool execution must be tightly governed.

Instead of allowing agents to invoke tools directly, requests should pass through a validation layer built using Amazon API Gateway and Lambda. This layer verifies whether the agent is authorized to call the tool, ensures that request payloads meet safety and compliance criteria, applies rate limits or thresholds, and checks business rules before forwarding the request. Only after successful validation should downstream systems execute the action.

Each tool should operate under its own IAM role, separate from the agent identity. This ensures that tools carry only the permissions required for their function, while agents remain isolated from direct access to AWS services. Observability systems such as EventBridge and CloudWatch can detect unusual tool use patterns, escalating alerts or initiating throttling when behavior deviates from expected norms.

Guardrails and Safety Controls
Safety guardrails ensure that agent behavior aligns with enterprise policies from content restrictions to internal terminology protections. Amazon Bedrock Guardrails provide mechanisms to block sensitive topics, detect or redact PII, enforce safety categories, and regulate both input and output content. Organizations can extend these protections by uploading internal deny lists covering confidential terms or business sensitive language.

When a request violates a guardrail, systems should return clear, predictable responses to maintain user experience without compromising safety. These responses should become part of the user facing layer of your agentic platform.

Monitoring, Logging, and Auditing
Operational clarity is essential for trust and maintainability. Every major event in a P2A environment including prompts, decisions, tool calls, inferred results, and system responses should be captured as structured logs. Amazon CloudWatch enables teams to search, filter, and generate alerts from this telemetry.

For agent workflows built using orchestrated logic, AWS Step Functions provides a detailed execution map that visualizes each step. This view is particularly valuable for debugging, compliance reviews, and security validations. For long term auditability, logs should be archived in secure, encrypted S3 buckets with lifecycle policies to balance compliance needs and storage efficiency.

Conclusion:
Agentic systems can transform enterprise operations, but only when they are designed with security, governance, and guardrails as first class priorities. By combining IAM Identity Center, tightly scoped permissions, customer managed KMS keys, Bedrock Guardrails, tool level access validation, CloudWatch monitoring, and Step Functions workflow visibility, organizations can build agentic systems that are powerful, predictable, and fully audit ready.

With the right guardrails in place, enterprises can embrace P2A architectures confidently scaling automated decision driven workflows across teams and business functions while maintaining complete oversight and operational control.

Transforming Enterprise Workflows with AWS Process to Agents (P2A): A Deep Dive Through a Supply Chain Logistics Use Case

Kishore Karumanchi — Sun, 16 Nov 2025 11:51:59 +0000

Generative AI is evolving far beyond conversational interfaces. Enterprises are now exploring how AI can act as an operational engine, an intelligent participant within core business systems. AWS is enabling this shift through Process to Agents (P2A), an architectural pattern that helps organizations transition from rigid, rules based workflows to adaptive, autonomous, agent driven orchestration.

Organizations long dependent on manual decision making, static process rules, and system integrations are beginning to adopt agentic systems capable of reasoning, planning, and executing tasks across distributed environments. This blog explains what P2A represents, the motivations behind the initiative, how it fits into enterprise architecture, and how it transforms traditional workflows, illustrated through a real world supply chain logistics example.

Understanding the AWS Process to Agents (P2A) Model
Many enterprises have experimented with generative AI for chat or content tasks, but few have embedded AI into the operational fabric of their processes. P2A helps close this gap by enabling AI driven orchestration within complex workflows.

At its core, P2A reframes enterprise automation: deterministic workflows are replaced by multi agent systems capable of evaluating context, sequencing actions, interacting with enterprise systems, self correcting, and progressively improving outcomes. Instead of strictly following BPM flows, agents understand business goals, interpret constraints, collaborate with other agents, and continuously optimize their decisions.

The Motivation Behind P2A
Enterprises seeking resilience, efficiency, and adaptability are increasingly constrained by static workflow logic. Traditional automation often struggles in environments where conditions change frequently - such as fluctuating inventory, shifting supplier timelines, or dynamic market events.

P2A introduces adaptability. Agents are capable of making context aware choices, reducing the burden of human intervention, and enabling systems to evolve beyond fixed logic. The goal is not to replace existing ERPs, WMS, or TMS platforms, but to augment them with an intelligent reasoning layer that operates through APIs, events, and integration services.

This approach supports business processes that are goal oriented rather than step oriented. For instance, ensuring a customer order is fulfilled at the optimal cost and within the promised SLA becomes the mission, allowing the agent to determine the best strategy based on real time conditions.

Operational resilience also improves significantly as agents continuously monitor systems, detect issues early, and take corrective actions - such as re routing a shipment or escalating an anomaly - without waiting for human input.

How the P2A Architecture Operates
P2A is not a dedicated AWS service. It is an architectural pattern composed of generative AI models, orchestration tools, integration services, and enterprise ready automation capabilities.

Organizations begin by identifying processes with high decision density, frequent cross system interactions, and substantial operational overhead. Examples include order allocation, logistics routing, financial approvals, procurement workflows, and claims processing.

Once a suitable candidate process is identified, a reasoning layer is developed using services such as Amazon Bedrock (agents, models, RAG), Amazon Q Business and Developer, enterprise knowledge bases, and guardrails. This reasoning layer serves as the intelligence core for planning, evaluating, and coordinating tasks.

Enterprise systems are then exposed as “agent tools” through secure APIs. Inventory checks, shipment status lookups, updates to order systems, and procurement triggers are all made accessible to agents via AWS Lambda, API Gateway, and PrivateLink.

This toolset enables agents to interact seamlessly with systems of record such as ERP, WMS, TMS, OMS, and other operational platforms.

The workflow is orchestrated using AWS Step Functions, Amazon EventBridge, and Bedrock Agents, which allow multiple agents to collaborate. Planning, execution, validation, and exception handling agents work together, each focusing on a specific dimension of the process while sharing context.

Where oversight is required, humans remain part of the loop. Approvals, validations, and escalations can occur through Amazon SNS, email based workflows, dashboards, or Amazon Q powered evaluation. This ensures responsible, controlled automation.

The architecture also establishes a continuous learning mechanism, using operational feedback, historical patterns, tool success rates, and process outcomes. Knowledge bases are updated regularly through S3 data lakes, forecasting models, and event streams, allowing agentic workflows to mature over time.

Use case - Supply Chain Logistics: A Before and After View of P2A
A supply chain fulfilment process provides a strong illustration of how P2A transforms enterprise workflows.
Before P2A Traditional Workflow - Reference Architecture

Note: Reference diagram link -
https://docs.aws.amazon.com/architecture-diagrams/latest/intelligent-supply-chain-retail/intelligent-supply-chain-retail.html

In a typical supply chain scenario, a new order triggers a sequence of checks across multiple disconnected systems. Inventory levels must be reviewed manually, shortages must be investigated by analysts, logistics teams validate carrier availability and route options, and planners evaluate shipment constraints. Exceptions such as delays or disruptions escalate to dedicated teams. The process updates various systems - ERP, WMS, TMS - and then communicates final status to the customer.
This approach involves lengthy processing times, multiple decision points, limited visibility, and significant operational overhead, making scalability difficult.

After P2A: Agent Driven Workflow - Reference Architecture

With P2A, the same fulfilment process becomes dynamic and autonomous. When an order is created, Event Bridge triggers a planning agent that interprets the order requirements, evaluates constraints, and orchestrates supporting agents.

An inventory reasoning agent checks availability across multiple warehouses and supplier networks using back-end APIs. When stock limitations appear, the agent evaluates alternatives such as nearby warehouses, in transit shipments, or supplier lead times.

A logistics planning agent assesses carrier options, delivery promises, route feasibility, cost structures, and real time conditions such as traffic and weather. It selects the optimal delivery method aligned with the organization’s business goals - balancing cost, SLA adherence, sustainability, and lead times.

If disruptions occur, an exception management agent dynamically adjusts the plan, re routes shipments, switches carriers, or escalates the issue for human validation.

Once final decisions are made, an execution agent updates ERP, WMS, and TMS systems with fulfilment details, shipping instructions, and customer communications.

As the process concludes, performance insights - such as carrier reliability, route efficiency, and SLA accuracy - feed into knowledge bases and forecasting models, strengthening the system’s ability to optimize future decisions.

Expected Outcomes from AWS P2A Adoption
Enterprises implementing P2A experience substantial operational gains. Manual decision work decreases significantly (60-80%) as agents handle repetitive evaluations and cross system queries. SLA compliance improves due to real time optimization and dynamic decision making. Carrier and routing costs decrease because the system consistently identifies the most efficient pathways. Fulfilment cycles accelerate from minutes or hours to near real time execution. Additionally, resilience improves as agents respond instantly to disruptions, reducing delays and customer impacts.

Over time, continuous learning enables agents to refine their reasoning, improve prediction accuracy, and enhance process reliability. Customers benefit from more accurate delivery commitments and improved service consistency.

Conclusion:
AWS Process to Agents (P2A) represents an important shift in enterprise automation -moving beyond predefined workflows toward intelligent, autonomous, and adaptive systems. For supply chain logistics, P2A offers a powerful advantage: faster and more reliable fulfilment, reduced operational cost, enhanced resilience, and improved customer experience.

While this blog focused on a supply chain scenario, the opportunities extend far beyond a single domain. Finance, operations, and other enterprise functions face similar challenges that benefit from adaptive, goal oriented automation. As organizations begin exploring agentic architectures across these areas, AWS P2A offers a clear and prescriptive path forward - integrating the strengths of Amazon Bedrock, Amazon Q, AWS Step Functions, enterprise APIs, and workflow automation into a cohesive, production ready operating model.

Architecting Large-Scale AWS Migrations Using AWS Application Migration Service (MGN) .

Kishore Karumanchi — Sat, 15 Nov 2025 06:48:51 +0000

Architecting Large-Scale AWS Migrations Using AWS Application Migration Service (MGN) & Cloud Studio 2.0

Kishore Karumanchi ・ Nov 15

#cloud #aws #architecture #mgn

Architecting Large Scale AWS Migrations Using AWS Application Migration Service (MGN) and Cloud Studio 2.0

Kishore Karumanchi — Sat, 15 Nov 2025 06:42:54 +0000

Introduction
Cloud migration often looks simple on paper, “lift and shift the servers and run them on AWS.”
But architects know the reality is dramatically different.
Enterprise migrations involve multi-tier apps, interdependent services, legacy systems, compliance requirements, weekend cutovers, and the never-ending question “Will the application work exactly the same after cutover?”

AWS Application Migration Service (MGN) significantly simplifies rehosting, yet the architecture behind a scalable migration is where most projects struggle.

In this blog, I will walk through how to architect large migrations using AWS MGN, combined with Cloud Studio 2.0, an accelerator that helps automate discovery, dependency mapping, and migration wave planning (Cloud Studio is a Wipro’s proprietary tool/ Platform, Instead of Cloud Studio tool you can use other third-party tools as well based on your requirement and use case, example Matilda etc.). These approaches come from real-world programs supporting enterprise customers transitioning hundreds of servers to AWS.

Rehosting Strategy: Why It Still Matters
While modernization themes like containers, serverless platforms, or AI driven refactoring attract attention, the majority of enterprises still adopt rehosting as their first step toward cloud transformation. Rehost offers the fastest and least disruptive path to AWS because it minimizes code changes, reduces migration risk, and makes rollback straightforward. AWS MGN further strengthens this approach by enabling continuous block level replication, near zero downtime cutovers, and automated testing sequences. These capabilities make MGN the operational backbone for large migration programs with legacy workloads and strict performance requirements.

Understanding the AWS MGN Architecture
An effective migration architecture with AWS MGN brings together several coordinated components. Source servers running on VMware, Hyper V, physical hardware, or other environments install the MGN replication agent, which transfers data continuously to AWS. A lightweight staging area consisting of EC2 instances and Amazon EBS volumes receives and synchronizes this data, while a replication server manages ongoing transfers. When testing or cutover is initiated, MGN automatically provisions new instances according to predefined launch templates. This architecture enables real time replication that remains synchronized throughout the migration, supports repeated functional and performance validation, and allows teams to roll back without data loss. Architectural considerations typically involve choosing appropriate subnets for staging, determining instance types for testing and cutover, enforcing IAM boundaries for teams, and supporting cross account replication for regulated workloads. Together, these elements create a reliable and secure migration pipeline.

Discovery and Planning with Cloud Studio 2.0
When migrating large environments - often 100 servers or more, planning becomes as important as execution. Enterprises must understand system relationships, communication pathways, upstream and downstream dependencies, application grouping, and downtime constraints. Cloud Studio 2.0 addresses these gaps by discovering application topologies, identifying interdependencies, and automatically grouping systems into migration waves based on their connectivity and operational behavior. It provides effort and timeline estimations, generates standardized runbooks, and creates visibility into the sequencing required for each application. When combined with AWS MGN’s automated replication and cutover workflows, this planning foundation significantly reduces migration effort and improves predictability.

Reference Migration Architecture

Reference – https://aws.amazon.com/blogs/architecture/multi-region-migration-using-aws-application-migration-service/

Above blog illustrates a reference architecture for MGN that integrates discovery, replication, testing, and cutover processes into a cohesive design. The architecture ensures that data is continuously synchronized, test instances can be launched repeatedly, and production cutover occurs only after the application has been validated. This foundation allows enterprises to maintain confidence throughout migration waves, even when dealing with complex multi tier workloads.

Best Practices for Large Scale Migrations
Enterprise programs benefit from beginning replication well in advance of scheduled cutover windows. Early warm up enables synchronization to stabilize, surfaces potential bandwidth limitations or I/O constraints, and reduces the final cutover delta. Many organizations create dedicated accounts for staging, testing, and production to improve governance and isolation. Standardizing launch templates helps remove configuration drift across teams and workloads, ensuring test and cutover environments remain consistent. Multiple rounds of functional and performance testing improve reliability and reduce surprises during actual migration. After workloads land on AWS, MGN’s post cutover automation can remove migration agents, perform initial cleanup operations, join systems to domains, and establish security baselines, making Day 1 operations more efficient.

Real World Implementation Example
A global retailer migrating 115 servers across 23 interconnected applications faced several challenges including undocumented dependencies, restricted weekend downtime windows, and significant ongoing data transfer requirements. By using Cloud Studio 2.0 for automated discovery and migration wave planning, AWS MGN for continuous replication and cutover, and AWS Systems Manager for post migration activities, the retailer completed the migration with no rollback events. Planning effort reduced by more than half, and cutover completed smoothly within the approved downtime window. This outcome demonstrates the importance of strong pre migration discovery combined with automation throughout the migration cycle.

Conclusion
Large scale enterprise migrations require architectural clarity, structured planning, and automation at every stage. AWS Application Migration Service (MGN), when combined with Cloud Studio 2.0 or equivalent planning tools, provides a scalable blueprint for rehosting workloads efficiently and predictably. Whether migrating ten servers or one thousand, the principles outlined in this blog help organizations build a repeatable, low risk framework for transitioning applications to AWS and unlocking future modernization opportunities.

Please refer the blog to follow the MGN service Migration steps - https://aws.amazon.com/blogs/architecture/multi-region-migration-using-aws-application-migration-service/

Migrating VMware Workloads from VMware to AWS – A Smarter, Future Ready Approach

Kishore Karumanchi — Sun, 19 Oct 2025 12:15:24 +0000

The enterprise virtualization ecosystem is undergoing rapid transformation, especially following Broadcom’s acquisition of VMware. This shift has prompted many organizations to reassess their long term compute strategies, licensing models, and cloud adoption roadmaps. As the industry moves toward subscription only licensing and tighter contractual boundaries, customers are increasingly evaluating alternatives that provide flexibility, transparency, and scale.

Against this backdrop, Amazon Web Services (AWS) has emerged as a natural destination for enterprises seeking a seamless transition for VMware workloads while enabling a pathway toward modernization.

Challenges with Broadcom’s VMware Licensing Model
Broadcom’s updated licensing strategy has introduced new operational and financial constraints for customers. The shift from perpetual licenses to recurring subscription models has created budget predictability issues and increased the overall cost of ownership. Organizations are also navigating product discontinuations, SKU reductions, and uncertainty around partner ecosystem support. These factors combined with stricter contractual lock ins have made cloud migration more compelling than ever.

Many enterprises now prefer platforms that offer flexibility, predictable scaling, reduced long term risk, and a broader innovation ecosystem. AWS aligns closely with these priorities.

Enterprise Use Cases for Migrating VMware Workloads to AWS
Organizations are embracing AWS for VMware migrations across a wide range of scenarios.

Some prefer AWS as part of a data center exit or consolidation strategy, moving legacy environments to a managed, scalable cloud foundation. Others leverage VMware Cloud on AWS to implement cost effective disaster recovery and business continuity - eliminating secondary hardware footprints.

AWS is also widely used to support development and test environments, enabling rapid provisioning of VMware compatible stacks on demand. Additionally, enterprises adopt AWS to pursue application modernization, gradually transforming VMware based workloads into containerized or serverless architectures without disrupting existing operations.

Regions across the globe support regulatory, compliance, and data residency needs, enabling organizations to remain compliant while expanding operational flexibility.

Why Enterprises Choose AWS for VMware Migrations
AWS provides a clear and practical migration path for VMware users seeking scalability and modernization without the friction of full re architecture. Customers gain the ability to run VMware based workloads natively on AWS while incrementally adopting cloud native services.

The value proposition centers on elastic scalability, a granular pay as you go cost model, access to 200+ managed services, and a geographically diverse infrastructure spanning 33 Regions and more than 100 Availability Zones. Organizations also benefit from AWS’s strong security posture, deep compliance programs, and operational transparency-ensuring a stable, secure foundation for mission critical workloads.

Target Architecture and Migration Path on AWS

Enterprises typically begin with a comprehensive discovery and assessment phase to evaluate workload compatibility, modernization readiness, and the most appropriate migration pathways. Workloads that can be rehosted may move directly to Amazon EC2, VMware Cloud on AWS, or to the newly introduced Amazon EVS (Elastic VMware Service) a fully managed VMware Cloud Foundation (VCF) environment that is deployed directly on EC2 bare metal instances integrated with your Amazon VPC, enabling a seamless, high performance landing zone for VMware workloads.
For workloads requiring replatforming or modernization, organizations take advantage of AWS container and serverless services such as Amazon EKS, Amazon ECS, AWS ROSA, and** AWS Lambda**, selected based on architectural requirements and long term transformation goals.

This structured approach minimizes disruption while expanding modernization opportunities and providing flexibility across multiple VMware to AWS migration paths.

Cost Optimization Levers for AWS Migration
Cost optimization is a critical component of VMware to AWS migration planning. Organizations often begin by right sizing instances, selecting appropriate pricing models, and using on demand capacity for non production environments. Production workloads typically achieve significant savings-up to 72%-by adopting 1 or 3 year Savings Plans.

License optimization also plays a major role. Organizations reduce spend by rationalizing Windows Server and SQL Server licenses, eliminating extended support costs for end of life versions, and reclaiming on premises licenses as workloads migrate.

AWS funding programs, including MAP (Migration Acceleration Program), help offset assessment, mobilization, and migration costs for eligible workloads, accelerating adoption and reducing initial investment.

Tools and Services for VMware Migration to AWS
AWS provides a comprehensive toolset to support migration planning, execution, and operations.
AWS Application Migration Service (MGN) enables automated rehosting of virtual machines from on premises VMware environments to Amazon EC2, simplifying cutovers and testing. AWS Migration Hub offers centralized visibility and tracking across multiple migrations, while AWS Backup ensures a unified approach to data protection across hybrid workloads.

Post migration operations are supported through AWS Systems Manager, enabling patching, configuration management, inventory tracking, and automated maintenance across AWS and VMware environments.

Example Scenario: Migrating VMware VMs to Amazon EC2
Detailed step-by-step instructions with descriptions of what you'll see in the console.

Migration Scenario Overview
Example Environment:
• Source: VMware vSphere environment with Windows Server 2019
• VM Specifications: 4 vCPUs, 8GB RAM, 80GB disk
• Application: Web server with IIS
• Migration Tool: AWS Application Migration Service (MGN)
Prerequisites Setup

Step 1: Access AWS Management Console
• Navigate to AWS Console
• Go to https://aws.amazon.com/console/
• Sign in with your AWS account credentials

Step 2: Set Up IAM Permissions
• Navigate to IAM Service
• In the AWS Console search bar, type "IAM"
• Click on "IAM" from the dropdown results
• You'll see the IAM dashboard
• Create MGN Service Role
• Click "Roles" in the left navigation panel
• Click "Create role" button
• Select "AWS service" as trusted entity type
• Search for and select "Application Migration Service"
• Click "Next: Permissions"
• The required policies will be automatically attached
• Click "Next: Tags" (optional)
• Click "Next: Review"
• Enter role name: "AWSApplicationMigrationServiceRole"
• Click "Create role"

Step 3: Initialize AWS Application Migration Service
• Navigate to MGN Service
• In the console search bar, type "Application Migration Service"
• Click on "AWS Application Migration Service"
• If this is your first time, you'll see an initialization screen
• Initialize the Service
• Click "Initialize AWS Application Migration Service"
• Select your preferred region (e.g., us-east-1)
• Click "Initialize"
• Wait for initialization to complete (usually takes 2-3 minutes)

Step 4: Configure Replication Settings
• Access Replication Settings (o In the MGN console, click "Settings" in the left navigation o Click "Replication settings templates" o Click "Create template" or edit the default template)
• Configure Template Settings (o Replication server instance type: Select "t3.small" (for testing) o EBS volume type: Select "gp3" for better performance o Replication server security groups: Select or create appropriate security group o Subnet: Choose a private subnet for replication servers o Bandwidth throttling: Set to 0 (unlimited) or specify limit o Data plane routing: Select "Private IP" for secure replication o Click "Create" to save the template)

Step 5: Install MGN Agent on Source VM
• Download Agent (o In MGN console, click "Source servers" in left navigation o Click "Add server" o You'll see agent download instructions o Copy the download command or download link)
• Install Agent on Windows VM (o Connect to your VMware Windows VM via RDP o Open PowerShell as Administrator o Download the agent: I o Invoke-WebRequest -Uri "https://aws-application-migration-service-us-east-1.s3.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe" -OutFile "C:\temp\AwsReplicationWindowsInstaller.exe" o Install the agent: o C:\temp\AwsReplicationWindowsInstaller.exe --region us-east-1 --aws-access-key-id YOUR_ACCESS_KEY --aws-secret-access-key YOUR_SECRET_KEY --no-prompt)
• Verify Agent Installation (o Check Windows Services for "AWS Replication Agent" o Verify network connectivity to AWS endpoints o Return to MGN console to see the server appear)

Step 6: Monitor Initial Replication
• View Source Server Status (o In MGN console, go to "Source servers" o Click on your server to view details o Monitor replication progress in the "Data replication" tab)
• Check Replication Health (o Look for "Healthy" status in the replication health column o Monitor data transfer progress o Check for any error messages or warnings)

Step 7: Configure Launch Settings
• Set Up Launch Template (o Click on your source server o Go to "Launch settings" tab o Click "Edit" next to "EC2 Launch Template")
• Configure Instance Settings (o Instance type: Select appropriate size (e.g., t3.medium) o Security groups: Create or select security groups o Subnet: Choose target subnet o IAM instance profile: Select appropriate role o Key pair: Select or create key pair for access o Click "Save")
• Configure Post-Launch Actions (o Go to "Post-launch settings" tab o Configure any required post-launch scripts o Set up SSM document execution if needed o Click "Save")

Step 8: Perform Test Cutover
• Initiate Test Cutover (o Select your source server o Click "Test and cutover" dropdown o Select "Launch test instances" o Review settings and click "Launch")
• Monitor Test Launch (o Go to "Launch history" tab o Monitor the test job progress o Wait for "Completed" status)
• Access Test Instance (o Once completed, go to EC2 console o Find your test instance (tagged with "Test" prefix) o Connect via RDP using the key pair)

Step 9: Validate Test Instance
• Verify System Functionality (o Connect to the test instance o Check that all services are running o Verify application functionality o Test network connectivity)
• Performance Testing (o Run performance benchmarks o Compare with source VM performance o Check disk I/O and network performance o Validate application response times)

Step 10: Production Cutover
• Prepare for Cutover (o Schedule maintenance window o Notify stakeholders o Ensure final data sync is complete o Stop applications on source VM)
• Execute Production Cutover (o Select your source server o Click "Test and cutover" dropdown o Select "Launch cutover instances" o Review final settings o Click "Launch")
• Monitor Cutover Progress (o Watch the cutover job in "Launch history" o Monitor for any errors or issues o Wait for "Completed" status)

Step 11: Post-Migration Configuration
• Update DNS Records (o Go to Route 53 console o Select your hosted zone o Edit A records to point to new EC2 instance IP o Set appropriate TTL values)
• Configure Security Groups (o Go to EC2 console o Click "Security Groups" in left navigation o Edit inbound/outbound rules as needed o Ensure proper access controls)
• Set Up CloudWatch Monitoring (o Go to CloudWatch console o Create custom dashboards for your instance o Set up alarms for CPU, memory, and disk usage o Configure SNS notifications)

Conclusion:
As enterprises adapt to the evolving VMware ecosystem, AWS provides a smart, scalable, and future ready trajectory for virtualized workloads. By combining familiar VMware tooling with AWS elasticity, modernization pathways, and operational control, organizations gain the freedom to design architectures aligned with long term business and technology goals.

Whether through VMware Cloud on AWS or AWS Application Migration Service, AWS enables seamless transitions, cost optimization, and a clear runway toward cloud native innovation.
In this changing landscape, AWS offers the resilience, flexibility, and modernization capabilities enterprises need to shape the next generation of virtualized infrastructure.

For more information about Amazon EVS service please visit this link - https://aws.amazon.com/evs/resources/

AWS Resource Tagging - A Practical Guide for Developers

Kishore Karumanchi — Sat, 18 Oct 2025 16:38:30 +0000

As AWS environments expand from a handful of resources to hundreds or even thousands, keeping track of what each resource does and who it belongs to quickly becomes challenging. Questions such as which EC2 instance belongs to the development environment, what the monthly spend is for specific production databases, or who owns an unidentified S3 bucket are common pain points for teams operating at scale. These challenges highlight why AWS resource tagging is one of the most overlooked yet powerful capabilities available to developers.

While tagging may initially appear to be administrative overhead, it becomes a strategic enabler as environments grow. Tags act as metadata labels that bring clarity and structure to large, complex cloud landscapes. They help transform an unorganized set of independent resources into a coherent, searchable, and well governed ecosystem. Whether you’re a solo developer or part of an enterprise team, effective tagging practices reduce investigative time, eliminate avoidable errors, improve visibility, and enhance cost transparency.

This guide focuses on practical, real world tagging approaches that developers can apply immediately. It avoids abstract concepts and instead emphasizes how tagging supports operations, cost optimization, automation, compliance, and environment management. By the end of this blog, you will understand how to apply meaningful tags, automate tagging at scale, and use tags to improve observability and governance across your AWS environment. In short, tagging becomes a foundational technique for building a cloud environment that is not only functional but also clean, traceable, and easy to operate.

In AWS, tags function as key–value pairs that are attached to cloud resources. They act as metadata that makes it easier to categorize and identify services such as EC2, S3, RDS, Lambda, and more. These metadata labels play a pivotal role in cost tracking, access governance, system automation, and operational management across diversified workloads.

One of the most impactful applications of tagging is in cost allocation and billing, where teams assign labels such as Environment, Project, or Department to allocate spending accurately. Tags also strengthen access control, enabling IAM policies that restrict or permit actions based on resource tags. Automation workflows leverage tags to power activities such as scheduled shutdowns, patch orchestration, and backup management through AWS Lambda, EventBridge, and Systems Manager. Tagging also improves security and compliance by enabling users to distinguish production resources from development workloads at a glance. Finally, operational visibility improves significantly as teams search and group large numbers of resources through console filtering.

Resource tagging provides meaningful **advantages **in day to day management. It improves cost visibility and accountability by associating resources with teams, applications, or business units. Operational efficiency increases because tags simplify lifecycle automation and help standardize resource governance practices. Tagging also enhances compliance by ensuring teams can identify business critical assets quickly and confirm they meet required policies. The ability to classify resources consistently contributes to a more controlled, predictable cloud environment that supports smarter decision making.

There are multiple approaches to tagging AWS resources, each suited to a different stage of the provisioning lifecycle. Tags can be applied manually from the AWS Management Console, either on individual resources or in bulk using Tag Editor. Developers using command line tooling can apply tags programmatically through the AWS CLI, while teams using infrastructure as code rely on CloudFormation **or **Terraform **templates to ensure resources are tagged automatically during deployment. Organizations operating at scale enforce standards using **Tag Policies in AWS Organizations, promoting consistent tagging structures. SDKs and AWS APIs further enable tag automation through languages such as Python (Boto3), JavaScript, or Go, making tagging part of the application deployment workflow.
A practical example of bulk tagging demonstrates how AWS Console users can efficiently label multiple resources.
By signing into the AWS Management Console and navigating to Resource Groups → *Tag Editor, *

you can select a region and specify one or more resource types such as EC2 instances or S3 buckets.

After retrieving the relevant resources, selecting the ones to update, and choosing “Manage Tags,”

teams can apply key–value pairs such as Environment=Dev to all selected items at once.

The new tags are applied consistently across resources, and you can verify the updates by inspecting each service individually. For instance, after applying tags, opening the EC2 instance page will reveal the updated metadata under the Tags tab, while the same verification is possible from the S3 bucket properties page.

This process illustrates how tagging can improve cross resource visibility and accelerate management tasks, especially when operating multiple instances or storage buckets that need to adhere to the same governance standards. Through bulk tagging, teams reduce manual effort, ensure tagging consistency, and maintain clear alignment with organizational policies.

Conclusion:
AWS resource tagging is far more than a labeling mechanism, it forms the foundation for structured, automated, and cost efficient cloud operations. With well defined tag policies and automation in place, organizations gain deeper visibility into their environments, enforce consistent governance, improve operational control, and reduce time spent managing resources manually. As infrastructures continue to grow in size and complexity, a strong tagging strategy becomes indispensable for achieving clarity, accountability, and long term operational excellence across AWS environments.