How to Manage Chrome on AWS: Advanced Issues and Fixes
Fix Chrome cache growth in WorkSpaces Applications, check browser access requirements, and gather the right session and client diagnostics.
To stop Chrome’s local disk cache from filling the persistent settings VHD in Amazon WorkSpaces Applications, launch Chrome with a disk-cache directory outside the location intended to persist:
chrome.exe --disk-cache-dir C:\path-to-unsaved-location\This changes where Chrome writes its disk cache. AWS says the cache will not persist between streaming sessions when it is placed in an unsaved location. It does not move the rest of Chrome’s user data or disable persistence for the rest of the profile. First confirm the fleet image’s launch configuration and choose a destination that is not part of the persistent settings location. AWS documents this Chrome cache remedy.
1. Identify which AWS service is involved
“Chrome on AWS” can mean two different things: using a browser to connect to a streamed application or desktop, or troubleshooting a Chrome profile running inside that environment. Identify the service and connection path before applying a fix.
| Path | What to check |
|---|---|
| Amazon WorkSpaces Applications (formerly AppStream 2.0) | Browser requirements, streaming session behavior, and whether Chrome’s cache is filling the persistent settings VHD. |
| Amazon WorkSpaces Web Access | Whether the WorkSpace uses DCV or PCoIP, whether an administrator enabled web access, and the protocol’s browser and feature limits. |
Do not apply a browser support statement for WorkSpaces Applications to WorkSpaces Web Access: their requirements differ.
2. Fix Chrome cache growth in WorkSpaces Applications
Set a cache directory outside persistent settings
- On the fleet instance, identify how Chrome is launched and which user profile location is included in persistent application settings.
- Choose a writable cache directory outside the location intended to persist. Check the image’s directory layout and launch configuration before rolling out the change.
- Start Chrome with the documented flag, substituting the destination path appropriate for that image:
chrome.exe --disk-cache-dir C:\path-to-unsaved-location\ - Confirm that Chrome starts with the intended launch path and that the selected directory is outside the persistent settings location.
Chrome stores both user data and local disk cache in the Windows user profile by default. This option redirects the disk cache; it is not a general profile relocation setting. AWS specifically describes the cache as not persisting between streaming sessions when moved to an unsaved location. Decide whether that behavior is suitable for the fleet before deployment.
Choose the path based on persistence needs
- Cache should be temporary: use a writable location that is not saved with persistent application settings.
- Cache is intentionally retained: do not assume the documented unsaved-location remedy preserves it. Review the fleet’s persistence design and Chrome launch configuration.
- Profile data is the concern: the cache flag alone does not move user data. Diagnose profile persistence separately.
3. Check browser access and feature compatibility
WorkSpaces Applications browser streaming
AWS lists Chrome, Firefox, Safari, and Edge as supported HTML5 browsers and supports the three latest major versions. No browser extension or plugin is required for browser access. Drawing tablets are supported only with Chrome or Firefox. Webcam redirection for conferencing is supported on Chromium-based browsers, including Chrome and Edge. See the WorkSpaces Applications browser requirements.
If the problem affects one feature, check its specific browser requirement along with the browser’s major version. A browser can support streaming while a particular peripheral feature is unsupported.
WorkSpaces Web Access
First determine whether the WorkSpace uses DCV or PCoIP and confirm that an administrator enabled web access. AWS documents DCV web access for Windows and Linux WorkSpaces through supported browsers. PCoIP web access is Windows-only, is unavailable in some AWS Regions, and supports Chrome or Firefox on desktop systems. PCoIP browser access does not support multiple monitors or GPU-enabled WorkSpaces. AWS also warns that YUV444 encoding can cause login or rendering problems. Check the current WorkSpaces Web Access requirements against the actual protocol and environment.
When a connection or feature behaves differently across users, record the AWS service, protocol, client device and operating system, browser version, and affected feature. This narrows the issue to a supported boundary before changing Chrome settings.
4. Collect the right diagnostics
Find a WorkSpaces Applications streaming session ID
- Open browser developer tools during the affected streaming session.
- Open browser storage tools and locate session storage for
https://appstream2.<aws-region>.aws.amazon.com, substituting the applicable AWS Region. - Expand
sessionStorage.as2SessionData. - Read the
sessionIdkey and provide that identifier to the administrator investigating the session.
AWS describes this session-storage location in its WorkSpaces Applications browser troubleshooting guide. The session ID helps identify the streaming session; it is not a substitute for client logs.
Use client logs for client connection problems
When the connection itself is failing, enable advanced logging for the relevant WorkSpaces client and collect the platform-specific logs AWS documents. Include the exact error, timestamp and time zone, service and Region, protocol, client and browser versions, and whether the failure reproduces in another supported browser. Consult AWS’s WorkSpaces troubleshooting guidance for client logging and log locations.
Browser session storage and client logs answer different questions: the first provides a WorkSpaces Applications session identifier; the second helps diagnose the client connection. Keep both when the symptoms involve both streaming and the local client.
5. Understand client deployment settings
The WorkSpaces Applications client tutorial describes an Enterprise Deployment Tool, client installation files, a Group Policy administrative template, and StartURL and TrustedDomains registry settings. It also documents a DNS TXT record option for trusted domains. These settings customize the streaming client experience; they are not Chrome browser policies and do not replace the Chrome cache launch flag. See AWS’s client installation and customization tutorial.
6. Troubleshooting common failures
| Symptom | Likely cause | Action |
|---|---|---|
| Persistent settings VHD fills up | Chrome’s local disk cache is stored in the Windows user profile, which is included in persistent settings. | Review the fleet’s Chrome launch command and use the documented --disk-cache-dir flag with a writable location outside the persistent area if cache persistence is not required. |
| Chrome fails to start after adding the flag | The destination may be malformed, unavailable, or unwritable for the account launching Chrome. | Check the exact path, permissions, and launch configuration on the fleet image. Confirm the directory exists or can be created in the session. |
| Chrome settings still persist after redirecting cache | The flag redirects the cache only; it does not move all user data. | Review the profile and persistence configuration separately. Do not treat the cache setting as a profile relocation. |
| Browser streaming is unsupported or prompts for an update | The browser may be outside the three latest supported major versions. | Update Chrome or compare with another currently supported browser listed by AWS. |
| Drawing tablet does not work | WorkSpaces Applications drawing tablet support is limited to Chrome and Firefox. | Use a supported browser and confirm the client device and session meet the service requirements. |
| Webcam redirection is missing | The browser may not be Chromium-based, or the issue may be on a different service path. | For WorkSpaces Applications, check Chrome or Edge and verify the service and browser requirements. |
| WorkSpaces Web Access fails with PCoIP | The WorkSpace may use an unsupported OS, Region, browser, monitor setup, or GPU configuration, or web access may not be enabled. | Verify the PCoIP limitations and administrator setting. If YUV444 encoding is enabled, investigate it as a potential login or rendering cause. |
| Streaming issue cannot be correlated to a session | The administrator lacks the relevant WorkSpaces Applications session identifier. | Retrieve the sessionId from the regional AppStream browser session storage and share it through the normal support process. |
| Client connection problem is mistaken for a Chrome issue | Browser state and client connection diagnostics have been conflated. | Collect advanced WorkSpaces client logs and the browser session ID separately; compare reproduction across supported browsers. |
7. Performance, reliability, and cost considerations
The AWS-documented cache change is a storage and persistence choice: locating cache outside persistent settings prevents that cache from accumulating there across streaming sessions, but also means the cache is not retained between sessions. Do not assume this improves page speed or that every VHD growth problem comes from Chrome. Check the actual storage pattern and profile configuration.
For reliability, validate the launch command, destination permissions, browser version, service path, and feature requirements on the fleet image and client combination in scope before broad rollout. During an incident, capture the timestamp, Region, protocol, browser/client version, session ID when applicable, and relevant client logs so repeated failures can be compared.
The cited AWS remedies and diagnostic steps do not require purchasing a physical Chrome accessory or replacement part. No hardware purchase is needed to apply the documented cache configuration.
8. Capture a page screenshot while diagnosing
If you need a reproducible image of a page involved in a Chrome or streaming investigation, you can use a browser automation setup or a screenshot API. For a page that must be captured through your own browser session and configuration, retain the steps and environment details with the image.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server from ScreenshotNeo. One GET request returns a screenshot or PDF; the following cURL example saves a WebP screenshot. See the ScreenshotNeo API documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpCookie banners are accepted and removed before capture, along with supported consent platforms, newsletter popups, and chat widgets. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed. Its MCP server gives AI agents tools to take screenshots, inspect page information, and capture PDFs. The Free plan includes 1,000 screenshots a month without a card; paid plans start at $5 for 3,000 shots. This captures a public URL and does not reproduce an authenticated WorkSpaces session or replace AWS session diagnostics.
Sign up for ScreenshotNeo’s free plan: 1,000 screenshots a month, no card required.
9. FAQ
Does the cache flag erase or move Chrome bookmarks and settings?
The flag changes the disk cache directory. AWS does not describe it as moving Chrome’s user data or profile settings.
Can I use the same browser requirements for AppStream and WorkSpaces Web Access?
No. Confirm the service and protocol first; the supported browsers, operating systems, and feature limitations differ.
Do I need a browser extension for WorkSpaces Applications browser access?
AWS says no extension or plugin is required for browser access.
Is the session ID the same as the WorkSpaces client log?
No. The session ID is stored in browser session storage for WorkSpaces Applications. Client logs are separate diagnostics for connection troubleshooting.
