Per-session isolation in a shared VPC: how DeskBoot separates customers

Fair question we get from security-conscious customers: "If I'm sharing a VPC with other DeskBoot users, how is that safe?" Here's the answer at the level of detail we'd want if we were asking.

Yes, we share a VPC per region

Every DeskBoot customer session in us-east-1 lives in the same VPC. Same for af-south-1, eu-west-1, and every other region. This is standard SaaS practice — the alternative (one VPC per customer) would burn AWS's per-account limits (which cap VPCs per region) and add tens of seconds of provisioning latency for the same net security outcome.

Shared VPC ≠ shared network access. The isolation happens at the security group and subnet layer, not the VPC layer.

What actually isolates you

Per-session security groups. Every session you launch gets its own SG, created at launch, destroyed on terminate. Default posture: block all inbound and outbound except:

• RDP (3389) or SSH (22) inbound from 0.0.0.0/0 (so you can connect from anywhere), scoped to the specific port your OS uses
• Outbound to the internet gateway (so your session can browse)
• No inbound from any other customer's session
• No inbound from any private IP in the VPC

If your session tries to curl 10.x.x.x for another customer's private IP, the packet leaves your instance, hits the other instance's SG, and gets dropped there. There's no cross-customer trust in the SG rules.

Per-session KMS-encrypted disks. The EBS volume is encrypted with AWS-managed KMS keys. Even if someone snapshotted your volume (they can't — IAM prevents it), they'd need the KMS key to decrypt.

Per-session key pairs. Every session gets its own RSA key pair, created at launch, destroyed on terminate. Your session's SSH private key isn't stored, isn't shared, isn't recoverable — it's shown once on the credentials page, and if you lose it, you launch a new session.

No shared filesystems. DeskBoot doesn't attach EFS or shared NFS to any session. Each session has its own dedicated block-level EBS volume, mounted only on that session's EC2 instance.

What about the database?

Same isolation logic. RDS lives in the same VPC but in a separate, private subnet, with an SG that allows inbound only from the ECS task SG that runs the DeskBoot web app. No customer session SG can reach RDS. As of 2026-06-29, RDS also has no public IP — the whole thing is unreachable from outside the ECS task boundary.

What isn't in scope

Two things we don't currently do that some enterprise buyers ask about:

• Dedicated VPC per customer. Available as a custom option for large deployments; not standard.
• Customer-managed KMS keys (BYOK). On the roadmap. Currently AWS-managed keys.

If either matters for compliance, email <a href="mailto:security@deskboot.store">security@deskboot.store</a> and we can talk specifics.

The short version

Shared VPC, isolated at the security group + subnet + encryption layer. Every session is a network island; every session's disk is encrypted with its own key generation; nothing crosses between customers by default. Same pattern almost every major SaaS uses, applied deliberately.