--- url: "https://www.xcademia.com/news/fastweb-vodafone-automates-telecom-network-impact-analysis-with-aws" title: Fastweb+Vodafone Automates Telecom Network Impact Analysis With AWS description: "Fastweb+Vodafone uses AWS, Amazon Neptune, and EKS to automate telecom network change impact analysis and identify affected services and customers." publishedAt: "2026-10-19T12:06:35.897+00:00" updatedAt: "2026-10-19T12:35:34.653888+00:00" type: news category: devops source_name: AWS for Industries source_url: "https://aws.amazon.com/blogs/industries/how-fastwebvodafone-automates-change-impact-analysis-for-transport-networks-with-aws/" tags: - "#Telecom" - "#NetworkAutomation" - "#AWS" - "#DigitalTwin" - "#AmazonNeptune" - "#CloudInfrastructure" - "#AutonomousNetworks" - "#NetworkEngineering" --- # Fastweb+Vodafone Automates Telecom Network Impact Analysis With AWS > Fastweb+Vodafone has deployed an AWS-based Digital Twin to automate telecom change impact analysis, using Amazon Neptune, EKS, and graph algorithms to identify affected services, customers, and network elements. Source: **AWS for Industries** · 19 October 2026 **T**elecommunications operator Fastweb+Vodafone has collaborated with Celfocus and Amazon Web Services (AWS) to automate change impact analysis across its transport network. The production solution uses a Digital Twin of network topology and graph-based analysis to identify the services, customers, and infrastructure elements that could be affected by planned maintenance or network changes. Described in an AWS for Industries article published on October 18, 2026, the system replaces much of the manual correlation traditionally required to assess the effects of planned work. It combines network inventory data, an Amazon Neptune graph database, and containerized applications running on Amazon Elastic Kubernetes Service (Amazon EKS). The project is part of Fastweb+Vodafone's Autonomous Networks transformation. Fastweb+Vodafone contributed network expertise and operational requirements, while Celfocus supplied its telecom-focused Digital Twin framework. AWS provides the cloud infrastructure and managed services supporting the solution. The central design principle is to represent network equipment, connections, and services as a queryable graph. This gives the Change Impact Analysis (CIA) engine a structured model to traverse when determining the potential impact of a proposed change. ## Why telecom operators need automated change impact analysis Transport networks connect large numbers of network elements, links, and services. Before maintenance, reconfiguration, shutdowns, or migrations, operators need to understand which parts of the network could be affected and which customers rely on those services. Traditionally, engineers assemble this information from multiple Network Inventory Systems (NIS) and other data sources. They correlate equipment, connectivity, and service dependencies manually to estimate the impact of planned work. AWS describes this approach as time-consuming and vulnerable to human error. The quality of an assessment can also depend heavily on the experience of the engineer performing it. For Fastweb+Vodafone, the challenge involves an Italian transport network spanning both Internet Protocol (IP) and transmission layers. According to the source, a single planned maintenance event could require hours of manual correlation. The automated system is designed to answer three operational questions: - **Who is affected?** Identify relevant customer categories and customer endpoints. - **Which services are affected?** Trace dependencies across voice, data, video, enterprise, and emergency services. - **Where does the impact extend?** Determine affected equipment, sites, connections, circuits, and related network paths. By automating these assessments, the solution aims to give network engineers more consistent impact information for maintenance planning and operational prioritization. ## The Digital Twin: A graph-based model of the network The foundation of the solution is a Digital Twin representing Fastweb+Vodafone's network topology and service dependencies. It is stored in Amazon Neptune, a managed graph database, using the labeled property graph model and queried with openCypher. Rather than treating inventory records as disconnected data, the model represents network components as nodes and their relationships as typed edges. Each equipment element has a stable identifier and associated properties. The model captures equipment hierarchies that include: - Sites - Shelves and slots - Cards and subcards - Ports It also represents network interconnections, referred to in the source as trails, and service paths that use the underlying topology. These relationships allow the analysis engine to traverse the physical and service layers together. The model covers two connected network domains. The IP layer represents IP elements as endpoints, while the transmission layer captures the transport infrastructure and its equipment hierarchy. A connection between two IP elements can be represented as a service path over the transmission layer, whether it uses intermediate transmission equipment or a direct cable. The topology model was co-designed with Fastweb+Vodafone's network engineering team. It accounts for the operator's multi-vendor infrastructure, equipment hierarchies, naming conventions, and internal inventory schemas following the integration of Fastweb and Vodafone Italia. Celfocus's Digital Twin framework provides reusable capabilities for converting heterogeneous inventory data into graph entities and relationships, constructing service dependencies, and supporting graph-based analysis. The operator-specific model preserves Fastweb+Vodafone's network semantics while using those reusable capabilities. ![info-1](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1792411249455-info-1--225-.webp) ## The four-phase data and analysis workflow The solution combines on-premises data preparation, streaming ingestion, graph construction, and event-driven impact analysis. Each phase has a distinct role in keeping the Digital Twin useful for operational decisions. ### 1. Retrieve and prepare network data The Network Inventory System is the primary source for equipment definitions, connections, and services. The solution also uses feeds from Data Center Interconnect (DCI), the Geographic Information System (GIS), and the Lawful Interception (LI) database. The initial data staging and preprocessing take place on-premises. Apache Spark jobs prepare the raw inventory data before it is streamed to AWS for downstream processing. This allows the solution to combine information from multiple systems while retaining a structured path from source inventory data to the graph representation. ### 2. Ingest changes and update the graph Amazon Managed Streaming for Apache Kafka (Amazon MSK) receives preprocessed inventory feeds and makes them available to downstream components. It also supports the flow of topology changes used to update the Digital Twin between full baseline loads. For incremental updates, changes detected in the Network Inventory System can trigger openCypher write queries against Neptune. The implementation uses `MERGE` and `SET` with stable inventory identifiers to update existing graph entities and their properties without unnecessarily creating duplicate nodes. This incremental path complements the periodic full-load process. It is designed to keep the graph current between baseline rebuilds rather than waiting for the next batch cycle. ### 3. Build and refresh the Digital Twin A containerized Graph Builder application running on Amazon EKS normalizes and correlates inventory entities, reconstructs equipment hierarchies, and creates the connectivity and service relationships required for analysis. The Graph Builder also generates bulk-load files that are stored in Amazon S3 and imported into Neptune through its bulk loader. The source describes an important lifecycle detail: the Neptune bulk loader is insert-oriented and does not, by itself, remove entities or relationships that have disappeared from the source inventory. A full baseline refresh therefore clears the target graph using the Neptune fast reset API before reloading the current inventory export. This helps prevent obsolete nodes, stale relationships, and superseded values from remaining in the refreshed baseline. The full-load and incremental-update paths serve different purposes. The batch process re-establishes the authoritative baseline, while streaming and incremental writes keep the Digital Twin updated between refreshes. ### 4. Calculate service impact The CIA engine also runs on Amazon EKS. It is triggered when a change request spreadsheet in Microsoft Excel `.xlsx` format arrives in a designated Amazon S3 bucket. The engine uses the request to identify the target network elements and traverse the Digital Twin. It then calculates which network components, services, and customers may be affected. The output is a structured Excel report with multiple sheets covering impacted network elements, affected circuits and topology paths, impacted services, and aggregated indicators such as subscriber counts and customer endpoints. The source also describes severity scoring. The engine assigns severity levels based on factors including the type and criticality of affected elements, the services and customer categories involved, and the scope of the impact. These results help operators prioritize the work and assess its potential consequences. **Workflow summary:** Inventory data is prepared on-premises, streamed to AWS, transformed into a graph-based Digital Twin, and traversed by the CIA engine when a change request arrives. ## AWS services supporting the solution The architecture combines graph storage, container orchestration, streaming, object storage, relational data management, and operational monitoring. AWS service Role in the solution Amazon EKS Hosts the Graph Builder and CIA engine applications. Amazon Neptune Stores the network Digital Twin and supports graph queries and traversal. Amazon MSK Receives preprocessed inventory feeds and supports downstream ingestion and incremental updates. Amazon S3 Stores source data dumps, graph bulk-load files, change request spreadsheets, and analysis outputs. Amazon Aurora PostgreSQL Stores structured analysis inputs and results for operational use, auditing, and historical analysis. Amazon SageMaker AI Provides Jupyter notebooks for interactive validation in the development environment only. Amazon CloudWatch Provides centralized logs, application metrics, alerts, monitoring, and operational dashboards. The architecture separates development and production into dedicated AWS accounts and VPCs. SageMaker AI notebooks are used in development but are not provisioned in production, supporting the stated least-privilege approach. The combination of Neptune and EKS separates the graph data layer from the applications that build and query the network model. This also allows the graph foundation to be reused for additional network operations use cases as the operator's requirements evolve. ## Security, connectivity, and high availability Because network and customer endpoint information can be sensitive, the architecture includes controls for identity, encryption, network access, and environment isolation. AWS Identity and Access Management (IAM) applies dedicated roles and policies based on the principle of least privilege. The source notes that customer endpoint identifiers may constitute personal data under the General Data Protection Regulation (GDPR), making controlled access an important consideration. Encryption is applied at rest using a customer-managed AWS Key Management Service (AWS KMS) key. Communications use TLS 1.2 or higher, with encrypted connections enforced for Neptune and Aurora. Development and production run in separate AWS accounts and VPCs. Within each environment, subnets, route tables, network access control lists, and security groups help segment connectivity. The production environment has no internet egress through a NAT Gateway or Internet Gateway. The public-subnet tier is reserved for future use, while access to services such as Amazon S3 uses a gateway VPC endpoint. Connectivity between the operator's on-premises data center and the VPC is provided through AWS Direct Connect. The design also spans two Availability Zones. According to the source, Neptune operates as a multi-AZ cluster with a reader instance, Aurora is deployed in a Multi-AZ configuration, and EKS managed node groups are distributed across both zones. These choices are intended to reduce single points of failure within the AWS Region. Amazon CloudWatch supports operational visibility through centralized logging, custom metrics, alerting for critical conditions, and dashboards. The source also notes optional Grafana integration for enhanced visualization. These are described architectural controls. The article does not provide independent security test results or quantified availability measurements for the complete solution. ![info-2](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1792411270167-info-2--207-.webp) ## How the CIA engine evaluates a change request The event-driven workflow starts when a new Excel file appears in the designated S3 bucket. Excel is used for both input and output because Fastweb+Vodafone's existing change management process is spreadsheet-based. The source states that exposing the capability through an API is on the roadmap. It is not described as an already deployed API interface. Once the input arrives, the CIA engine follows a structured sequence: 1. **Validate the file.** Check required worksheets, columns, data types, and conformity with the expected change request schema. 2. **Parse the request.** Extract the planned change details, target sites or equipment, components and ports, associated services, and other relevant context. 3. **Classify the change.** Use the specified change type, such as maintenance, reconfiguration, shutdown, or migration, to guide the analysis. 4. **Traverse the graph.** Resolve the targets against the Digital Twin and evaluate physical, logical, and service dependencies. The CIA algorithms determine the traversal scope, how impact propagates, which entities are affected, and the resulting blast radius. 5. **Score and report the impact.** Assign severity levels using the affected elements, service and customer categories, and extent of impact. Consolidate the findings into a multi-sheet Excel report. The resulting assessment is designed to give engineers a more consistent view of potential disruption before work is performed. The source describes deterministic graph-based analysis, but this should not be interpreted as a guarantee that every operational consequence will always be captured. Results depend on the quality and currency of the inventory data and the accuracy of the network model. Inputs and outputs are also registered in Amazon Aurora PostgreSQL for operational consumption, audit trails, and historical analysis. ## Deployment and operational practices The implementation uses infrastructure automation and repeatable testing practices to support deployment across development and production. **Infrastructure as code:** Terraform is used to provision the solution's infrastructure in both environments. The aim is to make deployments repeatable and reduce discrepancies between environments. **Automated CI/CD:** The continuous integration and continuous deployment pipeline automates infrastructure validation, planning, and deployment steps. **Backup and recovery:** The solution uses automated backups, point-in-time recovery for database services, and documented recovery procedures. Data classification tiers include Public, Private, Confidential, and Restricted, with standardized tagging used for security and compliance validation. **Testing:** The team follows a V-Model testing approach, combining automated and manual testing. Automation is prioritized for regression, data validation, and repeatable integration scenarios, while manual testing supports exploratory work and early functional verification. The source references IEEE 829 and notes that it has been superseded by ISO/IEC/IEEE 29119-3. Together, these practices support repeatable infrastructure changes and lifecycle management around the Digital Twin and impact-analysis applications. ## What the deployment means for telecom network operations The Fastweb+Vodafone deployment illustrates how a graph-based Digital Twin can connect network inventory with service dependencies and planned changes. Instead of requiring engineers to reconstruct those relationships manually for each assessment, the system provides a reusable topology model that the CIA engine can query. For telecom operators, this architecture offers a pattern for consolidating information across network domains and automating a defined operational task. The same Digital Twin foundation is intended to support further network operations use cases, although the source does not specify which additional capabilities have already been deployed. The design also shows that network automation depends on more than cloud compute. It requires accurate inventory data, a model aligned with the operator's infrastructure, reliable update mechanisms, well-defined graph algorithms, and operational controls for handling sensitive information. The article reports that Fastweb+Vodafone's previous manual correlation could take hours and that the automated process delivers results in minutes, according to the operator's quoted representative. However, it does not provide a formal benchmark, a detailed test methodology, or quantified results across different types of change requests. ![info-3](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1792411287366-info-3--193-.webp) ## Conclusion Fastweb+Vodafone, Celfocus, and AWS have built a production-grade change impact analysis solution that combines a graph-based network Digital Twin with automated workflows on AWS. Amazon Neptune stores the topology and service relationships, Amazon EKS runs the graph-building and analysis applications, and Amazon MSK, Amazon S3, and Aurora PostgreSQL support data ingestion, file handling, and operational records. The solution is designed to help engineers identify affected network elements, services, and customers before planned maintenance or other changes. Its broader architectural value lies in creating a reusable representation of the network that can support additional operational analysis without rebuilding the underlying topology model. For telecom operators pursuing network automation, the deployment highlights the importance of combining domain-specific network modeling with graph traversal, controlled data pipelines, and operational governance. It also reinforces that dependable impact analysis relies on maintaining an accurate Digital Twin and validating the results against real network conditions. ## Original source https://aws.amazon.com/blogs/industries/how-fastwebvodafone-automates-change-impact-analysis-for-transport-networks-with-aws/ ## Tags `#Telecom` · `#NetworkAutomation` · `#AWS` · `#DigitalTwin` · `#AmazonNeptune` · `#CloudInfrastructure` · `#AutonomousNetworks` · `#NetworkEngineering` --- ## About this content This Markdown news article is the citation-grade twin of [Fastweb+Vodafone Automates Telecom Network Impact Analysis With AWS](https://www.xcademia.com/news/fastweb-vodafone-automates-telecom-network-impact-analysis-with-aws). It is published by **Xcademia** (UK Companies House 12322710) and is available for AI search engines and large language models to index, summarise, and cite. When citing or quoting, please attribute *Xcademia* and link back to the source URL above. - Source: https://www.xcademia.com/news/fastweb-vodafone-automates-telecom-network-impact-analysis-with-aws - Publisher: Xcademia, https://www.xcademia.com - Catalogue index: https://www.xcademia.com/llms-full.txt