EKS Fraud Detection

A real-time fraud detection system running on EKS with three Go microservices: an ingest worker consuming Kinesis streams, an alert handler processing SQS notifications, and an operator API behind an ALB. Each pod assumes its own IAM role via IRSA (IAM Roles for Service Accounts) with OIDC federation. The scenario validates Simfra's EKS simulation with Kubernetes-native AWS identity integration and streaming data flows.

Services

Service	Role
EKS	Kind-backed Kubernetes cluster with managed node group
ECR	Container image repositories for three microservices
Kinesis	2-shard stream for transaction ingestion, KMS encrypted
DynamoDB	Feature table (risk metrics) and alerts table, both SSE-KMS
ElastiCache	Redis cluster for scoring result caching
EventBridge	Routes high-risk fraud events to notification chain
SNS	Alert notification topic
SQS	Alert queue (via SNS subscription) for alert-handler consumption
S3	NDJSON fraud event archive, SSE-KMS
ELBv2	ALB with HTTPS for operator-api ingress
Route53	Hosted zone with ALIAS record for ALB
ACM	TLS certificate with DNS validation
KMS	Six keys: EKS secrets, Kinesis, DynamoDB (x2), S3, SQS/SNS
IAM/STS	Eight roles: cluster, node, three IRSA workload roles, CI/CD, LB controller
CloudWatch Logs	Pod execution logs
CodeCommit	Source repository
CodeBuild	Docker image builds and ECR pushes
CodePipeline	Deployment orchestration

Architecture

Kinesis Stream (2 shards, KMS)
  |
  v
EKS: ingest-worker (2 replicas, IRSA)
  |
  ├── Score transactions (amount, velocity, geography)
  ├── Update DynamoDB fraud-features table
  ├── Cache scoring results in Redis
  ├── Archive events to S3 (NDJSON)
  └── Emit high-risk events to EventBridge
                                    |
                                    v
                              EventBridge Rule
                                    |
                                    v
                              SNS --> SQS
                                       |
                                       v
                              EKS: alert-handler (1 replica, IRSA)
                                    |
                                    v
                              DynamoDB fraud-alerts table

EKS: operator-api (1 replica, IRSA) --> ALB (HTTPS, ACM) --> Route53
  Endpoints: /health, /api/features/{id}, /api/alerts, /api/replay

Each EKS workload assumes a different IAM role through IRSA with OIDC federation. The ingest-worker has permissions for Kinesis, DynamoDB, Redis, S3, and EventBridge. The alert-handler has permissions for SQS and DynamoDB. The operator-api has read-only access to DynamoDB and S3. No pod has more permissions than it needs.

What This Validates

EKS cluster with Kind backend and managed node group
IRSA (IAM Roles for Service Accounts) with OIDC federation and per-pod identity
Kinesis stream consumption from Kubernetes pods using GetRecords polling
Pod-to-AWS service communication (DynamoDB, S3, EventBridge, SQS) via IRSA credentials
EventBridge-to-SNS-to-SQS alert delivery chain
AWS Load Balancer Controller creating ALB from Kubernetes Ingress resources
Six separate KMS keys with per-service encryption boundaries
Security group isolation for Redis and backing services
ALB HTTPS with ACM certificate and Route53 ALIAS DNS
Rule-based fraud scoring with feature state persistence

Test Coverage

Six test phases: CI/CD pipeline execution, smoke checks for all 13 resource types, integration tests for the full fraud flow (seed transactions, verify feature updates, check S3 archive, validate alert delivery), security tests for encryption across all six KMS keys and IRSA credential validation (including negative test: pod without IRSA has no AWS credentials), day-2 operations (IRSA token verification), and performance tests with 50-record burst ingestion and concurrent ALB health checks.