An AWS platform service is an internally operated product that gives delivery teams a supported way to obtain accounts, infrastructure, deployment workflows, observability and security controls. Its value comes from reducing repeated decisions and waiting time while preserving organizational policy. This AWS platform service FAQ explains how landing zones, controls and developer self-service fit together and where platform responsibility ends.
Teams planning implementation should use the AWS platform service checklist and the platform service cloud design plan. Smaller organizations can compare the minimum viable platform guide. The right first platform is narrow: one reliable path for a frequent workload is more useful than a catalog full of unsupported templates.
What does an AWS platform service include?
A typical service includes a governed AWS organization, account provisioning, identity federation, network and DNS patterns, logging, security monitoring, infrastructure modules, CI/CD integration, secrets, runtime templates, cost allocation, documentation and support. Not every company needs every capability centrally. The platform should own shared foundations and repeatable automation; application teams should own workload code, data, service objectives and the way their application uses cloud services.
AWS describes an internal developer platform as a self-service product for environments, deployments, resources and configuration. The official AWS internal developer platform guidance emphasizes self-sufficiency, lower cognitive load, reusable building blocks and automation. Those aims require product management: named users, discovery, a roadmap, service levels, adoption support and a route for teams to request or contribute new capabilities.
| Platform owns | Workload team owns | Shared decision |
|---|---|---|
| Account vending and baseline | Application resources inside the account | Account classification and exceptions |
| Federation and role patterns | Role requests and least-privilege use | Privileged access and emergency paths |
| Approved infrastructure modules | Module configuration and workload code | New service or pattern onboarding |
| Central telemetry route | Application signals and runbooks | Retention, alerting and incident roles |
| Cost tags and allocation data | Workload demand and optimization | Budgets and unit-economics targets |
Is AWS Control Tower the platform?
No. AWS Control Tower can establish and govern a multi-account landing zone, but the developer product includes workflows and support above that foundation. AWS Control Tower orchestrates services including AWS Organizations, IAM Identity Center and Service Catalog. It provides a landing zone, controls, Account Factory and governance visibility. A platform team must still design organizational units, identity, networks, account lifecycle, workload paths, exceptions and operations.
Keep the management account focused on organization management and restrict routine workloads. Separate log archive, audit or security functions and production workloads according to risk and operating model. Decide which regions are governed and how existing accounts are enrolled. Treat the landing-zone configuration as controlled infrastructure, test updates in a representative environment, and avoid modifying AWS Control Tower-managed resources through unsupported paths.
How do guardrails and SCPs work?
AWS Control Tower uses the term controls for high-level governance rules. The Control Tower controls documentation distinguishes preventive controls that deny actions, detective controls that identify noncompliance and proactive controls that evaluate CloudFormation resources before provisioning. Choose the mechanism according to timing and consequence. A policy that must never be violated needs prevention where feasible; a configuration that requires context may be better detected and routed for remediation.
A service control policy defines the maximum available permissions for identities in member accounts; it does not grant permissions. The AWS Organizations SCP guide recommends testing effects before applying an SCP broadly. Use a test organizational unit and representative roles, verify service dependencies and retain an emergency recovery path. Document the user-facing error and support route so a denied deployment leads to a clear fix instead of policy avoidance.
- Express each control as an organizational outcome and identify affected workloads.
- Choose preventive, proactive or detective enforcement from risk and operational context.
- Test policies with service last-accessed data and representative deployment fixtures.
- Version policy, rollout, exception, remediation and rollback records.
- Monitor control coverage and stale exceptions, not only current violation counts.
- Keep platform administrators subject to attributable, time-bounded privileged access.
What is an AWS golden path?
A golden path is an opinionated, supported route from repository to production for a common workload. It can create an account or environment, pipeline, runtime, identity, logs, alarms, backup and ownership metadata from a small set of inputs. The AWS platform principles recommend a product mindset, customer focus, self-service, optional use, golden paths and simple onboarding. The path should hide accidental complexity while preserving the controls and choices a workload owner must understand.
Start from one workload archetype such as a containerized API, serverless event processor or static application. Publish prerequisites, generated resources, support boundary, upgrade policy and escape hatch. Provide source-controlled modules and examples, not a click-only portal. Teams need a way to inspect plans, test changes and own their configuration. An exception should be a governed alternate path with an owner and review date, not an undocumented fork of platform code.
| Golden-path gate | Automated evidence | Owner confirmation |
|---|---|---|
| Request | Account, environment, owner and data classification | Business and technical ownership is valid |
| Plan | Infrastructure diff, policy checks and estimated cost | Workload configuration fits purpose |
| Build | Tests, scans, artifact identity and provenance | Release candidate meets application criteria |
| Deploy | Approval, change record and environment health | Production release is authorized |
| Operate | Logs, metrics, alarms, backup and runbook links | On-call team accepts the service |
| Improve | Usage, friction, incidents and deprecation state | Roadmap reflects evidence |
How should identity and access be structured?
Federate workforce access through IAM Identity Center or the approved identity provider and map roles to job functions and account classes. Prefer short-lived role sessions to IAM users and long-lived access keys. Workloads should use service roles or workload identity with permissions scoped to the resource and action. Separate platform deployment, security inspection and workload operation duties where risk warrants it, and log role assumption centrally.
Design break-glass access before an outage. Protect emergency identities with strong authentication, restricted custody, alerting and post-use review. Verify that central identity failure does not make every recovery action impossible. Review unused permissions with access evidence and remove stale assignments. The platform can supply patterns and analysis, but workload owners must explain why their application needs each data or service permission.
How is an AWS platform operated?
Publish service objectives for account provisioning, pipeline availability, incident response and supported module versions. Monitor central log delivery, configuration recording, identity federation, DNS, networking, artifact stores, policy evaluation and account lifecycle. Use synthetic requests to prove that a developer can complete the golden path, because a green AWS service dashboard does not prove that the internal product works end to end.
Review workloads against the AWS Well-Architected Framework as a structured conversation about tradeoffs across operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. Do not turn the review into a one-time badge. Track high-risk improvements, owners and due dates. Platform defaults should absorb repeated lessons, while workload-specific findings remain with application teams.
How should platform value be measured?
Measure the user funnel from discovery to successful production operation. Useful indicators include time to first deployment, provisioning success, path adoption, manual tickets per onboarding, upgrade lag, control exceptions, deployment recovery time and developer satisfaction tied to specific journeys. The platform adoption metrics guide explains why usage alone is incomplete: a team can invoke a template once and then abandon it.
Allocate platform cost transparently across shared foundations, team-operated services and workload consumption. Track unit costs such as account or deployment served, but avoid incentives that cause underinvestment in resilience. Show workload teams cost and usage quickly enough to act. Platform success is a combination of shorter delivery time, lower repeated toil, stronger control coverage and reliable operation, not merely a lower central cloud bill.
Example: a container service golden path
A product team supplies repository, owner, data class, environments and service objective. The platform creates accounts, roles, pipeline, signed image flow, runtime, network policy, logs, alarms, backup and cost tags from versioned modules. The deployment plan shows policy checks and estimated cost; production promotion requires application acceptance. A synthetic transaction proves the route after release, while the team owns business metrics and its runbook. Exceptions are recorded against the path with a review date, and repeated exceptions become evidence for the platform roadmap.
Key takeaways
- Treat the AWS platform service as an internal product built on a governed landing zone.
- Use multi-account boundaries and short-lived identity to make ownership and impact clearer.
- Test controls and SCPs with representative workloads before broad attachment.
- Start with one supported golden path and make its boundaries, evidence and escape route explicit.
- Operate the developer journey end to end, not only the underlying AWS resources.
- Measure adoption, lead time, exceptions, reliability and unit cost together.
Does an internal developer platform require a portal?
No. A portal can improve discovery and orchestration, but a useful first platform may consist of documented templates, APIs, command-line workflows and support. Add a portal when it reduces a measured user problem and can represent state accurately. Do not put a polished interface in front of slow manual fulfillment and call it self-service.
Can existing AWS accounts join the platform?
Often yes, after discovery and remediation. Inventory ownership, regions, identity, logging, network dependencies, policies, quotas and unsupported resources. Test enrollment in a controlled sequence and define rollback. Some accounts may need restructuring or migration before they can inherit the standard baseline. Do not force enrollment when it would disrupt a critical workload without a proven recovery plan.
Conclusion
A strong AWS platform service makes the secure path the understandable path. Landing-zone controls provide the foundation; golden paths, support and measured adoption turn that foundation into a developer product. Keep scope narrow enough to operate well, learn from real journeys and expand only when a repeated need and clear owner exist.