Serverless services

Memory hook: Separate execution limits, data access patterns, API authorization and workflow state instead of treating serverless as unlimited capacity.

Must remember

Lambda execution, scaling and network access

• Lambda runs event-driven functions without provisioning ordinary application servers. Handlers should tolerate retries and avoid depending on one execution environment's local state.
• Concurrency is simultaneous execution, roughly arrival rate multiplied by execution duration. Faster functions can reduce concurrent capacity needed, but downstream services may remain the bottleneck.
• Reserved concurrency reserves capacity and caps that function; it does not pre-initialize environments. Provisioned concurrency keeps initialized environments ready and can incur idle cost. Account quotas, function scaling behavior and throttling still apply.
• The standard Lambda functions used in this pack have a 15-minute maximum invocation timeout. Current specialized execution modes have separate limits; do not turn that rule into a claim about every new Lambda feature. Memory also influences available CPU. Current Lambda quotas
• SnapStart restores eligible published functions from initialized snapshots. Check runtime/feature support and handle values that must remain unique or connections that can become stale after initialization.
• VPC attachment reaches private resources such as a private relational database. It does not give the function a public IP; a public subnet alone does not provide internet egress. Use appropriate NAT/routes or supported endpoints.
• Supported RDS/Aurora-to-Lambda integrations let database-side activity invoke a function with suitable engine, IAM and network configuration. That is different from Lambda opening a database connection.
• CloudFront Functions suits lightweight viewer logic; Lambda@Edge supports richer viewer/origin processing but introduces replicated-resource restrictions and slower cleanup. See global delivery.

DynamoDB access patterns, capacity and consistency

• A table has a partition key, or a composite partition key plus sort key. The partition key distributes data; the sort key orders related items within that partition-key value.
• Query uses a key condition to select a partition and optional sort-key range. Scan reads across the table/index. A filter is applied after reading; it does not transform an expensive scan into an efficient key lookup.
• On-demand suits variable demand without choosing provisioned throughput. Provisioned uses read/write capacity with optional auto scaling; predictable utilization can favor explicit sizing. Item size, read consistency and transactional operations affect capacity use.
• Capacity arithmetic: one RCU supports one strong read per second, or two eventual reads, for items up to 4 KB. One WCU supports one write per second for items up to 1 KB. Round larger items up to capacity-unit boundaries; transactions require additional capacity. Provisioned capacity
• LSI: same partition key, different sort key; define it with the table, share table capacity, and choose eventual or strong reads.
• GSI: a different access path using potentially different partition/sort keys; it can be added later and scales separately. GSI reads are eventually consistent, not strongly consistent. Index comparison
• Tables and LSIs support strong reads when requested. Strong reads cost more than equivalent eventual reads; neither means every future request is protected from subsequent writes.
• Global tables replicate across Regions. Multi-Region eventual consistency and multi-Region strong consistency are different modes with different support and tradeoffs; do not memorize “all global tables are eventually consistent.” Read consistency
• DAX caches suitable eventually consistent DynamoDB reads. It does not remove the need for good partition keys or make a strong-read requirement a cache hit.
• Streams captures item changes for event processing with per-item ordering; it is not permanent backup history. TTL deletes expired items asynchronously, so applications must handle records that have expired logically but remain physically present.
• PITR and on-demand backups restore into new tables. S3 export supports analysis of point-in-time data without consuming table read capacity; S3 import creates a new table. Replication and backup protect against different failures.

API Gateway and user identity

• REST APIs offer edge-optimized, regional and private endpoint types. HTTP APIs are a separate feature/cost choice; do not assume every REST feature exists on HTTP APIs.
• IAM authorization uses signed AWS requests. REST APIs support Cognito user-pool authorizers; HTTP APIs have native JWT authorizers. Lambda authorizers allow custom authorization logic. REST API keys and usage plans provide client identification/metering controls, not sufficient authentication by themselves. API comparison
• Cognito user pools provide user directories, sign-in and tokens. Identity pools exchange supported identities for temporary AWS credentials through roles, optionally including configured guest access. They solve different problems and may be combined.
• A valid token proves an identity claim; the application still must enforce ownership of the requested record. See serverless application design.

Workflow orchestration and reusable applications

• Step Functions models tasks, choices, parallelism, waits, retries and catches. Prefer it to implementing a long workflow through functions that poll or sleep.
• Standard supports durable, auditable workflows up to one year and bills state transitions. Its exactly-once workflow model does not make every external side effect immune to explicitly configured retries.
• Express supports short, high-volume workflows up to five minutes and bills execution/duration/memory. Asynchronous Express is at-least-once; synchronous Express is at-most-once. Select a model compatible with the work's idempotency and integration needs. Workflow types
• AWS Serverless Application Repository publishes and shares deployable serverless applications, commonly described with AWS SAM. It is a reusable application catalog, not a runtime, container registry or marketplace data feed. Review permissions and created resources before deployment. Repository purpose

Choose under exam pressure

Traps

• On-demand capacity does not eliminate hot keys, service quotas or downstream limits.
• TTL is not an exact scheduler; a global replica is not a historical backup.
• An LSI cannot simply be added to an existing table; a GSI cannot provide strong reads.
• A VPC subnet labelled “public” does not give Lambda public-address connectivity.
• Reserving concurrency is different from paying to keep environments initialized.

Active recall

Terraform anchor: Keep module interfaces explicit, and control optional resource counts with known booleans rather than unknown generated policy strings.

Sources

• Lambda execution quotas
• DynamoDB secondary indexes
• DynamoDB read consistency and global modes
• API Gateway REST/HTTP comparison
• Step Functions workflow types