What is a CNF? A CNF, or Cloud-Native Network Function, is a network function built and operated according to cloud-native principles, so that teams can deploy, scale, update and heal it through automation rather than through manual, appliance-style operations.
In telecom networks, CNFs are the software building blocks of modern cloud-native cores, edge platforms and network services. For example, typical CNFs include 5G Core functions such as the AMF, SMF and UPF. They usually run as containers on Kubernetes, but the term describes how the function is designed and operated, not only how it is packaged.
CNFs are the next stage after Network Functions Virtualization (NFV) and Virtualized Network Functions (VNFs), and they are a central part of Telco Cloud architecture.
This guide explains what a CNF is, how it works, what a CNF architecture and a CNF platform look like, where CNFs appear in 5G, and which benefits and challenges to expect. For a direct comparison with virtualized functions, read our VNF vs CNF guide.
What Is a CNF? Quick Answer
CNF: A Cloud-Native Network Function is a network function designed around cloud-native principles such as modularity, loose coupling, automation, resilience and observability, and commonly delivered as containers on Kubernetes.
Where it is used: 5G Core, edge computing, virtual routing and security functions, and other Telco Cloud workloads.
Key point: CNF stands for Cloud-Native Network Function. However, a network application that simply runs inside a container is not automatically cloud-native.
What Is a Cloud-Native Network Function (CNF)?
A Cloud-Native Network Function is a software implementation of a network function that teams design, build and operate according to cloud-native principles, rather than simply move from a hardware appliance onto cloud infrastructure.
Common design principles include:
- Loose coupling between components
- Modular or microservice-oriented design
- Horizontal elasticity
- Resilience and automated recovery
- Automation of deployment and lifecycle operations
- Declarative configuration
- Built-in observability
- Continuous delivery of software updates
This view is consistent with the CNCF Cloud Native Definition, which emphasizes scalable applications in dynamic environments and lists containers, microservices, immutable infrastructure and declarative APIs as typical examples. It also fits the ETSI work on network virtualisation and telecom cloud infrastructure, which increasingly covers cloud-native workloads alongside virtual machines.
Does CNF Mean Containerized Network Function?
Important: CNF stands for Cloud-Native Network Function. Some sources read it informally as “containerized network function”, because containers are the usual way to deliver cloud-native software.
The two ideas are related but not identical. For example, a monolithic application packaged in a container is containerized, yet it may still scale only as one large unit, require manual upgrades and keep its state inside a single instance.
A practical test is to ask five questions about the network function:
- Can its components scale independently?
- Can you upgrade it without interrupting service?
- Does it keep important state outside individual instances?
- Is its configuration declarative and version-controlled?
- Does it expose the metrics, logs and traces that operators need?
The more of these answers are “yes”, the closer the function is to genuine cloud-native design.
How Does a CNF Work?
A CNF works by combining a set of cloud-native technologies. The details vary by vendor, but most CNF deployments follow the same pattern.
Container Images
Vendors package the CNF as one or more container images. Each image contains a component of the network function and its runtime dependencies, which makes deployment more repeatable across environments.
Kubernetes Orchestration
Kubernetes schedules the containers, keeps the desired number of instances running, restarts failed workloads and supports service discovery. The official Kubernetes documentation describes it as a platform for managing containerized workloads and services that supports both declarative configuration and automation.
Helm Charts and Operators
Declarative packages such as Helm charts or Kubernetes manifests usually describe deployment and configuration. Operators can add network-function-specific automation for tasks such as upgrades, scaling and configuration changes.
Networking for Telecom Workloads
Standard Kubernetes networking is often not enough for telecom traffic. As a result, CNFs frequently need several network interfaces, separation of control, user and management traffic, and high-performance data paths. Operators commonly use technologies such as Multus, SR-IOV and DPDK to meet these requirements.
Lifecycle and Orchestration
In addition, telecom orchestration systems can sit above Kubernetes to coordinate network services across CNFs, VNFs and physical functions. Kubernetes manages the cloud-native workload, while NFV-MANO or other service orchestration manages the wider service. This relationship is explained in more detail in our VNF vs CNF guide.
CNF Architecture
Most sources describe a CNF architecture in layers. The table below shows the main building blocks of a CNF environment.
| Layer | Role in a CNF environment | Typical technologies |
|---|---|---|
| Application | The microservices or components of the network function | Container images, service APIs |
| Packaging | Describes how the CNF is deployed and configured | Helm charts, Kubernetes manifests, operators |
| Orchestration | Schedules workloads and maintains desired state | Kubernetes |
| Networking | Provides pod networking and additional telecom interfaces | CNI plugins, Multus, SR-IOV, DPDK |
| Observability | Collects metrics, logs and traces | Prometheus, OpenTelemetry, logging platforms |
| Delivery | Builds, tests and deploys changes | CI/CD pipelines, GitOps |
| Telecom orchestration | Coordinates network services across domains | NFV-MANO, service orchestrators |
This table is illustrative. Actual implementations differ by vendor, operator and platform.
Microservices and Loose Coupling
Instead of one large software image, a CNF is typically divided into smaller components with defined interfaces. Operators can then scale, update or restart individual components without affecting the whole function, provided the application was designed for it.
Control Plane and User Plane Separation
Many network functions separate signalling from packet forwarding. Control-plane components often suit horizontal scaling well, while user-plane functions can have strict performance requirements. Cloud-native design allows each part to be scaled and placed according to its own needs, for example with user-plane functions closer to the edge.
Externalized State
State is one of the hardest parts of cloud-native network functions. As a result, cloud-native designs often keep session or subscriber state in resilient shared data layers instead of inside a single instance, so that a failed component can be replaced without losing service continuity.
CNF Examples in the 5G Core
5G has accelerated the adoption of CNFs. The 3GPP 5G system architecture is service based: control-plane network functions in the core expose services to one another through standardized interfaces, which fits modular, cloud-native software well.
Typical 5G Core functions that vendors deliver as CNFs include:
- AMF (Access and Mobility Management Function) — registration, connection and mobility management
- SMF (Session Management Function) — establishment and management of data sessions
- UPF (User Plane Function) — packet routing, forwarding and handling of user traffic
- NRF (Network Repository Function) — service discovery between network functions
- AUSF and UDM — authentication and subscriber data management
- PCF (Policy Control Function) — policy rules for sessions and services
Whether a given implementation is truly cloud-native depends on how the vendor designed it. However, vendors built some 5G Core products cloud-native from the start, while others evolved from earlier virtualized designs. The UPF often has the most demanding performance requirements, which is why acceleration technologies matter most there.
What Is a CNF Platform?
A CNF platform is the cloud-native infrastructure layer on which CNFs run. In practice it is usually a Kubernetes-based platform prepared for telecom requirements.
Therefore, a CNF platform typically needs to provide:
- Container orchestration and cluster lifecycle management
- Carrier-grade networking, including multiple interfaces per workload
- High-performance data paths using SR-IOV, DPDK, CPU pinning or similar mechanisms
- Automated upgrades and rollback
- Observability for metrics, logs and traces
- Security controls such as RBAC, network policies and image management
- Support for multiple clusters and edge locations
Operators use commercial Kubernetes distributions such as Red Hat OpenShift for this purpose, alongside telecom-focused platforms from infrastructure vendors. The platform choice should start from the requirements published by the CNF vendors, not from the platform alone.
Benefits of CNFs
When the application and platform are designed well, CNFs can offer:
- Elastic scaling: individual components can be scaled to match demand
- Faster updates: smaller components can be upgraded more often and with less risk
- Automation: deployment, healing and configuration can be driven by declarative definitions
- Resilience: failures can be isolated to individual components and recovered automatically
- Efficient infrastructure use: workloads can share cloud-native infrastructure
- Delivery alignment: network software can follow modern DevOps and CI/CD practices
However, these benefits depend on application design and operations. They do not appear automatically because containers or Kubernetes are present.
Challenges of CNFs
Performance and Networking Complexity
High-throughput, low-latency functions need careful design of networking, CPU allocation, memory and acceleration. Teams should validate performance with the real application and traffic profile, not assume it.
Stateful Functions
Network functions often maintain sessions, subscriber data or routing information. Kubernetes can restart a failed workload, but application-level service continuity still depends on how state is managed.
Skills and Operating Model
In addition, operating CNFs requires skills in Linux, Kubernetes, networking, APIs, automation and observability, and often a change from device-centric to platform-centric operations.
Security
Moreover, cloud-native environments add security concerns across container images, registries, Kubernetes API access, secrets, network policies and software supply chains. Many of these controls overlap with DevSecOps practices.
Vendor Maturity and Interoperability
CNF maturity varies between vendors and functions. Therefore, operators should check upgrade paths, support models and interoperability before committing to a migration.
CNF vs VNF in Brief
A VNF virtualizes a network function, commonly in virtual machines managed through NFV-MANO. In contrast, a CNF goes further by redesigning the function around cloud-native principles, commonly using containers and Kubernetes. Neither replaces the other in every case, and many operators run both.
For the full comparison covering architecture, orchestration, scaling, performance, security and migration, read our VNF vs CNF guide.
5-Minute CNF Readiness Check
Use this short check before deciding whether a network function is ready to run as a CNF.
- Check the application design. Is the function genuinely built from loosely coupled components, or is it a monolith in a container?
- Check the platform. Do you have a production-ready Kubernetes platform with the networking, storage, security and observability this function needs?
- Check performance needs. Have you validated throughput, latency, acceleration and resilience with a realistic traffic profile?
- Check operations. Do your teams have the skills and processes for Kubernetes, automation, CI/CD and cloud-native troubleshooting?
- Check the vendor. Does the vendor provide a mature CNF with a clear upgrade path, support model and interoperability?
Decision outcome: PROCEED to a pilot when most answers are yes; PREPARE the platform and skills first when the function is ready but the environment is not; KEEP AS A VNF when the existing function works well and modernization offers limited value; INVESTIGATE FURTHER when performance, state or vendor questions remain open.
Next action: pilot one representative function and measure deployment time, upgrade effort, resilience, scaling behavior and operational workload before expanding.
CNFs and the Evolution Toward Telco Cloud
CNFs are one part of a larger transformation from appliance-centric networking toward software-driven Telco Cloud infrastructure, where physical functions, VNFs and CNFs can operate side by side.
To understand the foundation behind virtualized functions, read our complete guide to Network Functions Virtualization (NFV). For the target architecture that combines NFV, CNFs, Kubernetes, edge computing, automation and 5G, see our complete Telco Cloud guide.
Frequently Asked Questions About CNFs
What does CNF stand for in telecom?
CNF stands for Cloud-Native Network Function. It describes a network function designed and operated according to cloud-native principles.
What is the difference between a CNF and a VNF?
A VNF is a virtualized network function, traditionally running in virtual machines within an NFV environment. A CNF is designed around cloud-native principles and commonly runs in containers on Kubernetes. See the full VNF vs CNF comparison.
Is every containerized network function a CNF?
No. Packaging an existing application in a container does not by itself make it cloud-native. Architecture, lifecycle, resilience, automation and observability matter as well.
Do CNFs always run on Kubernetes?
Kubernetes is the most common orchestration platform for CNFs, but the defining characteristic of a CNF is its cloud-native design rather than one specific tool.
What is a CNF in 5G?
In 5G, a CNF is typically a core network function such as the AMF, SMF or UPF delivered as cloud-native software. The service-based architecture of the 5G Core suits this modular approach.
What is a CNF platform?
A CNF platform is the cloud-native infrastructure layer, usually Kubernetes-based and prepared for telecom networking, performance, security and lifecycle requirements, on which teams deploy and operate CNFs.
Are CNFs faster or more secure than VNFs?
Not automatically. Performance and security depend on application design, infrastructure, configuration and operations. Validate the actual function rather than assuming results from its VNF or CNF classification.
Can CNFs run on bare metal?
Yes. Kubernetes can run on bare-metal servers, and some telecom deployments choose this for performance and predictability. Others run CNFs on virtual machines or public cloud infrastructure.
Conclusion: A CNF Is Defined by Design, Not Just by Containers
Cloud-Native Network Functions apply cloud-native architecture, automation and lifecycle management to network software. They are central to 5G Core, edge computing and Telco Cloud, and they work best when the application, the platform and the operating model are all designed for cloud-native operation.
A CNF is a network function designed for the cloud. Containers are the usual vehicle, but cloud-native design is what makes it a CNF.
Continue Learning
Continue exploring the TechTeamSynergy telco cloud and network virtualization cluster with these related guides.