5 minute read

AWS Platform Engineering: Build an Internal Developer Platform

Platform engineering gives application teams a supported path from source code to an operable AWS workload. The internal developer platform is the product; infrastructure automation, templates, portals, APIs, and documentation are capabilities that support it.

The goal is not to hide every AWS decision. It is to make common decisions safe and repeatable while keeping ownership, cost, and failure behavior visible.

Need to review a platform roadmap or golden path? Schedule a platform engineering assessment or use the contact page to describe the teams, workload type, and delivery bottleneck in scope.

Start with a platform product, not a tool list

AWS Prescriptive Guidance recommends treating an internal developer platform as a product, identifying developer needs, reducing cognitive load, and building reusable golden paths. See Building an internal developer platform on AWS and the associated platform principles.

Before selecting a portal or orchestration layer, answer:

  • Who are the first platform customers?
  • Which delivery journey causes the most repeated work or risk?
  • What must remain configurable, and what can be standardized?
  • Which team owns the platform roadmap and support model?
  • How will developers give feedback and contribute changes?
  • What evidence will show that the path is safer or easier to use?

If the platform team cannot name its first customer and journey, it is too early to choose the interface.

A concrete AWS golden path

Consider a team that needs to deploy a small HTTP API. A useful golden path can connect the following steps without pretending every workload is identical.

1. Request and ownership

The developer supplies a service name, owner, data classification, environment, repository, and expected traffic shape. Defaults handle common choices; exceptions require a reason and an owner.

2. Repository and template

The platform creates or updates a repository from a versioned template containing:

  • application and infrastructure source layout;
  • build and test commands;
  • dependency and secret scanning;
  • CODEOWNERS and review rules;
  • deployment and rollback workflow; and
  • service metadata for ownership and cost allocation.

Templates should be upgradeable. A copied template with no update path becomes another fleet of snowflakes.

3. AWS account and environment

The workflow targets an enrolled AWS account and approved Region, then uses a deployment role with temporary credentials. Account vending, baseline networking, logging, and security administration belong to the cloud foundation; the application golden path consumes those capabilities.

For that foundation, see the AWS multi-account security architecture guide.

4. Infrastructure and delivery

CloudFormation, CDK, Terraform, or OpenTofu defines the service resources. Pull requests show the change, run tests and policy checks, and produce a reviewable plan. The pipeline promotes the same artifact through environments and uses staged deployment where blast radius matters.

5. Guardrails

The template enforces the requirements that should be consistent:

  • no long-lived cloud credentials in the pipeline;
  • encryption and logging defaults;
  • scoped IAM roles;
  • ownership and cost metadata;
  • approved network exposure; and
  • deployment health and rollback criteria.

Guardrails need useful error messages and an exception process. A policy that only says “denied” pushes teams around the platform instead of through it.

6. Observability and operations

The deployed service registers dashboards, alarms, deployment events, a runbook, and an ownership record. The platform should not declare success at “stack created.” The service must be diagnosable and recoverable by the owning team.

7. Feedback and lifecycle

Developers can report friction, see template changes, and adopt updates. The platform also handles service retirement so unused environments, identities, DNS, and data do not remain indefinitely.

What to build first

AWS guidance on preparing an internal developer platform recommends inventorying current tools and processes, identifying cognitive load, and starting with one golden path.

A practical first increment is:

  1. Choose one willing application team and one workload shape.
  2. Document the current path from repository creation to production support.
  3. Remove one repeated handoff and one high-risk manual step.
  4. Package the result as a versioned template plus documentation.
  5. Run a real service through it and observe where developers leave the path.
  6. Fix the highest-friction point before onboarding another team.

This field sequence avoids a common failure mode: building a broad portal before the underlying delivery path works.

Platform capabilities by layer

Layer Platform responsibility Example AWS capabilities
Foundation Accounts, identity, networking, logs, baseline guardrails Organizations, Control Tower, IAM Identity Center, CloudTrail
Provisioning Versioned workload infrastructure and approved patterns CloudFormation, CDK, Service Catalog
Delivery Build, test, artifact promotion, deployment, rollback CodeBuild, CodePipeline, ECR, deployment services
Security Policy checks, findings, exceptions, evidence IAM Access Analyzer, Security Hub CSPM, Inspector, Config
Operations Metrics, logs, traces, alarms, incidents, runbooks CloudWatch, X-Ray, Systems Manager, Incident Manager
Cost Ownership, budgets, unit cost, recommendation workflow Cost Categories, Budgets, Cost Optimization Hub
Experience Templates, API/CLI/portal, docs, support, feedback Backstage or another interface over platform APIs

The exact services vary. The stable contract is the developer journey and its operating evidence.

Measure adoption and outcomes honestly

Do not publish a promised deployment-speed or cost-reduction percentage before measuring the baseline. Track metrics that the platform can actually influence:

  • time from approved request to a deployable environment;
  • time for a new service to pass the first production-readiness review;
  • golden-path adoption and abandonment points;
  • failed deployment and rollback frequency;
  • policy exceptions by age and owner;
  • support requests by workflow step;
  • services with complete ownership, runbook, and cost metadata; and
  • developer feedback about the specific journey.

Pair delivery metrics with reliability and cost. Faster provisioning is not a win if teams cannot operate or retire what they create.

Common platform engineering mistakes

Building a portal over broken workflows

A polished interface cannot repair unclear ownership, inconsistent infrastructure modules, or untested deployments. Stabilize the workflow first.

Requiring every team to migrate at once

Start with one workload shape and make adoption valuable. Teams with different runtime or compliance needs may require another path.

Hiding operational responsibility

Self-service does not mean no ownership. Every generated workload needs an owner, signals, recovery path, and lifecycle policy.

Treating exceptions as failures

Some workloads need different controls. Make exceptions visible, time-bound, and reviewable instead of forcing teams to bypass the platform.

Frequently asked questions

Does an internal developer platform require a web portal?

No. A CLI, API, repository template, or service catalog can provide the first self-service path. Add a portal when it materially improves discovery or workflow usability.

Should every workload use the same golden path?

No. Standardize a common workload shape, then create additional supported paths when real demand and different constraints justify them.

Who owns the platform?

A platform team owns the product and roadmap, but application teams remain responsible for their services. Security, finance, and operations stakeholders contribute requirements and feedback.

Contact Jon Price to review an AWS platform engineering plan.

Updated:

You may also enjoy