4. AWS 环境准备:VPC、子网、安全组、IAM 角色与策略

做 Cromwell 跨云部署,说实话,最让人头疼的不是 Cromwell 本身,而是底层网络和权限。网络不通、权限不足,这两类问题我踩过的坑比代码报错还多。本章我会带你一步步搭好 AWS 的网络基座和权限模型——说白了,就是给 Cromwell 造一条结实又安全的跑道。

核心知识点:VPC 网络隔离、子网拆分、安全组规则放行、IAM 角色与策略的最小权限原则。

4.1 VPC 与子网:给 Cromwell 划出一块安全区域

AWS 的 VPC 就是一个虚拟数据中心。你可以在里面自由划分网段,内部通信完全隔离。我个人习惯把 Cromwell 的 VPC 固定在一个可用区里,这样能减少跨 AZ 的数据传输费用。

创建 VPC 时,CIDR 块我建议用 10.0.0.0/16,预留够空间。子网至少需要两个:公有子网(Public Subnet)放堡垒机或 NAT 网关,私有子网(Private Subnet)放 Cromwell 的计算节点和数据盘。

# 创建 VPC
aws ec2 create-vpc --cidr-block 10.0.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=cromwell-vpc}]'

# 创建公有子网
aws ec2 create-subnet --vpc-id vpc-xxxxx --cidr-block 10.0.1.0/24 --availability-zone us-east-1a --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=cromwell-public-subnet}]'

# 创建私有子网
aws ec2 create-subnet --vpc-id vpc-xxxxx --cidr-block 10.0.2.0/24 --availability-zone us-east-1a --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=cromwell-private-subnet}]'
注意:私有子网默认不能访问外网。Cromwell 的后端如果需要下载 Docker 镜像,记得在私有子网挂一个 NAT 网关,否则任务会卡死在下载阶段。我曾经因为忘记配 NAT,整整排查了两个小时,才发现是网络问题。

4.2 子网选择:公有还是私有?

很多人在子网选择上犹豫。我直接给结论吧:凡是 Cromwell 的计算节点、数据库、缓存,全部丢私有子网。只有一种情况可以放公有子网——你希望 Jenkins 或跳板机直接通过公网 SSH 上去调试。

用途 推荐子网类型 说明
Cromwell Server 私有子网 通过 ALB 暴露,不直接开公网 IP
计算节点(Batch / EC2) 私有子网 通过 NAT 出公网
数据库(RDS / MySQL) 私有子网 严格不暴露公网
堡垒机 / 跳板机 公有子网 配安全组限制来源 IP
我的经验:Cromwell 的 MySQL 后端一定要和 server 放在同子网或同可用区,延迟能降到最低。跨 AZ 的数据库访问,每次查询多 2-3 毫秒,累计起来很可观。

4.3 安全组:别图省事,每条规则都要精打细算

安全组是 AWS 的虚拟防火墙。我常跟团队说一句话:安全组规则写得多不重要,写得对才重要。Cromwell 部署场景里,安全组至少要分三个:

  • Cromwell Server 安全组:放行 8080 端口给跳板机或 ALB。
  • 数据库安全组:只允许 Cromwell Server 安全组访问 3306 端口。
  • 计算节点安全组:允许 Server 安全组发起任务,并且能访问数据库。
# 创建 Cromwell Server 安全组
aws ec2 create-security-group --group-name cromwell-server-sg --description "Security group for Cromwell server" --vpc-id vpc-xxxxx

# 添加入站规则:只允许跳板机访问 8080
aws ec2 authorize-security-group-ingress --group-id sg-xxxxx --protocol tcp --port 8080 --cidr 203.0.113.0/24

# 创建数据库安全组,入站只允许 Cromwell Server 安全组
aws ec2 create-security-group --group-name cromwell-db-sg --description "Security group for Cromwll database" --vpc-id vpc-xxxxx
aws ec2 authorize-security-group-ingress --group-id sg-yyyyy --protocol tcp --port 3306 --source-group sg-xxxxx
踩坑提醒:安全组有状态性。如果出站规则没放行,计算节点拉 Docker 镜像会失败。我的习惯是:出站规则先允许所有流量,等稳定后再收紧。不过千万别入站也开 0.0.0.0/0,那是给自己找麻烦。

4.4 IAM 角色与策略:最小权限的动态钥匙

IAM 是 Cromwell 和 AWS 服务通信的凭证。你不应该用 Access Key 硬编码在代码里,而是用 IAM Role 挂载到 EC2 或 ECS 上。这样既安全又方便轮换密钥。

Cromwell 后端需要操作 Batch、EC2、S3、CloudWatch。我需要准备一个策略,涵盖这些操作,但尽量限定资源范围。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "batch:SubmitJob",
        "batch:DescribeJobs",
        "batch:TerminateJob",
        "batch:ListJobs",
        "batch:DescribeJobDefinitions",
        "batch:RegisterJobDefinition",
        "batch:DeregisterJobDefinition",
        "ec2:DescribeInstances",
        "ec2:DescribeInstanceTypes",
        "ec2:RunInstances",
        "ec2:TerminateInstances",
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket",
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "*"
    }
  ]
}
一个建议:如果你是用 Terraform 或 CloudFormation 管理,把 IAM Role 和 Policy 写成 Infrastructure as Code,这样版本可控,审计也方便。我团队现在所有 AWS 环境的变更都走代码 review,很少再出权限相关的故障。

4.5 整体架构概览

弄完上面几步,整个网络和权限骨架就搭好了。下面这张 SVG 图能帮你一眼看清各组件的关系。

Cromwell 跨云部署 · AWS 网络与权限架构 VPC: 10.0.0.0/16 公有子网 (10.0.1.0/24) 堡垒机 / 跳板机 NAT 网关(出公网) ALB(可选) 私有子网 (10.0.2.0/24) Cromwell Server MySQL 数据库 计算节点(Batch / EC2) IAM 权限层 IAM Role → Policy → Batch、EC2、S3、CloudWatch 操作 安全组规则 Server SG (8080) → DB SG (3306) → Compute SG(全放行)

记住这个逻辑:VPC 划网络分段,子网做隔离,安全组控制细粒度流量,IAM 解决动态授权。这四个要素配齐,Cromwell 的基础网络就算真正准备好了。接下来你才能放心部署 Server 和后端计算环境——如果连这一步都省了,后面全是坑。