LangSmith BYOC on AWS: Architecture and Setup

LangSmith BYOC on AWS is a managed deployment model for teams that want LangSmith observability and agent operations without placing sensitive traces and runtime data in a shared SaaS data plane. LangChain operates the platform; the customer owns the AWS account, VPC, databases, object storage, and data plane.

The practical verdict

LangChain announced BYOC on AWS as generally available on August 12, 2026. The current docs also say GA, while the public Enterprise Hub onboarding page still contains “Beta” wording and says fuller documentation is being built. Preserve that contradiction and confirm onboarding status with your LangChain contact.

What LangSmith BYOC is

BYOC means Bring Your Own Cloud. A customer creates or selects an AWS environment, applies LangChain’s Terraform module to create a scoped IAM role, and registers a data plane. LangChain then provisions and operates the platform in the customer account.

The model sits between LangSmith Cloud and self-hosting:

BYOC is for organizations that need their agents, traces, prompts, datasets, sandbox data, and private-system connections to remain inside a cloud boundary they govern, while still wanting LangChain to manage upgrades, scaling, patching, backups, and health monitoring.

Control plane and data plane

LangChain describes a two-plane architecture:

Communication between the planes uses AWS PrivateLink. LangChain says the private EKS cluster has no public API-server endpoint and worker nodes have no public IPs.

The customer data plane includes a dedicated VPC, private EKS cluster, private load balancer, RDS, ElastiCache, S3-backed trace storage, autoscaling, and multi-AZ services. LangChain provisions and reconciles infrastructure using Crossplane after assuming the customer-granted role.

The important boundary is not “everything is in AWS.” The customer’s sensitive data can stay in the customer account, while identity, organization configuration, billing metadata, and control-plane orchestration remain outside it. Document that split for compliance and threat-model reviews.

Regions and data residency

The current LangChain BYOC docs list 15 AWS data-plane regions:

LangChain says the control plane runs in us-east-2 regardless of the data-plane region. If you place the data plane in EU or APAC, sensitive application data can remain there while control-plane metadata remains in the US.

Do not treat a region list as a complete residency certification. Verify:

• which fields are sent to the control plane;
• support and break-glass access procedures;
• logs emitted by AWS, Kubernetes, and LangChain;
• backup locations and retention;
• model-provider egress from agents and sandboxes;
• cross-region traffic created by your own integrations.

Onboarding and setup

The documented onboarding flow is approval-based rather than a public self-serve deployment:

1. Create a LangSmith organization on the AWS sign-up surface and provide the organization ID to LangChain.
2. Confirm Enterprise eligibility, supported region, data-residency needs, and the required BYOC features.
3. Create a dedicated AWS account where possible; isolate BYOC from unrelated workloads.
4. Apply LangChain’s langsmith-byoc-role Terraform module to create the IAM role and external ID.
5. Register the data plane in LangSmith under infrastructure settings using the role ARN, external ID, region, and VPC CIDR.
6. Wait for the data plane state to move from Requested to Provisioning to Active.
7. Configure private connectivity such as PrivateLink, VPC peering, or Tailscale according to the approved architecture.
8. Validate SSO, roles, retention, audit logs, network paths, backups, and an agent trace before production rollout.

The direct AWS account setup is intentionally narrow: customers create the IAM role and grant the approved infrastructure capability; LangChain provisions the rest. Keep the Terraform module revision and role policy under change control.

A useful preflight record contains:

organization_id = <approved LangSmith organization>
aws_account    = <dedicated customer account>
data_region    = <approved AWS region>
vpc_cidr       = <non-overlapping private range>
role_arn       = <Terraform-created role>
external_id    = <LangChain-provided external ID>
features       = <approved LangSmith components>

Never place AWS access keys, license keys, or admin passwords in this record. Use the customer’s secret manager and the onboarding workflow.

Security and operating boundaries

The BYOC role is an infrastructure-management role, not a general data-reading grant. LangChain says permissions are limited where possible to resources with managed_by=langsmith tags and name prefixes, and the role does not include direct data-read permissions such as s3:GetObject on the trace bucket, database connection, or Redis connection.

Verify that claim in the exact Terraform module and account policy before approval. Your review should cover:

• IAM trust policy and external ID;
• resource tags and name-prefix enforcement;
• CloudTrail events for role assumption and resource mutation;
• EKS audit logs and CloudWatch retention;
• VPC flow logs written to a customer-owned S3 bucket;
• break-glass access, approval, expiration, and auditability;
• PrivateLink endpoint policies and DNS;
• sandbox node-group isolation and egress;
• secret injection and rotation;
• backup encryption, restore tests, and deletion behavior.

LangChain says operational access is auditable and that customer-owned audit paths include LangSmith audit logs, EKS audit logs in CloudWatch, and VPC flow logs in S3. Confirm retention and alerting rather than treating log existence as monitoring.

The current Terraform and BYOC security documentation also describes break-glass access as disabled by default and requiring explicit customer enablement and audit. Customer-managed KMS keys/CMKs are not supported today, according to the current FAQ; data at rest uses cloud-provider-managed keys. That is a material limitation for regulated teams that require customer-owned key control.

Because agents and sandboxes run in the customer VPC, they can potentially reach private databases, internal APIs, and on-premises systems. That is a major benefit and a major blast-radius decision. Start with deny-by-default egress, explicit service endpoints, separate workload subnets, and human approval for tools that mutate external state.

BYOC versus self-hosted and cloud

Choose LangSmith Cloud when the fastest start and managed SaaS fit your data policy. Choose self-hosted when your team needs full operational control and can own Kubernetes, database, backup, upgrade, and incident responsibilities. Choose BYOC when data must stay in your account but LangChain should operate the platform.

BYOC still creates vendor dependence in several places:

• LangChain controls the managed upgrade and reconciliation lifecycle.
• The control plane remains a required external dependency.
• Features may arrive later than in LangSmith Cloud; LangChain currently lists some capabilities as planned for BYOC.
• Enterprise sales and onboarding are required.
• AWS architecture, quotas, and account policy remain customer responsibilities.

The right comparison is not “private versus public.” It is who controls data, who operates infrastructure, which control-plane metadata leaves the account, and who carries the failure and upgrade burden.

Availability and documentation caveats

LangChain’s launch post and current docs describe BYOC on AWS as GA for Enterprise customers across 15 regions. The public Enterprise Hub onboarding page still says BYOC is in beta and that full public documentation is in progress. That may be a documentation transition, but it is material evidence for procurement and rollout planning.

Before signing off, confirm current:

• Enterprise plan and regional availability;
• supported features and planned features;
• control-plane region and data fields;
• AWS account prerequisites;
• support and emergency-access model;
• pricing and infrastructure charges;
• migration and rollback procedure;
• deletion and backup retention guarantees.

Do not call BYOC “self-hosted LangSmith,” and do not promise that no information ever leaves the customer account. State the exact data-plane/control-plane boundary instead.

FAQ

Sources and links

• LangChain: LangSmith BYOC on AWS is generally available
• LangChain BYOC documentation
• LangChain BYOC architecture
• LangChain BYOC onboarding
• LangChain BYOC FAQ
• LangChain Enterprise Hub BYOC onboarding overview
• LangSmith AWS sign-up
• LangChain AWS BYOC Terraform role module
• LangChain: self-hosted AWS Terraform deployment
• AgentPedia: LangChain architecture guide
• AgentPedia: Cloudflare WebMCP security guide
• AgentPedia: NVIDIA Nemotron and Switchyard guide