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.

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.

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.

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 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.