Artificial Intelligence on AWS

The AWS assessment covers feasibility, account placement and cost together, because on this platform the cost model is a design input rather than an afterthought.

• Account and IAM placement. AWS Organizations structure, IAM boundaries and where the AI workload should sit relative to your existing production accounts.
• Source-data inventory. Format, volume, refresh frequency and access owner recorded for every set in Amazon S3 and the connected systems around it.
• Sydney model availability check. Which shortlisted models can be called on demand from your intended region and which need a cross-Region inference profile, recorded with the date.
• Token and idle cost model. Monthly inference cost projected at expected and peak usage, plus the retrieval store your design implies and what it charges while nobody is asking questions.
• Build against adopt ruling. Where a managed assistant covers the need and where a custom Bedrock application is justified, with connector coverage checked against your real systems.
• Guardrails and approval points defined. The guardrail policies, the human approval steps and the actions an agent must never take unattended, all agreed before the first line of code.

Patterns are assembled from managed services rather than a single product, which gives precision at the cost of more decisions. We make those decisions explicit and record why each was taken. Where a problem genuinely needs several cooperating agents rather than one bounded agent, that is a different design and it sits with our agentic AI orchestration work.

• Retrieval with a documented strategy. Chunking and embedding choices recorded, metadata filters for team or tenancy scoping, and permission checks applied before any result reaches the model.
• One Bedrock integration point. Every application calls models through a single layer with Bedrock guardrails applied consistently, so a model change is configuration rather than a rewrite.
• Agents scoped to a tool schema. Explicit tools with validated arguments, using Bedrock AgentCore where a session needs managed runtime, memory and identity handling.
• Retrieval store sized for real volume. A serverless vector collection where query volume justifies its capacity floor, and a database with vector support where it does not.
• Event-driven document orchestration. Step Functions for multi-step work, Lambda for extraction and enrichment, and EventBridge triggering on new objects in S3 instead of polling on a timer.
• Model access off the public surface. Amazon API Gateway in front of application endpoints for authentication, throttling and usage plans, with no direct model endpoint exposed.
• Predictive models registered, not ad hoc. Trained and versioned in SageMaker AI, with Amazon SageMaker Unified Studio used where data engineering, analysis and modelling share one governed source.

On AWS almost nothing is enabled by default, which is an advantage if the controls are designed in and a liability if they are left until later. We build them in the first increment.

• A role per component. Separate IAM roles for retrieval, inference and each tool an agent may call, with no shared long-lived credentials anywhere in the path.
• Guardrails as code, not console clicks. One shared Bedrock guardrail policy set, with denied topics, sensitive-information rules and grounding checks tested in the release pipeline.
• Retrieved content treated as hostile. Prompt-injection cases held permanently in the evaluation suite, and tool invocation restricted to an allowlist with argument validation.
• Buckets in scope, and out, in writing. S3 bucket policies, encryption and access logging reviewed for every source, with a published list of buckets deliberately excluded from indexing.
• Correlation IDs on every call. Model calls, retrievals and tool invocations logged to CloudWatch so any single answer can be reconstructed during an internal review.
• Approval as a workflow state. A human approval task inside Step Functions before an agent takes any action with financial, contractual or client-facing consequence.

AWS assistants usually appear inside your own application or a managed assistant you switch on for one team, so adoption is planned per cohort and per workflow rather than per tenant.

• A pilot cohort, not a tenant rollout. Named users with a weekly review of unhelpful answers and a documented list of the questions the system is not expected to handle.
• Managed assistant to one area first. Connector coverage confirmed against the systems that team actually uses before licences are assigned any more widely.
• Engineering conventions agreed first. Amazon Q Developer introduced with written rules on review, testing and what may not be accepted into a codebase without inspection.
• Enablement per workflow. Prompts and worked examples written from your own documents, covering the specific tasks in scope rather than the tool in general.
• The sponsor owns the usage statement. Intended use, known limitations and escalation path published and owned by the business, not by the platform team.
• Measured against the assessment baseline. Reported to the sponsor with the original assumptions restated, so the comparison is still defensible months later.

A generative workload on AWS has many moving parts and many small meters. Continuation keeps quality, security posture and cost under the same review each month.

• Evaluation on every model change. The suite re-run on a schedule and on each model or prompt change, with results trended and regressions raised before users report them.
• Alarms on the meters that matter. CloudWatch dashboards and alarms on invocation errors, throttling, latency percentiles, consumption per feature and retrieval quality signals.
• Guardrails re-tested on new content. Denied topics and sensitive-information filters checked against fresh examples as new content types and use cases appear.
• Model lifecycle tracked. A migration path tested and ready before a Bedrock model version is withdrawn, rather than after a call starts failing in production.
• Retrieval sizing revisited. OpenSearch cluster health, index freshness and ingestion failures reviewed, with capacity set against real query volume rather than the first estimate.
• Cost attributed by feature. Monthly inference, retrieval and orchestration spend compared with the assessment model, broken down per feature and per account.