On this page · 11 sections
- What AWS announced, and what the release notes say
- Nine days, three versions, and no auto-update
- The requirements page quietly dropped Windows 10
- The CLI is real, and it wants a credentials file
- What the administrative controls actually change
- Who is affected, and how to tell
- India-specific considerations
- What is still unknown
- FAQ
- How eCorpIT can help
- References
Summary. AWS announced the rebuilt AWS VPN Client v6.0.x on 13 August 2026, with a CLI, enterprise administrative controls and an OpenVPN3 core. By that date the release had already been patched twice: 6.0.0 landed on 4 August 2026, 6.0.1 on 7 August fixed a SAML authentication fault that caused sporadic connection errors, and Windows 6.0.2 on 12 August fixed a TAP adapter name conflict. macOS did not get 6.0.2 until 18 August, five days after the announcement. The change that matters to whoever manages the fleet is in the 6.0.0 release notes, not the announcement: the client relocated its configuration files to a system-wide admin-protected location, and AWS documents a troubleshooting path for profiles that disappear when that migration fails. The client also does not support automatic updates, and the Windows requirements page now lists only Windows 11. The version it replaces, 5.4.3, dates from 23 July 2026, and AWS has published no end-of-support date for the 5.4.x line.
What AWS announced, and what the release notes say
The What's New post, dated 13 August 2026, describes three things: CLI support with "full feature parity with the GUI", administrative controls that let you "centralize VPN policy enforcement by scoping profiles to specific users", and a client "rebuilt with OpenVPN3, delivering faster connection establishment across all supported operating systems". It closes with a compatibility promise: "The rebuilt client v6.0 onwards maintains full backward compatibility with existing AWS Client VPN endpoints, so no endpoint changes are required."
That promise is about the endpoint. It is not about the desktop. The per-platform release notes are where the desktop-side change is recorded, and the 6.0.0 entry lists six items. Five are what you would expect. The sixth is not: "Relocated configuration files to a system-wide admin-protected location. If profiles or preferences are missing after the upgrade, see Profiles or preferences missing after upgrade to version 6.0 for resolution steps."
AWS shipped a troubleshooting page for that failure at the same time as the release, which tells you how likely it was considered. The Windows troubleshooting guide states the problem as "after upgrading the AWS provided client to version 6.0 or later, previously configured VPN profiles do not appear in the client, and preferences might be reset to their defaults," and the cause as "version 6.0 introduced a new architecture that stores configuration data in a new system-wide location. On first launch, the client attempts to automatically migrate profiles and preferences from the previous location, but this migration can fail in some cases."
The documented fix is not a repair. It is a re-import: download a fresh endpoint configuration file and add the profile again. On a fleet where users received their .ovpn file once, by email, eighteen months ago, that is a support ticket per user. The guide's own fallback line says so: "If you cannot locate your endpoint or do not have access to the self-service portal, contact your VPN administrator to obtain a new configuration file."
Nine days, three versions, and no auto-update
The AWS Client VPN User Guide document history gives exact dates for every build.
| Version | Windows | macOS | Linux | Fixed |
|---|---|---|---|---|
| 6.0.0 | 4 August 2026 | 4 August 2026 | not released | first 6.x build |
| 6.0.1 | 7 August 2026 | 7 August 2026 | 12 August 2026 | SAML authentication causing sporadic connection errors |
| 6.0.2 | 12 August 2026 | 18 August 2026 | not released | TAP adapter name conflict and duplicate profile names on migration |
| Announcement | 13 August 2026 | 13 August 2026 | 13 August 2026 | n/a |
Two things fall out of that table. Linux skipped 6.0.0 entirely and went straight to 6.0.1 on 12 August, so its first 6.x build already contained the SAML fix. Linux has no 6.0.2, which means the Linux release notes do not carry the migration fix that Windows got on 12 August and macOS got on 18 August. The macOS 6.0.2 entry describes it as "fixed profile migration issues that affected some users upgrading from pre-6.x to 6.x" — the same class of problem the troubleshooting page covers.
The second thing is the constraint that makes all of this expensive. The Windows client page states it in one line: "The AWS provided client does not support automatic updates."
Three builds in nine days, each fixing a defect in the last, on software that cannot update itself. Every one of those is a package push through Intune, Jamf, SCCM or apt, and a user who upgraded on 5 August is sitting on the SAML defect until somebody pushes again.
The requirements page quietly dropped Windows 10
This is the check to run before you schedule the rollout. The Windows requirements section now reads:
- Windows Arm64: Windows 11 (64-bit, Arm64 processor) and .NET Framework 4.8.1 or higher.
- Windows x64: Windows 11 (64-bit, x64 processor) and .NET Framework 4.7.2 or higher.
Windows 10 does not appear. The troubleshooting page in the same guide still carries a section titled "Client crash occurs on Dell PCs using Windows 10 or 11", describing a crash "on certain Dell PCs (desktop and laptop) that are running Windows 10 or 11" when browsing the file system to import a configuration file. So one page in the user guide treats Windows 10 as unsupported and another treats it as a live troubleshooting scenario. AWS has not published a statement resolving that, and the announcement says nothing about an operating system floor at all.
If any part of your estate is still on Windows 10, do not assume the announcement's "available today for Windows (x64/ARM)" covers you. Test one machine before the fleet push.
The full supported-platform picture across the three guides:
| Platform | Supported versions | Architecture | Package |
|---|---|---|---|
| Windows | Windows 11 only | x64 and Arm64 | .msi, needs .NET Framework 4.7.2 (x64) or 4.8.1 (Arm64) |
| macOS | Sonoma 14.0, Sequoia 15.0, Tahoe 26.0 | x86_64 and ARM64 | .pkg |
| Linux | Ubuntu 22.04, 24.04, 26.04 LTS | AMD64 only | awsvpnclient_amd64.deb or apt repository |
The announcement's phrasing was "Linux (x64)". The Linux requirements are narrower than that: three Ubuntu LTS releases, AMD64 only, and the install page offers a Debian package or an apt repository keyed to a CloudFront-hosted signing key. There is no RPM. RHEL, Amazon Linux and Fedora desktops are not on the list.
One more shared requirement that catches people running local development stacks: on all three platforms, for endpoints using SAML-based federated authentication, "the client reserves TCP ports 8096-8115 on your computer." Twenty ports, reserved on every developer laptop that uses SSO to reach the VPN.
The CLI is real, and it wants a credentials file
The CLI is the genuinely useful part of this release, and the command syntax page documents eleven commands under aws-vpn-client: connect, disconnect, delete-profile, import-profile, list-profiles, get-config, put-preference, list-preferences, get-connection-status, list-connections and send-diagnostic-logs. connect --profile-name "Production-VPN" returns {"status": "Connected"}. That is enough to put VPN establishment inside a CI runner or a bootstrap script, which previously needed third-party tooling.
Read the optional flag on connect carefully before you build around it. --auth-user-pass takes a "path to a file containing the username (line 1), password (line 2), and optional MFA code (line 3)."
That is a plaintext credentials file on disk, in a fixed line order, including the MFA code. It is the obvious way to script an unattended connection and it is the wrong way to store a corporate credential. If you automate this, source the file from a secrets manager at run time, write it to a tmpfs path, and delete it in a trap. Do not commit it, and do not bake it into an image. The same release that adds administrative controls to stop users sharing profiles will happily read a password off the filesystem.
The announcement also notes that "you can use both the GUI and CLI together as both run concurrently and VPN connections persist independently of either interface," which is what makes a scripted connect survive a GUI restart.
What the administrative controls actually change
Before 6.0, per the announcement, "you had to distribute VPN profiles among all users in your organization, which could be managed by any user without permissions." The new controls scope profiles to specific users, manage global profiles available to all users on a device, and enforce approved configurations. Combined with configuration files moving to an admin-protected system-wide location, the practical effect is that a standard user can no longer quietly edit or replace a VPN profile.
That is a real improvement to endpoint posture, and it is also the mechanism behind the migration failure. The files moved because the permissions model changed. You do not get one without the other.
Who is affected, and how to tell
You are exposed if you run AWS Client VPN with the AWS provided client on managed desktops and any of these hold: users self-upgraded to 6.0.0 between 4 and 7 August 2026 and hit the SAML fault; your Linux fleet is on 6.0.1 and therefore lacks the profile migration fix; your packaging pipeline pinned a 6.0.0 or 6.0.1 build; or your Windows estate includes Windows 10 machines.
You are not affected if you use a third-party OpenVPN client against the endpoint. Endpoint configuration is unchanged, and AWS states no endpoint changes are required. There is also no pricing change: the announcement states "there are no additional charges beyond standard pricing of AWS Client VPN."
The sequencing that avoids most of the pain is unglamorous. Pin 6.0.2 on Windows and macOS rather than "latest". Hold Linux at 6.0.1 and watch the Linux release notes for a 6.0.2. Before the push, have every user's endpoint configuration available through the self-service portal so a lost profile is a self-serve re-import rather than a ticket. Verify the .NET Framework floor on Arm64 devices, because 4.8.1 is higher than the x64 requirement. Then push once, not three times.
The migration is the work here, not the feature.
India-specific considerations
For Indian teams running distributed engineering across Gurugram, Bengaluru and Pune offices, the operational cost of this release is the fleet push, not the AWS bill. A managed desktop rebuild across a few hundred endpoints, coordinated with a support window for lost profiles, is realistically a ₹1,50,000 to ₹4,00,000 engagement in internal time at typical senior rates, against zero incremental AWS charge. Budget it as endpoint management work.
Where VPN access carries personal data, the move of configuration to an admin-protected location helps rather than hurts: profiles can no longer be copied between users on a shared machine without administrative rights, which is easier to defend under the Digital Personal Data Protection Act 2023 than the pre-6.0 model the announcement describes, where profiles "could be managed by any user without permissions". Note that diagnostic logs sent with send-diagnostic-logs go to AWS, so treat that command as a data egress step and get it approved before you script it.
What is still unknown
AWS has not published an end-of-support date for the 5.4.x line, so there is no documented deadline forcing the upgrade. The user guide does carry a standing note that "previous versions might be affected by usability or security issues" and recommends the latest version on every platform, which is guidance rather than a cliff. AWS has also not said whether Linux will receive a 6.0.2, nor clarified the Windows 10 contradiction between its requirements and troubleshooting pages. Both are worth rechecking against the release notes before a large rollout.
FAQ
How eCorpIT can help
eCorpIT plans and executes endpoint rollouts of this kind for distributed engineering teams, including packaging, version pinning across Windows, macOS and Ubuntu fleets, and the self-service configuration path that keeps a lost VPN profile from becoming a support ticket. We are a CMMI Level 5 and ISO 27001:2022 certified organisation with senior-led teams in Gurugram. If AWS VPN Client 6.0 is on your rollout list this quarter, talk to us before the first push.
References
- AWS Client VPN now supports CLI, administration controls, and faster connections, AWS What's New, 13 August 2026
- CLI command syntax, AWS Client VPN User Guide
Last updated: 22 August 2026.