Platform Engineering Overview
Last Updated: February 23, 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: Developers provision infrastructure directly without filing tickets
- Guardrails: Security and compliance built in by default
- 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 layer on top of DevOps + 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 Cloud Adoption Framework (CAF) provides organizational guidelines for cloud adoption. The Platform Perspective covers three key areas:
- Platform Engineering -- The focus of this section
- Platform Architecture -- Cloud architecture design principles
- Data Architecture -- Data management and analytics strategy
Maturity Model: START → ADVANCE → EXCEL
AWS CAF defines cloud platform maturity in three stages. Let's examine how Kubernetes ecosystem tools map to each stage.
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 |
| Logging | Cross-account observability | Prometheus, Loki, OpenTelemetry |
| Controls | Programmatic security controls | Pod Security Standards, Network Policies |
| Cost Management | Tagging strategy, cost allocation | Resource Quotas, LimitRange, 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 | - |
| 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:
yaml
# 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.mediumFrom this single manifest, KRO internally creates:
- Deployment + Service (Kubernetes native)
- RDS Instance (AWS resource via ACK)
- IAM Role (Permission setup via ACK)
For detailed examples, see ExampleCorp Integration Example.
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: Recommended, not enforced -- developers can deviate when needed, but it's the optimal choice in most cases
- Examples:
- "New Microservice Deployment" Golden Path: Helm Chart template → ArgoCD integration → Automatic Prometheus metrics collection
- "Database Provisioning" Golden Path: KRO RGD manifest → RDS creation via ACK → Automatic Secret injection
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 and improved? | - |
| [ ] | 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) |