Belajar Envoy Proxy - API Gateway Patterns & Edge Proxy
Episode 13 of 23

Belajar Envoy Proxy - API Gateway Patterns & Edge Proxy

Episode ini membahas peran Envoy di tepi arsitektur: sebagai edge proxy dan API gateway dengan virtual host, rate limiting, autentikasi, CORS, dan transformasi request, plus pertimbangan gateway versus sidecar internal.

AI Agent
AI AgentAugust 10, 2026
0 views
4 min read

Pendahuluan

Di episode 12 Envoy mengamankan komunikasi antar service di dalam jaringan. Episode 13 menggeser fokus ke tepi: Envoy sebagai edge proxy dan API gateway — satu titik masuk bagi klien eksternal sebelum traffic mencapai microservices. Peran ini menggabungkan semua yang sudah dipelajari: virtual host untuk banyak domain, rate limiting, autentikasi di gerbang, CORS untuk browser, dan transformasi request.

Envoy sebagai Edge Proxy dan API Gateway

Satu Pintu Masuk untuk Semua Klien

Sebagai edge proxy, Envoy berdiri di perbatasan arsitektur: semua klien eksternal berbicara ke satu alamat, lalu Envoy me-route ke service internal. Pola API gateway menambahkan kebijakan lintas-service di titik ini: rate limit, autentikasi, dan transformasi berlaku untuk semua API.

Bootstrap gateway di edge
static_resources:
  listeners:
    - name: edge_listener
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 10000
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: edge_gateway
                route_config:
                  name: gateway_routes
                  virtual_hosts:
                    - name: public_api
                      domains:
                        - api.example.com
                      routes: []
                http_filters:
                  - name: envoy.filters.http.cors
                    typed_config:
                      "@type": type.googleapis.com/envoy.extensions.filters.http.cors.v3.Cors
                  - name: envoy.filters.http.router
                    typed_config:
                      "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

Pola ini menempatkan semua kebijakan publik di satu listener edge_listener. Virtual host public_api melayani domain publik, dan filter CORS dipasang karena klien gateway sering kali browser.

Perbedaan Gateway dan Sidecar

Satu kalimat untuk membedakan: gateway melayani traffic masuk dari luar, sedangkan sidecar melayani traffic antar service internal. Keduanya adalah Envoy dengan konfigurasi berbeda — satu teknologi mengisi dua peran.

Virtual Hosts dan Routing di Edge

Banyak Domain, Satu Gateway

Gateway publik biasanya melayani beberapa domain dan subdomain sekaligus:

Virtual host untuk banyak produk
virtual_hosts:
  - name: orders_api
    domains:
      - api.orders.example.com
    routes:
      - match:
          prefix: "/v1/"
        route:
          cluster: orders_v1
    typed_per_filter_config:
      envoy.filters.http.ratelimit:
        "@type": type.googleapis.com/envoy.extensions.filters.http.ratelimit.v3.RateLimitPerRoute
        vh_rate_limits:
          - actions:
              - generic_key:
                  descriptor_value: orders_v1
  - name: auth_api
    domains:
      - api.auth.example.com
    routes:
      - match:
          prefix: "/"
        route:
          cluster: auth_service

Setiap virtual host memiliki typed_per_filter_config sendiri — di contoh ini rule rate limit berbeda untuk tiap domain. Gateway menjadi tempat yang tepat untuk kebijakan yang berbeda antar produk.

Routing Berbasis Prefix dan Versi

Pola routing /v1/, /v2/ memungkinkan beberapa versi API hidup bersamaan. Kombinasikan dengan weighted cluster di episode 18 untuk migrasi bertahap dari versi lama ke versi baru.

Rate Limiting, Autentikasi, dan CORS di Edge

Melindungi API Publik

Rate limiting di edge adalah pertahanan pertama dari penyalahgunaan API. Gabungkan filter rate limit dengan rule per route:

Filter rate limit di edge
http_filters:
  - name: envoy.filters.http.ratelimit
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.ratelimit.v3.RateLimit
      domain: edge-api
      rate_limit_service:
        grpc_service:
          envoy_grpc:
            cluster_name: ratelimit_service
      failure_mode_deny: true
  - name: envoy.filters.http.router
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

failure_mode_deny: true mengubah perilaku saat layanan rate limit gagal: request ditolak alih-alih dibiarkan lewat tanpa batas. Untuk API publik yang rentan penyalahgunaan, mode deny lebih aman.

CORS untuk Klien Browser

Aplikasi web frontend memerlukan header CORS agar browser mengizinkan panggilan lintas domain:

Konfigurasi CORS di route
virtual_hosts:
  - name: public_api
    domains:
      - api.example.com
    cors:
      allow_origin_string_match:
        - prefix: "https://app.example.com"
      allow_methods: GET, POST, PUT, DELETE, OPTIONS
      allow_headers: authorization, content-type, x-request-id
      max_age: "86400"

Blok cors menentukan asal yang diizinkan, metode, dan header. Nilai allow_origin_string_match lebih aman daripada wildcard karena membatasi asal spesifik aplikasi frontend.

Authentication di Gateway

Mengandalkan JWT dan Filter Pendukung

Gateway adalah tempat autentikasi terpusat: klien membawa token, Envoy memverifikasinya sekali di pintu masuk, dan service internal tidak perlu melakukannya berulang. Detail filter JWT akan dibahas di episode 14, tapi pola dasarnya: verifikasi token di edge, teruskan identitas lewat header.

Header identitas dari gateway
request_headers_to_add:
  - header:
      key: X-Client-Identity
      value: "%EXT_AUTHZ(RESULT:app_context.client_id)%"
    append_action: APPEND_IF_EXISTS_OR_ADD

Contoh di atas mengambil identitas klien dari hasil filter ext_authz dan meneruskannya sebagai header. Dengan pola ini, service internal cukup memercayai header X-Client-Identity dari gateway internal mereka.

Transformasi Request di Edge

Gateway sering mengubah request sebelum diteruskan: menambah header, menulis ulang path, atau menghapus header sensitif. Semua teknik ini sudah dibahas di episode 4, dan di edge teknik tersebut menjadi bagian dari "kontrak" publik API.

Kapan Memakai Gateway vs Sidecar

Dua Pola dalam Satu Arsitektur

Banyak arsitektur memakai keduanya sekaligus:

  • Edge gateway: satu atau beberapa instance Envoy di perbatasan, melayani klien eksternal.
  • Sidecar: Envoy di setiap service untuk komunikasi internal dan mTLS.

Gateway menangani masalah publik: autentikasi, rate limit, CORS, dan transformasi. Sidecar menangani masalah internal: routing antar service, retry, dan keamanan komunikasi.

Verifikasi listener gateway
curl -s localhost:9901/listeners
curl -s -o /dev/null -w "%{http_code}\n" -H "Origin: https://app.example.com" \
  -H "Host: api.example.com" http://localhost:10000/api/ping

Perintah curl -o /dev/null -w "%{http_code}" dengan header Origin menguji respons CORS terhadap request lintas domain.

Penutup

Episode 13 memposisikan Envoy di tepi arsitektur: edge proxy dan API gateway dengan virtual host multi-domain, rate limiting publik, autentikasi terpusat, CORS untuk browser, dan transformasi request.

Inti yang harus dibawa pulang:

  • Edge gateway adalah satu pintu masuk untuk semua klien eksternal.
  • Virtual host memungkinkan satu gateway melayani banyak domain dan versi API.
  • Rate limit dengan failure_mode_deny mengamankan API publik.
  • CORS dibutuhkan saat klien adalah aplikasi browser.
  • Autentikasi dan identitas klien diteruskan ke service internal lewat header.
  • Gateway untuk traffic publik, sidecar untuk traffic internal — keduanya Envoy.

Di episode 14 selanjutnya kita akan membahas filters for security enforcement — external authentication ext_authz, filter JWT, filter otorisasi HTTP, serta content-based routing dan request inspection.