Amazon WorkLink was an AWS service designed to let employees view internal corporate websites from mobile devices without giving each device an ordinary full-network VPN connection. AWS launched it in January 2019 and ended the service on November 30, 2021. The former product is not an option for a new deployment in 2026. Its architecture is nevertheless useful for understanding the design of controlled mobile web access and why security teams separate presentation of data from access to the internal network.
The original product addressed a concrete business tension. Employees wanted to use a phone to read an intranet page or business application, while administrators wanted to avoid exposing internal sites, creating unmanaged data copies or handing a personally owned device unrestricted connectivity. WorkLink took a browser-based approach rather than assuming every internal resource required device-wide network access.
The problem traditional remote access did not always solve well
A traditional VPN can establish a protected network path, but once connected the device may gain more network reachability than the business application actually requires. This is a design problem, not an assertion that VPN encryption is unsafe. Network scope, user identity and application authorization should each be bounded to the legitimate task.
Mobile device management can establish security requirements such as encryption, screen lock and approved applications, but not every company can manage every personally owned handset. WorkLink aimed at a narrower use case: the user needed a browser view of selected internal content, while the company wanted controls around where page data was rendered.
The service did not replace every internal application protocol. A web page displayed on a phone is different from an SSH client, a database connection or a desktop program requiring full network access. Architects must understand which workflows are genuinely browser-based before proposing a secure browser model.
How WorkLink presented internal web applications
WorkLink connected an authorized user to configured corporate web applications and rendered content remotely, presenting a controlled view on the mobile device. The historical description involved delivering graphical or vector-style output instead of simply copying the original website assets and granting the phone direct internal-network access.
That approach can reduce some forms of local data exposure, but it does not automatically prevent every screenshot, camera capture or misuse of information. A secure presentation channel still depends on identity verification, backend application authorization, session controls, monitoring and the trustworthiness of the remote rendering service.
For example, an employee opening an internal procurement dashboard should see only the transactions allowed by their business role. Even if the page is rendered remotely, a compromised or overprivileged application account could still reveal confidential procurement information. Rendering location is not a substitute for application access control.
Authentication and policy decisions were still important
Controlled web access requires a way to identify users and decide which corporate sites they may open. WorkLink’s historical integration with enterprise identity and access decisions was part of its value proposition. The organization still needed to define eligible groups, review access and withdraw permissions promptly after employment or project status changed.
A contractor’s session provides a useful threat model. The consultant might be authorized to read an intranet document for three weeks, but must not see payroll resources or keep the same access after the contract ends. Secure browser delivery must be combined with appropriate application authorization, session termination and documented owner approval.
Device posture may also matter. A company could restrict access from devices that lack required protections, but it should avoid relying on a signal it cannot verify for the particular mobile platform. Strong MFA and device controls can support each other; neither automatically addresses excessive permissions inside an application.
Benefits and limitations of the original service
The primary potential benefit was reduced friction for viewing web-based internal resources on supported mobile devices. Employees did not necessarily need a complex per-app VPN configuration before opening the authorized content. Administrators could reduce some network exposure and centralize selected access policies.
The model also created dependencies: a supported browser or client experience, availability of the rendering service, connectivity to corporate applications, authentication and organizational policy. Latency or rendering fidelity could affect interactive pages. The business still needed a fallback when the service or identity integration was unavailable.
The economic case was not universal. Charging and service design depended on the historical product’s terms, expected users and traffic, while operational costs included identity integration, support and security review. An archived promotional comparison should not be used to claim that WorkLink remains a cheaper or faster option than all current secure-access products.
What retirement changed
AWS confirms that Amazon WorkLink was fully shut down on November 30, 2021. Its older mobile app, admin instructions and provisioning guidance should not be used to start a new service. A reader encountering a step-by-step WorkLink tutorial needs to treat the steps as a historical description of the architecture.
AWS originally suggested Amazon WorkSpaces Web, subsequently called Amazon WorkSpaces Secure Browser, for remotely rendered browser sessions after WorkLink closed. AWS announced that WorkSpaces Secure Browser would close to new customers on October 29, 2026, although existing customers may continue using it. WorkLink was already shut down in 2021, so neither service should be promoted as a new-customer replacement on this date. Availability and service eligibility must be verified before new deployment plans are made.
For customers seeking another AWS-hosted browser isolation option, AWS identifies Amazon WorkSpaces Applications with a self-managed Chrome image as a possible migration route. That approach requires its own browser administration, IAM, VPC, policy and cost assessment. A remote browser, zero-trust network access service and a VPN do not necessarily support the same application protocols or data-control requirements.
Migration planning should inventory which internal sites users accessed, how authentication worked, what logging and retention were required, and whether workflows depended on clipboard access, file downloads or local browser features. Choosing an alternative based only on its screenshot isolation claim could disrupt essential work.
How to design a supported secure web-access solution
Begin by naming the application protocols, audience, authentication method and allowed resources. Classify the information being presented. Decide whether users need remote browser interaction or broader network connectivity. For a replacement deployed in AWS, evaluate the private paths and AWS security group boundaries between the browser environment and internal applications. Choose a supported solution by verified protocol, identity, data-control and policy requirements rather than by brand similarity.
Test an employee and an external partner with different permissions. Confirm that both authenticate appropriately, only see authorized sites, and lose access when group membership or the business relationship changes. Measure page performance and verify how downloads, printing or copy operations behave under policy.
Finally, establish operational response: who investigates unusual access, how the team revokes a compromised session, which logs provide evidence and how employees continue critical work during an outage. A secure browser product is useful only when it fits those administrative and business processes.
Browser isolation does not automatically define data rights. An organization might prevent a device from downloading a file yet still show a user information the person should never have been permitted to view. Authorization rules at the application and document level must be enforced independently from the presentation technology.
Threat modeling should also consider credential theft, stolen devices, malicious browser extensions, screen capture and exposure of the remote rendering platform. Not every threat can be eliminated by remote rendering. Document which risk is reduced, which continues to require endpoint controls and which is transferred to a vendor-controlled service.
During a transition away from a retired access service, test the workflow with actual roles and mobile devices rather than only an administrator account. Confirm accessibility, input methods, authentication prompts, session timeout, large pages and attachment behavior. Security measures that make a critical task impossible will create pressure for uncontrolled workarounds.
Why WorkLink remains a useful case study
WorkLink demonstrates an architectural principle that outlives the product: access can be limited to an application presentation surface rather than extended to an entire corporate network. The benefit is meaningful only when identity, application permissions, device controls, logging and recovery have been considered together.
Use historic WorkLink material to understand that trade-off, not as an invitation to create a retired AWS service. A contemporary implementation must be built on currently supported technology with verified features and a defined exit plan.