Most companies have now embraced the hybrid workforce concept, despite the the recent push for return-to-office, there are still more people working from home than before the pandemic. You’ve got employees at home, in offices, on the road, plus contractors and vendors dipping into your systems from every timezone and coffee shop on the planet.

Underneath all of that, the core problem barely changes: people need to reach internal applications, servers, and data from untrusted networks and devices, and you need to let them do it without turning your VPN into a giant “allow everything” tunnel.

Modern guidance like NIST’s Zero Trust Architecture and the usual ZTNA playbooks all give the same advice: stop trusting the network. Start making decisions on identity, device state, and context for each access attempt. This piece sticks to patterns that are cloud agnostic and then shows how they map to commercial providers such as AWS and Azure.

Remember, don’t drink the koolaid from any vendor, design for capability first, then pick the product.

What people actually need to reach

If you strip away all the vendor names, the remote-access story is surprisingly boring. People want to reach a small number of things.

They need internal web apps: admin portals, dashboards, line-of-business tools, approval systems. They need shells and consoles for servers and containers: SSH or RDP into compute, kubectl into clusters, remote PowerShell or bash. They need access to data platforms: databases, data warehouses, object storage buckets and data lakes. Some users need full desktops and heavy tools: Windows desktops with Office and Teams, IDEs close to the code and data, CAD and design tools, trading platforms. On top of that you have the control planes: cloud consoles, CI/CD systems, identity providers, ticketing, CRM. Finally, there are third parties such as vendors, auditors, support engineers who need carefully scoped access to some of the above.

The interesting part isn’t whether you “have a VPN”. The interesting part is where you place the trust boundary for each of these categories.

Four patterns for remote access

Almost every remote-access design ends up as a blend of four basic patterns:

1. Network-centric: “let the user onto the network”.
2. Application-centric: “let the user reach this application”.
3. Host-centric: “let the user onto this box”.
4. Desktop-centric: “let the user into this desktop”.

The technology logos change, but these four ideas keep repeating.

Network-centric: VPN done deliberately

In the classic model, users establish an encrypted tunnel into a private network and, once they’re “inside”, routing and firewall rules decide what they can talk to.

On AWS this usually means AWS Client VPN or a site-to-site VPN landing in one or more VPCs, often hanging off a Transit Gateway. On Azure it’s typically Azure VPN Gateway, with point-to-site connections for users and site-to-site links for branch offices and data centres.

This pattern still has a place. It works well when you’ve got a lot of “traditional” workloads that assume IP-level reachability, or when developers and admins need a wide range of ports and protocols such as SSH, RDP, database ports, message queues, internal APIs, without wrapping every single one in a custom front door. It’s also something you can deploy quickly if you’re early in your zero-trust journey.

The obvious downside is blast radius. If the VPN profile is broad and a laptop is compromised, an attacker suddenly has a large slice of the internal network to explore. That’s why both AWS and Azure now frame VPN as one tool among many, rather than the answer to everything.

If you’re going to lean on this pattern, treat VPN access as high-risk access. Terminate authentication at your corporate IdP so that strong auth and MFA are non-negotiable. Scope profiles to specific networks and subnets for each group rather than “any VPC” or “any VNet”. Push all VPN logs into your SIEM and line them up against identity events and endpoint telemetry so you can see suspicious patterns quickly.

Application-centric: identity-aware front doors

Application-centric access flips the model around. Instead of dropping users onto a network and hoping security groups save you, you put an identity-aware service in front of specific applications. That service looks at who the user is, what device they’re on, where they’re coming from, and then decides whether to let them talk to that app at all. That’s the essence of Zero Trust Network Access.

On AWS, the centrepiece is AWS Verified Access. It gives you VPN-less access to internal web apps and, increasingly, to arbitrary TCP services like SSH and RDP, with policies based on user identity and device context. On Azure, the comparable story is Microsoft Entra Private Access, part of the Entra Suite / Global Secure Access stack. It sits between users and private apps, applies Conditional Access policies (MFA, device compliance, risk signals), and is positioned very explicitly as the thing you should use instead of a big flat VPN.

For regular employees using internal web apps, this is normally where you want to end up. Users open a browser, hit an SSO portal or the app URL directly, and get in if their identity, device, and risk level all look acceptable. There’s no need for a full-tunnel VPN for 90% of office work, and you get clean, app-level logs tied directly to identities and devices.

Host-centric: privileged access without open SSH/RDP

Operators, SREs and DBAs often care less about “the app” and more about “the box”. Host-centric access is about giving them SSH, RDP and command-line control, but through a broker that enforces strong identity and leaves an audit trail.

On AWS you usually reach for two things. Systems Manager Session Manager uses an agent on EC2 instances to give you shell sessions from the console or CLI with no inbound SSH port at all, commands and sessions can feed into CloudWatch Logs or S3 for review. EC2 Instance Connect handles just-in-time SSH keys tied to IAM identities instead of long-lived key pairs.

Azure’s closest match is Azure Bastion. It’s a managed jump host that lets you RDP or SSH into machines over TLS straight from the Azure portal or your usual clients, without assigning public IPs to those VMs. In both environments you can also layer traditional PAM tools on top if you want password vaults, approvals and full session recording.

This pattern is the right one for production servers, databases and network appliances where you care about every admin action. It’s also a good way to avoid the old habit of “SSH from my laptop over the VPN straight into prod”. The normal path for engineers should be via Session Manager, Bastion or your chosen PAM gateway, always with MFA and short-lived elevation.

Desktop-centric: move the user to the data

Sometimes the most robust answer is not to give users direct access to networks or apps at all, but to give them a hosted desktop and keep the data there.

AWS offers the Amazon WorkSpaces family for full desktops and AppStream 2.0 for application streaming. Azure offers Azure Virtual Desktop, which delivers Windows desktops and published apps from Azure to almost any device. Both platforms support multi-session Windows, integrate neatly with Microsoft 365, and can place desktops close to cloud-resident data so that heavy workloads feel snappy.

This pattern is particularly useful when you’ve got highly sensitive data and want to avoid it ever landing on endpoints, when you need to support untrusted or bring-your-own devices, or when users need high-performance desktops near large datasets. Analysts, traders, engineers with GPU workloads and outsourced teams are all common candidates.

Microsoft is also nudging customers towards its new Windows client app for connecting to Azure Virtual Desktop and cloud PCs, replacing the older Store Remote Desktop client, so any new AVD design should assume that direction of travel.

Foundations that matter more than the logo

Everything above describes ways of connecting. To make any of it sane at scale you need some shared foundations, no matter whose logo appears on the slide.

Identity needs to be the real control plane. In most organisations that means Entra ID as the corporate directory, even if half the workloads live on AWS. If you’re using Okta, Ping or something similar, wire that into IAM Identity Center and Azure as the single place where users, groups and roles live. VPNs, ZTNA, Bastion, Session Manager, cloud consoles and SaaS apps should all front-door through that IdP with MFA. Local accounts, static SSH keys and app-local user databases should be on a strict deprecation plan.

Device posture has to become a first-class signal rather than an afterthought. Entra Conditional Access already looks at compliance state, risk, location and more. Entra Private Access reuses exactly those signals for private apps. Verified Access on AWS leans on integrations with device-management and security tooling to decide whether a device is “trusted enough” to reach a resource. To take advantage of that, you need basic hygiene in place: an MDM/EMM platform to enforce encryption and OS baselines, EDR/XDR on corporate endpoints, and a way to feed device signals into Conditional Access and Verified Access policies.

Finally, you need to see what is actually happening. Remote access is a prime target in almost every intrusion, so VPN logs, ZTNA events, Bastion and Session Manager logs, desktop connection logs and IdP events should all land in a central logging or SIEM platform. Build simple but specific detections: impossible travel, sudden explosions in group membership, mass policy changes, unusual admin flows. Then test your incident-response playbooks specifically around “compromised remote account or device” rather than just generic “malware on a server”.

A realistic end state

A realistic target architecture on either AWS or Azure usually looks like this.

Most everyday internal web apps are fronted by SSO plus an application-centric access layer, Verified Access for apps living on AWS, Entra Private Access for apps in Azure and on-prem. A VPN still exists but is reserved for legacy protocols and edge cases, not as the default path for everybody.

Servers and infrastructure are reached through host-centric tools: Session Manager and EC2 Instance Connect on AWS, Azure Bastion on Azure, with public SSH/RDP turned off by default. Sensitive operations go through PAM workflows, and admin sessions are logged.

Users who deal with especially sensitive data or who work from untrusted devices use virtual desktops: Azure Virtual Desktop or Amazon WorkSpaces, depending on where the data lives, with access to that data restricted to those desktops rather than to laptops.

Vendors and third parties do not get broad VPN profiles by default. They get narrow, time-bound application- or host-centric access with strong logging i.e. segments and profiles in Entra Private Access, Verified Access, Bastion and Session Manager.

The product names change between AWS and Azure, but the architecture patterns and security principles stay the same. Once you frame the problem in terms of where you put trust and how you make access decisions, the choice of cloud provider becomes an implementation detail rather than the whole story.