Cloud Provider Integration

USDN integrates with major cloud providers so you can extend your network into AWS, Azure, and (soon) GCP without writing infrastructure code by hand. Everything is driven from the USDN portal: link a cloud account once with OIDC federation, then validate credentials, discover networking resources, and launch AdWanOS devices directly from the Cloud Accounts page.

Supported Cloud Providers

Provider	Onboarding	Resource Discovery	Image Listing	Device Deploy	Lifecycle Mgmt
Amazon Web Services (AWS)	✅	✅ VPCs, subnets, security groups	✅ Marketplace + private AMIs	✅	✅ launch / poll / terminate
Microsoft Azure	✅	✅ Resource groups, VNets, subnets, NSGs	⏳ Planned	⏳ Planned	⏳ Planned
Google Cloud Platform (GCP)	⏳ Roadmap	—	—	—	—

Both AWS and Azure use Workload Identity Federation as the trust mechanism. USDN never stores cloud access keys, client secrets, or shared external IDs — credentials are minted on demand by exchanging a short-lived JWT (signed by the USDN OIDC issuer) for cloud-provider temporary credentials.

How Portal-Driven Integration Works

The trust anchor is the public JWKS that USDN exposes at /.well-known/openid-configuration. The customer cloud tenant pulls this and verifies every JWT signature. The JWT subject claim (usdn-deploy-<organization_id>) is what scopes access to a single tenant — another USDN organization cannot impersonate yours.

Network Architecture

When you deploy a device into a cloud tenant, that device participates in the same AdWanOS overlay as your on-premises devices.

The portal handles device registration, agent bootstrap, and tunnel configuration after launch — there is no manual SSH step.

Amazon Web Services (AWS)

Status: Production

AWS integration is fully end-to-end through the portal. Once your account is linked you can:

• Validate credentials — portal calls sts:AssumeRoleWithWebIdentity and sts:GetCallerIdentity to confirm the trust path.
• Discover networking — VPCs, subnets, and security groups are pulled live for the deploy wizard.
• Browse images — list AdWanOS Marketplace AMIs and any private AMIs the role can describe.
• Deploy devices — ec2:RunInstances against the chosen subnet/security group, with USDN tags applied via ec2:CreateTags.
• Lifecycle management — poll instance status, terminate from the portal, and auto-register the booted device with the controller.

What you supply once: an OIDC Identity Provider in your AWS account pointing at the USDN issuer, and an IAM role whose trust policy pins sub=usdn-deploy-<org_id> and aud=cloud-federation.

→ Step-by-step setup: AWS IAM Setup with OIDC Federation

Microsoft Azure

Status: Onboarding & discovery only — device deploy is in development

Azure integration uses Workload Identity Federation with an Azure AD App Registration. Today the portal supports:

• Account onboarding — supply tenant ID, subscription ID, and client (application) ID. No client secret is stored.
• Connection test — Azure SDK ClientAssertionCredential against the federated app, plus a Resource Manager probe to confirm the Reader RBAC assignment.
• Resource discovery — resource groups, virtual networks, subnets, and network security groups are listed for the deploy wizard.

The Azure deploy wizard currently shows a "Deploy coming soon" panel; image listing and the launch lifecycle are deliberately short-circuited at the API layer with a clear status message until the next release.

What you supply once: an App Registration with a Federated Credential (subject = usdn-cloud-deploy, audience = api://AzureADTokenExchange, issuer = USDN OIDC URL) and the Reader role assignment scoped to the subscription you want USDN to discover.

→ Step-by-step setup: Azure Workload Identity Federation Setup

Google Cloud Platform (GCP)

Status: Roadmap

GCP integration is on the roadmap but is not currently available. When delivered it will follow the same pattern: a one-time Workload Identity Pool/Provider in your GCP project, a service account bound to it, and portal-driven discovery and deploy. There is no current manual deployment path supported through the portal.

Working with Linked Cloud Accounts

After an account shows Connected, the Cloud Accounts page exposes the day-to-day operations operators care about:

Action	What it does	Provider availability
Validate	Re-runs the federation handshake against the cloud IAM and updates the account status. Triggered automatically when you rotate identity fields.	AWS, Azure
Discover	Re-fetches VPCs/VNets, subnets, security groups/NSGs, and (Azure) resource groups. Used by the deploy wizard.	AWS, Azure
Deploy	Opens the deploy wizard: pick site, region, AMI, instance type, network placement, and launch.	AWS only
Track deployments	Live status updates from Pending → Launching → Running → Provisioning → Completed. Failures surface with the underlying provider error.	AWS only
Terminate	Tears down the instance from the portal and marks the device as decommissioned.	AWS only
Unlink	Removes the cloud account record. The customer-side IAM role / App Registration is not deleted automatically — revoke it on the cloud side as well.	AWS, Azure

Security Posture

The integration was designed around a few non-negotiables:

1. No long-lived secrets on the platform. USDN does not store cloud access keys, client secrets, or ExternalId values. Every cloud API call is preceded by a fresh JWT mint and a credential exchange against the cloud's STS/Azure AD endpoint.
2. Per-organization subject pinning. The JWT sub claim embeds your USDN organization ID (usdn-deploy-<org_id> for AWS, usdn-cloud-deploy matched against your federated credential subject for Azure). The cloud-side trust policy must pin this exact value, which prevents one USDN organization from assuming another organization's role.
3. Public JWKS, no callback. The cloud provider verifies JWTs by pulling our JWKS over public HTTPS — there is no inbound webhook from the cloud back into USDN that could be tampered with.
4. Least-privilege deploy policies. The setup guides ship with policies scoped to EC2 lifecycle + describe operations and resource-group/network read for Azure. We do not require admin or write-everything roles.
5. Auditable session names. AWS sessions are named usdn-deploy-<account-id> so they're easy to filter in CloudTrail; Azure assertions log against the federated credential's app ID.
6. Revocation on the customer side. Removing the OIDC IdP (AWS) or the federated credential (Azure) immediately severs USDN's access — no support ticket required. See the per-provider setup guides for the exact CLI commands.

Best Practices

Account hygiene

• Use a dedicated cloud account or subscription for USDN-managed devices when possible. It keeps blast radius small and makes cost attribution trivial.
• Tag the IAM role / App Registration with purpose=usdn-cloud-integration so future cloud admins know what it's for.
• Rotate the role/app-registration name when offboarding old USDN organizations rather than reusing the same IAM resource across tenants.

Region & placement

• Pick the cloud region that's closest to the on-prem site the device will tunnel back to.
• Deploy AdWanOS devices into a public subnet with a route to the internet gateway/NAT — they need outbound HTTPS to reach the controller. Application workloads stay in private subnets.
• Use the discovery results in the deploy wizard to pick the correct VPC/VNet — it will only show networks the federated role can describe.

Cost

• Right-size the instance type for your throughput target. The deploy wizard surfaces recommended sizes for the AdWanOS Marketplace AMI.
• Terminate test deployments from the portal — leaving them running incurs the same hourly cost as any other EC2 instance/Azure VM.
• Use cloud-native cost tags (USDN tags every instance with the deploying organization) for cost allocation.

Roadmap

Short-term (this cycle):

• Azure VM deploy + lifecycle parity with AWS (image catalog, launch, poll, terminate).
• Azure Marketplace listing for the AdWanOS image.

Mid-term:

• GCP Workload Identity Federation onboarding, discovery, and deploy.
• Cross-cloud overlay templates for common hybrid topologies.
• Bulk device deploy from the portal.

Longer-term:

• Additional providers (Oracle Cloud, IBM Cloud) as customer demand surfaces.
• Cloud-native auto-scaling pools of AdWanOS devices.
• Marketplace billing integration for consolidated cloud + USDN invoicing.

Related Guides

• AWS IAM Setup with OIDC Federation — full step-by-step for the AWS path.
• Azure Workload Identity Federation Setup — full step-by-step for the Azure path.