Cisco Secure Firewall Threat Defense Container Architecture and Scale

Cisco Secure Firewall Threat Defense Container (FTDc) extends next-generation firewall controls into containerized environments. It provides routed Layer 3 through Layer 7 firewalling, application visibility and control, intrusion prevention, VPN, container-native policy attributes, and centralized management for deployments running in private infrastructure, on-premises environments, and supported public cloud platforms.

The platform uses a performance-based subscription model. A performance tier defines the firewall inspection rate limit and the maximum number of concurrent Remote Access VPN sessions. The selected container compute allocation is separate from the license tier, allowing architects to size compute for scale factors such as session tables, routing, access control rules, and interface count while selecting a license according to throughput and VPN requirements.

Product capabilities

Container deployment and operations

FTDc is designed for deployment alongside containerized applications and network services. Its principal operational capabilities include:

• Deployment in data centers, branch environments, private clouds, and supported public cloud environments.
• A common license entitlement for virtual and container deployments across public and private clouds.
• Container lifecycle management through HELM charts.
• Low-Touch Provisioning through a Sidecar.
• Routed deployment mode.
• Layer 3 through Layer 7 firewalling.
• Policy enforcement using traditional network constructs and container-native attributes.
• Support for Macvlan and SR-IOV container network interfaces in private cloud and on-premises environments.
• AWS deployment through Elastic Kubernetes Service within the supported Kubernetes range.

High availability and clustering are not included as currently available deployment capabilities in the supplied specifications. Both Active/Standby high availability and clustering are identified as planned capabilities.

Inspection and visibility

The firewall supports application visibility and control, intrusion prevention, VPN, and encrypted traffic analysis.

The Encrypted Visibility Engine provides visibility into encrypted traffic, including TLS 1.3, without requiring traffic decryption. This is relevant where decryption introduces operational overhead, certificate management complexity, privacy concerns, or application compatibility issues.

SnortML is integrated with Snort 3 IPS. It provides machine learning-based exploit detection and is powered by the Cisco Talos Intelligence Group. SnortML should be evaluated as part of the overall IPS policy design rather than treated as a substitute for capacity planning. Enabling additional inspection services affects the performance profile used for sizing.

Centralized management and integrations

Physical, virtual, and container firewalls can be managed through a single unified management console. The management capability is available in on-premises and cloud-delivered form factors.

Native integration is identified for:

• Cisco Umbrella
• Cisco Secure Access
• Cisco Endpoint Security

The management architecture should be established before deployment. Presales discovery should identify whether the customer requires centralized policy administration, local operational autonomy, cloud-delivered management, or an on-premises management model.

Licensing and ordering model

The base ordering product ID is:

After selecting the base subscription, the customer selects a performance tier and may add one or more subscription licenses:

• T-Threat
• M-Malware Defense
• URL Filtering

The performance tier controls two explicit license parameters:

1. Throughput rate limit: The maximum firewall inspection throughput enforced by the integrated rate limiter.
2. Remote Access VPN session limit: The maximum number of concurrent Remote Access VPN sessions permitted by the license.

The license rate limit does not change the vCPU or memory allocation of the container. It also does not define the maximum raw performance of the selected compute instance. Compute sizing and license selection must therefore be treated as two separate presales activities.

Performance license matrix

License selection rules

Use the following presales rules when selecting a tier:

• Select the tier from the required licensed throughput, not from the maximum benchmark throughput of the compute platform.
• Confirm that the tier’s RA VPN session limit covers the peak concurrent user requirement, not only the average user count.
• If the expected throughput is near a tier boundary, account for traffic bursts, inspection policy growth, and future application expansion.
• Do not assume that selecting a higher license tier supplies additional vCPUs, memory, interfaces, sessions, routing entries, or connection establishment capacity.
• For deployments using IPS, use the FW plus AVC plus IPS performance figures for the selected vCPU count as the relevant engineering reference.
• For VPN-heavy deployments, use the IPSec VPN throughput and maximum VPN peer figures rather than the general firewall throughput figures.
• Validate the selected public cloud instance or on-premises compute platform against the applicable Getting Started Guide and compatibility documentation.

Supported deployment environments

The supported system range is:

The minimum resource profile is 4 vCPUs, 8 GB of RAM, and 50 GB of disk. The maximum stated profile is 32 vCPUs, 64 GB of RAM, and 500 GB of disk. These limits define the stated container appliance resource range; they do not guarantee a particular throughput result.

Compute performance and scale

The following figures apply to FTDc running Docker or Kubernetes with Snort 3 and SR-IOV. They are general performance guidelines. Actual results depend on traffic type and profile, CPU type and speed, cache characteristics, number of interfaces, and other environmental variables.

Sizing interpretation

The benchmark table shows that increasing vCPU allocation affects several independent dimensions:

• Inspection throughput increases from 5 Gbps to 59 Gbps for FW plus AVC.
• IPS-enabled throughput increases from 4.5 Gbps to 55 Gbps.
• IPSec VPN throughput increases from 2.2 Gbps to 35 Gbps.
• Concurrent sessions increase from 100,000 to 4 million.
• New connection establishment capacity increases from 27,000 to 300,000 connections per second.
• VPN peer capacity increases from 250 to 20,000.
• VRF capacity remains fixed at 30 across all listed compute profiles.

A design that is acceptable for steady-state throughput may still be unsuitable for connection-heavy workloads. For example, short-lived microservice connections can exhaust new-connection capacity before aggregate bandwidth becomes the limiting factor. Similarly, VPN deployments should be evaluated against both tunnel or peer count and encrypted throughput.

Use the lowest vCPU profile that satisfies all relevant constraints only after checking:

• Peak inspected throughput
• Peak new connections per second
• Maximum concurrent sessions
• VPN throughput
• VPN peer count
• Number of VRFs
• Number of interfaces
• Access control policy scale
• Routing table requirements
• Traffic mix and packet size
• Whether AVC, IPS, VPN, and encrypted traffic visibility are enabled simultaneously

The benchmark traffic size is 1024 bytes. Smaller packets generally create more packets per second for the same aggregate bandwidth and should be included in performance validation where the production workload is packet intensive.

Network architecture and deployment design

FTDc uses routed deployment mode. The design should define the container’s northbound and southbound connectivity, interface attachment method, route ownership, default gateway behavior, and failure handling.

Macvlan and SR-IOV provide different operational characteristics and should be selected according to the host, network, and performance design. SR-IOV is specifically represented in the published performance data. The deployment team should confirm the required host configuration, supported compute shape, interface count, and CNI implementation before committing to a production topology.

HELM charts should be incorporated into the customer’s container operations model. Presales validation should cover:

• Chart deployment and upgrade procedures
• Configuration values and secrets handling
• Persistent storage requirements
• Network attachment definitions
• Rollback procedures
• Sidecar-based Low-Touch Provisioning
• Monitoring and logging integration
• Change control for security policy updates

Because high availability and clustering are not currently identified as available capabilities, resilience must not be represented through unsupported native firewall mechanisms. The customer should document the expected behavior for node, host, container, network interface, and cluster failures and validate those behaviors in a controlled test.

Environmental and physical considerations

FTDc is a containerized software appliance rather than a dedicated hardware platform. The supplied product specifications do not state hardware-specific acoustic, mechanical, or environmental values.

For private cloud and on-premises deployments, the infrastructure owner remains responsible for rack, power, cooling, physical network interface, host operating temperature, and hardware lifecycle requirements. For AWS deployments, these considerations are inherited from the selected AWS service and instance configuration.

The container requires disk allocation within the stated minimum and maximum resource range. Disk sizing should account for the appliance requirement and the customer’s operational model for logs, diagnostics, images, upgrades, and retained data. The supplied specifications do not define additional disk consumption by feature or log retention period.

Warranty and service considerations

The supplied product information identifies the offering as a subscription-based virtual/container firewall entitlement but does not state a hardware warranty period, appliance replacement service, software support level, response-time commitment, service-level agreement, or named technical support program.

For presales and contract review, the following items must be confirmed through the applicable commercial documentation:

• Subscription term and renewal conditions
• Base subscription entitlements
• Performance tier entitlement
• T-Threat, M-Malware Defense, and URL Filtering options
• Software maintenance and update rights
• Technical support coverage
• Severity definitions and response targets
• Cloud-delivered management service coverage, if selected
• Support boundaries between Cisco software, the container runtime, Kubernetes, Ubuntu, AWS EKS, and the underlying host
• Customer responsibilities for supported versions, compute resources, networking, backups, and operational monitoring

There is no dedicated hardware warranty for the container itself because the product is deployed as software within customer-controlled or public cloud compute infrastructure. Any physical host warranty or cloud infrastructure service commitment is separate from the FTDc software subscription and must be procured or validated independently.

Sustainability information

The product material identifies sustainability information under corporate environmental reporting. The referenced sustainability areas include:

• Product material content laws and regulations
• Electronic waste laws and regulations, including products, batteries, and packaging

For a container deployment, physical material content and electronic waste obligations primarily relate to the host hardware and associated data center equipment rather than the software container. Packaging and hardware compliance should therefore be evaluated against the infrastructure platform used for the deployment.

Presales qualification checklist

Before proposing FTDc, confirm the following:

1. The target deployment is routed and fits the supported container architecture.
2. The runtime is Docker or Kubernetes within the supported range.
3. The operating system is Ubuntu within the supported range for private or on-premises deployment.
4. The AWS deployment uses EKS within the supported range.
5. The CNI is Macvlan or SR-IOV.
6. The customer has selected an appropriate host or cloud compute profile between 4 and 32 vCPUs.
7. Memory and disk allocation remain within the stated limits.
8. Licensed throughput and benchmark throughput have been evaluated separately.
9. The required RA VPN session count fits the selected performance tier.
10. VPN throughput and VPN peer capacity have been evaluated independently.
11. The selected vCPU profile supports the required sessions and new connections per second.
12. The design does not depend on currently unavailable high availability or clustering.
13. Required add-on subscriptions have been identified.
14. Management architecture and operational ownership have been defined.
15. Support responsibilities across the firewall, container platform, operating system, cloud service, and host infrastructure are documented.