cost-optimized-architectures on Alperen Doc

pricing-models-ri-savings-plans-spot

Mon, 01 Jan 0001 00:00:00 +0000

Pricing Models: On-Demand, RIs (Reserved Instance), Savings Plans and Spot#

Almost every cost question is a matching game: workload pattern → purchase option. Get these five into your head and half of Domain 4 is free.

The options#

Option	Discount	Commitment	Best for
On-Demand	0%	None	Spiky, unknown, short-lived workloads
Savings Plans (Compute / EC2 (Elastic Compute Cloud) Instance / SageMaker)	up to 72%	1 or 3 years, $/hour commitment	Steady usage, want flexibility
Reserved Instances (Standard / Convertible)	up to 72%	1 or 3 years, specific instance family	Very steady, known capacity
Spot Instances	up to 90%	None - can be reclaimed (2-min notice)	Fault-tolerant, interruptible work
Dedicated Hosts / Instances	0% (premium)	None/1-3y	Licensing, compliance, single-tenant

Savings Plans vs Reserved Instances (a favorite comparison)#

Savings Plans = commit to $X/hour of compute; covers any instance family, region (Compute SP (Savings Plan)), Fargate and Lambda too. More flexible → usually the better answer
Reserved Instances = commit to a specific instance type/region; can be standard (most discount, resellable) or convertible (less discount, can change family/OS); zonal RI also reserves capacity in an AZ (Availability Zone)
Scheduled RIs = recurring time windows (rarely tested)

Not: “surekli calisan ve tahmin edilebilir is yuk” = Savings Plans (esnek oldugu icin RI’ye tercih edilir). “Kesintiye dayanikli toplu is / ML egitim / test ortami” = Spot. “Windows/SQL lisansi bizim” = Dedicated Host.

s3-cost-and-lifecycle-policies

Mon, 01 Jan 0001 00:00:00 +0000

S3 (Simple Storage Service) Cost Optimization and Lifecycle Policies#

S3 cost questions are really about storage class transitions and data transfer - the two levers that move the bill the most.

Lifecycle policies - the main tool#

Two rule types:

Transition - move objects to cheaper classes over time (e.g. Standard → IA after 30 days → Glacier Instant after 90)
Expiration - delete objects/versions after N days

Example flow for a log bucket:

cost-management-tools

Mon, 01 Jan 0001 00:00:00 +0000

Cost Management Tools#

“Which tool should the company use to see/track/limit spending?” - the answer is one of a small set of billing tools. Learn what each one uniquely does.

The lineup#

Tool	What it’s for	Scenario keyword
Cost Explorer	Visualize & forecast costs, RI (Reserved Instance)/SP (Savings Plan) utilization & coverage	“why did costs rise”, “should we buy RIs”
Cost & Usage Report (CUR)	Most granular billing data (hourly, resource-level)	“detailed analysis in Athena/QuickSight”
Budgets	Alert and act at thresholds	“notify me at 80% of budget”, “stop resources”
Cost Anomaly Detection	ML-based unusual-spend alerts	“sudden unexpected spike”
Pricing Calculator	Estimate costs before building	“what will this architecture cost”
Trusted Advisor	Best-practice checks: cost, security, performance, fault tolerance, service limits	“find idle resources, unattached EBS (Elastic Block Store)”
Compute Optimizer	Right-size recommendations	“is this instance too big”
AWS Budgets + Billing Alarms	Classic proactive control	CloudWatch alarm on estimated charges

Details worth knowing#

Cost Explorer: 12 months history default, forecasting up to 12 months, save custom views; RI/SP utilization reports answer “are we wasting our commitment”
CUR is the only source with full resource-level detail → analyze with Athena, visualize with QuickSight
Budgets can trigger actions (e.g. apply an IAM (Identity and Access Management) policy via Service Catalog to stop non-prod); alert types: actual, forecasted, and planned (RI/SP)
Trusted Advisor full checks require Business/Enterprise support; the “cost” category finds idle ELBs (Elastic Load Balancing), unassociated Elastic IPs, low-utilization instances
Compute Optimizer analyzes CloudWatch metrics and recommends right-sized instances (needs opt-in)

flowchart LR
 usage[AWS usage] --> ce[Cost Explorer: what happened?]
 usage --> cur[CUR: raw detail]
 usage --> budget[Budgets: alert/act]
 usage --> ta[Trusted Advisor: fix waste]
 usage --> co[Compute Optimizer: right-size]

Not: sinav eslesmeleri: “harcama gecmisi ve RI karari” = Cost Explorer, “en detayli veri” = CUR, “butce asiminda uyari/aksiyon” = Budgets, “bos kaynak / limit uyari” = Trusted Advisor, “instance fazla buyuk mu” = Compute Optimizer.

cost-optimized-architecture-patterns

Mon, 01 Jan 0001 00:00:00 +0000

Cost-Optimized Architecture Patterns#

The last Domain 4 piece: not a tool, but a habit set. The exam’s “MOST cost-effective” questions are usually one of these patterns wearing a scenario costume.

The pattern checklist#

Right-size - use Compute Optimizer; T-family burstables for spiky small work; don’t pay for a 16-vCPU box that idles at 5%
Turn things off - dev/test schedules (Instance Scheduler), stop idle instances, delete unattached EBS (Elastic Block Store) volumes and idle ELBs (Elastic Load Balancing) - Trusted Advisor finds them
Pay for commitment, not flexibility - steady state → Savings Plans/RI (Reserved Instance); see pricing-models
Embrace Spot and serverless - batch/CI/stateless → Spot; event-driven, spiky → Lambda/Fargate (pay per use, no idle)
Right storage class + lifecycle - s3-cost-and-lifecycle-policies
Cache to cut backend load - CloudFront + ElastiCache = fewer DB instances, less egress (also better perf)
Route data cheaply - VPC (Virtual Private Cloud) gateway endpoints (free S3 (Simple Storage Service) access vs NAT charges), keep inter-service traffic in-region/AZ (Availability Zone), CloudFront for internet egress
S3 instead of compute - static hosting on S3/CloudFront beats an always-on web server

Cost-aware multi-tier design#

flowchart LR
 users[Users] --> cf[CloudFront - cached, cheap egress]
 cf --> alb[ALB]
 alb --> asg[ASG with Spot + On-Demand mix]
 asg --> sqs[SQS buffer]
 sqs --> lambda[Lambda consumers]
 asg & lambda --> ddb[DynamoDB on-demand]

Exam nuance: “most cost-effective” still must meet requirements. If the question says the workload is steady and latency-sensitive, Spot is wrong even though it’s cheapest. Cost answers are always “cheapest that works”.