Appendix F — Cloud implementation mapping
This is Appendix F, ‘Cloud implementation mapping’, of The Contextual Agentic Enterprise, given in full on the companion site.
This appendix maps vendor-neutral architectural responsibilities to representative AWS and Microsoft Azure implementation options as of the book’s August 2026 research freeze. It is not a recommendation to use every listed service. Product capabilities should be verified against current documentation before implementation.
The durable requirement is intentionally listed separately from vendor examples. That separation is important: service names will change faster than the enterprise responsibilities they implement.
F.1 Identity and authority
Human identity. AWS examples include IAM Identity Centre and federated identity-provider patterns. Microsoft examples include Microsoft Entra ID. The durable requirement is an authenticated human principal with appropriate MFA, conditional access and lifecycle controls.
Workload and agent identity. AWS examples include IAM roles and AgentCore Identity where applicable. Microsoft examples include managed identities and workload identity. The durable requirement is a non-human identity with least privilege, short credential lifetime where possible and explicit ownership.
Policy enforcement. AWS examples include IAM, Cedar-based policy approaches, AgentCore Policy and custom policy services. Microsoft examples include Azure RBAC, ABAC-capable patterns and custom policy engines. The durable requirement is deterministic policy decision and enforcement outside the model.
F.2 Models, agents and durable execution
Model access. AWS examples include Amazon Bedrock and other provider endpoints. Microsoft examples include Microsoft Foundry and Azure-hosted model endpoints. The durable requirement is provider abstraction, policy control, telemetry and cost visibility.
Agent runtime. AWS examples include AgentCore Runtime, containers, Lambda, ECS and EKS. Microsoft examples include Agent Framework/Foundry, Functions, Container Apps and AKS. The durable requirement is bounded execution with state separated from ephemeral model context.
Durable workflows. AWS examples include Step Functions, queues and custom workflow engines. Microsoft examples include Durable Functions, Logic Apps, Service Bus and custom workflow engines. The durable requirement is checkpointing, retry policy, idempotency and deterministic state transitions where business invariants require them.
F.3 Capability and protocol boundaries
MCP gateway. AWS examples include AgentCore Gateway or a custom gateway. Microsoft examples include API Management or custom MCP gateways and agent services. The durable requirement is governed tool registration, identity, authorisation, schema validation, auditing and revocation.
API facade. AWS examples include API Gateway, Application Load Balancer and custom services. Microsoft examples include API Management and Application Gateway. The durable requirement is a protected and stable capability boundary in front of systems of record.
F.4 Knowledge and retrieval
Retrieval. AWS examples include OpenSearch, Bedrock Knowledge Bases and custom search stacks. Microsoft examples include Azure AI Search and custom retrieval systems. The durable requirement is permission-aware lexical, vector or hybrid retrieval with provenance and evaluation.
Graph and semantic relationships. AWS examples include Neptune and custom graph services. Microsoft implementations may use graph-capable or custom data services depending on requirements. The durable requirement is governed relationship semantics, provenance and access control rather than a particular graph product.
Object and document storage. AWS examples include Amazon S3. Microsoft examples include Blob Storage and ADLS. The durable requirement is source provenance, lifecycle policy, encryption and permission alignment with retrieval.
F.5 Events, secrets and observability
Messaging and events. AWS examples include SQS, SNS, EventBridge and MSK. Microsoft examples include Service Bus, Event Grid and Event Hubs. The durable requirement is durable event delivery, backpressure handling, identity and replay semantics appropriate to the business process.
Secrets and keys. AWS examples include Secrets Manager and KMS. Microsoft examples include Key Vault. The durable requirement is to keep secrets outside prompts and source code, apply rotation, and separate credential authority from model reasoning.
Observability. AWS examples include CloudWatch, X-Ray, OpenTelemetry and AgentCore observability. Microsoft examples include Azure Monitor, Application Insights and OpenTelemetry. The durable requirement is an end-to-end evidence trail connecting user request, model invocation, retrieval, policy, tool calls, A2A handoffs, cost and business outcome.
Evaluation. AWS examples include AgentCore Evaluations and custom evaluation harnesses. Microsoft examples include Foundry/AI evaluation tooling and custom harnesses. The durable requirement is repeatable offline and production evaluation tied to explicit acceptance criteria.
F.6 Private networking
AWS examples include VPC endpoints and PrivateLink. Microsoft examples include Private Link, private endpoints and VNet-integrated services. The durable requirement is to minimise unnecessary data movement and public exposure while recognising that network location alone is not a trust decision.
F.7 AWS-specific evolution note
The AWS Well-Architected Agentic AI Lens was published in June 2026 and is unusually explicit about bounded agents, observability, agent identity, human oversight, tool security, multi-agent communication, reliability and cost. Its principles align closely with the vendor-neutral patterns in this book. Service names such as AgentCore Runtime, Identity, Gateway, Memory, Policy, Observability and Evaluations should nonetheless be treated as current implementation options, not permanent architectural categories.
F.8 Azure-specific evolution note
Microsoft Agent Framework is the current successor direction to AutoGen and Semantic Kernel concepts for agent/workflow development. Azure AI Search’s 2026 agentic retrieval features include query planning and parallel subqueries in selected APIs. These details are fast-moving. Preserve the distinction between agent runtime, durable workflow, retrieval, identity and policy even if implementation services merge or change names.
F.9 Portable design seams
Portability is most valuable at seams where change is plausible: model adapters, retrieval interfaces, tool schemas, evidence formats, telemetry, policy-decision interfaces, business workflow state and protocol boundaries such as MCP and A2A.
Avoid forcing a lowest-common-denominator abstraction across every cloud service. Portability has an engineering cost and should be applied where it reduces a credible switching, sovereignty or resilience risk.
Last updated 3 October 2026.