亚马逊子公司与业务品牌：Amazon.com Services、AWS、Whole Foods、MGM、Twitch
很多卖家第一次认真注意到“亚马逊子公司”，不是在看财报，而是在处理一个很具体的问题：
摘要：别把公司名当成 Case 团队
很多卖家第一次认真注意到“亚马逊子公司”，不是在看财报，而是在处理一个很具体的问题：
一张费用发票上出现了 Amazon.com Services LLC；
一封协议通知写的是 Amazon Services Business Solutions Agreement；
广告后台、品牌备案、FBA、账户健康又都叫 Amazon；
再去网上查，发现 AWS、Whole Foods、MGM、Twitch 也都和 Amazon 有关系。
于是问题就来了：我到底在和哪个 Amazon 打交道？Case 应该找谁？法律实体、业务品牌、Seller Central 团队是不是一回事？
这篇文章的核心结论很简单：卖家不能把“法律子公司”“业务品牌”“财务分部”“Case 支持团队”混成一张图。
混在一起，轻则 Case 写偏，重则把付款、税务、合规、品牌授权、广告审核的问题交给错误入口，浪费处理窗口。
1. 先把四张图分开
看亚马逊，至少有四套口径。
| 口径 | 你看到的名字 | 它主要回答什么问题 | 卖家最容易犯的错 |
|---|---|---|---|
| 法律实体 | Amazon.com Services LLC、Amazon Web Services, Inc. 等 | 谁签约、谁开票、谁承担某类法律或税务身份 | 看到公司名就以为它是 Case 处理团队 |
| 业务品牌 | AWS、Whole Foods Market、Amazon MGM Studios、Twitch | 面向客户的产品、服务、内容或渠道是什么 | 把消费者品牌当成卖家支持入口 |
| 财务分部 | North America、International、AWS | 财报怎么管理和披露经营结果 | 把财报分部当成 Seller Central 后台分类 |
| Case 路由 | Account Health、FBA、Listing、Brand Registry、Ads、Payments 等 | 卖家问题该从哪个支持入口进入 | 用公司架构理论替代证据和问题分类 |
卖家真正需要掌握的是：先判断问题属于哪一类业务链路，再决定证据和入口。
比如，一笔 FBA 赔偿少了，不是因为“Amazon.com Services LLC 是不是负责 FBA”就能解决；它要回到 Shipment ID、FNSKU、库存状态、赔偿报告和政策口径。
再比如，广告扣费异常，也不是因为 AWS 负责技术基础设施，就去找 AWS；它要回到 Campaign ID、日期范围、预算、点击/展示、账单和广告报表。
2. 公开资料明确写到什么
先看事实，不做脑补。
公开资料明确写到，亚马逊在 2025 年 Form 10-K 中把运营组织为三个分部：North America、International 和 Amazon Web Services，也就是 AWS。这个口径是财务管理和披露口径，不等于 Seller Central 的支持团队口径。
同一份 2025 年 10-K 的 Exhibit 21.1 列出 Amazon.com, Inc. 的重大子公司，其中包括：
| 法律名称 | 管辖地 | 持股比例 |
|---|---|---|
| Amazon.com Services LLC | Delaware | 100% |
| Amazon.com Sales, Inc. | Delaware | 100% |
| Amazon Data Services, Inc. | Delaware | 100% |
| Amazon Web Services, Inc. | Delaware | 100% |
| Amazon Technologies, Inc. | Nevada | 100% |
| Amazon.com NV Investment Holdings LLC | Nevada | 100% |
| Amazon US Services LLC | Delaware | 100% |
| A100 ROW, Inc. | Delaware | 100% |
| Day One Insurance, Inc. | Arizona | 100% |
这里有两个重点。
第一，这是一张“重大子公司”清单，不是所有业务品牌清单。 没出现在这张表里，不代表某个品牌和亚马逊没有关系；出现在这张表里，也不代表卖家遇到任何问题都能直接找这个法律实体。
第二，法律实体名字和业务品牌名字经常不是同一层。 AWS 既是财务分部，也是业务品牌，背后也有 Amazon Web Services, Inc. 这样的法律实体；但 Whole Foods、MGM、Twitch 更常以消费者能感知的业务品牌出现。
再看卖家协议。
Seller Central 的 Amazon Services Business Solutions Agreement 页面底部显示版权方为 Amazon.com Services LLC。Seller Forums 中 News_Amazon 发布的官方公告也说明，2026 年 3 月 4 日起 Amazon 会更新 BSA，并加入与 Agent Policy、AI 使用、自动化系统、争议解决流程相关的调整。
这说明一件事：卖家和 Amazon 的关系，很多时候先落在协议、服务条款、后台通知和卖家服务入口上，而不是落在“我知道亚马逊有哪个子公司”上。
3. Amazon.com Services LLC：卖家最常看到，但不要把它当万能客服
很多美国站卖家会在 Seller Central、协议页、条款页、费用相关文件里看到 Amazon.com Services LLC。
它在 2025 年 Exhibit 21.1 中被列为 Amazon.com, Inc. 的重大子公司；Seller Central BSA 页面底部也显示 Amazon.com Services LLC。
对卖家来说，比较稳妥的理解是：
Amazon.com Services LLC 是你在美国站卖家服务、协议、后台页面和某些服务文件中经常遇到的法律实体线索，但它不是你可以绕过 Seller Central 的“高级处理团队”。
这句话很关键。
如果你的问题是费用、付款、协议、账户、税务信息、身份验证、BSA 通知，法律实体名称可能出现在证据里。
但 Case 处理仍然要按问题类型走：
| 问题 | 不应该怎么写 | 应该怎么写 |
|---|---|---|
| 付款暂停 | “请 Amazon.com Services LLC 立刻付款” | 说明付款周期、金额、暂停通知、账户验证状态、税务信息状态 |
| 协议更新疑问 | “我不同意你们集团安排” | 引用具体 BSA 条款或通知日期，问清适用范围和卖家需要采取的动作 |
| 费用文件不一致 | “你们哪个公司扣错钱了” | 提供发票编号、交易报告、费用类型、日期范围和差异金额 |
| 账户停用 | “找法律部门重新审核” | 回到停用原因、根因、纠正措施、预防措施和证据附件 |
卖家要记住：法律实体名称可以作为证据背景，但 Case 的有效性取决于问题分类和证据颗粒度。
4. AWS：它很重要，但大多数 Seller Central Case 不归 AWS 处理
AWS 是 Amazon 的大业务。
公开 AWS 文档写到，Amazon Web Services 提供包括计算、存储、数据库、分析、网络、开发工具、管理工具、IoT、安全和企业应用在内的全球云产品；AWS 2006 年开始提供 IT 基础设施服务。
这对卖家有什么关系？
不是说卖家后台出问题就去找 AWS。
真正的关系有三层。
第一，亚马逊整体有很强的技术基础设施能力。卖家今天用的 SP-API、报表、广告后台、自动化工具、目录系统，本质上都离不开数据管道和技术平台。
第二，很多第三方 ERP、BI、广告工具、AI Agent 可能部署在 AWS 或其他云上，但工具问题不自动等于 Amazon Seller Central 问题。
第三，SP-API 相关问题要区分清楚：是你自己的开发者权限、API 调用、Rate limit、报表生成、工具商同步，还是 Seller Central 后台数据本身异常。
一个实用判断：
| 现象 | 更可能的入口 | 证据 |
|---|---|---|
| ERP 拉不到订单 | 先找工具商 / SP-API 开发者排查 | API error code、request ID、时间戳、授权状态 |
| Seller Central 页面也没有订单 | Seller Central 支持 | 订单页面截图、订单时间、Marketplace、买家付款状态 |
| 广告 API 数据和广告后台不一致 | 广告支持 / 工具商共同核对 | 报表类型、Campaign ID、下载时间、时间区间 |
| AWS 服务器账单异常 | AWS Support | AWS Account、服务名、账单周期、资源 ID |
不要用“亚马逊云出问题了”概括所有技术问题。 这句话太大，Case 无法处理。
5. Whole Foods：它是亚马逊的零售和生鲜业务品牌，不是普通 3P 卖家的支持入口
Whole Foods Market 是亚马逊非常典型的业务品牌案例。
Amazon 官方新闻在 2017 年 8 月 24 日说明，Amazon 对 Whole Foods Market 的收购将在 2017 年 8 月 28 日完成；双方会在 Prime、门店、商品和物流等方面逐步整合。
这说明 Whole Foods 和 Amazon 的关系是真实存在的。
但对普通 Amazon Marketplace 卖家来说，关键不是“Whole Foods 属不属于 Amazon”，而是：
你的问题是不是发生在 Seller Central 的第三方卖家链路里。
如果你是在 Amazon.com 上销售食品、保健品、厨房用品，遇到的是 Listing、类目、FBA、合规、食品标签、危险品、消费者投诉，那仍然按 Seller Central 的商品、合规、履约或买家体验路径走。
如果你是想供货给 Whole Foods 门店，或者涉及线下零售采购、供应商入驻、门店陈列，那通常不是普通 Seller Central Case 能解决的问题。
这就是法律关系和运营入口的区别。
6. MGM 和 Twitch：内容与流量品牌，不等于卖家后台团队
MGM 和 Twitch 更容易被卖家误读。
Amazon 官方新闻在 2022 年说明，MGM 加入 Prime Video 和 Amazon Studios，MGM 的片库包括大量电影和电视内容。Twitch 的官方收购公告则显示，Amazon 在 2014 年宣布收购 Twitch Interactive, Inc.，当时 Twitch 是面向游戏的直播视频平台。
这些业务对 Amazon 的消费者生态、内容生态、广告生态有意义。
但卖家要谨慎：MGM、Prime Video、Twitch 这样的业务品牌，不是处理你 Listing、FBA、账户健康、付款 Case 的入口。
它们对卖家的相关性通常是间接的：
- 品牌和 IP 风险：不要在 Listing、图片、A+、广告素材里未经授权使用电影、游戏、角色、直播平台、赛事或内容品牌资产。
- 广告和内容投放：如果你做品牌广告、视频素材、站外内容合作，要按 Amazon Ads、创作者合作或对应广告产品规则处理。
- 消费者心智：Amazon 的 Prime、视频、直播、内容生态会增强用户黏性，但这不是卖家解决后台 Case 的理由。
如果你因为广告素材里使用了某个影视、游戏或平台元素导致审核被拒，Case 应该写成广告素材合规问题，而不是写“这是 Amazon 自己旗下业务，为什么不能用”。
因为所属关系不等于授权关系。
7. 一套卖家可用的判断法：先问 5 个问题
遇到任何带 Amazon 公司名、品牌名、协议名、发票名的问题，先不要急着开 Case。
用下面 5 个问题判断入口。
| 诊断问题 | 如果答案是“是” | 下一步 |
|---|---|---|
| 问题发生在 Seller Central 吗？ | 是 | 优先按 Seller Central 分类开 Case |
| 问题和广告投放、扣费、审核有关吗？ | 是 | 走 Amazon Ads 支持或广告后台问题路径 |
| 问题和 API、ERP、自动化同步有关吗？ | 是 | 先分清 SP-API、工具商、Seller Central 数据源 |
| 问题和发票、付款、税务、协议有关吗？ | 是 | 保留法律实体名，但按付款/税务/协议问题写证据 |
| 问题和某个消费者品牌有关吗？ | 是 | 先判断是 IP、广告素材、供应商渠道，还是普通卖家链路 |
这个判断法比“查亚马逊组织架构”更有用。
因为 Case 系统处理的是可归类、可验证、可复核的问题，不处理模糊的公司版图讨论。
8. Case 证据清单：涉及法律实体或业务品牌时，至少准备这些
如果你的 Case 里确实需要提到 Amazon.com Services LLC、AWS、Whole Foods、MGM、Twitch 或其他 Amazon 相关名称，证据要按“问题本身”准备。
付款 / 费用 / 发票类
- Marketplace
- 日期范围
- 发票编号或结算周期
- Transaction report / Payments report
- 费用类型和差异金额
- 出现的法律实体名称截图
- 你期望 Amazon 核对的具体字段
协议 / BSA / 账户通知类
- 通知标题和日期
- 后台通知截图
- 涉及的协议或政策链接
- 账号当前状态
- 你需要确认的问题，不要泛泛要求“解释所有条款”
API / 工具 / 数据同步类
- API 名称或报表名称
- Request ID / Error code
- 时间戳和时区
- 工具商后台截图
- Seller Central 原始数据截图
- 是否已重新授权或重试
品牌 / 内容 / IP 类
- ASIN / SKU / Campaign ID
- 被拒或被投诉的具体素材
- 权利方名称、授权文件或不可使用原因
- 广告审核或 Listing 审核提示
- 你已经删除、替换或修正的内容
证据清单不是越多越好，而是要让支持团队一眼看到：问题发生在哪里、影响什么、你要求复核哪一个字段或动作。
9. 可复制 Case 模板：公司名/业务品牌导致的路由混乱
下面这个模板适合用于“发票、协议、后台名称不一致，卖家需要确认具体处理路径”的场景。
不要直接照抄所有字段；把不相关的删掉。
Subject: Request to review entity / billing / agreement information for a specific seller account issue
Hello Amazon Team,
I am requesting help with a specific issue related to [billing / payment / agreement notice / account notification].
Marketplace:
Issue date:
Document or notification title:
Invoice / transaction / case ID:
Affected amount or affected function:
What I observed:
The document / notification shows [Amazon entity or business name]. I want to confirm how this applies to my seller account and what action I should take in Seller Central.
Evidence attached:
1. Screenshot of the document or notification
2. Payment / transaction / invoice report
3. Seller Central page showing the current status
4. Any related previous Case ID
My request:
Please review this specific issue and confirm:
1. Whether the document / notification applies to this seller account
2. Which action I need to take in Seller Central
3. If the charge / status / notice is incorrect, please advise the correct correction path or escalate to the relevant team
Thank you.
这个模板故意不写“请转给 Amazon.com Services LLC 法务部”。
原因很现实：卖家 Case 的目标不是展示你知道哪个法律实体，而是让系统把问题按正确类型送到能处理的队列。
10. 内部 SOP：别让老板、财务、运营、开发各开一个 Case
这类问题最怕多人同时操作。
建议卖家团队内部用一张小表统一。
| 角色 | 要做什么 | 不要做什么 |
|---|---|---|
| 运营 | 判断问题发生在 Listing、FBA、广告、账户还是付款 | 不要凭公司名猜测处理团队 |
| 财务 | 提供发票、付款、结算、费用差异证据 | 不要只截图金额，不给报告来源 |
| 开发/工具负责人 | 核对 API、ERP、报表同步和错误码 | 不要把工具商问题直接归因给 Amazon |
| 合规/品牌负责人 | 判断是否涉及授权、IP、协议、政策 | 不要用“Amazon 旗下品牌”替代授权证明 |
| 老板/负责人 | 决定是否升级、是否补证据、是否停止重复开 Case | 不要情绪化催单或多入口重复提交 |
推荐流程：
- 先确定问题类型。
- 再收集证据。
- 只由一个负责人开 Case。
- 记录 Case ID、提交时间、回复要点和下一步动作。
- 如果被拒，不要马上重开；先判断是入口错、证据少，还是请求本身不成立。
11. 常见误区
误区一：看到 Amazon.com Services LLC，就以为找到了“真正负责人”。
它可以是协议、页面、文件中的法律实体线索，但卖家问题仍然要按 Case 类型处理。
误区二：把 AWS 当成 Seller Central 技术客服。
AWS 是重要的云业务和财务分部，但 Seller Central、SP-API、ERP、广告 API 的问题要按各自支持路径排查。
误区三：Whole Foods、MGM、Twitch 属于 Amazon，所以素材或品牌词就能随便用。
不能。所属关系不等于卖家授权。Listing 和广告素材仍然要遵守 IP、广告和内容政策。
误区四：拿组织架构当证据。
Case 最需要的是后台截图、报告、ID、时间线、金额、政策链接和业务影响，不是“我查到你们某某部门存在”。
误区五：同一个问题从多个入口重复提交。
这会让信息分散。更好的做法是保留一个主 Case，把新增证据和前序 Case ID 写清楚。
12. 风险边界：哪些话本文不能替你下结论
本文只基于公开资料和卖家常见后台路径做解释，不替代法律、税务或合规意见。
有几类问题必须谨慎：
- 不同站点、不同服务、不同协议下，具体合同主体可能不同。
- BSA、Seller Central 帮助页、广告政策、API 政策会更新，正式处理前要以当前后台和官方页面为准。
- 亚马逊内部团队权限、风控模型、Case 流转规则并不公开，不能把外部推断写成“内部规则”。
- 如果问题涉及诉讼、税务处罚、重大付款冻结、品牌权属争议，要请律师、税务顾问或专业合规人员介入。
我们能确定的是：卖家写 Case 时，应当把公开事实、合理推断和实操请求分开。
结尾：明天就做一张“Amazon 名称对照表”
这篇文章不要求你背下亚马逊所有子公司。
真正有用的动作是：给自己的店铺做一张“Amazon 名称对照表”。
表里写清楚：
- 后台通知里出现过哪些 Amazon 名称；
- 它对应的是协议、付款、广告、API、品牌，还是消费者业务；
- 你们内部谁负责处理；
- Case 应该从哪个入口走；
- 需要准备哪些证据。
卖家不需要把自己变成亚马逊组织架构专家，但必须知道：看到一个 Amazon 名称时，下一步该查什么、问什么、交什么证据。
这才是子公司和业务品牌对卖家的真正价值。
资料来源与边界说明
公开资料明确写到
- Amazon 2025 Form 10-K / SEC：亚马逊将运营组织为 North America、International、AWS 三个分部。
https://www.sec.gov/Archives/edgar/data/1018724/000101872426000004/amzn-20251231.htm - Amazon 2025 Form 10-K Exhibit 21.1 / SEC：列出 Amazon.com, Inc. 的重大子公司，包括 Amazon.com Services LLC、Amazon.com Sales, Inc.、Amazon Data Services, Inc.、Amazon Web Services, Inc. 等。
https://www.sec.gov/Archives/edgar/data/1018724/000101872426000004/amzn-20251231xex211.htm - Amazon Seller Central：Amazon Services Business Solutions Agreement 页面为官方卖家协议入口，页面底部显示 Amazon.com Services LLC。
https://sellercentral.amazon.com/help/hub/reference/external/G1791?locale=en-US - Amazon Seller Forums / News_Amazon：Business Solutions Agreement updates effective March 4, 2026，说明 BSA 更新、新 Agent Policy、AI 使用、自动化系统和争议解决流程相关调整。
https://sellercentral.amazon.com/seller-forums/discussions/t/84e3f6b1-42f7-4cf3-a189-a5cc8d78d838 - AWS Documentation：AWS 提供全球云产品，包括计算、存储、数据库、分析、网络、开发工具、安全等；AWS 在 2006 年开始提供 IT 基础设施服务。
https://docs.aws.amazon.com/whitepapers/latest/aws-overview/introduction.html - Amazon Press Center：Amazon 和 Whole Foods Market 宣布收购将在 2017 年 8 月 28 日完成，并提到 Prime、门店和商品等方面的整合。
https://press.aboutamazon.com/2017/8/amazon-and-whole-foods-market-announce-acquisition-to-close-this-monday-will-work-together-to-make-high-quality-natural-and-organic-food-affordable-for-everyone - About Amazon：MGM 加入 Prime Video 和 Amazon Studios，MGM 片库包括大量电影和电视内容。
https://www.aboutamazon.com/news/entertainment/mgm-joins-prime-video-and-amazon-studios - Amazon Press Center：Amazon 在 2014 年宣布收购 Twitch Interactive, Inc.。
https://press.aboutamazon.com/2014/8/amazon-com-to-acquire-twitch
我们可以合理推断
- 法律实体、财务分部、业务品牌和 Seller Central Case 支持队列是不同口径；卖家不能用其中一张图替代其他三张图。
- Amazon.com Services LLC 出现在卖家协议和相关页面中，对美国站卖家理解协议、付款、费用和后台通知有参考价值，但它不是可绕过 Seller Central 的万能处理入口。
- AWS 与卖家工具、API、数据管道有间接关系，但普通 Seller Central、广告、Listing、FBA Case 不应直接归类为 AWS 问题。
卖家实操建议
- 开 Case 前先判断问题发生在 Seller Central、Amazon Ads、SP-API/工具、付款/税务/协议，还是消费者业务品牌。
- Case 中可以保留法律实体或业务品牌名称作为背景，但必须回到 ASIN、SKU、Order ID、Shipment ID、Campaign ID、Invoice、Transaction report、API error code、时间线等证据。
- 涉及重大付款、税务、合同、品牌授权或诉讼问题时，应让律师、税务顾问或专业合规人员介入。