Raff Functions is an AWS Lambda alternative for teams that want free requests and egress, active-CPU pricing, portable handlers, and execution windows beyond Lambda's 15-minute limit. AWS Lambda remains stronger for global AWS-native architectures that depend on its mature event integrations, regional footprint, IAM, CloudWatch, API Gateway, S3, DynamoDB, EventBridge, and enterprise governance. Pricing depends on workload shape: Lambda's 1 million request and 400,000 GB-second free tier can be cheaper for small or lightly used functions, while Raff can become more economical as duration, egress, or request volume grows. Choose AWS Lambda for ecosystem depth and hyperscale maturity; choose Raff Functions for simpler cost controls, fewer billing lines, and a more portable operating model.
For the broader architecture decision, start with Serverless Functions vs VMs for Small Teams.
AWS Lambda vs Raff: which is right for you?
The decision is not simply which provider has the lower unit rate. It is whether your workload benefits more from AWS integration or from a narrower function platform with simpler billing and fewer platform-specific assumptions.
| Decision factor | Choose Raff Functions | Choose AWS Lambda |
|---|
| Existing cloud stack | You want Functions, VMs, managed databases, object storage, and Apps in one compact Raff environment | Your application already depends on AWS accounts, IAM, S3, DynamoDB, EventBridge, API Gateway, CloudWatch, or other AWS services |
| Cost model | You prefer free requests and egress, memory plus active-CPU billing, and a spend cap on by default | You benefit from 1 million free requests and 400,000 free GB-seconds each month |
| Execution length | Jobs may exceed 15 minutes or need a 1-hour default window | Every invocation can finish within the 900-second Lambda limit |
| Portability | You want standard HTTP handlers and a Dockerfile path that can move more easily | You accept Lambda handlers, event formats, and AWS-specific deployment conventions |
| Global placement | One us-east region fits the workload | You need AWS's broad regional footprint |
| Operational maturity | You want a smaller platform and direct support | You need AWS's mature governance, documentation, partner, and enterprise ecosystem |
AWS Lambda is the safer default for organizations already standardized on AWS. Raff Functions is the clearer alternative for small teams that want event-driven compute without adding request fees, function egress charges, and a growing set of adjacent AWS services to every deployment.
AWS Lambda overview
AWS Lambda is AWS's managed functions-as-a-service platform. It runs code in response to HTTP requests, schedules, queues, streams, storage events, database events, and many other triggers across the AWS ecosystem.
Its strongest advantage is integration depth. Lambda connects naturally with services such as Amazon S3, Amazon API Gateway, Amazon EventBridge, Amazon SQS, Amazon SNS, DynamoDB, Kinesis, Step Functions, CloudWatch, Secrets Manager, and IAM. For teams already using those services, Lambda can remove infrastructure management while preserving AWS-native security and governance.
Lambda supports managed runtimes, custom runtimes, zip packages, and Linux container images. Container images can be as large as 10 GB uncompressed, but they must implement the Lambda runtime interface and be stored in Amazon ECR in the same AWS Region as the function.
Lambda is designed for short-lived, stateless execution. A standard invocation can run for up to 900 seconds, or 15 minutes. Memory can be configured from 128 MB to 10,240 MB, and CPU allocation increases with memory. The default regional concurrency quota is 1,000 executions per account, with quota increases available.
This operating model is mature and powerful, but it introduces platform-specific concepts: Lambda event objects, IAM permissions, execution roles, event-source mappings, CloudWatch logs, API Gateway configuration, concurrency controls, and service-specific billing. That complexity is reasonable when the wider AWS platform is the objective.
Raff Functions overview
Raff Functions is event-driven compute for HTTP handlers, webhooks, cron schedules, object-storage events, one-off future tasks, AI jobs, ETL, and batch workloads.
Raff uses a two-meter pricing model:
- Memory at $0.0000035 per GB-second
- Active CPU at $0.000020 per vCPU-second
- Requests are free
- Function egress is free
- A spend cap is on by default
- The monthly free tier includes 100,000 GB-seconds and 10,000 vCPU-seconds
Raff Functions supports standard application-style handlers, including Python FastAPI or ASGI, Node.js standard http, TypeScript, JavaScript Web Fetch, Go net/http, and a Dockerfile escape hatch for other languages or custom runtimes. The purpose is to keep function code close to ordinary application code instead of requiring a Raff-specific handler signature.
Execution windows are also different. Raff Functions supports timeouts up to 1 hour by default and up to 24 hours on request. That expands the function model beyond short web handlers into bounded AI inference, ETL, file processing, imports, exports, and batch work that would exceed Lambda's 15-minute limit.
Raff also provides a migration path for existing Lambda workloads. Teams can import Lambda code, review the required changes, and move toward standard handlers rather than carrying AWS-specific event and response shapes into every future deployment.
The tradeoff is platform scale. Raff currently serves Functions from one us-east region and does not match AWS's global regional footprint or its catalog of event integrations. Raff is best when the workload fits the available region and the team values cost clarity, portability, and direct support over hyperscale ecosystem breadth.
AWS Lambda pricing vs Raff Functions pricing
AWS Lambda Functions are billed by request count and execution duration. In US East on x86, the standard on-demand example rate is $0.20 per 1 million requests and $0.0000166667 per GB-second after the free tier. The monthly free tier includes 1 million requests and 400,000 GB-seconds.
AWS also has additional pricing dimensions that may apply:
- Provisioned Concurrency
- Extra ephemeral storage above the included amount
- HTTP response streaming beyond free allowances
- CloudWatch logs and metrics
- API Gateway
- Data transfer
- Event-source services such as SQS, SNS, Kinesis, or EventBridge
- ECR storage for container images
Raff Functions meters memory and active CPU separately. Requests and egress do not create function-specific charges. This makes I/O-heavy handlers easier to model because time waiting on databases, storage, or external APIs does not have to be treated exactly like active CPU consumption.
The following examples apply both monthly free tiers. AWS estimates use x86 on-demand Lambda pricing in US East. Raff estimates use the listed active CPU seconds rather than assuming CPU is active for the full wall-clock duration. They exclude logs, databases, queues, gateways, storage, and other connected services.
| Monthly workload | Raff Functions | AWS Lambda |
|---|
| 1M requests, 128 MB, 100 ms, 10k active vCPU-s | $0.00 | $0.00 |
| 3M requests, 256 MB, 200 ms, 60k active vCPU-s | About $1.18 | About $0.40 |
| 10M requests, 512 MB, 300 ms, 500k active vCPU-s | About $14.70 | About $20.13 |
| 5M requests, 1 GB, 1 second, 1M active vCPU-s | About $36.95 | About $77.47 |
| 1M requests, 2 GB, 5 seconds, 1M active vCPU-s | About $54.45 | About $160.00 |
| 100k requests, 4 GB, 600 seconds, 12M active vCPU-s | About $1,079.45 | About $3,993.34 |
These are planning examples, not a universal price guarantee. Real cost depends on architecture, region, processor, memory, execution duration, active CPU behavior, retries, concurrency, response size, and connected services.
The pricing result changes by workload:
- Very small workloads: AWS Lambda can be cheaper because its free tier is larger.
- Request-heavy workloads: Raff removes the request line entirely.
- I/O-heavy workloads: Raff's active-CPU meter may reduce the cost of time spent waiting.
- Long-running workloads: Raff can support jobs that Lambda cannot complete in one 15-minute invocation.
- AWS-native workloads: Lambda may still be operationally cheaper because it avoids moving data and events outside AWS.
The correct comparison is total architecture cost, not only the function line item.
Bandwidth and transfer policy
Raff Functions includes free function egress. A handler can return API responses, call external services, or move output without adding a separate Raff Functions egress charge.
AWS Lambda pricing is more context-dependent. Standard AWS data-transfer rules can apply depending on where data moves, and the surrounding architecture may add API Gateway, CloudFront, NAT Gateway, VPC, or other service charges. Some same-region AWS service paths are free or discounted, so Lambda is not automatically expensive for transfer.
This creates two different strengths.
Raff is easier to forecast when functions send public responses, call external APIs, or produce variable outbound traffic. AWS is stronger when the function communicates primarily with AWS services through optimized same-region paths and the organization already understands the associated network architecture.
For large files, neither platform should automatically return everything through a function response. A better design is often:
Function
↓
Object storage
↓
Signed or controlled download path
On Raff, use Raff Object Storage for generated files, reports, exports, images, and artifacts. On AWS, teams commonly use Amazon S3 and CloudFront or signed S3 URLs.
The practical rule is simple: use functions to authorize, transform, and coordinate data; use object storage to hold large durable files.
Feature comparison: AWS Lambda vs Raff
Runtime and deployment
| Feature | Raff Functions | AWS Lambda |
|---|
| Standard HTTP handlers | FastAPI/ASGI, Node http, Web Fetch, Go net/http | Possible through adapters, frameworks, Function URLs, or API Gateway |
| Provider-specific handler required | No Raff-specific signature for supported standard handlers | Lambda handler and event model are standard in AWS workflows |
| Zip deployment | Platform workflow | Supported |
| Container deployment | Dockerfile escape hatch | Linux images up to 10 GB through ECR and Lambda runtime interface |
| Custom languages | Dockerfile path | Custom runtime or compatible container image |
| Local portability | Stronger when standard handlers are used | Strong with SAM, containers, and frameworks, but AWS assumptions may remain |
Triggers and integrations
| Feature | Raff Functions | AWS Lambda |
|---|
| HTTP endpoints | Included live URLs with TLS | Function URLs or API Gateway |
| Cron schedules | Included and timezone-aware | EventBridge Scheduler or scheduled rules |
| Object-storage events | Raff Object Storage events | Amazon S3 events |
| One-off future execution | Supported | Usually built with EventBridge Scheduler or another AWS service |
| Queue and stream ecosystem | Narrower | Extensive SQS, SNS, Kinesis, DynamoDB, Kafka, and EventBridge integrations |
| Broader cloud catalog | Compact Raff platform | Very broad AWS service catalog |
Execution and scaling
| Feature | Raff Functions | AWS Lambda |
|---|
| Scale to zero | Yes | Yes |
| Maximum standard duration | 1 hour by default; up to 24 hours on request | 15 minutes |
| Memory model | Memory billed by GB-second | Memory from 128 MB to 10,240 MB |
| CPU model | Active CPU billed separately | CPU scales with configured memory |
| Warm capacity | Optional warm instances | Provisioned Concurrency |
| Default account concurrency | Platform-managed limits | 1,000 per Region, increaseable |
Data and persistence
| Feature | Raff Functions | AWS Lambda |
|---|
| Local runtime state | Ephemeral; durable state should be external | Ephemeral; durable state should be external |
| Managed database binding | Raff Managed Databases | RDS, Aurora, DynamoDB, and other AWS services |
| Object storage binding | Raff Object Storage | Amazon S3 |
| Writable temporary storage | Runtime-dependent | 512 MB to 10,240 MB /tmp |
| Durable files | Store in object storage | Store in S3 or another durable service |
Cost controls
| Feature | Raff Functions | AWS Lambda |
|---|
| Request charge | Free | $0.20 per 1M after free tier |
| Function egress charge | Free | Depends on destination and AWS transfer rules |
| Free compute | 100k GB-s and 10k vCPU-s | 400k GB-s |
| Free requests | Unlimited as a priced line | 1M monthly, then billed |
| Spend cap | On by default | Use AWS Budgets, quotas, concurrency, and account controls |
| Provisioned warm capacity | 30% of memory rate | Separate Provisioned Concurrency pricing |
Operations and observability
| Feature | Raff Functions | AWS Lambda |
|---|
| Logs and metrics | Included function logs and metrics | CloudWatch integration |
| IAM and governance | Simpler Raff account model | Deep IAM, Organizations, CloudTrail, Config, and enterprise controls |
| Infrastructure as code | Raff platform tooling | CloudFormation, SAM, CDK, Terraform, Serverless Framework, and more |
| Migration portability | Standard handlers and Lambda import path | Strong AWS-native tooling; migration effort depends on AWS coupling |
| Support model | Direct Raff support | AWS documentation, community, partners, and paid support plans |
Features and reliability: Raff vs AWS Lambda
This comparison does not include a performance benchmark. Serverless performance depends on runtime, package size, memory allocation, processor architecture, cold starts, warm capacity, region, downstream services, network path, and code behavior. A credible benchmark would require matched functions, identical dependencies, repeated warm and cold runs, controlled network targets, and current production environments on both platforms.
AWS Lambda has the stronger reliability history and operational scale. It has run production event workloads for more than a decade, operates across many AWS Regions, and integrates with mature AWS monitoring, identity, auditing, and support systems.
Raff is newer and geographically narrower. The Raff platform reports 3,000+ customers, 15,000+ production VMs, a 99.9% uptime SLA, a Trustpilot rating of 4.4/5, and a G2 rating of 4.6/5. These are useful trust signals, but they do not equal AWS's history or global scale.
Raff's reliability advantage is not hyperscale redundancy. It is operational simplicity for teams whose workload fits the platform:
- Fewer required services for a basic HTTP, cron, or storage-event workload
- Default spend protection
- Included logs and metrics
- Direct support
- Longer execution windows
- Standard handlers that can move to a VM or container if the workload changes
AWS's reliability advantage is ecosystem depth:
- Multiple Regions and Availability Zones
- Mature service integrations
- Enterprise identity and governance
- Large documentation and partner ecosystem
- Advanced concurrency controls
- Established incident and support processes
- Broad infrastructure options if Lambda is no longer the right runtime
Choose reliability based on the whole application. A function platform cannot compensate for a fragile database, missing retries, non-idempotent code, poor secrets management, or an untested recovery path.
When you should choose AWS Lambda over Raff
Choose AWS Lambda when:
- Your application already runs primarily on AWS.
- Events originate from S3, DynamoDB, SQS, SNS, Kinesis, EventBridge, API Gateway, or other AWS services.
- You need deployment across several AWS Regions.
- Your organization relies on AWS IAM, Organizations, CloudTrail, Config, Security Hub, or existing account controls.
- You need mature enterprise procurement, support, marketplace, partner, or compliance workflows.
- Every standard invocation completes within 15 minutes.
- Lambda's 1 million request and 400,000 GB-second monthly free tier covers most of the workload.
- Your developers already use SAM, CDK, CloudFormation, Terraform, or Serverless Framework around AWS.
- Moving data outside AWS would create more cost, latency, or operational complexity than it saves.
- You want the deepest selection of event sources and managed integrations.
AWS Lambda is especially strong when the function is one component inside an AWS-native architecture rather than a standalone compute decision.
When you should choose Raff over AWS Lambda
Choose Raff Functions when:
- You want free requests and free function egress.
- You want memory and active CPU billed separately.
- A default spend cap is important for a small team.
- Jobs may exceed Lambda's 15-minute maximum.
- You want standard application-style handlers rather than Lambda-specific event shapes.
- You need HTTP, cron, webhook, object-storage, or one-off workloads without assembling several AWS services.
- Your application already uses Raff VM, Raff Apps, Managed Databases, or Object Storage.
- One us-east region fits the workload.
- You prefer direct support and a smaller operating surface.
- You want an easier path from functions to containers, VMs, or other infrastructure later.
Raff is not a drop-in replacement for every AWS integration. It is strongest when the function can be expressed as a clear HTTP request, scheduled task, storage event, webhook, or bounded background job.
Migrating from AWS Lambda to Raff
A safe migration starts by separating business logic from AWS-specific adapters.
- Inventory every Lambda dependency. Record runtimes, memory, timeout, environment variables, layers, container images, IAM roles, triggers, destinations, dead-letter queues, concurrency settings, VPC access, CloudWatch alarms, and connected services.
- Classify the trigger. Map API Gateway or Function URLs to HTTP handlers, EventBridge schedules to Raff cron, S3 events to Raff Object Storage events, and suitable asynchronous tasks to one-off or event-driven functions.
- Extract portable business logic. Move validation, transformations, database access, and application rules out of
event and context handling. Keep AWS event parsing in a thin adapter until cutover.
- Create the Raff function. Select a standard handler or Dockerfile, configure memory and timeout, add environment variables and secrets, and bind the required database or object-storage credentials.
- Test with production-shaped events. Compare successful responses, error behavior, retries, idempotency, logs, duration, memory, active CPU, database connections, and external API behavior.
- Cut over gradually. Route a small share of HTTP traffic, switch one cron schedule, or mirror selected events. Keep the Lambda function available until the rollback window closes.
Common migration gotchas include:
- Lambda event payloads do not automatically match standard HTTP or storage-event inputs.
- IAM permissions must be replaced with scoped Raff credentials and bindings.
- CloudWatch alarms, dashboards, and log retention need a new operating plan.
- API Gateway authentication, throttling, custom domains, and authorizers may require separate replacements.
- SQS, SNS, Kinesis, DynamoDB Streams, Step Functions, and EventBridge integrations are not direct one-to-one Raff equivalents.
- Lambda layers and ECR images may contain AWS-specific runtime assumptions.
- VPC-only databases or services may not be reachable after migration without network changes.
- Retries can create duplicate work on either platform, so handlers should be idempotent.
- A 15-minute Lambda workflow may have been split into several functions; Raff's longer timeout can simplify it, but combining steps should not remove failure visibility.
For migration design, use Portable Serverless Handlers: Avoiding Lambda Lock-In and Long-Running Serverless Functions for AI, ETL, and Batch Jobs.
About AWS Lambda
<a href="https://aws.amazon.com/lambda/" rel="external nofollow noopener">AWS Lambda</a> is Amazon Web Services' event-driven serverless compute platform. It runs functions from managed runtimes, custom runtimes, zip packages, or compatible Linux container images and integrates with a wide range of AWS services.
AWS Lambda pricing and quotas in this comparison were checked against official AWS sources on July 30, 2026. Pricing varies by Region, processor architecture, concurrency model, transfer path, and connected services.
Conclusion: AWS Lambda or Raff?
AWS Lambda is the stronger choice for AWS-native organizations that need global regions, deep event integrations, mature IAM and governance, and a long production history.
Raff Functions is the stronger AWS Lambda alternative when the workload fits us-east and the priorities are free requests, free function egress, active-CPU pricing, default spend protection, portable handlers, and execution beyond 15 minutes.
The final decision comes down to five questions:
- Ecosystem: Does the function depend on AWS services or can it run as a standard HTTP, cron, webhook, storage-event, or batch workload?
- Duration: Can every invocation finish within 15 minutes?
- Cost shape: Is the workload covered by Lambda's larger free tier, or will request volume, active duration, and outbound traffic make Raff easier to forecast?
- Portability: Is the team comfortable with Lambda event models, or should business logic stay closer to standard application code?
- Regions: Does one us-east region fit, or is AWS's global placement required?
Choose AWS Lambda when AWS integration is the product advantage. Choose Raff Functions when a simpler serverless operating model is the product advantage.