Modern API connectivity in hybrid multi-cloud architectures

Red Hat Connectivity Link is a new Kubernetes-native API connectivity platform designed to connect distributed applications in complex environments more easily, securely and consistently. In modern architectures, applications often span multiple Kubernetes clusters, data centers and cloud environments. Traditional approaches usually required several separate tools for this – such as separate solutions for API security, rate limiting, service mesh, etc. – which made integration and operation more difficult. Connectivity Link takes a new approach: it consolidates traffic routing, security and policy management functions in a unified solution directly in Kubernetes. This significantly reduces complexity and allows both development and platform teams to centrally define, manage and view connectivity rules across all environments.

As a Kubernetes-native solution, Connectivity Link relies on emerging cloud-native standards such as the Kubernetes Gateway API standard and the proven Envoy proxy. This basis makes it possible to control Ingress gateways consistently across clusters. Policies for authentication, authorization, DNS routing or TLS encryption are simply defined as Kubernetes objects – instead of in external systems or through manual configuration as was previously the case. API gateways thus become extensions of the cluster, which enables end-to-end control, especially in hybrid cloud scenarios. Connectivity Link thus addresses the challenges of modern IT organizations with a single integrated solution instead of a complex web of multiple products.

Advantages for multi-cloud

Companies in regulated sectors attach great importance to reliability and flexibility. Connectivity Link was designed from the outset for hybrid and multi-cloud architectures. For example, it enables traffic to be distributed dynamically across multiple Kubernetes clusters and locations – whether on-premises in your own data center or in various public cloud regions. By integrating common DNS providers, Ingress endpoints can be automatically registered in DNS, including failover mechanisms across cluster boundaries. For banks, this means that services remain available even if an entire site fails and users can be transparently redirected to an alternative cluster. In addition, data traffic can be routed based on geographical criteria. For example, queries from European customers can be sent to an EU-based cluster in order to comply with regulatory requirements for data storage. This location-based routing capability ensures that latency is optimized and compliance requirements (e.g. data regionality) are met at the same time.

End-of-Life of Red Hat 3scale: Impact on banking systems

The end of support for Red Hat 3scale API Management marks a significant turning point for organizations that have relied on this solution to date. According to lifecycle information, full product support for 3scale was already discontinued in mid-2021, and since May 2023, 3scale has been in the final maintenance phase without further product development. In practical terms, this means No more new features or versions will be released, only critical bugs will be fixed for a limited time. This poses a risk for banks that use 3scale in their integration architecture. On the one hand, security-relevant updates may not be released, which can lead to compliance problems in the highly regulated financial sector. On the other hand, competitive disadvantages become significant over time, as modern requirements – such as seamless cloud integration or Kubernetes-native operation – are no longer addressed by 3scale. Red Hat is reclassifying some middleware products as part of a strategic realignment; 3scale is one of the solutions whose further development has been deprioritized in favour of new approaches. Organizations must therefore plan how to replace or modernize the functionality of 3scale.

What does this mean in concrete terms? Existing API programs that run on 3scale (e.g. partner APIs, open banking interfaces or internal microservice APIs) should be migrated to a future-proof platform at an early stage. Without vendor support, the continued productive operation of 3scale is not sustainable in the medium term – not least because internal security and compliance guidelines of the banks could prohibit this. In addition, the integration effort increases if newer technologies (such as service meshes or cloud-native ingress controllers) no longer harmonize with the old system. Against this backdrop, the introduction of Red Hat Connectivity Link is a strategic shift in Red Hat’s API portfolio, offering customers a modern replacement for 3scale. Connectivity Link covers many of the core requirements for API connectivity and security, but with a different architectural design than the classic 3scale API Manager. The following section looks at how this solution is used in Kubernetes environments – including OpenShift – and why it is cloud agnostic.

Kubernetes and OpenShift integration without cloud lock-in

Red Hat Connectivity Link was developed for operation in containerized environments and is cloud-agnostic – meaning it can run on any Kubernetes platform, be it in the private cloud of a data center, in OpenShift container platforms or in public cloud Kubernetes services. The decisive factor is that no specific cloud provider is required. This is ideal for Swiss banks, which often rely on OpenShift as a strategic container platform: Connectivity Link integrates seamlessly into OpenShift clusters, for example via an operator, and uses the standardized Kubernetes APIs. This allows banks to operate their API gateway and policy infrastructure in-house and retain full data sovereignty – an important point in strictly regulated environments.

Connectivity Link is configured declaratively via Custom Resource Definitions (CRDs) in the Kubernetes cluster. For example, a platform team can define an ingress gateway instance (in accordance with the Gateway API standard) and then link various rules to it using policy attachments – from TLS certificate management to rate limiting. All of this is done within the Kubernetes configuration and can be managed via GitOps. No external appliances or separate management servers are required, which simplifies operation across cloud boundaries. This allows identical policies to be rolled out in multiple clusters without being tied to a specific cloud load balancer.

Another advantage is the integration with service mesh technologies: Connectivity Link supports common mesh orchestrators such as Istio or Red Hat OpenShift Service Mesh. This means that financial companies that already use Service Mesh for microservice communication can use Connectivity Link at their ingress points. They benefit from a consistent security and traffic management layer – from the edge of the cluster deep into the service mesh – without proprietary, cloud-specific tools. With this universal approach, Connectivity Link meets the requirements of multi-cloud strategies, as pursued by many banks.

Migration from 3scale to Connectivity Link: Challenges and strategies

The transition from an established solution such as 3scale to a new Kubernetes-native architecture needs to be well planned – especially in the regulated financial environment, where stability, security and compliance have top priority. The key challenges of a migration include

Architecture change:
3scale was based on a centralized API manager with its own administration interface, user administration and an API gateway (APIcast). Connectivity Link, on the other hand, distributes functions to the Kubernetes cluster (CRDs, Ingress Controller, Service Mesh). This paradigm shift requires a rethink of operating processes and responsibilities. APIs are no longer configured via the 3scale portal, but defined as code (infrastructure as code) in the cluster. Teams must familiarize themselves with Kubernetes resources such as HTTP routes, gateways and policy CRDs.

Functional coverage:
A 1:1 replacement of all 3scale features may not be immediately available. For example, 3scale offered a developer portal for external consumers, billing features and fine-grained schedulable usage plans. Connectivity Link initially focuses on connectivity, security and traffic management. API design and cataloging features are planned (via integration of Apicurio in Developer Preview), but are still under development. Companies should check which 3scale components they have actually used (e.g. rate limits, authentication, analytics) and ensure that these can be implemented with Connectivity Link or supplementary tools (such as Apicurio Registry, Keycloak etc.).

Data and user migration:
If external developers or applications use 3scale (e.g. API keys, OAuth clients, contracts), these must be migrated to the new platform. As Connectivity Link enforces policies directly at the infrastructure level, existing API keys and access rules can be migrated to a new form (e.g. Keycloak Identity or JWT Tokens for Authorino). This step must be planned carefully so as not to interrupt any ongoing integrations. Parallel operation is often recommended in banks: new API endpoints are already offered via Connectivity Link, while old endpoints are still running on 3scale. Services can then be migrated step by step, with intensive tests and user acceptance tests ensuring that policy parity is guaranteed.

Compliance and testing:
Every change in a banking environment requires strict tests and approvals. Sufficient time should be planned for security audits and performance tests during migration. One advantage of Connectivity Link is that rules such as OAuth/OIDC authentication, encryption specifications or transaction limits are available centrally as code – this facilitates reviews by security departments. Nevertheless, companies must prove that the new solution offers at least the same level of security as before. Suitable migration strategies can include a step-by-step onboarding of less critical APIs, a fallback plan (re-routing to 3scale in an emergency) and training for the operations team in dealing with Kubernetes policies.

From a strategic perspective, the migration offers the opportunity to eliminate legacy issues and put the API landscape on a sustainable footing. Red Hat Connectivity Link is more than just a replacement for 3scale – it is a reorientation towards cloud-native principles. The upstream project Kuadrant, on which Connectivity Link is based, is described as a “re-architecture of API management using cloud native concepts”. It decouples previously monolithic API management components and instead uses Kubernetes features, Envoy/Istio and CRDs to provide flexible and extensible API services. A successful migration therefore means making the organization fit for this new way of thinking – an investment that pays off in the long term in terms of greater agility and better scalability.

Central functions of Red Hat Connectivity Link at a glance

Uniform policy management and access control
Connectivity Link offers a flexible policy attachment model in which security and traffic policies are attached directly to Kubernetes gateways or routes. This allows authentication and authorization policies to be defined and enforced centrally – for example via an AuthPolicy that only allows access to certain API routes with a valid OAuth2/JWT token. This uses an external Auth component that supports common standards such as OIDC and API keys. Platform teams can set global default policies, while development teams can define more granular rules for individual services as required. Role-Based Access Control (RBAC) in Kubernetes also regulates who can create or change which policies – which fulfills important audit requirements in regulated environments.

Granular rate limiting and quotas
To prevent misuse or overloading of APIs, Connectivity Link offers granular rate limiting control. RateLimitPolicy-CRDs can be used to define threshold values for API calls, for example “maximum 100 requests per minute per customer” or “10 requests per second globally”. The limits can be set at different levels – for example, globally at the gateway or specifically per HTTP route. Thanks to the Kubernetes integration, several distributed instances of an API service can share a global quota. Technically, this is implemented via Envoy’s integrated rate limit service. A simple YAML snippet illustrates how a RateLimitPolicy is defined as a Kubernetes resource:

In this example, a limit of 100 requests per minute is set for the API route. Such policies can be versioned and automated, which increases traceability, especially in banks – in contrast to 3scale, where rate limits were configured via an admin portal.

Centralized control across cluster and cloud boundaries
A key advantage of Connectivity Link is the ability to centrally control multiple clusters and clouds. Using a central control plane, implemented by the Connectivity Link Operator in the cluster, administrators can enforce uniform rules in all Kubernetes environments. For example, a company-wide security header or a compliance policy can be defined globally and automatically applied to all gateways. This simplifies governance considerably and minimizes misconfigurations. For banks pursuing a multi-cluster strategy, this means consistent security guidelines and simplified audit and reporting processes.

Integrated TLS certificate management and encrypted communication
Secure communication is mandatory in the financial sector. Connectivity Link integrates TLS management directly into the gateway. TLS certificates for ingress endpoints can be issued and renewed automatically via connections to Cert-Manager and ACME – for example with Let’s Encrypt. This means that a new API gateway can automatically receive a valid certificate without the need for manual intervention. In addition, mTLS (mutual TLS) and service mesh integrations are supported to ensure end-to-end encryption between the consumer and the backend service. This simplifies certificate management considerably.

Observability and monitoring for APIs
One aspect that is often underestimated is observability – i.e. the monitorability and visibility of API usage. Connectivity Link provides comprehensive metrics and preconfigured dashboards that are tailored to each role (platform engineers, developers, specialist departments). Platform engineers gain insights into compliance, gateway utilization, error rates and latencies, while developers primarily track service-specific metrics such as response times. Thanks to the deep Kubernetes integration, many of these metrics automatically flow into familiar tools such as Prometheus and Grafana. The dashboards are supplemented by logs and traces – for example via OpenTelemetry integration – which is particularly important for 24/7 monitoring, incident response and reporting in highly regulated environments.

Conclusion: Future-proof API connectivity for banks

Red Hat Connectivity Link represents an innovative leap forward in the field of API connectivity. For banks and other regulated organizations, the solution offers the opportunity to bring their API infrastructure into the Kubernetes world – with all the benefits of standardized, declarative management and multi-cloud capability. The end-of-life of 3scale may seem like a challenge at first, but it turns out to be an opportunity to move to a more modern architecture that better fits today’s cloud strategies and DevOps practices. Kubernetes-native API management means fewer silos, more automation and a tighter integration of security and network control directly in the platform.

Especially in the financial sector, where stability and compliance are imperative, Connectivity Link scores with centralized policy enforcement, high reliability across clusters and advanced security features. It is important to manage the transition carefully – with targeted migration tools, sufficient testing and, if necessary, support from experienced Red Hat partners. The open source basis of the Kuadrant project and the open documentation make it possible to build up know-how early on and adapt the solution to your own requirements if necessary.

Ultimately, Red Hat Connectivity Link is an example of how innovation pressure (cloud, microservices, DevOps) and concrete product decisions (3scale discontinuation) work together to break new ground. For banks, this means taking a proactive approach to this development. A well-planned migration and adoption of Connectivity Link will prepare the API landscape for the coming years – flexible, secure and ready for multi-cloud.

We take a hands-on approach to the critical success factors in the migration from 3scale to Red Hat Connectivity Link – with a focus on technical details, platform operation and developer experience:

Challenges in the migration from 3scale to Connectivity Link

• Architecture shift: From centralized API manager to distributed, declarative policy management in the Kubernetes cluster

• Dealing with parallel operation: gradual migration of existing APIs without downtime

• Ensuring production quality through integration tests, security audits and approval processes

• Training requirements for platform and development teams

Which 3scale functionalities can already be mapped in Connectivity Link today

• API security via AuthPolicy (e.g. JWT, OAuth2, mTLS)

• Traffic control through RateLimitPolicy

• TLS management with Cert-Manager & ACME

• Multi-cluster routing and DNS integration

• Partial support for service mesh connection (e.g. Istio)

What gaps still exist – and how they can be bridged

• No integrated developer portal (workaround: Apicurio or external portals)

• Missing billing functions & contract management

• Path-based routing only possible to a limited extent depending on the backend (depending on gateway API support)

• Missing UI for API product definition (e.g. compared to Kong Manager or 3scale Admin)

Possible additions:

• Apicurio Registry: API documentation and catalog

• Authorino: Flexible authentication services

• Keycloak: Identity Federation & OAuth2 provider

Best practices for platform teams when dev teams should manage their APIs themselves

• Define role concepts and CRD scopes (e.g. namespaces, RBAC)

• Provide “Golden YAML Templates” for policies & gateway setups

• GitOps models with review stages for productive routes and policies

• Developer enablement through self-service portals, CLI tools or Git templates

Tools & dashboards for visualizing CRDs that do not deter developers

• K9s or Lens for interactive CRD navigation

• Own UIs via OpenAPI + GitOps dashboards (e.g. ArgoCD or Backstage)

• Prometheus & Grafana for gateway metrics

• OpenTelemetry for distributed traces

📚 References

• Red Hat Developer & Product Documentation
  Red Hat. (2025). Red Hat Connectivity Link Documentation & Developer Guide.
  Available at: https://access.redhat.com/documentation/en-us/red_hat_connectivity_link/

• Red Hat Press Releases (January 2025)
  Red Hat. (2025). Red Hat Connectivity Link General Availability Announcement.
  Available at: https://www.redhat.com/en/blog/red-hat-connectivity-link-unified-api-connectivity-multi-cloud-environments

• Kuadrant.io – Open Source Upstream Project
  Kuadrant Community. (2025). Kuadrant Project – Kubernetes-native API Management.
  Available at: https://kuadrant.io/
  GitHub Repository: https://github.com/kuadrant

• ADMIN Magazine
  ADMIN Magazine. (2025). Red Hat Releases Kubernetes-Native Connectivity Platform.
  Available at: https://www.admin-magazine.com/News/Red-Hat-Releases-Kubernetes-Native-Connectivity

• Database Trends and Applications
  DBTA. (2025). Red Hat Introduces Red Hat Connectivity Link – A Unified Solution That Simplifies and Enhances Application Connectivity.
  Available at:  https://www.dbta.com/Editorial/News-Flashes/Red-Hat-Introduces-Red-Hat-Connectivity-Link-A-Unified-Solution-that-Simplifies-and-Enhances-Application-Connectivity-167729.aspx

• Own project experience
  Experience reports and technical assessments from customer projects in the finance and insurance environment with a focus on OpenShift, Kubernetes-native API gateways and policy management.