Practice: Deploying into customer clouds: AWS, Google Cloud and Azure

Generated by Claude through GigAI 0.1.11.10 on 2026-10-11.

Main tool: AWS · AWS makes the customer boundary explicit as separate accounts joined by IAM roles and short-lived STS credentials, so practising cross-account access and customer-run templates here gives a pattern you can map onto the other two clouds. · Alternatives: Google Cloud (project-scoped IAM with service account impersonation, GKE and Vertex AI), Microsoft Azure (Entra ID tenants with subscription-level role assignments, AKS and Azure OpenAI), Terraform (one infrastructure-as-code language across all three clouds instead of a per-cloud template service), AWS CDK (general-purpose code that synthesizes CloudFormation templates), and on-premises Kubernetes (the customer owns hardware and identity, with no cloud control plane).

Every step links into the tool's own documentation; links were checked on 2026-10-11 · version 1

Setup (one time)

1. Create a free-tier AWS account to act as the vendor account, secure its root user with multi-factor authentication, and stop using root for daily work.
Every customer security review starts by asking how root is protected. IAM, STS and CloudFormation carry no charge, so the path stays inside the free tier.
Explained in: AWS account root user - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-11
Done when: You can sign in as root only with a second factor, and the account has no root access keys.
2. Create a second account to play the customer account and note which tasks in it still need root credentials.
Cross-boundary access can only be practised with two real account ids. Knowing the root-only tasks tells you what to ask the customer to do themselves.
Explained in: AWS account root user - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-11
Done when: You hold two distinct twelve-digit account ids, labelled vendor and customer, and a short list of root-only tasks.
3. Install the AWS command line tool on your laptop and configure it with credentials for a non-root identity in each account, as two named profiles.
The rest of the path switches between the vendor side and the customer side many times. Understanding the credential types early prevents leaking long-lived keys.
Explained in: AWS General Reference - AWS General Reference (docs.aws.amazon.com), checked 2026-10-11
Done when: Asking each profile for its caller identity prints the matching account id and a non-root identity.

Steps

1. Create your first administrative identity in the vendor account by following the IAM getting started flow, then sign in with it instead of root.
This is the first run of the tool: it shows the sign-in, identity and permission flow that every later step builds on.
Explained in: Getting started with IAM - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-11
Done when: You are signed in to the console as a non-root identity and can open the IAM dashboard.
2. Write a one-page map of the IAM object model: principals, users, roles, policies, and how a request is authenticated and then authorized.
Customer access negotiations go faster when you can say exactly which object you need created and which you do not.
Explained in: What is IAM? - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-11
Done when: Your page names each object, says who creates it in a customer deployment, and traces one request from sign-in to allow or deny.
3. Write a decision note that compares vendor-hosted, customer cloud and on-premises deployment of one AI service against the Well-Architected pillars.
The deployment model is chosen before any access is granted, and the pillars give a neutral vocabulary for the trade-offs a customer cares about.
Explained in: AWS Well-Architected Framework - AWS Well-Architected Framework (docs.aws.amazon.com), checked 2026-10-11
Done when: The note has one row per pillar and one column per deployment model, with a stated recommendation for a regulated customer.
4. Create a role in the customer account that trusts the vendor account only when a matching external ID is supplied, modelled on the confused deputy example; apply the condition to an IAM role trust policy, which is free, rather than to a paid CloudTrail channel.
This is the standard way a customer grants a vendor access without sharing credentials. The external ID stops another tenant of the vendor from reusing the trust.
Explained in: AWS CloudTrail resource-based policy examples - AWS CloudTrail (docs.aws.amazon.com), checked 2026-10-11
Done when: Assuming the role from the vendor profile succeeds with the external ID and is denied without it.
5. Create a log group in the customer account, attach a policy to the cross-account role that allows access to that one log group only, then compare what the role can read there against a second log group.
Customers expect vendor access scoped to named resources, and logs are the first thing you need when a deployment misbehaves.
Explained in: Using identity-based policies (IAM policies) for CloudWatch Logs - Amazon CloudWatch Logs (docs.aws.amazon.com), checked 2026-10-11
Done when: With the assumed role you can read events in the permitted log group and get an access denied error on the other one.
6. Run an assume role call from the vendor profile and inspect the temporary credentials that STS returns, including their expiry.
Short-lived credentials are what make cross-boundary access acceptable to a security team. You need to know how long a session lasts before an automated deployment breaks.
Explained in: AWS services that work with IAM - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-11
Done when: You can show a set of temporary credentials with an expiry time, and a call made after expiry fails.
7. Package a small container image on your laptop, create a private registry repository in the vendor account, and configure a resource-based policy on it that lets the customer account pull the image.
Shipping into a customer cloud usually means the customer pulls your artifacts from your registry. The repository policy is the promotion gate between the two accounts.
Explained in: Identity and Access Management for Amazon Elastic Container Registry - Amazon ECR (docs.aws.amazon.com), checked 2026-10-11
Done when: The customer profile pulls the image successfully and a push from the customer profile is denied.
8. Write a mapping table that takes each AWS service your architecture uses from the services that work with IAM table and names its Google Cloud and Azure counterpart, plus whether it supports resource-based policies and temporary credentials.
Customers on another cloud ask for the same architecture. The IAM feature columns show where an identity pattern will not translate one to one.
Explained in: AWS services that work with IAM - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-11
Done when: Every service in your design has a row with three cloud names and a note on any identity feature missing on one of them.
9. Compare granting the customer pull access through an identity-based policy on a role with granting it through the resource-based policy on the repository, and record which side must make each change.
Across an account boundary both sides often need to allow the action. Knowing who edits what avoids a week of back-and-forth tickets.
Explained in: Identity-based policies and resource-based policies - AWS Identity and Access Management (docs.aws.amazon.com), checked 2026-10-11
Done when: You have a two-column note showing, for each policy type, which account owns the change and the result of removing it.
10. Write a CloudFormation template that creates the cross-account role, its scoped policy and the log group, then create the stack in the customer account, acknowledging that it creates IAM resources.
A template the customer can read and run themselves is infrastructure as code they can audit. The explicit acknowledgement is the control their reviewers look for.
Explained in: Control CloudFormation access with AWS Identity and Access Management - AWS CloudFormation (docs.aws.amazon.com), checked 2026-10-11
Done when: The stack reaches a complete status only when the IAM capability is acknowledged, and fails with a clear error without it.
11. Configure a least-privilege deployer policy in the customer account that allows only the CloudFormation actions needed to create and update your stack, and run the deployment under it.
Customers rarely grant administrator rights to run a vendor template, so you must know the minimum set of actions to request.
Explained in: Control CloudFormation access with AWS Identity and Access Management - AWS CloudFormation (docs.aws.amazon.com), checked 2026-10-11
Done when: The stack updates successfully under the deployer policy, and deleting an unrelated stack with it is denied.
12. Reproduce the whole deployment from scratch by deleting the stack and recreating it using only temporary federated credentials, with no long-lived access keys present on the laptop.
This is the production-like finish: a repeatable, customer-run deployment under short-lived access is what a real engagement signs off on.
Explained in: Control CloudFormation access with AWS Identity and Access Management - AWS CloudFormation (docs.aws.amazon.com), checked 2026-10-11
Done when: A clean recreate completes with temporary credentials only, and the external ID, log scoping and image pull checks all pass again.

Back to Deploying into customer clouds: AWS, Google Cloud and Azure