Gartner predicted that by 2026, 80% of large software engineering organizations would establish platform engineering teams. That prediction landed. Platform engineering is no longer a trend — it's the default operating model for cloud-native organizations.
But here's what most teams get wrong: they build a platform nobody uses. They create golden paths developers ignore, self-service portals that are harder than Terraform, and governance layers that slow teams down.
This post covers how to build an Internal Developer Platform (IDP) on AWS that developers actually adopt — the architecture, the AWS services that power it, the golden path patterns, and the operating model that sustains it.
What Is Platform Engineering?
Platform engineering is the practice of building and maintaining an Internal Developer Platform — a self-service layer that abstracts infrastructure complexity while enforcing organizational standards.
WITHOUT PLATFORM WITH PLATFORM
Developer → learns Terraform Developer → picks template
→ configures VPC → clicks deploy
→ sets up IAM → gets environment
→ creates pipeline → ships code
→ manages monitoring
→ handles security
Cognitive load: HIGH Cognitive load: LOW
Time to first deploy: Weeks Time to first deploy: Minutes
Consistency: None Consistency: Enforced
The goal: Developers get self-service access to production-ready infrastructure without needing to become infrastructure experts.
The IDP Architecture on AWS
┌─────────────────────────────────────────────────────────────────┐
│ DEVELOPER INTERFACE (Portal) │
│ Backstage | Custom Portal | Service Catalog Console │
├─────────────────────────────────────────────────────────────────┤
│ ORCHESTRATION (Provisioning Engine) │
│ Service Catalog | Proton | CDK Pipelines | Crossplane | ArgoCD │
├─────────────────────────────────────────────────────────────────┤
│ TEMPLATES (Golden Paths) │
│ CloudFormation | Terraform | CDK | EKS Blueprints | Cookiecutter│
├─────────────────────────────────────────────────────────────────┤
│ PLATFORM SERVICES (Shared Capabilities) │
│ CI/CD | Observability | Security Scanning | Secrets | DNS │
├─────────────────────────────────────────────────────────────────┤
│ INFRASTRUCTURE (Managed by Platform Team) │
│ EKS | ECS | Lambda | RDS | S3 | VPC | IAM | KMS │
└─────────────────────────────────────────────────────────────────┘
The 5 Capabilities Every IDP Needs
1. Self-Service Infrastructure Provisioning
Developers should deploy environments without filing tickets or waiting for ops teams.
AWS Options:
| Service | Best For | Developer Experience |
|---|---|---|
| AWS Service Catalog | Governed AWS resource provisioning | Console/API, pre-approved products |
| AWS Proton | Container and serverless environments | Template-based, managed pipelines |
| CDK Pipelines | Custom IaC with CI/CD | Code-first, GitOps-style |
| EKS Blueprints | Kubernetes cluster standardization | Addons + configurations pre-packaged |
Service Catalog pattern:
Platform Team creates "Products":
├── "Web Application" → VPC + ALB + ECS + RDS + CloudWatch
├── "Data Pipeline" → S3 + Glue + Step Functions + Athena
├── "API Backend" → API Gateway + Lambda + DynamoDB
└── "ML Workspace" → SageMaker Studio + S3 + IAM role
Developer: Launches product → fills 5 parameters → gets full stack in 10 minutes
2. Golden Paths (Opinionated Templates)
Golden paths are pre-built, production-ready templates that encode best practices. They're not mandatory — but they're so much easier than building from scratch that teams naturally adopt them.
What makes a golden path "golden":
- Security pre-configured (IAM roles, encryption, network isolation)
- Observability built-in (CloudWatch dashboards, alarms, X-Ray tracing)
- CI/CD included (pipeline deploys on merge)
- Cost-optimized (right-sized, auto-scaling configured)
- Compliance-ready (tagging, logging, Config rules)
Example golden path: "Microservice on ECS"
Developer runs: `platform create service --type=ecs-microservice --name=payment-api`
Platform creates:
├── ECR repository
├── ECS service + task definition (Fargate, Graviton)
├── ALB target group + listener rule
├── CodePipeline (source → build → deploy)
├── CloudWatch dashboard + alarms
├── IAM task role (least privilege)
├── Security group (ingress from ALB only)
├── X-Ray tracing enabled
└── Resource tags (team, cost-center, environment)
Developer gets a working, production-grade service in minutes. No Terraform expertise required.
3. Built-In CI/CD
Every golden path should include a deployment pipeline. Developers shouldn't configure CI/CD — it should come free with the platform.
Pattern: CodePipeline per service (auto-provisioned)
Service creation triggers:
├── CodeCommit/GitHub repo created
├── CodeBuild project (build + test + scan)
├── CodeDeploy / ECS rolling update
├── Pipeline stages: Source → Build → Test → Deploy-Dev → Deploy-Staging → Deploy-Prod
└── Quality gates: unit tests, SAST scan, container scan, integration tests
Alternative: GitOps with ArgoCD (for EKS platforms)
Developer pushes code → CI builds image → updates manifest repo →
ArgoCD detects change → syncs to EKS cluster → progressive rollout
4. Observability as a Platform Service
Don't make developers configure monitoring. Bake it into every golden path:
| Layer | Auto-Configured | Service |
|---|---|---|
| Metrics | CPU, memory, request count, error rate, latency | CloudWatch Container Insights / EMF |
| Logs | Structured JSON, centralized, retention policies | CloudWatch Logs + Log Insights |
| Traces | Distributed tracing across services | X-Ray / OpenTelemetry on ADOT |
| Dashboards | Per-service dashboard auto-generated | CloudWatch Dashboards |
| Alerts | SLO-based alerting (error rate > 1%, latency p99 > 500ms) | CloudWatch Alarms → SNS → PagerDuty |
Developer experience: Deploy a service → dashboard appears automatically → alerts fire if SLOs breach. Zero configuration.
5. Security and Compliance Guardrails
The platform enforces security without developer intervention:
- IAM boundaries — permission boundaries on developer roles prevent privilege escalation
- Container scanning — ECR image scan on push, block deployment if critical CVEs
- SAST/SCA — code scanning in pipeline (CodeGuru, Snyk, Checkov)
- Network isolation — services get private subnets by default, no public access unless explicitly approved
- Secrets management — Secrets Manager integrated into task definitions, no hardcoded credentials
- Config rules — continuous compliance checking (encryption enabled, public access blocked, tags present)
AWS Proton: The Managed Platform Engine
AWS Proton is purpose-built for platform engineering:
- Environment templates — define shared infrastructure (VPC, cluster, logging)
- Service templates — define workload patterns (how services deploy INTO environments)
- Versioning — templates are versioned; platform team upgrades without breaking existing services
- Self-service — developers create services from templates via console, CLI, or API
- Sync from Git — templates stored in Git, Proton syncs changes automatically
Proton Architecture
Platform Team Developer
│ │
▼ │
┌──────────────┐ │
│ Environment │ (VPC, EKS, RDS, shared) │
│ Template v2 │ │
└──────────────┘ │
▼
┌──────────────┐ ┌──────────────┐
│ Service │ ────────────────→ │ My Service │
│ Template v3 │ (developer picks) │ (deployed) │
│ (ECS+ALB+CD)│ └──────────────┘
└──────────────┘
EKS Blueprints: Platform for Kubernetes
If your IDP is Kubernetes-based, EKS Blueprints (CDK or Terraform) provide standardized cluster provisioning:
What Blueprints package:
- EKS cluster with managed node groups (Graviton, Spot)
- Core addons: CoreDNS, kube-proxy, VPC CNI, EBS CSI
- Platform addons: ArgoCD, Karpenter, Prometheus, Grafana, cert-manager, external-dns
- Team namespaces with RBAC and resource quotas
- GitOps pipeline for addon management
Developer experience: Request a namespace → get isolated Kubernetes namespace with resource quota, network policy, service account, and ArgoCD project. Deploy via Git push.
Developer Portal: The Front Door
A developer portal gives visibility into all platform services, documentation, and self-service actions.
Backstage (Open Source, Popular Choice)
- Service catalog — discover all services, their owners, and documentation
- Software templates — create new services from golden paths via UI wizard
- TechDocs — documentation lives alongside code
- Plugins — integrate AWS services, CI/CD status, cost dashboards
- Scorecards — track adoption of best practices per team
Alternative: Custom Portal
Some teams build a simpler portal with:
- React frontend
- API Gateway + Lambda backend
- Service Catalog / Proton API integration
- CloudFormation/Terraform execution via CodeBuild
The Platform Team Operating Model
What the Platform Team Owns
- Golden path templates (create, update, deprecate)
- Shared infrastructure (networking, clusters, CI/CD pipelines)
- Security baselines (scanning, guardrails, compliance)
- Observability stack (metrics, logs, traces, dashboards)
- Developer experience (portal, documentation, onboarding)
What the Platform Team Does NOT Own
- Application code
- Business logic
- Feature decisions
- Application-level testing
Team Size Guidance
| Organization Size | Platform Team | Ratio |
|---|---|---|
| 50 developers | 3-5 platform engineers | 1:10-15 |
| 200 developers | 8-12 platform engineers | 1:15-20 |
| 500+ developers | 15-25 platform engineers | 1:20-30 |
Measuring Platform Success
| Metric | Target | Measures |
|---|---|---|
| Time to first deploy | < 1 day | Onboarding friction |
| Golden path adoption | > 80% | Template quality |
| Lead time for changes | < 1 hour | CI/CD effectiveness |
| Developer satisfaction (NPS) | > 40 | Overall experience |
| Mean time to recovery | < 30 min | Platform reliability |
| Self-service ratio | > 90% | Ticket reduction |
Common Anti-Patterns
| Anti-Pattern | Problem | Fix |
|---|---|---|
| "Build it and they will come" | Developers ignore the platform | Co-design with dev teams, solve THEIR pain points |
| Too much abstraction | Developers can't debug issues | Provide escape hatches and visibility |
| Mandatory everything | Creates friction, teams route around | Make golden paths easier than alternatives, not mandatory |
| Platform as ticket queue | Defeats self-service purpose | If devs still file tickets, the platform isn't done |
| Over-engineering v1 | Launches too late, already outdated | Start with 1-2 golden paths, iterate based on adoption |
| No documentation | Developers can't onboard | Treat docs as product feature, not afterthought |
Getting Started: The 90-Day Plan
Days 1-30:
- Interview 5 dev teams about their biggest infrastructure pain points
- Identify the #1 most-deployed workload pattern (usually: web API or containerized service)
- Build the first golden path template for that pattern
Days 31-60:
- Deploy Service Catalog or Proton with the first template
- Onboard 2 teams as pilot users
- Iterate based on feedback (what's missing? what's confusing?)
Days 61-90:
- Add CI/CD and observability to the golden path
- Build second template based on demand
- Launch developer portal (even basic) with documentation
- Measure: adoption rate, deploy frequency, support tickets avoided
Summary
Platform engineering on AWS is about reducing developer cognitive load while maintaining governance:
- Self-service provisioning — Service Catalog, Proton, or custom portal. No tickets.
- Golden paths — opinionated templates with security, CI/CD, and observability built in.
- Shared platform services — CI/CD, observability, security scanning as platform capabilities.
- Developer portal — Backstage or custom. Discoverability and documentation.
- Operating model — platform team owns templates and shared infra, not application code.
The best platforms aren't built by mandate. They're adopted because they're easier than the alternative. Start with one golden path that solves a real developer pain point, and grow from there.
Alpesh Kumbhare is an AWS Architect at Atos, specializing in AWS infrastructure automation and platform engineering. Connect on LinkedIn.
Top comments (0)