Reusing an Existing AWS API Gateway for EKS Microservices

Reusing an Existing AWS API Gateway for EKS Microservices

A Practical, Empathetic Playbook for App Teams and Cloud Teams

Modern cloud friction rarely comes from technology.

It comes from ownership, governance, risk, and time pressure.

If you’re running:

• An EKS cluster

• A VPC landing zone

• Microservices already reachable internally

• CI/CD pipelines working

• A shared AWS API Gateway already fronting Lambda

… and now you need to expose EKS services through that same gateway —

this article is your blueprint.

The Architecture Context

Existing Pattern (Already Working)

Many enterprises already have:

• API Gateway → Lambda integrations

• Terraform modules to deploy it

• IAM roles and guardrails in place

• Logging and monitoring standardized

That’s good news.

You are not starting from scratch.

The New Requirement

Now the architecture shifts:

Instead of Lambda proxy integration, you now need:

API Gateway → VPC Link → NLB/ALB → EKS Services

This is a different integration model.

Not harder — just different.

Why Cloud Teams Hesitate (And Why It’s Rational)

Before pushing harder, understand what might be happening.

1. Blast Radius Anxiety

Shared API Gateway means:

• One mistake affects multiple teams

• Terraform changes impact production workloads

• Downtime becomes enterprise-visible

Cloud teams are wired to reduce shared risk.

That’s not obstruction — that’s protection.

2. Governance Boundaries Are Often Undefined

Questions cloud teams may be silently asking:

• Who owns route versioning?

• Who owns rate limiting?

• Who owns auth configuration?

• Who owns WAF rules?

• Who owns deprecation strategy?

If those aren’t defined, onboarding a new service feels dangerous.

3. Pattern Shift (Lambda vs EKS)

Lambda integration is simple.

EKS requires:

• VPC Link configuration

• Load balancer strategy (NLB vs ALB)

• Health check alignment

• Private vs public endpoint clarity

• Network security review

It introduces networking into what was previously “serverless.”

That’s a meaningful operational change.

4. Terraform Maturity Concerns

Shared Terraform modules often evolve organically.

Cloud teams may wonder:

• Is the module flexible enough?

• Do we need refactoring?

• Are we introducing tech debt?

Extending shared infrastructure is not just adding a route.

It’s modifying an enterprise contract.

The Right Way to Approach This (Step-by-Step)

Let’s walk through a mature approach.

Step 1 — Define Ownership Clearly

Before Terraform.

Before architecture diagrams.

Define two layers.

Platform-Owned Responsibilities

• API Gateway instance

• WAF configuration

• Base IAM patterns

• Logging standards

• Monitoring & alarms

• CI/CD pipeline for gateway

• Default throttling rules

App-Team Responsibilities

• OpenAPI spec

• Route definitions

• Backend service contract

• Auth requirements (scopes, roles)

• SLA expectations

When this boundary is written down, friction drops dramatically.

Step 2 — Clarify Exposure Model

Critical question:

Are your consumers internal or external?

• Salesforce (external SaaS)

• ServiceNow (external SaaS)

• Bots (possibly external)

This decision determines:

• Public API Gateway vs Private API Gateway

• mTLS vs JWT vs IAM auth

• WAF requirements

• IP allowlisting needs

If this isn’t clarified early, everything stalls later.

Step 3 — Decide Integration Pattern

For EKS, you typically choose:

Option A — API Gateway + VPC Link + NLB

Best for:

• Private services

• Stable backend services

• Internal routing

Option B — API Gateway + ALB

Useful if:

• You want layer 7 routing

• You already have ingress controller patterns

Cloud teams need to agree on this once — not per team.

Standardization reduces hesitation.

Step 4 — Observability First (Not Last)

Before production:

• Enable access logs

• Configure structured logging

• Define CloudWatch alarms (4xx, 5xx, latency)

• Decide tracing strategy (X-Ray or OpenTelemetry)

If observability isn’t defined, cloud teams will pause deployment.

Because they don’t want blind production APIs.

Step 5 — Terraform Strategy

Instead of modifying a monolithic module:

Create an extension module for EKS-backed services.

For example:

module "eks_api_integration" {

  source = "../modules/api-gateway-eks-service"

  openapi_spec = file("openapi.yaml")

  vpc_link_id = var.vpc_link_id

  nlb_arn     = var.nlb_arn

}

Keep Lambda integrations intact.

Reduce blast radius.

Step 6 — Productive Meeting Structure

Here’s how to run a 60-minute alignment meeting:

First 15 Minutes – State the Goal

“We want to reuse the shared gateway.

We want to respect governance.

We want to meet our six-week deadline.”

Set tone first.

Next 20 Minutes – Cloud Team Concerns

Ask directly:

• What risks do you see?

• What governance gaps worry you?

• What Terraform constraints exist?

• What production safety checks are missing?

Listen. Don’t counter.

Next 15 Minutes – Define Ownership Boundaries

Document live:

• Platform responsibilities

• App responsibilities

• Approval workflow

Final 10 Minutes – Agree on a Timeline

Break into milestones:

Week 1: Integration pattern decision

Week 2: Terraform module draft

Week 3: Dev deployment

Week 4: Observability validation

Week 5: Security review

Week 6: Production readiness

When people see structure, hesitation decreases.

Checklist for Reusing a Shared API Gateway

Architecture Checklist

• Confirm exposure model (public/private)

• Select integration pattern (VPC Link/NLB/ALB)

• Define auth model

• Confirm WAF requirements

• Confirm rate limiting strategy

Governance Checklist

• Ownership documented

• Versioning strategy defined

• Deprecation process defined

• SLA expectations documented

Infrastructure Checklist

• Terraform module reviewed

• Separate EKS integration module created

• CI/CD validated

• IAM least-privilege applied

Observability Checklist

• Access logs enabled

• 4xx/5xx alarms configured

• Latency alarm configured

• Tracing decision documented

The Real Lesson

Most API Gateway friction isn’t AWS.

It’s:

• Shared ownership anxiety

• Undefined governance

• Risk containment

• Terraform maturity

• Deadline pressure

App teams think:

“We just need routing.”

Cloud teams think:

“We need an enterprise contract.”

Both are right.

A Final Word on Empathy

When you’re under a six-week deadline, urgency feels obvious.

But shared services teams live in a different mental model:

Stability > Speed

Governance > Convenience

Enterprise risk > Local deadline

When you approach the conversation acknowledging that, meetings shift from defensive to collaborative.

The Mature Cloud Posture

A shared API Gateway should:

• Be reused

• Be extended safely

• Have clear ownership boundaries

• Be observable

• Be versioned

• Be governed

When those pieces are in place, onboarding a new EKS service becomes routine.

And that’s the real goal.

Not just deploying an API.

But building a repeatable enterprise pattern.