Amazon Web Services (AWS) Skills Assessment

Lambda functions execute only when triggered and are billed by actual invocation duration, making them ideal for short, infrequent, bursty workloads like an hourly 45-second batch job, since there is no cost for idle time between invocations. An always-on EC2 instance, whether Reserved or Spot, would incur charges 24/7 even though the actual workload runs for less than a minute per hour. Lambda's automatic concurrency scaling also handles occasional spikes without any manual capacity planning.

A target tracking scaling policy lets an Auto Scaling group automatically adjust capacity to maintain a target value for a specified metric, such as keeping average CPU utilization near 50%, without an operator manually defining every scaling step. This is generally simpler to configure than step scaling policies, which require manually defining specific thresholds and corresponding capacity changes. Target tracking is the most commonly recommended starting point for teams new to Auto Scaling.

Since December 2020, Amazon S3 provides strong read-after-write consistency for all PUT and DELETE operations, including cases where an object is overwritten or deleted, so a read immediately following a successful write will always reflect the latest data. This was a meaningful change from S3's earlier eventual consistency model, which had additional caveats especially around overwrites. This consistency guarantee removes a whole category of race-condition bugs that developers previously had to work around with retry logic.

Amazon EFS is a managed NFS file system built specifically for concurrent access from potentially thousands of EC2 instances across multiple Availability Zones simultaneously, with storage capacity that scales automatically as data grows. EBS volumes, by contrast, can only attach to a single EC2 instance at a time in most configurations. S3 is object storage accessed via API calls, not a mountable file system, and instance store is ephemeral, non-shared local storage tied to a single instance's lifecycle.

DynamoDB excels at single-digit millisecond latency for simple key-value or document access patterns at virtually unlimited scale (A), and storing session data with predictable primary-key lookups is a textbook DynamoDB use case (C). Complex multi-table JOINs (B) and applications requiring strict relational integrity across many interrelated tables with complex reporting (D) are exactly what relational databases like RDS are designed for, since DynamoDB deliberately trades away those relational capabilities in exchange for its scale and latency advantages.

RDS Multi-AZ maintains a synchronously replicated standby instance in a different Availability Zone specifically for high availability, and when the primary fails, RDS automatically detects the failure and fails over to the standby, typically within a minute or two, without requiring manual intervention. Multi-AZ is explicitly not designed for read scaling — that is what read replicas are for — a commonly confused distinction. No system can prevent all possible outages, but Multi-AZ significantly reduces downtime and eliminates the need for a human to manually promote a new primary during a failure.

On-Demand Instances (2) offer maximum flexibility with no commitment, at the highest per-hour price, ideal for unpredictable or short-term workloads. Savings Plans (3) offer meaningful discounts in exchange for a spending commitment while still allowing flexibility across instance families and sizes. Reserved Instances (1) offer the deepest discounts for steady, predictable workloads but come with the least flexibility, since they are tied to a specific instance type and require a 1 or 3 year commitment to unlock their full savings.

An IAM Role (1) is an identity that can be assumed temporarily, generating short-lived credentials, ideal for cross-account access or granting permissions to AWS services (B). An IAM Policy (2) is the actual JSON document that defines what actions are allowed or denied (A). An IAM User (3) is a permanent identity, typically representing a specific person, with long-term credentials (D). An IAM Group (4) is simply a collection of users that share a common set of permissions, simplifying permission management at scale (C).

Attaching an IAM role directly to an EC2 instance allows the application running on it to automatically retrieve short-lived, automatically rotated temporary credentials through the instance metadata service, completely eliminating the need to store or manage any long-lived access keys in code. Hardcoded credentials in source code are a serious security risk, especially if that code is ever committed to a shared repository, and annual manual rotation still leaves a long-lived key exposed for up to a year. Storing credentials in any S3 bucket, public or not, is never an appropriate way to distribute AWS credentials.

Spot Instances let AWS sell unused EC2 capacity at steep discounts, sometimes up to 90% off On-Demand pricing, in exchange for the risk that AWS can reclaim the instance with only a two-minute warning if that capacity is needed elsewhere. This makes Spot ideal for fault-tolerant, stateless, or checkpoint-able workloads like batch processing or CI/CD build agents, but a poor fit for anything requiring guaranteed uptime like a primary database. Understanding this tradeoff is essential for cost optimization discussions in any AWS architecture review.

AWS Lambda functions have a maximum execution timeout, which can be configured up to 15 minutes per invocation; a function cannot run indefinitely regardless of how it is configured. Workloads that genuinely need to run longer than 15 minutes are not a good fit for Lambda and typically require a different compute option like ECS, Fargate, or a traditional EC2-based approach. This timeout limit is one of the first architectural constraints engineers need to account for when deciding whether Lambda fits a given workload.

EFS provides a standard POSIX-compliant file system where a write from one client is immediately visible to all other clients that have the file system mounted, which fits a shared configuration file scenario across multiple Availability Zones far more naturally than S3's object model or EBS's block-storage model. EBS multi-attach is limited to specific instance types and cluster-aware file systems, and is generally not recommended for typical shared-file use cases. Local instance store is inherently per-instance and would require significant custom syncing logic, defeating the purpose of a shared file.

Read Replicas use asynchronous replication (A), meaning there can be a small replication lag, and they are specifically designed to offload read-heavy query traffic from the primary instance (D). A Read Replica can also be promoted into an independent, standalone database instance if needed (B). Automatic failover (C) is the purpose of Multi-AZ, not Read Replicas, since Read Replicas do not automatically take over as the primary during a failure without manual promotion, making C false.

A 40% reduction on $0.10 per hour means calculating 0.10 multiplied by 0.60, which equals $0.06 per hour. This kind of straightforward percentage-discount calculation is exactly the type of quick math AWS cost optimization conversations require when comparing On-Demand, Reserved Instance, and Savings Plans pricing across different commitment terms. Being able to do this calculation quickly and correctly is a practical, everyday skill for anyone managing AWS costs.