AWS Random Graph Network Creates a New Due Diligence Item for Regulated Cloud Workloads

Regulatory action: AWS changes the network fabric, not the law

Amazon Web Services has begun deploying a new data center networking architecture called Resilient Network Graphs, or RNG, for core server networks. According to Amazon researchers in the paper Expanding into Reality: Random Graphs for Datacenter Networks, RNG uses random graph theory, a distributed routing protocol, and a passive optical device to flatten traffic paths inside large data centers. AWS says the design can improve throughput by up to 33 percent, reduce power use by up to 40 percent, and cut hardware needs compared with traditional hierarchical networks.

This is not a new privacy regulation. It is an infrastructure change by a major cloud provider. For compliance teams, that distinction matters. Regulators generally do not require customers to approve every router, topology, or fiber interconnect used by a cloud provider. They do require regulated organizations to understand material third-party technology risks, maintain appropriate security controls, document vendor oversight, and prove that business continuity and incident response obligations still work when underlying infrastructure changes.

The main legal frame is therefore existing law. Under the General Data Protection Regulation, Regulation (EU) 2016/679, which has applied since 25 May 2018, controllers and processors must apply appropriate technical and organizational measures for personal data security. Article 28 also requires processor oversight, while Article 32 requires security appropriate to risk, including resilience, confidentiality, integrity, availability, and the ability to restore access after an incident.

For cloud and data center operators in Europe, NIS2, Directive (EU) 2022/2555, is directly relevant. Member States were required to adopt national measures by 17 October 2024 and apply them from 18 October 2024. NIS2 covers, among other sectors, cloud computing service providers and data center service providers. It requires cybersecurity risk management, incident handling, supply chain security, vulnerability handling, access control, continuity measures, and significant incident reporting.

For financial institutions, DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025. DORA requires financial entities to manage ICT risk, test digital operational resilience, classify and report major ICT incidents, maintain registers of ICT third-party arrangements, and oversee providers supporting critical or important functions. A cloud network redesign by AWS does not automatically create a filing obligation for every customer, but it may belong in the evidence file for provider risk reviews and resilience assessments.

In the United States, the Federal Trade Commission angle is narrower but still practical. The FTC Safeguards Rule, issued under the Gramm-Leach-Bliley Act for covered financial institutions, requires a written information security program, risk assessment, safeguards, monitoring, and service-provider oversight. Most amended Safeguards Rule requirements became enforceable on 9 June 2023. The FTC does not prescribe a data center topology, but it does expect covered companies to manage service-provider security risk in a documented way.

What it requires: update the control record, not the architecture diagram only

AWS describes RNG as a departure from the familiar tree-shaped, hierarchical data center network. In a traditional design, traffic moves through layers of switches and routers. That hierarchy makes routing simpler and cabling orderly, but it can concentrate traffic at certain points while other parts of the network sit underused. RNG instead creates a flatter graph with many possible paths. AWS says it makes this practical through Spraypoint, a routing algorithm that spreads traffic across paths, and Shufflebox, a passive optical device that helps organize fiber connections that would otherwise become operationally difficult at scale.

For engineering teams, the important change is performance and capacity distribution. For compliance teams, the important question is control assurance. A faster internal network can support availability, resilience, and lower energy use, but regulated customers should avoid treating vendor performance claims as compliance evidence on their own. The evidence has to be tied back to obligations.

Start with the data processing register. If AWS hosts personal data, confirm which services and regions are in scope, especially where workloads run in Ireland, Germany, Spain, or other EU regions where AWS says RNG has been deployed or is planned. The register does not need to describe RNG in technical depth, but it should identify AWS as a processor or subprocessor relationship, the categories of data involved, the regions used, and the business processes that depend on those services.

Next, update the third-party risk file. The file should record what AWS has announced, which workloads may depend on the affected infrastructure, and which existing AWS assurance materials remain relevant. The right sources include the AWS Shared Responsibility Model, AWS compliance programs, contractual data processing terms, service-level commitments, audit reports available through AWS Artifact, and internal resilience testing results. The customer remains responsible for configuration, access control, encryption choices, backup design, application failover, logging, and incident playbooks.

For GDPR Article 32, the compliance question is whether the organization can still show appropriate measures for confidentiality, integrity, availability, and resilience. RNG may support availability, but it does not replace customer controls. Encryption at rest and in transit, key management, identity controls, least privilege, backup restoration, logging, and tested recovery procedures remain customer evidence. If a regulated workload uses AWS database services, the compliance file should connect AWS infrastructure assurance to the customer’s own recovery time objectives, recovery point objectives, and breach response process.

For NIS2, cloud-dependent entities should map the change to supply chain security and incident handling. If the organization is an essential or important entity under national NIS2 implementation, it should confirm that supplier risk assessments cover cloud infrastructure dependencies, that significant incident criteria are understood, and that notification workflows identify who contacts AWS, who assesses business impact, and who reports to the national authority when required. NIS2 reporting timelines can be strict, so teams should not wait for a real outage to decide whether a cloud network incident is reportable.

For DORA, the key issue is whether the AWS workload supports a critical or important function. If it does, the financial entity should check that its ICT third-party register is current, its exit strategy is credible, and its resilience tests reflect realistic cloud failure scenarios. RNG may reduce some bottleneck risks, but DORA focuses on the financial entity’s ability to withstand, respond to, and recover from ICT disruption. That means tabletop exercises, failover tests, concentration-risk reviews, and documented accountability.

For FTC Safeguards Rule purposes, covered financial institutions should treat the AWS change as part of ongoing service-provider oversight. The practical requirement is not to approve RNG. It is to keep a written security program current, review service-provider safeguards, and verify that controls remain suitable after material changes in technology risk. That means the qualified individual responsible for the program should be able to explain why AWS remains an appropriate provider for covered systems and what compensating customer controls are in place.

Compliance timeline: what to do now through year end 2026

Immediate action, by 30 June 2026, should be documentation. Record the AWS RNG announcement in the vendor-risk log, identify AWS-hosted systems that process personal data or support regulated services, and assign an owner in security, infrastructure, or compliance. The owner should collect AWS public materials, the Amazon research paper, contract documents, relevant assurance reports, and internal dependency maps.

By 31 July 2026, complete a control mapping. For GDPR, map RNG-related vendor assurance to Article 28 processor oversight and Article 32 security. For NIS2, map it to supply chain security, incident handling, business continuity, and risk management. For DORA, map it to ICT third-party risk, operational resilience testing, incident classification, and exit planning. For FTC Safeguards Rule coverage, map it to service-provider oversight and written information security program maintenance.

By 30 September 2026, test the customer-controlled parts of resilience. Do not rely on AWS network efficiency as a substitute for customer failover. Run backup restoration tests, regional failover exercises where appropriate, incident communications drills, and access-review checks. The goal is to prove that the organization can maintain or restore regulated services even if a provider-side network event affects availability or latency.

By 31 December 2026, align the vendor review cycle with AWS deployment plans. The original report says AWS has rolled RNG out in Ireland, Germany, and Spain and plans broader deployment by the end of 2026. Treat that date as a review marker, not as a legal deadline. Ask whether critical workloads changed regions, whether service-level performance changed, whether incident history changed, whether AWS assurance documents were updated, and whether any customer risk rating should move.

The practical compliance position is straightforward: AWS RNG is a cloud infrastructure improvement, but regulated customers still own their governance evidence. A compliance officer should not ask engineers to redesign around RNG without a specific risk reason. The better response is to document the change, confirm which regulated workloads depend on AWS, refresh the third-party risk assessment, test recovery, and keep the legal mapping current. That is the file a regulator, auditor, or customer security reviewer will expect to see.