AWS monitoring is the practice of collecting availability and performance data from cloud resources such as EC2 compute instances, EBS volumes, S3 storage buckets, and load balanced endpoints, comparing that data against thresholds you define, and alerting when a value moves outside the acceptable range. Because AWS handles the underlying hardware, monitoring focuses on the metrics AWS exposes through CloudWatch, on the operating system and applications running inside your instances, and on whether the services your users depend on are actually reachable.

• Burstable instances degrade silently: A T-family instance that drains its CPU credit balance keeps running at baseline performance, so applications slow down without any instance failing.
• Storage costs track object counts and bucket size: Watching both over time shows which buckets are growing and where lifecycle rules are missing.
• Error rates identify the failing side: Separating 4XX from 5XX responses on an S3 bucket distinguishes a client-side request problem from a service-side one.
• Latency changes precede user complaints: First byte latency and total request latency move before anyone opens a ticket.
• Cloud and on-premises problems interact: A hybrid outage is faster to diagnose when both environments report into one Host and Service list.
• Utilization data supports rightsizing: Recorded CPU, disk, and network figures show which instances are oversized before you change instance types.

Amazon EC2 Instance Monitoring

The Amazon EC2 Wizard connects with an Identity and Access Management (IAM) user’s Access Key ID and Secret Access Key, retrieves your available instances, and creates Host and Service checks for the metrics you select.

• CPU Credit Usage and CPU Credit Balance: Track credit consumption and remaining balance on burstable instance types.
• CPU Utilization: Alert on sustained load and identify instances running well below their allocation.
• Disk Read/Write Operations: Watch I/O operation counts against the instance’s attached volumes.
• Disk Read/Write Bytes: Measure throughput to separate an IOPS ceiling from a bandwidth ceiling.
• Network In/Out: Record inbound and outbound traffic volume per instance.
• Network Packets In/Out: Track packet counts alongside byte counts.
• Instance Up/Down: Report instance state as the Host check.

Set Warning and Critical thresholds for each metric in Step 2 of the wizard.

Documentation: How To Monitor Amazon EC2 In Nagios XI | How To Troubleshoot EC2 Data Issues In Nagios XI

Amazon EBS Volume and Disk Monitoring

The disk metrics in the Amazon EC2 Wizard, Disk Read/Write Operations and Disk Read/Write Bytes, describe I/O activity against the volumes attached to an instance. These are the metrics to watch for a volume that has become an application bottleneck.

• Detailed Monitoring: If most checks return no data, enable Detailed Monitoring on the instance from the Monitoring tab in the instance details.
• CloudWatch Agent: If Detailed Monitoring is already enabled and only the disk checks return no data, install a CloudWatch Agent on the instance. Red Hat Enterprise Linux distributions may require an alternative setup path.
• Filesystem capacity: Volume I/O metrics do not report how full a filesystem is. Use NCPA inside the instance for free space, inode, and mount point checks.

Documentation: How To Troubleshoot EC2 Data Issues In Nagios XI

Amazon S3 Bucket Monitoring

The Amazon S3 Wizard retrieves your available buckets from the same IAM credentials and creates checks per bucket. Your Nagios XI server must have boto3 installed.

• Bucket Size: Total bucket size in bytes.
• Number of Objects: Object count per bucket.
• All/Get/Put Requests: Overall and read/write request volume.
• Delete Requests: Deletion request volume.
• Head/Post/List Requests: Metadata and listing request volume.
• Bytes Downloaded/Uploaded: Data transfer volume in each direction.
• 4XX Errors: Client-side error responses, including missing keys and rejected requests.
• 5XX Errors: Service-side error responses.
• First Byte Latency: Time to first byte on bucket requests.
• Total Request Latency: End-to-end request duration.

Documentation: How To Monitor Amazon S3 In Nagios XI

Operating System and Application Monitoring on EC2 Instances

CloudWatch metrics describe the instance from outside. Install NCPA on the instance for what is happening inside it: memory usage, filesystem capacity, running processes, and services. The NCPA Wizard takes an address, a port, and a token, then presents the metrics discovered on that Host. The same agent and the same wizard cover Windows, Linux, macOS, AIX, and Solaris instances, so cloud servers configure exactly like the Linux server monitoring you already run on-premises. Containerized workloads on EC2 are covered by Docker container monitoring.

Documentation: Installing NCPA | How To Monitor Devices Using NCPA In Nagios XI

Load Balanced Endpoint and Elastic Load Balancing Checks

ICMP-based checks such as check_icmp and check_ping are frequently unreliable health signals for endpoints behind managed load balancers, including AWS ELB, ALB, and NLB. A command line ping that appears to succeed does not mean the plugin will, because packet construction differs and middleboxes and individual front-end nodes respond inconsistently.

• Identify cloud-hosted targets: Run nslookup and look for CNAME chains ending in domains such as elb.amazonaws.com.
• Use an HTTP check: check_http or check_xi_service_http for HTTP and HTTPS endpoints.
• Use a TCP check: check_tcp against the application port, for example 443, for lightweight reachability.
• Review the Website Wizard output: It creates a Ping service by default. Remove or disable that service when the target sits behind a load balancer.

Documentation: Load Balanced Cloud Host Check Considerations For Nagios XI | Changing Host Alive Check In Nagios XI

AWS Monitoring Thresholds and Alerting

• Per-metric thresholds: Every metric selected in the EC2 and S3 Wizards carries its own Warning and Critical values, set during Step 2.
• State-based notifications: Notifications fire on transitions between OK, Warning, Critical, and Unknown, so a metric that recovers on its own does not generate a page.
• Notification scope: Steps 3 through 5 of each wizard set check intervals, notification conditions, contacts, and Host group and Service group membership.
• Dashboards and reports: Collected AWS metrics feed the same graphs, availability reports, and capacity planning views as the rest of your monitored infrastructure.

IAM Permissions and Credential Handling

• Scope the IAM policy to what the wizards read: cloudwatch:GetMetricStatistics, cloudwatch:GetMetricData, cloudwatch:ListMetrics, ec2:DescribeInstances, and ec2:DescribeRegions.
• Use a dedicated IAM user for monitoring: Do not reuse an administrative account’s credentials for the wizards.
• Keep secrets out of Service definitions: Store the Secret Access Key as a user macro and reference the macro, so the value is not visible in the Core Config Manager.
• Restrict inbound agent access: Allow TCP 5693 from the Nagios XI server only, in the security group attached to instances running NCPA.

Documentation: Understanding User Macros In Nagios XI

One view across cloud and on-premises. EC2 instances, S3 buckets, and the physical servers in your data center appear in the same Host and Service lists, under the same Host groups, with the same escalation rules. Hybrid incidents get diagnosed from one screen instead of two consoles.

Alerting that reflects your thresholds, not defaults. You define what counts as a Warning and what counts as Critical for every AWS metric you collect, and adjust as workloads change.

Historical data for rightsizing decisions. Recorded CPU, disk, and network utilization over weeks shows which instances are consistently oversized and which are near their ceiling, which turns instance type changes into a decision backed by measurements.

Guest-level visibility that CloudWatch metrics alone do not provide. Memory usage, filesystem capacity, service state, and process counts come from NCPA inside the instance.

Consistent operations as you migrate. Teams moving workloads to AWS keep the notification paths, contact groups, reports, and dashboards they already use, so monitoring does not have to be rebuilt alongside the migration.

• Active Maintenance & Support benefits: Required for the Amazon EC2 Wizard and the Amazon S3 Wizard.
• An IAM user with an Access Key ID and Secret Access Key: Created in the AWS Management Console under the account’s security credentials.
• An IAM policy granting cloudwatch:GetMetricStatistics, cloudwatch:GetMetricData, cloudwatch:ListMetrics, ec2:DescribeInstances, and ec2:DescribeRegions: Without these, the wizard cannot list your instances.
• boto3 installed on the Nagios XI server: Required by the Amazon S3 Wizard.
• Outbound HTTPS from the Nagios XI server to the AWS API endpoints: The wizards query AWS from the Nagios XI server.
• A security group rule permitting ICMP, if you want a ping check: New EC2 instances have ping disabled by default.
• Detailed Monitoring enabled on instances where per-metric granularity matters: Set from the Monitoring tab in the instance details.
• A CloudWatch Agent on instances whose disk checks return no data: Needed on some instance configurations.
• NCPA installed and TCP 5693 reachable from the Nagios XI server: Required for operating system and application checks inside instances.

1. In the AWS Management Console, create an IAM user for monitoring, attach a policy granting the CloudWatch and EC2 read permissions listed above, and generate an Access Key ID and Secret Access Key.
2. In Nagios XI, navigate to Configure > Configuration Wizards and select the Amazon EC2 Wizard.
3. In Step 1, enter the Access Key ID and Secret Access Key, click Get Available Instances, select the instance to monitor, and click Next.
4. In Step 2, enter a valid Host Name, select the metrics you want, and set Warning and Critical thresholds for each.
5. Complete Steps 3 through 5 to set check intervals, notification settings, and group membership, then click Finish to apply the configuration and begin monitoring.
6. Repeat with the Amazon S3 Wizard for bucket monitoring, using Get Available Buckets in Step 1, then install NCPA on your instances and run the NCPA Wizard for operating system metrics.

Documentation: How To Monitor Amazon EC2 In Nagios XI | How To Monitor Amazon S3 In Nagios XI | Understanding And Using Configuration Wizards In Nagios XI

Nagios XI covers availability and performance: is the instance up, is the volume keeping pace with I/O demand, is the bucket returning errors, is the application inside the instance responding, and has any of those crossed a threshold you set. It compares each check result against the values you specified and changes state accordingly. It does not classify a result as anomalous on its own, and it does not evaluate configuration against a security benchmark.

Adjacent capabilities live in separate Nagios solutions, each licensed on its own. Centralizing and searching CloudTrail, VPC Flow Logs, or application logs written by your instances is the job of Nagios Log Server. Flow record analysis and intrusion detection belong to Nagios Network Analyzer. Consolidating several independent Nagios XI servers, for example one per region or per business unit, into a single view is what Nagios Fusion does. Billing and cost allocation data is outside the scope of all four.

AWS Services

• Amazon EC2 monitoring
• Amazon S3 monitoring

Workloads Running on AWS

• Linux server monitoring
• Docker container monitoring

Nagios Solutions

• Nagios XI
• Nagios Log Server
• Nagios Network Analyzer
• Nagios Fusion

Install Nagios XI, create an IAM user with read access to CloudWatch and EC2, and run the Amazon EC2 Wizard. Your first instances report into the same interface as the rest of your infrastructure within the trial period, with no changes to the instances themselves.