Based on the SAP-C02 exam guideReport an error
When AWS announced Lambda in 2014, the industry reaction was skeptical: "You're abstracting away the infrastructure just to run a single function?" Ten years later, however, serverless has become the standard by which startups scale to a global level without an infrastructure team. The symbol of that was a photo-sharing app that made headlines in 2017. Only 13 employees ran millions of users on serverless alone, with zero infrastructure engineers. The point is simple: for a team of 3, the most expensive resource is not servers but engineers' time, and serverless shifts that time from running infrastructure to the product.
Today's scenario is a seed-stage SaaS. 3 engineers, a fast launch, minimal initial cost, but a 100x increase in users expected 6 months later. These two requirements look like they conflict: it is barely used at first, yet it must suddenly blow up 100x. For SAA the answer ends at "use Lambda," but Pro asks about the full lifecycle economics: zero cost at zero usage, automatic scaling at 100x, and after 100x, cutting cost again with Savings Plans. Today we break down in depth why serverless is economically superior for startups, where 100x scaling gets blocked (concurrency and cold starts), and the math of commitment discounts.
Traditional EC2 charges for provisioned capacity: whether or not the instance receives traffic, it is billed by the hour as long as it is on. This is fatal in the early startup stage. Even when there are only 100 users a day, you have to keep EC2 on 24 hours, so the idle cost can be larger than revenue. Lambda, DynamoDB On-Demand, and Aurora Serverless v2 flip this structure: no requests means no charges (pay-per-use).
This is the extreme form of the CAPEX → OPEX shift, a core concept in cloud economics. Traditional IT is a CAPEX model of buying servers up front, and EC2 is hourly OPEX but you still pay for "being on." Serverless is usage-based OPEX, where cost follows revenue (= usage) linearly. Financially, this ties a startup's burn rate (the speed of cash consumption) to the revenue curve, protecting cash before finding product-market fit (PMF). The "matching supply with demand" described by the Cost Optimization pillar of the WA Framework is achieved automatically with serverless. On the exam, if you see "zero cost when there is no traffic," it is one of Lambda, DDB On-Demand, or Aurora Serverless v2.
But serverless is not always cheaper. Usage has a break-even point. Lambda is billed per invocation + execution time (GB-seconds), so if traffic is consistently very high, an always-on EC2/Fargate actually becomes cheaper. Roughly, "predictable, sustained high load" favors provisioned compute and "highly variable or intermittent" favors serverless. The Pro insight is to change the model along the lifecycle: start with serverless for zero cost, and once usage becomes stable high load, move part of it to Fargate/EC2 + Savings Plans to optimize again. On the exam, if you see "predictable, steady high load + minimum cost," the answer may be provisioned + commitment discount rather than serverless.
The center of serverless data is DynamoDB. RDS has limits on vertical scaling of a single node, but DDB automatically splits partitions to scale horizontally and grows virtually without limit. On-Demand mode follows traffic immediately without capacity planning, absorbing a 100x surge.
DDB's design philosophy starts from Amazon's 2007 Dynamo paper (SOSP). From the requirement that "the shopping cart must never stop," that paper chose an AP system (CAP theorem) that prioritizes availability over consistency. The default is eventual consistency, with strong reads available as an option. The paper became the progenitor of later NoSQL systems such as Cassandra and Riak. The secret to DDB's unlimited scaling is distributing data to nodes by the hash of the partition key (consistent hashing), which is why partition key design is performance. On the exam, if you see "traffic concentrated on a single key (hot partition)," it is a key design problem, and the fix is write sharding or key distribution.
⚠️ Trap: If you memorize "DDB scales infinitely," you fall into the hot partition trap. If traffic concentrates on a specific partition key, it is blocked by that partition's throughput limit (about 3,000 RCU/1,000 WCU per partition) and throttled, even if the whole table has headroom. This blows up at 100x scale. The fix is to design the partition key so it distributes evenly (for example, write sharding with date + random suffix), or, for patterns like time series, to add a distribution factor to the key. On the exam, if you see "it's DDB but only some keys are throttled," it is a hot partition, not a capacity shortage.
If you truly need relational, use Aurora Serverless v2. The difference between v1 and v2 appears on the exam: v1 has a pause when scaling, scales slowly, and goes down to zero but with large cold-start delay. v2 scales in place without interruption in increments as small as 0.5 ACU, making it suitable for production workloads. However, v2 did not originally go all the way down to zero (newer versions support 0 ACU through automatic pause). On the exam, "relational + variable usage + production" is Aurora Serverless v2.
Lambda's scaling looks unlimited, but there are two practical walls: the concurrency limit and cold starts.
Lambda starts an execution environment per request. The number of requests being processed at the same moment is the concurrency, and there is a default concurrency limit per account per Region (usually 1,000, can be raised). If a 100x surge exceeds this limit, it is throttled. Also, the delay for runtime initialization and code loading when a new execution environment is first started is the cold start; with heavy runtimes such as Java/.NET it can be hundreds of ms to several seconds.
A cold start is essentially the cost of simulating a stateless function on stateful infrastructure. Lambda reuses an environment for a while after use (warm) and reclaims it when idle; this reclaim-and-recreate cycle is the root of cold starts. To reduce it, AWS introduced Provisioned Concurrency (pre-warming environments, which incurs cost) and, in 2022, SnapStart (takes a snapshot of a Java function's initialization in advance and restores it, using the snapshot feature of the Firecracker microVM). Firecracker is a lightweight virtualization technology that AWS open-sourced in 2018 and is the isolation foundation of Lambda and Fargate. On the exam, if you see "latency SLA violated because of Lambda cold starts," the answer is Provisioned Concurrency (or SnapStart for Java).
⚠️ Trap: A common mistake when scaling 100x is that downstream resources cannot keep up with Lambda's concurrency. Lambda explodes to 1,000 concurrent executions in an instant, but the RDS behind it collapses at its connection limit (for example, a few hundred), because each Lambda instance opens a DB connection. The fix is to reuse connections with RDS Proxy (connection pooling), or to move to serverless data such as DDB. On the exam, if you see "Lambda + RDS but 'too many connections' when scaling," RDS Proxy is the answer. Serverless scales only as far as its weakest link.
🎯 Scenario: "A startup knows that a marketing campaign will momentarily surge traffic to 100x the usual. The architecture is API Gateway + Lambda + DynamoDB. What are the three most important things to pay attention to?" - Answer: (1) Lambda reserved/provisioned concurrency to prepare for throttling and cold starts, (2) DynamoDB On-Demand or a key design that prevents hot partitions, (3) raise the API Gateway throttle limit + buffer with SQS. If you receive the synchronous surge into SQS and let Lambda consume at its own pace (buffer & decouple), you protect downstream and process without loss. On the exam, if you see "absorb a predicted surge," SQS buffering + concurrency management is the key.
For global users, CloudFront + S3 (SPA static hosting) is the standard. CloudFront caches content at edge locations worldwide to reduce latency, and with the 1 TB/month free tier the initial cost is also nearly zero. Dynamic edge logic splits into two.
| Item | CloudFront Functions | Lambda@Edge |
|---|---|---|
| Execution location | Edge locations (218+) | Regional edge caches (13) |
| Runtime | Lightweight JS | Node.js/Python |
| Latency | Under 1 ms | A few ms to tens of ms |
| Use | Header manipulation, redirects, URL rewriting | Heavy logic, external calls, body manipulation |
| Max execution | Under 1 ms | 5 seconds (viewer) to 30 seconds (origin) |
This separation is the implementation of the edge computing principle "the lightest work at the closest place." CloudFront Functions is based on V8 isolates and is extremely lightweight, running in 0.x ms at every edge, so it is used for simple header additions, A/B routing, and simple authentication checks. Lambda@Edge is heavier but handles complex logic such as external API calls and request body transformation. On the exam, it splits as follows: "simple headers/redirects at the edge, lowest latency and lowest cost" is CloudFront Functions, and "validate an auth token at the edge, external calls" is Lambda@Edge.
Once you have grown 100x and usage has stabilized, on-demand prices become expensive. At that point you get a commitment discount with Savings Plans (SP). SP is a model that, if you commit to "$X per hour for 1 or 3 years," discounts by up to 72% compared with on-demand.
| Type | Applies to | Flexibility | Max discount |
|---|---|---|---|
| Compute Savings Plans | All of EC2, Fargate, and Lambda, regardless of Region or instance family | Highest | ~66% |
| EC2 Instance Savings Plans | Only EC2 in a specific Region and family | Medium | ~72% |
| Reserved Instances | A specific instance type | Low (the old way) | ~72% |
The economics of SP is an exchange of demand predictability for a discount rate. When users commit to future usage, AWS finds capacity planning easier and gives a discount in return, a kind of futures contract. The key math: with discount rate D and commitment ratio C (the share of total usage covered by the commitment), savings = C × D × (on-demand cost). So for a highly variable workload, it is optimal to commit with SP only the baseline (the minimum usage that is always running) and absorb the variable part with on-demand. If you commit the baseline too large, you have to pay the committed amount even when usage falls (use-it-or-lose-it), which is a loss. On the exam, if you see "variable usage + commitment discount," the right way of thinking is to cover only the baseline with Compute SP.
What matters especially for startups is that Compute SP also covers Lambda and Fargate. When a serverless-first startup grows 100x and its Lambda and Fargate cost becomes tens of thousands of dollars per month, it can layer a discount on top with a 1-year Compute SP commitment, getting commitment savings without giving up serverless. EC2 Instance SP and RIs do not apply to Lambda. On the exam, if you see "reduce Lambda and Fargate cost + keep flexibility," Compute Savings Plans is the direct answer. Also, the discount rate varies with the term (1 year vs 3 years) and the payment option (All/Partial/No Upfront), so the exam may ask about the tradeoff between cash on hand and discount.
For a small team to iterate quickly, IaC (SAM/CDK) and CI/CD are essential. SAM is serverless-specific IaC, and CDK defines infrastructure in real programming languages (TypeScript, Python, and so on), making it strong at abstraction and reuse. For permissions, assume an IAM Role from GitHub Actions via OIDC so that no long-lived access keys are stored.
Storing AWS access keys in GitHub Secrets for CI/CD is an anti-pattern: if a key leaks, permanent privileges are exposed, and the rotation burden is also large. OIDC (OpenID Connect) federation assumes an IAM Role with a short-lived token issued by GitHub, so no access key is stored at all (keyless). The token is valid only during the workflow run and expires automatically. On the exam, if you see "access AWS from GitHub Actions/external CI + without long-lived keys," OIDC + IAM Role is the answer.
Startup serverless design is lifecycle economics: at first, serverless (Lambda, DDB On-Demand, Aurora Serverless v2) gives usage 0 = cost 0; during a surge, you scale automatically while managing concurrency, hot partitions, and downstream connections; after stabilization, you commit the baseline with Compute SP to cut cost again. The key insights are (1) serverless ties burn rate to revenue, (2) DDB's unlimited scaling depends on key design, (3) serverless scales only as far as its weakest link (RDS connections), and (4) Compute SP also covers Lambda and Fargate.
SAP exam mapping: (1) "Zero compute cost when traffic is 0" → Lambda, (2) "Relational + highly variable usage + production" → Aurora Serverless v2, (3) "Fast global SPA deployment, minimal cost" → CloudFront + S3 (OAC), (4) "Reduce Lambda and Fargate cost + flexibility" → Compute Savings Plans, (5) "Access AWS from external CI, no long-lived keys" → OIDC + IAM Role, (6) "Simple edge headers, lowest latency" → CloudFront Functions, (7) "Lambda cold start violates SLA" → Provisioned Concurrency/SnapStart, (8) "Connection explosion when scaling Lambda+RDS" → RDS Proxy, (9) "Absorb a predicted surge" → SQS buffering + concurrency management. The next day is the exact opposite: it digs into financial-sector architecture, where regulation, isolation, and auditing govern everything.
Click a choice to reveal the answer and explanation.
Question 1
A seed-stage SaaS has almost zero traffic at night but large variability during the day. It wants compute cost to be exactly proportional to usage, and to be zero when there is no traffic. Which compute is most suitable?
Question 2
It is a production workload that needs a relational database, with very large usage variability, and it wants seamless, second-level scaling. Which is the most suitable choice?
Question 3
After a 100x traffic surge, 'too many connections' errors occur frequently when Lambda connects to RDS. Which is the most suitable fix?
Question 4
You have grown 100x and Lambda and Fargate cost is now tens of thousands of dollars per month. You want to cut cost with a commitment discount while keeping the serverless architecture, and you also want the flexibility to change instance families and Regions. Which is the most suitable?
Question 5
You need to deploy to AWS from a GitHub Actions pipeline. The security team requires that no long-lived access keys be stored anywhere. Which is the most suitable method?
Question 6
The whole DynamoDB table has ample capacity headroom, but throttling occurs only on a specific partition key. Which is the most accurate cause and fix?
Question 7
You know that synchronous API traffic will surge to 100x momentarily because of a marketing campaign. You are worried about Lambda concurrency throttling and protecting downstream resources. Which is the most suitable buffering design?