--- title: Cost Control Is Architecture, Not Discounts description: Savings Plans and Reserved Instances reduce the rate you pay. Architecture determines the volume you pay at. The most durable cost reductions in AWS come from designing systems that generate less spend, and negotiating a lower price for the same behavior does not achieve that. url: https://www.joinhorizon.co/blog/aws-cost-control-architecture-optimization-playbook/ datePublished: 2026-03-29T00:00:00.000Z dateModified: 2026-10-28T00:00:00.000Z author: kevin-w category: Cost Optimization & FinOps tags: cost-optimization, finops, aws, savings-plans, elasticache, trusted-advisor, architecture --- # Cost Control Is Architecture, Not Discounts > Savings Plans and Reserved Instances reduce the rate you pay. Architecture determines the volume you pay at. The most durable cost reductions in AWS come from designing systems that generate less spend, and negotiating a lower price for the same behavior does not achieve that. > **AWS lifecycle notice (June 30, 2026):** Amazon Q Business is in maintenance for new customers after **July 30, 2026**. Net-new evaluators should use [Amazon Quick Suite](https://www.joinhorizon.co/services/amazon-quick-suite/). Existing deployments remain supported. Full matrix: [lifecycle roundup](https://www.joinhorizon.co/blog/aws-service-lifecycle-updates-june-2026/). _Part 8 of 8: The AWS Cost Trap, or Why Your Bill Keeps Surprising You_ > **Series tooling (June 2026):** [Cost Explorer + Analyze with Amazon Q](https://www.joinhorizon.co/blog/aws-cost-explorer-budgets-monitoring-guide/) for human drill-down; [Cost Optimization Hub](https://www.joinhorizon.co/blog/aws-cost-optimization-hub-guide/) for prioritized backlog; [FinOps Agent (preview)](https://www.joinhorizon.co/blog/aws-finops-agent-preview-bedrock-cost-anomaly-2026/) for Slack/Jira delivery. When AWS bills exceed expectations, the most common first response is to look for discounts: purchase Reserved Instances, sign up for Savings Plans, negotiate an Enterprise Discount Program. These are valid tools. A one-year Compute Savings Plan can reduce EC2 costs by 30 to 40% compared to on-demand pricing. Reserved Instances for predictable workloads reduce costs further. But discounts reduce the rate you pay. They do not reduce the volume of resources you consume. A system that generates $100,000 per month in on-demand compute costs will cost $60,000 to $70,000 per month with a Savings Plan. That is still expensive, and still growing linearly with scale. The architectural patterns that generated $100,000 in compute costs are unchanged. As you grow, you will return to $100,000 and beyond, but now with a committed spend that cannot be reduced without forfeiting commitment fees. Durable cost reduction requires changing the architecture to reduce the volume of resources consumed, as well as the price per unit. The playbook is a set of structural patterns, each targeting a specific cost driver identified in the previous posts in this series. ## Reduce Cross-AZ Chatter Inter-Availability Zone data transfer is charged per GB in both directions. In microservices architectures, east-west traffic between services in different AZs generates continuous transfer charges. The fix is architectural: locality-aware routing. **AZ affinity in ECS.** When ECS tasks call other ECS services, configure the AWS Cloud Map service discovery or the Application Load Balancer to prefer targets in the same AZ as the calling task. ECS Service Connect supports traffic routing with AZ awareness. The goal is that a task in us-east-1a calls other tasks in us-east-1a rather than tasks in us-east-1b or us-east-1c. **Topology-aware routing in Kubernetes.** EKS (Kubernetes 1.21+) supports topology-aware routing via the `service.kubernetes.io/topology-mode: Auto` annotation on Services. When enabled, kube-proxy prefers endpoints in the same zone as the calling pod. This reduces cross-AZ service-mesh traffic without changing application code. **Placement groups for tightly coupled EC2.** A cluster placement group ensures that EC2 instances are placed on hardware within the same availability zone and as close together as possible. For workloads with high-bandwidth, low-latency requirements between a fixed set of instances (HPC, distributed databases, large in-memory caches), placement groups both reduce cross-AZ transfer charges and improve performance. **The tradeoff:** AZ affinity reduces resilience. A system that strictly routes traffic within AZ will experience degraded capacity if that AZ has an outage. The correct design is a soft preference (prefer same-AZ, but fall back to cross-AZ) rather than strict locality that creates a single-AZ dependency. All the mechanisms above support soft preferences; use them that way. ## Eliminate Unnecessary NAT Gateway Traffic ![Architecture diagram of a private task reaching S3 through a gateway endpoint, with a dashed NAT Gateway path marked as the avoidable charge](../../assets/images/blog/aws-cost-control-architecture-optimization-playbook-endpoint.webp) _Figure: S3 and DynamoDB from a private subnet can use a gateway endpoint at no hourly charge. The dashed arrow is the same call leaving through NAT Gateway, which bills per gigabyte. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/aws-cost-control-architecture-optimization-playbook/nat-endpoint.drawio)._ As discussed in Part 2, NAT Gateway charges per GB processed. Any private subnet resource calling an AWS service through NAT Gateway is generating avoidable costs. VPC Endpoints route that traffic directly through the AWS network without NAT processing charges. **Gateway Endpoints (free):** - Amazon S3 - Amazon DynamoDB **Interface Endpoints (hourly + per-GB charge, but lower than NAT):** - AWS Secrets Manager - AWS Systems Manager (SSM) - Amazon ECR (container image pulls) - Amazon CloudWatch Logs - AWS STS - Amazon SQS - Amazon SNS **The decision rule:** for any AWS service your private-subnet resources call more than a few times per day, evaluate whether a VPC Endpoint reduces costs compared to NAT Gateway processing charges. For S3 and DynamoDB specifically, Gateway Endpoints are always the right choice: they are free, they improve performance, and they eliminate NAT Gateway processing on what are typically the highest-volume inter-service calls. **Audit your NAT Gateway traffic** by enabling CloudWatch metrics on your NAT Gateway (`BytesOutToDestination` grouped by destination) or by sampling VPC Flow Logs for a 24-hour period. The top destination addresses from private subnet sources will tell you which services are generating the most NAT traffic. Create VPC Endpoints for the AWS services in that top list. **VPC Lattice for service-to-service networking and lower transit costs** For microservices architectures with complex service-to-service communication, VPC Lattice (generally available since 2023) is worth evaluating as a replacement for multi-VPC Transit Gateway setups. Traditional approaches to cross-VPC service networking (Transit Gateway, VPC peering, or PrivateLink per service) each have fixed or per-GB costs that accumulate with service mesh complexity. VPC Lattice provides a managed application networking layer for service-to-service communication across VPCs and accounts. It handles routing, authentication, and observability at the application layer without requiring Transit Gateway attachments. For architectures where services in separate VPCs or accounts communicate frequently, VPC Lattice's pricing (per hour per service network + per GB processed) can be lower than Transit Gateway attachment costs plus data processing charges for the same traffic volume. The key comparison: Transit Gateway charges per attachment per hour plus per GB data processed. If you have 20 services across 4 VPCs, you have 4 Transit Gateway VPC attachments ($0.05/hour each = $144/month in attachment fees alone) plus data processing. VPC Lattice charges per service network hour plus per GB, and for service meshes with fewer than ~8 VPCs, the cost model is typically equivalent or lower with reduced operational complexity. ## Caching as a structural cost reducer Every cache hit is a request that did not reach the origin. Every request that does not reach the origin does not generate: - Origin compute cost (Lambda invocation, EC2 CPU) - Database read cost (DynamoDB RCU, RDS query) - S3 GET request cost - Network transfer from origin to cache to caller Caching reduces costs at every layer simultaneously, not just at the cached layer. That is why caching is the highest-return optimization in most architectures: a 90% cache hit rate eliminates 90% of origin resource consumption at all levels of the stack. **ElastiCache for database offload.** The most common and highest-ROI caching pattern: place ElastiCache (Redis or Memcached) in front of your primary database. Cache the results of expensive queries, the records of frequently accessed entities, and the session data for authenticated users. A database query that runs 10,000 times per hour and takes 10 ms each time can be reduced to 1,000 database queries and 9,000 ElastiCache cache hits, a 90% reduction in database load at a fraction of the database cost. ElastiCache itself has a cost: instance hours plus data transfer. For workloads where the database is a cost driver, ElastiCache almost always reduces total cost because ElastiCache instance costs are substantially lower than the equivalent RDS capacity required to handle peak load without caching. **Lambda response caching with API Gateway.** API Gateway supports response caching at the gateway level, with configurable TTLs per resource and method. For API endpoints that return data that changes infrequently (catalog data, configuration, reference data), gateway-level caching eliminates Lambda invocations for cached responses. The API Gateway cache has a per-hour cost based on cache size, but at moderate to high request rates, the Lambda cost savings exceed the cache cost within days. **CloudFront caching for everything edge-deliverable.** CloudFront should cache not just static assets but any API response that can be shared across users with the same request parameters. Product listings, category pages, search results for common queries, and pricing data are candidates for edge caching. Each cache hit from CloudFront edge does not reach your origin, does not invoke Lambda, does not consume DynamoDB reads, and does not traverse NAT Gateway. The cache-control headers on your origin responses determine whether CloudFront caches a response. An origin that returns `Cache-Control: no-cache` on all responses provides no benefit from being behind CloudFront (beyond DDoS protection and geographic distribution). Auditing your cache-control headers and maximizing cacheable TTLs for non-personalized content is one of the highest-leverage configuration changes for cost reduction. ## Batch vs. real-time processing ![Architecture diagram of S3 uploads triggering either one Lambda per object or one Lambda per time window](../../assets/images/blog/aws-cost-control-architecture-optimization-playbook-batch.webp) _Figure: the same uploads can invoke Lambda per object or once per window. Per object fits a seconds budget. A minutes or hours budget is the batch path, which cuts invocation and log overhead. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/aws-cost-control-architecture-optimization-playbook/batch-window.drawio)._ Many workloads process data in real-time that does not actually require real-time processing. The default architecture for data processing has shifted to streaming (Kinesis, Kafka, Lambda) because it is feasible, but feasibility does not imply cost efficiency. A real-time Lambda function triggered on every S3 upload, running for 5 seconds per invocation, costs differently than a batch Lambda function that processes 1,000 uploads together every 5 minutes. Both architectures process the same data. The real-time architecture generates 1,000 invocations per processing window. The batch architecture generates 1 invocation. At the same compute cost per second, the batch architecture is not necessarily cheaper (it processes the same total data volume), but it: - Reduces per-invocation overhead (start, end, initialization) by 1,000× - Reduces CloudWatch log lines by 1,000× - Reduces SQS or EventBridge event costs if those services trigger the Lambda - Enables larger-batch processing optimizations (file compaction, bulk database writes) **The batch vs. real-time decision framework:** - What is the maximum acceptable latency between data arrival and processing completion? - If the answer is "seconds," real-time processing is justified. - If the answer is "minutes" or "hours," batch processing is almost always cheaper and often simpler. For data analytics pipelines, ETL workloads, report generation, and notification systems with non-urgent delivery requirements, batch processing reduces cost substantially without degrading user experience. ## Rightsizing Rightsizing means using instances appropriately sized for your actual workload characteristics, which is more than using smaller ones. An oversized instance wastes money. An undersized instance creates performance problems that engineers respond to by scaling out (more instances) rather than scaling up (correctly sized instances), which often costs more than a single correctly sized instance would. **The rightsizing process:** 1. Collect CloudWatch utilization metrics for CPU, memory (requires CloudWatch Agent for EC2), network, and disk IO over a minimum 14-day period covering peak and off-peak patterns. 2. Identify the utilization at the 95th percentile, not the average or the maximum. The 95th percentile captures your sustained peak without being distorted by one-time spikes. 3. Target 60 to 70% utilization at the 95th percentile. This gives headroom for unexpected spikes without wasting capacity at average load. 4. Select the instance type that achieves 60 to 70% utilization at 95th percentile load. **AWS Compute Optimizer** performs this analysis automatically and provides recommendations with projected cost impact. For the 32-day lookback rollout order and performance-risk tiers, see [AWS Rightsizing with Compute Optimizer (2026)](https://www.joinhorizon.co/blog/aws-rightsizing-compute-optimizer-playbook-2026/). It uses actual CloudWatch metric data from your running instances, not generic benchmarks. The recommendations are not always correct, since they cannot account for application-specific behavior, but they are a useful starting point that surfaces clear over-provisioning. **Memory-optimized vs. compute-optimized vs. general-purpose:** The instance family matters as much as the size. A workload that is memory-constrained running on a compute-optimized instance is over-provisioned on CPU and under-provisioned on memory simultaneously. Matching the instance family to the workload bottleneck (memory, CPU, network, storage) is the first step in rightsizing, not the final one. ## When to use Savings Plans and Reserved Instances Savings Plans and Reserved Instances should be purchased after architectural optimization, not before. Purchasing a commitment for a system that will be significantly changed by cost optimization work locks you into spending on capacity that no longer matches your architecture. **The sequence:** 1. Architect to reduce volume (cross-AZ reduction, caching, batch/real-time trade-offs) 2. Right-size to reduce over-provisioning 3. Measure stable baseline compute after steps 1 and 2 4. Purchase Savings Plans or Reserved Instances to cover that stable baseline at a discount **Compute Savings Plans** are the most flexible commitment: they apply to any EC2 instance family, size, region, and OS, as well as Lambda and Fargate. They are the right starting point for most organizations because they provide flexibility if instance types change. **EC2 Instance Savings Plans** commit to a specific instance family in a specific region and provide a deeper discount than Compute Savings Plans. Use these when your instance type and region are stable and unlikely to change within the commitment period. **The coverage target:** aim for Savings Plans or Reserved Instances to cover 70 to 80% of your stable baseline compute. Leave 20 to 30% on on-demand pricing to absorb spikes and workload changes without forfeiting committed spend. An account with 100% committed spend has no flexibility for growth or architectural changes. ## AWS Trusted Advisor as a starting point AWS Trusted Advisor (Business and Enterprise Support tiers) provides automated checks across cost, performance, security, and fault tolerance. The cost checks that provide the most value: - **Idle EC2 instances**: instances with less than 10% average daily CPU and minimal network activity over 14 days - **Underutilized EBS volumes**: volumes with less than 1 IOPS average over 7 days - **Idle RDS DB instances**: RDS instances with no connections over the past 7 days - **Savings Plans and Reserved Instance coverage**: what fraction of your usage is covered by commitments Trusted Advisor is not a complete FinOps solution; it surfaces obvious inefficiencies, not architectural patterns. But it provides a regular automated scan that catches the clearest zombie resources and over-provisioning without requiring manual audit work. For accounts without Business Support+ (the post-2025-12-02 replacement for Business Support), **AWS Cost Explorer Rightsizing Recommendations** (available to all accounts) and **AWS Compute Optimizer** (free) provide similar functionality for EC2 and ECS without the Trusted Advisor subscription requirement. ## Rightsizing and recommendation routing (June 2026) Three AWS surfaces overlap, so use each for what it does best: | Surface | Scope | When to use | | ----------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------------------------- | | **Cost Explorer rightsizing** | EC2 instances | Free first pass on underutilized compute | | **Compute Optimizer** | EC2, ASG, RDS, EBS, Lambda, ECS | Deeper metrics; **32-day lookback** (June 2026, free) for EBS/ECS with month-end or weekly spikes | | **Cost Optimization Hub** | All of the above + Trusted Advisor idle checks | Single prioritized backlog across the org | **Delivery to engineering:** **FinOps Agent (preview)** rolls COH recommendations into Jira tickets and auto-investigates anomaly events. **Analyze with Amazon Q** explains whatever Cost Explorer view a human has open during weekly reviews. Neither replaces the architectural patterns in this playbook; they operationalize the backlog those patterns create. ## Design for cost from day one Across all eight posts in this series, the common point is that cost is an emergent property of your architecture, not a billing artifact you optimize after the fact. Every architectural decision has a cost dimension: - Synchronous vs. asynchronous communication: latency vs. cost - Microservices vs. modular monolith: operational flexibility vs. inter-service data transfer cost - Multi-AZ distribution: resilience vs. cross-AZ transfer cost - Real-time vs. batch processing: latency vs. invocation overhead - High-cardinality metrics vs. structured logs: observability granularity vs. CloudWatch cost None of these trade-offs has a universally correct answer. The right answer depends on your workload, your scale, your latency requirements, and your cost targets. What matters is that the trade-off is explicit and made with awareness of the cost dimension, rather than implicit, where you discover the cost only when the bill arrives. The organizations that manage AWS costs effectively are not the ones with the best Savings Plan coverage. They are the ones where cost awareness is embedded in the engineering culture: in architecture reviews, in PR checklists, in sprint retrospectives, and in the operational dashboards that engineers look at every day. Cost control is an engineering function informed by FinOps data, not a FinOps function. The people who can change costs are engineers: finance can report on costs, and engineers can design them down. --- **Related reading:** [AWS Cost Optimization Strategies Most Teams Overlook](https://www.joinhorizon.co/blog/5-aws-cost-optimization-strategies-most-teams-overlook/) is a quick tactical companion to this post, covering right-sizing, lifecycle policies, and anomaly detection in a faster format. [AWS ElastiCache: Redis Caching Strategies for Production](https://www.joinhorizon.co/blog/aws-elasticache-redis-caching-strategies-for-production/) covers ElastiCache architecture and cache invalidation strategy in operational depth. For Savings Plans and Reserved Instance monitoring workflow, see [AWS Cost Explorer and Budgets: A Cloud Cost Management Guide](https://www.joinhorizon.co/blog/aws-cost-explorer-budgets-monitoring-guide/). --- **The AWS Cost Trap: Full Series** [Part 1 — Billing Complexity as a System Problem](https://www.joinhorizon.co/blog/aws-pricing-emergent-behavior-billing-complexity/) · [Part 2 — Data Transfer Costs](https://www.joinhorizon.co/blog/aws-data-transfer-costs-startups/) · [Part 3 — Autoscaling + AI Workloads](https://www.joinhorizon.co/blog/aws-autoscaling-ai-workloads-budget-overrun/) · [Part 4 — Observability & Logging Costs](https://www.joinhorizon.co/blog/aws-cloudwatch-logging-costs-observability/) · [Part 5 — S3 Storage Cost Traps](https://www.joinhorizon.co/blog/aws-s3-storage-costs-not-cheap/) · [Part 6 — The FinOps Gap](https://www.joinhorizon.co/blog/aws-finops-gap-engineering-cost-ownership/) · [Part 7 — Real Failure Patterns](https://www.joinhorizon.co/blog/aws-startup-cost-explosion-real-failure-patterns/) · [Part 8 — Optimization Playbook](https://www.joinhorizon.co/blog/aws-cost-control-architecture-optimization-playbook/) --- _This concludes The AWS Cost Trap series. We covered billing complexity as a system property (Part 1), data transfer patterns that break budgets (Part 2), autoscaling feedback loops (Part 3), observability cost anti-patterns (Part 4), S3 usage traps (Part 5), the FinOps organizational gap (Part 6), real failure patterns (Part 7), and the architectural playbook for durable cost reduction (Part 8)._ _If you are working through these patterns in your own AWS environment and want a structured review, [contact the FactualMinds team](https://www.joinhorizon.co/contact-us/). As an AWS Select Tier Services Partner specializing in cloud cost optimization and architecture, we run cost audits that identify the specific patterns from this series in your account, with prioritized recommendations ranked by cost impact._ ## Related reading - [AWS Bill Teardown #1: The SaaS Startup Paying $40k/Month for $8k of Workloads](https://www.joinhorizon.co/blog/aws-bill-teardown-1-saas-startup-40k-month-overrun/) - [AWS Bill Teardown #2: How a Healthcare Company Spent $200k/Year on NAT Gateways](https://www.joinhorizon.co/blog/aws-bill-teardown-2-healthcare-nat-gateway-problem/) - [Designing AWS Architectures with Predictable, Stable Costs](https://www.joinhorizon.co/blog/aws-cost-stable-architecture-design/) - [AWS Managed Services Provider vs DIY: Total Cost of Ownership](https://www.joinhorizon.co/blog/aws-managed-services-vs-diy-total-cost-of-ownership/) - [AWS Retail Competency: What It Is and Why It Matters When Choosing a Cloud Partner](https://www.joinhorizon.co/blog/aws-retail-competency-what-it-means-for-your-business/) - [AWS Service Announcements Worth Knowing: March 2026 Edition](https://www.joinhorizon.co/blog/aws-service-announcements-march-2026/) - [AWS Service Announcements: May 2026 Roundup](https://www.joinhorizon.co/blog/aws-service-announcements-may-2026/) - [AWS Service Announcements: June 2026 Roundup](https://www.joinhorizon.co/blog/aws-service-announcements-june-2026/) - [Amazon SES for eCommerce: Scaling Promotional and Transactional Email That Actually Reaches the Inbox](https://www.joinhorizon.co/blog/aws-ses-ecommerce-email-marketing/) - [How to Migrate from SendGrid to Amazon SES (Step-by-Step)](https://www.joinhorizon.co/blog/how-to-migrate-from-sendgrid-to-amazon-ses/) - [How to Prevent Queue-Based Cost Explosions on AWS](https://www.joinhorizon.co/blog/prevent-queue-cost-explosions-aws/) - [10 AWS Cloud Security Best Practices: An Implementation Guide for 2026](https://www.joinhorizon.co/blog/10-aws-cloud-security-best-practices-implementation-guide/) - [7 Signs You Need an AWS Migration Strategy Partner](https://www.joinhorizon.co/blog/7-signs-you-need-an-aws-cloud-migration-partner/) - [Amazon Aurora Limitless Database: Horizontal SQL Scaling Without Application Rewrites](https://www.joinhorizon.co/blog/amazon-aurora-limitless-database/) - [Amazon Bedrock Automated Reasoning Checks: Production Hallucination Prevention with Math-Validated Factuality](https://www.joinhorizon.co/blog/amazon-bedrock-automated-reasoning-checks-hallucination-prevention/) - [Amazon Bedrock Data Automation: Intelligent Document and Media Processing at Scale](https://www.joinhorizon.co/blog/amazon-bedrock-data-automation/) - [Amazon Bedrock Marketplace: Enterprise Guide to Third-Party Foundation Models](https://www.joinhorizon.co/blog/amazon-bedrock-marketplace-third-party-models/) - [Amazon Bedrock Now Offers OpenAI Models, Codex, and Managed Agents: What It Means for Enterprise AI](https://www.joinhorizon.co/blog/amazon-bedrock-openai-models-codex-managed-agents/) - [Amazon Elastic VMware Service: Migrating VMware Workloads to AWS Without Re-Architecting](https://www.joinhorizon.co/blog/amazon-elastic-vmware-service-evs/) - [Amazon MemoryDB with Vector Search: Durable Redis-Compatible Storage for AI Workloads](https://www.joinhorizon.co/blog/amazon-memorydb-vector-search/) - [Amazon Neptune Analytics: Graph and Vector Analytics for Fraud Detection and Recommendations](https://www.joinhorizon.co/blog/amazon-neptune-analytics-graph-vector/) - [Amazon Nova Canvas and Reel: Enterprise Multimodal Content Generation on AWS](https://www.joinhorizon.co/blog/amazon-nova-canvas-reel-multimodal/) - [Amazon Q for Business vs ChatGPT Enterprise: A CTO](https://www.joinhorizon.co/blog/amazon-q-for-business-vs-chatgpt-enterprise-cto-guide/) - [Amazon Q in QuickSight: Building Natural-Language BI for Enterprise Data Teams](https://www.joinhorizon.co/blog/amazon-q-quicksight-generative-bi/) - [Amazon Q vs GitHub Copilot 2026: Developer Tools Comparison](https://www.joinhorizon.co/blog/amazon-q-vs-github-copilot-2026/) - [Amazon QuickSight Embedding: Adding Analytics to Your SaaS Application](https://www.joinhorizon.co/blog/amazon-quicksight-embedding-analytics-saas-applications/) - [Amazon QuickSight in Production: A Practical Guide for BI Teams](https://www.joinhorizon.co/blog/amazon-quicksight-production-guide-best-practices/) - [Amazon SageMaker Unified Studio: Migrating from Studio Classic to the Unified ML Platform](https://www.joinhorizon.co/blog/amazon-sagemaker-unified-studio/) - [Amazon Verified Permissions: Fine-Grained Authorization with Cedar for SaaS Applications](https://www.joinhorizon.co/blog/amazon-verified-permissions-cedar/) - [24/7 AWS Managed Support: What to Expect from a Monitoring Partner](https://www.joinhorizon.co/blog/aws-24-7-managed-support-monitoring/) - [AWS Agent Toolkit for AWS: Plugins, Rules, and Every Skill Explained](https://www.joinhorizon.co/blog/aws-agent-toolkit-for-aws-skills-guide/) - [AWS API Gateway Patterns: REST, HTTP, and WebSocket APIs](https://www.joinhorizon.co/blog/aws-api-gateway-patterns-rest-http-websocket/) - [AWS Application Composer: AI-Assisted Infrastructure Code Generation in 2026](https://www.joinhorizon.co/blog/aws-application-composer-iac-generator/) - [AWS Application Modernization: When to Refactor, Replatform, or Rearchitect](https://www.joinhorizon.co/blog/aws-application-modernization-refactor-replatform-rearchitect/) - [AWS Application Modernization ROI: How to Build the Business Case for Your Board](https://www.joinhorizon.co/blog/aws-application-modernization-roi-business-case/) - [AWS Backup Strategies: Automated Data Protection](https://www.joinhorizon.co/blog/aws-backup-strategies-automated-data-protection/) - [How to Implement AWS Bedrock Multi-Agent Supervisor Pattern in Production](https://www.joinhorizon.co/blog/aws-bedrock-multi-agent-supervisor-pattern/) - [Bedrock Provisioned Throughput vs On-Demand: Break-Even Math for Production Workloads (2026)](https://www.joinhorizon.co/blog/aws-bedrock-provisioned-throughput-vs-on-demand-break-even-2026/) - [AWS Bill Teardown #3: The Data Transfer Trap That Costs Retailers Every Holiday Season](https://www.joinhorizon.co/blog/aws-bill-teardown-3-retail-data-transfer-trap/) - [AWS Bill Teardown #4: Multi-Account Commitment Leakage](https://www.joinhorizon.co/blog/aws-bill-teardown-4-multi-account-commitment-leakage/) - [Blue/Green vs Canary on AWS (2026): ECS, Lambda, and When Rolling Is Enough](https://www.joinhorizon.co/blog/aws-blue-green-vs-canary-deployment-decision-guide-2026/) - [CI/CD Threat Models and Web App Security on AWS: Pipelines, XSS, CSRF, and SQL Injection](https://www.joinhorizon.co/blog/aws-cicd-appsec-pipeline-threat-model/) - [AWS Clean Rooms: Privacy-Preserving Collaborative Analytics Without Sharing Raw Data](https://www.joinhorizon.co/blog/aws-clean-rooms-privacy-analytics/) - [AWS Cloud Adoption Framework (CAF) in Practice: MAP, Landing Zones, and Well-Architected](https://www.joinhorizon.co/blog/aws-cloud-adoption-framework-practice-map-well-architected/) - [What Makes a Top AWS Cloud Consulting Partner (And How to Choose One)](https://www.joinhorizon.co/blog/aws-cloud-consulting-partner-how-to-choose/) - [Cloud Exit and Reversibility on AWS (2026): Egress, Portability, and the Contract Clauses Procurement Actually Asks For](https://www.joinhorizon.co/blog/aws-cloud-exit-reversibility-strategy-2026/) - [AWS Cloud Migration Readiness Assessment: The 47-Point Checklist for MAP and Your Business Case](https://www.joinhorizon.co/blog/aws-cloud-migration-readiness-assessment-checklist/) - [AWS CloudFront vs Cloudflare: Which CDN for Your Enterprise?](https://www.joinhorizon.co/blog/aws-cloudfront-vs-cloudflare-which-cdn-for-your-enterprise/) - [AWS Cognito Authentication for SaaS Applications](https://www.joinhorizon.co/blog/aws-cognito-authentication-for-saas-applications/) - [AWS Cost Prediction in 2026: The Playbook for Accurate Forecasting](https://www.joinhorizon.co/blog/aws-cost-prediction-2026-playbook/) - [Distributed Data on AWS: Transactions, Aurora Failover Behavior, DynamoDB Partitions, and Shard-Like Aurora Limitless](https://www.joinhorizon.co/blog/aws-data-transactions-partitioning-at-scale/) - [AWS EBS Encryption and Snapshot Hygiene: Default Encryption, Public Snapshot Prevention, and KMS Key Lifecycle](https://www.joinhorizon.co/blog/aws-ebs-encryption-snapshot-hygiene-kms-lifecycle/) - [How to Eliminate AWS Surprise Bills From Autoscaling](https://www.joinhorizon.co/blog/aws-eliminate-surprise-bills-autoscaling/) - [AWS Graviton: The Complete Cost Optimization Guide for Production Workloads](https://www.joinhorizon.co/blog/aws-graviton-cost-optimization-guide/) - [HTTP vs WebSockets, API Gateway Stages, and Versioning Strategies That Survive Deprecation](https://www.joinhorizon.co/blog/aws-http-websocket-api-versioning/) - [AWS IAM Identity Center: Workforce SSO and Identity Propagation in Production](https://www.joinhorizon.co/blog/aws-iam-identity-center-workforce-sso-identity-propagation/) - [Ingress, Load Balancing, and Elastic Scale on AWS: L4 vs L7, Horizontal vs Vertical, and the Cold-Start Bill](https://www.joinhorizon.co/blog/aws-ingress-scale-and-cold-start/) - [AWS IoT Core for Industrial MQTT: Architecture and Scaling Patterns](https://www.joinhorizon.co/blog/aws-iot-core-mqtt-industrial-workloads/) - [AWS KMS Post-Quantum Cryptography: ML-KEM Hybrid TLS and ML-DSA Signatures in Production](https://www.joinhorizon.co/blog/aws-kms-post-quantum-cryptography-ml-kem-ml-dsa/) - [AWS MCP Server Hits GA: What It Changes for Agentic Development (Plus the Serverless Agent Plugin)](https://www.joinhorizon.co/blog/aws-mcp-server-ga-agent-toolkit-serverless-plugin/) - [AWS Network Firewall + Firewall Manager: Multi-Account Stateful L3-L7 Defense in Production](https://www.joinhorizon.co/blog/aws-network-firewall-firewall-manager-multi-account/) - [Post-Migration Optimization and the FinOps Handoff (2026): The First 30 Days After Cutover Decide Your Run-Rate](https://www.joinhorizon.co/blog/aws-post-migration-optimization-finops-handoff-2026/) - [Building Real-Time Analytics Dashboards with AWS QuickSight](https://www.joinhorizon.co/blog/aws-quicksight-real-time-analytics-dashboards-guide/) - [AWS RDS Performance and Caching: IOPS, Query Tuning, and Application-Layer Cache Patterns](https://www.joinhorizon.co/blog/aws-rds-database-performance-best-practices/) - [AWS Route 53: DNS and Traffic Management Patterns](https://www.joinhorizon.co/blog/aws-route-53-dns-traffic-management-patterns/) - [AWS Trainium2 and Inferentia2: Purpose-Built AI Chips for Enterprise ML Cost Reduction](https://www.joinhorizon.co/blog/aws-trainium2-inferentia2-ai-chips/) - [AWS Verified Access in Production: A Zero-Trust Network Access (ZTNA) Replacement for Legacy VPN](https://www.joinhorizon.co/blog/aws-verified-access-ztna-zero-trust-network/) - [building-a-data-lake-on-aws-s3-glue-athena-architecture](https://www.joinhorizon.co/blog/building-a-data-lake-on-aws-s3-glue-athena-architecture/) - [Building Fintech Applications on AWS: Architecture Patterns](https://www.joinhorizon.co/blog/building-fintech-applications-on-aws-architecture-patterns/) - [Claude Fable 5 on AWS (June 2026): Mythos-Class Models, Safeguards, and What Changes for Bedrock Teams](https://www.joinhorizon.co/blog/claude-fable-5-aws-bedrock-mythos-class-guide-2026/) - [Cloud Cost Optimization in 2026: 8 Modern Strategies Beyond the Basics](https://www.joinhorizon.co/blog/cloud-cost-optimization-2026-modern-strategies/) - [Biggest Mistakes Teams Face During an AWS Migration (and How to Dodge Them)](https://www.joinhorizon.co/blog/common-aws-cloud-migration-mistakes-2026/) - [How to Build a Cost-Optimized SaaS Stack on AWS (End-to-End Reference)](https://www.joinhorizon.co/blog/cost-optimized-saas-stack-aws-end-to-end/) - [Designing a Customer-Facing SLA on AWS (2026): SLO Error Budgets and the Composite-Availability Math Most Teams Skip](https://www.joinhorizon.co/blog/customer-facing-sla-slo-design-aws/) - [EC2 Spot Instance Selection: A Data-Driven Approach to 60–90% Cost Reduction](https://www.joinhorizon.co/blog/ec2-spot-instance-intelligent-selection-cost-optimization/) - [EU AI Act on AWS: A Practical Compliance Guide for High-Risk AI on Bedrock and SageMaker](https://www.joinhorizon.co/blog/eu-ai-act-compliance-aws-bedrock-sagemaker/) - [Fine-Tuning vs RAG on AWS Bedrock: When to Use Each](https://www.joinhorizon.co/blog/fine-tuning-vs-rag-bedrock-when-to-use/) - [How to Run High-Scale Postgres on AWS Without Breaking the Bank](https://www.joinhorizon.co/blog/high-scale-postgres-aws-cost-optimization/) - [HIPAA-Compliant AI on AWS Bedrock: A Production Guide for Healthcare Workloads](https://www.joinhorizon.co/blog/hipaa-compliant-ai-aws-bedrock/) - [How to Achieve SOC 2 Type II Compliance on AWS (2026 Checklist)](https://www.joinhorizon.co/blog/how-to-achieve-soc2-compliance-aws-2026/) - [How to Evaluate an AWS Managed Services Provider: RFP Checklist](https://www.joinhorizon.co/blog/how-to-evaluate-aws-managed-services-provider/) - [How to Host n8n on AWS EKS: A Production-Ready Deployment Guide](https://www.joinhorizon.co/blog/how-to-host-n8n-on-aws-eks-production-guide/) - [How to Implement Blue/Green Deployments on ECS with CodeDeploy](https://www.joinhorizon.co/blog/how-to-implement-blue-green-deployments-ecs-codedeploy/) - [How to Migrate a Monolith to ECS Fargate Without Downtime](https://www.joinhorizon.co/blog/how-to-migrate-monolith-ecs-fargate-zero-downtime/) - [How to Build Hybrid Compute (EC2 + Serverless) for Cost Efficiency](https://www.joinhorizon.co/blog/hybrid-compute-ec2-serverless-cost-efficiency/) - [ISO 27001 Certification on AWS: ISMS Implementation Guide for 2026](https://www.joinhorizon.co/blog/iso-27001-certification-aws-isms-implementation/) - [Migrate from Terraform to OpenTofu: What AWS Teams Need to Know](https://www.joinhorizon.co/blog/migrate-terraform-opentofu-aws/) - [How to Design MongoDB for Scalable, Cost-Efficient Workloads on AWS](https://www.joinhorizon.co/blog/mongodb-scalable-cost-efficient-aws/) - [Multi-Cloud vs AWS-First (2026): A Buyer Decision Guide That Counts Requirements, Not Slogans](https://www.joinhorizon.co/blog/multi-cloud-vs-aws-first-decision-guide/) - [NIS2 Directive on AWS: A Practical Compliance Guide for EU Critical Infrastructure](https://www.joinhorizon.co/blog/nis2-directive-aws-critical-infrastructure/) - [How to Run Production Laravel, Django, and Node Apps on ECS (2026)](https://www.joinhorizon.co/blog/production-laravel-django-node-on-ecs-2026/) - [The Real Cost of Not Having 24/7 AWS Monitoring](https://www.joinhorizon.co/blog/real-cost-of-no-24-7-aws-monitoring/) - [Real-Time Data Pipelines on AWS: Kinesis Data Streams + Lambda + DynamoDB](https://www.joinhorizon.co/blog/real-time-data-pipeline-kinesis-lambda-dynamodb/) - [How to Use Redis and Valkey as a Cost-Saving Layer (Not Just Cache)](https://www.joinhorizon.co/blog/redis-valkey-cost-saving-layer-aws/) - [How to Build a Safe Terraform Apply Workflow on AWS: Approval Gates, Plan Review, and Rollback](https://www.joinhorizon.co/blog/safe-terraform-apply-workflows-approval-gates-aws/) - [How to Upgrade the AWS Terraform Provider Safely: Strategy, Testing, and Rollback](https://www.joinhorizon.co/blog/terraform-aws-provider-upgrade-strategy/) - [Terraform + Claude Skills on AWS: A Production Walkthrough (and 5 Things It Still Won](https://www.joinhorizon.co/blog/terraform-claude-skill-aws-production-guide/) - [What Does an AWS Managed Services Partner Actually Do? (And What They Don](https://www.joinhorizon.co/blog/what-does-aws-msp-actually-do/) - [Do You Need an AWS Managed Services Provider? 10 Signs It](https://www.joinhorizon.co/blog/when-do-you-need-aws-managed-services-provider/) - [When to Hire an AWS Consultant: 12 Business Triggers That Signal It](https://www.joinhorizon.co/blog/when-to-hire-aws-consultant-business-triggers/) - [Amazon Bedrock AgentCore Pricing: The 12 Components Behind Your Agent Bill](https://www.joinhorizon.co/blog/amazon-bedrock-agentcore-pricing-12-components/) - [Kubecost on EKS: From Cost Visibility to Actual Savings](https://www.joinhorizon.co/blog/kubecost-eks-optimization/) - [ProsperOps on AWS: Automation vs Commitment Strategy](https://www.joinhorizon.co/blog/prosperops-aws-savings-plans/) ## FAQ ### Should I buy AWS Savings Plans or Reserved Instances first? Neither at first. Optimize architecture to reduce volume consumed, then right-size to eliminate over-provisioning, then measure your stable baseline compute over 30+ days, then purchase commitments to cover 70 to 80% of that baseline. Purchasing commitments before architectural optimization locks you into spending on capacity that may no longer match your architecture after cost reduction work. Compute Savings Plans are the right starting point for most organizations because they apply across instance families, regions, and sizes, providing flexibility if your infrastructure evolves during the commitment period. ### What is rightsizing in AWS and how do I do it correctly? Rightsizing is selecting instances appropriately sized for your actual workload, which is more than using smaller instances. The process: collect CloudWatch CPU, memory (requires CloudWatch Agent), network, and disk IO metrics over 14+ days covering peak and off-peak. Identify utilization at the 95th percentile (not average, not maximum). Target 60 to 70% utilization at 95th percentile to provide spike headroom without wasting capacity at average load. Use AWS Compute Optimizer for automated recommendations based on your actual metric data. Match the instance family to the actual bottleneck: a memory-constrained workload on a compute-optimized instance is simultaneously over-provisioned on CPU and under-provisioned on memory. ### When is batch processing cheaper than real-time processing on AWS? Batch processing is cheaper when: maximum acceptable latency is minutes or hours (not seconds); objects can be compacted before processing; downstream writes can be batched (bulk DynamoDB writes cost less than single-item writes); and Lambda initialization overhead is a significant fraction of total execution time. A real-time Lambda triggered on every S3 upload pays per-invocation overhead (start, end, initialization, CloudWatch log lines) for each individual object. A batch Lambda processing 1,000 objects together pays that overhead once. For data analytics, ETL, and non-urgent notifications, batch processing typically reduces costs by 60 to 90% versus equivalent real-time architectures. ### How do VPC Endpoints reduce AWS costs? VPC Endpoints route AWS service API calls (S3, DynamoDB, Secrets Manager, ECR, CloudWatch Logs, SQS, etc.) directly through the AWS private network, bypassing NAT Gateway. Gateway Endpoints for S3 and DynamoDB are completely free. Interface Endpoints for other services charge an hourly fee and a per-GB data processing fee lower than NAT Gateway rates. Any private-subnet resource calling AWS services through NAT Gateway without VPC Endpoints is paying NAT data processing charges on every API call. For clusters with high API call volumes to DynamoDB, S3, or ECR, the savings from Gateway Endpoints alone frequently justify the one-time configuration effort. --- *Source: https://www.joinhorizon.co/blog/aws-cost-control-architecture-optimization-playbook/*