Deep Subnet Insights

To drill more details about the Subnet Utilization in a VPC, click the More details link in the extreme right end. This takes you to a dedicate page within the VPC dashboard. This page in DDI Central gives you micro-level clarity inside your AWS VPCs. Whether you’re troubleshooting DHCP scope exhaustion, planning IPv6 rollout, or reviewing address hygiene, this view acts as your control tower.

Here you can see six tabs below a specific VPC. Navigate to the Subnet tab to gather more details on subnet behavior and resource usage inside a selected VPC.

There are three powerful sections under the Subnet tab:

1. Top Subnet Utilization Bar Chart (Left Side)

• Displays the top 5 subnets with the highest IP address consumption.
• Each bar represents a subnet’s total IP range and the percentage of it currently used.

This section instantly identifies IP usage hotspots across your VPC — enabling you to detect:

• Subnets nearing exhaustion (e.g., 80%+ used)
• Underutilized subnets (e.g., 10–20% used)
• Imbalanced address planning

This insight helps you rebalance IP allocations before you run out of space or create inefficient subnet layouts.

2. VPC Subnet State Distribution (Right Side)

• Visualizes the current lifecycle states of all subnets within the VPC:
  • Available: Active and provisioned
  • Pending: Still provisioning
  • Unavailable: Deleted, unreachable, or with failed status

Enables health monitoring of your subnet landscape. You can:

• Detect provisioning delays
• Confirm successful subnet rollout
• Catch misconfigurations that may render subnets unavailable

3. Subnet Inventory Table (Bottom)

The table offers the most complete view of each subnet’s health, capacity, and location in the cloud. Whether you're troubleshooting connectivity issues, scaling infrastructure, or cleaning up unused IP blocks— every field here helps you make faster, more accurate decisions.

How do each field empower administrators

Why It's Effective

This data in whole enables administrators to:

• Audit current IP consumption in real time
• Spot subnets that need expansion or reassignment
• Validate IPv6 readiness and DNS64 compatibility
• Plan proactive scaling without last-minute chaos

Now navigate to the Instance tab. This view displays all EC2 virtual machines (instances) tied to that VPC — giving admins direct visibility into compute resources and their current operational and networking state. DDI Central will now display a detailed list of EC2 instances deployed within this VPC.

Each instance is listed with the following key fields:

Why It's Effective

This data in whole enables administrators to:

• Allows centralized visibility into cloud-based compute assets from within the IPAM layer.
• Helps validate zone diversity and balance for DR/HA planning.
• Allows you to track instance availability and spot dormant or stopped VMs that can be deprovisioned.
• Public DNS records make it easy to trace traffic behavior back to a source instance.

Elastic Network Interface (ENI) Snapshot

Go to the Network Interface tab beside Instances. DDI Central displays every Elastic Network Interface deployed within the selected VPC.

From the same Network Interface tab, scroll further towards right to quickly view the per-interface address mapping. DDI Central makes sure to display deeper address-layer data, helping admins trace every bit of IP allocation tied to an ENI.

What does the table say

Why It's Effective

• Allows admins to verify which interfaces are live, associated, or orphaned
• Great for tracing network bottlenecks or firewall rule failures
• Centralizes security group-to-interface visibility
• Crucial for troubleshooting “no connectivity” issues from instances or services
• Provides end-to-end address tracking for security audits and troubleshooting
• Helps avoid duplicate IPs or binding failures across reboots or scaling events
• Ideal for incident forensics or confirming DNS-to-IP linkages
• Supports compliance reporting with MAC/IP/DNS binding logs

9. Load Balancer Intelligence

Now switch to the Load Balancers tab within the selected VPC view. DDI Central displays an insightful table that provides a unified view of all Elastic Load Balancers (ELBs) associated with the selected AWS VPC. It helps administrators assess traffic flow distribution, high availability, and fault tolerance.

The table presents the following insights:

Why It's Effective

• Ensures that load balancers are properly distributed across zones for high availability.
• Confirms the right type of load balancer is deployed per use case.
• Validates that the DNS entry is accessible and resolves correctly to maintain uptime.
• Allows admins to act quickly if a load balancer appears inactive, misconfigured, or not adequately zoned.

Load Balancer Intelligence

Now switch to the Load Balancers tab within the selected VPC view. DDI Central displays an insightful table that provides a unified view of all Elastic Load Balancers (ELBs) associated with the selected AWS VPC. It helps administrators assess traffic flow distribution, high availability, and fault tolerance.

The table presents the following insights:

The RDS inventory of a VPC presents the following insights:

Why It's Effective

• High Availability Planning: The AZ field helps ensure your RDS instances are spread across multiple zones for fault tolerance.
• Backend IP Planning: Knowing the status and engine types helps you align database traffic, IP allocation, and DNS naming schemes.
• Troubleshooting: Quickly detect failed or missing RDS components in your service chain.
• DNS Routing Validation: The presence and health of these RDS entries validate DNS-based application failovers.

Subnet availability overview across multiple AZs

This screen above provides an aggregated regional view of all subnets across multiple VPCs, empowering teams to understand how IP space is fragmented and utilized. In essence, this dashboard transforms raw subnet metadata into actionable intelligence—supporting cost control, risk mitigation, and uptime for network-driven workloads.

• Map Panel (Left)
  
  • Displays subnet distribution by country using red heatmap overlays.
  • Tooltip shows:
    • Country (e.g., Hong Kong)
    • AWS Service: VPC Subnet
    • Count: Total subnets provisioned
  • This reveals regional subnet density and infrastructure concentration zones.
• Donut Chart (Center)
  
  • Breaks down 42 subnets across APAC locations like Tokyo, Seoul, Hong Kong, and Singapore.
  • It offers a normalized visual of infrastructure deployment by region.
• Top Utilized Subnets (Right)
  
  • Highlights top 5 subnets in Hong Kong with the highest IP utilization.
  • It enables Admins to quickly identify which subnets are nearing exhaustion for proactive expansion.
• Table View (Bottom)
  
  • Key Fields:
    • Subnet Name: Human-readable context for project ownership or role (e.g., RDS, public, private)
    • ID: Unique reference for automation, config, and routing
    • State: Confirms health or availability of each subnet
    • Associated VPC: Shows which VPC each subnet belongs to—important for policy boundaries
    • (IPv4)CIDR: Displays subnet IP range for IP planning and overlap checks
    • Availability Zone: Ensures redundancy and AZ spread validation
    • IPv6 / DNS64: Flags subnets with special networking behavior
    • Usage: Quantified IP consumption—ideal for proactive alerting and capacity planning
    • Available IP: Real-time visibility into how much space remains in each subnet
    • Tags: Provides metadata for ownership, billing, lifecycle stage (e.g., Name, Project)

Why This View Matters

• Network teams can monitor subnet saturation before IP exhaustion or outages occur
• Cloud architects can audit subnet-to-AZ distribution to maintain fault tolerance
• Security admins can quickly scan for exposed or IPv6-enabled subnets
• Ops can align usage and allocation with organizational tagging policies
• Engineers can clean up low-usage or overlapping subnets

Associated VPCs with Subnet Context

While the subnet is a slice of the VPC, this section helps confirm which VPCs the subnet lives under and their CIDR plans. This VPC tab contextualizes the subnet within the broader cloud network architecture—giving the admin the visibility to enforce policy, plan growth, and troubleshoot intelligently.

• Fields:
  • Name: Identifies the VPC to which the subnet belongs or may be associated with. Useful for confirming environment boundaries (e.g., dev, test, prod).
  • VPC ID: A unique identifier that lets admins trace routing tables, internet gateways, and peering connections tied to the subnet. CIDR ranges (IPv4 and optional IPv6).
  • State: Verifies that the VPC is active and routable—important during provisioning or troubleshooting.
  • CIDR IPv4: Shows the IP range available in the VPC. Helps confirm whether the subnet’s IP block is within bounds and whether enough space exists for scaling.
  • CIDR IPv6: Indicates if the VPC is IPv6-enabled, helping admins plan for dual-stack or modern networking compatibility.
  • Default VPC: Flags whether the VPC is AWS’s default (auto-configured) or a custom-designed one—important for enforcing strict segmentation policies.
  • Ensures context when assessing routing behaviors or peering implications.

Why It Matters in a Subnet View

• Validates whether the subnet is part of a custom VPC with specific security/routing rules or a default VPC with more relaxed controls.
• Assists in identifying overlapping IP ranges across VPCs that could cause routing conflicts or break peering setups.
• Ensures subnet-to-VPC alignment before attaching route tables, NAT gateways, or deploying hybrid cloud connectors.
• Helps in auditing and compliance: network teams can ensure workloads are deployed in the correct VPC context.

EC2 Workloads in Subnet

Gives a list of virtual machines actively or historically using the subnet. It provides subnet-level visibility into the EC2 instances. Even in a read-only view, each field is rich with operational value for a network administrator overseeing workload distribution, access, and security posture. This view lets a network admin zoom in on how compute resources behave, communicate, and are distributed within a single subnet slice—essential for maintaining a secure, efficient, and well-architected cloud network.

Fields:

• Instance Name: Identifies workload role (e.g., media, WMS, docs). Helps in inventory management and naming convention enforcement.
• ID: Unique identifier of each instance. Critical for correlating logs, automation scripts, and audits.
• Instance State: Shows if the instance is running or stopped—useful for cost control, resource planning, and incident response.
• Type: Indicates instance size and capacity (e.g., c5.12xlarge, m5.2xlarge). Helps gauge subnet resource density and impact on IP exhaustion.
• Availability Zone: Reveals the AZ distribution of workloads—key for HA design and latency planning.
• Public DNS / Public IPv4: Provides external reachability insights. Identifies which instances are internet-facing and subject to additional security scrutiny.
• IPv6 IPs: Displays IPv6 readiness. Important for hybrid and modern app architectures.
• Platform: Reveals the OS platform (Linux/UNIX) for OS-specific firewalling or patching compliance.
• Helps determine traffic origin and capacity stress imposed on the subnet.

Why This Matters in a Subnet View:

• Confirms whether the subnet is hosting production-facing compute or backend-only workloads.
• Enables rapid identification of improperly placed or idle/stopped instances.
• Supports network isolation validation: e.g., whether public IPs should exist in this subnet.
• Aids in identifying AZ imbalance that could affect availability or performance.
• Improves capacity planning: is this subnet approaching IP exhaustion due to instance count?

Network Interface Mapping (ENI)

This section displays all ENIs of a subnet.

Fields:

• Name / Subnet ID: Helps quickly identify and reference specific subnets in large VPC architectures.
• VPC ID: Ties the subnet to its parent network boundary, important for routing, NATs, and gateways.
• Instance ID: Shows which EC2 instances are attached to this subnet — helps understand workload distribution.
• Availability Zone: Clarifies fault domain — helps ensure high availability through multi-AZ architecture.
• Security Group / ID: Reveals which firewall rules govern traffic for instances in this subnet — crucial for audit and compliance.
• Public / Private DNS: Indicates DNS naming for attached resources — aids in debugging and service discovery.
• Public / Private IPv4: Lets you track assigned IPs — useful for IP planning, troubleshooting, and inventory management.
• MAC Address: Can help in deep-level diagnostics, network capture correlation, or static IP assignments.
• IPv6 IPs: Supports dual-stack visibility if the subnet uses IPv6 — important for modern network scaling.

Why This View Matters:

• Gives a per-subnet breakdown of all network interfaces (ENIs) and their associations.
• Helps ensure proper IP segmentation, routing isolation, and AZ alignment.
• Aids in troubleshooting (e.g., "Why can’t this instance reach the internet?") by cross-verifying IPs, AZ, SGs, and instance bindings.
• Supports cost monitoring and capacity planning by viewing available IPs and usage density.

Load Balancers Active Within Subnet Scope

Provides visibility into DNS-driven traffic handling for workloads hosted in or routed through the subnet's VPC.

Fields:

• Load Balancer Name: Identifies which load balancers are actively serving resources within this subnet. Helpful for quick correlation with infrastructure services.
• DNS Name: Shows the publicly or internally resolvable name used by clients to reach services. Useful for testing, monitoring, and endpoint validation.
• State: Indicates operational status (e.g., active/inactive). Helps quickly identify health or deployment issues tied to the subnet.
• VPC ID: Verifies which VPC the load balancer belongs to. Ensures proper segmentation and routing.
• Availability Zone (AZ): Reveals redundancy spread. Load balancers deployed across multiple AZs improve fault tolerance and load distribution.
• Type: Shows the purpose of each load balancer (application, network, gateway). This helps in understanding traffic patterns and where in the OSI model the traffic is handled.

Why It Matters:

• Enables subnet-level troubleshooting when latency or access issues occur.
• Helps assess whether application traffic is properly distributed across zones.
• Validates whether load balancing is set up for public access, internal routing, or API gateway functions.
• Supports planning for scaling, security group assignments, and subnet utilization.

This view, even at a glance, is a tactical hub for understanding how load-balanced traffic flows through a network slice (subnet) in a complex AWS environment. Highlights DNS path redundancy and fault-tolerant delivery per subnet-aware applications.

RDS Instances Bound to Subnet

Displays databases deployed in or routed through the subnet.

Displays databases deployed in or routed through the subnet.

• Fields:
  • Name: Identifies the database workload operating in this subnet. Useful for correlating network flows, auditing, and troubleshooting.
  • Status: Shows if the DB instance is healthy, pending, or failing—critical for real-time operational awareness.
  • Engine: Displays the database engine (e.g., sqlserver-ex), informing the admin about potential port/protocol needs and performance characteristics.
  • Availability Zone: Indicates which AZ this database resides in—important for understanding redundancy, failover design, and latency sensitivity.
  • VPC ID: Confirms the broader network boundary that governs this subnet, helping enforce routing, firewall, and segmentation policies.
  • Brings data-layer visibility to the network admin—align IP scopes to data workloads.

Why This Matters in the Context of a Subnet

• Confirms whether the subnet is serving critical back-end workloads like databases—useful for deciding whether the subnet should remain private (non-routable from the internet).
• Helps with designing and validating subnet-AZ alignment (e.g., DBs in one AZ, apps in another for HA).
• Supports IP planning—admins can ensure there's enough capacity left in the subnet for future DB replicas or read-only nodes.
• Enables root-cause investigation in case of connection drops, latency spikes, or security incidents affecting data services.

In short, this tab gives subnet-level clarity into how data workloads are distributed, isolated, and operating—essential for maintaining secure, high-performing infrastructure in cloud-native environments.

Tagging and Metadata Classification

Tags are essential labels that offer structure to what could easily become a tangled web of IP ranges—ensuring governance, clarity, and agility across environments. Enables auditability, searchability, and billing segmentation by project, region, or department.

DDI Central displays governance-level labels for the subnet.

• Fields:
  • Key: User-friendly identifier for the subnet. Helps avoid confusion when managing dozens or hundreds of subnets across environments or regions.
  • Value: Conveys purpose, scope, location, and tier of the subnet (e.g., "project", "private1", "ap-east-1a"). This can inform routing, access, or automation decisions.

Why It Matters (Especially on Subnets):

• Clarity: Helps engineers quickly identify the role and region of a subnet without digging through IP ranges.
• IAM & Automation: Enables fine-grained permissions and automation rules (e.g., “only allow tagging to ‘private’ subnets”).
• Cost & Audit: Assists in cost attribution and usage reporting when subnets are tied to a project, team, or environment.
• Filtering & Grouping: Allows dashboards, scripts, and inventory tools to filter subnets based on purpose or lifecycle (e.g., prod/dev/staging).