Engineering Notes

step functions and difference beterrn ecs and eks

6 min read

Absolutely. Given your resume, prepare these as architecture-level interview answers, not just AWS definitions.

1. AWS Step Functions

One-line answer

AWS Step Functions is a serverless workflow orchestration service used to coordinate multiple distributed steps, handle retries/errors/timeouts, and maintain workflow state.

Think:

Order API
   │
   ▼
Step Functions
   │
   ├── Validate Order
   │       ↓
   ├── Charge Payment
   │       ↓
   ├── Update Inventory
   │       ↓
   ├── Send Notification
   │
   └── Failure → Compensation / Retry

Instead of putting everything into one Lambda:

❌ Lambda
   ├── validate
   ├── payment
   ├── inventory
   ├── notification
   └── error handling

you can orchestrate independent components.

2. Why Step Functions?

Imagine:

Order
 ↓
Payment
 ↓
Inventory
 ↓
Shipping

Payment fails temporarily.

You may want:

Payment
   ↓
Retry 3 times
   ↓
Still failing
   ↓
Mark order failed
   ↓
Notify customer

Step Functions gives you workflow-level capabilities such as:

  • retries

  • catches

  • timeouts

  • branching

  • parallel execution

  • sequencing

  • workflow state

  • error handling

Interview keywords

Orchestration · State machine · Workflow · Retry · Catch · Timeout · Parallel · Choice · Compensation

3. Step Functions vs SQS

This is a useful distinction because your resume has SQS.

SQS

Decouples producers and consumers.

Service A
   │
   ▼
  SQS
   │
   ▼
Service B

SQS doesn’t know:

“After B succeeds, execute C, then D.”

It’s primarily messaging/decoupling.

Step Functions

Orchestrates a workflow.

Step A
 ↓
Step B
 ↓
Step C
 ↓
Step D

Interview answer

“I’d use SQS when I primarily need asynchronous decoupling and buffering between services. I’d use Step Functions when I need to model and manage a multi-step business workflow with explicit state, branching, retries and error handling.”

4. Step Functions + Lambda

A common architecture:

              Step Functions
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
       Lambda    Lambda    Lambda
       Validate  Payment   Inventory

For example:

POST /orders
     │
     ▼
Step Functions
     │
     ▼
Validate Order
     │
     ▼
Charge Payment
     │
     ├── failure → retry
     │
     ▼
Reserve Inventory
     │
     ▼
Send Notification

5. Important Step Functions interview question

”Why not just call Lambda from Lambda?”

You can, but orchestration becomes hidden inside application code:

Lambda A
  ↓
Lambda B
  ↓
Lambda C
  ↓
Lambda D

Now you’re responsible for:

  • workflow state

  • retries

  • timeout handling

  • failure handling

  • branching

  • tracking execution

Step Functions externalizes the workflow orchestration.

Good answer

“Step Functions separates business workflow orchestration from individual service implementations. This makes long-running and failure-prone workflows easier to observe, retry and evolve.”

6. ECS vs EKS

This is very likely to be asked.

The simplest answer

ECS is AWS’s managed container orchestration service. EKS is AWS’s managed Kubernetes service.

Think:

ECS
 │
 └── AWS-native container orchestration
 
 
EKS
 │
 └── Kubernetes
       │
       ├── Pods
       ├── Deployments
       ├── Services
       └── Ingress

7. ECS

Amazon Elastic Container Service

You package your application:

.NET API
   ↓
Docker Image
   ↓
ECR
   ↓
ECS

ECS manages running containers.

Typical architecture:

                   ALB
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
      ECS Task             ECS Task
       .NET API             .NET API
          │                   │
          └─────────┬─────────┘
                    ▼
                PostgreSQL

8. ECS Launch Types

There are two important ways to run ECS workloads:

ECS
 │
 ├── EC2
 │
 └── Fargate

ECS + EC2

AWS manages the ECS control plane, but you manage the EC2 instances that run the containers.

ECS
 │
 └── EC2 instances
       ├── Container
       ├── Container
       └── Container

You are responsible for things such as:

  • EC2 capacity

  • instance types

  • patching

  • scaling the underlying instances

ECS + Fargate

Fargate is serverless compute for containers.

ECS
 │
 └── Fargate
       ├── Task
       ├── Task
       └── Task

You don’t manage the underlying EC2 servers.

Interview phrase

“ECS is the orchestrator; Fargate is a serverless compute option for running ECS tasks.”

That’s an important distinction.

9. EKS

Amazon Elastic Kubernetes Service

EKS provides managed Kubernetes control-plane infrastructure.

Your application runs as Kubernetes workloads:

EKS Cluster
    │
    ├── Pod
    │    └── .NET API
    │
    ├── Pod
    │    └── .NET API
    │
    └── Pod
         └── .NET API

You interact with Kubernetes concepts:

Pod
Deployment
Service
Ingress
ConfigMap
Secret
Namespace
HPA

10. ECS vs EKS

ECSEKS
OrchestratorAWS ECSKubernetes
ComplexityLowerHigher
AWS integrationExcellentExcellent
Kubernetes expertiseNot requiredRequired
PortabilityLowerHigher
Learning curveLowerHigher
Operational complexityLowerHigher
Best forAWS-centric containersKubernetes ecosystem

11. When would YOU choose ECS?

Suppose you’re building:

ASP.NET Core APIs
Docker
AWS
ALB
RDS PostgreSQL
SQS
CloudWatch

and don’t have a requirement for Kubernetes.

I’d strongly consider:

ALB
 ↓
ECS
 ↓
Fargate
 ↓
ASP.NET Core containers

Why?

Because you get container orchestration without taking on the additional Kubernetes operational model.

Interview answer

“If we’re AWS-centric and don’t have a strong Kubernetes requirement, I’d generally prefer ECS/Fargate because it reduces operational complexity while still giving us container orchestration and autoscaling.”

12. When would you choose EKS?

EKS becomes attractive when:

  • organization already standardizes on Kubernetes

  • multiple clouds/on-prem Kubernetes

  • Kubernetes ecosystem is required

  • advanced Kubernetes tooling is needed

  • teams already have strong Kubernetes expertise

  • portability is important

Example:

AWS
 │
 ├── EKS
 │
 ├── On-prem Kubernetes
 │
 └── Azure Kubernetes

You can maintain a more consistent Kubernetes operating model.

13. ECS/Fargate vs Lambda

Since your resume has Lambda, expect this question.

Lambda

Best for:

Event-driven
Short-lived
Serverless
Bursty workloads

Example:

SQS
 ↓
Lambda
 ↓
Process message

ECS/Fargate

Better when you need:

Long-running service
Container
More runtime control
Consistent workload
Custom dependencies

Example:

ALB
 ↓
ECS/Fargate
 ↓
ASP.NET Core API

Strong interview answer

“I would use Lambda when the workload is event-driven and short-lived and benefits from serverless scaling. I’d choose ECS/Fargate when I need a continuously running containerized service, more control over the runtime, or workloads that don’t fit Lambda’s execution model.”

14. ECS/Fargate vs EC2

Another likely question.

                 Compute
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
      EC2         Lambda       Fargate
   VM-based      Functions     Containers

EC2

You manage:

OS
Patching
Capacity
Instances
Scaling

Fargate

You manage:

Container
CPU / Memory
Task configuration
Networking
Application

AWS manages the underlying infrastructure.

15. Your AWS Architecture — good interview story

You can connect your resume technologies into one architecture:

                       Internet
                          │
                          ▼
                         ALB
                          │
                 ┌────────┴────────┐
                 ▼                 ▼
             ECS/Fargate       ASP.NET Core
             Service              Lambda
                 │                  │
                 └────────┬─────────┘
                          ▼
                         SQS
                          │
                          ▼
                       Lambda
                          │
                          ▼
                    Step Functions
                          │
               ┌──────────┼──────────┐
               ▼          ▼          ▼
            Service A  Service B  Notification
               │
               ▼
           PostgreSQL

Inside AWS:

                         VPC
              ┌───────────┴───────────┐
              │                       │
        Public Subnet          Private Subnets
              │                       │
             ALB              ECS/Fargate
                                      │
                                  Lambda*
                                      │
                                   RDS/DB
  • Lambda can be configured for VPC access when it needs private VPC resources.

🚨 5 answers I’d memorize before your interview

Step Functions

“Serverless workflow orchestration using state machines, useful for coordinating distributed steps with retries, error handling, branching and timeouts.”

SQS vs Step Functions

“SQS is primarily asynchronous messaging and decoupling; Step Functions models and orchestrates a multi-step workflow.”

ECS

“AWS-native container orchestration.”

EKS

“Managed Kubernetes on AWS.”

ECS vs Fargate

“ECS is the container orchestrator; Fargate is a serverless compute option that runs ECS tasks without me managing EC2 instances.”

ECS vs EKS

“I’d choose ECS/Fargate for a simpler AWS-native container platform. I’d choose EKS when Kubernetes standardization, ecosystem, portability or existing Kubernetes expertise justifies the additional operational complexity.”

One final trap: don’t say “Fargate is an alternative to ECS.” Fargate is a compute engine that can run ECS tasks (and can also be used with EKS).

Graph View