# AGENTOPS03-BP03 Implement agent-specific scaling policies and capacity planning
Scaling policies designed for typical web workloads don't fit agents. Model inference latency, tool dependency availability, and downstream service capacity all shape the right response to load, and a policy that ignores them either over-provisions during quiet hours or under-provisions during peaks.
**Desired outcome:**
+ Agent compute scales dynamically in response to demand while respecting cost, performance, and governance constraints.
+ Scaling decisions account for agent-specific factors: model inference latency, tool availability, and downstream service capacity.
+ Per-environment scaling boundaries help prevent runaway scaling in development while preserving capacity headroom in production.
+ Monthly capacity reviews keep deployments right-sized as usage patterns evolve.
**Common anti-patterns:**
+ Using identical scaling configurations across all environments, either over-provisioning development or under-provisioning production during traffic spikes.
+ Scaling based solely on CPU and memory utilization without considering agent-specific metrics like request queue depth or inference latency, missing the real bottleneck.
+ Setting scaling policies once at deployment and never revisiting them as usage patterns evolve.
+ Treating capacity planning as a quarterly finance exercise rather than an ongoing operational one, so policies fall out of step with reality.
**Benefits of establishing this best practice:**
+ Scaling policies adapt to deployment context and agent compute model, keeping capacity appropriate as workloads move from prototype to production scale.
+ Per-environment boundaries and centralized configuration make scaling behavior consistent, auditable, and governed across environments.
+ Monthly reviews catch drift between configured capacity and actual usage patterns before it becomes a cost or latency problem.
+ Agent-specific scaling metrics expose the real bottleneck, often downstream service capacity or model throttling, that generic metrics hide.
**Level of risk exposed if this best practice is not established:** Medium
## Implementation guidance
[Amazon Bedrock AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html) handles the scaling question for most teams through its built-in consumption-based scaling and pricing model. AgentCore Runtime allocates compute automatically based on demand, so custom scaling policies are not required. For agents deployed outside AgentCore Runtime, on [AWS Lambda](https://aws.amazon.com/lambda/) or [Amazon ECS](https://aws.amazon.com/ecs/) for example, scaling triggers must be configured against agent-specific signals: request queue depth, average response latency, and concurrent invocation count. CPU and memory alone miss the mark because agents often wait on model inference or downstream tools rather than saturating local compute.
Configure environment-appropriate maximums to control cost in development and maintain performance in production. Development can run with permissive minimums and tight maximums. Cost is the first consideration, so the policy should expect spikes and throttle them. In production, maximums should be generous enough to absorb traffic bursts without latency degradation, and minimums should hold enough warm capacity to avoid cold starts during demand ramps. Staging is the midpoint between development and production, so maximums and minimums should match that as well.
Store scaling configurations centrally (like in a parameter store integrated with the agent registry) so boundaries adjust automatically when an agent transitions between lifecycle stages. A configuration store also gives the team a single place to audit and adjust policies, instead of chasing them through individual service consoles.
The operations team should perform monthly reviews, analyzing scaling event history, peak utilization patterns, and capacity headroom across the portfolio using [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) metrics. The outputs are concrete:
+ Agents to scale down
+ Agents to increase ceilings for
+ Demand forecasts for the upcoming period
Without this review, scaling policies drift from the workload they were tuned against. For fleet-level operational visibility including dashboards, anomaly detection, and behavioral monitoring, see [AGENTOPS05-BP05 Create workflow-specific dashboards for operational health](agentops05-bp05.html).
### Implementation steps
1. **Choose the right scaling foundation:** Deploy agents on [Amazon Bedrock AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html) for built-in scaling, or configure auto scaling policies with agent-specific metrics for non-Runtime deployments.
1. **Set per-environment boundaries:** Use permissive policies for development, moderate for staging, and production with higher minimums to absorb traffic spikes.
1. **Centralize scaling configurations:** Store policies in a parameter store integrated with the agent registry so boundaries adjust as agents transition between lifecycle stages.
1. **Review capacity monthly:** Analyze scaling events, peak utilization, and capacity headroom in [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) to right-size deployments and forecast demand.
## Resources
**Related best practices:**
+ [AGENTOPS03-BP01 Define an agent lifecycle with clear SME ownership, testing, and governance](agentops03-bp01.html)
+ [AGENTOPS03-BP02 Implement CI/CD pipelines tailored to agentic system deployment (AgentOps)](agentops03-bp02.html)
+ [AGENTOPS02-BP02 Implement configuration drift detection and remediation](agentops02-bp02.html)
+ [AGENTOPS05-BP04 Define and track KPIs for agent workflows](agentops05-bp04.html)
**Related documents:**
+ [Operationalizing agentic AI on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-operationalizing-agentic-ai/introduction.html)
+ [Preparing the business for agentic AI at scale](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-operationalizing-agentic-ai/preparing-business.html)
+ [Introducing Amazon Bedrock AgentCore: Securely deploy and operate AI agents at any scale](https://aws.amazon.com/blogs/aws/introducing-amazon-bedrock-agentcore-securely-deploy-and-operate-ai-agents-at-any-scale/)
+ [Securely launch and scale your agents and tools on Amazon Bedrock AgentCore Runtime](https://aws.amazon.com/blogs/machine-learning/securely-launch-and-scale-your-agents-and-tools-on-amazon-bedrock-agentcore-runtime/)
**Related videos:**
+ [AWS 2025 - AgentCore Deep Dive: Runtime](https://www.youtube.com/watch?v=wizEw5a4gvM)
**Related services:**
+ [Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)