Since June 2023, over 100,000 practitioners downloaded our Internal Developer Platform (IDP) reference architectures. Now, version 2.0 is here - shaped by real-world implementations, insights from 90+ platform engineering ambassadors, and data from hundreds of platform teams.
These aren't theoretical blueprints from tech giants. They represent proven patterns from typical enterprises running teams of hundreds to thousands of developers. The update reflects what's changed: AI integration as a first-class concern, the multi-platform reality most organizations face, and security-first principles embedded throughout.
Here's what you need to know about the new architectures for AWS, GCP, and Azure.
What changed in version 2.0: Four strategic updates
The original architectures established a shared vocabulary. Version 2.0 captures how teams actually operate at scale.
Multi-platform reality is now explicit. Most enterprises run up to four distinct platform types: backend services, frontend applications, data/AI workloads, and mobile development. Sophisticated organizations differentiate further with specialized component libraries. The architecture acknowledges this instead of pretending one platform serves all needs.
AI integration gets dedicated components. The Developer Control Plane now includes explicit support for Copilot, LLM, and agent-based tooling. This isn't about adding AI features - it's about recognizing that AI-driven development fundamentally changes how developers interact with platforms.
Security becomes embedded, not bolted on. The Security Plane now spans all architectural layers with code analysis, secrets management, identity control, and policy enforcement integrated from the start. Security isn't a separate concern - it's woven into every plane.
Code as truth, interface as enabler. The shift from UI-first to code-first approaches reflects modern developer workflows. Portals and interfaces exist to enable, not replace, declarative configuration and GitOps patterns.
The five-plane architecture: Universal framework across clouds
Regardless of cloud provider, enterprise-grade IDPs converge on five architectural planes. Each addresses distinct concerns in the platform engineering lifecycle.
Developer Control Plane provides the interfaces developers use daily: IDEs, cloud development environments, portals, and AI integration points. This is where cognitive load gets reduced or amplified based on design choices.
Integration and Delivery Plane handles version control, CI/CD pipelines, image registries, and platform orchestration. The Platform Orchestrator sits here - coordinating workflows across the entire system and serving as the integration point between developer intent and infrastructure reality.
Resource Plane manages infrastructure provisioning and lifecycle. Whether you're using Terraform, Crossplane, or cloud-native tools, this plane translates application requirements into actual infrastructure.
Security Plane embeds protection throughout the platform: static code analysis, secrets management, identity and access management, policy control, and network security. Every action flows through security controls, not around them.
Observability Plane provides real-time insights into platform health through monitoring, logging, FinOps, and incident management. This plane makes platform behavior visible and measurable.
How the same principles map to different clouds
The architectural planes remain consistent. The implementation choices reflect each cloud's native capabilities.
In the Integration and Delivery Plane, AWS teams typically leverage CodePipeline and CodeBuild, Azure teams use Azure DevOps or GitHub Actions, while GCP teams implement Cloud Build and Cloud Deploy. The orchestration patterns stay the same - the services differ.
For the Resource Plane, AWS implementations often use EKS for container orchestration, Azure relies on AKS, and GCP uses GKE. All three support the same Kubernetes-based patterns with cloud-specific optimizations.
The Observability Plane shows similar convergence: CloudWatch on AWS, Azure Monitor on Azure, and Cloud Monitoring on GCP all provide the same fundamental capabilities - metrics, logs, traces, and alerting - through different interfaces and integration patterns.
This consistency matters. Platform teams can maintain standardized developer experiences across clouds while leveraging cloud-specific optimizations. The architectural principles transcend vendor choice.
Framework, not prescription: How to approach implementation
These architectures succeed not because they prescribe specific tools, but because they embody principles that platform teams can adapt to their context - whether running on AWS, Azure, GCP, or hybrid environments.
Start with the build vs. buy vs. blend decision. The market has reached a maturity where building everything from scratch rarely makes sense. Your IDP will likely include a blend of self build, and vendor solutions. The reference architectures help you evaluate where to invest that engineering effort in that decision making.
Codify every action and define a single source of truth. Effective platforms aren't collections of tools - they're cohesive systems built on clarity, consistency, and control. GitOps patterns and declarative configuration reduce cognitive load and minimize risk.
Embed security and observability from day one. These aren't add-ons. The architecture shows how to integrate them throughout all planes, making security and visibility default behaviors rather than afterthoughts.
Recognize that no two platforms are alike. The multi-platform reality means you might need separate IDPs for backend, frontend, data/AI, and mobile workloads. The same architectural fundamentals apply across all of them: clear ownership, composability, automation, and continuous feedback loops.
Getting the architectures and next steps
Download the cloud-specific reference architecture that matches your environment:
- AWS reference architecture - Detailed implementation patterns for AWS-native services
- Azure reference architecture - Azure-specific service mappings and integration patterns
- GCP reference architecture - GCP-native implementations of the five-plane architecture
Each whitepaper includes the complete architectural framework, design principles, roles and responsibilities, and golden path examples.
For platform teams new to these concepts, start with the design fundamentals of IDPs before diving into the advanced patterns. The Platform Engineering certification courses provide structured learning paths for just that.
The architectures represent living, community-validated knowledge - not static blueprints. As AI, technology, and organizational structures evolve, these patterns continue serving platform engineering's core purpose: empowering teams to build, ship, and operate software faster, more securely, and with greater confidence.
