Skip to content

AWS Architecture

The OneConnect Infrastructure Platform defines the foundational architecture for deploying the OneConnect Application in a scalable, reliable, and secure manner. It establishes a clear operational model that separates infrastructure provisioning from application orchestration, enabling consistent, automated, and repeatable deployments across all environments.

OneConnect AWS Architecture Diagram

Architectural Goals

Separation of Concerns: AWS vs Kubernetes

AWS infrastructure resources are provisioned and managed exclusively through Terraform, while ArgoCD governs all Kubernetes-native resources. This boundary ensures that application and infrastructure lifecycles remain decoupled, improving maintainability and reducing cross-layer drift.

Ephemeral and Reproducible Infrastructure

The AWS environment can be destroyed and rebuilt at any time without affecting persistent dependencies. - Long-lived services (e.g., MongoDB Atlas, OIDC provider, account-level resources) are managed on independent lifecycles. - All other resources are fully ephemeral and automatically provisioned from code, reinforcing Infrastructure as Code (IaC) principles. * It should be easy to remove and recreate environments from scratch.

All new code that conflicts with these architectural goals should go through the Architecture Review Process.

Kubernetes Architecture - Service Mesh and Gateway API

Architecture Overview:

Our cluster network architecture combines AWS Load Balancers, the Kubernetes Gateway API, and Istio Ambient Mesh to create a secure and maintainable external and service-to-service communication layer.

Kubernetes Istio Architecture - Authentication and Routing

Key Components:

  • Load Balancers
    • External Load Balancer: Public entry point for internet traffic into the cluster.
    • Internal Load Balancer: Private entry point for our internal systems (ArgoCD, Dashboards, etc)
  • Gateway API
    • oneconnect-gateway (external) – Accessing client-facing applications in our cluster
    • internal-gateway (internal) – Accessing internal-facing applications
  • Waypoints:
    • Per-namespace Istio Waypoint proxies implementing L7 policy (HTTP routing, authz) in Ambient mode—without sidecars.
    • Used to perform OAuth2 exchange and pass headers down to individual services.

What does it give us?

  • The Gateway API: Splits development and operations team responsibilities.
  • Ops: Create Gateways that map to Load Balancers in AWS.
  • Developers: Create Waypoints (per-namespace), HttpRoutes, GRPCRoutes,...
  • Ambient Mode:
  • No sidecars to inject/update; This reduces complexity and reduces cost of running our services.
  • The waypoint proxies act as a single place to do authorization and authentication within the cluster.
  • Service-to-service mTLS via Istio's Zero Trust Tunnels.

[!WARNING]

There can still be differences between AWS environments and KinD environments.

Long term we would like to support virtual environments in AWS - per-engineer to further minimize inconsistencies between AWS and dev environments. However this involves more mature tooling and further platform work to accomplish.