AWS 半导体安全研发环境架构解读

基于 AWS Prescriptive Guidance：Securing semiconductor development environments on AWS

官方文档：
https://docs.aws.amazon.com/pdfs/prescriptive-guidance/latest/strategy-aws-semicon-workloads/strategy-aws-semicon-workloads.pdf

文档作者：Mike Virgilio、Allan Carter、Nikhil Marrapu，Amazon Web Services
文档历史：Initial publication — June 20, 2023
当前 PDF 版权页：Copyright © 2026 Amazon Web Services, Inc. and/or its affiliates.

1. 阅读结论

这份 Prescriptive Guidance 不是“如何在 AWS 上建设完整 EDA 云”的实施手册，它解决的核心问题更明确：

如何在 AWS 上建立一个能够承载半导体高价值 IP、EDA 工具和第三方协作的安全研发环境，并控制未经授权的数据外泄。

AWS 在开篇就把半导体研发环境的特殊性定义得很清楚：芯片公司既持有自研 IP，也需要使用处理器核、标准接口 IP、晶圆厂 PDK 和 EDA 厂商授权工具；同时，内部工程师、EDA/IP/Foundry 等第三方工程师又不可避免地需要参与研发协作。因此，这类环境最重要的安全问题不是“服务器是否在云上”，而是谁可以进入研发环境、可以访问什么数据、数据可以从哪里流入和流出、这些行为能否被控制和追溯。（AWS PDF 正文 p.1、p.5）

从 IT 架构角度看，AWS 给出的方案可以归纳为五个设计原则：

  1. 把研发环境视为一个受控安全域，而不是一批 EC2 主机。
  2. 身份、网络、数据、密钥和审计共同构成安全边界，不能只依赖单一防火墙。
  3. 研发人员的交互入口与实际计算资源分离，远程桌面只是访问层，不是计算架构本身。
  4. 对第三方协作采用临时、隔离、最小化的数据和工具副本，而不是直接开放主研发环境。
  5. 云的弹性和自动化只有与安全控制、数据迁移和运行治理一起设计，才构成完整的半导体研发云方案。

需要特别说明：上述五点中的表述是本文的架构归纳；其事实基础来自 AWS 文档对安全研发环境、数据防外泄、远程桌面、Collaboration Chamber、安全服务和云弹性的描述。

2. 先明确这份文档的边界

2.1 AWS 明确讨论了什么

文档明确覆盖：

  • 半导体研发环境中的 IP 安全；
  • Shared Responsibility Model；
  • 合规与审计；
  • IAM、IAM Identity Center、AWS Directory Service；
  • Linux 文件权限；
  • VPC Endpoint 与 Endpoint Policy；
  • S3、Amazon FSx、AWS DataSync、NetApp SnapMirror；
  • 数据静态与传输加密；
  • Internet 出口限制；
  • Data Residency；
  • Amazon DCV、NoMachine、OpenText Exceed TurboX；
  • 第三方 Collaboration Chamber；
  • Direct Connect、Transit Gateway、Scheduler、Compute Cluster、License Server 等参考架构组件；
  • CloudTrail、GuardDuty、Inspector、Security Hub CSPM、Security Lake、VPC Flow Logs 等安全服务；
  • Ransomware 防护的总体原则；
  • AWS 弹性、自动化、HPC 与云存储带来的平台能力。

2.2 AWS 没有在本文中给出什么

本指南没有给出以下内容，因此不能从本文直接推导：

  • Cadence、Synopsys、Siemens EDA、Ansys 等具体 EDA 产品的性能数据；
  • VCS、Xcelium、PrimeTime、Innovus、ICC2、Calibre 等工具的 Benchmark；
  • 某类 EDA Workload 应选择哪一种 EC2 Instance；
  • CPU 主频、核数、Memory、NUMA 的具体 sizing；
  • IBM LSF、Slurm、AWS Batch 等调度器的选型结论；
  • Scheduler 的弹性伸缩实现；
  • FlexNet/FlexLM 或各 EDA Vendor 的云端 License 合同政策；
  • License Server 的 HA、Rehost、HostID 等实现细节；
  • FSx for ONTAP、FSx for Lustre、FSx for OpenZFS 之间的 EDA 性能对比；
  • 完整的 TCO/ROI 模型；
  • EDA 云上 Disaster Recovery 的 RPO/RTO 设计；
  • DCV、ETX、NoMachine 之间的性能 Benchmark。

因此，这份文档更适合作为安全架构基线和总体设计约束，而不是直接作为采购或性能选型依据。

3. AWS 对半导体研发环境的基本判断

AWS 认为半导体行业同时具备两个特征：

一方面，芯片设计和制造复杂度持续增长，Compute 和 Storage 需求快速增加；另一方面，芯片 IP 具有极高价值，是攻击和数据外泄的重点目标。AWS 因而将“技术能力”和“安全性”放在同一个架构讨论中。（AWS PDF 正文 p.1–2）

AWS 给出的云平台价值主要是：

  • economies of scale；
  • resource elasticity；
  • automation；
  • compute、network、storage；
  • machine learning；
  • HPC；
  • security services。

这里需要从架构角度做一个区分：

弹性是能力，不等于自动获得成本优势。 AWS 文档明确提出可以按需求 scale up、任务结束后 scale down，以优化成本；但本文没有给出芯片研发场景的 TCO 计算。因此，对于 7×24 固定运行的 EDA Desktop、License Server、核心文件系统，以及高利用率 Compute Farm，仍需要单独做成本模型。不能仅用“按需付费”得出“云一定更便宜”的结论。（AWS PDF 正文 p.2、p.16）

4. 从架构上看，真正的对象是“Secure Development Environment”

传统上容易把“EDA 上云”理解成：

1
2
3

On-Prem Server
      ↓
Amazon EC2

这不是本文表达的重点。

AWS 实际讨论的是一个完整的受控研发域：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

                    Corporate / Partner Identity
                              │
                       Authentication
                              │
                 ┌────────────▼────────────┐
                 │ Secure Development Zone │
                 │                         │
                 │ Remote Access           │
                 │ Compute                 │
                 │ Storage                 │
                 │ EDA License             │
                 │ Project / IP Data       │
                 │                         │
                 └───────┬─────────┬───────┘
                         │         │
                   AWS Services   Controlled
                   via Endpoints   Egress
                         │         │
                         └────┬────┘
                              │
                     Central Logging
                     Security Monitoring

这个环境首先是一个数据安全域（data security domain），其次才是一个计算资源池。

AWS 在“Preventing unauthorized access and data exfiltration”一节列出的控制点很有代表性：

  • 用户认证；
  • 用户对研发数据的授权；
  • 记录所有进出安全研发环境的数据传输；
  • 设计安全的数据流；
  • 数据静态和传输加密；
  • 限制并记录出站网络流量。

这六项实际上定义了该安全域的基本边界。（AWS PDF 正文 p.5）

5. 身份与权限：不能只解决“AWS Console 登录”

5.1 Workforce Identity

AWS 对人工用户的建议是使用身份联邦和临时凭证，推荐使用 AWS IAM Identity Center 集中管理 workforce access，并可以与外部 IdP 通过 SAML 2.0、OIDC 或 OAuth 2.0 联邦。（AWS PDF 正文 p.6）

对于企业架构，这一层主要解决：

1
2
3

企业人员身份
      ↓
AWS Account / Application Access

它解决的是“谁可以访问 AWS 平台资源”。

5.2 OS 与研发数据权限仍然存在

AWS 同时明确指出，可以通过 AWS Directory Service 管理目录中的用户和组，例如 Active Directory；进入安全研发环境后，还可以使用 Linux file permissions 控制 VPC 内的数据访问。（AWS PDF 正文 p.6）

这一点非常重要。

半导体研发环境至少有两套授权面：

1
2

AWS Control Plane
IAM / Role / Policy

和：

1
2

Linux / POSIX Data Plane
UID / GID / File Permission

因此，在实际建设中，不能把 IAM 权限模型等同于 /project、/pdk、/ip、/work 等研发目录权限模型。

从架构治理角度，需要分别回答：

  • 谁可以创建或修改 EC2、VPC、FSx、S3；
  • 谁可以登录研发桌面；
  • 谁可以读取某项目数据；
  • 谁可以读取 Foundry PDK；
  • 谁可以使用第三方 IP；
  • 谁可以访问 License Server。

AWS 本文明确提供了前两类控制机制，但没有替芯片公司定义项目级 Unix Group 或具体的数据权限模型。

6. AWS 采用的是“多层数据边界”，不是单点边界

AWS 在本文中的安全设计不是依赖某一个防火墙，而是把多类控制叠加起来：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Identity
   +
IAM Policy
   +
Linux Permission
   +
Security Group / NACL
   +
VPC Endpoint / Endpoint Policy
   +
Network Firewall / Proxy
   +
KMS / CloudHSM
   +
CloudTrail / Flow Logs

AWS 将这种思路总结为通过 layered security controls 建立并实施 robust data perimeter。（AWS PDF 正文 p.7–8）

从架构角度，这意味着芯片研发网的安全目标应由“端口是否开放”升级为：

任何一条数据离开研发安全域的路径，都应当是预先设计、可授权、可限制、可记录的。

这比传统“研发 VLAN + 防火墙”的模型更加精细。

7. VPC Endpoint 的意义：减少数据经过公网路径

AWS 明确建议使用 VPC endpoints 访问 AWS 服务，以避免经过 Public Internet，并配合：

  • Endpoint Policy：限制哪些 AWS principals 可以使用 Endpoint；
  • Identity-based Policy：限制可以访问哪些 AWS 服务、执行哪些动作。

（AWS PDF 正文 p.6）

对于半导体研发环境，这种设计的意义并不只是“网络性能更好”，而是把访问 S3、AWS API 等云服务的路径纳入内部受控网络边界。

架构上应该把以下两类流量区别开：

1

研发环境 → AWS Service

和：

1

研发环境 → Public Internet

前者优先通过私有 Endpoint 完成；后者则需要更强的业务必要性审查和出口控制。

8. Internet 出口：默认不是“自由访问”

AWS 对这一点的描述非常明确：

如果安全研发环境确实需要 Internet Access，所有 outbound internet traffic 应通过网络级 enforcement point 进行限制和记录，例如：

  • AWS Network Firewall；
  • Squid Proxy。

AWS 同时指出，VPC Endpoint 和 Internet Proxy 有助于减少未经授权的数据外泄。（AWS PDF 正文 p.7–8）

因此，从架构设计上不应采用：

1
2
3
4
5

EC2
  │
Public IP / NAT
  │
Internet

作为研发服务器的默认网络模型。

更符合本文原则的是：

1
2
3
4
5
6
7

EDA / Desktop / Compute
          │
          ├──── VPC Endpoint ──── AWS Services
          │
          └──── Proxy / Firewall ──── Approved Internet
                         │
                    Logging / Policy

这里的重点是出口必须有控制点。

9. 数据迁移：AWS 的建议是先做 Storage Requirement，再选迁移工具

AWS 对数据迁移的顺序给出了非常明确的建议：

先定义 semiconductor workload 的 storage requirements，再确定 appropriate data transfer mechanism。

随后 AWS 推荐使用 AWS DataSync 将 On-Prem 数据迁移到 AWS。DataSync 可通过 Internet 或 AWS Direct Connect 移动/复制数据，并可以传输 ownership、timestamps、access permissions 等文件系统元数据。（AWS PDF 正文 p.6–7）

这对芯片研发环境尤其重要，因为 EDA 工程目录并不只是“文件内容”。

实际迁移对象通常同时包含：

1
2
3
4
5
6
7
8

Directory Hierarchy
File Data
Ownership
UID / GID
Mode Bits
Timestamp
Application Assumptions
Symbolic Relationships

AWS 本文明确提到 ownership、timestamp、access permissions；其他项目属于迁移评估时需要自行验证的工程内容，不能假设 DataSync 在所有文件系统与所有语义下都自动满足。

架构决策顺序

建议按以下顺序评估，而不是反过来：

1
2
3
4
5
6
7
8
9

Workload I/O Pattern
       ↓
Capacity / Performance Requirement
       ↓
Target File System
       ↓
Migration / Synchronization Mechanism
       ↓
Cutover Strategy

这与 AWS 文档的原则一致。

10. S3 的定位：数据平台，不等同于直接替代 POSIX NAS

AWS 指出，本地数据迁移到云时通常可以首先存储到 Amazon S3；S3 可以作为复制源，用于创建新的文件系统，或向 EC2 实例传输数据。AWS 还指出，S3 可以作为 AWS 托管的 POSIX-compliant 文件系统的后端，用于 semiconductor tools and flows。（AWS PDF 正文 p.6）

这段内容容易被过度解读。

正确理解应该是：

  • S3 是重要的数据落地点、复制源和对象存储层；
  • AWS 并没有在本文中说“所有 EDA 工作目录直接改成 S3”；
  • 对依赖 POSIX/NFS 语义的 EDA Flow，仍需要文件系统层。

因此，S3 与 FSx 在该架构中承担的是不同角色。

11. Amazon FSx：AWS 明确列出的半导体常见选择

AWS 明确指出，半导体行业常见的 Amazon FSx 选择包括：

  • Amazon FSx for NetApp ONTAP
  • Amazon FSx for Lustre
  • Amazon FSx for OpenZFS

并认为这些可扩展、高性能文件系统适合在安全研发环境内本地存储数据。（AWS PDF 正文 p.7）

如果在 FSx for ONTAP 与 NetApp ONTAP 之间迁移文件，AWS 推荐使用 NetApp SnapMirror。（AWS PDF 正文 p.7）

这对已有 NetApp 资产的企业很有现实意义，因为它提供了一条较自然的混合云迁移路径。

但需要保持边界：

本文没有提供三种 FSx 文件系统在 EDA 场景中的 Metadata、Small-file、Directory Traversal、Regression、P&R 或 Physical Verification 性能比较。

所以最终选型仍应使用真实 EDA workload 做 PoC，而不是只看服务规格。

12. 加密：数据加密只是安全域的一部分

AWS 在本文中的要求包括：

Data at Rest

使用：

  • AWS KMS customer managed keys；
  • 或 AWS CloudHSM；

并维护 granular key resource policies。

Data in Transit

AWS 指南要求至少使用 TLS 1.2，并提到采用 industry-standard 256-bit AES cipher。（AWS PDF 正文 p.7）

这里的架构重点不是“打开 encryption 开关”这么简单，而是：

  • 谁拥有密钥；
  • 谁可以使用密钥；
  • 哪些数据使用哪个密钥；
  • 密钥权限是否和业务数据权限分离；
  • Key Policy 是否进入变更和审计范围。

这些属于企业实施层设计，本文没有给出具体 KMS Key Hierarchy。

13. Data Residency：Region 选择是安全与合规架构的一部分

AWS 文档分别解释了：

  • Partition；
  • Region；
  • Availability Zone；
  • Local Zone。

并指出不同 Partition 之间具有独立的数据、网络与凭证隔离。AWS 建议多 Region Workload 尽量部署在同一 Partition 中，以降低 compliance、operational 和 technical challenges。（AWS PDF 正文 p.8–9）

对于半导体公司，Region 选择不能仅按：

1
2
3

Latency
Price
Instance Availability

考虑，还需要同时考虑：

1
2
3
4

IP / Contract Requirement
Data Residency
Export / Regulatory Requirement
Security Classification

本文提到 ITAR、GovCloud 以及不同安全分类场景，但并不等同于“部署到某 Region 就自动满足某项合规”。Shared Responsibility Model 仍然成立。

14. 远程桌面：AWS 把它定义为工程师访问层

AWS 明确指出，remote visualization 是 semiconductor design 的关键组件。设计人员通常通过：

  • terminal-based SSH；
  • graphical remote desktop；

提交任务和查看工作流；GUI Remote Desktop 则用于 layout、place、route 等交互式工具。（AWS PDF 正文 p.10）

这说明在 AWS 的模型里，研发工程师的工作方式仍然非常接近传统 EDA 数据中心：

1
2
3
4
5
6
7

Engineer Laptop
      │
SSH / Remote Desktop
      │
Linux Engineering Environment
      │
EDA Workflow

并不是把大型 EDA 数据集下载到工程师本地运行。

这对 IP 安全是非常关键的架构选择：尽量让数据停留在安全研发环境内部，终端侧主要承载交互。

15. Amazon DCV：AWS 在本文中的主推远程显示协议

AWS 在文档中重点介绍 Amazon DCV，称其为 high-performance remote display protocol，用于 engineering 和 physical design team，并指出它可在不同网络条件下工作。（AWS PDF 正文 p.10）

AWS 特别强调两项安全属性：

  1. DCV 传输 pixels，而不是 geometries；
  2. DCV 使用 TLS 保护 pixels 和 end-user inputs。

同时，AWS 也给出了一个非常具体的安全提醒：

DCV connection file 中 password 和 proxypassword 字段没有加密。

因此，如果企业通过 Connection File 分发桌面连接信息，连接文件本身应当按照凭据材料进行保护，而不能当成普通配置文件处理。（AWS PDF 正文 p.10）

16. ETX 与 NoMachine：应该如何准确解读

AWS 在该章节明确写到，其他提供 Remote Desktop 功能的商业方案包括：

  • NoMachine
  • OpenText Exceed TurboX

（AWS PDF 正文 p.10）

因此，可以基于本文得出：

AWS Prescriptive Guidance 明确识别 NoMachine 和 OpenText Exceed TurboX 为半导体工程远程桌面场景中的商业解决方案选项。

但不能把这句话扩大为：

  • AWS 指定 ETX 为标准方案；
  • AWS 认证 ETX 性能优于 DCV；
  • AWS 给出了 ETX Benchmark；
  • AWS 推荐 ETX 替换 VNC；
  • AWS 对 ETX 做了安全认证。

这些内容都不在本文中。

AWS 随后说明，无论采用何种 Remote Desktop Solution，其 AWS 侧底层基础设施由 Amazon EC2 提供，并再次强调客户仍需负责：

  • VPC / Security Group 网络控制；
  • 实例登录凭据；
  • Guest OS；
  • Guest OS 软件、更新与安全补丁；
  • EC2 IAM Role 及其权限。

（AWS PDF 正文 p.10–11）

这体现的仍然是 Shared Responsibility Model，而不是“使用托管云后 OS 运维责任消失”。

17. Collaboration Chamber：本文最有半导体行业针对性的架构设计

如果从整份文档中选一个最值得芯片公司 Infra 团队重点研究的部分，我会选择 Collaboration Chamber。

半导体研发过程中，以下协作无法避免：

  • EDA Tool Debug；
  • IP Integration；
  • 外部 Contractor；
  • 专业第三方技术支持。

AWS 的判断是：直接从 On-Prem 基础设施向第三方提供安全访问并不容易。因此，可以利用 Infrastructure as Code 创建主安全研发环境的一个副本，称为 Collaboration Chamber。（AWS PDF 正文 p.11）

这个模式的核心不是“复制整个研发环境”，而是：

复制一套满足协作所需的最小环境，并只放入完成合作所需的数据、工具和基础设施。

AWS 还明确建议：

  • Collaboration Chamber 中为 Collaborator 设置账号；
  • curated data、tools、infrastructure；
  • 为防止 data exfiltration，可以通过不允许 Internet Access 来收紧 Chamber；
  • 合作结束后删除 Chamber，以降低成本并移除潜在的数据访问路径。

（AWS PDF 正文 p.11）

从安全架构上看，这是典型的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Primary R&D Environment
          │
     Controlled Copy
          │
          ▼
┌──────────────────────────┐
│ Collaboration Chamber    │
│                          │
│ Minimal Data             │
│ Minimal Tools            │
│ Minimal Infrastructure   │
│ Restricted Connectivity  │
│ Dedicated Collaborators  │
└─────────────┬────────────┘
              │
        Project Finished
              │
            Delete

它改变了第三方协作的信任模型：

1
2

传统：
第三方进入主研发环境

变成：

1
2

AWS 模式：
把最少必要的研发环境交付给第三方

这是一个非常实用的安全设计思想。

18. 对 Collaboration Chamber 参考架构的专业拆解

AWS 在正文 p.13 给出了一张完整的 Collaboration Chamber Reference Architecture。图中明确出现以下组件：

On-Premises

  • Users；
  • Office subnet / Office equipment；
  • Lab subnet / Lab equipment；
  • Partner VLAN；
  • Router。

Cloud Connectivity

  • AWS Direct Connect；
  • AWS Transit Gateway。

Collaboration Chamber 内部

  • Remote desktops；
  • Scheduler；
  • Compute cluster；
  • Internet proxy；
  • Internet gateway；
  • VPC endpoints；
  • License Server；
  • AWS Storage Gateway；
  • Amazon FSx。

Partner Access

  • Partner VPC；
  • Remote desktop endpoint；
  • Network Load Balancer；
  • Partner remote desktops；
  • Partner IAM role。

Security / Governance / Management

  • IAM；
  • AWS Directory Service；
  • VPC Flow Logs；
  • AWS CloudTrail；
  • Amazon Inspector；
  • Amazon GuardDuty；
  • AWS Systems Manager；
  • AWS Security Hub；
  • Amazon CloudWatch；
  • Amazon Macie。

Data Layer

  • Amazon S3。

这些组件都可以直接从 AWS 的参考架构图中确认。（AWS PDF 正文 p.13）

19. Scheduler、Compute Cluster 和 License Server 应该怎么理解

参考架构中明确出现：

1
2
3
4
5

Remote desktops
      │
   Scheduler
      │
Compute cluster

同时有独立：

1

License Server

这非常符合芯片研发基础设施的典型形态。

但是，架构审阅时必须保持准确：

这张图是 Collaboration Chamber 的参考架构，不是 AWS 声明的所有 Semiconductor Development Environment 的唯一标准拓扑。

因此，可以得出：

  • AWS 认识到半导体研发通常存在交互桌面、调度器、计算集群和 License Server；
  • 这些组件可以出现在 AWS 的半导体研发参考架构中。

但不能据此得出：

  • AWS 指定 Scheduler 必须是 LSF；
  • AWS 指定 Scheduler 必须是 Slurm；
  • AWS License Server 必须部署在某类 EC2；
  • 所有项目都必须复制一套独立 Scheduler；
  • AWS 已验证所有 EDA License 模型均可直接部署在云端。

这些实施问题必须单独验证。

20. 这张图真正重要的是“工作负载分层”

从架构师角度，参考图最值得注意的不是服务名称，而是职责分层：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Engineer / Partner
        │
        ▼
Remote Desktop Layer
        │
        ▼
Scheduling Layer
        │
        ▼
Compute Layer
        │
        ├──── License
        │
        └──── Storage

这与成熟的 On-Prem EDA Farm 逻辑非常接近：

1
2
3
4
5
6
7

Desktop / Login
      ↓
LSF / Slurm
      ↓
Compute Farm
      ↓
Shared Storage + License

因此，AWS 并没有要求芯片公司改变 EDA Flow 的基本交互模式；AWS 的主要变化在于：

  • Compute / Storage 变为云资源；
  • 身份与网络控制变得更细；
  • 环境可以通过 IaC 复制和销毁；
  • 安全日志与检测服务可以统一纳入云治理。

这里是基于参考架构的工程化解读，不是 AWS 文档的逐字结论。

21. 一个容易忽略的细节：图里有 Internet Proxy，但正文建议 Chamber 不上 Internet

AWS 正文对 Collaboration Chamber 的建议非常明确：

为防止数据外泄，可以通过不允许访问 Internet 来加强 Collaboration Chamber 的安全姿态。

但正文 p.13 的参考图同时画出了：

1
2
3
4
5

Compute Cluster
      │
Internet Proxy
      │
Internet Gateway

这两个信息不应被理解为冲突。

更合理的架构解读是：

  • 最严格的 Chamber 可以完全禁止 Internet；
  • 如果确有业务需求开放 Internet，前文要求所有 outbound traffic 必须通过受控、可记录的 Network-level Enforcement Point；
  • 图中的 Proxy/IGW 应被视为可受控的出口路径，而不是“Compute Cluster 可自由访问 Internet”。

因此，在生产设计中，不应因为参考图出现 Internet Gateway 就默认放通研发环境公网出口。

22. Direct Connect 与 Transit Gateway：体现的是混合云，而不是全量迁移

参考图明确保留：

1
2
3

On-Prem Office
On-Prem Lab
Partner VLAN

并通过：

1
2
3

AWS Direct Connect
        │
AWS Transit Gateway

接入 AWS。（AWS PDF 正文 p.13）

这说明 AWS 的半导体研发模式并不要求企业一次性把所有资产迁出本地数据中心。

从架构角度，半导体研发天然适合长期存在 Hybrid 模式：

1
2
3
4
5
6
7
8
9
10
11
12

On-Prem
  ├─ Office Network
  ├─ Lab Equipment
  └─ Existing Infrastructure
          │
     Direct Connect
          │
        AWS
  ├─ Remote Desktop
  ├─ Compute
  ├─ Storage
  └─ Collaboration Environment

本文没有具体讨论硬件仿真、ATE、Board Farm 等设备，因此这些设备是否以及如何与 AWS 集成，需要另做专项设计，不能由该参考图直接推导。

23. 安全日志：AWS 明确要求集中化

AWS 对数据传输相关日志给出一项非常有价值的建议：

  • 使用 CloudTrail 和 service-specific logging 记录 API 调用和相关的数据传输；
  • 将日志集中到 dedicated account；
  • 使用 granular access policies 形成 immutable history。

（AWS PDF 正文 p.7）

这实际上是安全架构中的职责分离：

1
2
3
4
5
6
7
8
9
10

R&D / Project Account
       │
       ├── 运行 Workload
       │
       └── 产生日志
              │
              ▼
       Dedicated Log Account
              │
      Restricted Administration

它避免项目管理员同时拥有：

1
2
3

运行权限
+
删除审计证据权限

这比“每台服务器本地保留日志”更符合企业级研发环境治理。

24. AWS 安全服务的职责不是相同的

AWS 在正文 p.14 列出的服务，应按不同控制面理解，而不是简单列成一串产品名。

领域 服务 本文中的定位
API 审计 AWS CloudTrail Governance、Compliance、Operational Risk 审计
Threat Detection Amazon GuardDuty 持续分析日志，识别异常和潜在未授权活动
Vulnerability Amazon Inspector 扫描软件漏洞及非预期网络暴露
Security Posture AWS Security Hub CSPM 汇总安全状态并对照标准与最佳实践
Security Data Amazon Security Lake 集中 Cloud、On-Prem 和自定义安全数据
Organization Governance SCP 跨 AWS Accounts 管理服务使用范围
Network Telemetry VPC Flow Logs 记录 VPC ENI 的 IP Traffic

AWS 还指出，这些服务可以通过 Amazon EventBridge 集成，以自动响应安全风险。（AWS PDF 正文 p.14）

这意味着一个成熟的 AWS Semiconductor Security Architecture 应该同时具有：

1
2
3
4
5
6
7

Preventive Controls
+
Detective Controls
+
Central Telemetry
+
Automated Response

而不是只部署防火墙。

25. Shared Responsibility Model：不要把云安全责任误解成 AWS 全包

AWS 明确区分：

1
2
3
4
5

Security OF the Cloud
        AWS

Security IN the Cloud
      Customer

（AWS PDF 正文 p.3）

对半导体研发环境而言，客户仍然需要对很多关键控制负责，例如：

  • IAM 权限；
  • Guest OS；
  • Patch；
  • Network Access；
  • Remote Desktop Credential；
  • EC2 IAM Role；
  • Linux 文件权限；
  • Egress Policy；
  • Data Classification；
  • Project Access；
  • EDA Tool 和 License Policy。

因此：

“迁移到 AWS”不是把研发环境安全责任转移给 AWS，而是把物理云基础设施责任交给 AWS，同时企业继续承担工作负载层和数据层责任。

这是评估云安全投入时必须先统一的认识。

26. Compliance：AWS 提供证据与工具，不等于自动合规

AWS 列出了：

  • AWS Artifact；
  • AWS Audit Manager。

Artifact 可提供 ISO、NIST、FedRAMP 等相关合规报告；Audit Manager 可以把合规要求映射到 AWS Usage Data，并通过预置或自定义 Framework 收集证据。（AWS PDF 正文 p.3）

AWS 还提到，可将 Artifact 报告与企业对云资源的自身评估结合，支持 ITAR 等法规相关的合规工作。

准确理解应当是：

AWS 提供底层云服务的合规证据和自动化审计能力，但企业自己的 Workload Architecture、Data Flow、IAM、Region、Operating Process 仍然需要独立满足适用要求。

不能简单表述成“使用某个 AWS 服务即可获得某项合规认证”。

27. Ransomware：本文只给原则，没有给完整恢复架构

AWS 单独讨论了 Ransomware，原因也很符合半导体行业特点：

  • 攻击会造成业务中断；
  • 业务中断可能对供应链产生级联影响；
  • 可能造成高价值 IP 丢失。

AWS 要求保护所有：

1
2
3

store
process
transmit

数据的系统，并进一步引用其他 AWS Ransomware 资料。（AWS PDF 正文 p.15）

但本指南没有提供一套完整的：

1
2
3
4
5
6

Backup
Immutable Backup
Recovery Account
RPO / RTO
Restore Validation
Cyber Recovery

实施架构。

因此，如果企业要把本文作为 Semiconductor Cloud Security 基线，Ransomware Recovery 仍应作为独立 Architecture Workstream。

28. 从 IT 架构师角度看，AWS 这份方案真正成熟的地方

这份文档的价值不在于告诉我们“买哪一种服务器”，而在于把半导体研发云的几个关键边界定义清楚。

28.1 研发环境首先是数据边界

不是：

1

一批 EC2 + 一套 EDA

而是：

1
2
3
4
5

Identity Boundary
Network Boundary
Data Boundary
Encryption Boundary
Audit Boundary

28.2 Remote Desktop 只是 Access Plane

工程师通过 Remote Desktop 进入环境，但真正的 EDA 计算资源可以独立放在 Compute Cluster 后面。

28.3 第三方不是主研发环境中的普通用户

Collaboration Chamber 把第三方协作从“身份授权问题”升级为“独立安全域问题”。

28.4 Hybrid Cloud 是一等场景

参考架构直接包含 On-Prem Network、Lab Equipment、Direct Connect 和 Transit Gateway，而不是假设所有研发系统全部迁入 AWS。

28.5 安全治理是平台能力

Organizations、SCP、CloudTrail、GuardDuty、Inspector、Security Hub、Security Lake 等不是项目自己逐套临时搭建，而是可以作为企业级 Cloud Foundation 统一提供。

29. 对现有芯片公司 Infra 的对应关系

可以用下面的方式理解 AWS 架构与传统 EDA Data Center 的关系：

传统芯片研发 Infra AWS 文档中的对应能力
Linux Desktop / VDI EC2 + Amazon DCV；文档也列出 NoMachine、OpenText Exceed TurboX
Login / Interactive Node Remote desktops
Batch Scheduler Scheduler（文档未指定产品）
Compute Farm Compute cluster
EDA License Infrastructure License Server
NetApp / Shared NAS / HPC FS Amazon FSx family
Object / Archive / Transfer Layer Amazon S3
IDC 专线 AWS Direct Connect
Network Hub AWS Transit Gateway
AD / Enterprise IdP IAM Identity Center / AWS Directory Service
Unix Project Permission Linux file permissions
Firewall / ACL Security Group、NACL、AWS Network Firewall
Internet Proxy Squid / Internet Proxy
Private Cloud Service Access VPC Endpoint
API Audit CloudTrail
Network Audit VPC Flow Logs
Vendor / Contractor Isolation Zone Collaboration Chamber

这个表的价值在于说明：

AWS 并没有改变 EDA 研发的核心工作模型，而是在传统的 Desktop + Scheduler + Compute + Storage + License 模型外围增加云原生的身份、网络、审计、自动化和临时环境能力。

30. 企业真正落地时，建议拆成七个 Architecture Workstream

这部分是基于 AWS 本文形成的实施拆分，不是 AWS 原文的项目计划。

Workstream 1：Cloud Foundation

先解决：

  • AWS Organizations；
  • Account Boundary；
  • IAM Federation；
  • Network；
  • Direct Connect；
  • Central Logging；
  • KMS；
  • Security Baseline。

不要一开始就以“安装 EDA 软件”为项目主线。

Workstream 2：R&D Identity and Access

定义：

  • Workforce Federation；
  • Privileged Access；
  • Linux Identity；
  • Project Group；
  • PDK/IP Data Entitlement；
  • Service Account；
  • Third-party Identity。

Workstream 3：Storage and Data Mobility

分别测量：

  • Capacity；
  • File Count；
  • Metadata Rate；
  • Throughput；
  • Latency；
  • Concurrent Client；
  • Permission Semantics；
  • Migration Window。

再决定：

  • FSx for ONTAP；
  • FSx for Lustre；
  • FSx for OpenZFS；
  • S3；
  • DataSync / SnapMirror。

Workstream 4：Remote Engineering Experience

验证：

  • SSH；
  • Amazon DCV；
  • ETX / NoMachine（如企业已有）；
  • WAN Latency；
  • Interactive GUI；
  • Session Security；
  • Clipboard / File Transfer Policy；
  • Credential Handling。

AWS 本文没有提供这些产品之间的性能比较，因此必须 PoC。

Workstream 5：Compute and Scheduler

基于现有 EDA Flow 验证：

  • Interactive vs Batch；
  • Scheduler Integration；
  • Compute Elasticity；
  • Queue Policy；
  • Job Startup；
  • Storage Dependency；
  • License Dependency。

本文只给出了 Scheduler/Compute Cluster 的架构形态，没有实现细节。

Workstream 6：License Architecture

单独确认：

  • EDA Vendor Contract；
  • Cloud Permission；
  • Host Binding；
  • Network Path；
  • HA；
  • DR；
  • Rehost；
  • Audit。

不要因为 AWS 图中画了 License Server 就假定所有 Vendor License 都可以无条件迁移。

Workstream 7：Security and Collaboration

完成：

  • VPC Endpoint；
  • Egress Proxy；
  • Network Firewall；
  • Central Logging；
  • Security Monitoring；
  • Collaboration Chamber；
  • Partner Data Curation；
  • Chamber Lifecycle；
  • Ransomware Recovery。

31. PoC 不应只做 CPU Benchmark

如果以这份 AWS 指南为安全基线，再开展 EDA Cloud PoC，至少应从以下四个维度评价。

31.1 Engineering Performance

使用真实 Flow，而不是只运行通用 CPU Benchmark：

1
2
3
4
5
6

EDA Job Runtime
Regression Throughput
Interactive Response
Scheduler Queue Time
Storage Wait
License Wait

具体 EDA 工具和指标需企业自行定义，AWS 本文没有给出。

31.2 Storage

重点验证：

1
2
3
4
5
6
7

Metadata
Small File
Large Directory
Concurrent Access
NFS Semantics
Permission
Snapshot / Recovery

31.3 Security

验证：

1
2
3
4
5
6
7

Who can log in?
Who can read project data?
Can compute nodes reach Internet?
Can users upload/download data?
Can third parties see unrelated IP?
Are transfers logged?
Can administrators delete audit history?

31.4 Cost

至少区分：

1
2
3
4
5
6
7

Always-On Infrastructure
Elastic Compute
Persistent Storage
Data Transfer
Security Services
Software / License
Operations

不能把“EC2 单价 × 核数”当成完整 TCO。

32. 对 AWS 这份指南的最终评价

从专业架构角度，这份文档的定位很清楚：

它是一份 Semiconductor Secure Development Environment 的安全架构指南，而不是 EDA Cloud 的完整工程设计书。

它真正有价值的内容有四类：

第一，给出了半导体研发云的信任边界

重点不是服务器，而是 IP、身份、数据流和出口。

第二，明确了研发环境的典型组成

在 Collaboration Chamber 参考架构中可以看到：

1
2
3
4
5
6
7
8
9

Remote Desktop
Scheduler
Compute Cluster
License Server
Storage
Direct Connect
Transit Gateway
Partner Access
Security Services

这说明 AWS 对芯片研发 Infrastructure 的基本形态有明确认知。

第三，提出了很有行业针对性的第三方隔离模型

Collaboration Chamber 比“给 EDA 厂商开 VPN + 主研发账号”的模式更值得研究，因为它从根本上缩小了第三方可见的数据和系统范围。

第四，把安全控制从设备级提升到了平台级

IAM、Endpoint、KMS、Proxy、Flow Logs、CloudTrail、GuardDuty、Inspector、Security Hub、Security Lake、Organizations 等可以形成统一的平台治理，而不是每个项目单独建设。

但这份文档也有明显边界：

  • 它没有回答 EDA Compute 应如何 sizing；
  • 没有回答哪个 Scheduler 最合适；
  • 没有给出 License 实施方案；
  • 没有给出 EDA Storage Benchmark；
  • 没有给出具体 Cost Model；
  • 没有给出完整 DR/Ransomware Recovery Architecture。

因此，在企业真正进行“EDA 上 AWS”的技术决策时，应把本指南作为Security Architecture Baseline，再分别补齐：

1
2
3
4
5
6
7
8

Compute Architecture
Storage Architecture
Scheduler Architecture
License Architecture
Remote Desktop Architecture
Hybrid Network Architecture
Cost Model
DR / Cyber Recovery

这才是一套可以进入 PoC 和生产评审的完整 Semiconductor R&D Cloud Architecture。

附录 A：关键结论与 AWS 原文页码对应

本文关键结论 AWS PDF 正文页码
半导体研发环境必须严格控制 IP 访问，防止未授权数据外泄 p.1
AWS 强调弹性、规模经济和自动化 p.2
Shared Responsibility Model p.3
AWS Artifact / Audit Manager p.3
Well-Architected / CAF / SRA / Security Maturity Model p.4
Authentication、Authorization、Transfer Logging、Secure Data Flow、Encryption、Egress Control p.5
IAM Least Privilege p.5–6
IAM Identity Center、Federation、Directory Service、Linux Permissions p.6
VPC Endpoint / Endpoint Policy p.6
S3、FSx、DataSync p.6–7
FSx for ONTAP / Lustre / OpenZFS p.7
SnapMirror p.7
Centralized Logging in Dedicated Account p.7
Network Firewall、DNS Firewall、WAF、SG、NACL、SCP、VPC Flow Logs p.7
KMS / CloudHSM、TLS p.7
Outbound Traffic 通过 Network Firewall / Squid 限制和记录 p.7–8
Network Access Analyzer / Data Perimeter p.8
Partition / Region / AZ / Local Zone / Data Residency p.8–9
Remote Visualization、SSH、GUI Remote Desktop p.10
Amazon DCV p.10
DCV Connection File 密码字段未加密的提醒 p.10
NoMachine / OpenText Exceed TurboX p.10
EC2 Remote Desktop 的客户安全责任 p.10–11
Collaboration Chamber 原则 p.11
Collaboration Chamber Reference Architecture p.13
CloudTrail / GuardDuty / Inspector / Security Hub / Security Lake / SCP / Flow Logs p.14
Ransomware 总体原则 p.15
AWS HPC、Cloud Storage、FSx for ONTAP 的平台价值描述 p.16
Conclusion p.17

附录 B：对本文引用边界的说明

本文只把 AWS PDF 中可以直接确认的服务、架构元素和安全原则归为“AWS 明确内容”。

以下内容在文中出现时属于架构分析或实施建议，不应视为 AWS 官方产品结论：

  • 将 AWS 安全控制映射到企业 Semiconductor R&D Platform；
  • 对传统 EDA Data Center 与 AWS 组件做的逻辑对应；
  • Architecture Workstream 的划分；
  • PoC 评价方法；
  • 对成本、License、Unix 权限、项目治理的工程化判断。

对于具体 EDA Vendor、Instance、Scheduler、License、Storage 性能和商业合同，应另行使用 AWS、EDA Vendor、Storage Vendor 的官方资料做专项验证。

参考资料

Amazon Web Services, Securing semiconductor development environments on AWS, AWS Prescriptive Guidance.

官方 PDF：
https://docs.aws.amazon.com/pdfs/prescriptive-guidance/latest/strategy-aws-semicon-workloads/strategy-aws-semicon-workloads.pdf

Initial publication: June 20, 2023.