很多人在做跨账号业务时，会遇到一个绕不开的问题：两个阿里云账号各自有ECS，怎么让它们之间走内网通信？比如你手头有个账号A，跑着业务服务；另一个账号B，部署着数据库。为了安全和性能，你不想把数据库暴露公网，但又希望账号A的ECS能直接访问。其实阿里云安全组提供了一个非常干净的方案——跨账号授权。这篇文章手把手带你从0到1，实现同地域下不同账号ECS的内网互通。

一、准备工作：先把账号ID摸清楚

登录阿里云控制台，鼠标悬停在右上角头像上，就能看到一个“账号ID”的入口。点击进去，一串纯数字就是你的阿里云账号ID。这个ID很关键，后面配置跨账号安全组规则时，系统会让你填写“账号ID”，填错了会直接导致授权失效。同样，你需要提前拿到对方的账号ID，建议让同事在浏览器无痕模式下进入控制台后告诉你，避免串号。

同时，确认两台ECS都在同一个地域。比如都在华东1（杭州）。如果不在一个地域，安全组跨账号授权也允许，但底层网络一般需要靠云企业网打通，而且会有跨地域带宽费用，不在本文讨论范围内。我这次实操就是华东1，两个账号的两台ECS，都是CentOS系统。

二、打通网络：别急着配安全组，先看VPC能不能通

很多人会忽略这一点：安全组只管“放行”或“拒绝”，但前提是报文得能到达目标机。如果两个ECS不在同一个VPC，安全组规则再宽松也白搭，因为网络路径根本不通。

创建VPC对等连接并规避网段重叠

所以第二步，需要先把两个账号的VPC之间连起来。同地域最简单的方式是创建“VPC对等连接”。对等连接在阿里云同地域情况下是免费且不限带宽的，非常适合诉求。去“专有网络VPC”控制台，左侧找到“VPC对等连接”，创建实例时选择另一个账号的VPC，输入对方账号ID和VPC ID，等待创建成功。如果不喜欢对等连接，也可以用云企业网（CEN）把两个VPC加载进来，效果一样。

这里有一个坑：两个VPC的网段不能重叠。如果重叠了，路由表会冲突，对接后你会发现自己连不上任何一台ECS。最好提前规划好，比如A账号VPC网段用192.168.1.0/24，B账号用172.16.1.0/24。

临时放行并测试网络连通性

网络打通后，你可以临时在A账号的ECS上ping一下B账号ECS的私网IP。如果ping不通，甚至都ping不通网关，就说明对等连接没生效或路由没配好。先别急着调安全组，因为安全组默认会放行出方向，入方向拒绝好像也拒绝不了ICMP？实际上入方向规则默认拒绝。所以要测试网络通，最好先临时加一条放行ICMP的入方向规则，或者直接在两台ECS上分别用相对被访问方安全组加一下，但这样有点绕。我的习惯是：先在两台ECS上把系统防火墙关了，然后给安全组临时放行全部入方向，等网络确认通了再去删掉，再精确配置。注意，不要在生产环境这样干。

三、核心配置：安全组跨账号授权

网络打通之后，接下来最关键的一步就是配置安全组。假设A账号的ECS需要访问B账号的ECS（B作为数据库服务器），那么操作方向是在B账号的安全组上添加入方向规则，允许来自A账号安全组的流量。

以来源安全组ID配置跨账号入方向规则

具体操作步骤如下：以B账号身份登录阿里云控制台，进入ECS的"安全组"列表，找到B账号ECS实例所绑定的那个安全组，点击"管理规则"，切换到"入方向"页签，然后点击"手动添加"。

这里有一个关键点：在"源"这一栏，不要选择"IP地址"，而要选择手动添加后出现的"安全组ID"类型。阿里云安全组支持以另一个安全组作为源，并且支持跨账号填写。当您选择"安全组ID"作为源后，会出现两个输入框：一个是"安全组ID"，另一个是"账号ID"。这时把A账号的ECS所属安全组ID填进去，再把A账号的账号ID填进去。

需要特别注意的是：这里填的是发起访问一方（即来源方）的安全组ID，不是被访问方自己的安全组ID。安全组ID形如"sg-xxxx"，可以在A账号的安全组列表里查到。

端口范围根据实际服务填写。如果B账号装的是MySQL，就填3306/3306；如果是Redis，填6379；如果是SQL Server，填1433。协议类型选择对应的TCP即可。授权对象就写来源安全组。如果你只是测试想要放开全部端口，也可以写-1/-1，但生产环境千万别这么干，风险极高。

填完之后点击保存。这个时候B账号的那个安全组规则就会类似于"放行来自账号ID为XXXX，安全组ID为sg-xxxx的所有实例的流量"。这个规则非常精准，就算A账号的ECS弹性公网IP或私网IP发生了变化，也不影响访问，因为规则是按安全组身份来识别的，而不是按IP地址。这正是安全组跨账号授权的核心价值所在。

四、别忘了ICMP：验证连通性时的坑

补充ICMP规则验证内网连通性

配置完成后，我习惯先从A账号的SSH上直接ping一下B账号的私网IP，结果发现还是ping不通。排查了很久才发现，入方向安全组规则根本没有放行ICMP协议。

很多教程会说ping是默认放行的，实际上安全组默认对入方向是拒绝所有。你只加了3306的端口规则，而ping走的是ICMP协议，端口规则不涵盖ICMP，所以ping报文依然被拒。

解决方式有两种：

一种是在B账号的安全组上再添加一条入方向规则，协议选择"ICMP"，源同样选择A账号的安全组ID和账号ID，授权后ping就通了。

另一种是你干脆用telnet或者nc去测试端口，比如在A账号上执行"telnet B的私网IP 3306"，能通就说明业务访问没问题，不用纠结ping通不通。

我建议如果你是做数据库访问的，直接测试端口即可。ping不通不代表业务不通，反之，ping通了也不代表TCP端口能通。别让ICMP干扰你的判断，端口测试才是验证业务连通性的正确方式。

五、反向访问：如果两边都要互访怎么办

有时候不只是单向访问，比如A要读B的数据库，B要回调A的接口。那就需要两边安全组都配置。

在A账号的安全组上，同样添加一条入方向规则，源填B账号的安全组ID和B账号的账号ID，端口写A服务监听的端口，比如8080。这样两边就都放行了，也就是实现了双向内网互通。

这里很多人容易绕晕：安全组规则里的"入方向"是指进入本安全组所关联的ECS的流量。所以谁是被访问方，就在谁的安全组上添加入方向规则，源是主动发起访问方。记住这个原则就不会配反：被访问方加入方向规则，源填发起方的安全组ID和账号ID。

六、检查与排错

如果配置完之后还是不通，按以下顺序逐一排查：

第一，检查两个VPC之间的对等连接或云企业网状态是否正常。去看"专有网络VPC"控制台里对等连接的"实例状态"，是不是"已激活"。如果是"未建立"，需要接受对方账号的申请。对等连接需要双方都接受才能生效，这一步经常被遗漏。

第二，确认源安全组ID和账号ID没有填错。账号ID是阿里云账号的主号，不是RAM用户的ID。我曾经就填过RAM子账号的ID，结果规则一直不生效，后来才发现要填主账号的账号ID。安全组ID也要仔细核对，确保填的是发起方ECS所绑定的那个安全组。

第三，检查ECS系统内部的防火墙。CentOS默认可能开着firewalld，Ubuntu可能存着iptables规则。你需要检查系统防火墙是否也放行了对应端口。安全组是云上第一道防线，系统防火墙是第二道，两道都要通才行。可以用"systemctl status firewalld"查看防火墙状态，用"firewall-cmd --list-all"查看已放行的规则。

第四，查看安全组规则是否符合优先级。阿里云安全组规则默认是叠加判断的，只要有匹配的拒绝规则，就会拒绝，即使同时存在允许规则。如果历史遗留的拒绝规则把来源安全组拒绝了，记得调整规则顺序或删除冲突的拒绝规则。

第五，确认路由是否正常。在对等连接已激活的前提下，检查两端VPC的路由表中是否有指向对端VPC网段的路由条目。如果路由缺失，即使安全组放行了，流量也找不到正确的路径。

七、这件事的价值

通过安全组跨账号授权，你不用在安全组里一个个填IP地址，也不用担心ECS重启后IP变化导致规则失效。安全组作为逻辑上的身份凭证，把整个安全组合并成一个可信任的源对象，管理起来非常简洁高效。

这种管理方式在微服务架构和跨团队协作中特别有用。比如多个业务账号的ECS需要访问同一个数据库账号的RDS或ECS自建数据库，只需在数据库侧安全组中逐一授权各业务账号的安全组即可，无需关心每个实例的具体IP。再比如团队之间协作开发时，可以直接按安全组授权，而不必反复确认和更新IP白名单。

而且这个方案完全走阿里云内网，不占用公网带宽，延迟低，安全风险小。没有了公网暴露面，互联网上的扫描和爆破基本可以无视。数据库不暴露在公网上，从根本上降低了被攻击的风险。

希望这篇实操能帮你少走弯路。如果你在配置中遇到问题，不妨回看一下"账号ID"和"安全组ID"这两处，十有八九是它们写反了或者填错了。另外，别忘了ICMP和系统防火墙这两个常见的坑。祝上线顺利。