Nagios Vs CloudWatch AWS

Monitoring is certainly an important thing in maintaining consistent infrastructure in cloud or on-premise network infrastructure. AWS CloudWatch is a native tool to monitor the AWS Services.CloudWatch can monitor AWS resources like EC2, DynamoDB, Lambda, RDS, and Custom Metrics generated by your application or service. We can use CloudWatch to have automated monitoring by use of ALARMS. With the use of ALARM’s in CloudWatch, you can send alerts to your team whenever the ALARM breaches.

On EC2 CloudWatch provides system-wide metrics like CPU Utilization, Brust balance for T2 type instances, Available Memory( with use of Custom Metrics) and it also provides metrics for EBS Volumes such as BytesRead, BytesWrite, VolumeQueueLength i.e Number of reading, writes operations waiting to be completed in a specific duration of time. By using these metrics we can analyze the performance of the applications and audit the logs for security and compliance.

There is no shortage of monitoring tools besides CloudWatch. One such popular tool is Nagios, it has its advantage of being an early player in monitoring the IT infrastructure. Nagios is trusted monitoring tool for enterprises who are working with on-premise networks.It can monitor the network, servers, and applications as well.

Nagios extends its usage to monitoring the Cloud Computing resources too. The following described highlights can be used for deciding which monitoring tool to be used based on your usage.

  • ALARMS:

AWS CloudWatch and Nagios both have capabilities of monitoring the deployment of Computing resources in AWS. When it comes to monitoring the metrics of other AWS Resources such as RDS, DynamoDB or other managed services, CloudWatch unsurprisingly leads over Nagios. CloudWatch is not interoperable with third-party messaging tools like slack. Instead, ALARM’s in CloudWatch uses SNS to publish Email Alerts. In this Nagios much matured with its wide community plugins.

It is to be noted that Nagios can not monitor the IOPS of EBS and Burst Balance of EC2 resources. These metrics provide good reasons to find out the application performance and system level metrics over given period of time.

  1.     Resource Metrics:

If comes to AWS Cloud resources, CloudWatch provides many detailed metrics for every resource in AWS. CloudWatch can even store these metrics over a period of 4 weeks. With these stored metrics you can analyze the performance of your application servers based on the generated load. CloudWatch is on top of Nagios in storing the Metrics for Cloud Services.

CloudWatch provides a rich set of graphics for all AWS resource metrics. 

3.Events

Events are set of rules that will trigger the other AWS resources like calling lambda, creating an Ec2 instance etc. This feature quite useful in the cloud to automate the things. Events in CloudWatch can also be used as Cron job as to trigger for every 5 minutes a lambda function or call some other service. Nagios lacks these kinds of the feature.

  4.Ease of Use

Nagios is a centralized monitoring system provides support for monitoring the network, storage and computing devices. Being a legacy monitoring system it is a bit hard to understand the things in Nagios.You need to have a learning curve in Nagios. CloudWatch is more user-friendly and provides graphs for each metric.

  5.Pricing

Nagios is free open sourced, but when it comes to using enterprise features you have to be prepared to pay from your pocket.Nagios Enterprise features price starts from $1995.

Comparative to Nagios enterprise edition CloudWatch is cost effective. Each Dashboard in CloudWatch cost about $3.00 per month where detailed monitoring cost $3.50 per month

Bottom Line: If you are enterprise and wants to move your existing infrastructure from on-premise to Cloud try with your existing monitoring tools and start using CloudWatch monitoring features and if it satisfies your monitoring needs replace Nagios with CloudWatch.

 

If you need to monitoring any network appliance which most telecom companies use in Cloud, I would strongly suggest using existing Nagios. Because CloudWatch does not provide application metrics as Nagios provides.

Best Regards

Naveen

Hybrid Cloud with CISCO CSR 1000v

Cisco CSR 1000v series is a router software appliance from Cisco. It provides enterprise routing, VPN, Firewall, IP SLA, and more.CSR 1000v can be used to connect multiple VPC across all-region in AWS Cloud and on-premise networks. Thus it can be used avoid managed VPN service from AWS.

In AWS, you can find Cisco CSR 1000v in AWS marketplace which has 30 days free trial to test it out. AWS Marketplace for Cisco. Be aware this is not cheap, it will cost you EC2 Instance charges. All instance types are not supported for CSR 1000v. It supports only m3 and c3 instance family types.

Cisco CSR 1000v Can be used in various network models in cloud like Transit VPC, multi-cloud Network.

Following is the Architecture I have used to connect multiple VPC.

 

The two VPC’s are one in N.Virginia region and other is in Ohio Region. And Each VPC has Internet Gateway and were connected over VPN. On Ohio region, we used AWS managed VPN service to connect VPC in N.Virginia region VPC. And On-Premise Edge Router we used Cisco RV110W small business router. In this Post, I would like to mention the steps to follow to establish VPN over two VPC’s spread in two different regions in AWS.

Steps to create VPC’s in two regions:

  1. Create VPC in N.Virginia Region with CIDR 10.0.0.0/16 and attach Internet Gateway to it. you can do it from CLI or through the management console.
    aws ec2 create-vpc --cidr-block 10.0.0.0/16 --region us-east-1
    
    Output:
    {
                "Vpc": {
                    "VpcId": "vpc-848344fd",
                    "InstanceTenancy": "dedicated",
                    "Tags": [],
                    "CidrBlockAssociations": [
                        {
                            "AssociationId": "vpc-cidr-assoc-8c4fb8e7",
                            "CidrBlock": "10.0.0.0/16",
                            "CidrBlockState": {
                                "State": "associated"
                            }
                        }
                    ],
                    "Ipv6CidrBlockAssociationSet": [],
                    "State": "pending",
                    "DhcpOptionsId": "dopt-38f7a057",
                    "CidrBlock": "10.0.0.0/16",
                    "IsDefault": false
                }
              }
    
    
    aws ec2 create-internet-gateway --region us-east-1
    
    Output:
    
              {
                  "InternetGateway": {
                      "Tags": [],
                      "InternetGatewayId": "igw-c0a643a9",
                      "Attachments": []
                  }
              }
    
    
    
    aws ec2 attach-internet-gateway --gateway-id <<IGW-ID>> --vpc-id <<VPC-ID>> --region us-east-1
  2. Create two subnets in N.Virginia Region VPC, one for CSR 1000v with CIDR 10.0.0.0/24 and another subnet with CIDR 10.0.1.0/24.
    aws ec2 create-subnet --cidr-block 10.0.0.0/24 --vpc-id <<VPC-ID>> --region us-east-1
    
    Output:
    {
                  "Subnet": {
                    "VpcId": "vpc-a01106c2",
                    "AvailableIpAddressCount": 251,
                    "MapPublicIpOnLaunch": false,
                    "DefaultForAz": false,
                    "Ipv6CidrBlockAssociationSet": [],
                    "State": "pending",
                    "AvailabilityZone": "us-east-1a",
                    "SubnetId": "subnet-2c2de375",
                    "CidrBlock": "10.0.0.0/24",
                    "AssignIpv6AddressOnCreation": false
                  }
              }
    
    aws ec2 create-subnet --cidr-block 10.0.1.0/24 --vpc-id <<VPC-ID>> --region us-east-1
    
    Output:
    {
                  "Subnet": {
                    "VpcId": "vpc-a01106c2",
                    "AvailableIpAddressCount": 251,
                    "MapPublicIpOnLaunch": false,
                    "DefaultForAz": false,
                    "Ipv6CidrBlockAssociationSet": [],
                    "State": "pending",
                    "AvailabilityZone": "us-east-1b",
                    "SubnetId": "subnet-2c2de375",
                    "CidrBlock": "10.0.1.0/24",
                    "AssignIpv6AddressOnCreation": false
                  }
              }
  3. Create Route Table in N.Virginia VPC which will have the default route to Internet Gateway.And associate CSR subnet to it.

4. Launch the CSR 1000v from AWS MarketPlace with the one-click launch. Link To AWS Marketplace, you can ssh into the CSR 1000v instance using ec2-user.Attach Elastic IP to the CSR instance which will act as Customer Gateway in N.Virginia Region VPC. In later steps, we will configure the router to add Static routes to other subnets in VPC and setting BGP to propagate routes over VPN Connection with other VPC.

5. In a similar fashion create VPC in AWS Ohio region with CIDR 10.1.0.0/16 And create two subnets with CIDR 10.1.0.0/24 and 10.1.1.0/24

Steps to Create VPN connection in AWS Ohio VPC

  1. Create Customer Gateway. Open VPC management console at console.aws.amazon.com. In navigation pane choose Customer Gateway and then create new Customer Gateway. Enter Name, Routing type as Dynamic and EIP of the CSR 1000v instance in N.Viriginia Region VPC. ASN number is 16-bit and must be in the range of 64512 to 65534.
  2. Create VPG and attach to the VPC.In the Navigation Pane choose Virtual Private Gateway and create VPG.
  3.  Now Create VPN connection. In Navigation Pane Choose VPN Connection, Create New VPN Connection. Enter the Name, VPG and Customer Gateway which we have created previously, select routing type as Dynamic and create VPN connection.

It will take few minutes to create VPN connection. When it is ready to download the configuration for Cisco CSR from the drop-down menu.

Steps to establish VPN Connection on CSR 1000v

  1. Add static routes of other subnets in VPC(N.Virginia) to CSR 1000v. Every subnet in AWS has a virtual router with IP address of Subnet CIDR +1. As CSR router will be in Subnet 10.0.0.0/24  the virtual router IP address will be 10.0.0.1. The Virtual Router on each subnet has a route to other all subnets in the VPC.
    >Configure terminal
    #ip route 10.0.1.0 255.255.255.0 10.0.0.1
  2. Configure BGP. Choose the ASN number which you gave while creating Customer Gateway in Ohio VPC. Above we gave 64512
    > Configure terminal
    (config)#router bgp 64512
    (Config-router)# timers bgp keepalive holdtime
    (Config-router)# bgp log-neighbor-changes
    (Config-router)# end

    This step might not be necessary. But as good practice, I have applied the above configuration before copying the configuration file that is downloaded before.

  3. Apply the Configurations that are downloaded previously when VPN Connections Created. After you have applied those setting on CSR you can see on the management console that both the tunnels of VPN as UP.

Testing to check connectivity between two VPC’s

  1. Launch an instance in subnet1 in Ohio region VPC’s with Public IPv4. SSH into the instance and ping the CSR 1000v instance private IP.
  2. Similarly, you can check connectivity with Ohio Region VPC by pinging the instance in subnet1 in Ohio region VPC with its Private IP.

Troubleshooting :

> Route Propagation must be added to the route table in Ohio Region VPC.

> You must configure CSR 1000v as NAT, so the subnets in N.Virginia region can access the hosts in Ohio region VPC via CSR 1000v. You need to Update the route table with target fo CSR 1000v instance-id after making it as NAT.

> Allow ICMP in Security groups on all instances.

Thanks and Regards

Naveen