The default MCP deployment buys a Kubernetes operational surface for request/response traffic

Take the rate limit first, since it is the one recommendation in the dev.to post with numbers attached. It asks for a burst of 20 and a sustained 10 requests per second on the gateway in front of the MCP server ^[12]. It says an agent stuck in a loop hits that ceiling four seconds into a session ^[13]. For the loop to trip at four seconds, it has to be calling faster than ten times a second. On a bucket refilling at the sustained rate, roughly 60 calls get through in that window: 20 from the burst allowance plus 10 a second for four seconds ^[19]. The other way to learn about the loop is the invoice, about a month later ^[10].

Choosing between the two AgentCore pieces is a question about which problem you have. Ten internal APIs that need to look like one governed MCP endpoint is a Gateway job, and Gateway fronts what already runs without hosting anything new ^[7]. Not wanting to manage containers for your own server code is a Runtime job ^[6]. The post says the pair is easy to mix up on a first read, and that the naming gets muddled in most blog posts written about it ^[8].

For the managed path to be the cheaper first try, your tool calls have to fit compute the post describes as mostly request/response with an occasional long-running call in the middle ^[3]. That occasional long call is the part serverless hosting either accommodates or does not, and the post does not include cost figures, latency numbers or Runtime execution limits for either option ^[20]. The case against ECS and EKS is argued on operating surface: autoscaling tuned for traffic with no predictable pattern, plus IAM role assumption per agent session ^[2].

Write access changes what a scoping mistake costs. A wrong read produces bad output; a wrong write modifies infrastructure ^[15]. The post's rule is one role per tool rather than one per agent. Reuse a role across five tools to save setup time and the tool that queries a single table gets a path to S3 and security groups ^[16]. Cognito goes in front of the endpoint before any of that fires ^[17]. A guardrail layer, Bedrock Guardrails or an equivalent, sits between the model and anything sensitive, and the post names prompt injection aimed at leaking data or pushing an unauthorized change as the case it is there for ^[18].

Per-service tags cannot say which customer or which run spent the money, so the post wants tags at the session or tenant level, with cost per agent decision as the unit ^[11]. X-Ray and CloudWatch return latency numbers and error rates, neither of which explains why the agent called tool B right after tool A ^[14]. And the reason to put the whole thing in Terraform is the question you get six months out, once whoever set it up has moved teams. Which IAM role got attached to which agent in which environment ^[9].