# Deployment Architecture --- # Lección: Deployment decision framework LESSON 1 OF 5 · DEPLOYMENT ARCHITECTURE ## One decision shapes the entire engagement By the end of this lesson you can recommend a deployment path for any client profile and defend it on billing, auth, compliance, and capability grounds. Why this decision is hard to reverse ## The path sets the rails before anyone writes a prompt Where the client's Claude Code traffic runs determines who bills them, how users authenticate, where usage data lands, and which features exist at all. - Procurement signs against the billing route - Security reviews the auth model - Finance builds chargeback on the cost-tracking surface Reversing the path after rollout means re-running all three workstreams, which is why on a standard 30-day activation this recommendation lands in pre-kickoff, the two weeks before Day 0, alongside the security questionnaire and org-level setup, not in a mid-engagement change request. Treat it the way you'd treat a platform selection in any modernization engagement: a one-way door unless someone pays to walk back through it. Working rule The client's existing cloud commitments and compliance posture pick the path. Your job is to surface them before the client picks by default. Next: The four paths Back: Why this decision is hard to reverse The four paths ## Same Claude Code, four different rails The CLI is identical on every path. What changes is everything around it. 01 Claude for Enterprise (direct) Anthropic's recommended default. Seat-based contract, SSO and domain capture, role-based permissions, managed policy settings, compliance API. The only path that bundles Claude on the web and the only path eligible for zero data retention. Auth is Claude.ai SSO; cost tracking lives in the usage dashboard. 02 Amazon Bedrock Model traffic stays inside the client's AWS account. PAYG billing through AWS, so spend burns down existing AWS commitments. Auth via IAM or Bedrock API keys, audit via CloudTrail, cost tracking in Cost Explorer, content filtering via Bedrock Guardrails. The client owns model enablement per account and region. 03 Google Vertex AI GCP-native equivalent. Billing through GCP, auth via GCP credentials and Application Default Credentials, IAM roles, Cloud Audit Logs. Model access is requested per project through Model Garden and can take 24 to 48 hours to approve, which matters for activation timelines. Supports global, multi-region, and regional endpoints. 04 Microsoft Foundry Azure-native path. Billing through Azure, auth via API key or Microsoft Entra ID, RBAC policies, Azure Monitor. The client provisions Claude model deployments in the Foundry portal. One nuance to know cold: Foundry requests route to Anthropic-operated infrastructure, unlike Bedrock and Vertex. That changes the data residency conversation, and Lesson 3.5 covers how. Next: The decision drivers Back: The four paths The decision drivers ## Four questions, asked in this order Work through these in discovery. The client's answers do the narrowing. 1 Where do cloud commitments sit? A committed-spend agreement the client needs to burn down, an AWS EDP (Enterprise Discount Program), GCP CUD (Committed Use Discount), or Azure MACC (Microsoft Azure Consumption Commitment), is the single strongest pull toward the matching cloud path. Spend that counts against the commitment is money the client considers already spent. Ask procurement, not just IT. 2 How does procurement want to buy? Seat-based subscription through a new Anthropic contract, or PAYG through a cloud marketplace vendor they already have on paper? Many enterprises can approve marketplace spend in days and a new vendor in months. This decides timelines as much as architecture. 3 What does the compliance posture demand? If the client requires zero data retention, that is Enterprise direct only. If they require traffic to stay inside their own cloud tenancy and regions, that points to Bedrock or Vertex. Get the security questionnaire early; Lesson 3.5 gives you the answers it will ask for. 4 Who manages users and budgets? Enterprise direct gives admins seat management, managed policy settings, and a usage dashboard out of the box. On the cloud paths the client builds the equivalent from IAM plus cloud cost tooling, or adds an LLM gateway for central auth and budgets. That gateway pattern is Lesson 3.4. Next: The trade-off to name out loud Back: The decision drivers The trade-off to name out loud ## Cloud-native control, or the full product Every path recommendation is a trade. Saying the trade explicitly is what separates a recommendation from a preference. Cloud provider paths The client's perimeter, the client's tooling Traffic and billing inside infrastructure the client already governs. IAM they already audit, cost tooling finance already uses, commitments procurement already signed. The cost: no bundled Claude on the web, no ZDR, and a handful of capability gaps you will flag in Lesson 3.2. Two consequences hit the activation directly: - Own model version pinning: unpinned aliases resolve to defaults that can lag new releases or break users when a model isn't enabled in their account yet; pin versions in managed settings before rollout - Build the usage dashboard: cost reporting gets assembled from Cost Explorer, GCP Billing, or Azure Cost Management, or centralized through the gateway pattern in Lesson 3.4 Claude for Enterprise direct The full surface, managed by Anthropic One subscription covers Claude Code and Claude on the web, with SSO, seat management, managed settings, compliance API, and ZDR eligibility. The cost: a new vendor relationship, seat-based pricing rather than committed-spend burn-down, and model traffic to Anthropic's platform rather than the client's own tenancy. From decision to Day -14 ## The recommendation writes your pre-kickoff checklist On a 30-day activation, pre-kickoff runs from Day -14 to Day 0. Each path puts different blockers on that list, and some have lead times you cannot compress. Enterprise direct Identity is the long pole - Configure SSO and domain capture with the client's IdP team - Map seat list and role assignments - Apply managed policy settings - Submit ZDR enablement request to the Anthropic account team if required; it is confirmed per organization Amazon Bedrock Account plumbing, mostly same-day - Submit use-case form per AWS account (access is immediate) - Create IAM policy for model invocation and inference profiles - Enable Claude models in target regions - Pin model IDs in shared settings before anyone installs Google Vertex AI File the access request on Day 1 - Enable Vertex AI API on the project - Request Claude access in Model Garden (approval can take 24 to 48 hours) - Confirm quota in the target region - Pin model IDs in shared settings The approval wait is the reason this can't start the week of kickoff. Microsoft Foundry Provision deployments, fix the versions - Provision Foundry resource - Create Claude model deployments with fixed versions rather than auto-update - Agree Entra ID roles or API key handling with the identity team - Pin deployment names in settings Next: Scenario: make the call Back: The trade-off to name out loud Scenario · Make the call ## Meridian Capital wants a recommendation by Friday A financial services client, 800 developers, is activating Claude Code. You lead the deployment workstream. Four decisions, eight points. Choices have consequences. Simulation Meridian Capital · Deployment workstream You're in the room now. Click a card to commit to a choice. Choices lock, consequences land, and the credibility meter travels with you. Green is a strong call, orange is defensible, grey costs you the room. Credibility · 0 / 8 1 Decision 1 of 4 · Discovery call You have 30 minutes with the client's platform lead and a procurement manager. What do you pin down first? Choose your move A Seat count and rollout phasing How many of the 800 developers need access in wave one, and on what timeline. Select B Cloud commitments and buying route Whether an EDP, CUD, or MACC exists, and whether procurement prefers marketplace spend or a new vendor contract. Select C IDE standards and repo structure Which editors the teams use and how their monorepo is laid out, so setup guidance is ready. Select 2 Decision 2 of 4 · The recommendation Procurement confirms a three-year AWS EDP with significant unburned commitment, and the CFO wants AI spend counted against it. The security review is still pending. What goes in your recommendation draft? Choose your move A Bedrock, conditional on the security review EDP burn-down plus AWS-native IAM and CloudTrail fit their stated priorities. Flag that the pending review could still change the call. Select B Enterprise direct Strongest admin controls, bundled web access, and ZDR eligibility. Recommend it as the premium option despite the EDP. Select C Microsoft Foundry Their identity stack is Entra ID, so the Azure path gives the cleanest authentication story. Select 3 Decision 3 of 4 · The CISO pushes back In the review meeting the CISO asks: "Can we get zero data retention on Bedrock?" The room looks at you. Choose your move A "Yes, ZDR applies on every path" Reassure the room that Anthropic's zero data retention covers Claude Code wherever it runs. Select B "No. On Bedrock, retention is governed by AWS" Anthropic ZDR is an Enterprise-direct capability. On Bedrock, inference runs in their AWS account, so retention and encryption follow AWS policies they already control. Select C "Let me take that away and confirm" Park the question and follow up with the Anthropic account team after the meeting. Select 4 Decision 4 of 4 · The CIO's last question The CIO is ready to sign off on Bedrock but asks: "What are we giving up versus going direct?" Choose your move A Keep it commercial Explain the billing difference: PAYG burn-down instead of seats, and a usage dashboard they'll have to build from AWS tooling. Select B "Functionally nothing" The CLI is the same binary on every path, so the developer experience is identical. Keep the momentum toward sign-off. Select C Name the parity gaps No bundled Claude on the web, no Anthropic ZDR, WebSearch unavailable, and the client owns model version pinning. Offer a one-page gap memo before sign-off. Select Engagement debrief 0 / 8 The path you took Run the scenario again Course artifact · Lesson 1 contribution Deployment Decision Doc Deployment Decision Doc By the end of this course you'll have a Deployment Decision Doc for a sample client: the path recommendation plus the auth, network, gateway, and compliance posture that defends it. This lesson contributes the client profile and path recommendation. 1 Open a new doc. Define a sample client: industry, developer count, primary cloud, and one committed-spend agreement (EDP, CUD, or MACC). 2 Answer the four decision drivers for that client in one sentence each: commitments, buying route, compliance posture, admin ownership. 3 Write the recommendation: one path, two sentences of rationale, and the single condition that would change your call. 4 List the pre-kickoff blockers your path creates, each with an owner and a lead time, so the doc drops straight into the Day -14 checklist of an activation plan. LESSON 1 OF 5 COMPLETE ## You can make the call. Now defend the fine print. The path follows the client's cloud commitments, buying route, and compliance posture, and a recommendation isn't complete until you've named what the client gives up by taking it. UP NEXT · LESSON 2 Feature parity gaps and what to flag to the client The specific capability differences between the paths, and how to put them in front of the client before contract, not after. --- # Lección: Feature parity gaps and flags LESSON 2 OF 5 · DEPLOYMENT ARCHITECTURE ## Flag the gaps before the contract By the end of this lesson you can name the capability gaps of each deployment path and put them in front of the client without losing the deal. Why timing determines the outcome ## Every gap gets discovered. The only question is by whom, and when In Lesson 3.1 you recommended a path. The same CLI runs on all of them, but the surface around it differs, and those differences surface mid-activation if you let them. On a 30-day activation the pattern is predictable: - Week one: a champion asks where a feature went - Week two: the CoE asks why the metrics dashboard is empty - Day 30: the biggest-gaps report either contains items the client has known about since contract time, or items they're hearing for the first time with your name attached A one-page gap memo, delivered with the path recommendation before signature, is the cheapest insurance in this course. It's the same discipline as flagging scope exclusions in an SOW: nobody disputes a line they agreed to. Working rule A gap flagged at contract time is consulting. The same gap discovered in week three is a defect with your name on it. Next: The gap map Back: Why timing determines the outcome The gap map ## Six gaps that belong in your memo These are the differences between the cloud paths and Enterprise direct that clients actually hit. Match them to the path you recommended in 3.1. Bedrock · Capability WebSearch is unavailable The built-in WebSearch tool does not work on Bedrock. Teams that lean on live documentation lookups need an approved MCP alternative, scoped during pre-kickoff, not improvised in week two. All cloud paths · Product surface No bundled Claude on the web Only Teams and Enterprise direct include the web surface. On Bedrock, Vertex, or Foundry, business stakeholders have no chat surface unless the client buys one separately. This surfaces the first time an executive asks for a demo. All cloud paths · Compliance Anthropic ZDR does not apply Zero data retention is an Enterprise-direct capability. On the cloud paths, retention follows the provider policies the client already governs. Accurate framing, as you practiced in 3.1: different control, not absent control. All cloud paths · Operations Model versions are the client's job Aliases like sonnet resolve to defaults that can lag releases or point at models the account hasn't enabled. Background tasks also default to the primary model rather than a cheaper Haiku-class one. Pin versions in shared settings before rollout. All cloud paths · Measurement Telemetry defaults to off Anthropic metrics, error reporting, and /feedback submission are disabled by default on third-party paths; feedback writes a local bundle instead. The adoption metrics the CoE reviews weekly need OTel or a gateway, which Lesson 3.4 covers. Vertex · Lead times and defaults Vertex has its own fine print - Allow 24 to 48 hours for Model Garden access approval - Enable MCP tool search explicitly: off by default, so large tool catalogs load upfront if left unconfigured - Verify prompt caching by region: availability varies on both Vertex and Bedrock; if cache counts sit at zero, check the region The conversation ## A gap memo is one page, not a risk register Structure each line the same way: - Name the gap: which capability is absent or reduced on this path - Place the moment: which week, which person, which meeting the client would have hit it - Lead with the mitigation: the plan already in place, stated before the limitation "WebSearch is unavailable on Bedrock; your platform docs team would hit this in week one; we'll scope an approved MCP alternative in pre-kickoff" reads as preparation. A bare feature comparison table reads as a reason to stall the deal. Lead with the mitigation, and the memo becomes evidence you've done this before. Next: Scenario · Hold the line Back: The gap map Scenario · Hold the line ## Northgate Logistics signed Bedrock. The gaps start arriving You wrote the gap memo at contract time. Now the activation is live and the gaps surface one by one. Three decisions, six points. Simulation Northgate Logistics · Weeks 0 to 4 Same rules as Meridian. Click a card to commit. Green is a strong call, orange is defensible, grey costs you the room. Credibility · 0 / 6 1 Decision 1 of 3 · Contract week The CTO reads your gap memo and frowns: "If I show security this list, they'll stall the whole deal. Can we trim it?" Choose your move A Keep every line, reframe each as a mitigation Each gap stays, paired with the moment it would surface and the plan already in place. Offer to walk security through it yourself. Select B Trim it to the two gaps security would care about Keep ZDR and telemetry, drop the product-surface items. The CTO knows their security team best. Select C Move the memo to the kickoff deck instead Take it out of the contract conversation entirely and present it at kickoff once the deal is safe. Select 2 Decision 2 of 3 · Week two A champion posts in the activation channel: "WebSearch just doesn't work for anyone. Is our install broken?" Twenty developers are watching the thread. Choose your move A File a support ticket and post that it's under investigation Treat it as a possible defect until confirmed. Better safe than wrong in front of twenty people. Select B Reply with the memo line and the planned alternative WebSearch is unavailable on Bedrock, it was flagged at contract, and the approved MCP alternative is in the catalog. Link both. Select C Suggest developers use claude.ai in the browser for lookups Quick unblock: personal Claude accounts can search the web while you sort out a longer-term answer. Select 3 Decision 3 of 3 · CoE metrics review The CoE lead pulls up the weekly review: "Where's our usage data? The plan says we track DAU and cost per developer, and I see nothing." Choose your move A Explain the default and propose the fix Telemetry to Anthropic is off by default on Bedrock. The data lives in their own stack: OTel for usage events, Cost Explorer for spend, or centralized via the gateway you'll design next lesson. Select B Tell them the Anthropic dashboard should have it The Console has usage views; promise to find the right link after the meeting. Select C Run a developer survey to cover this week Self-reported usage and hours saved keep the review alive while the instrumentation question gets sorted later. Select Engagement debrief 0 / 6 The path you took Run the scenario again LESSON 2 OF 5 COMPLETE ## No surprises in the file. Now make it connect. Every path has gaps, and the gap memo turns them from week-three defects into contract-time line items with mitigations already attached. UP NEXT · LESSON 3 Corporate proxy configuration The network posture that decides whether day-one installs work: HTTPS_PROXY, TLS inspection, and the allowlist to hand the client's network team. --- # Lección: Corporate proxy configuration LESSON 3 OF 5 · DEPLOYMENT ARCHITECTURE ## Day 1 lives or dies at the proxy By the end of this lesson you can configure Claude Code for a proxied, TLS-inspected corporate network and hand the client's network team the exact allowlist they'll ask for. Where installs break ## The first support ticket of every enterprise activation is a network ticket The activation plan calls it "setup support: confirm blockers prior to kickoff." In practice it means one thing: find out what sits between the developer's terminal and the model endpoint before forty people install at once. Two different components can sit in that path, and they solve different problems. A corporate proxy routes outbound traffic through the client's network perimeter for monitoring and policy enforcement; you configure Claude Code to pass through it. An LLM gateway sits in front of the model provider to handle auth, budgets, and usage attribution; that's Lesson 3.4. They stack: plenty of clients run both. This lesson is the perimeter half, and it's pure pre-kickoff work, because the failure mode is forty developers with hanging terminals in the first hour of Week 1. Corporate proxy · This lesson Gets traffic out of the building The client's existing network perimeter: HTTP/HTTPS proxy, TLS inspection, firewall allowlists. Claude Code respects the standard proxy environment variables. Owned by the network and security teams. LLM gateway · Lesson 3.4 Controls what happens to model traffic Centralized auth, usage tracking, budgets, audit. A service the client deploys deliberately, not perimeter plumbing they already have. Configured through base-URL overrides rather than proxy variables. Next: The proxy variables Back: Where installs break The proxy variables ## Four environment variables cover most networks Configuration detail ahead: developers and architects, this is yours. Business-facing consultants can skip to Topic 4, where the allowlist conversation lives. # Route Claude Code through the corporate proxy export HTTPS_PROXY=https://proxy.client.com:8080 # HTTP fallback if the proxy has no HTTPS endpoint export HTTP_PROXY=http://proxy.client.com:8080 # Keep internal hosts off the proxy (comma- or space-separated) export NO_PROXY="localhost,.client.com,169.254.169.254" # Proxy requires basic auth? Credentials go in the URL -- # from a secrets manager, never hardcoded in a script export HTTPS_PROXY=http://user:pass@proxy.client.com:8080 Proxy env vars are OS-level and cannot be set via Claude Code's settings files. To deploy them org-wide, use MDM: Jamf or Kandji on macOS, Windows registry policy on Windows. Two boundaries to know before the client asks: - Rule out SOCKS proxies: not supported; if the client runs SOCKS for other engineering tools, it's not a viable path for Claude Code - Escalate NTLM or Kerberos auth to the gateway: Claude Code can't speak either protocol directly; an LLM gateway that handles enterprise auth becomes the answer, which is one more reason 3.4 matters Next: TLS inspection and trust Back: The proxy variables TLS inspection and trust ## "Self-signed certificate in chain" means the proxy is working as designed TLS-inspecting proxies like Zscaler or Netskope re-sign traffic with the corporate root CA. Claude Code trusts the OS system trust store by default, so on a well-managed fleet this usually just works. When it doesn't, the corporate root certificate isn't where Node can see it. The fix is to point at it directly, not to disable verification. Any suggestion of turning off TLS checks fails the client's own security review, and it should. # Trust the corporate root CA directly export NODE_EXTRA_CA_CERTS=/etc/ssl/corp-root-ca.pem # Control which trust stores are used (default: system) export CLAUDE_CODE_CERT_STORE=system # Client-certificate (mTLS) environments export CLAUDE_CODE_CLIENT_CERT=/path/to/client-cert.pem export CLAUDE_CODE_CLIENT_KEY=/path/to/client-key.pem Next: The allowlist conversation Back: TLS inspection and trust The allowlist conversation ## "Which domains does this thing need?" deserves a prepared answer The network team will ask. Handing them the list in the first meeting, with rationale per domain, is the difference between a same-week approval and a three-week change request. Model and API api.anthropic.com Claude API requests on the direct path, and the WebFetch domain safety check on every path. Block it on a Bedrock deployment and WebFetch fails even though model traffic flows fine, unless settings disable the preflight. Authentication claude.ai · platform.claude.com Account authentication for claude.ai and Console accounts respectively. On Bedrock, Vertex, and Foundry, auth goes to the cloud provider instead, so these mostly matter on the direct path. Distribution downloads.claude.ai Native installer, auto-updater, and plugin executable downloads. Clients that distribute Claude Code through their own artifact registry can often skip this for end users. Cloud paths Provider endpoints instead On Bedrock, Vertex, or Foundry, model and auth traffic go to the provider's endpoints, which are usually already reachable. Optional telemetry to Anthropic defaults off, as flagged in 3.2. Verify the final posture with /status inside Claude Code. Once the allowlist is approved, the next question from IT is usually: "How do we make sure every developer uses the right configuration?" That is what managed settings is for. What it is The org-level policy layer managed-settings.json sits at the top of Claude Code's settings hierarchy, above user and project settings. Rules set here cannot be overridden by individual developers. Use it to lock permissions, enforce allowed MCP servers, require SSO login, and pin version floors across the org. How it reaches developer machines Three delivery paths Server-managed via the Anthropic admin console, Enterprise only. MDM/OS-level via plist on macOS or registry on Windows; deploy through Jamf, Kandji, or similar. File-based: write managed-settings.json to the system directory for the OS. All three require admin rights, which is the point. Next: Scenario: the install clinic Back: The allowlist conversation Scenario · The install clinic ## Forty terminals at Halvern Bank, all hanging Week 1, Day 1. The kickoff went well, the install session is now, and nothing connects. Four decisions, eight points. Simulation Halvern Bank · Day-one install clinic Click a card to commit. Choices lock, consequences land. Green is a strong call, orange is defensible, grey costs you the room. Credibility · 0 / 8 1 Decision 1 of 4 · Everything hangs Every developer's first prompt spins forever. Forty people, one hour booked, zero working installs. Your first move? Choose your move A Get the network team on the call Ask the two questions that matter: does outbound traffic transit a proxy, and is TLS inspection on? Everything every terminal does next depends on those answers. Select B Have everyone uninstall and reinstall Forty identical failures suggest a bad build. A clean reinstall rules it out fastest. Select C Test one laptop on a phone hotspot If it works off the corporate network, you've isolated the problem to the perimeter in five minutes. Select 2 Decision 2 of 4 · Proxy confirmed The network team confirms: all outbound traffic transits proxy.halvern.net:8080. How do you roll out the fix to forty machines? Choose your move A Post export commands in the channel Everyone adds HTTPS_PROXY to their shell profile. Works within the hour for whoever does it right. Select B Push HTTPS_PROXY and NO_PROXY via MDM Proxy env vars are OS-level; deploy via Jamf or Kandji on macOS, registry policy on Windows. Every existing machine picks it up, and new machines get it on enroll. Select C Ask for the SOCKS endpoint instead Halvern also runs a SOCKS5 proxy for engineering tools; point Claude Code at that and skip the HTTP proxy entirely. Select 3 Decision 3 of 4 · The certificate error Proxy configured, new error: "self-signed certificate in certificate chain." A developer suggests a flag he found on Stack Overflow: NODE_TLS_REJECT_UNAUTHORIZED=0. Choose your move A Use the flag as a temporary unblock It gets forty people working today. Swap in the proper fix once the clinic is over. Select B Point NODE_EXTRA_CA_CERTS at the corporate root CA The TLS-inspecting proxy is re-signing traffic; trust its root certificate explicitly and ship that in the same managed settings block. Select C Request a TLS-inspection bypass for the API domains Ask the network team to exempt api.anthropic.com from inspection. Legitimate, but it's a security change request with its own approval cycle. Select 4 Decision 4 of 4 · Security wants the list Installs work. Halvern's security lead asks for "the definitive list of every domain this tool talks to," in writing, before wave two. Choose your move A Send the allowlist with rationale per domain API, auth, and download domains, each with its purpose, plus the WebFetch preflight nuance and which telemetry endpoints are optional and how to disable them. Select B Suggest allowing *.anthropic.com and *.claude.ai Wildcards cover whatever the product needs now and later, and it's one line in the proxy config. Select C Tell them it's all standard HTTPS on port 443 It rides the same rails as any SaaS tool; no special firewall treatment needed. Select Engagement debrief 0 / 8 The path you took Run the scenario again LESSON 3 OF 5 COMPLETE ## Traffic gets out of the building. Now govern it. Proxy posture is pre-kickoff work: HTTPS_PROXY deployed via MDM, the corporate root CA trusted explicitly, and an allowlist the network team can approve in one reading. UP NEXT · LESSON 4 The LLM gateway pattern Centralized auth, per-team budgets, and the usage attribution that unblocks the CoE metrics review, designed once for every developer. --- # Lección: LLM gateway pattern ## LLM gateway pattern LESSON 4 OF 5 · DEPLOYMENT ARCHITECTURE ## A proxy passes traffic. A gateway understands it. By the end of this lesson, you can explain when a client needs an LLM gateway over a proxy, configure one for any deployment path, and show how session headers turn gateway logs into per-team chargeback. Proxy vs. gateway ## The distinction that matters for enterprise clients Enterprise clients with multiple development teams making model calls will eventually ask: who is spending what? A proxy cannot answer that question. A gateway can. Proxy Forwards traffic Routes requests from inside the network to an external endpoint. Applies firewall rules, TLS inspection, and egress controls. Sees packets. Does not understand what is inside them. Gateway Understands model traffic Parses the request, applies auth policy, attributes cost to a team, enforces rate limits, logs the interaction, and routes to the right provider. The proxy gets traffic out of the building. The gateway governs what happens to it. What a gateway provides ## Five capabilities a proxy cannot replicate A proxy has no concept of a team, a budget, or a provider. A gateway has all three. These are the five things enterprise clients with more than one team will eventually ask for. 01 Centralised authentication Provider credentials live in one place the platform team controls. Developers hold short-lived gateway tokens. Credential rotation happens once, centrally, not across every developer machine. 02 Per-team cost attribution Session headers map each request to a team token. The gateway answers who spent what without parsing request bodies or estimating from cloud invoices. 03 Budget enforcement Rate limits and spend caps applied per team at the request boundary, before the model call is made. This is an enforcement feature, not a reporting feature. 04 Model routing Switch providers or model versions behind a stable endpoint. A client running Bedrock and Vertex side by side presents both through one base URL. No developer machine changes required on a provider swap. 05 Compliance audit logging Every model interaction logged in the client's own stack. On cloud paths where OTel telemetry to Anthropic defaults off, as covered in 3.2, the gateway audit log is where observability comes from. Configuration ## A base URL, a token, and a skip flag Developers and architects: this section is for you. The pattern is identical across deployment paths. Only the variable names change. # Gateway exposing the Anthropic API format export ANTHROPIC_BASE_URL=https://llm-gateway.client.com export ANTHROPIC_AUTH_TOKEN=team-token-from-gateway # Bedrock behind the gateway export CLAUDE_CODE_USE_BEDROCK=1 export ANTHROPIC_BEDROCK_BASE_URL=https://llm-gateway.client.com/bedrock export CLAUDE_CODE_SKIP_BEDROCK_AUTH=1 # Vertex behind the gateway export CLAUDE_CODE_USE_VERTEX=1 export ANTHROPIC_VERTEX_BASE_URL=https://llm-gateway.client.com/vertex export CLAUDE_CODE_SKIP_VERTEX_AUTH=1 The skip-auth flags are the centralised-auth payoff in code: Claude Code stops signing requests itself because the gateway injects provider credentials server-side. For rotating per-user tokens, configure apiKeyHelper in settings to run a script that fetches from the client's vault. One requirement for the gateway team's acceptance criteria: the gateway must forward anthropic-beta and anthropic-version headers intact. A gateway that strips them silently degrades Claude Code features, and that failure looks like a product bug until someone inspects the traffic. Session headers ## How Claude Code labels its own traffic Every Claude Code request carries attribution headers the gateway can read without parsing the request body. These three headers are the foundation of per-team chargeback. Session level X-Claude-Code-Session-Id A unique ID for the current Claude Code session. The gateway aggregates all requests in a session under this ID. This gives you session-level cost and duration reporting without touching request bodies. Subagent level X-Claude-Code-Agent-Id Present on requests from subagents. When Claude Code fans out into parallel subagents, each carries its own agent ID so the gateway can attribute cost to individual agent threads within the session. Parent relationship X-Claude-Code-Parent-Agent-Id Links a subagent to its parent. Enables full nested agent attribution: a session that spawns five subagents still rolls up correctly into a single team's cost report at the CoE review. What this enables Per-team chargeback Map gateway tokens to teams and the three headers give you cost per team per week, sessions per developer, and budget alerts before the next invoice. The CoE metrics review and the CFO conversation, served by the same data pipe. Non-technical leads: these headers are what enable per-team cost reporting in the Day 30 readout. You do not configure them. Claude Code sends them automatically. The gateway reads them. Reference implementation ## LiteLLM as the starting point Anthropic's gateway documentation uses LiteLLM as its reference implementation. It is not the only option, but it has the most tested configuration patterns for Claude Code deployments. LiteLLM proxies support both Anthropic Messages format and OpenAI-compatible format pass-through. For clients who already run OpenAI-format tooling, this means a single gateway can serve both workflows without a separate integration layer. The base-URL override and skip-auth flags documented in Section 3 work identically whether the path is the Anthropic API, Bedrock, or Vertex. Configuration details and currently tested versions are in the Anthropic LLM gateway documentation at code.claude.com/docs/en/llm-gateway. Security notice LiteLLM PyPI versions 1.82.7 and 1.82.8 were compromised with credential-stealing malware. Do not install those versions. Before any client deployment using LiteLLM, verify the current safe version against the Anthropic LLM gateway documentation. This is a supply chain risk, not a product limitation. Positioning principle Every enterprise client with more than one team will eventually ask who is spending what. Recommend a gateway before they ask, not after the first invoice surprises someone. Course artifact · Lesson 4 contribution Deployment Decision Doc Section: Gateway recommendation and configuration Add the gateway section to your Deployment Decision Document. This section records whether the engagement needs a gateway and the key configuration decisions the platform team needs to action. 1. State whether the client requires a gateway. Use the positioning principle from this lesson as the decision criterion: more than one team, chargeback requirement, or multi-cloud routing need. 2. If yes, record which deployment path the gateway will front (Anthropic API, Bedrock, Vertex, or a combination) and confirm which skip-auth flags apply for each path. 3. Note the gateway acceptance criterion for the platform team handoff: the gateway must forward anthropic-beta and anthropic-version headers intact. Flag this as a pilot go/no-go requirement. 4. If recommending LiteLLM, confirm the installed version against the Anthropic LLM gateway documentation before recording it in the document. Lesson 4 out of 5 complete ## The network layer is designed. One question left: where does the data live? You can now recommend a gateway with a reason tied to the client's actual needs, configure it for any deployment path, and explain how session headers and per-team attribution turn gateway logs into a chargeback model the CFO can read. UP NEXT · LESSON 5 Security questionnaire preparation Turn deployment architecture decisions into audit-ready answers. Encryption by path, ZDR eligibility, Compliance API scope, and the data questions every enterprise security team asks. --- # Lección: Data residency, compliance posture, ZDR eligibility LESSON 5 OF 5 · DEPLOYMENT ARCHITECTURE ## Answer the security questionnaire in the room By the end of this lesson you can answer the training, retention, and residency questions a client security review asks, and state exactly what ZDR does and doesn't cover. The gate ## The questionnaire is the first item in pre-kickoff for a reason Every activation plan starts with the security onboarding questionnaire, because nothing else proceeds until it clears. Three questions decide it. 1 "Does our data train your models?" Short answer: no, not under commercial terms. The full answer, including the one opt-in exception you must know about, is Topic 2. 2 "What do you retain, and for how long?" Short answer: governed by your customer agreement; confirm the current retention window with your account team. ZDR is the no-server-side-persistence option on one specific path. Topics 2 and 3. 3 "Where does our data physically go?" Short answer: it depends on the path you chose in 3.1, and one path behaves differently than clients assume. Topic 4. You've already practiced the stakes: in the Meridian scenario, one wrong ZDR answer in front of a CISO cost more credibility than any architecture diagram earned back. This lesson gives you the complete answers, so the questionnaire becomes a meeting you run rather than a form you fear. Next: Training and retention Back: The gate Training and retention ## The answers, with the nuances that survive fact-checking Half-right answers are worse than no answer, because security teams verify. These are the complete versions. Training: Anthropic does not train generative models on code or prompts sent to Claude Code under commercial terms: Team, Enterprise, API, and the cloud paths alike. The one exception is explicit opt-in, such as the Development Partner Program, which an org admin must actively join, and which isn't even available on Bedrock or Vertex. Say "no, unless you explicitly opt in," not "no, never": the qualified version survives the client's own research. Retention: Server-side retention is governed by the customer agreement; confirm the current retention window with your account team or the Anthropic privacy documentation rather than quoting a number that may not match their plan. And the answer endpoint-security teams actually need: Claude Code also caches session transcripts locally on each developer's machine, in plaintext under the user's home directory, configurable via settings. That's a device-management conversation, not a cloud one. Encryption at rest ## Where inference data lives, by path Anthropic direct AES-256, ZDR available Infrastructure-level disk encryption, with zero data retention as the no-server-side-persistence option for eligible Enterprise orgs. Topic 3 covers eligibility. Amazon Bedrock Client's AWS account, KMS optional AES-256 with AWS-managed keys, customer-managed keys available through KMS. Retention and key policy are governed by controls the client already audits. Google Vertex AI Client's GCP project, CMEK optional Google-managed encryption keys by default, customer-managed (CMEK) available. Same logic as Bedrock: the client's cloud governance applies. Microsoft Foundry The one that surprises people Foundry is an Azure-native deployment — Azure billing, Microsoft Entra ID authentication, and Azure RBAC policies apply. Confirm the data routing path with Anthropic before advising clients with cloud-specific data residency requirements. The "data never leaves our tenancy" question belongs in the path conversation, not the post-mortem. Next: ZDR, precisely Back: Training and retention ZDR, precisely ## Zero data retention is a scope, not a slogan ZDR applies to Claude Code on Claude for Enterprise, enabled per organization by the Anthropic account team after eligibility review. It is not in the standard Enterprise plan by default, and it is not available on the cloud paths. What it covers Claude Code inference, full stop Prompts and model responses from Claude Code sessions are processed in real time and not stored after the response returns, regardless of model, except where law or abuse-handling requires it. Admin capabilities like cost controls, analytics, and audit logs keep working. What it doesn't, and what it disables The trade the client must choose Not covered: claude.ai chat, Cowork, admin metadata like seat assignments, and anything third-party MCP servers process. Disabled outright because they require server-side storage: Claude Code on the web, remote sessions from the desktop app, and /feedback. And flagged sessions can still be retained up to 2 years under the usage policy. A client who wants ZDR and Claude Code on the web is choosing between them. Also worth saying in the room: analytics under ZDR shows usage metrics but not contribution metrics, so the Day 30 scorecard should be designed around what will actually be measurable. Each new org under the same account needs its own enablement, which is a detail that bites multi-org enterprises at rollout. Next: Residency and certifications Back: ZDR, precisely Residency and certifications ## Residency follows the path. Certifications follow the Trust Center If the client has a hard residency requirement, the cloud paths are where region control lives: Bedrock offers region selection across AWS regions, Vertex offers global, multi-region, and regional endpoints. On the direct path, service availability follows Anthropic's supported countries; specific region-level processing guarantees are an account-team conversation, and the honest move is to say so rather than improvise one. For the certification half of the questionnaire, the artifact set is self-serve at trust.anthropic.com: SOC 2 Type 2, ISO 27001:2022, ISO/IEC 27017 and 27018 for cloud security and privacy, ISO/IEC 42001 for AI management systems, CSA STAR Level 2, HIPAA with BAA available, GDPR, NIST 800-171 attestation, FedRAMP High through Claude for Government, and annual third-party penetration test summaries. Knowing that list from memory is optional; knowing it's all downloadable the same day the CISO asks is not. Working rule Answer from the facts you can cite, name the one thing you'll verify, and never improvise a guarantee. Security teams forgive "I'll confirm the region commitment." They don't forgive a wrong yes. Next: Scenario: the questionnaire, live Back: Residency and certifications Scenario · The questionnaire, live ## Corvane Health's CISO reads the questions out loud A life-sciences client, pre-kickoff, and the CISO wants answers in the meeting, not in a follow-up email. Five questions, ten points. This is the course's final gate. Simulation Corvane Health · Security review Click a card to commit. Choices lock, consequences land. Green is a strong call, orange is defensible, grey costs you the room. Credibility · 0 / 10 1 Question 1 of 5 · Training "Will our source code be used to train your models?" Choose your answer A "No, not under commercial terms, unless you explicitly opt in" Commercial data never trains models. The only exception is an admin-level opt-in like the Development Partner Program, which you'd have to join deliberately. Select B "It's anonymized before any training use" Reassure them that personal and proprietary details are stripped before data reaches training pipelines. Select C "Let me send you the data usage policy after this" Point to the official documentation rather than risk a wrong word in the room. Select 2 Question 2 of 5 · Retention "If we go Enterprise direct without ZDR, what exactly is retained, and where?" Choose your answer A "Server-side retention is governed by the agreement; check with your account team for the exact period" The server-side answer, without the local transcript piece the endpoint team will need. Select B "30 days server-side, plus local transcripts on each laptop" The standard policy, and the part endpoint security needs: session transcripts cache in plaintext on developer machines for 30 days by default, configurable, which belongs in their device-management review. Select C "Nothing is stored; sessions are ephemeral" Claude Code is a real-time tool; conversations disappear when the terminal closes. Select 3 Question 3 of 5 · ZDR "We want ZDR, and our teams are excited about Claude Code on the web. Both, yes?" Choose your answer A "Yes, both, that's the standard Enterprise package" Keep the energy up; the details can be confirmed during onboarding. Select B "They conflict. ZDR disables the web surface; let's choose deliberately" ZDR disables Claude Code on the web, remote sessions, and /feedback because they require server-side storage. It's also enabled per org after eligibility review, not bundled. Frame the trade and let security and engineering decide together. Select C "Let's secure ZDR first and revisit the web surface later" Lock in the compliance win now; the product surface question can wait for the next phase. Select 4 Question 4 of 5 · Residency "We're an Azure shop, so we'd use Foundry, and everything stays in our tenancy. Correct?" Choose your answer A "Broadly yes; I'll validate the specifics" Azure-native billing and auth, with a follow-up to confirm the data flow details. Select B "Correct, it's all inside your Azure boundary" That's the point of going with the native cloud path; the data never leaves their subscription. Select C "No, and that's worth pausing on: Foundry routes to Anthropic infrastructure" Unlike Bedrock and Vertex, Foundry requests are served on Anthropic-operated infrastructure. If hard tenancy residency is the requirement, Bedrock or Vertex satisfies it the way they're assuming; Foundry doesn't. Select 5 Question 5 of 5 · Evidence "Fine. Send me your certifications and your latest pen-test results by Friday." Choose your answer A "You'll have them today, from the Trust Center" SOC 2 Type 2, ISO 27001 and 42001, HIPAA BAA documentation, and the annual pen-test summary are self-serve at trust.anthropic.com. Send the links before the meeting ends. Select B "We're SOC 2 certified; that should cover your framework" Lead with the certification most security teams anchor on and offer the rest if they need it. Select C "I'll raise a request with Anthropic legal to compile a package" Formal documents should come through formal channels; expect it within a couple of weeks. Select Engagement debrief 0 / 10 The path you took Run the scenario again Course artifact · Lesson 5 contribution Deployment Decision Doc Deployment Decision Doc This is the final section. With it, the doc carries everything an engagement lead needs to defend the deployment: path recommendation, parity-gap memo, network posture, gateway design, and compliance posture. 1 Write the compliance section for your sample client: the training answer, the retention answer including local transcripts, and the ZDR position with its trade-offs. 2 Add the residency statement for your recommended path and the list of certification artifacts you'd send, with the Trust Center as source. 3 Assemble all five sections into the finished doc, then have a colleague play the client CISO and red-team it for fifteen minutes. Every question they ask that the doc can't answer is your edit list. With path recommendation, gateway design, and data residency complete, this document answers every question a client security review will raise before the rollout can begin. Practice Try this You've covered the four deployment paths, the gateway decision, and the data residency questions that come up in every security review. Before moving on: take a sample client profile and recommend a deployment path. Write up the rationale — cloud commitments, data residency position, and the parity gaps that would affect this client. That's the core of the Deployment Decision Doc, and the judgment call you'll need to make on every engagement. Deployment architecture · Complete ## You can recommend, configure, and defend a path. That's the deployment workstream. Five lessons ago, deployment was a checkbox. Now it's a sequence you own: the path decision driven by commitments and compliance, the gaps flagged before contract, the network and gateway posture configured for Day 1, and a security questionnaire you answer in the room. Course 8 builds the delivery methodology on top of exactly this foundation. Next Course Configuration and customization Course 4 covers the configuration decisions that shape how developers experience Claude Code across a client organisation — CLAUDE.md, managed settings, and permission policies. By the end you can customise any deployment for the client's security posture and team workflows.