AWS Elemental MediaStore has shut down, so it is no longer an available origin or storage option. For a simple live-video origin, AWS points customers to Amazon S3; for workflows needing DRM, ad insertion, cross-region failover or specific low-latency features, MediaPackage is the more appropriate direction.
The dates in AWS’s notices differ by a day: its General Reference lists 12 November 2025 as MediaStore’s end-of-support date, while its discontinuation announcement says customers could use it until 13 November 2025 and that capabilities would no longer be available after that date. Treat both statements as AWS’s distinct wording, not as evidence that the service remains usable.
MediaStore’s shutdown dates, carefully read
AWS’s General Reference table identifies 12 November 2025 as the end-of-support date for Elemental MediaStore. AWS’s earlier discontinuation announcement describes the customer-use window differently: active customers could continue using the service until 13 November 2025, after which service capabilities would no longer be available. The General Reference entry and AWS discontinuation announcement are the primary records to consult if you need to document the timeline.
That one-day wording difference matters when you are reconstructing an incident or explaining a delayed migration. It does not create a grace period now. The deadline has passed, and MediaStore should not appear in a current design as an option to restore, extend or newly configure.
AWS’s announcement said customers who had not retrieved data before the deadline, or had other questions, should contact AWS Support through their AWS account. That is not a promise that post-shutdown data access remains possible. If retained objects matter, ask Support about the account-specific situation rather than building a plan around presumed access.
A useful distinction is between live-origin objects and persistent data. Objects created as part of a live stream may have been temporary, with an encoder deleting them after a configured period or a lifecycle policy clearing them. Separately, some accounts may have used the service to retain objects they needed later. Those are different migration problems and should be inventoried separately.
Inventory the workflow that existed
Start with the flow of media, not the old service name. Draw a simple path from encoder or packager, through the origin, to the delivery layer and player. Record who writes each object, how manifests and segments are named, how clients request them, and which component deletes or replaces them. A design that merely stored persistent files may have very different needs from one serving live manifests to a large audience.
For each live channel, identify the protocols and output formats, the number of renditions, manifest update behaviour, retention policy and any authentication or cache rules. Note where encryption is applied and whether ads are inserted into the stream or its manifest. A viewer’s player compatibility is part of the workflow: a destination that accepts the same input is not necessarily a destination that produces the same output behaviour.
Then separate the requirements into essential and optional. Essential might mean the stream continues to reach the current player with the existing delay target and packaging format. Optional might mean changing the player or improving an operational process. Avoid quietly treating a migration as an opportunity to redesign the whole system unless you have time to test the additional changes.
Capture the operational details that are easy to miss in a diagram: object naming, cache-control headers, access policies, DNS names, certificates, monitoring alarms and who receives incident notifications. Include the publishing and playback endpoints in a controlled inventory, but do not put stream keys or credentials in a general-purpose document. The OBS-to-YouTube workflow guide illustrates why the source side and the destination workflow should be considered together, even when your AWS origin sits between them.
When AWS recommends S3
For a simple live-video origin without advanced packaging requirements, AWS recommends Amazon S3. AWS’s discontinuation post explains that S3’s strong read-after-write consistency, implemented in 2020, and improved tail-latency performance helped make it suitable for live-video origination. These are AWS’s reasons for its recommendation, not an independent benchmark for every workload or a guarantee about your viewers’ experience.
S3 is the conditional fit when your workflow chiefly needs an origin to hold and serve the objects your existing publishing and delivery design expects, and you do not depend on repackaging for DRM or ad insertion. You still need to validate how the encoder or publishing process writes and replaces manifests and segments, how requests are delivered and cached, and whether your target latency and request patterns work for the actual channel.
AWS also describes S3 as a lower-cost option for live-video origination than MediaStore, but the announcement provides no workload assumptions or numeric comparison. Do not turn that statement into a savings estimate for your own account. Compare the services using your traffic, storage, request pattern and delivery architecture, and check current AWS pricing before making a cost case.
S3 is not a universal drop-in replacement simply because both services can be part of an origin workflow. If your old design relied on features that transform, protect or repackage media at the origin, replacing the storage endpoint alone may leave that job undone. For a single-format stream with no such requirements, the simpler S3 path may reduce moving parts; test the resulting manifest and segment behaviour before cutover.
Keep the whole delivery path in view. Your origin is one component; a CDN or other delivery layer, player expectations and cache rules can affect the outcome. If the audience watches a continuous YouTube channel, also consider the publishing source and its restart behaviour; the guide to an always-on YouTube stream source covers that adjacent operational concern, but does not substitute for validating an AWS origin.
When AWS recommends MediaPackage
AWS points advanced workflows toward AWS Elemental MediaPackage, including workflows that require cross-region failover or specific low-latency requirements. MediaPackage is also the stronger direction when you need DRM or ad insertion that requires repackaging. The relevant question is not whether MediaPackage is more capable in the abstract; it is whether the particular capabilities your workflow depends on are available and configured for your output, region and player.
Repackaging changes what the origin delivers, rather than merely where objects are stored. With DRM, the packaging and encryption path must align with the supported player and entitlement arrangements. With ad insertion, manifest handling and the ad workflow need to fit together. Document these dependencies before migration, then check current AWS documentation for the precise feature and regional details that apply to your design.
Cross-region failover is also a design requirement, not just a box to tick. Specify which failures you need to tolerate, how the publishing path behaves during a regional problem, and what the player sees when delivery changes. A low-latency objective likewise needs a concrete definition for the audience and player; “low latency” without a measured target or a test method cannot tell you whether the proposed workflow is suitable.
MediaPackage can add configuration and operational considerations compared with a simple object-origin workflow. That may be warranted when the requirements call for it, but it is not an automatic improvement for every channel. AWS’s MediaLive user guide on MediaPackage can help frame the packaging choice; verify feature details against current service documentation before you commit.
Do not conflate a MediaStore migration with a MediaPackage version upgrade. AWS documents that MediaPackage v2 has distinct resource identifiers and no automated process for moving v1 resources to v2. If your destination plan also involves a v1-to-v2 move, treat that as separate migration work and inventory and recreate the relevant resources deliberately.
Compare requirements before choosing
The choice is conditional. S3 is the destination AWS recommends for a simple live-video origin; MediaPackage is the direction for advanced requirements that depend on packaging or failover capabilities. A table can expose the decision point, but it cannot replace validation against your own manifests, player and delivery path.
| Workflow requirement | Direction to assess | What to verify |
|---|---|---|
| Simple origin, with no advanced packaging requirement | Amazon S3 | Object writes and reads, manifest updates, cache behaviour, latency target and delivery architecture |
| DRM requiring repackaging | MediaPackage | Supported output, encryption configuration, player compatibility and regional availability |
| Ad insertion requiring repackaging | MediaPackage | Manifest and ad workflow, insertion point, player behaviour and monitoring |
| Cross-region failover | MediaPackage | Failure scenarios, publishing behaviour, recovery path and what viewers experience |
| Specific low-latency workflow | MediaPackage | A defined latency target, end-to-end measurement method and client behaviour |
| Persistent objects to retain | Selected storage such as S3 | Whether the objects remain accessible, retention policy, metadata and any required transformation |
The table is a starting filter, not a feature matrix or a guarantee that a particular configuration will work. AWS’s announcement says MediaStore List and Get APIs could be used to copy persistent data to a storage destination such as S3. Because the service shutdown has passed, that historical instruction does not establish that those APIs can still retrieve your objects. If the data is unavailable, contact AWS Support as the notice advises.
For a small channel or a straightforward loop, the important test may be whether the new origin serves fresh manifests and segments correctly through the existing delivery path. For a broadcaster with multiple outputs, DRM and regional continuity requirements, the work is more like a workflow migration: you must verify each output and failure mode. AWS’s June 2026 case study of broadcaster 5 describes a customer-specific move to MediaPackage v2, but it is an example rather than a prescription for every MediaStore user.
Plan migration and test delivery
Write down a migration plan with an owner for each part: data, configuration, publishing, delivery, playback and rollback decision. If data is persistent, establish whether you have a copy outside MediaStore or whether AWS Support can clarify access. Preserve object names and metadata where downstream systems depend on them, and decide whether you need to transform or reorganise retained files before loading the chosen destination.
Build the new workflow in a test environment or with a non-production channel where possible. Use representative content and the actual encoder or publishing process, not just a manually uploaded sample. Observe several manifest updates and segment transitions; verify that playback continues across the transitions, that the player can seek or join as expected, and that caching does not serve stale manifests. Test both a normal operating period and the failure conditions relevant to your design.
For S3, confirm permissions, write behaviour, object lifecycle and delivery configuration. For MediaPackage, validate each configured output, encryption or ad treatment, and any failover or latency behaviour you rely on. Check the precise AWS service features and regions involved against current documentation. Where the migration crosses several AWS services or has a strict broadcast requirement, a qualified AWS media-workflow architect may help review the plan; that is an optional service category, not a guarantee of a particular outcome.
Keep a written acceptance checklist. It might include: the expected manifest format is present; segment requests return successfully; a test viewer plays the stream on each supported device; encryption and ad markers behave as intended; alarms detect a stopped or stale publishing path; and the team knows whom to contact during a fault. Define pass conditions before testing so you do not declare success solely because one browser played for a few minutes.
The always-on YouTube channel comparison is useful context when the question extends beyond the AWS origin to how the broader channel is operated. It does not make S3 and MediaPackage interchangeable, and it should not replace a review of the AWS-specific origin and packaging requirements.
Review dependencies and cut over deliberately
Before cutover, search configuration repositories, scripts, dashboards and runbooks for the old origin endpoint and service-specific identifiers. Review encoder destinations, CDN origin settings, DNS records, access policies, monitoring checks, cache invalidation routines and any scheduled cleanup. Also look for less visible dependencies such as a player URL embedded on a website, a workflow that archives old segments, or a support document that tells staff where to restart publishing.
Set the change window and communication plan around your audience and team. If the new path can be tested in parallel without disrupting the existing publication, do so; do not assume the old path can serve as a rollback once the shutdown has passed. Your rollback plan should instead identify a known-good available destination or a controlled pause while you correct the new configuration.
After changing the endpoint or publishing path, verify from outside the AWS console as a viewer would. Check the actual stream on representative networks and devices, then watch the relevant alarms and logs. Keep a person responsible for observing the cutover until the acceptance checks pass. If you have retained objects, verify that the selected storage holds the expected data and that retention and access policies match the intended use.
Record what changed and update the runbook immediately. Include the new endpoints, resource identifiers, ownership, alert meanings, recovery steps and the date of the change. Do not place credentials in the runbook. A clean handover is especially useful for a channel that may need attention overnight, when the person responding may not have been part of the migration design.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Is MediaStore still available after November 2025?
No. AWS’s shutdown notices describe the service ending in November 2025, with the General Reference listing 12 November as end of support and the discontinuation post describing use until 13 November. Treat MediaStore as unavailable and do not plan a new workflow around it.
Should every MediaStore workflow move to S3?
No. AWS recommends S3 for simple live-video origins, but directs advanced workflows needing cross-region failover or specific low-latency requirements to MediaPackage. DRM and ad insertion that require repackaging also point towards MediaPackage, so choose by required capabilities.
Can I retrieve persistent objects through MediaStore APIs now?
AWS’s earlier notice described using List and Get APIs to copy persistent data, but that statement predates the shutdown and does not confirm current access. Contact AWS Support if the objects are not already available elsewhere; do not assume retrieval is possible.
Does MediaPackage v2 automatically import v1 resources?
No. AWS says there is no automated migration process from MediaPackage v1 resources to v2, which uses distinct resource identifiers. Treat that as separate migration work if your destination plan includes a v1-to-v2 change.