Building the Cloud for an Agentic World | AWS CEO Matt Garman

Startups have been central to AWS since its launch, as technology builders and potential enterprise customers; AWS estimates, imprecisely, that companies founded as startups account for 30–40% of its revenue. Garman said today’s startups often begin at greater scale and cost, but still need cloud security, performance, architecture, and the ability to grow. AWS is adapting its cloud for agents as well as people, with well-defined APIs, agent-building services, and a context layer intended to help agents reach data across services such as Aurora and S3. Garman said agent workflows are sensitive to tail latency, including S3 P999 latency, and that AWS’s performance can benefit them.

AWS wants to make it easier to begin building without forcing customers into a separate, limited environment. A new account can be ready in under 30 seconds, with VPC and IAM defaults handled behind the scenes, although the rollout may not be complete. Garman said it remains a full AWS account, so customers can configure advanced features later without migrating. For agents, AWS is also developing compute sandboxes, gateways, and fine-grained, short-lived permissions rather than simply granting an agent a person’s access. Firecracker micro VMs can start quickly and provide secure isolation with less overhead than traditional large VMs. Agent-created databases may be temporary, Garman said, but customers need a path to make them durable and scale them into production.

The physical buildout remains uncertain despite AWS’s plans to buy 2 million NVIDIA GPUs over the next couple of years; Garman said he does not know whether that will be enough. Power, data centers, construction labor, memory, and other components can limit deployments, and the bottleneck shifts by component and location. AWS plans server demand several years ahead and power, transmission, and capital needs decades ahead, while tracking tens or hundreds of thousands of components several supply-chain tiers down. Garman said the effort will never be perfect. The interviewer cited $220 billion in AWS capital spending for 2026; Garman said AI infrastructure has materially accelerated spending over roughly three or four years and that AWS does not expect to slow investment soon because demand remains massive. AWS allocates capacity across frontier labs, enterprises, and startups, aiming to fulfill about 60% of requests, sometimes later, in another region, or with a different configuration.

AWS’s investment in its own chips is intended to improve cost and performance as well as reduce reliance on general-purpose capacity. Nitro cards moved network and storage virtualization off servers, targeting near-bare-metal performance and stronger isolation; work on Nitro with the Annapurna team led to Graviton after customer interest in an Arm server processor. Garman said Graviton instances have been about 20% cheaper and delivered about 20% better performance for five or six years, and are now used by more than 90% of AWS’s top 100 customers. AWS began developing Trainium five or six years ago in anticipation of AI demand; Trainium 3 is in market, and capacity is sold out until around the end of next year. Garman said most Bedrock traffic runs on Trainium, which AWS uses extensively for inference, and argued its memory bandwidth and architecture may make it a leader in inference performance and cost. Trainium 4 has not launched.

Garman said most enterprise agents remain relatively simple, non-autonomous, and supervised by people, but already deliver value. He argued that companies can get more from agents by redesigning workflows from a blank slate rather than merely automating existing human steps; agents can explore many approaches in parallel. Wider deployment requires permission controls, sandboxing, guardrails, human oversight, evaluations, continuous testing, labeled data, production measurement, and checks for drift. Garman said few, if any, companies are good at solving these problems today, and that concern about autonomous agents may appropriately slow adoption. AWS and partners use forward-deployed engineering teams in 45-day engagements intended to train customers to create evaluations and label data themselves, rather than leave them dependent on consultants.

Data protection and security are central to AWS’s pitch for production agent workloads. Garman said enterprise data is a customer’s most valuable asset and that sending it back to a model provider is dangerous. He said Bedrock keeps prompts in the customer’s trusted environment and guarantees that customer data never leaves the customer’s EPC; it supports open and proprietary models, while customers can also use models outside Bedrock, including Gemini. He said some customers moving from proof of concept to production choose Bedrock for its data protections and service capabilities. Models can also help find vulnerabilities: AWS’s Continuum uses models and knowledge of customer environments to identify and prioritize them. Garman expects security to move toward machine-speed defense, while safe agent use still requires decisions about permissions, guardrails, and when people stay in the loop.

Agent-first work is changing AWS internally, though Garman said there is no settled organizational model for widespread agent use. Amazon Quick has been rolled out to every employee for building agents across business functions. In some frontier teams, agents write code while people manage the agents; work that once took teams weeks can sometimes take one person a couple of hours. AWS is experimenting with teams of three or four rather than around ten for some capabilities, because smaller teams can build faster. Garman said the company is still working out how to maintain what those teams build and move them between projects.