vybekiit 0.4.0 → 0.6.0

package/dist/global-skills/aws-serverless/references/architecture.md

@@ -0,0 +1,262 @@
+# Serverless Architecture Patterns
+
+Reference architectures, pattern selection flowcharts, and service selection tables for common serverless workloads.
+
+## Contents
+
+- [Pattern selection flowchart](#pattern-selection-flowchart)
+- [REST/HTTP API pattern](#resthttp-api-pattern)
+- [Event processing pattern](#event-processing-pattern)
+- [Orchestration pattern](#orchestration-pattern)
+- [Real-time streaming pattern](#real-time-streaming-pattern)
+- [Async fan-out pattern](#async-fan-out-pattern)
+- [Scheduled jobs pattern](#scheduled-jobs-pattern)
+- [Choosing between patterns](#choosing-between-patterns)
+
+---
+
+## Pattern selection flowchart
+
+```
+What are you building?
+│
+├── Synchronous request/response API?
+│   └── REST/HTTP API pattern
+│
+├── Processing events from a queue/stream/database?
+│   └── Event processing pattern
+│
+├── Multi-step workflow with branching/error handling?
+│   └── Orchestration pattern
+│
+├── Real-time bidirectional communication or LLM streaming?
+│   └── Real-time streaming pattern
+│
+├── One event triggers multiple independent consumers?
+│   └── Async fan-out pattern
+│
+└── Recurring task on a schedule?
+    └── Scheduled jobs pattern
+```
+
+---
+
+## REST/HTTP API pattern
+
+```
+Client → API Gateway (HTTP API) → Lambda → DynamoDB
+                                         → S3 (binary storage)
+```
+
+**When:** CRUD APIs, mobile/web backends, microservices.
+
+**Service selection:**
+
+| Decision | Default | Alternative |
+|---|---|---|
+| API type | HTTP API (simpler) | REST API if you need WAF, caching, request validation, API keys |
+| Auth | JWT authorizer (HTTP API native) | Cognito (REST: native Cognito authorizer; HTTP: JWT authorizer), Lambda authorizer (custom logic) |
+| Database | DynamoDB (on-demand) | RDS Proxy + RDS if relational data needed |
+| File storage | S3 with presigned URLs | Direct upload via API Gateway (10 MB limit) |
+| Function pattern | One function per route | Lambdalith if team prefers Express/FastAPI style |
+
+**Key constraints:**
+
+- HTTP API: 30s hard timeout, no WAF, no caching, 10 MB payload
+- REST API: 29s default timeout (adjustable for Regional/private APIs), 10 MB payload
+
+---
+
+## Event processing pattern
+
+```
+Event source → SQS → Lambda → DynamoDB / S3
+                ↓
+              DLQ (failed messages)
+```
+
+**When:** Async workloads, decoupled producers/consumers, batch processing, file processing.
+
+**Service selection:**
+
+| Decision | Default | Alternative |
+|---|---|---|
+| Buffer | SQS standard queue | SQS FIFO if ordering matters (10 msg batch limit) |
+| Trigger | SQS event source mapping | S3 event notification → Lambda (file uploads) |
+| Change data capture | DynamoDB Streams → Lambda | EventBridge Pipes → Lambda (no ESM needed) |
+| Stream ingestion | SQS (simpler) | Kinesis (ordered replay, multiple consumers, high-throughput) |
+| Error handling | SQS redrive policy (DLQ) | On-failure destination (SQS/SNS/S3) for streams |
+| Concurrency control | MaximumConcurrency on ESM | Reserved concurrency on function |
+| Batch processing | ReportBatchItemFailures | Powertools Batch Processor utility |
+
+**Key constraints:**
+
+- SQS visibility timeout ≥ 6× function timeout
+- MaximumConcurrency and Provisioned Mode are mutually exclusive on same ESM
+- Enable partial batch failure reporting to avoid reprocessing successful messages
+- SQS event filtering automatically deletes unmatched messages (permanently — not sent to DLQ)
+
+**S3 trigger constraints:**
+
+- Recursive invocation risk: never write output to the same bucket/prefix that triggers the function
+- No native DLQ on S3 notifications — use Lambda async invocation DLQ instead
+- Use prefix/suffix filtering to limit which objects trigger the function
+- Consider EventBridge for S3 instead of S3 notifications (richer filtering, multiple targets)
+
+**DynamoDB Streams constraints:**
+
+- Max 2 Lambda consumers per stream shard (use EventBridge Pipes for more)
+- 24-hour stream retention — records expire and cannot be replayed after that
+- Ordering guaranteed per partition key, not globally
+
+---
+
+## Orchestration pattern
+
+```
+Trigger → Step Functions → Lambda (validate)
+                         → Choice (route by status)
+                         → Parallel (fan-out)
+                         → Lambda (aggregate) → DynamoDB
+```
+
+**When:** Multi-step workflows, saga transactions, approval chains, data pipelines, AI agent loops.
+
+**Service selection:**
+
+| Decision | Default | Alternative |
+|---|---|---|
+| Workflow type | Standard (exactly-once, up to 1 year) | Express (<5 min, high-volume; async=at-least-once, sync=at-most-once) |
+| Simple data transforms | JSONata (inline, no Lambda needed) | Lambda task (complex logic) |
+| Service calls | Direct SDK integration (200+ services) | Lambda intermediary (only if business logic needed) |
+| Human approval | .waitForTaskToken | Lambda durable functions waitForCallback |
+| AI agent loops | Step Functions + Bedrock | Lambda durable functions (code-first, checkpointed) |
+| Error handling | Retry + Catch in ASL | Lambda durable functions try/catch in code |
+
+**Key constraints:**
+
+- 256 KB payload limit between states — use S3 for large data
+- Express: no .sync, no .waitForTaskToken, no Distributed Map, no Activities
+- 25,000 execution history entries (Standard) — split long workflows into child executions
+- Prefer direct SDK integrations over Lambda intermediary functions to reduce latency
+
+---
+
+## Real-time streaming pattern
+
+```
+Client ←→ API Gateway WebSocket ←→ Lambda → DynamoDB (connections)
+                                          → Bedrock (LLM responses)
+```
+
+Or for LLM token streaming:
+
+```
+Client → Lambda Function URL (streaming) → Bedrock ConverseStream
+```
+
+**When:** Chat apps, live dashboards, notifications, LLM token streaming, multiplayer games.
+
+**Service selection:**
+
+| Decision | Default | Alternative |
+|---|---|---|
+| Bidirectional | API Gateway WebSocket | AppSync subscriptions (GraphQL) |
+| LLM streaming | Lambda Function URL + ConverseStream | REST API proxy with STREAM mode |
+| Connection state | DynamoDB (connectionId → metadata, enable TTL to clean up stale connections after 2-hour max duration) | ElastiCache (higher throughput) |
+| Auth | $connect route authorizer | Cognito + custom auth in Lambda |
+
+**Key constraints:**
+
+- WebSocket: 10 min idle timeout, 2 hour max connection, 128 KB message (hard limit)
+- Function URL streaming: 200 MB limit, 2 MBps after first 6 MB, Node.js native support
+- Function URLs **MUST** use `AWS_IAM` auth type. For CloudFront integration, use Origin Access Control (OAC) to sign requests — do not set auth to `NONE`. If `NONE` is unavoidable for other reasons, authentication **MUST** be enforced at the edge (e.g., CloudFront + Lambda@Edge). No native JWT/Cognito support.
+
+---
+
+## Async fan-out pattern
+
+```
+Producer → EventBridge → Rule A → Lambda (process)
+                       → Rule B → Step Functions (workflow)
+                       → Rule C → SQS → Lambda (batch)
+```
+
+**When:** One event triggers multiple independent actions, event-driven microservices, cross-service communication.
+
+**Service selection:**
+
+| Decision | Default | Alternative |
+|---|---|---|
+| Event router | EventBridge (content-based routing) | SNS (simpler fan-out, attribute/body filtering) |
+| Point-to-point | EventBridge Pipes (source→target, no Lambda intermediary) | SQS → Lambda ESM |
+| Schema management | EventBridge Schema Registry + Discovery | Manual schema documentation |
+| Cross-account | EventBridge cross-account rules | SNS cross-account subscriptions |
+| Scheduling | EventBridge Scheduler (cron/rate) | EventBridge rules (simpler but less flexible) |
+
+**Key constraints:**
+
+- Use dedicated event bus per application domain (not the default bus)
+- EventBridge Pipes eliminates Lambda intermediary functions for source→target integrations
+- Be precise with event patterns — overly broad patterns risk loops
+- Configure DLQs on all targets
+
+---
+
+## Scheduled jobs pattern
+
+```
+EventBridge Scheduler → Lambda (task)
+                      → Step Functions (complex workflow)
+```
+
+**When:** Cron jobs, periodic data sync, report generation, cleanup tasks.
+
+**Service selection:**
+
+| Decision | Default | Alternative |
+|---|---|---|
+| Scheduler | EventBridge Scheduler (flexible, one-time + recurring) | EventBridge rules with schedule expression (simpler) |
+| Short task (<15 min) | Lambda directly | — |
+| Long task (>15 min) | Step Functions (up to 1 year) | Lambda durable functions |
+| High frequency (<1 min) | Not supported natively | SQS delay queue + Lambda |
+
+**Key constraints:**
+
+- Minimum schedule interval: 1 minute
+- Lambda max timeout: 15 minutes — use Step Functions for longer
+- Always make scheduled Lambda idempotent (scheduler guarantees at-least-once)
+- Use EventBridge Scheduler over EventBridge rules for new projects (more features, flexible time windows)
+
+---
+
+## Choosing between patterns
+
+Most real applications combine multiple patterns:
+
+```
+                    ┌─ HTTP API ─── Lambda ─── DynamoDB
+Client ─── CloudFront ─┤
+                    └─ WebSocket ── Lambda ─── DynamoDB
+                                      │
+                                      ▼
+                              EventBridge
+                              ┌────┼────┐
+                              ▼    ▼    ▼
+                            SQS  SFN  Lambda
+                              │    │
+                              ▼    ▼
+                           Lambda  Bedrock
+```
+
+**Common combinations:**
+
+| Application | Patterns used |
+|---|---|
+| SaaS API backend | REST API + Event processing + Scheduled jobs |
+| E-commerce | REST API + Orchestration (order saga) + Fan-out (notifications) |
+| Data pipeline | Scheduled jobs + Event processing + Orchestration |
+| AI chatbot | Real-time streaming + Orchestration (agent loop) |
+| IoT processing | Event processing + Fan-out + Scheduled jobs (aggregation) |
+
+**Begin with a single pattern and add more as requirements grow.** A CRUD API with DynamoDB covers most initial implementations. Add event processing when you need async work. Add orchestration when you need multi-step workflows. Add fan-out when you need cross-service communication.

package/dist/global-skills/aws-serverless/references/concurrency.md

@@ -0,0 +1,200 @@
+# Lambda Concurrency Controls
+
+Four concurrency controls operate at different levels, solve different problems, and have complex interactions.
+
+## Contents
+
+- [The 4 concurrency types](#the-4-concurrency-types)
+- [Interaction matrix](#interaction-matrix)
+- [Decision scenarios](#decision-scenarios)
+- [Account limits and scaling](#account-limits-and-scaling)
+- [Common mistakes](#common-mistakes)
+- [SnapStart interaction](#snapstart-interaction)
+- [SAM/CDK examples](#samcdk-property-reference)
+
+---
+
+## The 4 concurrency types
+
+### 1. Reserved Concurrency
+Sets the **maximum** concurrent instances for a function and **reserves** that capacity from the account pool so no other function can consume it.
+
+- **Scope:** Function.
+- Reserve 400 → function always gets up to 400, never more. Others share the rest.
+- Setting to **0** completely throttles the function (emergency shutoff).
+- Use for: protecting critical functions, capping to protect downstream, emergency shutoff.
+
+### 2. Provisioned Concurrency
+Pre-initializes execution environments so they are **ready before requests arrive**.
+
+- **Scope:** Published version or alias (**NOT** `$LATEST`).
+- **Allocation rate:** Up to 6,000 environments per minute when provisioning.
+- Configure 100 on alias `PROD` → first 100 concurrent requests get sub-10ms startup.
+  Request 101+ spills to on-demand with cold starts.
+- **Account-level RPS quota**: RPS = 10 × account concurrency. For example, 1,000 account concurrency → 10,000 RPS cap across all functions. This is an account-level quota, not a per-instance throughput cap. Per-instance throughput = 1 / function duration.
+- Combine with **Application Auto Scaling** (target ~70% utilization).
+- Use for: user-facing APIs, functions with heavy init (ML models, DB pools).
+
+### 3. Maximum Concurrency
+Limits how many concurrent instances a **specific SQS event source mapping (ESM)** can invoke.
+
+- **Scope:** Per ESM. **Range:** 2–1,000. **Sources:** SQS only.
+- Does **not** reserve anything — other triggers can still consume function concurrency.
+- Use for: multiple SQS queues on one function, rate-limiting a specific queue.
+
+### 4. Provisioned Mode — ESM (Kafka 2024, SQS 2025)
+Allocates **dedicated event pollers** for an SQS or Kafka ESM with configurable min/max.
+
+- **Scope:** Per ESM.
+- Standard mode: ~5 pollers, +300/min, max 1,250 invokes. Provisioned mode: you control
+  min/max pollers. Each handles up to 1 MB/s, 10 concurrent invokes.
+- Use for: high-throughput SQS/Kafka, spiky traffic where standard ramp-up is too slow.
+
+---
+
+## Interaction matrix
+
+| Combination | OK? | Notes |
+|-------------|:---:|-------|
+| Reserved + Provisioned | Yes | Provisioned ≤ Reserved |
+| Reserved + Max Concurrency (ESM) | Yes | Reserved ≥ Σ(max concurrency across ESMs) |
+| Reserved + Provisioned Mode (ESM) | Yes | Independent layers |
+| Provisioned + Max Concurrency (ESM) | Yes | Different layers |
+| Provisioned + Provisioned Mode (ESM) | Yes | Warms envs vs warms pollers |
+| **Max Concurrency + Provisioned Mode (same ESM)** | No | **Mutually exclusive** |
+| **Provisioned Concurrency + SnapStart** | No | **Mutually exclusive** |
+
+**Key rules:** Account limit is the hard ceiling. Reserved carves from the pool — Lambda
+always keeps **100 unreserved**. Provisioned ≤ Reserved when both set. Max Concurrency is
+advisory to the ESM, not the function.
+
+```
+┌──────────────────────────────────────────────────────┐
+│  ACCOUNT: 1,000 concurrency                          │
+│  ┌─────────────────┐  ┌───────────────────────────┐  │
+│  │ RESERVED (400)   │  │ UNRESERVED POOL (600)     │  │
+│  │ ┌─────────────┐  │  │ Shared by all others      │  │
+│  │ │PROVISIONED  │  │  │ Must keep ≥100 always     │  │
+│  │ │(200 warm)   │  │  └───────────────────────────┘  │
+│  │ └─────────────┘  │                                 │
+│  │ + 200 on-demand  │  ESM LAYER (per mapping):       │
+│  └─────────────────┘  Max Concurrency — OR —          │
+│                        Provisioned Mode (not both)     │
+└──────────────────────────────────────────────────────┘
+```
+
+---
+
+## Decision scenarios
+
+| Scenario | Reserved | Provisioned | Max Conc (ESM) | Prov Mode (ESM) |
+|----------|:--------:|:-----------:|:--------------:|:---------------:|
+| Protect critical API from starvation | Yes | — | — | — |
+| Cap function to protect downstream DB | Yes | — | — | — |
+| Eliminate cold starts for user-facing API | Optional | Yes | — | — |
+| Multiple SQS queues, prevent hogging | Yes | — | Yes | — |
+| High-throughput SQS, low-latency | Optional | Optional | — | Yes |
+| Kafka ESM with spiky traffic | — | — | — | Yes |
+| Predictable daily traffic | — | Yes+AutoScale | — | — |
+| Emergency shutoff | Yes (=0) | — | — | — |
+| Java/.NET heavy init | — | Yes or SnapStart | — | — |
+
+**A — Checkout API:** Reserved=200 + Provisioned=150 + Auto Scaling for peak.
+**B — 3 SQS queues → 1 function:** Reserved=300, Max Concurrency=100 per ESM.
+**C — Kafka stream (spiky):** Provisioned Mode min=5, max=50 pollers.
+**D — Batch job:** Reserved=50, no provisioned.
+
+---
+
+## Account limits and scaling
+
+| Quota | Default | Adjustable? |
+|-------|---------|:-----------:|
+| Account concurrency | 1,000 / Region | Yes |
+| Reservable concurrency | Account − 100 | Scales |
+| RPS limit | 10 × concurrency | Scales |
+| Scaling rate | 1,000 envs / 10s / function | No |
+
+Scaling is per-function, continuously refilled, unused capacity does not accumulate.
+~50 seconds to reach 5,000 concurrency from zero.
+
+**At the limit:** Sync → 429. Async → retries up to 6h then DLQ. Streams → polling
+throttled, messages stay in source.
+
+**RPS constraint:** A 50ms function at 20,000 RPS needs only 1,000 concurrency but the RPS
+limit (10×1,000=10,000) throttles it. Request account concurrency = 2,000.
+
+```bash
+aws service-quotas request-service-quota-increase \
+  --service-code lambda --quota-code L-B99A9384 --desired-value 5000
+```
+
+---
+
+## Common mistakes
+
+1. **Reserved set to 0** — Blocks ALL invocations (429 TooManyRequestsException). Sometimes
+   set during an incident and not restored. If a function is throttled at low traffic, check
+   this first.
+
+2. **Reserved too low** — Reserve 50, need 80 → throttled at 51 even with spare account
+   capacity. Fix: monitor `ConcurrentExecutions`, set above peak + buffer.
+
+3. **Starving other functions** — Reserve 800/1,000 → others share 200. Reserved is
+   subtracted even when unused. Fix: be conservative.
+
+4. **Provisioned without auto scaling** — Paying for idle envs off-peak, spilling on-peak.
+   Fix: Auto Scaling targeting ~70% `ProvisionedConcurrencyUtilization`.
+
+5. **Provisioned on `$LATEST`** — Doesn't work. Fix: publish a version, create an alias.
+
+6. **Max concurrency > reserved** — ESM tries 100, function caps at 50. Fix: ensure
+   `reserved ≥ Σ(max concurrency across ESMs)`.
+
+7. **Confusing ESM max with reserved** — Max concurrency doesn't reserve anything. API
+   Gateway can still consume all concurrency. Fix: use reserved on the function.
+
+8. **Both ESM controls on same ESM** — Mutually exclusive; API rejects it. Fix: choose one.
+
+9. **Forgetting 100-unit buffer** — Max reservable = account limit − 100.
+
+10. **Not tracking ClaimedAccountConcurrency** — Provisioned counts against account limit
+   even when idle. Monitor the metric.
+
+---
+
+## SnapStart interaction
+
+| Aspect | SnapStart | Provisioned Concurrency |
+|--------|-----------|------------------------|
+| Cold start | Seconds → sub-second | Seconds → ~0 |
+| Runtimes | Java 11+, Python 3.12+, .NET 8+ | All |
+| Scales with traffic | Yes (snapshot restore) | Only up to provisioned count |
+
+> **SnapStart and Provisioned Concurrency are mutually exclusive on the same function.**
+
+```
+Is runtime Java 11+, Python 3.12+, or .NET 8+?
+├─ No  → Provisioned Concurrency
+└─ Yes
+   ├─ Need guaranteed <50ms on EVERY request? → Provisioned Concurrency
+   ├─ Need EFS or >512MB ephemeral storage?   → Provisioned Concurrency
+   └─ Otherwise → SnapStart first; if P99 still too high, switch to Provisioned Concurrency (they cannot coexist)
+```
+
+Limitations: no EFS, no >512MB ephemeral, no container images, must handle uniqueness,
+re-validate network connections on restore.
+
+---
+
+## SAM/CDK property reference
+
+| Concurrency type | SAM property | CDK property |
+|---|---|---|
+| Reserved | `ReservedConcurrentExecutions: 100` | `reservedConcurrentExecutions: 100` |
+| Provisioned | `AutoPublishAlias: live` + `ProvisionedConcurrencyConfig.ProvisionedConcurrentExecutions: 50` | `new lambda.Alias({ provisionedConcurrentExecutions: 50 })` — must use alias, not `$LATEST` |
+| Maximum Concurrency (ESM) | `ScalingConfig.MaximumConcurrency: 50` | `maxConcurrency: 50` on `EventSourceMapping` |
+| Provisioned Mode (ESM) | `ProvisionedPollerConfig.MinimumPollers` / `MaximumPollers` | `provisionedPollerConfig: { minimumPollers, maximumPollers }` on `EventSourceMapping` |
+| SnapStart | `SnapStart.ApplyOn: PublishedVersions` + `AutoPublishAlias` | `snapStart: lambda.SnapStartConf.ON_PUBLISHED_VERSIONS` |
+
+Auto scaling for Provisioned Concurrency: `alias.addAutoScaling({ minCapacity, maxCapacity })` then `scaling.scaleOnUtilization({ utilizationTarget: 0.7 })`.

package/dist/global-skills/aws-serverless/references/deployment.md

@@ -0,0 +1,94 @@
+# Deployment Reference
+
+Serverless-specific deployment patterns, resource types, and fast iteration tools.
+
+## Contents
+
+- [SAM resource types](#sam-resource-types)
+- [SAM Globals section](#sam-globals-section)
+- [CDK serverless constructs](#cdk-serverless-constructs)
+- [Fast iteration](#fast-iteration)
+
+---
+
+## SAM resource types
+
+SAM templates extend CloudFormation with `Transform: AWS::Serverless-2016-10-31`. Only `Transform` and `Resources` are required.
+
+| Resource Type | Purpose |
+|---|---|
+| `AWS::Serverless::Function` | Lambda + IAM role + event source mappings |
+| `AWS::Serverless::HttpApi` | HTTP API (API Gateway v2) — recommended |
+| `AWS::Serverless::Api` | REST API (v1) — WAF, usage plans, request validation |
+| `AWS::Serverless::SimpleTable` | DynamoDB with minimal config |
+| `AWS::Serverless::LayerVersion` | Lambda layer |
+| `AWS::Serverless::StateMachine` | Step Functions state machine |
+| `AWS::Serverless::Connector` | Simplified permissions between resources |
+| `AWS::Serverless::Application` | Nested serverless application (SAR or local) |
+| `AWS::Serverless::GraphQLApi` | AppSync GraphQL API |
+| `AWS::Serverless::WebSocketApi` | WebSocket API (API Gateway v2) |
+| `AWS::Serverless::CapacityProvider` | Lambda Managed Instances on customer-owned EC2 |
+
+---
+
+## SAM Globals section
+
+Eliminates duplication across functions/APIs. Supported types: `Function`, `Api`, `HttpApi`, `SimpleTable`, `StateMachine`, `CapacityProvider`.
+
+**Override rules:**
+
+| Type | Behavior |
+|---|---|
+| Primitives (string, number, boolean) | Resource value **replaces** global |
+| Maps (dictionaries) | **Merged** — resource keys override matching global keys |
+| Lists (arrays) | Global entries **prepended** to resource entries |
+
+---
+
+## CDK serverless constructs
+
+Prefer L2 constructs — they provide sensible defaults and least-privilege IAM via `grant*` methods.
+
+| Construct | Module | Use for |
+|---|---|---|
+| `NodejsFunction` | `aws-cdk-lib/aws-lambda-nodejs` | Node.js/TypeScript — bundles with esbuild automatically |
+| `PythonFunction` | `@aws-cdk/aws-lambda-python-alpha` | Python — requires Docker for bundling |
+| `HttpApi` | `aws-cdk-lib/aws-apigatewayv2` | HTTP API with CORS, JWT auth |
+| `HttpLambdaIntegration` | `aws-cdk-lib/aws-apigatewayv2-integrations` | Connect Lambda to HttpApi |
+
+---
+
+## Fast iteration
+
+Both tools are **development-only** — they bypass CloudFormation safety and introduce drift. Use `sam deploy` or CI/CD for production.
+
+### SAM Accelerate
+
+```bash
+sam sync --watch --stack-name my-stack                            # Watch mode — auto-syncs on save
+sam sync --code --watch --stack-name my-stack                     # Code-only (minimal sync time)
+sam sync --code --resource-id MyFunction --watch --stack-name my-stack  # Single function
+```
+
+Code changes sync via service APIs in seconds. Infrastructure changes trigger CloudFormation (slower, automatic).
+
+### CDK hotswap / watch
+
+```bash
+cdk deploy --hotswap           # Direct resource update, skips non-hotswappable
+cdk deploy --hotswap-fallback  # Hotswap with CloudFormation fallback
+cdk watch                      # Watch mode (hotswap + file watching)
+```
+
+Hotswap supports: Lambda code/config/versions/aliases, Step Functions definitions, ECS images, S3 deployments, CodeBuild projects, AppSync resolvers/functions/schemas.
+
+### Comparison
+
+| Feature | SAM Sync | CDK Hotswap |
+|---|---|---|
+| Watch mode | `sam sync --watch` | `cdk watch` |
+| Code-only sync | `sam sync --code` | `cdk deploy --hotswap` |
+| Fallback to full deploy | Automatic | `--hotswap-fallback` |
+| Selective resource sync | `--resource-id` | Not supported |
+| Code change speed | Seconds | Seconds |
+| Production safe | **No** | **No** |