Internal Developer Platforms on AWS - What Narrows the Choices, What Enforces the Permissions, and What Still Gets Around Both

First Published: 2026-09-09
Last Updated: 2026-09-09

You build a catalog. You list approved templates, and developers pick from them to stand up their environments. It looks like governance is in place.

However, what happens if a developer bypasses the catalog and directly calls APIs? The answer depends entirely on what the developer's own IAM permissions allow. The catalog is a list of options, not a boundary for permissions.

Put the axis first. Narrowing the choices and narrowing the permissions are not the same operation. Creating a catalog and listing products only addresses the former. The IAM role attached to those products does the latter. The two operations are configured on the same screens, talked about in the same words, and nothing on screen warns you when only one of them is set.

This article is written for someone handing out AWS environments to several teams inside one company. Once a paved road is laid, how much freedom is left to leave it, and what is actually holding the governance up? Only once you know that can you decide how much of your own organization to turn into products.

The technical details in this article were verified, as of September 8, 2026, against the AWS Service Catalog Administrator Guide and API Reference, the AWS Prescriptive Guidance documents, the AWS Product Lifecycle page and Service Availability Updates, and the official documentation for Backstage and Crossplane. Availability status is the fastest-moving thing in this article. Look up the state of each component again at the time you read this, before you use any of it to decide. This article does not address pricing details, nor does it compare the merits of third-party products or open-source projects.

1. There Are Two Different Things Being Narrowed
2. AWS's Own Design Guides Split at Exactly This Seam
3. What the Catalog Actually Narrows
4. What Actually Enforces the Narrowing
5. The Further You Move From CloudFormation, the Fewer Ways to Narrow
6. The Surface the Developer Sees
7. Building the Surface on Kubernetes
8. Deciding How Much to Turn Into a Product
9. The Paving Itself Ages
10. Failure Modes
11. Design Checklist
12. Frequently Asked Questions
13. Summary
14. References

1. There Are Two Different Things Being Narrowed

1.1 The Position This Article Assumes

The reader this article has in mind hands AWS environments to several teams. The accounts are already handed out, and the goal is to enable each team to set up their own environments independently. It is aimed at readers who have hit one of the following:

You had leaned your template distribution on an AWS managed service, and that surface was folded up.
Each team writes its own Infrastructure as Code (IaC), and the center cannot see what is in production.
Management or the audit function has told you that going self-service will turn into a free-for-all.

All three scenarios ultimately address the same question: Once you have narrowed what developers can reach, what is holding that narrowing in place?

This article does not aim to provide a universal solution regarding which specific products to use. Instead, its purpose is to help you understand what guarantees your own chosen approach provides, and what it does not, for a developer who leaves the road.

1.2 What Catalog Refers to in This Article

Confusingly, three different catalogs appear in this area. Writing them all with the same word would erase the central distinction of this article, so each one keeps a separate name throughout.

AWS Service Catalog refers to the AWS service of that name, and to nothing else.
software catalog refers to a capability of a developer portal. It is a register of what exists and who owns it.
The bare word catalog refers to the general noun, a list of things you can choose from.

For the same reason, product in a code span refers to the AWS Service Catalog identifier itself, while the plain word product refers to something an organization offers its internal users. portfolio is treated the same way.

1.3 On the Term Paved Road

The terms golden path and paved road are widely used to refer to the standard paths provided to developers. AWS itself uses this terminology in its official design guides. The AWS Prescriptive Guidance internal developer platform guide, for example, uses golden path as a central term:

Golden paths are the most fundamental capability that the internal developer platform should
provide.

However, this is a term used in design guides, not an API identifier. Neither the console nor the API has an entry called golden path. The expression paved road refers to the result of combining several separate mechanisms, and the term itself does not tell you which mechanism is responsible for what. This article opens that breakdown.

1.4 The Two Kinds of Narrowing Sit in Different Places

A developer's request passes through four surfaces: the surface that is seen, the surface that is selected from, the permissions that get handed over, and what actually gets created. Of these, only one cannot be avoided on either route.

Four surfaces a request passes through, and the one that cannot be skipped

The surface that is seen and the surface that is selected from can both reject a request under the right conditions. But they do so only when the developer goes through them. Neither surface stops the developer from creating the same resource by another route. What stops that is the permissions attached to the developer's own identity, or the mechanism that makes them use permissions attached to the product instead.

This article opens the four surfaces in order. Section 3 takes the surface that is selected from, Section 4 the permissions surface, and Section 6 the surface that is seen. Section 5 describes what changes when you look at it from the side of what actually gets created.

2. AWS's Own Design Guides Split at Exactly This Seam

2.1 The Two Guides Never Reference Each Other

AWS Prescriptive Guidance has two related design guides in this area: one focuses on how to build an internal developer platform, and the other addresses how to package infrastructure as a product.

Guide	Publication Date	Chapters (Main Content)	Primary Focus
Building an internal developer platform on AWS	April 22, 2024	7	The surface the developer sees, and the capabilities laid out on it.
Implementing IaP on AWS	January 30, 2023	14	Defining and distributing products using AWS Service Catalog.

The chapter counts come from each guide's table of contents, with Document history and Resources left out. Both guides' publication dates reflect the initial release date in their respective document histories, and neither guide records any subsequent revisions.

The two split at exactly the seam this article deals with. As of September 8, 2026, after fetching every one of the chapters counted above and counting the terms, the numbers came out as follows. The table below lists the term and the number of times it appears, along with the chapter(s) in which it is found.

Term	Internal Developer Platform Guide (7 Chapters)	IaP Guide (14 Chapters)
`Service Catalog`	0 occurrences / 0 chapters	166 occurrences / 14 chapters
`portal`	3 occurrences / 3 chapters	0 occurrences / 0 chapters
`golden`	27 occurrences / 5 chapters	0 occurrences / 0 chapters
`constraint`	0 occurrences / 0 chapters	1 occurrence / 1 chapter

The first guide lays out 14 kinds of capability for what to show developers, and does not put AWS Service Catalog in that table. The second guide uses AWS Service Catalog throughout all 14 chapters, but never uses the term developer portal. Both guides are detailed about their own focus areas, but provide no information about the other.

The last row is the one that matters for this article. The one constraint in the IaP guide sits in the chapter on Service Catalog Puppet, and it refers to a stack set constraint. The term launch constraint does not appear anywhere in this guide. The term launch role appears only twice: once in a sentence describing how a product is associated with either a launch IAM role or a stack set, and once in a sentence stating that Service Catalog Puppet utilizes both the administrator role and the launch role.

So neither of the two AWS design guides explains much of the mechanism that Section 4 examines. One guide dwells on the surface the developer sees, the other on defining and distributing products. The question that sits between them, what actually enforces the narrowing, is at the center of neither guide. It sits in the administrator guide and the API reference instead. This article addresses the connection between those two.

2.2 The Surface That Distributed Templates Was Folded Up

AWS Proton, the managed service AWS offered for distributing platform templates, closed to new customers on October 7, 2025, and ends support on October 7, 2026. Existing customers will be able to continue using the service until that date.

This article does not provide an explanation of AWS Proton. Information regarding what will be lost and what will remain upon its discontinuation, as well as the available migration options, can be found in the previously published article AWS Service Lifecycle States.

The only key point for this article is this: What was folded up is the surface that distributed templates, not the mechanism AWS uses to hold governance. That mechanism is still in AWS Service Catalog, and the next section goes through it.

3. What the Catalog Actually Narrows

3.1 What product and portfolio Take as Their Unit

In AWS Service Catalog, a product is a collection of AWS resources that together provide a single capability. This could be a single instance or an entire multi-layered application. A portfolio groups products together and serves as the unit for managing who can access and use them. A single product can belong to multiple portfolios.

You grant permissions at the portfolio level. When a user is given access to a portfolio, they can view and launch the products contained within it. So the portfolio is what decides the set of options a developer sees.

3.2 There Are Six Types

Versions of product are referred to as provisioning artifacts. The API reference for ProvisioningArtifactDetail lists six Valid Values for its Type.

CLOUD_FORMATION_TEMPLATE | MARKETPLACE_AMI | MARKETPLACE_CAR | TERRAFORM_OPEN_SOURCE |
EXTERNAL | TERRAFORM_CLOUD

The descriptive text on the same page only describes four. While MARKETPLACE_AMI and MARKETPLACE_CAR appear in the enumerated values, they are not mentioned in the subsequent bullet points. When counting the types, it is necessary to refer to the enumerated values in the API reference rather than the descriptive text that explains the features.

The differences between the types become significant in Section 5. For now, it is sufficient to understand that the available functionality varies depending on the type.

3.3 Adding a Version and Allowing a Version Are Different Acts

AWS Service Catalog allows you to manage multiple versions of a product. When a new version is created, it is made available to everyone who has access to that product, and users can choose which version to use. It is also possible to update existing resources to the new version.

Note the distinction here. Publishing a new version and stopping people from using an old one are separate operations. Guidance does the latter, and the API reference states:

The administrator can set the guidance to DEPRECATED to inform users that the product version
is deprecated. Users are able to make updates to a provisioned product of a deprecated version
but cannot launch new provisioned products using a deprecated version.

DEPRECATED prevents new launches but does not prevent updates to existing resources. Misunderstandings can arise when users intend to disable a version but existing environments continue to update.

To completely hide a version, set Active to false. The API reference for UpdateProvisioningArtifact states that inactive provisioning artifacts are not visible to users and cannot be launched or updated from. There are two separate methods for disabling a version, each affecting a different scope.

4. What Actually Enforces the Narrowing

4.1 What a Launch Constraint Does

This section is central to the article. The administrator guide describes what developers need, even when simply listing product offerings in a catalog, as follows:

Without a launch constraint, end users must launch and manage products using their own IAM
credentials. To do so, they must have permissions for CloudFormation, AWS services that the
products use, and AWS Service Catalog.

When only listing products in the catalog, developers can launch them using their own permissions. In other words, the developer needs to have their own permissions to access the AWS services used by the product, and if they do, they can perform the same actions without using the catalog. In this state the catalog offers a list of options, standardized templates, and records you can audit. It has added no governance at all.

A launch constraint reverses that relationship. The administrator guide summarizes this as follows:

With launch constraints, you specify a role for a product in a portfolio. Use this role to
provision the resources at launch, so you can restrict user permissions without impacting
users' ability to provision products from the catalog.

A launch constraint specifies the IAM role that AWS Service Catalog assumes when a developer launches, updates, or terminates a product. The permission to create resources belongs to that role, and the developer does not hold it. This allows developers to operate with minimal permissions, only launching from the catalog.

This is where the thing that enforces the narrowing actually sits. Listing a product in the catalog says only that the option exists. It does not say the developer has no other route. The developer's lack of alternative methods is a result of their own IAM permissions being limited. They can still do their work because the launch constraint hands them a role.

The scope needs attention too. The administrator guide states:

Launch constraints apply to products in the portfolio (product-portfolio association).
Launch constraints do not apply at the portfolio level or to a product across all portfolios.

Apply launch constraints to each product within a portfolio, not to the portfolio as a whole. Even if you want to use the same role for all product offerings within a portfolio, you need to apply it individually. If you forget to apply a launch constraint to a product, it will revert to a state where the developer can launch it using their own permissions.

While the launch role sets a limit, that role itself is also subject to limitations. The launch role is one more IAM role, so the service control policies on the account it runs in govern it too. Widening the launch role on the paved road side does not lift the organization's ceiling.

Note that three permissions, servicecatalog:ProvisionProduct, servicecatalog:TerminateProvisionedProduct, and servicecatalog:UpdateProvisionedProduct, cannot be assigned in a launch role. Instead, these permissions belong in the developers' own IAM. What the developer keeps is the permission to operate the catalog, not the permission to create resources. That split is the design.

4.2 There Are Five Kinds of Constraint

The chapter that introduces constraints lists five types.

Type	What it Restricts
`Launch`	Specifies the IAM role used when creating resources.
`Notification`	Specifies the SNS topic to receive stack events.
`Tag Update`	Determines whether users are allowed to update tags on launched resources.
`Stack Set`	Defines the accounts and Regions the stack set deploys to, and the order of deployment.
`Template`	Narrows the range of values users can select for parameters at launch time.

The AWS Service Catalog overview page only lists three of these five types: Launch, Notification, and Template. The overview page is an introductory document, so it simplifies the categorization; Tag Update and Stack Set are only described on individual pages. When you need the full set, read the constraints chapter or the individual pages.

Of these five types, only Launch directly relates to developer permissions. The other four decide which values can be picked, where notifications go, where things deploy, and how tags are handled. All four are useful, and none of them stops a developer from creating the same resource by another route.

4.3 What a Template Constraint Narrows Is the Parameters

A template constraint narrows the values a user can pick for the parameters of the CloudFormation template behind a product. For example, they can be used to restrict instance types to smaller options. A template constraint consists of one or more rules, and you apply it to a product in a portfolio.

Keep these three key characteristics in mind:

Portfolio-specific. Even if a template constraint is applied to a product within a portfolio, it will not apply if that same product is added to a different portfolio.
Most restrictive rule prevails. When a portfolio and a product carry several constraints, AWS Service Catalog applies the most restrictive of them.
Effective immediately for shared products. Once applied, the constraint takes effect immediately for all subsequent launches and applies to every version of that product in the portfolio.

A template constraint is a mechanism for narrowing the values you can pick, not for narrowing permissions. Whether a developer can launch larger instances directly, bypassing the catalog, depends on their IAM permissions and has nothing to do with any template constraint.

4.4 Sharing the Catalog Has Permission Consequences Too

A portfolio can be shared with other accounts and organizational units. When sharing, if the share-by-principal-name setting is enabled, accounts receiving the share will be able to launch the product in the portfolio if they hold a principal with a matching name. The API reference includes a specific note regarding this functionality.

When you associate a principal with portfolio, a potential privilege escalation path may
occur when that portfolio is then shared with other accounts.

Even users who are not AWS Service Catalog administrators can create roles whose names match the associated principal in the receiving account. The API reference recommends setting the PrincipalType to IAM if this route is a concern. With this setting enabled, the association can only be made if a PrincipalARN already exists in the receiving account.

Handing out the catalog has permission consequences of its own. Treat it as an operation that decides what people see, and this path never enters your field of view.

5. The Further You Move From CloudFormation, the Fewer Ways to Narrow

5.1 The External Type and Its Rename

AWS Service Catalog can handle Infrastructure as Code (IaC) tools other than CloudFormation. The EXTERNAL type is designed to integrate with third-party provisioning engines, and the administrator guide states:

The EXTERNAL product type allows for the integration of third-party provisioning engines,
such as Terraform.

There is a rename to account for here. Following the Terraform licensing change, the administrator guide states:

The External product type includes support for the Terraform Community Edition, previously
known as Terraform Open Source.

The guide states that it changed every previous reference to Terraform Open Source into External. While the API still includes the value TERRAFORM_OPEN_SOURCE, the documentation and console have been updated to use External. Because the same functionality is currently referred to by two different names, it is necessary to include both names when writing internal procedures.

With the EXTERNAL type, AWS Service Catalog delegates processing to the engine. It stores the provisioning artifact, sends launch requests to a queue, and the engine assumes the launch role to create resources and then reports the results via a notification API. The AWS Cloud Operations blog notes that, while AWS Service Catalog stores the provisioning artifact, it does not validate External type IaC templates, unlike CloudFormation templates. You have to do that validation yourself.

5.2 Which Constraints You Can Use Depends on the Type

Each constraint page specifically lists incompatibilities for Terraform-related types. And the types they name are not the same from page to page.

`constraint`	CloudFormation	Types Listed as Incompatible
`Launch`	Available	None. Used with the Terraform types too, with steps in the tutorial.
`Notification`	Available	Terraform Open Source and Terraform Cloud
`Tag Update`	Available	Terraform Open Source
`Stack Set`	Available	Terraform Open Source
`Template`	Available	Terraform Open Source and Terraform Cloud

Tag Update and Stack Set name only Terraform Open Source as unsupported and say nothing about Terraform Cloud. The other two name both. Whether this difference is intentional or a documentation oversight cannot be determined from the official documentation. If you plan to use these two with Terraform Cloud, you will need to verify their behavior in practice, rather than relying on the documentation.

One key takeaway from this table is that as you move away from CloudFormation, the mechanisms that narrow the choices fall away, but the mechanism that narrows permissions stays. The launch constraint is the only one you can count on with the Terraform types, and it is exactly the one of the five that touches developer permissions.

Not being able to narrow the range of parameter values means that narrowing has to be done again somewhere else, on the IaC side, in the engine, or in review. Pick a type without deciding who takes over for the mechanisms that fell away, and what you thought you had narrowed turns out to be narrowed by nobody.

5.3 This Article Does Not Compare the IaC Tools Themselves

Which IaC tool to pick, how to manage state, and how to migrate between tools belong to the previously published article Comparing Terraform, AWS CDK, AWS SAM, and CloudFormation. This article will not cover the process of choosing a tool. It describes only how the ways of narrowing change once the tool you picked is handed out as a product.

6. The Surface the Developer Sees

6.1 What the Software Catalog Holds

The developer portal consolidates information about what exists, who owns it, and where documentation can be found, all in one place. The AWS Prescriptive Guidance internal developer platform guide names Backstage as the recommended tool for the developer portal capability.

On the Backstage software catalog, the official documentation states:

The Backstage Software Catalog is a centralized system that keeps track of ownership and
metadata for all the software in your ecosystem (services, websites, libraries, data
pipelines, etc).

It is a register of ownership and metadata. Entries live as YAML files under version control, next to the code. Software Templates, for its part, reads a skeleton of code, fills in variables, and publishes it to somewhere like GitHub or GitLab. Whatever it creates is registered in the software catalog automatically.

All of this helps developers find what exists and gives a starting point for creating new things. However, it does not dictate what developers are permitted to do on AWS.

6.2 Not Protected by Default

Backstage includes an authorization framework that allows you to define who can access which resources and what actions they can perform. However, the official documentation clearly states the default configuration.

By default, Backstage endpoints are not protected, and all actions are available to anyone.

This is not a defect report. It states what the unconfigured state is. The framework is designed for whoever integrates Backstage to configure, and it does nothing until they do.

Two questions follow, and you have to answer both before putting a developer portal in place.

Who will configure the authorization for the portal itself? If the portal is there to narrow what is displayed, that restriction itself is a product of configuration.
When the portal creates something on AWS, where do those permissions originate? If the portal uses its own credentials, the scope of those credentials effectively becomes the upper limit. If the portal goes through AWS Service Catalog, the role the launch constraint hands over sets the limit.

The second question is directly relevant to the focus of this article. The portal can narrow what developers see. The mechanism that holds it to less than the permissions it already carries sits outside the portal.

Regarding Backstage's TechDocs, which aggregates documentation by rendering Markdown files from repositories, see the previously published article Architecture Decision Records: Templates and Operational Patterns for Teams That Actually Maintain Them. This article does not discuss where to store the documentation.

6.3 Making an ITSM Screen the Surface

A developer portal does not have to be a dedicated product. An ITSM screen already in use inside the company can be the entry point instead. AWS has offered the AWS Service Management Connector for this route. The IaP guide also lists it as one of the potential integration targets when used with AppRegistry.

This route has dates attached to it. AWS Service Management Connector closed to new customers on March 31, 2026, and support ends on March 31, 2027. This announcement was made in the March 31, 2026, Service Availability Updates. Potential migration options include solutions offered by AWS partners or direct integration using SDKs.

There is something here that must not be mixed up. The same page states exactly how far the change reaches.

This change does not impact AWS Config, AWS Service Catalog, AWS Security Hub CSPM, Support,
or AWS Systems Manager.

What was folded up is the part that bridges an ITSM product and AWS, not AWS Service Catalog itself. Section 9 returns to this misreading.

7. Building the Surface on Kubernetes

One option is to move the surface developers touch onto the Kubernetes API. Developers write Kubernetes manifests, and controllers provision AWS resources. In this approach, the vocabulary visible to developers becomes the cluster's custom resources.

The previously published article that owns AWS Controllers for Kubernetes and kro as a subject is Amazon EKS Capabilities - Managed Argo CD, ACK, and kro. That article covers which capability handles what, what changes when the controllers move off the cluster, and where staying self-managed is the right call. None of it is repeated here.

Another option is Crossplane. The official documentation describes itself as follows:

Crossplane is a control plane framework for platform engineering.

It puts the APIs your users touch at the center, letting you design them yourself, and its Composition mechanism assembles custom APIs without your writing a controller. As of September 8, 2026, the latest version documented is v2.4.

On this route too, the central distinction of this article does not change. The definition of the custom resources you show developers narrows the choices. What actually creates the AWS resources is the controller inside the cluster, and the IAM role that controller assumes sets the ceiling on permissions. However small the developer's manifest is, the ceiling stays large if the controller's role is large.

8. Deciding How Much to Turn Into a Product

Everything so far collapses into one table. What gets narrowed, how it gets narrowed, what enforces it, and whether the freedom to leave the road survives all differ from row to row.

On the paved road and off it, and the controls that apply either way

What Is Narrowed	How It Is Narrowed	What Enforces It	Freedom to Leave the Road
What appears to exist at all	Registration in the software catalog	The portal's authorization settings (Backstage ships unconfigured)	Remains. Things that were never registered can still be created.
The list you can select from	Assignment to a `portfolio`	IAM permissions on the `portfolio`	Remains. A route that skips the catalog is a separate matter.
The values you can pick at launch	`template constraint`	AWS Service Catalog, evaluated at launch	Remains. It does nothing if the catalog is not used.
The target accounts and Regions	`stack set constraint`	CloudFormation StackSets	Remains, for the same reason.
The permission to create resources	The IAM role a `launch constraint` hands over	IAM	Does not remain. If the developer's own permissions are small, the off-road route cannot create it either.
What the account permits at all	Service control policies	IAM evaluation, with the ceiling set in AWS Organizations	Does not remain. It applies inside and outside the catalog alike.

There is one way to read this table. The first four rows work only on the road. The last two work whether you are on it or off it. If laying the paved road consists only of the first four rows, what you have is a presentation of options, not governance.

The bottom row works on and off the road because service control policies set a ceiling rather than granting anything. The previously published article that covers where the organization's policies sit in the evaluation is AWS Organization Guardrails. How to divide accounts and operate on top of them belongs to the previously published article AWS Multi-Account Operational Patterns. This article focuses on what can be built on top of that foundation.

8.1 What to Make a Product, and What Not To

Not everything needs to be a product. Three questions sort it out.

Will the same thing be repeatedly needed? If it is used once, making it a product leaves you with the version management and nothing else.
Are there parameters you want to restrict? If there are none, a template in a shared repository may be enough. What a product buys you is narrowing the values that can be picked, and handing the permission over.
Do you want to withhold that permission from developers? If the answer is yes, there is a reason to make it a product. If the answer is no, developers can already do the same thing with their own permissions, so the product only adds convenience.

The third question is the branch point. A product that reaches yes on the first two questions alone does not add any governance. It is fine to build it, but it must not be counted as governance gained.

The third situation listed in Section 1, the one where someone has said that self-service will turn into a free-for-all, gets its answer straight from this table. Going self-service opened no new hole. Developers can already create things with their existing permissions, even before a catalog exists. The catalog only added a surface that presents options. So the question to ask is not whether the catalog should be allowed, but what the developers' own permissions allow today. If that is still wide, the free-for-all is available with or without a catalog. Narrow it and then attach a launch constraint, and going self-service makes the permissions smaller, not larger.

8.2 Do Not Lay Only One Road

With only one paved road, work that will not fit on it always turns up. Force that work onto the road anyway, and a separate route gets built unofficially.

What the design needs is not a number of roads but a route for leaving one. Rather than forbidding people to leave, decide what they go through when they do. The last two rows of the table above apply off the road as well, so the route that leaves still meets them. You can leave the freedom to deviate and still hold governance only when the governance sits on the permissions rather than on the road.

9. The Paving Itself Ages

When you lay a paved road, the design guide you consult and the components it names both have a lifetime of their own. The two guides this article rests on are the example.

The IaP guide was published on January 30, 2023, and its document history records no revision since. That guide has a chapter that treats the resources a product created as an application, and it names AWS Service Catalog AppRegistry there along with several services it integrates with. Three of the components it names have had availability changes announced.

Component	Notification Date	Effective Date	Status
AWS Service Catalog AppRegistry	June 30, 2026	July 30, 2026	Moving to maintenance. Closed to new customers.
AWS Systems Manager Application Manager	June 30, 2026	July 30, 2026	Moving to maintenance. Closed to new customers.
AWS Service Management Connector	March 31, 2026	March 31, 2026 (closed to new customers) / March 31, 2027 (end of support)	Sunset

The AppRegistry availability change page states:

AWS Service Catalog AppRegistry is transitioning to maintenance mode, and will no longer be
open to new customers starting July 30, 2026.

Existing users can continue to use the service. AWS will maintain its availability and performance, and support will also continue. No new features will be added, and it will not expand into new Regions. The awsApplication tag that AppRegistry creates is a user tag. It persists indefinitely and can go on being used.

The location of the date varies depending on the component. The AppRegistry availability change page carries July 30, 2026 in its opening notice. In contrast, the Application Manager availability change page opens by saying only that it is no longer open to new customers, and carries the date further down, inside the frequently asked questions on the same page. The June 30, 2026 Service Availability Updates carries it as well, stating in one place that services moving to maintenance in that round close to new customers starting July 30, 2026. Read only the opening of a component's own page, conclude there is no date, and you miss the deadline.

9.1 The Announcement Date and the Effective Date Are Different

There is a reason the table above splits the dates into two columns. AWS service availability changes have two dates: the announcement date and the effective date. AppRegistry was announced on June 30, 2026, and closes to new customers on July 30, 2026. If you only look at one date, you can conclude either that it is still available or that it is already gone.

The two do not always fall in that order. Proton closed to new customers on October 7, 2025, but the Service Availability Updates round that carried the change was published on October 13, 2025. There are instances where the publication date is after the effective date. A publication date is no guarantee that the change is still ahead of you.

When recording this information in internal records, be sure to include both dates. The announcement date marks when you received the information. The effective date sets your deadline.

9.2 The Service Itself Is Still Moving

All three of the items above are components or features around AWS Service Catalog, not AWS Service Catalog itself.

There is a shape here that is easy to misread. Service Availability Updates have occurred three times as of September 8, 2026, with publication dates of October 13, 2025, March 31, 2026, and June 30, 2026. No round exists from July 2026 onward. Across those three updates, the string AWS Service Catalog appears in exactly one of them, the June 30, 2026 update, and it appears there as part of the feature name AWS Service Catalog - Application Registry. Scanning the list, it looks as though the service itself is listed. What is listed is the feature.

And the service itself expanded into two new Regions in May 2026. That is the fact check that keeps a folded-up component from being read as a folded-up service.

9.3 Run the Same Check Against Your Own Paved Road

All this section did was look up the availability status of each component the design guide names, one at a time. Now run the same process against the components of the paved road you laid yourself.

The publication date of the design guide you referenced, and any subsequent revisions.
The current availability of the AWS services and features mentioned in that design guide.
The availability of the AWS services your product utilizes.
The versions of components outside of AWS, such as portals and IaC tools, and their maintenance status.

A paved road degrades after you lay it. Developers only check whether the road is passable. They do not look at the state of the parts underneath it. Unless whoever laid the road goes and looks at them regularly, nobody does.

10. Failure Modes

10.1 Assuming That Listing It in the Catalog Enforces Governance

This is the most common mistake. A product with no launch constraint attached launches under the developer's own permissions. If that developer has permissions for the AWS services the product uses, they simultaneously open an alternative path that bypasses the catalog.

The inspection method is straightforward. For each portfolio, call ListConstraintsForPortfolio. The returned ConstraintDetail contains a Type and the ProductId to which it applies. Collect all entries where the Type is Launch, and compare this list with the list of products within that portfolio. The difference will reveal instances where a launch constraint is missing from a product. Because you attach a launch constraint per product, a gap appears whenever someone believed they had attached it to the whole portfolio.

10.2 Laying Only One Paved Road

With only one paved road, work that does not fit it creates unofficial routes. Unofficial routes are not in any register, so they are invisible the next time something changes. Designing the route people take when they leave costs less than arguing about how many roads to lay.

10.3 Blocking the Exit and Creating an Invisible One

This is the inverse of the previous item. Prohibit deviation across the board, and routes that evade the prohibition appear instead. The key is not to block the pathways themselves, but to restrict the permissions. By controlling permissions, any attempt to deviate will encounter the same barrier. Blocking pathways, on the other hand, only motivates users to find routes that bypass the restrictions.

10.4 Letting the Portal Become a List of Links

The software catalog only knows about registered items. If registration is optional, and work can still be done without it, the number of unregistered items will likely increase. Whether a portal becomes a valuable resource depends on whether registration is the only way to gain access or benefit from it. A catalog that only serves as a place to view information will eventually become outdated.

10.5 Believing a Version Is Stopped When It Is Not

Setting Guidance to DEPRECATED does not stop updates to already-provisioned resources. Only new launches are stopped. To completely stop it, you must set Active to false. You can only determine its current status by checking the list of versions for the product.

10.6 Treating the Share Setting as a Visibility Setting

Sharing a portfolio by principal name carries a privilege escalation path that the API reference documents explicitly. Users who can create principals on the receiving end can then create their own roles with matching names. The share setting is a setting for what is visible and, at the same time, a setting for who can launch.

10.7 Adopting Components From a Design Guide Without Checking Them

This is Section 9 restated. It is essential to verify both the publication date of the design guide and the current availability of the components listed within it. The fact that a guide has not been updated does not guarantee that the components it references are still available.

11. Design Checklist

Does every product in the portfolio carry a launch constraint? If not, has it been determined that it is acceptable for developers to launch these products independently?
Is the IAM policy for the launch role restricted to only the resources created by that product?
Is it ensured that developers' IAM permissions do not allow them to create the same resources directly, bypassing the catalog?
For parameters that should not be selectable, have you decided whether a template constraint or the IaC side does the narrowing?
If using EXTERNAL or Terraform Cloud types, has it been decided who takes over for the constraints that drop away?
If the portfolio share uses principal name sharing, have you checked who can create principals in the receiving account?
When deprecating a version, has it been determined whether DEPRECATED or Active is the appropriate status?
Has the portal's authorization been configured? If not, is that the intended state?
If the portal creates resources on AWS, has the source of those permissions been identified?
Have you designed the route that leaves the paved road? Can you name the governance that still applies on it?
Has the publication date of the design guide been verified, along with the availability status of the components referenced within it?
Has the verification date been recorded, and has a schedule been determined for the next verification?

12. Frequently Asked Questions

Does listing products in the catalog stop developers from creating whatever they like?

No. What prevents it is the developer's own IAM permissions. If a product has no launch constraint applied, developers can launch resources using their own permissions, bypassing the catalog. The catalog provides a list of options, standardized templates, and auditable records.

Between launch constraint and template constraint, which one is the governance?

The launch constraint. It specifies the IAM role used to create resources, allowing developers to launch from the catalog while minimizing their own permissions. A template constraint limits the values of parameters that can be selected at launch time, but it does not reach launches that bypass the catalog.

Can launch constraint be applied to an entire portfolio?

No. The administrator guide states that a launch constraint applies to a product in the portfolio, and that it does not apply at the portfolio level or to a product across all portfolios. Even when every product in a portfolio should use the same role, you attach it one at a time.

Can Terraform configurations be distributed as products?

Yes. You can use either the External type or the Terraform Cloud type. However, the official documentation explicitly states that template constraint and notification constraint are not supported for these two types. Regarding tag update constraint and stack set constraint, the documentation only lists Terraform Open Source as unsupported, and says nothing about Terraform Cloud.

Has AWS withdrawn from the developer platform space?

No. While AWS Proton will end support on October 7, 2026, AWS Service Catalog itself is not listed as a subject of any of the three Service Availability Updates, and it expanded into two new Regions in May 2026. AWS Prescriptive Guidance also publishes an internal developer platform guide, dated April 22, 2024.

AWS Service Catalog AppRegistry was folded up. Does that mean AWS Service Catalog will be folded up too?

No. What moved to maintenance is the AppRegistry feature. The end-of-support page for AWS Service Management Connector also explicitly states that these changes do not affect AWS Config, AWS Service Catalog, AWS Security Hub CSPM, Support, or AWS Systems Manager.

Does putting a developer portal in place narrow what is visible?

Only if you configure the portal's authorization. The official Backstage documentation states that by default, endpoints are not protected, and all operations are accessible to everyone. Furthermore, limiting what is visible and limiting what can be created within AWS are separate issues. The IAM role that the portal, or whatever sits behind it, assumes decides the latter.

If a version is set to DEPRECATED, does it stop being used?

Only partly. New launches stop, but updates to what was already provisioned from that version do not. To completely disable it, you need to set the Active status of the corresponding provisioning artifact to false.

Should deviating from the paved road be prohibited?

This article does not recommend preventing deviations. Block the routes that leave, and unofficial routes appear where governance does not reach. Put the governance on the permissions instead, and the route that leaves hits the same wall. You can keep governance while leaving the freedom to deviate only when the governance sits on the permissions rather than on the road.

13. Summary

Narrowing the choices and narrowing the permissions are not the same operation. Listing product entries in a catalog does only the former. The IAM role a launch constraint hands over does the latter, and the administrator guide states plainly that without this constraint, users will launch using their own IAM credentials.

There are five kinds of constraint, and only Launch touches developer permissions. The other four decide which values can be picked, where notifications go, where things deploy, and how tags are handled. When selecting Terraform-related types, at least two of these four are explicitly marked as unsupported, leaving only Launch as a guaranteed option. Pick a type without deciding who takes over for the mechanisms that fell away, and what you thought you had narrowed turns out to be narrowed by nobody.

The developer portal consolidates information about what exists and who owns it. But narrowing what the portal shows and narrowing what can be created on AWS are two different things. Backstage's official documentation states that, by default, endpoints are not protected. If the portal creates anything on AWS, you have to identify where those permissions come from.

AWS's own design guides split at exactly this seam. The internal developer platform guide describes what developers see, without mentioning AWS Service Catalog, while the IaP guide dedicates all 14 chapters to AWS Service Catalog but never mentions the developer portal. Furthermore, the term launch constraint does not appear in either guide. The mechanism that actually enforces the narrowing sits in the administrator guide and the API reference.

And the parts a paved road is made of have a lifetime. Three of the components the IaP guide names have had availability changes announced. An AWS availability change carries both an announcement date and an effective date, so record both. At the same time, a folded-up component must not be read as the service itself. AWS Service Catalog itself is not listed as a subject of any of the three Service Availability Updates, and it expanded into two new Regions in May 2026.

Finally, if the decision has to come down to one question, it is this: Are you building that product because you do not want to hand developers those permissions? If not, that product offers convenience, not governance. It is fine to build it, but it must not be counted as governance gained.

The same reading error sits below this one, twice. On a single accelerator, a split can be declared without isolating memory or compute, and the request line reads the same either way: Sharing One GPU on Amazon EKS. In a model API, three settings are all called a limit, and only one of them is a ceiling the runtime enforces: Controlling How Much a Model Thinks.

14. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi