Cloud discovery

Cloud discovery lets an agent inventory your AWS resources and turn them into monitors for you, so you don’t have to add each endpoint by hand.

What it discovers

An agent with AWS access lists, from the AWS API:

• Load balancers — ALBs and NLBs, with their ports and tags.
• EC2 instances — with public/private IPs, VPC, and tags.
• RDS databases — with their endpoint, port, engine, and tags.

Discovery is AWS only today. (There is no Kubernetes discovery, despite older design notes — an agent discovers the three AWS resource kinds above.)

Requirements

• An enrolled agent that can reach the AWS API, configured with AWS credentials (an IAM role or keys) and the region(s) to scan.
• Cloud discovery is available on every plan — there’s no separate entitlement to turn on.

From resources to monitors

You control what becomes a monitor with match rules. Each rule matches resources by a tag or attribute (equals, one-of, exists, or a regex) and maps a match to a monitor — its type, port, and name. You choose the monitor type for each rule (a new rule starts with none selected). A live preview shows exactly what would be created before you commit.

An HTTP monitor made from a resource gets a full web address. The port comes from your rule, or else from the resource’s first listed port. Port 443 or 8443, or no port at all, gives https://; any other port gives http://. Ports other than the standard 80 and 443 are written into the address, as in https://my-lb.example.com:8443 or http://my-lb.example.com:8080.

If your rule takes the monitor type from a tag and that tag’s value is https, the monitor uses https:// whatever the port, and a load balancer listening on both 80 and 443 uses 443. When the resource’s address already starts with http:// or https://, the port from your rule is added to it (unless it is the standard port for that scheme). IPv6 addresses are written in square brackets, as in [2001:db8::1]:22.

EC2 instances are discovered without ports. If an instance serves plain HTTP, set the port in your rule (for example 80); otherwise the check uses https://.

Without a matching rule, an EC2 instance is adopted as a ping (ICMP) check. Many security groups block ping, and the monitor would then time out. If yours does, either allow ICMP from your agent in the security group, or add a rule that makes a TCP or HTTP check on a port the instance serves.

Then choose how resources become monitors:

• Manual — review the discovered resources and adopt the ones you want, one by one.
• Auto-adopt — turn on a per-agent toggle and matching resources become monitors automatically. Auto-adoption stops at your plan’s monitor limit, so it never creates more than you’re allowed. It only considers resources the agent’s most recent scan actually saw, so a resource that has gone away while scans were failing is never adopted.

Monitors created from discovery check every minute, or at your plan’s fastest check interval if that’s slower (every 5 minutes on Free). You can change the interval on the monitor afterwards, down to your plan’s limit.

When a later scan no longer sees a resource, CuliPulse marks it closed rather than deleting it, so you keep the history. A scan that reports an error, such as missing AWS permissions or a region that isn’t enabled, is only partly complete. Newer agents tell CuliPulse which services and regions they did read successfully, and CuliPulse closes vanished resources from those, so one missing permission doesn’t stop clean-up elsewhere. Resources of the service or region that failed stay in the list, and older agents close nothing while the agent’s page shows a discovery error. Fix the permission or region problem, and the next scan without errors brings the whole list up to date.

Discovery reads every page of results AWS returns, so accounts with many load balancers, servers or databases are scanned in full (agent version 1.11.0 and later). If AWS refuses or times out while reading part of a scan, for example one load balancer’s listeners or tags, that shows as an error on the agent’s page. The affected resources keep their last known details until a later scan reads them successfully. Each region gets its own time limit, so one slow region can’t cut the others short.

A monitor made from a resource is tagged orphaned in your monitors list when that resource disappears from scans, or when CuliPulse can no longer tell how to check it (for example, a load balancer or database that no longer reports a port and has no matching rule). CuliPulse never deletes or pauses the monitor; you decide whether to keep it. The tag clears by itself when the resource comes back. Editing or removing match rules doesn’t flag monitors you’ve already adopted, as long as CuliPulse can still check the resource.

Local network scan

Separately from AWS discovery, an agent can scan a local network range (a CIDR block) on ports you specify and report the open TCP services it finds — useful for taking stock of what’s running on an internal network. This is configured on the agent itself and is distinct from cloud discovery above.

Adopting a service the scan found creates a TCP monitor that checks at the same interval as other discovered monitors: every minute, or your plan’s fastest interval if that’s slower.