Serverless Architecture: When to Use It and When to Avoid It

We had a client who was paying $3,200/month for two EC2 instances that ran a batch processing job for 4 hours per day. We moved it to Lambda + Step Functions. Monthly cost: $47. Same job, same output, 98.5% cost reduction.

Another client moved their entire REST API to Lambda. Monthly cost went from $800 on ECS to $2,400 on Lambda — because the API handled 50 million requests per month with consistent, predictable traffic. Wrong workload.

Serverless isn't universally cheaper, faster, or better. It's a tool with specific strengths. At Pillai Infotech, we've migrated workloads to serverless and migrated workloads away from serverless. This guide helps you figure out which direction to go.

What Serverless Really Means

Serverless doesn't mean "no servers." It means you don't manage servers. The cloud provider handles provisioning, scaling, patching, and availability. You write functions, the provider runs them.

The Serverless Spectrum

Serverless isn't binary. It's a spectrum from fully managed to fully self-hosted:

Our recommendation for most teams today: start at the Container-as-a-Service level (Cloud Run, App Runner). You get most of the serverless benefits — zero server management, scale-to-zero, pay-per-use — without the function-level constraints of FaaS. Move to pure FaaS for event-driven workloads where it fits naturally.

When Serverless Is the Right Choice

Serverless excels in specific scenarios. Here's where we consistently see it deliver value:

1. Event-Driven Processing

File uploads that trigger processing. Webhooks from third-party services. Database change streams. Queue consumers. These are the bread and butter of serverless — sporadic, unpredictable triggers where maintaining an always-on server wastes money.

Example: An e-commerce client processes product images after upload — resize, compress, generate thumbnails, extract colors. Each upload triggers a Lambda function. Traffic: 0 at 3 AM, 5,000/hour during flash sales. Pay only for what runs. Perfect fit.

2. Scheduled Jobs and Batch Processing

Jobs that run on a schedule — daily reports, weekly data aggregation, hourly syncs. Instead of a cron server running 24/7, use EventBridge + Lambda or Cloud Scheduler + Cloud Functions.

3. API Backends with Variable Traffic

APIs where traffic varies dramatically — 100 requests during business hours, 5 at midnight, 10,000 during marketing campaigns. Serverless scales automatically in both directions, including to zero.

4. Prototypes and MVPs

When you're validating an idea, serverless minimizes upfront infrastructure investment. No capacity planning, no cluster sizing. Deploy, test, iterate. If the idea fails, you spent near-zero on infrastructure.

5. Glue Code and Integrations

Small functions that connect systems — transform data between APIs, route events, send notifications. These don't justify their own server or container.

When to Avoid Serverless

This is the section most serverless articles skip. Knowing when not to use serverless is more valuable than knowing when to use it.

1. Steady, High-Throughput Workloads

If your service handles consistent traffic (1,000+ requests/second around the clock), containers or VMs are cheaper. Serverless pricing is per-invocation + per-GB-second. At steady high volume, those fractions add up to more than a reserved instance.

The crossover point: When your Lambda function would run at 60%+ concurrency 24/7, containers become cheaper. We've calculated this for dozens of clients — the break-even is typically around 500K-1M requests/day for a typical API endpoint.

2. Long-Running Processes

Lambda has a 15-minute maximum execution time. Cloud Functions: 60 minutes. If your job takes longer — video transcoding, large data processing, ML training — serverless functions won't work directly. You can orchestrate with Step Functions, but complexity increases.

3. Latency-Sensitive Applications

Cold starts add 100ms-2s of latency on the first invocation (depending on runtime and memory). For user-facing APIs where every millisecond matters — real-time gaming, financial trading, live video processing — this is unacceptable. Provisioned concurrency helps but eliminates the cost advantage.

4. Complex Stateful Applications

Functions are stateless by design. If your application needs in-memory state (WebSocket connections, session management, caches), serverless adds complexity. You'll need external state stores (Redis, DynamoDB) for everything, which adds latency and cost.

5. GPU or Specialized Hardware Workloads

ML inference with GPUs, video encoding with hardware acceleration, cryptographic operations — these need specific hardware. While AWS now offers Lambda with GPU access in limited regions, it's expensive and constrained. Use EC2, GKE with GPU nodes, or managed ML platforms instead.

The Cold Start Reality in 2026

Cold starts are the most discussed serverless limitation. Here's the current state — because the numbers have improved significantly:

Mitigating Cold Starts

• Provisioned concurrency: Keep N instances warm. Eliminates cold starts but costs money regardless of traffic. Use for latency-critical endpoints only.
• Smaller packages: Bundle only what you need. Tree-shake dependencies. A 5MB deployment package starts 3-5x faster than a 50MB one.
• Lazy initialization: Don't load everything at startup. Initialize database connections and heavy clients on first use, not at module load.
• Choose the right runtime: Go and Rust start in under 50ms. If cold starts matter, choose a fast-starting runtime or use SnapStart (Java) / Native AOT (.NET).
• Cloud Run / App Runner: Container-based serverless with minimum instance settings. One warm instance handles initial requests while more scale up.

Cost Analysis: The Crossover Point

Let's do real math. Here's a comparison for an API endpoint handling different traffic levels on AWS:

Assumptions: 128MB Lambda, 200ms avg duration, t3.medium EC2, 0.25 vCPU Fargate task.

The crossover point is around 3-5 million requests per month for a typical API. Below that, Lambda wins. Above that, containers or VMs are more cost-effective — unless your traffic is extremely spiky (10x peaks vs. baseline), in which case Lambda's scale-to-zero still wins.

Serverless Platform Comparison (2026)

Our picks by use case:

• General-purpose serverless: AWS Lambda — largest ecosystem, most event sources, best tooling
• Container-based serverless: Google Cloud Run — simplest developer experience, great for web apps
• Edge computing: Cloudflare Workers — 0ms cold starts, global by default, growing fast
• Complex workflows: Azure Durable Functions — built-in state management, fan-out/fan-in, human-in-the-loop

For a deeper comparison of cloud platforms beyond serverless, see our AWS vs Azure vs GCP comparison.

Serverless Patterns That Work

1. API Gateway + Function Pattern

The most common pattern. API Gateway handles routing, auth, rate limiting. Lambda handles business logic. Each route maps to a function (or a monolithic handler for simpler apps).

When to use single-function vs. function-per-route: Start with a single handler function that routes internally. Split into separate functions only when individual routes need different memory/timeout settings or independent scaling.

2. Event Processing Pipeline

Events flow through a chain: source → queue → processor → store. Each step is a separate function. The queue (SQS, Pub/Sub) provides buffering, retry, and dead-letter handling.

# Step Functions workflow for document processing
{
  "StartAt": "ExtractText",
  "States": {
    "ExtractText": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:extract-text",
      "Next": "ClassifyDocument"
    },
    "ClassifyDocument": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:classify",
      "Next": "RouteByType"
    },
    "RouteByType": {
      "Type": "Choice",
      "Choices": [
        { "Variable": "$.type", "StringEquals": "invoice",
          "Next": "ProcessInvoice" },
        { "Variable": "$.type", "StringEquals": "contract",
          "Next": "ProcessContract" }
      ],
      "Default": "Archive"
    }
  }
}

3. Fan-Out / Fan-In

Split a large job into parallel chunks, process each independently, aggregate results. Step Functions Map state or SQS + Lambda handles this naturally. We use this for batch processing — a client processes 100K product price updates nightly with 500 concurrent Lambda functions completing in under 3 minutes.

4. Scheduled Tasks (Cron Replacement)

EventBridge Scheduler + Lambda replaces cron servers. Each scheduled task is a separate function with its own schedule, retry policy, and monitoring. No cron server to maintain, no single point of failure.

5. Backend for Frontend (BFF)

Each frontend (web, mobile, admin) gets its own API layer implemented as serverless functions. The BFF aggregates calls to backend microservices, transforms data for each frontend's needs, and handles client-specific caching.

Vendor Lock-In: How Bad Is It Really?

This is the concern we hear most. Let's be honest about it.

What's Actually Locked In

• Event sources: S3 triggers, DynamoDB streams, EventBridge rules — these are deeply AWS-specific. GCP and Azure equivalents exist but aren't compatible.
• Orchestration: Step Functions state machines don't port to Cloud Workflows or Durable Functions without a rewrite.
• Proprietary services: DynamoDB, Cognito, API Gateway configurations — tightly coupled to the platform.

What's Portable

• Business logic: Your function code (the actual algorithms, data processing, business rules) is completely portable. It's just Node.js, Python, Go, etc.
• Databases: If you use PostgreSQL (via RDS or Aurora) instead of DynamoDB, your data layer is portable.
• Container-based serverless: Cloud Run, App Runner, and Azure Container Apps all run standard Docker containers. Moving between them is significantly easier than moving between FaaS platforms.

Our Recommendation

Don't optimize for portability at the expense of productivity. In practice, fewer than 5% of companies actually switch cloud providers. The ones that do usually have bigger problems than function rewrites.

That said, keep your business logic clean and separated from platform glue code. Your handler function should call a business logic module that knows nothing about Lambda or API Gateway. If you ever need to move, you rewrite the thin handler layer, not the business logic.

For teams deeply concerned about lock-in, container-based serverless (Cloud Run, App Runner) offers the best balance of serverless benefits with portability. See our Docker best practices for containerization guidance.

Building Your Serverless Strategy

Decision Framework

For each workload, ask these five questions:

1. Is traffic spiky or steady? Spiky → serverless. Steady high-volume → containers.
2. Is latency critical? Sub-100ms required → containers or provisioned concurrency. 200ms+ acceptable → serverless is fine.
3. Is it event-driven? Reacting to events (file uploads, messages, schedule) → serverless. Request/response with persistent connections → containers.
4. What's the execution duration? Under 15 minutes → Lambda. Under 60 minutes → Cloud Functions. Longer → containers.
5. What's the team's expertise? New to infrastructure → serverless reduces operational burden. Strong ops team → containers give more control.

At Pillai Infotech, most of our new projects use a hybrid approach: Cloud Run for APIs and web services (portable, no cold start with min instances) + Lambda/Cloud Functions for event processing (natural fit, cost-effective). This gives the best of both worlds — and it's the pattern we recommend for most teams starting their cloud-native journey.