Platform Engineering Overview
Last Updated: September 12, 2026
1. What is Platform Engineering?
Definition
Platform Engineering is the discipline of designing, building, and operating tools, workflows, and infrastructure for developer self-service. Platform engineering teams build an Internal Developer Platform (IDP) that enables developers to deploy applications quickly and securely without dealing directly with infrastructure complexity.
Internal Developer Platform (IDP)
An IDP is a self-service platform that abstracts operational tasks such as infrastructure provisioning, deployment, and monitoring so developers can focus on writing code.
Core Values of an IDP:
- Self-Service: Request approved resources/actions through APIs, CLIs or portals
- Guardrails: Implement and verify security policies, approval and audit paths
- Standardization: Consistent deployment patterns through Golden Paths
- Automation: Reduced cognitive load by eliminating repetitive tasks
Platform Engineering vs DevOps vs SRE
| Aspect | Platform Engineering | DevOps | SRE |
|---|---|---|---|
| Focus | Developer experience and self-service platform construction | Cultural integration of development and operations | Service reliability and operational automation |
| Key Deliverables | Internal Developer Platform | CI/CD pipelines, automation scripts | SLO/SLI, error budgets, toil automation |
| Primary Metrics | Developer productivity, onboarding time | Deployment frequency, lead time | Availability, error budget burn rate |
| Team Structure | Dedicated platform team | Cross-functional teams | SRE team or embedded SREs |
| Relationship | Product-oriented platform practice collaborating with DevOps and SRE | Culture and methodology | Operational engineering practice |
Note: These three approaches are complementary, not mutually exclusive. Platform Engineering is about packaging DevOps principles and SRE practices as a product.
Platform Team Roles and Structure
Key Roles:
| Role | Responsibility |
|---|---|
| Platform Product Manager | Analyze developer needs, manage IDP roadmap, define success metrics |
| Platform Engineer | Build core IDP infrastructure, Kubernetes/cloud automation |
| Platform SRE | Reliability of the platform itself, monitoring, incident response |
| Developer Experience (DX) Engineer | CLI tools, documentation, onboarding workflows |
2. AWS CAF Platform Perspective
Introduction to AWS Cloud Adoption Framework
The AWS CAF Platform perspective has seven capabilities: platform architecture, data architecture, platform engineering, data engineering, provisioning and orchestration, modern application development, and continuous integration/continuous delivery. This guide focuses on platform engineering.
Maturity Model: START → ADVANCE → EXCEL
AWS's detailed platform-engineering guide organizes improvement tasks as Start, Advance and Excel. The Kubernetes mappings/checklist below are this guide's teaching examples, not an official certification scorecard or mandatory sequence for every organization.
START: Foundation Building
The stage of establishing foundational infrastructure and setting up security guardrails.
| Capability | Description | Kubernetes Ecosystem Mapping |
|---|---|---|
| Landing Zone & Guardrails | Multi-account environment, preventive/detective controls | EKS cluster configuration, OPA Gatekeeper / Kyverno |
| Authentication | Centralized identity management, IdP integration | K8s Authentication & Authorization, OIDC, IRSA |
| Networking | Centralized network management | VPC CNI, Calico, Cilium |
| Observability | Collect/protect logs, metrics and traces | Prometheus, Loki, OpenTelemetry |
| Controls | Programmatic security controls | Pod Security Standards, Network Policies |
| Cost Management | Tagging strategy, cost allocation | Billing tags, usage and cost allocation, EKS Cost Optimization |
ADVANCE: Operational Scaling
The stage of expanding automation and building centralized observability.
| Capability | Description | Kubernetes Ecosystem Mapping |
|---|---|---|
| Infrastructure Automation | IaC, self-service products | ACK, KRO, Crossplane, Helm |
| Central Observability | Log/metric/trace correlation | Grafana Stack, CloudWatch |
| Systems Management | Image standardization, patch management | Image Security, Kyverno |
| Credential Management | Temporary credentials, automatic rotation | Secrets Management, IRSA |
| Security Tooling | XDR, granular monitoring | Runtime Security, Trivy, GuardDuty |
EXCEL: Continuous Optimization
The stage of achieving automated governance and continuous improvement.
| Capability | Description | Kubernetes Ecosystem Mapping |
|---|---|---|
| Automated Identity Management | Version-controlled roles/policies via IaC | GitOps-based RBAC management |
| Anomaly Detection | Proactive vulnerability assessment, anomaly pattern detection | Runtime Security (Falco), audit log analysis |
| Threat Analysis | Continuous monitoring against industry benchmarks | CIS Benchmark, kube-bench |
| Permission Refinement | Automated least privilege principle | K8s audit log-based RBAC optimization |
| Platform Metrics | Metrics aligned with organizational goals | DORA metrics, SLI/SLO |
3. IDP Reference Architecture
Kubernetes-Based IDP Layer Structure
┌─────────────────────────────────────────────────────┐
│ Developer Interface Layer │
│ (Backstage, Port, CLI, GitOps UI) │
├─────────────────────────────────────────────────────┤
│ Integration/Orchestration Layer │
│ (ArgoCD, FluxCD, Crossplane, KRO) │
├─────────────────────────────────────────────────────┤
│ Resource Layer │
│ (ACK, Helm Charts, Operators, CRDs) │
├─────────────────────────────────────────────────────┤
│ Infrastructure Layer │
│ (EKS, VPC, IAM, S3, RDS, ...) │
└─────────────────────────────────────────────────────┘Role and Tool Mapping for Each Layer
| Layer | Role | Key Tools | Repo Docs |
|---|---|---|---|
| Developer Interface | UI/CLI that developers interact with | Backstage, Port, Argo Workflows UI | Backstage |
| Integration/Orchestration | Declarative state management, deployment automation | ArgoCD, FluxCD, KRO | GitOps, KRO |
| Resource | Abstraction of cloud/K8s resources | ACK, Helm, Operators | ACK, Helm, K8s Extensions |
| Infrastructure | Actual compute/network/storage | EKS, VPC, IAM | EKS |
Self-Service Catalog Pattern (KRO RGD + ACK)
Combining KRO's ResourceGraphDefinition (RGD) with ACK enables a powerful self-service pattern:
# Single manifest written by developers
apiVersion: kro.run/v1alpha1
kind: WebApplication
metadata:
name: my-app
spec:
name: my-app
image: my-app:v1.0
replicas: 3
database:
engine: postgresql
instanceClass: db.t3.mediumWebApplication above is a custom platform API that must be defined beforehand, not a built-in Kubernetes/kro kind. Without its RGD/generated CRD, the object cannot be applied. This overview does not provide a complete RGD or create resources.
When an RGD explicitly declares Deployment, Service and ACK RDS/IAM resources, kro manages the Kubernetes objects/dependencies and the relevant ACK service controllers call AWS APIs. The resulting resource set depends on that RGD. Validate controllers/CRDs, RBAC/IAM, quotas, readiness/errors, credential delivery and deletion/retention policies separately. Creating one CR does not guarantee immediate AWS readiness or transactional provisioning. See the ExampleCorp example and kro guide.
Golden Path Concept
A Golden Path is the recommended deployment path provided by the platform team:
- Purpose: Guide developers to get started quickly using validated methods
- Characteristics: Supported recommended path; exceptions follow organizational approval and cannot bypass mandatory security/data policies
- Examples:
- "New Microservice Deployment" Golden Path: Validated Helm template → ArgoCD integration → configured metrics publishing/collection
- "Database Provisioning" Golden Path: Validated RGD → ACK RDS lifecycle → approved credential delivery
4. Platform Engineering Tool Ecosystem
This section maps where the tools covered in this repository fit within the platform engineering landscape.
| Category | Tools | Repo Doc Link |
|---|---|---|
| Package Management | Helm, Kustomize | Helm |
| AWS IaC | ACK, CloudFormation | ACK |
| Resource Orchestration | KRO, Crossplane | KRO |
| Extension Mechanisms | CRD, Operators | Kubernetes Extension Mechanisms |
| GitOps | ArgoCD, FluxCD | GitOps Section |
| Policy/Governance | Kyverno, OPA Gatekeeper | Kyverno, OPA Gatekeeper |
| Observability | Prometheus, Grafana, OTel | Observability Section |
| Autoscaling | KEDA, Karpenter | KEDA, Karpenter |
| Service Mesh | Istio, Cilium | Istio, Cilium Service Mesh |
| Security | Falco, Trivy, PSS | Runtime Security, Image Security, PSS |
5. Platform Maturity Self-Assessment Checklist
Assess your organization's platform engineering maturity. Each item links to the relevant document in this repository.
START Stage
| Check | Item | Related Docs |
|---|---|---|
| [ ] | Are EKS clusters created in a standardized manner? | EKS Cluster Creation |
| [ ] | Are RBAC policies defined and enforced? | Authentication & Authorization |
| [ ] | Are network policies applied? | Network Policies |
| [ ] | Is basic monitoring and logging configured? | EKS Monitoring |
| [ ] | Are Pod Security Standards applied? | PSS |
| [ ] | Are resource quotas and limits set? | EKS Cost Optimization |
ADVANCE Stage
| Check | Item | Related Docs |
|---|---|---|
| [ ] | Is infrastructure managed with IaC? (ACK, Terraform, etc.) | ACK |
| [ ] | Is a GitOps workflow in place? | GitOps |
| [ ] | Is a centralized observability stack operational? | Observability |
| [ ] | Is governance automated with a policy engine? | Kyverno |
| [ ] | Are secrets automatically managed from an external store? | Secrets Management |
| [ ] | Is container image scanning automated? | Image Security |
EXCEL Stage
| Check | Item | Related Docs |
|---|---|---|
| [ ] | Is a self-service catalog provided to developers? | KRO, ExampleCorp |
| [ ] | Are DORA metrics measured/improved at an appropriate service scope? | Current DORA definitions |
| [ ] | Is runtime security monitoring operational? | Runtime Security |
| [ ] | Is autoscaling optimized for workloads? | KEDA, Karpenter |
| [ ] | Are platform SLOs defined and tracked? | Observability Analysis |
| [ ] | Are Golden Paths defined and documented? | This document (Section 3) |
Metrics and Platform Product Success
Current DORA guidance describes five metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Do not mix the older four metrics or generic MTTR with current definitions. Use them to improve delivery and stability within a service/team context, not rank individuals. Also measure onboarding time, task success, user satisfaction and adoption. Measurement need not wait until Excel.
An IDP is more than a portal: it includes APIs, CLIs, templates, documentation, support and operating responsibilities. It does not transfer every application-security responsibility away from development teams. Validate guardrail enforcement, exceptions, changes and recovery.