Lesson 358 · AWS Learning Path

AWS 358: Service Catalog, CodeArtifact, Amazon Q Developer, and delivery-platform choices

Anil Jalela · Published Jun 18, 2026 · 7 min read

Why this lesson matters

An internal developer platform is not one AWS service. It is a product that provides safe self-service paths for source, packages, infrastructure, pipelines, environments, documentation, observability, and support. Service Catalog, CodeArtifact, CloudFormation Git sync, CodePipeline, CodeBuild, and Amazon Q Developer solve different parts.

AWS Proton must now be treated as a migration topic: AWS states support ends October 7, 2026, after which its console and resources are unavailable, while deployed infrastructure remains. Do not design a new long-lived dependency on it.

Start with platform users and jobs

Identify personas: application developer, platform engineer, security, operations, finance, auditor, and service owner. Interview them for jobs such as:

• create a compliant service/environment;
• consume an approved package;
• request/deploy infrastructure with guardrails;
• build, test, approve, and promote an artifact;
• discover ownership, documentation, health, cost, and support;
• update templates/pipelines safely across many teams;
• revoke a vulnerable dependency or unsafe template;
• migrate or retire a platform capability.

Measure onboarding lead time, successful self-service rate, deployment lead time, change failure, policy exceptions, support toil, template adoption/age, vulnerable dependency removal time, unit cost, and developer satisfaction. Avoid measuring portal clicks as business success.

Capability map

The correct answer may combine services or use a supported third-party platform. Compare capability, operating ownership, lock-in, integration, security, resilience, cost, and migration.

Service Catalog deep boundary

Service Catalog structures portfolios, products, versions/provisioning artifacts, constraints, access, sharing, and provisioned products. A product commonly wraps CloudFormation or supported provisioning mechanisms. Platform teams can expose approved infrastructure without granting users unrestricted provisioning permissions.

Design:

• product owner, consumer, support, and retirement owner;
• portfolio/account/Region distribution and sharing;
• launch role versus user authorization;
• template constraint, tag update constraint, notification constraint, and launch constraint where applicable;
• version lifecycle, default/recommended version, deprecation, and forced security update process;
• parameter validation, naming, tags, budgets, quotas, and outputs;
• drift/updates, failed provision recovery, termination protection, and cleanup;
• CloudTrail/Config/stack evidence and cost allocation.

Service Catalog approval does not prove the product is secure forever. Scan/test templates and dependencies, patch product versions, identify deployed old versions, and provide migration paths. Restrict who can change launch roles and portfolios.

CodeArtifact deep boundary

CodeArtifact uses domains, repositories, assets/package versions, upstream repositories, and external connections. A domain provides aggregation and deduplication scope plus encryption configuration. Repositories can consume upstreams, creating dependency-resolution order that must be governed.

Design:

• package formats and namespace/name ownership;
• publisher versus consumer roles;
• domain/repository account and Region placement;
• upstream order and external-package allow policy;
• version immutability/republication rules;
• package-origin controls, malware/vulnerability/license review, quarantine, and revocation;
• short-lived authorization tokens and build-role use;
• KMS, CloudTrail, network path, retention, deletion, and cross-account access;
• storage/request/upstream-transfer cost and package-cache behavior.

Never allow dependency confusion by assuming an internal name always resolves internally. Reserve namespaces, control external origins, lock dependencies, verify hashes/signatures/provenance, and test upstream outage. Deleting a bad version does not remove it from developer/build caches or already-built artifacts.

CodeArtifact is for supported package ecosystems; use S3/ECR and release systems for other artifact types as appropriate.

CloudFormation Git sync

Git sync links a stack to a repository and deployment file so changes can drive stack updates. Design repository connection identity, branch ownership, deployment-file parameters, template paths, pull-request protection, CloudFormation role, change safety, stack drift, failure notification, rollback, and emergency pause.

Git sync is useful for CloudFormation-centered GitOps. It does not replace application build/test, package management, multi-stage approval, runtime verification, or broad developer-portal functionality. A bad reviewed template can still make a bad stack update; require linting, policy, change preview, and recovery.

Amazon Q Developer boundary

Amazon Q Developer can assist with understanding, generation, transformation, review, troubleshooting, and AWS development workflows depending on edition/integration. Treat generated output as untrusted proposed change until a human and automated controls validate it.

Govern:

• approved edition, identity, IDE/CLI/console integration, Region/data policy, and telemetry;
• repository/data classification and excluded content;
• least-privilege tool/agent permissions and human approval before mutation;
• prompt/output handling, attribution/licensing process, secret scanning, and audit;
• tests, static/security review, architecture ownership, and rollback;
• incident response for unsafe suggestion, data exposure, or excessive action.

Never give an AI assistant broad production credentials because it can generate correct-looking code. The human/team remains accountable for requirements, evidence, risk acceptance, and deployment.

AWS Proton end-of-support migration

AWS states Proton support ends October 7, 2026. Existing customers must inventory templates, environments, services, pipelines, connections, roles, and provisioned infrastructure. The underlying deployed CloudFormation stacks/resources remain, but Proton's control plane and delivery management will not.

Migration workflow:

1. Freeze new Proton adoption and name migration owner.
2. Export inventory, template bundles, versions, service/environment relationships, pipeline definitions, IAM, and evidence.
3. Map every capability to CloudFormation Git sync, Service Catalog, CodePipeline/CodeBuild, an external portal, or another approved target.
4. Identify what Proton currently updates, observes, and authorizes.
5. Recreate source ownership and deployment workflows outside Proton.
6. Pilot one low-risk service; compare stack/template state and operations.
7. Migrate in waves without replacing stable infrastructure unnecessarily.
8. Remove Proton dependencies/roles only after target workflow and rollback proof.
9. Complete before support ends and retain audit evidence.

Do not delete deployed stacks merely to remove Proton. Establish who owns future stack updates and drift first.

Platform architecture choices

Compare four viable patterns:

AWS-native governed products

Service Catalog + CloudFormation, CodeArtifact/ECR/S3, CodePipeline/CodeBuild/CodeDeploy, IAM Identity Center/roles, CloudWatch/CloudTrail. Strong AWS integration; platform team owns product lifecycle and cross-service experience.

GitOps-centered infrastructure

Protected repository + CloudFormation Git sync or another approved controller + package/artifact stores + separate application pipeline. Strong source-driven state; requires careful reconciliation, identity, and drift semantics.

Portal/API platform

Backstage or another portal provides catalog/templates/workflows over AWS APIs. Strong discoverability and extensibility; organization owns plugins, upgrades, availability, secrets, data, and support.

External CI/CD platform with AWS federation

External source/runners use OIDC or workload federation to bounded AWS roles and AWS artifact/deployment services. Avoids static keys; trust claims, runner security, egress, audit integration, and outage dependencies require ownership.

Decision matrix

Score only after hard rejection tests:

Run sensitivity analysis: change weights for a regulated team, small startup, 500-team enterprise, and disconnected environment. One platform pattern need not serve every persona.

Failure scenarios

Complete ten tabletop tests: vulnerable package already cached; upstream dependency hijack; artifact token exposed; launch role broadened; product version revoked with 100 deployments; Git sync applies wrong parameters; portal unavailable; OIDC trust accepts an unintended branch; Q-generated policy grants wildcard access; Proton migration misses pipeline ownership.

For each state detection, containment, owner, developer impact, recovery, evidence, and prevention. Include break-glass paths that remain auditable.

Workshop and acceptance

Design a platform for 100 teams across 20 accounts. Produce persona research, capability map, three viable architectures, knockout/weighted matrix, Service Catalog product lifecycle, CodeArtifact namespace/upstream policy, pipeline/artifact provenance, Q governance, Proton migration if applicable, operating model/RACI, SLOs, support model, cost/unit economics, adoption plan, ten failures, and exit strategy.

Pass requires service boundaries, no new Proton dependency, temporary credentials, package-origin controls, immutable promotion, explicit human approval for AI-driven mutation, lifecycle ownership, and a tested degraded/manual operating path.

Official sources

• AWS Service Catalog administrator guide
• CodeArtifact concepts
• CloudFormation Git sync
• Amazon Q Developer administration
• AWS Proton end-of-support and migration