AWS VPN Client 6.0 lost profiles on upgrade, and three versions shipped in nine days

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

What changed in AWS VPN Client version 6.0?

Version 6.0.0 added a command-line interface and enterprise administrative controls, redesigned the graphical interface, rebuilt connectivity on OpenVPN3 for faster connection establishment, and relocated configuration files to a system-wide admin-protected location. AWS announced the release on 13 August 2026, after the first build shipped on 4 August 2026.

Why did VPN profiles disappear after upgrading to 6.0?

Version 6.0 stores configuration data in a new system-wide location. On first launch the client tries to migrate profiles and preferences from the old location automatically, and AWS documents that this migration can fail. The original .ovpn files are not deleted, but the fix is to download and re-import a fresh endpoint configuration file.

Which AWS VPN Client version should we deploy?

On Windows and macOS, 6.0.2, released 12 August 2026 and 18 August 2026 respectively. On Linux the newest build is 6.0.1, released 12 August 2026, which does not include the profile migration fix that 6.0.2 carries on the other two platforms. AWS recommends the latest version for every platform.

Does AWS VPN Client update itself?

No. The Windows client page states that the AWS provided client does not support automatic updates. With 6.0.0, 6.0.1 and 6.0.2 all released between 4 and 12 August 2026, every build has to be pushed through your own endpoint management tooling, and any machine upgraded early stays on the older defect until you push again.

Is Windows 10 still supported?

The requirements page lists only Windows 11 for both x64 and Arm64, along with .NET Framework 4.7.2 or 4.8.1. The troubleshooting page in the same guide still describes a crash affecting Dell PCs running Windows 10 or 11. AWS has not resolved that contradiction publicly, so test before deploying to Windows 10.

What can the aws-vpn-client CLI do?

It supports eleven commands: connect, disconnect, delete-profile, import-profile, list-profiles, get-config, put-preference, list-preferences, get-connection-status, list-connections and send-diagnostic-logs. The connect command takes a profile name and returns a JSON status object, which makes scripted VPN establishment possible inside automation without third-party tooling.

Is passing credentials to the CLI safe?

The connect command's optional auth-user-pass flag reads a file holding the username on line one, password on line two and an optional MFA code on line three. That is plaintext on disk. Source it from a secrets manager at run time, write it to a temporary in-memory path, and delete it after the connection is established.

Do Client VPN endpoints need changes for version 6?

No. AWS states the rebuilt client from v6.0 onwards maintains full backward compatibility with existing AWS Client VPN endpoints and that no endpoint changes are required. There is also no pricing change, with no additional charges beyond standard AWS Client VPN pricing. All the work sits on the desktop side.

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

1. AWS Client VPN now supports CLI, administration controls, and faster connections, AWS What's New, 13 August 2026
2. Document history for the AWS Client VPN User Guide, AWS
3. AWS Client VPN for Windows release notes, AWS
4. AWS Client VPN for macOS release notes, AWS
5. AWS Client VPN for Linux release notes, AWS
6. AWS Client VPN for Windows, requirements, AWS
7. AWS Client VPN for macOS, requirements, AWS
8. AWS Client VPN for Linux, requirements, AWS
9. Install the AWS provided client for Linux, AWS
10. CLI command syntax, AWS Client VPN User Guide
11. Troubleshooting the AWS provided client for Windows, AWS
12. Getting started with AWS Client VPN, AWS

Last updated: 22 August 2026.