Amazon Lambda

Lambda isn't an AI platform -- it's commonly used as the glue layer in AI workflows: invoking a model API (like Amazon Bedrock), running lightweight preprocessing or inference, or orchestrating multi-step AI pipelines via Step Functions, rather than training or hosting large models itself.

Practical Details

Container image support (up to 10GB) and ephemeral /tmp storage (up to 10GB) make it possible to bundle ML dependencies for lightweight inference, but the 15-minute timeout and memory ceiling make Lambda unsuitable for large model training or hosting heavy models directly.

Actionable Considerations

• Use Lambda to orchestrate or call AI services (like Bedrock), not to train or host large models yourself
• Package larger inference dependencies as a container image if you need more than the .zip package size allows
• Route genuinely long-running AI workloads to a different compute service, since Lambda's 15-minute cap will cut them off

Setup means packaging your code (as a .zip deployment package or a container image up to 10GB), choosing a runtime (Node.js, Python, Java, Go, .NET, or a custom runtime via the Runtime API), defining the handler function, and attaching an IAM execution role -- deployment then happens via the console, AWS SAM, CDK, Terraform, or the CLI.

Practical Details

Memory (128MB to 10GB) also scales CPU allocation proportionally, so under-provisioning memory can silently slow down CPU-bound code, not just risk out-of-memory errors; timeout is capped at 15 minutes, which rules out Lambda for genuinely long-running jobs.

Actionable Considerations

1. Use versions and aliases to roll out new code safely rather than overwriting the function others depend on
2. Tune memory deliberately, since it affects both cost and CPU speed, not just whether the function fits in RAM
3. Confirm your workload fits within the 15-minute timeout before building it as a single Lambda function

Lambda scales by running many concurrent execution environments automatically as invocations arrive -- there's no server capacity to provision, but there is a concurrency limit (a default account-level cap, adjustable, and shareable across functions unless you reserve concurrency per function).

Practical Details

Cold starts (the latency of initializing a fresh execution environment) are the real performance gotcha for latency-sensitive workloads -- Provisioned Concurrency keeps a set number of environments warm and ready, at an always-on cost, specifically to eliminate that cold-start delay.

Actionable Considerations

1. Set reserved concurrency on functions that must not be starved by other functions sharing the account-level limit
2. Use Provisioned Concurrency for latency-sensitive functions where cold starts are unacceptable, understanding it adds always-on cost
3. Monitor for throttling errors as invocation volume grows, since hitting the concurrency limit causes requests to be throttled, not queued indefinitely

You're billed per request plus compute duration measured in GB-seconds (memory allocated multiplied by execution time), not for idle capacity -- a function that isn't invoked costs nothing beyond the free tier's baseline.

Practical Details

The free tier (1 million requests and 400,000 GB-seconds per month) applies on an ongoing monthly basis, not just during a trial; Provisioned Concurrency is billed separately as an always-on cost since it keeps environments warm regardless of invocation volume, and ephemeral storage beyond the free 512MB also adds cost.

Actionable Considerations

• Model cost using GB-seconds (memory x duration), not just request count, since memory setting directly affects the bill
• Remember Provisioned Concurrency is billed continuously, unlike standard on-demand Lambda pricing
• Watch ephemeral storage usage if you configure more than the free 512MB /tmp allocation

Every function runs under an IAM execution role that defines exactly what AWS resources it can access -- the real security discipline is scoping that role tightly (least privilege) rather than reusing a broad, shared role across many functions.

Practical Details

A function that needs to reach resources inside a VPC (like an RDS database) requires explicit VPC configuration, and environment variables can be encrypted at rest with KMS for secrets that shouldn't sit in plaintext config.

Actionable Considerations

• Write a dedicated, narrowly-scoped IAM role per function rather than sharing one broad role across many functions
• Encrypt sensitive environment variables with KMS instead of storing secrets in plaintext
• Configure VPC access explicitly only when a function genuinely needs to reach private resources like an RDS instance

Lambda isn't a SaaS product with user engagement metrics -- it's infrastructure, so the realistic adoption pattern is teams moving specific workloads (API backends, event processing, scheduled jobs) to it incrementally, not an all-at-once platform migration.

Practical Details

The concrete payoff teams report is reduced operational overhead (no servers to patch or scale manually) and pay-per-use billing, which matters most for spiky or intermittent workloads rather than steady, predictable, high-volume traffic.

Actionable Considerations

1. Start with event-driven or intermittent workloads, where Lambda's pay-per-use model clearly beats always-on servers
2. Evaluate steady, high-volume workloads against Lambda's per-invocation pricing before assuming it's automatically cheaper
3. Expect incremental workload-by-workload adoption rather than a single platform-wide cutover

Lambda functions are triggered by event sources -- S3 object events, API Gateway requests, SQS/SNS messages, DynamoDB Streams, EventBridge rules, and Kinesis streams are the common ones -- rather than Lambda polling or pulling data on its own initiative in most cases.

Practical Details

Step Functions is the real mechanism for orchestrating multi-step workflows across several Lambda functions (with retries, branching, and error handling built in), and Destinations lets you route the success or failure result of an asynchronous invocation without writing that routing logic yourself.

Actionable Considerations

• Choose the event source that matches your workload (S3 for file processing, SQS for decoupled queues, EventBridge for scheduled or cross-service events)
• Use Step Functions instead of chaining Lambda-to-Lambda invocations manually for multi-step workflows
• Configure Destinations to handle async invocation outcomes rather than building custom success/failure routing

The fastest path is the AWS Lambda console's "Create function" with a blueprint, or `sam init` with AWS SAM CLI for a scaffolded project you can develop and test locally before deploying -- either way, you're writing a handler function and picking a runtime.

Practical Details

The AWS free tier includes 1 million free requests and 400,000 GB-seconds of compute per month on an ongoing basis (not just a trial period), which is enough for most people to experiment and build small production workloads without incurring charges.

Actionable Considerations

1. Use AWS SAM or the CDK for anything beyond a single throwaway function, since it gives you local testing and repeatable deployment
2. Start with a generous timeout and moderate memory setting, then tune both down once you've measured actual execution behavior
3. Track usage against the free tier early so cost surprises don't show up only once you're at scale

Every invocation's logs land in CloudWatch Logs automatically, and X-Ray tracing (if enabled) shows where time is spent across a request -- those two are the real starting points for diagnosing an issue, not guesswork.

Practical Details

The recurring failure modes are timeout errors (execution exceeded the configured timeout), throttling (ConcurrentExecutions limit reached), out-of-memory kills (the function exceeded its configured memory), and IAM AccessDenied errors from an execution role missing a needed permission.

Actionable Considerations

1. Check CloudWatch Logs first for the specific error and stack trace before assuming a platform-level problem
2. If you see throttling errors, check concurrency usage against your account or function-level limit
3. For AccessDenied errors, review the execution role's permissions rather than assuming a Lambda service issue