AWS Service Catalog EU Alternative 2026: Self-Service Portfolio Management, GDPR Sub-Processor Chains, and CLOUD Act Access to Your Approved Technology Inventory

Post #795 in the sota.io EU Compliance Series

AWS Service Catalog lets organizations create and manage portfolios of approved AWS resources — CloudFormation templates, Terraform configurations, and AWS products that end users can deploy through a self-service portal without needing direct AWS console access. It is the internal marketplace layer that separates "infrastructure you are permitted to provision" from "everything AWS offers," and it is the mechanism through which IT governance teams enforce standards: approved AMIs, pre-configured RDS instances, sanctioned network configurations, standardized EKS clusters.

It is not in the AWS European Sovereign Cloud service catalog.

That absence has a specific implication for organizations that use Service Catalog to enforce GDPR-compliant infrastructure standards. The service through which you manage, distribute, and audit infrastructure compliance — the catalog that defines which AWS services your organization has approved for handling personal data — is itself running outside the enhanced data residency and operator access restrictions that ESC provides. You are using a non-ESC service to govern your ESC-compliant workloads.

This guide examines the five GDPR issues that AWS Service Catalog raises, explains why the ESC catalog gap matters for organizations using Service Catalog as their compliance enforcement layer, and identifies the EU-sovereign alternatives for self-service developer portals and infrastructure catalogs.

What AWS Service Catalog Does

AWS Service Catalog provides a framework for creating and managing portfolios of pre-approved cloud resources that end users can deploy through a self-service interface.

Core components:

• Products: CloudFormation templates, Terraform configurations, or Service Actions that define a deployable resource or group of resources. Products include version histories, usage instructions, and launch constraints.
• Portfolios: Collections of products organized for distribution to specific teams, departments, or accounts. Portfolios can be shared across AWS Organizations member accounts.
• Provisioned Products: Deployed instances of catalog products. Each provisioned product is tracked in Service Catalog with its configuration, owner, deployment time, and stack outputs.
• Constraints: Rules applied to products that limit launch configuration — IAM roles, network settings, parameter values — ensuring that self-service deployments conform to governance requirements.
• Service Actions: AWS Systems Manager documents that can be invoked against provisioned products to perform operational tasks (updates, reconfigurations, terminations) through the Service Catalog interface.
• AppRegistry: A metadata registry that associates applications with their underlying AWS resources, providing an organizational view of what services each application uses.

Scale context: A mid-sized organization using Service Catalog across 20 AWS accounts generates a catalog of provisioned products covering every self-service infrastructure deployment — who provisioned what, when, in which account, with what parameters. For organizations using Service Catalog to enforce data residency requirements, this catalog is a complete audit record of every infrastructure decision.

ESC status: AWS Service Catalog is absent from the AWS European Sovereign Cloud service catalog. The governance and audit layer that manages your approved infrastructure catalog operates without ESC-level data residency and operator access restrictions.

GDPR Issue 1 — Art. 28: The Product Broker Sub-Processor Chain

GDPR Art. 28 requires that controllers engage only processors providing "sufficient guarantees" regarding technical and organizational measures, and that each processor relationship is governed by a contract specifying the processing purposes, data categories, and processor obligations. AWS Service Catalog creates a sub-processor chain that most DPAs do not document explicitly.

The product broker architecture: AWS Service Catalog does not deploy infrastructure directly. It orchestrates a chain of downstream services: when a user provisions a product from the catalog, Service Catalog calls AWS CloudFormation to execute the template, CloudFormation creates the specified resources (EC2 instances, RDS databases, S3 buckets, EKS clusters), and those resources begin processing your organization's data. Service Catalog is the broker layer — the control plane that sits above the actual processing infrastructure.

Why this matters for Art. 28: Most organizations document their AWS processing activities at the resource level — EC2 instances handling customer data, RDS storing transaction records, S3 containing backups. They document AWS as a data processor for these activities. But Service Catalog's role as the orchestration layer that triggered those deployments — and that continues to track them — is a separate processing activity that involves personal data: the identity of the employee who provisioned the product, the parameters they specified (which may include network addresses, naming conventions derived from customer segments, or configuration values reflecting data categories), and the metadata AWS stores about the provisioned product's lifecycle.

The sub-processor chain documentation gap: A complete Art. 28 documentation for an AWS environment that uses Service Catalog needs to account for:

1. Service Catalog as the control plane for authorized provisioning (stores employee identifiers, provisioning history, product access logs)
2. CloudFormation as the execution layer invoked by Service Catalog (stores template execution history, stack events including parameter values)
3. The provisioned resource layer (EC2, RDS, S3) as the processing infrastructure

Most DPA documentation programs cover level 3 and sometimes level 2. Level 1 — Service Catalog's own processing of provisioning metadata — is systematically absent from Art. 28 processor agreements because it is perceived as "access management" rather than "data processing." The Art. 28 contract with AWS that covers Service Catalog's handling of provisioning metadata — specifically who provisioned what, when, and with what configuration — is rarely explicit in DPA agreements.

Practical exposure: If your Art. 28 DPA with AWS does not explicitly cover Service Catalog's collection and retention of provisioning metadata (user identifiers associated with product launches, configuration parameters, and access grant records), you have a documentation gap. For organizations that use Service Catalog to manage infrastructure that handles personal data, this gap means the control plane for your processing infrastructure is operating under an incompletely documented processor relationship.

GDPR Issue 2 — CLOUD Act: Your Approved Technology Inventory Is a Business Intelligence Target

The CLOUD Act allows US authorities to compel US-headquartered cloud providers to disclose data stored anywhere in the world, including data in EU-based AWS regions. For AWS Service Catalog, the CLOUD Act exposure is not primarily about the data in your provisioned resources — it is about the catalog itself.

What the Service Catalog contains: Your AWS Service Catalog portfolio is a structured inventory of every technology standard your organization has approved for use. Each product entry represents a deliberate governance decision: this is the approved configuration for an RDS database in a healthcare context; this is the sanctioned network topology for customer-data workloads; this is the approved AMI for processing financial transactions. The catalog reflects your organization's infrastructure strategy, security standards, and risk appetite in executable form.

The business intelligence exposure: A US government compelled disclosure of your AWS Service Catalog contents — your product portfolios, their configuration parameters, your provisioned product inventory across all accounts, and your AppRegistry application-to-resource mapping — provides a detailed map of:

• Every technology standard your organization has approved (infrastructure blueprints)
• Which teams or business units are authorized to deploy which categories of infrastructure (portfolio-to-group assignments)
• The complete deployment history of every infrastructure provisioning event (provisioned products log)
• Which applications are running on which resources (AppRegistry)

This is not a disclosure of your customer data. It is a disclosure of your organization's entire infrastructure governance model. For companies where the structure of IT deployments is itself competitively or regulatorily sensitive — financial institutions whose risk controls are embedded in their infrastructure templates; healthcare providers whose data isolation architectures are encoded in their catalog constraints; government contractors whose security configurations are reflected in their approved products — this exposure is significant.

The ESC catalog gap: Because Service Catalog is not in the ESC catalog, the enhanced access restrictions that would require AWS employees to have German residency and Bundesamt für Sicherheit in der Informationstechnik clearance for operator access — the restrictions that are the ESC's primary CLOUD Act mitigation — do not apply to Service Catalog. AWS's standard operator access policies and US legal compulsion mechanisms apply to your infrastructure governance layer.

GDPR Issue 3 — Art. 30: Self-Service Portal Logs as Employee Behavior Records

GDPR Art. 30 requires controllers to maintain a Record of Processing Activities documenting each processing activity with its purposes, data subject categories, data categories, retention periods, and transfer mechanisms. AWS Service Catalog's provisioning logs create an employee behavior record that belongs in your RoPA but is typically absent from it.

What the provisioning logs contain: Every product launch in AWS Service Catalog generates a record that includes: the IAM identity of the user who initiated the launch (linked to a named employee), the product and version selected, the parameter values supplied (which may include account names, environment identifiers, project codes that identify the business purpose), the launch time, and the outcome. Service Catalog retains this record as the provisioned product's history, including subsequent updates and the termination event.

Why this is personal data: The IAM identity associated with each provisioning event is typically a named employee account — firstname.lastname@company.com or a similar identifier. Service Catalog's audit trail is therefore a record of named employees' provisioning activity: who deployed what infrastructure, when, for what declared purpose, and in which AWS account. This is processing of personal data about your employees.

The RoPA documentation gap: Most organizations document employee data in their RoPA under HR systems, access management platforms, and directory services. AWS Service Catalog's provisioning logs are not typically included in the employee data inventory because they are perceived as infrastructure records, not personnel records. But a log that associates named employee identifiers with deployment actions — especially over years of deployment history — is a behavioral record of your technical workforce. The purposes for which you retain this data (audit, compliance, governance), the retention period, and the legal basis should appear in your RoPA. For EU employees, the processing of behavioral logs may additionally require Works Council notification or consultation in jurisdictions with applicable co-determination laws.

GDPR Issue 4 — Art. 5(1)(b): Purpose Limitation in Portfolio Usage Analytics

GDPR Art. 5(1)(b) requires that personal data is collected for specified, explicit, and legitimate purposes and not further processed in a manner incompatible with those purposes. AWS Service Catalog raises a purpose limitation issue through its portfolio usage analytics.

The data collection purpose: Personal data in Service Catalog provisioning logs — employee identifiers, deployment parameters, timing data — is collected for the specific purpose of maintaining an audit trail of infrastructure deployments. The purpose is governance: ensuring that only approved products are deployed, that deployments can be attributed to specific users, and that the provisioned product lifecycle is traceable.

The secondary processing risk: AWS Service Catalog usage data can be analyzed to reveal patterns in employee behavior that go beyond the governance purpose. Which teams provision the most infrastructure? Which employees have unusually high provisioning rates? Which product versions are being avoided (suggesting that employees are finding workarounds to required standards)? Which business units deploy infrastructure at end-of-quarter at unusual rates (suggesting deadline-driven provisioning patterns that may indicate business planning information)?

These analytics — derived from the same provisioning records collected for governance purposes — serve a different purpose: workforce monitoring, productivity analysis, or business intelligence. Processing employee-linked provisioning data for these secondary purposes is not compatible with the original governance purpose under Art. 5(1)(b), unless employees have been informed and a separate legal basis exists.

The AWS analytics exposure: AWS provides usage reporting for Service Catalog through AWS Cost Explorer, CloudWatch, and CloudTrail. These integrations make it technically straightforward to build dashboards that aggregate employee-linked provisioning activity into behavioral analytics. The technical ease of the analysis does not resolve the purpose limitation issue — using governance data for workforce analytics requires separate disclosure and legal basis.

GDPR Issue 5 — Art. 17: Service Deletion in Catalog ≠ Resource Deletion in Accounts

GDPR Art. 17 provides data subjects with the right to erasure of personal data where it is no longer necessary for the purposes for which it was collected, or where consent is withdrawn. AWS Service Catalog creates an erasure failure mode that is architecturally distinct from data deletion in other services.

The two-layer architecture: AWS Service Catalog operates at two levels: the catalog layer (product definitions, portfolio assignments, provisioned product records) and the resource layer (the actual AWS resources — EC2 instances, RDS databases, S3 buckets — deployed by provisioning a product). These are maintained separately.

The deletion gap: When a product is deleted from an AWS Service Catalog portfolio, the product definition is removed from the catalog. But provisioned product records — the deployment history showing which users provisioned which products in which accounts — are retained in the Service Catalog audit trail. More critically, the actual AWS resources that were deployed via that product continue to exist in the member accounts. Deleting a catalog product does not terminate the provisioned resources that were launched from it.

This creates two distinct erasure gaps:

Gap A — Catalog audit trail retention: Even after a product is removed from the portfolio and all users lose the ability to provision it, the historical record of who deployed that product, when, and with what parameters remains in the Service Catalog provisioning history. If the purpose for collecting that data (governance of active infrastructure) has ended because the product no longer exists, retaining the historical provisioning log requires a separate justification — typically the legitimate interest of the data controller in maintaining audit records. The retention period for this audit data should be defined and enforced, not left at AWS's default.

Gap B — Orphaned resource personal data: When resources provisioned through Service Catalog are not terminated when products are deleted from the catalog, those resources may continue storing personal data indefinitely. An S3 bucket provisioned via a catalog product that has since been removed from the portfolio may contain customer personal data with no active governance connection to the catalog that originally authorized its deployment. The product deletion in Service Catalog creates the impression that the governance decision has been cleaned up — but the resource and its data remain.

Art. 17 compliance requirement: Organizations using Service Catalog should establish a lifecycle management process that ensures: (a) provisioned product termination is explicitly tracked and actioned when the governance purpose ends, not inferred from product catalog deletion; (b) the retention period for provisioned product audit records is defined and enforced; and (c) the connection between catalog governance decisions and actual resource lifecycle is maintained in the RoPA.

EU-Sovereign Alternatives for Self-Service Infrastructure Portals

The following platforms deliver Service Catalog-equivalent functionality — internal developer portals, infrastructure catalogs, self-service provisioning — without the US-jurisdiction dependencies of AWS Service Catalog.

Backstage.io

Origin: Developed by Spotify; contributed to the CNCF in 2020; licensed Apache 2.0.

What it is: Backstage is an open-source developer portal platform that provides a software catalog, service templates, documentation hub, and plugin ecosystem for internal developer tooling. It is the most widely adopted open-source internal developer portal, with production deployments at thousands of organizations.

Service Catalog equivalents: Backstage's Software Templates replace Service Catalog products — they define parameterized scaffolding actions that create repositories, deploy infrastructure via Terraform or Pulumi, and register the resulting service in the Backstage catalog. The Software Catalog replaces AppRegistry — it tracks every application, service, library, and resource in your organization with ownership metadata. Access controls are managed through Backstage's permission framework.

EU data residency: Self-hosted on EU infrastructure (Hetzner, Scaleway, OVH, ionos, Deutsche Telekom Open Telekom Cloud), Backstage stores all catalog data — software metadata, template execution history, ownership records — within your infrastructure boundary. No US-headquartered intermediary has access to your infrastructure catalog.

GDPR compliance advantages: Employee identifiers in template execution records remain within your data boundary. The provisioning audit trail is under your control and retention policy. No CLOUD Act exposure for your infrastructure catalog contents.

Limitations: Backstage is a self-hosted platform requiring engineering investment for setup, plugin development, and ongoing maintenance. The UI quality depends on your implementation. AWS-specific integrations (e.g., direct CloudFormation execution) require custom plugins.

Port.io

Origin: Israeli startup, founded 2021; EU region available.

What it is: Port is a commercial internal developer portal platform with a data-model-first approach. It provides a customizable catalog, self-service actions, and scorecards for infrastructure governance — positioned as an enterprise-grade Backstage alternative with lower operational overhead.

Service Catalog equivalents: Port's self-service actions replace Service Catalog products. Its Blueprints system creates a flexible data model for any infrastructure entity — accounts, services, databases, environments — with custom properties and relationships. Port's scorecards provide the equivalent of Service Catalog constraints as ongoing compliance checks rather than launch-time restrictions.

EU data residency: Port offers EU-region hosting (Frankfurt). For organizations with strict data residency requirements, this provides a contractual basis for EU-only storage of catalog metadata. Unlike Backstage, Port is a SaaS platform — you do not manage the infrastructure, but the data remains in the EU.

GDPR compliance advantages: EU hosting provides a stronger data residency position than AWS Service Catalog. Port's DPA covers EU-resident data processing. No CLOUD Act exposure to US authorities for your infrastructure catalog (Port is incorporated outside the US, though legal jurisdiction analysis applies).

Limitations: Commercial SaaS with subscription pricing. Self-service action execution still depends on the underlying infrastructure provider (you still call AWS APIs to deploy AWS resources). The SaaS model means Port has access to your catalog metadata as a processor.

Kratix

Origin: Syntasso Ltd, UK-based company; licensed Apache 2.0.

What it is: Kratix is a Kubernetes-native platform for delivering infrastructure as a service within an organization. It uses the Kubernetes API extension model — Custom Resource Definitions and operators — to create an internal cloud platform where teams request infrastructure (a database, a message queue, a monitoring stack) by applying Kubernetes manifests, and platform engineers define the fulfillment logic.

Service Catalog equivalents: Kratix Promises replace Service Catalog products — they define an infrastructure service contract (what teams can request) and the fulfillment pipeline (how the request is executed, potentially across multiple cloud providers or Kubernetes clusters). Kratix's GitOps-based orchestration provides an audit trail equivalent to Service Catalog's provisioned product history, stored in your Git repositories.

EU data residency: Self-hosted on EU infrastructure. Kratix's control plane runs in your Kubernetes cluster; fulfillment pipelines execute in your infrastructure boundary. No US-headquartered intermediary stores your service delivery metadata.

GDPR compliance advantages: Complete infrastructure boundary control. Provisioning audit trail in Git (version-controlled, cryptographically signed, retention-policy-enforced). Works well in combination with Flux or ArgoCD for GitOps-based compliance audit trails that are fully within your data boundary.

Limitations: Kratix requires Kubernetes for the control plane, which adds operational complexity. It is best suited for organizations already running Kubernetes-based platform engineering practices. Smaller teams may find Backstage or Port more accessible.

Migration Considerations

Organizations moving from AWS Service Catalog to an EU-sovereign alternative should address several specific areas:

Provisioning history data: Before decommissioning AWS Service Catalog, export the complete provisioned product history via AWS CLI (aws servicecatalog list-record-history) and store it in your data boundary. This history constitutes a personnel record under GDPR and should be retained under your defined retention policy, not left in AWS's Service Catalog.

Active provisioned products: Service Catalog removal does not affect running AWS resources. Each provisioned product should be reviewed and either terminated (if no longer needed), migrated to direct CloudFormation management, or transitioned to catalog management in the replacement platform. The resource lifecycle must be explicitly addressed — do not assume catalog migration completes the data governance remediation.

Constraint enforcement migration: Service Catalog's launch constraints (IAM role restrictions, parameter validation, network configuration limits) are typically enforced at provisioning time. In Backstage or Kratix, equivalent enforcement requires template validation logic, OPA/Kyverno policies in Kubernetes, or Service Control Policies at the AWS Organizations level. Plan the constraint coverage migration explicitly.

AppRegistry application inventory: If you use Service Catalog AppRegistry for application-to-resource mapping, export this inventory before migration. The application metadata in AppRegistry may be the only structured record of which AWS resources belong to which applications — particularly important for Art. 30 RoPA accuracy.

ESC Gap Summary and Compliance Assessment

ESC catalog status: AWS Service Catalog is not listed in the AWS European Sovereign Cloud service catalog. The governance layer managing your approved infrastructure catalog operates without ESC-level data residency and operator access controls.

Primary GDPR exposure areas:

1. Art. 28 documentation gap: Service Catalog's role as provisioning orchestrator and audit data processor is typically absent from DPA documentation programs
2. CLOUD Act: Your organization's complete infrastructure governance inventory — approved products, deployment history, application-to-resource mapping — is accessible under US legal compulsion
3. Art. 30 gap: Employee-linked provisioning logs are not documented in most organizations' RoPA as personnel behavior records
4. Art. 5(1)(b): Provisioning data collected for governance purposes may be secondarily analyzed for workforce monitoring without the required compatibility analysis
5. Art. 17: Product deletion in the catalog does not terminate resources or provisioning records — erasure requires explicit lifecycle management

For organizations using Service Catalog to enforce GDPR compliance: Using a non-ESC service as your infrastructure governance layer creates a structural compliance risk: the service that manages which AWS services are approved for personal data processing is itself outside the enhanced compliance guarantees you are trying to enforce. This is the same structural issue identified in the AWS Control Tower analysis — governance layer outside the compliance boundary.

For GDPR-compliant infrastructure catalog management: Self-hosting Backstage on EU infrastructure provides the highest data residency assurance. Port.io provides a commercial managed alternative with EU-region hosting and lower operational overhead. Kratix provides the strongest GitOps-native audit trail for Kubernetes-centric organizations.

The catalog that defines which infrastructure your organization trusts for personal data processing should operate under at least the same data sovereignty standards as the infrastructure itself.

This analysis is based on AWS Service Catalog documentation, the AWS European Sovereign Cloud service catalog, GDPR Articles 5, 17, 28, and 30, and publicly available information about Backstage.io, Port.io, and Kratix. It does not constitute legal advice. Organizations should conduct their own GDPR compliance assessment with qualified legal counsel.