What gets discovered (380+ types) and how

Outcome

By the end of this lesson, you will be able to predict whether a given cloud resource type appears in ZopNight’s discovery surface and explain the three discovery methods (RE2, Asset Inventory, Resource Graph).


Tier	Operator
JTBD	”Confirm a resource I just deployed shows up: and know what to do if it doesn’t.”
Personas	Platform Engineer · FinOps Analyst
Prerequisites	M1.1
Time	10 minutes
Bloom verb	Predict (Apply) and Explain (Understand)

1. Concept

ZopNight finds 380+ kinds of resource across AWS, GCP and Azure.

Each cloud offers one service whose job is to list everything you own. ZopNight starts there, then asks each individual service for the details that the master list leaves out.

PROVIDER        DISCOVERY METHOD                       TYPES DISCOVERED
─────────────────────────────────────────────────────────────────────────
AWS             Resource Explorer 2 (RE2) primary       191 unique types
                + per-service providers for detail       (204 RE2 keys)
GCP             Cloud Asset Inventory                    88 types
Azure           Resource Graph (with expanded query)    101 types

Total: about 380 distinct resource types covered.

How AWS discovery works

AWS’s master list is called Resource Explorer 2, shortened to RE2. One search returns resources from every service and every region at once, which is why it is the starting point:

Discoverer calls RE2:
  Search(query="*", regions=["us-east-1","us-west-2","eu-west-1",...])

Returns: 12,400 resources across 47 service types

For each resource, the discoverer then calls the per-service API for
detailed metadata (instance type, tags, IOPS, Multi-AZ, status):
  ec2.DescribeInstances(InstanceIds=[...])
  rds.DescribeDBInstances(DBInstanceIdentifier=...)
...

Why do both? RE2 tells you what exists, consistently, everywhere. The individual services tell you what each thing is actually configured as. Some details, particular tag values or a machine’s configuration, simply are not in RE2.

RE2 has to be switched on in your AWS account for the full picture. If it is off, ZopNight falls back to asking every service one at a time. That still works, and it takes longer.

How GCP discovery works

Google’s equivalent is Cloud Asset Inventory, asked for resources rather than for policies:

Discoverer calls Cloud Asset Inventory:
  ListAssets(parent="organizations/{orgId}", contentType=RESOURCE)

Returns ~8,000 assets across 88 types.

Not everything Google returns belongs on a resource list. Short-lived
permission records, for instance, are noise. Those are filtered out
before you ever see them.

Where things live. A Google resource sits either in a region or in one zone inside it. ZopNight reads the region out of the resource’s own path, so every resource records its location the same way.

Special handling for some services:

GCS buckets are enriched with size + object count via Cloud Monitoring metrics
Artifact Registry repositories are enriched with image count + total size

How Azure discovery works

Azure’s master list is Resource Graph. It takes a query, so ZopNight asks for all 101 types it supports in a single request:

Discoverer queries Resource Graph:
  query = "Resources | where type in (...101 type list...)
                       | project id, name, type, location, tags, properties"

Returns ~6,000 resources across the 101 types.

Databricks needs a second step. Resource Graph reports the workspace and stops there. ZopNight then looks inside each workspace and lists its clusters, instance pools and SQL warehouses as things that belong to it, which L2 explains.

The 380+ list

The full inventory of supported types is long. Here is the shape of coverage:

CATEGORY                   AWS                GCP                AZURE
─────────────────────────────────────────────────────────────────────────────
Compute                    EC2, ECS, ASG,     Compute Engine,    VM, VMSS, AKS
                           Fargate, App Run.  GKE                 nodepool
K8s control plane          EKS                GKE                AKS
K8s workload children      Deploy, STS, Cron  Deploy, STS, Cron  (same)
Serverless                 Lambda             Cloud Functions    Functions
                                              Cloud Run
Database                   RDS, Aurora,        Cloud SQL,         Azure SQL,
                           DynamoDB, DocDB,    Spanner,           Cosmos DB,
                           ElastiCache,        Memorystore        MySQL Flex,
                           Redshift, Keyspaces                    PostgreSQL Flex
Storage (object)           S3                  GCS                Blob Storage
Storage (block)            EBS                 Persistent Disk    Managed Disks
Storage (file)             EFS                 Filestore          Azure Files
Container registry         ECR                 Artifact Registry  ACR
Networking                 VPC, NAT, ELB,      VPC, Cloud LB,     VNet, App GW,
                           ALB, NLB,           Cloud NAT          Load Balancer
                           CloudFront                              Front Door
Data & Analytics           EMR, EMR Serverless GKE for analytics  Synapse,
                           Glue, Athena                            Data Explorer,
                                                                   Databricks
ML / AI                    SageMaker,          Vertex AI          Azure ML
                           Bedrock
Messaging                  SQS, SNS, EventBridge Pub/Sub          Service Bus,
                                                                   Event Grid
─────────────────────────────────────────────────────────────────────────────

If a type is not on the list, it does not appear in ZopNight. Adding one is work on our side, not something you can configure, so a missing type is a request to make rather than a setting to find.

What is NOT discovered

A few deliberate exclusions:

Users, roles and groups. Collected separately, to work out who owns what, and kept off the resource list
Secrets and certificates. Security items, with no cost attached
The billing records. They arrive through the billing sync instead
Logs and events. They arrive through the activity-log sync instead

Clouds outside the three, such as Oracle Cloud, IBM Cloud or Alibaba, are not covered at all. Individual services can be added on request.

How often the list is refreshed

DISCOVERY CRON             Every 6 hours
MANUAL REFRESH              On-demand (covered in L5)
METADATA ENRICHMENT         During the same discovery run
PER-SERVICE DETAIL          Triggered for new or updated resources

Something created in your cloud shows up in ZopNight within 6 hours. Press refresh yourself and it is 2 to 3 minutes.

2. Demo

A typical discovery run for a mid-size AWS account:

T+0       Discovery cron fires for account 941614911918
T+1 min   RE2 search returns 8,247 resources across 31 type categories
T+2 min   Per-service enrichment begins (parallel calls)
T+3 min   EC2 details: 1,840 instances enriched
T+3 min   RDS details: 47 databases enriched
T+4 min   S3 buckets: 142 buckets, size + object count from CloudWatch
T+5 min   EKS clusters: 6 clusters, each with nodegroups + Deployments enumerated
T+6 min   Permission Visibility drawer updated with Granted/Denied state
T+6 min   Recommendation engine fires for new findings
T+6 min   UI refreshes

Six minutes from sync start to UI updated. The customer sees the new estate state without manual intervention.

3. Hands-on (6 min)

For one of your connected accounts:

1. Open ZopNight → Resources.
2. Note the total resource count in the header.
3. Filter by Provider = AWS (or GCP, or Azure).
4. Count visible types (or count via the Grouped Type dropdown: covered L3).
5. Compare against your cloud's expected resource type spread.

If a resource type you know is in the cloud is NOT in the list:
  a. Check the Permission Visibility drawer (M1.1 L4) for any
     Denied state on that resource type.
  b. If Permission is Granted but the resource isn't shown,
     wait for the next 6h cron OR click Manual refresh.
  c. If still missing, the type may be outside ZopNight's 380+
     supported types. Check the documentation; submit a roadmap
     request if it's a frequent type.

Ask for it instead. The same task you just did in the console, asked in one sentence.

BEFORE  A ZopNight account with one cloud connected. Discovery run once. Anything in the supported list counts: EC2, RDS, EKS, Compute Engine, Cloud SQL, GKE, Azure Virtual Machines, AKS.
ASK     "How many resources did discovery find, by type and by account, and when did it last run?"
CHECK   the counts against the console. A gap is usually a permission the account is missing, not a resource that is not there.

Tools behind it: get_discovery_summary (read, Explore), get_resource_count (read, Explore), get_resources_last_synced (read, Explore). The full catalogue is at zop.dev/learn/mcp-tools.

4. Knowledge check

Q1

A new EC2 instance was launched 15 minutes ago. The ZopNight resource list does not show it yet. The most likely cause:

A. The 6-hour discovery cron has not run since the launch
B. ZopNight is broken
C. The instance is sitting in the wrong region entirely
D. Permission is denied

Show answer

Correct: A. Click Manual refresh to discover within 2-3 minutes, or wait for the next scheduled cron. Six-hour cron is the default. Manual refresh is the immediate path.

Q2

A team uses AWS Resource Explorer 2 disabled (the customer hasn’t enabled it). What happens to ZopNight discovery?

A. Discovery fails completely
B. Only EC2 is discovered
C. ZopNight cannot connect to that account properly
D. Discovery falls back to per-service-only calls

Show answer

Correct: D. Slower (more API calls, longer time), but functional. ZopNight recommends enabling RE2 in the customer’s account for full performance. RE2 is the primary path; per-service is the fallback. Both work; RE2 is faster and more consistent across services.

Q3

Which of these resource types are NOT discovered by ZopNight?

A. EC2, RDS, S3
B. Lambda, EKS, ECS
C. IAM users, secrets, certificates; these are out of scope for the resource list (IAM users flow through ownership detection, secrets and certificates are security artifacts not cost-relevant)
D. Compute Engine, GKE and Cloud SQL only, since those are the three services that Cloud Asset Inventory returns and everything else has to be fetched by a per-service call

Show answer

Correct: C. Exclusions are deliberate. ZopNight focuses on cost-relevant resources; security artifacts and identity principals are handled by other surfaces.

5. Apply

The Resources page is the primary discovery surface:

Resources page: the main view
Manual Refresh in the header: triggers an immediate discovery cycle
Discovery Status indicator: shows when a sync is in progress
Permission Visibility (per account): shows what is being scanned and what is not

For deeper drill-down (parent-child, filters, bulk actions), continue to L2 and L3.

Glossary terms touched

Resource Explorer 2 · Cloud Asset Inventory · Resource Graph · Discovery cron · Metadata enrichment

Outcome

1. Concept

How AWS discovery works

How GCP discovery works

How Azure discovery works

The 380+ list

What is NOT discovered

How often the list is refreshed

2. Demo

3. Hands-on (6 min)

4. Knowledge check

Q1

Q2

Q3

5. Apply

Related lessons

Glossary terms touched

Start with the bill.