从门户跳转到即时答案：HEMA 的 MCP 与 Amazon Bedrock 之旅

本文由 HEMA 的 Mauro Rallo 和 Patrick van der Plas 共同撰写。

当 HEMA 的工程师需要一个答案时，他们不得不在相互割裂的 Wiki、服务目录和 IT 门户之间反复跳转查找。为了将这种摩擦转化为即时答案，这家拥有 100 年历史的荷兰零售商基于 Amazon Bedrock AgentCore 构建了知识层。HEMA 在多个国家拥有超过 750 家门店，其技术组织由工程师、产品负责人和业务分析师构成，推动着数字化转型。它需要一种能够跨角色、跨工具发挥作用的解决方案。

多年来，HEMA 悄然构建了一项宝贵资产：一幅规模庞大且结构化的自身技术版图。服务目录将人员映射到团队、团队映射到服务，服务再映射到我们提供的 API 以及所支持的业务能力。问题从来不是知识不存在，而是这些知识难以获取。随着工程组织不断扩大，非正式的_“问问坐在你旁边的人”_模式失效了，团队最终将答案分散在门户、Wiki 和很少有人知道如何浏览的文档中。

本文介绍 HEMA 面临的内部知识碎片化挑战、我们为何选择使用 Model Context Protocol（MCP）和 Amazon Bedrock AgentCore 构建 HEMA 内部 AI 助手 HAL，以及它如何改变团队的工作方式。

这一构想建立在两个互补目标之上。HAL 将知识集中到一处，而 MCP 则将这些知识交付到人们已在使用的工具中（HAL 聊天、Kiro、Claude 和其他 Agent）。安全性以 Microsoft Entra ID 为基础，客户端无需 AWS 凭证。最初作为开发者工具的 HAL，如今已成为跨角色助手。相同架构还将成为下一步的基础：把 HAL 从只读知识层转变为行动层。

挑战：门户跳转与知识碎片化

HEMA 的知识问题包含两个不同层面。

第一层是结构化基础设施知识，实际状况良好。多年来，HEMA 一直维护着一份服务目录，用于记录技术资产如何组合：哪些团队负责哪些服务、这些服务公开哪些 API，以及它们如何映射到业务能力。来自产品信息管理（PIM）引擎和数据网格表等系统的结构化数据已被导入并整理。对于“有什么”和“谁负责”之类的问题，答案通常都存在，前提是你知道去哪里找。

第二层则是缺口。知道有什么，并不等同于知道如何完成某件事。_“如何申请 API 访问权限？如何开通一个新组？我们对 X 的规则是什么？”_这些流程性问题没有一个统一归宿。在团队规模较小、所有人彼此熟悉时，这并不是问题，大家直接询问即可。但随着 HEMA 发展并吸纳新工程师，这一模式不再具备可扩展性，而且几乎没有书面文档可以依靠。

这导致新成员入职节奏缓慢、不同查找位置给出的答案不一致、频繁的上下文切换，以及将人们从实际工作中拉走的阻碍。过去寻找一个答案可能需要在三个或四个门户之间导航，有时甚至耗费整整一个下午；如今，这件事可在 IDE 或聊天窗口中于数秒内完成。

图 1：实施前的状态，展示用户必须查询的信息来源

为什么选择 MCP 和 Amazon Bedrock AgentCore

两个目标塑造了这一方案，并分别清晰对应我们选择的两项技术。

第一个目标属于 HAL：将 HEMA 碎片化的知识整合为一个受治理的单一事实来源。第二个目标属于 MCP：在用户已在使用的工作环境中交付这些知识，而不是强迫他们再访问一个门户。

**为什么选择 MCP：**Model Context Protocol 为 AI 客户端与后端能力之间提供了标准化接口。我们无需为每个知识来源构建定制集成，也无需为每个客户端应用重新构建；而是将每个来源一次性作为 MCP 工具公开。

兼容 MCP 的客户端，如 HAL Web 聊天、Kiro、Claude 和其他 Agent，随后就能使用相同工具，无需定制开发。这使得_“从你的日常工具访问”_成为现实，而非一项针对每种工具都要单独实施的工程项目。

**为什么选择 Amazon Bedrock AgentCore：**Amazon Bedrock AgentCore 是一个可使用任意框架或模型，大规模构建、连接和优化 Agent 的平台。对于 HEMA 而言，它意味着无需搭建和运维自定义 MCP 服务器基础设施即可构建 HAL。最重要的能力包括：

• Gateway 可直接将 OpenAPI 规范和 AWS Lambda 函数 转换为 MCP 工具，无需编写或运行自定义 MCP 服务器代码。
• Identity 为我们的内部 API 提供托管的入站 JSON Web Token（JWT）认证，以及托管的出站 OAuth2（令牌保管库）。
• Runtime 将内部 Agent（使用 Strands 框架构建）托管为容器。
• Memory 和 Amazon Bedrock Guardrails 提供对话记忆与内容过滤，并支持欧盟推理区域和荷兰语。

这些能力共同为我们奠定了适合企业使用的基础：Entra ID OAuth、当前的只读访问，以及由既有 Active Directory 组驱动的访问控制，其安全程度足以用于公开真实的内部知识。

逐步构建 HAL

HAL 并非一开始就具备完整形态，而是通过两个经过深思熟虑的步骤逐步成长。首先，团队构建了拥有独立聊天 UI 的独立助手。随后，当这一基础证明自身价值后，我们通过 MCP 将其开放给人们已经在使用的工具。

第 1 步：作为独立助手的 HAL

HAL 的第一个版本是一个自包含助手：由一个 Web 聊天 UI（使用 Next.js 构建）支持，其后端 Agent 能够回答来自 HEMA 知识体系的问题。当时还没有 MCP 和外部客户端，只有 HAL UI 与 HAL Agent 通信。

HAL Agent 是一个 Strands Agent，被打包为 Linux/ARM64 容器，并托管在 AgentCore runtime 上；同时配套使用 AgentCore memory（短期对话上下文）和 Amazon Bedrock Guardrails（标准层级，为支持荷兰语而使用欧盟跨区域推理）。AgentCore runtime 和 AgentCore memory 都是 Amazon Bedrock AgentCore 的能力。

该 Agent 通过两条不同路径获取知识：

• **直接连接 Knowledge Bases 的本地工具。**Agent 的语义搜索工具是本地 Strands 工具，它们直接通过 Knowledge Bases 调用 Amazon Bedrock Retrieve API，中间没有 Gateway。这是最常用的_“从知识库回答问题”_路径。
• **通过 MCP 连接 AgentCore Gateway，以访问实时 API。**对于实时数据、完整 OpenAPI 规范、服务目录查询以及人员和团队查询，Agent 会通过 MCP 连接到自身的 AgentCore Gateway——这也是 Amazon Bedrock AgentCore 的一项能力。该 Gateway 使用 AWS Identity and Access Management（IAM）SigV4 认证，再由其调用我们的内部 API。

图 2：第 1 步，作为独立助手的 HAL

我们从已有的结构化数据——服务目录——起步，并添加最具价值的文档，依据痛点及问题被询问的频率确定优先级。HAL 背后是多个基于 Amazon Bedrock Knowledge Bases 构建的知识库。Amazon Bedrock Knowledge Bases 是全托管的检索增强生成（RAG）能力：其中包含 IT 和操作指南文档、API/OpenAPI 规范、Kafka 事件流主题及其 Avro 模式、数据整合层（DCL）数据交换通道，以及服务目录（人员、团队、服务和 API）。

这里没有自定义 MCP 服务器代码。AgentCore Gateway 会直接根据 API 透传目标的 OpenAPI 规范生成 MCP 工具，也会根据用于在 Knowledge Bases 上执行语义搜索的 Lambda 函数生成工具。将 Gateway 直接指向现有 API 规范并非理想的最终状态。为系统间调用设计的 API 不一定能够自然映射为 Agent 可以推理的工具，因此我们计划将这些定义重构为更适合 Agent 使用的工具。

不过目前，按原样公开这些 API 已以很低的工作量带来了高价值。kb-search Lambda 封装了针对 Knowledge Bases 的 Amazon Bedrock Retrieve API。其 AWS Identity and Access Management（IAM）权限被限定为特定知识库 Amazon Resource Names（ARN），以及对源文档 Amazon Simple Storage Service（Amazon S3）存储桶的只读访问。

检索遵循两步模式：首次 Knowledge Base 搜索可回答大多数问题；当单个分块不足以回答时，fetch_full_document 会拉取完整文档。通过 Amazon Bedrock 对语义查询进行重排序，以及针对团队范围查询使用 team_id 元数据过滤，可进一步提升检索质量。

HAL 在自身聊天 UI 中运行良好，但人们日常使用的是其他工具：IDE 和 AI 助手。第二步是让 Kiro 和 Claude 等外部 MCP 客户端能够访问相同的知识和工具，同时不向它们发放 AWS 凭证。这意味着需要增加第二个 AgentCore Gateway，使用 Microsoft Entra ID 而不是 IAM 进行认证。

由于一个 AgentCore Gateway 仅支持单一入站认证类型，我们无法将第 1 步中供 Agent 使用、采用 IAM 认证的 Gateway 复用于这些外部客户端。因此，我们增加了第二个 Gateway：Entra MCP Gateway。它通过 Microsoft Entra ID 的自定义 JWT 完成认证，专门服务于 Kiro 和 Claude 等外部 MCP 客户端。它仅与 Agent Gateway 共享只读 Knowledge Bases。二者没有共享代码，因此外部接口可以独立演进或发生故障，而不会影响内部 Agent。

图 3：第 2 步，通过 MCP 将 HAL 接入日常工具

AgentCore Gateway 从 OpenAPI 规范和 Lambda 函数中公开工具。为了将知识库作为 Gateway 目标公开，我们构建了一个小型中间 Lambda 函数：Gateway 将其作为工具调用，该函数代表 Gateway 在知识库上执行语义搜索。相比之下，实时内部 API 则直接作为 OpenAPI 目标公开。

难点：认证与动态客户端注册（DCR）

一个有趣的部分是，外部客户端如何在没有 AWS 凭证的情况下完成认证。Entra Gateway 前方部署了一个 MCP 认证代理：这是由单个 Lambda 支持的 Amazon API Gateway v2 HTTP API，用来协调 MCP OAuth 规范与 Entra ID 的具体要求。它提供 OAuth 发现文档，并将请求的 scope 重写为资源应用的调用 scope。它还会移除 Entra v2.0 不接受的旧版 resource 参数，添加 response_mode=query 以便桌面客户端获取授权码，并使用 bearer token 代理 /mcp。

有一个细节值得特别说明，因为 DCR 只在整个系统的这一处出现。MCP 客户端要求 DCR，即通过 POST /register 调用返回客户端 ID。代理并未实现真正的动态注册，而是使用一个桩实现的 /register，返回固定的、已预先配置的客户端 ID。DCR 是模拟的，并不是真实注册。

完整握手流程如下：

图 4：OAuth 与 DCR 认证时序

对于最终用户而言，收益在于配置时只需提供代理 URL 和一个空的 oauthScopes 列表：无需 AWS 凭证，首次连接时通过浏览器登录，之后自动刷新令牌。

在 Amazon Bedrock AgentCore 上部署

基础设施使用 AWS Cloud Development Kit（AWS CDK）定义，为采用 npm workspaces 的 TypeScript monorepo。内部 Agent 作为 Docker 容器运行在 AgentCore runtime 上。与环境相关的配置，如租户、客户端和资源标识符，则通过 AWS Systems Manager（SSM）参数提供。

测试与发布

在正式上线前，HEMA 部署了 HA

This post is co-written with Mauro Rallo and Patrick van der Plas from HEMA.

When engineers at HEMA needed an answer, they went portal-hopping, navigating disconnected wikis, service catalogs, and IT portals to find it. To turn that friction into instant answers, the 100-year-old Dutch retailer built a knowledge layer on Amazon Bedrock AgentCore. HEMA has over 750 stores across multiple countries, served by a technology organization of engineers, product owners, and business analysts driving digital transformation. It needed a solution that worked across roles and tools.

Over the years, HEMA had quietly built something valuable: a large, structured picture of its own technology landscape. A service catalog mapped people to teams, teams to services, and services to the APIs we expose, and the business capabilities we support. The problem was never that the knowledge didn’t exist. It was that the knowledge was hard to reach. As the engineering organization grew, the informal “just ask the person next to you” model broke down, and teams ended up scattering answers across portals, wikis, and documentation that few people knew how to navigate.

In this post, we describe the challenge HEMA faced with fragmented internal knowledge, why we chose to build HAL, HEMA’s internal AI assistant, using Model Context Protocol (MCP) and Amazon Bedrock AgentCore, and how it changed the way our teams work.

The idea rests on two complementary goals. HAL puts knowledge in one place, and MCP delivers that knowledge inside the tools people already use (the HAL chat, Kiro, Claude, and other agents). Security is anchored in Microsoft Entra ID, with no AWS credentials on the client. What began as a developer tool is already a cross-role assistant. The same architecture will be the foundation for a next step: turning HAL from a read-only knowledge layer into an action layer.

The challenge: Portal-hopping and knowledge fragmentation

HEMA’s knowledge problem had two distinct layers.

The first layer , structured infrastructure knowledge, was actually in good shape. For years, HEMA has maintained a service catalog that captured how the technology estate fits together: which teams own which services, what APIs those services expose, and how they map to business capabilities. Structured data from systems such as the product information management (PIM) engine and the data-mesh tables had been imported and organized. For anything about what exists and who owns it, the answer was usually available, if you knew where to look.

The second layer was the gap. Knowing what exists is not the same as knowing how to do something. “How do I request access to an API? How do I get a new group provisioned? What’s our rule for X?”. These procedural questions had no single home. When teams were small and everyone knew each other, that was fine. People asked directly. As HEMA grew and onboarded new engineers, that model stopped scaling, and there was little written documentation to fall back on.

That translated into slow onboarding for new joiners, inconsistent answers depending on where someone looked, constant context-switching, and friction that pulled people out of their actual work. Finding an answer that once meant navigating three or four portals, sometimes across an entire afternoon, now happens in seconds, from inside the Integrated Development Environment (IDE) or chat window.

Figure 1: The “before” state, showing the sources a user had to consult

Why MCP and Amazon Bedrock AgentCore

Two goals shaped the solution, and they map cleanly onto the two technologies we chose.

The first goal belongs to HAL : consolidate HEMA’s fragmented knowledge into one governed source of truth. The second goal belongs to MCP : deliver that knowledge to people where they already work, rather than forcing them to visit yet another portal.

Why MCP: Model Context Protocol gives us a standardized interface between AI clients and backend capabilities. Instead of building a bespoke integration for every knowledge source and re-building it for every client application, we expose each source once as an MCP tool.

MCP-compatible clients such as the HAL web chat, Kiro, Claude, and other agents can then consume the same tools without custom work. This is what makes “access from your daily tool” practical rather than a per-tool engineering project.

Why Amazon Bedrock AgentCore: Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale, with any framework or model. For HEMA, it meant building HAL without standing up and operating custom MCP server infrastructure. The capabilities that mattered most:

• Gateway turns OpenAPI specifications and AWS Lambda functions into MCP tools directly. There is no custom MCP server code to write or run.
• Identity provides managed inbound JSON Web Token (JWT) authentication and managed outbound OAuth2 (a token vault) to our internal APIs.
• Runtime hosts the internal agent (built with the Strands framework) as a container.
• Memory and Amazon Bedrock Guardrails provide conversation memory and content filtering, with EU inference regions and Dutch-language support.

Together, these gave us enterprise-appropriate footing: Entra ID OAuth, read-only access today, and access control driven by existing Active Directory groups, safe enough to expose real internal knowledge.

Building HAL, step by step

HAL didn’t arrive fully formed. It grew in two deliberate steps. First, the team built a standalone assistant with its own chat UI. Then, once that foundation proved itself, we opened it up to the tools people already work in through MCP.

Step 1: HAL as a standalone assistant

The first version of HAL was a self-contained assistant: a web chat UI (built with Next.js) backed by an agent that could answer questions from HEMA’s knowledge. There were no MCP and no external clients yet, only the HAL UI talking to the HAL agent.

The HAL agent is a Strands agent packaged as a Linux/ARM64 container and hosted on AgentCore runtime, together with AgentCore memory (short-term conversation context) and Amazon Bedrock Guardrails (Standard tier, EU Cross-Region inference for Dutch-language support). AgentCore runtime and AgentCore memory are capabilities of Amazon Bedrock AgentCore.

The agent reaches knowledge along two distinct paths:

• Local tools, direct to the Knowledge Bases. The agent’s semantic-search tools are local Strands tools that call the Amazon Bedrock Retrieve API directly over the Knowledge Bases, no gateway in between. This is the bread-and-butter “answer from the knowledge base” path.
• MCP to an AgentCore Gateway, for live APIs. For live data, full OpenAPI specifications, service-catalog lookups, and people/team queries, the agent connects over MCP to its own AgentCore Gateway, a capability of Amazon Bedrock AgentCore. This Gateway is authenticated with AWS Identity and Access Management (IAM) SigV4, which in turn calls our internal APIs.

Figure 2: Step 1, HAL as a standalone assistant

We started from the structured data we already had, the service catalog, and added the highest-value documentation, prioritizing by pain and by how often something was asked. Behind HAL sit several knowledge bases built on Amazon Bedrock Knowledge Bases, the fully managed Retrieval Augmented Generation (RAG) capability: IT and how-to documentation, API/OpenAPI specifications, Kafka event-streaming topics and their Avro schemas, Data Consolidation Layer (DCL) data-exchange channels, and the service catalog (people, teams, services, and APIs).

There’s no custom MCP server code. AgentCore Gateway generates the MCP tools directly from OpenAPI specifications for the API passthrough targets, and from a Lambda function for semantic search over the Knowledge Bases. Pointing the Gateway straight at our existing API specifications isn’t the ideal end state. An API designed for system-to-system use does not always map cleanly onto a tool an agent can reason about, so we plan to refactor those definitions into more agent-friendly tools.

For now, though, exposing the APIs as-is delivered high value for little effort. The kb-search Lambda wraps the Amazon Bedrock Retrieve API over the Knowledge Bases. It’s scoped by AWS Identity and Access Management (IAM) to the specific Knowledge Base Amazon Resource Names (ARNs), plus read access to the source-document Amazon Simple Storage Service (Amazon S3) bucket.

Retrieval follows a two-step pattern: an initial Knowledge Base search answers most questions, and fetch_full_document pulls the complete document when a single chunk isn’t enough. Retrieval quality is improved with Amazon Bedrock reranking on semantic queries and team_id metadata filtering for team-scoped lookups.

HAL worked well in its own chat UI, but people live in other tools: their IDE, their AI assistant. The second step was to let external MCP clients such as Kiro and Claude reach the same knowledge and tools, without handing out AWS credentials. That meant adding a second AgentCore Gateway, authenticated with Microsoft Entra ID instead of IAM.

Because an AgentCore Gateway supports only a single inbound authentication type, we could not reuse the agent’s IAM-authenticated Gateway from Step 1 for these external clients. So, we added a second Gateway, an Entra MCP Gateway authenticated with a custom JWT through Microsoft Entra ID, dedicated to external MCP clients such as Kiro and Claude. It shares only the read-only Knowledge Bases with the agent Gateway. There is no shared code, so the external-facing surface can evolve, or fail, without impact on the internal agent.

Figure 3: Step 2, opening HAL to daily tools with MCP

AgentCore Gateway exposes tools from OpenAPI specifications and Lambda functions. To surface the knowledge bases as a Gateway target, we built a small intermediate Lambda function that the Gateway calls as a tool, and which performs the semantic search over the knowledge bases on behalf of the Gateway. The live internal APIs, by contrast, are exposed directly as OpenAPI targets.

The hard part: Authentication and Dynamic Client Registration (DCR)

One interesting piece is how external clients authenticate without AWS credentials. In front of the Entra Gateway sits an MCP auth proxy, an Amazon API Gateway v2 HTTP API backed by a single Lambda, that reconciles the MCP OAuth specification with the specifics of Entra ID. It serves the OAuth discovery documents and rewrites the requested scope to the resource app’s invoke scope. It also strips the legacy resource parameter that Entra v2.0 rejects, adds response_mode=query so desktop clients can capture the authorization code, and proxies /mcp with the bearer token.

One detail is worth calling out because it is the only place DCR appears in the whole system. MCP clients expect DCR, a POST /register call that hands back a client ID. Rather than implementing true dynamic registration, the proxy uses a stubbed /register that returns a fixed, pre-provisioned client ID. DCR is emulated, not real.

The full handshake looks like this:

Figure 4: The OAuth and DCR authentication sequence

For the end user, the payoff is that configuration is only the proxy URL and an empty oauthScopes list, no AWS credentials, a browser login on first connect, and automatic token refresh thereafter.

Deployment on Amazon Bedrock AgentCore

The infrastructure is defined in AWS Cloud Development Kit (AWS CDK), a TypeScript monorepo using npm workspaces. The internal agent runs as a Docker container on AgentCore runtime. Environment-specific configuration, such as tenant, client, and resource identifiers, is supplied through AWS Systems Manager (SSM) parameters.

Testing and rollout

Before going live, HEMA deployed HAL to a staging environment and opened it to both engineers and business users for hands-on testing over a one-month period. This validated answer quality, coverage gaps, and day-to-day usability before the solution was promoted to production for wider adoption across the organization.

Who uses HAL today

HAL began as a developer tool, but it is already a cross-role assistant, and that breadth is the point.

• Developers use the full technical surface: documentation, API specifications, Kafka topics and schemas, the service catalog, and DCL channels, from inside Kiro and the chat.
• Product owners rely on HAL for documentation, how-to, and process knowledge: the procedural layer that used to have no home.
• Business analysts use HAL for infrastructure knowledge: which services exist, what APIs they expose, and which teams own them, drawing directly on the service catalog.

The pull from non-developer roles is real and growing: HEMA’s end-to-end team, mapping and optimizing product-manager processes, is already engaging with HAL as part of that work. Internally, HAL is distributed through an “Everyone Skill” and accompanying steering files, shared and maintained through the monthly HEMA AI Development Forum.

What’s next: From answers to actions

Today, HAL is read-only and delivers instant answers. The next step is instant action, performed by the same assistant.

This is feasible now precisely because the underlying portals are already API-enabled and already integrated with existing Microsoft Entra ID single sign-on. That means HAL can expose those operations as MCP action tools using the very same Entra ID authentication and Active Directory group authorization model that already secures the read tools. No new security model is required, only new, carefully scoped tools.

The flagship example is provisioning a new AWS account. Today a developer goes to a dedicated portal to request one. Next, they will make the same request directly from chat, Kiro, Claude, or other agents without visiting the portal at all. And because HAL already serves product owners and business analysts, the same action pattern extends naturally beyond developer operations to the wider set of operational requests those roles make every day.

The lesson is that the read architecture earns the write step: by getting identity, multi-client access, and governance right for answers, we have laid the groundwork for actions.

Conclusion

HAL puts HEMA’s organizational knowledge in one governed place. MCP and Amazon Bedrock AgentCore make that knowledge reachable, multi-client, and secure without forcing every consuming application to rebuild authentication, authorization, or routing from scratch. The outcome isn’t a developer chatbot, but a cross-role assistant for developers, product owners, and business analysts alike. The knowledge layer is live. The logical next step is extending it into an action layer. There, the same governed, authenticated infrastructure that today answers questions could tomorrow execute requests: provisioning access, triggering workflows, and acting on behalf of users directly from chat, Kiro, Claude, or other MCP-compatible agents.

If you want to explore the building blocks used in this post, the following resources are a good starting point. To learn about MCP server hosting, authentication, and gateway routing, see the Amazon Bedrock AgentCore documentation. For the Model Context Protocol specification and client compatibility guidance, visit the MCP specification site. To get hands-on with Strands Agents, the open source agent framework used to build HAL’s internal agent, see the Strands Agents GitHub repository. If you’re building a similar knowledge layer for your organization, the Amazon Bedrock workshop walks through RAG patterns, Knowledge Bases, and guardrails in a guided environment.

For related reading, see Building and connecting a production-ready ecommerce MCP server using Amazon Bedrock AgentCore and Mistral AI Studio and Introducing Amazon Bedrock AgentCore Identity: Securing agentic AI at scale.

---

About the authors

Mauro Rallo

Mauro is an Enterprise Architect and DevOps Product Owner for HEMA’s central platform (CIP), where he focuses on architecture, developer experience, and making engineering knowledge easy to reach across the organization.

Patrick van der Plas

Patrick is a Software Engineer on HEMA’s AI team, where he built the MCP gateway and tooling behind HAL, HEMA’s internal AI assistant. He also builds the wider platform for HEMA’s AI agents to run on and drives adoption of AI-assisted development across HEMA’s engineering teams. Outside the office, Patrick spends his time in the gym, running, competitive gaming, and enjoying life with his fiancée.

Amit Singh

Amit is a Senior Solutions Architect at AWS, working with enterprise retail customers in the Benelux region. He helps customers design cloud-native architectures, navigate complex modernization journeys, and adopt AI/ML capabilities at scale. Outside of work, he enjoys exploring new places and chasing the perfect shot, whether through a camera lens or on a running trail.