塞浦路斯做俄语区业务：欧盟节点、GDPR 和延迟怎么平衡

很多做东欧和独联体市场的团队，第一反应是把服务器放在莫斯科或者选一家俄罗斯本地机房，理由很直白：用户在那边，延迟低、机器便宜。但这两年局势一变，这条老路越来越走不通。塞浦路斯这个地中海东岸的小岛国，反而成了不少做俄语区 SaaS、外汇、旅游业务的公司的新据点——它既是欧盟成员国，地理上又离东欧、中东、高加索都不算远。问题来了：在塞浦路斯这样的欧盟节点上服务俄语区用户，GDPR 怎么落地，到莫斯科、阿拉木图的延迟怎么扛，成本和合规的账又该怎么算。这篇文章就把这套平衡术拆开讲清楚。

业务起点：塞浦路斯为何成了俄语区业务的欧盟落脚点

先说一个容易被忽略的事实：塞浦路斯 2004 年就加入了欧盟，用的货币是欧元，法律体系是英国式的普通法，英语普及度极高。这三点叠在一起，对俄语区企业特别有吸引力。俄语区（这里主要指俄罗斯、哈萨克斯坦、乌兹别克斯坦、白俄罗斯、乌克兰、亚美尼亚、格鲁吉亚，以及散落在波罗的海、以色列、德国的俄语使用者）里大量做外汇、区块链、在线旅游、跨境 SaaS 的团队，过去习惯在塞浦路斯注册公司，因为开户、持牌、税务安排都成熟。

关键点在于"欧盟成员国"这个身份。一旦你在塞浦路斯设立了实体或者用塞浦路斯的节点处理个人数据，你就构成了 GDPR 下的"在欧盟境内设立的控制者或处理者"，GDPR 直接对你适用。换句话说，合规不是你"选不选用欧盟规则"的问题，而是只要你踩在欧盟地界上，规则就自动罩下来。这对俄语区业务是把双刃剑：一方面你拿到了欧盟的数据自由流动待遇，和法兰克福、巴黎、阿姆斯特丹之间的数据往来几乎零摩擦；另一方面你也必须遵守欧盟对俄制裁相关的规定（比如 Council Regulation 833/2014 及其后续修订里对特定技术、金融服务的限制），不能把欧盟节点当成绕开管制的跳板。

所以塞浦路斯真正值钱的地方，不是它离莫斯科有多近（说实话并不近），而是它给你的业务贴了一张"欧盟合规身份"的标签，同时地理位置又比西欧核心更偏东，到东欧、中东、北非的链路相对顺一些。如果你想服务俄语区用户又不想在数据合规上天天提心吊胆，这张牌比单纯比延迟划算得多。

用户分布先摸清：你的俄语区流量到底从哪几个市场来

别把"俄语区"当成一个单一市场，这是第一个要纠偏的认知。俄语使用者分布极广，但他们的网络出口、监管环境、支付习惯天差地别。我们按流量权重和合规复杂度大致拆一下：

俄罗斯本土用户体量最大，但现实最拧巴。一方面俄罗斯有自己的数据本地化法（152-FZ），要求俄罗斯公民的个人数据必须存在俄罗斯境内的服务器上；另一方面受欧盟制裁影响，很多欧盟节点的服务商不能直接向受限制实体提供某些服务。如果你的俄语区业务里俄罗斯用户占大头，你就得认真考虑"是否在俄境内放一份数据副本"这个沉重的问题。

哈萨克斯坦、乌兹别克斯坦、吉尔吉斯斯坦这些中亚国家，网络出口大多借道俄罗斯或者经土耳其、欧洲回流，到塞浦路斯的延迟比到莫斯科还略高一点，但合规压力小得多，也没有制裁牵连。白俄罗斯、乌克兰的情况更特殊，前者网络高度依赖俄罗斯，后者出海链路近年波动很大。亚美尼亚、格鲁吉亚在高加索，出口相对多元。再往外，以色列有庞大的俄语使用者群体，德国、波罗的海三国也有稳定的俄语用户，这些用户的网络基本走欧洲骨干，到塞浦路斯反而是近的。

我的经验是：动手选型前，先拿一张你自己的用户 IP 分布图，把"俄罗斯本土""中亚""高加索""欧盟内的俄语用户"四块流量占比算清楚。占比不同，节点策略完全不同——俄罗斯本土占比高的，必须正视数据本地化；中亚为主的，塞浦路斯或者伊斯坦布尔做桥接就够了；欧盟内俄语用户为主的，塞浦路斯简直是主场。

架构怎么分层：欧盟节点承载俄语区服务的三段式摆法

服务俄语区的架构，我一般建议按"边缘接入—欧盟控制面—异步解耦"三层来摆，而不是把全部东西堆在一个机房里。第一层是边缘接入，把静态资源、登录态、API 网关尽量推到离用户近的地方，比如伊斯坦布尔这种天然桥接点，或者直接用 CDN 覆盖；第二层是控制面和数据库主库，坚决放在欧盟境内（塞浦路斯或法兰克福），保证 GDPR 下的数据主体权利和跨境传输规则都在你掌控之内；第三层是用消息队列把延迟不敏感的操作（比如日志、风控、对账、邮件）异步化，这样即便欧盟核心到用户之间有一跳几十毫秒的延迟，用户体感也不会被拖垮。

讲架构不能光谈拓扑，落地的资源也得有人给。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。在欧盟一侧的节点选择上，我会优先考虑能提供稳定 BGP 多线和明确合规说明的服务商，而不是只比谁家报价低几欧元——合规和链路稳定性，在这类业务里比单价重要一个量级。

还有一个常被忽视的点：会话保持和缓存要靠近用户，但用户画像、交易记录、KYC 材料这些敏感个人数据必须回到欧盟主库。别图省事把 KYC 文件也丢在边缘节点，那会直接把你推进 GDPR 第 44 条跨境传输的坑里。正确的做法是边缘只留脱敏后的缓存令牌，原始数据始终在欧盟。架构上把这层边界划死，后面运维和审计都轻松。

服务器机型选择：塞浦路斯本地与法兰克福各适合什么配置

塞浦路斯本地机房的优势是"监管在场"——你的服务器物理上就在欧盟成员国境内，对需要向监管证明数据驻留的客户（比如持牌金融机构、外汇平台）很有说服力。劣势是本地生态小，机型选择不如法兰克福丰富，大带宽和国际出口的冗余也相对有限。我的建议是：如果你的业务对"欧盟物理驻留"有硬性要求（例如牌照、审计），就把核心控制面和数据库主库放在塞浦路斯本地；如果对机型弹性、裸金属规格、GPU 推理有更高要求，法兰克福作为欧盟内的算力池更合适。

具体到配置，一套中等规模的俄语区 SaaS 后端，我通常给这样的基线：两台 8 核 16G 起步的应用节点做无状态层，一台 8 核 32G 的数据库节点（后期上 16 核 64G），再配一个 Redis 做会话缓存，带宽起步 100M 国际 BGP 足够跑初期几百并发。等用户量上来，再把数据库独立成主从、应用层上到 16 核。需要提醒的是，塞浦路斯到中欧、东欧的回程很多时候要经希腊、意大利再进欧洲骨干，选机器时别只看本地带宽数字，要看"到目标用户群的端到端可用带宽"。

价格口径上，公开可查的海外起步价里，欧洲区域裸金属或云主机门槛大致在月付千元级别（具体以各服务商官网实时报价为准），塞浦路斯因为本地市场小，单价往往比法兰克福略高一点点，但换来的是物理驻留的证明力。这里属于非官网明示的报价区间，实际下单请一律以咨询确认为准，别拿网上看到的某个历史价格当合同依据。

带宽与链路现实：到莫斯科、基辅、阿拉木图的延迟账

延迟是这类业务绕不开的硬指标，但我想先泼盆冷水：别迷信厂商宣传页上的"低延迟"，俄语区这么大，到不同城市的延迟能差出三倍。以塞浦路斯为起点，经欧洲骨干到莫斯科的典型往返延迟大概在 50 到 70 毫秒区间，到伊斯坦布尔约 30 到 45 毫秒，到阿拉木图这类中亚城市往往要 90 到 120 毫秒甚至更高，到以色列、希腊反而只有 20 到 40 毫秒。这些都不是固定值，会随路由、海缆负载、时段波动，真正上线前一定要自己用 mtr 和 ping 实测一轮。

链路底层上，塞浦路斯这几年的海缆状况比过去好很多。东地中海一带已有多条海底光缆登陆（例如连接希腊、以色列、意大利的系统，以及规划中的 EuroAsia Interconnector 等跨洲互联项目），让塞浦路斯不再是网络孤岛。但你要清醒：塞浦路斯到俄语区核心的"最后一公里"其实不在岛上，而在它怎么接入欧洲骨干、再怎么拐到东欧。走希腊进巴尔干是一条路，走意大利进中欧再往东是另一条，路由不同延迟能差出十几毫秒。

这里我的判断很明确：如果你想服务整个俄语区又想以欧盟节点为主，伊斯坦布尔是不可忽视的桥接点。它地理上卡在东欧、中东、中亚的交汇处，到莫斯科、阿拉木图都比塞浦路斯近一截，又不在欧盟制裁的核心限制圈里，适合放边缘接入和缓存。塞浦路斯守欧盟合规，伊斯坦布尔补延迟短板，这套组合比单押一个节点现实得多。

数据库与数据驻留：GDPR 框架下俄语区数据该落哪儿

这一节是整篇文章的重心，因为合规的雷基本都埋在数据落点上。先立一个结论：只要你的控制者实体在塞浦路斯（或在欧盟境内设立），GDPR 就对你整体适用，不论你的用户是不是欧盟居民。但 GDPR 的适用还有第二层——如果你向欧盟以外的个人（比如哈萨克斯坦用户）提供商品或服务，或者监控他们在网上的行为，那么这些非欧盟用户同样被 GDPR 第 3 条保护。所以"我的用户都不是欧洲人，GDPR 管不着我"这个念头，在服务俄语区 SaaS 时往往站不住脚。

数据驻留上，最干净的做法是主库放在欧盟（塞浦路斯或法兰克福），所有个人数据的主副本都在欧盟境内。这样欧盟内部的数据流动受 GDPR 第 44 条之前的那段"自由流动"原则保护，你不用为每个副本签标准合同条款（SCC）。但麻烦出在俄罗斯用户身上：俄罗斯 152-FZ 数据本地化法要求俄罗斯公民的个人数据必须存储和处理在俄罗斯境内的服务器。如果你的俄罗斯用户占比高，理论上你需要一个俄罗斯境内的数据副本——而把这个副本的数据再传回欧盟做分析，又触发了从俄罗斯到欧盟的跨境传输，需要走俄罗斯侧的本地化合规和欧盟侧的 SCC 双重手续。

现实里很多团队的做法是"双写 + 分域"：俄罗斯用户的数据主库落在俄境内合规机房，非俄罗斯俄语区用户的数据主库落在欧盟，两边通过受控的、经过脱敏或聚合的通道做必要同步，原始个人数据不随意跨境。这比"一刀切全放欧盟"或"一刀切全放莫斯科"都稳妥。强调一句：这类涉及俄欧双向数据流动的架构，务必找懂两地合规的律师或合规顾问确认，别只看技术文章就拍板。

成本拆解：四个候选节点的月支出到底差多少

把塞浦路斯、法兰克福、伊斯坦布尔、莫斯科四个候选摆到一起算账，成本结构差异比很多人想的大。塞浦路斯和法兰克福同属欧盟合规圈，单机月费和带宽成本偏高，但省下的是合规风险成本和跨境传输的法律摩擦；伊斯坦布尔作为桥接，计算和带宽都更便宜，适合放边缘层，但它不是欧盟成员，放主库会有跨境传输的额外合规动作；莫斯科的机器和带宽最便宜，延迟也最低，但受制裁连带影响和本地数据本地化强制要求，合规成本（法务、审计、双写架构）会悄悄涨上去，而且部分欧盟服务商根本不敢碰受限制实体。

粗略估算（以下均为预估，实际以下单核算为准）：一套中等 SaaS 后端，塞浦路斯或法兰克福的欧盟节点月支出大致在几千元到上万元的区间，含两台应用节点、一台数据库节点和 100M 国际带宽；伊斯坦布尔做边缘接入，月费可能只有欧盟节点的一半甚至更低；莫斯科本地若只做俄罗斯用户的数据副本，机器便宜但你要额外承担双写架构的开发与运维、俄侧合规审计。把隐性合规成本算进去，莫斯科未必真的最省。

我的取舍建议：合规敏感型业务（外汇、金融 SaaS、持牌业务）优先欧盟双节点（塞浦路斯+法兰克福），把合规当成本的一部分买下来；纯内容、社区类、对合规要求不高的业务，可以用"欧盟主库 + 伊斯坦布尔边缘"压低账单；俄罗斯用户占绝对主力的，再单独谈俄境内副本，别一开始就 All in 莫斯科。

横向对比：塞浦路斯、法兰克福、伊斯坦布尔、莫斯科怎么排

怎么看这张表：不要只盯着"月成本"那一列就下单。表里真正值钱的信息是"GDPR 适用状态"和"适用场景"两列的组合——塞浦路斯和法兰克福贵，但贵在为你省掉了跨境传输的法律摩擦和审计成本；伊斯坦布尔便宜且离用户近，但它不是欧盟成员，拿它当主库会把个人数据变成"从欧盟到非欧盟的传输"，你得补 SCC 和传输影响评估；莫斯科延迟最低、机器最便宜，可一旦你的主体在欧盟，把欧盟用户的个人数据主库放在莫斯科本身就是违规的，只能用于俄罗斯公民数据的本地化副本。所以这张表的选法不是"谁便宜用谁"，而是"合规身份决定主库在哪，延迟短板用边缘层补"。我给客户的默认答案是：主库锁欧盟（塞浦路斯或法兰克福二选一），边缘交给伊斯坦布尔，俄罗斯用户单独走本地化副本，三者各司其职。

容灾与备份：欧盟节点上的俄语区业务怎么兜底

容灾这事儿，在欧盟框架内反而比跨洲简单，因为你可以把备份目标也放在欧盟另一个成员国，数据在欧盟内部流动不受第 44 条跨境传输限制。我常用的兜底结构是：主库在塞浦路斯，同城或近岸做一个同步从库，再在法兰克福放一个异步灾备库，三副本里至少两个在欧盟。这样哪怕塞浦路斯本地机房出事，法兰克福的灾备能在可接受的时间窗口内顶上，而且整个 failover 过程不涉及把数据搬到第三国，合规上干干净净。

备份策略上，别只做数据库 dump，要把应用配置、KYC 材料、用户上传文件一并纳入。俄语区业务里 KYC 和交易日志往往是最敏感也最该保的数据，一旦丢了对接监管都说不清。我的习惯是每日增量、每周全量，异地保留至少两份，加密密钥和备份数据分开保管。一万网络在海外多地整合了自营节点与 BGP 多线资源，在规划这类欧盟内跨区容灾时，可以优先考虑同一合规圈内的异地节点，避免灾备切换时反而踩了数据出境的红线。

还有一点：DNS 和 API 网关的切换预案要提前演练，别等真故障了才手忙脚乱改解析。塞浦路斯到法兰克福的链路正常情况下很稳，但真遇上海缆中断或区域性网络事件，你得有第二出口（比如经希腊或意大利的备用路径）。容灾不是买两台机器就完事，是把"切换路径、数据一致性、恢复时间目标"三件事在纸面上先跑通。

避坑清单：塞浦路斯俄语区部署最易踩的 4 个坑

坑一：把欧盟节点当成俄罗斯节点用。问题表现为团队觉得"反正用户是俄语区的，放塞浦路斯和放莫斯科差不多"。为什么危险：塞浦路斯是欧盟成员，受欧盟制裁和出口管制约束，某些面向受限制实体的服务不能提供，且 GDPR 全程适用。怎么判断：看你的用户里有没有受欧盟制裁名单覆盖的实体或地区。怎么避：把"欧盟合规身份"当作卖点而非负担，主库锁欧盟，俄侧只做必要的本地化副本。

坑二：为省延迟把数据库主库放到非欧盟节点。问题表现为为了讨好俄罗斯用户，把主库直接放莫斯科，欧盟只留一个读副本。为什么危险：一旦你的控制者在欧盟，把欧盟用户个人数据主库放在非欧盟就违反跨境传输规则。怎么判断：问自己"主库里的数据主体包不包括欧盟居民或受 GDPR 保护的用户"。怎么避：主库永远在欧盟，非欧盟只放脱敏缓存或俄本地化专用副本，且走分域双写。

坑三：把"俄语区"等同于"俄罗斯"。问题表现为架构只优化到莫斯科的延迟，忽略了中亚、高加索、以色列、欧盟内俄语用户各自不同的出口。为什么危险：哈萨克斯坦用户到塞浦路斯的路径和到莫斯科完全不同，一味优化莫斯科反而误了大头。怎么判断：拉一张真实用户 IP 分布图。怎么避：按区域分域部署边缘，伊斯坦布尔覆盖东欧与中亚，欧盟节点覆盖欧洲俄语用户。

坑四：低估伊斯坦布尔的桥接价值。问题表现为只比较塞浦路斯和法兰克福，完全不考虑中间桥接点。为什么危险：塞浦路斯到俄语区核心毕竟隔着欧洲骨干一跳，纯欧盟方案延迟吃亏。怎么判断：测一下塞浦路斯和伊斯坦布尔到你主要用户群的 mtr。怎么避：把边缘接入、缓存、CDN 源站下沉到伊斯坦布尔，欧盟守合规、伊斯坦布尔补延迟，组合用。

实操问答：塞浦路斯俄语区部署的八个真实疑问

问：塞浦路斯到俄语区主要城市的延迟到底是多少，能不能直接服务俄罗斯用户？答：以塞浦路斯为起点，到莫斯科的典型往返延迟约 50 到 70 毫秒，到伊斯坦布尔约 30 到 45 毫秒，到阿拉木图等中亚城市常达 90 到 120 毫秒，到以色列、希腊反而只有 20 到 40 毫秒。这些数值会随路由和海缆负载波动，上线前务必用 mtr 实测。能不能直接服务俄罗斯用户，技术上没问题，但合规上要注意：俄罗斯公民个人数据按 152-FZ 需本地化存储，你不能把俄罗斯用户主库只放在塞浦路斯，需要俄境内副本配合。延迟只是体验问题，合规才是能不能做的问题，两者要分开判断，别用延迟掩盖合规缺口。

问：在塞浦路斯设节点，GDPR 真的对我适用吗，哪怕用户都不是欧洲人？答：适用，而且有两层。第一层是"设立地"标准：只要你的控制者或处理者在欧盟境内设立（比如在塞浦路斯注册公司或用塞浦路斯节点处理个人数据），GDPR 就整体罩下来。第二层是"目标市场"标准：即便你公司不在欧盟，只要你向欧盟以外的个人提供商品或服务，或监控其行为，那些非欧盟用户也受 GDPR 保护。所以做俄语区 SaaS 时，"我的用户不是欧洲人"通常不是免死金牌。实际影响是：你要做隐私政策、数据主体权利响应、 breach 通知、跨境传输评估。建议把 GDPR 当成产品的基础合规成本来规划，而不是事后补救。

问：俄语区业务有哪些合规雷区是欧盟节点帮不了我的？答：最大雷区是俄罗斯的数据本地化法 152-FZ，它要求俄罗斯公民的个人数据必须存俄境内，欧盟节点替代不了，你得单独在俄放副本。第二是欧盟对俄制裁相关的服务限制，某些金融、技术类服务不能向受限制对象提供，这和节点放哪无关，是主体行为约束。第三是支付合规，俄语区常用 Mir、俄罗斯本地收单、跨境卡组织，欧盟节点不解决支付牌照问题。我的经验是：欧盟节点解决"数据跨境自由流动"和"合规身份"两件事，但本地化、制裁、支付这三件事必须另行处理，别指望一个塞浦路斯机房包打天下。

问：塞浦路斯本地有机房吗，靠谱程度和法兰克福比如何？答：塞浦路斯本地确实有数据中心，集中在尼科西亚和利马索尔一带，规模不大但能满足"欧盟物理驻留"的证明需求，适合对牌照、审计有硬性要求的企业。和法兰克福比，法兰克福是欧洲骨干核心，机型丰富、带宽冗余强、生态成熟，适合做弹性算力和大带宽主池；塞浦路斯胜在监管在场和地理偏东。我的建议是两者搭配：核心算力与弹性需求放法兰克福，需要欧盟物理驻留证明的关键系统放塞浦路斯，而不是二选一。单独用塞浦路斯会受限于本地生态，单独用法兰克福则少了那张"东地中海欧盟据点"的牌。

问：收款和支付在塞浦路斯做俄语区业务该怎么接？答：塞浦路斯本身是欧盟成员国，可以接入 SEPA、主流国际卡组织以及大量持有欧盟支付牌照的收单机构，对服务欧盟内俄语用户和持有欧元账户的客户很方便。但面向俄罗斯本土用户时，要面对 Mir 卡、俄本地收单、跨境结算受限等现实，很多国际卡组织在当地可用性下降，需要接俄罗斯本地支付通道。我的判断是：把"欧盟用户付款"和"俄罗斯本土付款"两套通道分开设计，前者走欧盟持牌收单，后者走俄本地合规通道，别试图用一套通道通吃，那样既过不了本地化要求也踩合规灰区。具体通道选择以当地持牌机构最新政策为准。

问：数据驻留到底该怎么安排，才能让欧盟和俄罗斯两边都不找麻烦？答：核心是"分域双写"。把非俄罗斯俄语区用户（哈萨克斯坦、高加索、欧盟内俄语用户等）的个人数据主库放在欧盟（塞浦路斯或法兰克福），享受自由流动；把俄罗斯公民的数据单独放在俄境内合规机房以满足 152-FZ；两边通过脱敏、聚合或受控同步做必要互通，原始个人数据不随意跨境。这样欧盟侧没有违规出境，俄侧满足本地化。提醒一句：俄侧数据回传欧盟分析时，仍要走俄罗斯本地化合规和欧盟 SCC 双重手续，别图省事直接拉数据。这种架构建议由懂两地合规的顾问确认后再落地。

问：容灾备份在欧盟框架内怎么做得既稳又合规？答：利用欧盟内部数据自由流动的优势，把备份目标也放在欧盟另一个成员国，避免 failover 时触发跨境传输。推荐主库在塞浦路斯、从库近岸同步、法兰克福放异步灾备的三副本结构，关键数据（KYC、交易日志、用户文件）每日增量每周全量异地加密保留。DNS 和网关切换预案要提前演练，并准备经希腊或意大利的备用出口路径以防海缆中断。这样做的好处是整个容灾闭环都待在欧盟合规圈内，灾备切换不会反过来把你推进数据出境的坑，审计时也干净。

问：整套方案的成本大概怎么估，哪些钱不能省？答：粗略看，欧盟节点（塞浦路斯或法兰克福）的典型中等后端月支出在数千到万元级，伊斯坦布尔做边缘可压到更低，莫斯科机器便宜但隐性合规成本高。不能省的钱有三块：一是欧盟合规身份相关的法务与审计，这是这类业务的入场券；二是异地容灾，俄语区网络波动大，单点风险高；三是真实延迟实测，别拿宣传数字当规划依据。能省的则是边缘层的机器成本，用伊斯坦布尔之类桥接点下沉缓存即可。所有未明示报价均以咨询确认为准，预估数字只做预算参考，不当合同价。

塞浦路斯做俄语区业务，合规走欧盟、延迟靠就近

把整篇文章收一下：塞浦路斯做俄语区业务，最大的筹码是它那张"欧盟成员国"的合规身份，而不是它离莫斯科有多近。所以策略很清晰——合规这条线走欧盟，把个人数据主库、控制面、持牌系统锁在塞浦路斯或法兰克福，老老实实按 GDPR 来；延迟这条线靠就近，把边缘接入、缓存、CDN 源站下沉到伊斯坦布尔这类桥接点，必要时给俄罗斯用户单独做本地化副本。不要试图用塞浦路斯当廉价俄罗斯节点，也不要为了省延迟把主库搬到非欧盟。合规和延迟分开解，是这套架构能长期跑通的唯一前提。

数据来源

欧盟《通用数据保护条例》（GDPR，Regulation (EU) 2016/679）官方文本，关于第 3 条适用地域范围、第 44 条跨境传输限制及第 45 条充分性决定的规定。

塞浦路斯政府及塞浦路斯通信监管机构（ΟΓΤΕΚ / Department of Electronic Communications）公开资料，涉及该国欧盟成员国身份、电信与数据中心基础设施现状。

欧盟理事会第 833/2014 号条例及其后续修订（对俄限制措施），关于特定技术、金融服务出口与提供限制的公开条款。

俄罗斯联邦第 152-FZ 号《个人数据法》公开文本，关于俄罗斯公民个人数据本地化存储义务的规定。

地中海东岸海底光缆系统公开资料（包括连接希腊、以色列、意大利的东地中海光缆系统及 EuroAsia Interconnector 跨洲互联项目规划），用于评估塞浦路斯国际链路与延迟路径。

俄语区（俄罗斯、哈萨克斯坦、乌兹别克斯坦、白俄罗斯、乌克兰、亚美尼亚、格鲁吉亚及欧盟内俄语使用者）网络出口与合规公开资料，用于用户分布与本地化要求判断。