Cloud + AI: Building with Artificial Intelligence on AWS Without Losing Control
A practical guide to building generative AI on AWS with security built in from day one. It covers choosing the right service layer, a reference RAG architecture, mapping OWASP LLM risks to AWS controls, cost governance, and lessons for SMEs in Latin America.
The cloud is where AI becomes real
Generative AI is no longer an experiment: it is now a capability any team can consume as a service. What once required your own GPUs, months of training and a data science team now takes a single call to a managed API.
But that ease has a hidden cost. Connecting a model to company data raises questions that never show up in the demo: who can see what, how much each answer costs, and how to stop the model from doing something it shouldn't.
In this article I walk through building with AI on AWS from the perspective of someone who works in cybersecurity and vulnerability management. The idea is simple: take advantage of the cloud's speed without losing control.
What AWS offers: picking the right layer
The first decision is not which model to use, but which layer to build on. AWS organizes its AI offering in tiers that range from “ready to use” to “full control”.
| Layer | Service | What it's for | When to choose it |
|---|---|---|---|
| Applications | Amazon Q | Ready-made assistants for business and development | You want results without building anything yourself |
| Models as a service | Amazon Bedrock | API access to foundation models from several providers, with Knowledge Bases and Guardrails | You're building your own generative AI application |
| Agents in production | Amazon Bedrock AgentCore | Runtime, gateway, memory, policies and observability for agents | Your AI doesn't just answer: it takes actions through tools |
| ML infrastructure | Amazon SageMaker AI | Train, fine-tune and deploy your own models | You need a custom model or control over the ML lifecycle |
For most teams, Bedrock is the sensible starting point. You don't manage GPUs, you pay per use, and you can switch models without rewriting the application.
Agents deserve a closer look. In 2026 AWS added a policy-based authorization layer to AgentCore, which became generally available in March (Classmethod ). We'll come back to it in the security section.
Reference architecture: a RAG assistant with Bedrock
The most common use case is an assistant that answers using your company's documents. The RAG pattern (retrieval-augmented generation) solves it without retraining any model.
RAG assistant on AWS · 6 components + controls
The query comes in through API Gateway with WAF. Lambda retrieves the relevant chunks from Knowledge Bases, and Bedrock generates the answer with Guardrails applied. Documents live in S3 and sync to the vector index; Bedrock does not use your prompts or responses to train its models.
Security: AI is just another workload, with new risks
A model connected to your data is an attack surface. Classic cloud controls still apply, but LLMs bring their own risks, which the OWASP Top 10 for LLM Applications (2025 edition) describes very well.
| OWASP LLM risk | What happens | Control on AWS |
|---|---|---|
| LLM01 Prompt injection | Malicious text (from the user or a document) changes the model's behavior | Bedrock Guardrails with the prompt-attack filter; keep instructions separate from data |
| LLM02 Sensitive information disclosure | The model reveals personal or confidential data | PII filters in Guardrails; per-document permissions in the knowledge base |
| LLM05 Improper output handling | The response is executed or rendered without validation | Treat output as untrusted input: validate, escape, never execute it directly |
| LLM06 Excessive agency | An agent does more than it should | Least privilege in IAM; AgentCore policies on which tools it can invoke |
| LLM08 Vector and embedding weaknesses | One customer's data shows up in another's answers | Isolate indexes per tenant; mandatory metadata filters |
| LLM10 Unbounded consumption | Cost blowouts or abuse through request volume | Quotas, throttling in API Gateway, AWS Budgets alerts |
Beyond the table, I consider five practices non-negotiable:
• Identity first. Every Lambda function or agent gets its own IAM role, scoped to the models and buckets it needs.
• Private traffic. Invoke Bedrock through VPC endpoints (PrivateLink) when the data is sensitive.
• Encryption with your own keys. KMS customer managed keys for S3, the vector store and the logs.
• Traceability. CloudTrail for API calls and Bedrock model invocation logging to audit prompts and responses.
• Continuous vulnerability management. Amazon Inspector on your functions and containers, and Security Hub to consolidate findings. AI doesn't exempt you from patching.
One notable change this year: since June 2026, Bedrock Guardrails can be evaluated inside AgentCore policies, at the gateway boundary and outside the agent's code (AWS announcement ). That way, enforcement doesn't depend on the agent “behaving”. Note: at launch it was available in N. Virginia, London, Stockholm, Sydney and Tokyo, not São Paulo.
Cost and governance: every token counts
With generative AI you pay for input and output tokens, so cost grows with every document you add to the context. A cheap prototype can become expensive at scale if nobody is measuring it.
• Pick the smallest model that does the job. Classifying or summarizing rarely needs the most powerful model in the catalog.
• Trim the context. Good RAG sends the three relevant chunks, not the entire manual.
• Use prompt caching when the system instructions repeat on every call.
• Use batch inference for work that doesn't need an immediate answer, such as processing nightly reports.
• Tag everything. Project and team tags on every resource, so Cost Explorer shows who spends what.
• Set alarms before production. AWS Budgets with threshold alerts, not after the first surprise bill.
Governance is also organizational. Define who approves new use cases, what data can go into a model, and who reviews the invocation logs.
Lessons for SMEs in Latin America
Small and mid-sized businesses in the region don't need an AI lab to get value. They need a concrete use case, a scoped pilot and clear rules about their data.
1. Start with a real pain point. Answering repetitive customer questions, summarizing support tickets or searching internal procedures.
2. Run a four- to six-week pilot with a single team and one metric: time saved, tickets resolved or queries handled.
3. Classify your data before connecting it. If a document shouldn't be visible to everyone, the model shouldn't see it without access control either.
4. Check local regulation. In Peru, the Personal Data Protection Law (Law 29733) still applies when data travels to a model; also consider which AWS Region processes it.
5. Measure and decide. If the pilot doesn't move the metric, adjust it or drop it without fear. The cloud lets you switch off what doesn't work.
The advantage of the cloud is that being wrong is cheap. What's expensive is not defining controls from the start.
Conclusion: speed with control
The cloud put AI within reach of every builder; the difference now is how we operate it. Identity, data, limits and traceability don't slow innovation down: they are what lets us take it to production with confidence.
I'd love to hear how you're approaching this. What controls do you apply to your AI workloads on AWS? Are you already running agents in production? Let me know in the comments.
Sources
• OWASP Top 10 for Large Language Model Applications, 2025 edition
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article