Cost

Your traffic is spiky and unpredictable during business hours. Design an EC2 Auto Scaling policy that reacts fast without overspending overnight.

Target tracking should be the default scaling policy, since it only needs one metric and handles the math itself. Layer scheduled actions on top for the predictable part of the day, and treat step scaling as the exception for spikes that need a bigger, immediate jump than target tracking gives you.

When would you use EC2 Spot Instances in production, and how do you design a workload to survive interruptions?

Spot is unused EC2 capacity sold at a steep discount, usually 60 to 90 percent off On-Demand, with the trade that AWS can reclaim it with two minutes of warning. It's a good fit for anything stateless, retryable, or checkpointed, and a bad fit for anything that can't tolerate an interruption.

Reserved Instances, Savings Plans, Spot, and On-Demand: how do you decide what mix to run for a given EC2 workload?

The decision runs on one axis: how predictable is the usage, not how important the workload is. Steady, known baseline load goes on Savings Plans, spiky or unknown load stays On-Demand, and anything interruption- tolerant goes on Spot. Reserved Instances are mostly the older, less flexible version of a Savings Plan today.

How do you cut EC2 costs for workloads that sit idle nights and weekends, without relying on someone remembering to turn things off?

Automate the stop and start instead of asking anyone to remember it. Scheduled Auto Scaling actions or AWS Instance Scheduler both work; the choice mostly comes down to whether the fleet is already behind an Auto Scaling group. Either way, tag-based scoping is what keeps it from ever touching something that shouldn't be stopped.

Your RDS bill keeps climbing every month. What levers do you actually have to bring it down?

RDS cost breaks into three independent knobs: compute (instance type and purchase option), storage (type and provisioned amount), and everything that scales with those two but isn't obviously tied to them, like snapshot retention and cross-AZ data transfer. Most real savings come from right-sizing and switching purchase options, not from a single trick.

When would you scale vertically instead of horizontally?

Go vertical when the bottleneck doesn't split: database buffer cache, cache memory, network bandwidth on one node, a single-threaded lock. Go horizontal when the work partitions cleanly. The real question isn't which is better, it's whether the thing that's saturated can be divided across machines at all.

Your CI pipeline runs twice for every pull request. How do you investigate?

Almost always two triggers firing on one action, usually push and pull_request both matching the same branch. Read the event that started each run, then make the trigger config deliberate instead of deleting jobs until the noise stops.

Your 5 GB monorepo has code, binaries, Terraform and Helm charts, and clones are slow. What do you do?

Measure what the 5 GB actually is: big blobs, deep history, and a wide tree are three different problems with three different fixes. Work through them in order of cost, artifacts out of Git, binaries into LFS, partial clone and sparse checkout for developers, and treat splitting the repo as the last resort rather than the first idea.

Your LLM feature costs $40k/month and is growing 30% monthly. Leadership wants it cut by 70% without hurting quality. What do you do?

Most LLM spend goes on tokens that never needed generating, requests that never needed a frontier model, and identical prefixes reprocessed on every call. Measure where the money actually goes first, then attack caching, routing and prompt size before anything as drastic as self-hosting.

Your app writes 2 TB/month of logs that are queried heavily for 7 days, rarely after 30, and must be kept 7 years. Which S3 setup is most cost-effective?

S3 storage classes trade cheap storage for slow, sometimes paid retrieval. When you already know how access drops off with age, the cheapest setup is a lifecycle rule that walks the data down the tiers as it ages. A single class overpays, and Intelligent-Tiering solves a problem this question doesn't have.

A company runs a business-critical application in one AWS Region. The disaster recovery plan requires a recovery time objective of 10 minutes and a recovery point objective of 1 minute in a second Region. The company wants to avoid paying for a full duplicate of the production fleet. Which disaster recovery strategy should a solutions architect choose?

RTO and RPO in minutes rule out backup and restore and pilot light, because both require standing infrastructure up before traffic can move. Warm standby keeps a scaled-down copy always running, which is what buys minutes instead of hours without paying for a second full fleet.

A company stores analytics datasets in Amazon S3. Access is unpredictable: some datasets are queried daily for months, others are never opened again after the first week, and the team cannot tell which is which in advance. All objects are larger than 1 MB and must remain available for immediate retrieval. Which approach is MOST cost-effective?

Lifecycle rules are the cheapest option when access falls off predictably with age. When nobody can predict it, S3 Intelligent-Tiering is the class designed for exactly that: it moves each object between tiers on its own access pattern, with no retrieval fees and no minimum storage duration.

A company runs a steady production workload on Amazon EC2 that has not changed size in two years and is expected to continue for at least three more. The team occasionally changes instance family as new generations are released, and is also beginning to move some services to AWS Fargate. The company wants the largest possible discount without giving up that flexibility. Which purchasing option should a solutions architect recommend?

Predictable long-running usage should never sit on On-Demand pricing. Compute Savings Plans give the deepest commitment discount while staying flexible across instance family, size, Region and even across EC2, Fargate and Lambda, which is what the stem's flexibility requirement is asking for.

A nightly batch job renders video segments. The work is split into thousands of independent tasks, any task can be retried safely if it fails, and the job must finish before 06:00 but has no other timing constraint. The company wants to minimise compute cost. Which approach should a solutions architect recommend?

Independent, retryable tasks with a loose deadline is the definition of an interruption-tolerant workload, and that is what Spot Instances are for. Spreading the request across several instance types and Availability Zones is what keeps a Spot fleet from being reclaimed all at once.

A VPC spans three Availability Zones, each with a private subnet running application instances. All three private subnets route internet-bound traffic through a single NAT gateway in the first Availability Zone. A solutions architect must remove the dependency on that one Availability Zone and reduce cross-Availability Zone data transfer charges. What should the architect do?

A NAT gateway lives in one Availability Zone, so routing all three subnets through it creates both a single point of failure and a cross-zone data transfer charge on most of the traffic. Deploying one NAT gateway per Availability Zone fixes both problems at once.

A development team uses several Amazon RDS for MySQL instances that are only needed during working hours on weekdays. The team wants to stop paying for them outside those hours with the least possible engineering effort, and the databases must retain their data and endpoints between sessions. Which solution meets these requirements?

Stopping an RDS instance removes the instance-hour charge while keeping the data, the endpoint and the configuration. The catch worth knowing is the seven-day limit: RDS restarts a stopped instance automatically after seven consecutive days, so a weekday schedule fits and a long shutdown does not.