AWS has begun a two-service lifecycle change that is easy to misread as a shutdown. Starting October 29, 2026, new customers can no longer onboard to Amazon WorkSpaces Secure Browser or the Amazon Chime SDK SIP Media Application. Existing customers can continue using both services, and AWS says it will keep operating and supporting them. The immediate risk is therefore not an outage. It is discovering too late that a planned rollout, a new account, or a customer deployment depends on a service that has stopped accepting new users.

IT professionals review cloud service lifecycle dashboards and maintenance planning in an enterprise operations center.

AWS announced the change on September 29 in its service availability update. The company classified both products as moving to maintenance rather than announcing an end-of-support date. That distinction matters: maintenance mode preserves existing service access, but it also freezes the platform’s position in a way that changes the decision for anyone designing a new architecture today.

What changes on October 29

The AWS announcement lists two services moving to maintenance:

  • Amazon Chime SDK SIP Media Application
  • Amazon WorkSpaces Secure Browser

AWS’s wording says services in this category will no longer be accessible to new customers from October 29. Existing customers can continue using the services, and AWS will continue to operate and support them. The announcement does not say that existing environments will be disabled on the date, nor does it publish a mandatory migration deadline for either service.

That gives the change three practical consequences.

First, an organization that already has an active deployment is not facing a same-day cutover. Its current call flows or browser environments should continue to operate under the maintenance policy. Second, a team that has never enabled the service may lose the ability to start using it after the cutoff. Third, an enterprise that is already a customer may still need to check whether every account, region, subsidiary, and partner-managed environment is covered by that existing status.

The third point is where a lifecycle announcement becomes an operational issue. Large organizations often create new AWS accounts for business units, acquisitions, regulated workloads, development environments, or customer-specific deployments. A service that works in the original account may not be available for a new account created after the cutoff. AWS’s public notice does not remove the need to verify that boundary directly with the account team or AWS Support.

WorkSpaces Secure Browser: existing access remains, new rollout plans change

WorkSpaces Secure Browser is a managed remote-browser service. It gives users access to private websites, SaaS applications, and the public internet through a browser session running in AWS. The browser renders remotely and streams encrypted pixels to the user’s local device, while administrators apply policy to the remote session. AWS describes the service as a way to provide protected browsing without requiring IT teams to manage specialized client software, dedicated browser infrastructure, or a traditional VPN for every use case.

The service is relevant to organizations that provide controlled access to internal web applications for contractors, vendors, temporary staff, distributed teams, or users working from unmanaged devices. It can also be used to isolate browsing activity from the endpoint. The important architectural feature is not simply that the browser is in the cloud; it is that the endpoint receives a streamed session rather than running the protected browser workload locally.

AWS’s availability-change documentation says existing customers can continue to use WorkSpaces Secure Browser as normal. It also points to alternative approaches, including Amazon WorkSpaces Applications with a self-managed Chrome image. AWS describes that option as providing the same pixel-streaming isolation model, but it changes the operating model because the customer becomes responsible for managing the browser image.

That difference is easy to understate. A managed secure-browser service and a virtual application environment with a customer-managed Chrome image may deliver similar user-facing isolation, but they do not have identical administration, patching, image distribution, policy, monitoring, or cost characteristics. A migration assessment should therefore compare the controls and ownership model, not just ask whether the replacement can open the same websites.

Teams planning to use WorkSpaces Secure Browser for a new contractor program or a new business unit should treat October 29 as a provisioning boundary. If the service is a firm requirement, the organization needs to confirm whether the necessary customer relationship and service enablement are already in place before the cutoff. If the service is only one candidate in a broader remote-access design, the maintenance announcement is a reason to compare alternatives before building workflows around it.

Chime SDK SIP Media Application: a telephony migration concern

The second affected service has a different audience. The Amazon Chime SDK SIP Media Application capability, described in AWS documentation as the PSTN Audio service, lets developers build programmable voice applications that interact with telephone calls. A typical deployment can connect telephony events to application logic, including call routing, interactive voice response, call recording, or other workflows built around SIP and AWS Lambda integrations.

AWS’s service documentation says the PSTN Audio service entered maintenance mode on September 29, 2026. The documentation states that new feature development stops in maintenance mode, while AWS continues to provide bug fixes, security updates, and operational support for existing customers. From October 29, new customers cannot onboard. Existing call flows, Lambda integrations, SIP media applications, and phone-number assignments are described as remaining functional.

AWS recommends Amazon Connect Customer for similar telephony workloads and points to capabilities such as visual flow design, managed compliance, analytics, and AI-supported customer engagement. That recommendation should be read as a direction for future architecture, not as evidence that every existing Chime implementation can be moved by changing one API endpoint.

A telephony migration usually involves more than application code. Teams need to account for phone-number ownership, carrier relationships, geographic availability, emergency calling requirements, recording and retention policies, call authentication, compliance controls, latency, failure routing, and the behavior of integrations that consume call events. A workflow that appears simple in a diagram can have operational dependencies in contact-center systems, CRM platforms, identity services, monitoring, billing, and customer-support procedures.

The Chime SDK documentation also describes an exception process for customers using PSTN Audio only for Chime SDK Meetings dial-in or dial-out, or for programmatic outbound calling with DTMF for PSTN testing. AWS says those customers may request access through AWS Support, using the reference “PSTN Audio Maintenance Mode Exception.” That is a narrow exception path, not a general extension for new production deployments. Teams relying on it should document the exact use case and obtain written confirmation rather than assuming that a test workload qualifies.

Maintenance mode is not the same as end of support

The most important distinction in the announcement is between maintenance and sunset.

For the two services in this article, AWS has announced a restriction on new customers but not a final date when existing customers must leave. Maintenance means the service remains available to its existing base, with ongoing operational support and security fixes, but the product is no longer an open-ended choice for new adoption. AWS has not promised that the services will receive the same feature investment as an actively expanding product, and the Chime SDK documentation explicitly says new feature requests will no longer be considered.

The same September 29 AWS announcement lists other lifecycle events with different implications. Amazon Managed Blockchain and Amazon DevOps Guru are listed as entering sunset with support dates in September 2027. AWS Infrastructure Composer’s standalone console is listed with an end-of-support date of December 7, 2026. Amazon Mechanical Turk is listed as having reached end of support. Those entries should not be mixed with the WorkSpaces Secure Browser and Chime SDK change: their deadlines and migration obligations differ.

This distinction is useful when communicating internally. Saying “AWS is shutting down WorkSpaces Secure Browser today” is inaccurate. Saying “nothing changes” is also inaccurate. The correct operational statement is that new customer onboarding closes on October 29, existing service use continues, and new designs should be reviewed against AWS’s stated maintenance status and the available alternatives.

Who is affected

The directly affected groups are broader than the administrators who click the service enablement button.

Platform teams are affected because account vending and landing-zone processes may create environments that cannot activate the service after the deadline. They should identify whether service availability is part of an account template, a standard catalog item, or an automated provisioning workflow.

Security and endpoint teams are affected if WorkSpaces Secure Browser is part of a contractor-access or unmanaged-device control. They need to understand whether a replacement preserves remote rendering, browser isolation, data-loss controls, identity enforcement, session recording, and administrative visibility.

Contact-center and application teams are affected if Chime SDK SIP Media Application is embedded in voice applications. They need to identify the telephony functions that are implemented in code and the external systems that depend on them. A service inventory based only on AWS console ownership can miss customer-facing applications built by a systems integrator or a software vendor.

Procurement and vendor-management teams are affected because a service may be embedded in a third-party product. A vendor may already have an AWS account that qualifies as an existing customer, while the customer’s own account does not. Contract language, support responsibility, data location, and the vendor’s migration plan become relevant questions.

Architecture review boards are affected because a new design that selects a maintenance-mode product creates future optionality risk. It may still be defensible for a contained workload with a clear business reason, but the decision should be explicit and documented rather than hidden behind the label “AWS managed service.”

The checks IT teams should run now

The first task is an inventory, not a migration project. Search infrastructure-as-code repositories, AWS Organizations account metadata, service catalogs, billing records, CloudTrail activity, application configuration, and partner documentation for references to both services. For Chime, search for SIP media applications, PSTN Audio, phone-number assignments, Lambda integrations, and call-control flows. For WorkSpaces, look for browser portals, portal associations, user settings, network settings, policy objects, and automation that creates browser environments.

The inventory should record at least:

  • AWS account and region
  • Business owner and technical owner
  • Existing-customer status and date of first use
  • Production, test, and development environments
  • Dependent applications and third-party integrations
  • User or call volume
  • Data, recording, and retention requirements
  • Disaster-recovery and failover design
  • Planned expansion into new accounts or regions
  • Contractual or regulatory constraints

The second task is to separate existing use from planned use. An existing production deployment may be safe to keep in place for now, while a new regional rollout may be blocked. A proof of concept may not establish the same status as a paid production account. A partner’s deployment may not give the customer permission to assume that its own future account will qualify.

The third task is to confirm the boundary with AWS. AWS’s public pages explain the policy, but organizations should ask account teams or Support how the restriction applies to their specific account structure, consolidated billing arrangement, regions, and partner deployments. The question should be precise: can a particular existing customer create a new environment or add a new account after October 29, and under what conditions? Keep the response with the architecture record.

The fourth task is to freeze unreviewed new commitments. This does not mean stopping every project. It means requiring an architecture decision before a team chooses either service for a new workload. The decision should state why maintenance-mode adoption is acceptable, what the replacement path is, and what data or code would need to move if AWS later publishes an end date.

How to evaluate the WorkSpaces alternative

For WorkSpaces Secure Browser, compare the current service with the proposed alternative across the control plane and the user session.

Start with isolation. Confirm where browser processes run, what reaches the endpoint, whether clipboard and file transfer can be restricted, and how downloads are handled. Then examine image ownership. If a self-managed Chrome image is required, define who patches it, how quickly emergency browser fixes are deployed, and how a known-good image is promoted across environments.

Review identity and access separately from browser configuration. Check support for the organization’s identity provider, multifactor authentication, just-in-time access, session duration, contractor offboarding, and privileged access workflows. A remote browser that is technically isolated but weakly connected to identity governance does not solve the original access problem.

Finally, test the applications that motivated the design. Some internal sites depend on client certificates, private DNS, legacy authentication, browser extensions, local printing, or device posture signals. A replacement can match the pixel-streaming model and still fail because it handles one of those dependencies differently.

How to evaluate the Chime alternative

For Chime SDK SIP Media Application workloads, begin with a call-flow map. Record every inbound and outbound path, transfer, queue, prompt, recording, DTMF interaction, timeout, retry, and failure route. Mark which steps are handled by AWS, which run in Lambda, and which depend on external systems.

Then map the operational requirements. Identify number portability and ownership, regional calling rules, emergency services, recording consent, retention, encryption, redaction, speech or transcription processing, and support escalation. If the workload serves customers in multiple countries, validate the replacement against each country rather than treating “telephony support” as a single feature.

Run a small technical assessment with representative traffic. Measure call setup time, media behavior, integration latency, observability, failure recovery, and cost under realistic concurrency. A replacement that passes a demo but changes how failures are surfaced can create a support problem after launch.

Do not leave the migration plan at the level of “move to Amazon Connect.” Name the target service components, integration boundaries, test environment, cutover method, rollback approach, and owner. If the present workload is stable and AWS has not published an end date, the plan can be staged. It should still exist.

What the announcement says about cloud service selection

The broader lesson is about lifecycle risk rather than a single AWS product decision. Cloud services are often treated as permanent primitives because they are accessed through APIs and charged through a familiar account. In practice, they remain vendor products with changing investment levels, onboarding rules, support models, and replacement paths.

A service that is fully managed can reduce operating work while increasing dependence on the provider’s product roadmap. That is not automatically a reason to avoid managed services. It is a reason to record the exit conditions when selecting them. Teams should know which data they own, which configurations can be exported, which integrations are portable, which phone numbers or identities are difficult to move, and how long a replacement would take.

This is especially important for services that sit between infrastructure and business operations. A browser-isolation service affects access policy and user support. A programmable voice service affects customer contact and compliance. Their lifecycle status belongs in architecture and continuity reviews, not only in a vendor-news inbox.

For October 29, the practical conclusion is limited but clear: existing users do not need an emergency shutdown plan, while teams planning new deployments should stop treating these two AWS services as open-ended building blocks. Inventory them, confirm account eligibility, freeze unreviewed expansion, and begin a documented alternative assessment. That is enough to turn a quiet lifecycle notice into a manageable planning decision.