Pass the AWS Solutions Architect exam on the first try.

The first step is right-sizing: use AWS Compute Optimizer or CloudWatch metrics to identify the correct instance family and size. For a burstable workload with low baseline CPU, a T4g (Graviton-based) instance with Unlimited burst mode often covers the spikes while being cheaper than a fixed M or C family. Next, move the baseline capacity to a 1-year Convertible Reserved Instance or a Compute Savings Plan. Savings Plans are more flexible because they apply across instance families, sizes, and regions, and typically yield 20-66% savings over On-Demand. For the unpredictable spikes, add EC2 Auto Scaling with a target tracking policy keyed to CPU or request count, and configure the launch template to prefer Spot Instances in an instance-diversified Spot fleet across multiple AZs. If the app can tolerate interruption with a 2-minute warning, Spot cuts costs by up to 90%. Front the Auto Scaling group with an Application Load Balancer so traffic shifts seamlessly as instances come and go. Together: Savings Plan covers committed baseline, Spot handles burst, T4g cuts the per-hour rate, and Auto Scaling eliminates idle over-provisioning.

The right choice is S3 Standard-IA for millisecond access with lower storage cost, but the question exposes a common trap. If objects are small (under 128 KB) or retrieved very frequently, Standard-IA charges per-retrieval fees that quickly exceed Standard pricing. For 200 TB of large log files accessed rarely, Standard-IA is the correct answer: storage cost drops roughly 55% compared to Standard, and retrieval latency is still milliseconds, same as Standard. If millisecond latency were not required and the files were accessed perhaps once a quarter, S3 Glacier Instant Retrieval would be cheaper still: similar millisecond access but lower storage price than Standard-IA, at the cost of a 90-day minimum storage duration and higher per-retrieval fee. The decision tree is: Do you need milliseconds? If no, Glacier Instant or Flexible. Do you access less than once a month? If yes, Glacier Instant beats Standard-IA. Is each object small or retrieved often? If yes, Standard wins over IA despite the higher storage rate. Avoid confusing Glacier Flexible Retrieval (minutes-to-hours) with Glacier Instant. The word "Glacier" no longer means slow since AWS split the class. That nuance is exactly what the exam tests.

Start with a VPC CIDR large enough for growth: a /16 like 10.0.0.0/16 gives 65,536 addresses. Carve it into at least six subnets across two Availability Zones: two public subnets (e.g., 10.0.0.0/24 and 10.0.1.0/24), two private application subnets (10.0.10.0/24 and 10.0.11.0/24), and two private database subnets (10.0.20.0/24 and 10.0.21.0/24). Using multiple AZs at every tier is essential for high availability. Routing is what separates public from private. Public subnets get a route table with a default route (0.0.0.0/0) pointing to an Internet Gateway. Instances in public subnets also need public IPs or Elastic IPs. Private subnets must never have a route to the IGW. Instead, their default route points to a NAT Gateway deployed in the public subnet, which lets private instances reach the internet for updates while remaining unreachable inbound. Database subnets should have no default route at all unless they absolutely need outbound access. Security controls layer on top: security groups on each instance or load balancer control stateful inbound and outbound traffic. The web tier security group allows 443 from 0.0.0.0/0. The app tier security group allows only from the web tier security group. The database security group allows only port 3306 (or 5432) from the app tier security group. NACLs add a stateless layer at the subnet boundary for coarse-grained allow/deny rules but are optional if security groups are tight. Place the Application Load Balancer in the public subnets and the web EC2 instances in the private application tier, pointing the ALB target group there, so no web server needs a public IP.

Enable RDS Multi-AZ deployment. When Multi-AZ is active, RDS maintains a synchronous standby replica in a different Availability Zone within the same region. Every write to the primary is committed to the standby before the write is acknowledged to the application, so there is zero data loss (RPO of 0) on an AZ failure. When RDS detects that the primary is unavailable, it automatically promotes the standby and updates the CNAME DNS endpoint to point at the new primary, typically within 60 to 120 seconds. Applications must use the RDS endpoint, not the underlying instance IP, so the failover is transparent to them. Multi-AZ is not a read-scaling mechanism. The standby is not accessible for reads. If the team also needs read scaling, they should add Read Replicas, which use asynchronous replication and can serve SELECT traffic. Read Replicas can be in the same region or in other regions for cross-region disaster recovery, but they require manual promotion to become a primary during a failover event. The key distinction the exam tests: Multi-AZ is for high availability and automatic failover; Read Replicas are for read scalability and cross-region DR. Using a Read Replica as the HA mechanism fails the automatic-promotion requirement unless the team also enables Multi-AZ on it after promotion.

Hardcoding IAM user credentials on an EC2 instance is a well-known anti-pattern for several reasons. First, static access keys do not rotate automatically, so a leaked key remains valid until someone notices and revokes it manually. Second, keys stored in environment variables, config files, or code often end up in version control or AMI snapshots, creating a permanent credential leak. Third, the blast radius of a compromise is tied to the key owner, not the instance, so you cannot easily scope the damage to one host. The correct approach is to attach an IAM instance profile to the EC2 instance. An instance profile is a container for an IAM role. When the instance starts, the EC2 Instance Metadata Service (IMDS) provides temporary, automatically rotated credentials via STS AssumeRole under the hood. The AWS SDKs pick these up from the metadata endpoint automatically, so no credential is ever written to disk. Create an IAM role with a trust policy that allows the EC2 service principal to assume it, attach an identity-based policy granting only s3:GetObject on the specific bucket and prefix, and associate the role with the instance at launch or attach it afterward. IMDSv2 should be enforced (requiring a session token) to prevent SSRF attacks from stealing the metadata credentials. The instance never holds a long-lived secret, and if the instance is terminated the credentials die with it.

The standard starting point for a budget-conscious, highly available web application is a two-tier architecture spanning at least two Availability Zones behind an Application Load Balancer (ALB). Place EC2 instances or containers inside an Auto Scaling Group across private subnets in two AZs. Use Amazon RDS Multi-AZ for the database: it keeps a synchronous standby in a second AZ and fails over automatically, usually within 60 to 120 seconds, with no manual intervention. Put static assets on Amazon S3 and serve them through Amazon CloudFront to reduce origin load and improve global latency. For DNS, use Route 53 with health checks so traffic stops routing to an unhealthy endpoint. Store session state in Amazon ElastiCache for Redis rather than on the instance, which lets the ALB route any request to any healthy instance without sticky sessions. This achieves roughly 99.99% availability at a fraction of the cost of a multi-region setup. The key design principle is eliminating single points of failure at the compute, database, and DNS layers while keeping costs predictable. As traffic grows, the Auto Scaling Group adds capacity automatically, so the team pays for what they use rather than overprovisioning.