CloudWatch custom metric examples

Creating custom metric requires some custom coding or scripting using the AWS Command Line Interface or SDK.   As the name implies these metric are custom so some custom coding / scripting is required to be done.  Here are some places to start that will provide examples of creating custom metric:
CloudWatch custom metric for MySQL using PHP:
http://aws.typepad.com/aws/2011/05/how-to-use-the-new-cloudwatch-user-defined-metrics-feature-with-php-1.html

Linux script sample custom CloudWatch metric for memory, disk space, and swap space:
http://aws.amazon.com/code/8720044071969977

More examples using the CloudWatch Command Interface to create custom metric:
http://blogs.clogeny.com/custom-metrics-in-amazon-cloudwatch/

Sample code for instance memory reporting:
#!/bin/bash export AWS_CLOUDWATCH_HOME=/home/ec2-user/CloudWatch-1.0.12.1 export AWS_CREDENTIAL_FILE=$AWS_CLOUDWATCH_HOME/credentials export AWS_CLOUDWATCH_URL=https://monitoring.amazonaws.com export PATH=$AWS_CLOUDWATCH_HOME/bin:$PATH export JAVA_HOME=/usr/lib/jvm/jre # get ec2 instance id instanceid=`wget -q -O - http://169.254.169.254/latest/meta-data/instance-id` memtotal=`free -m | grep 'Mem' | tr -s ' ' | cut -d ' ' -f 2` memfree=`free -m | grep 'buffers/cache' | tr -s ' ' | cut -d ' ' -f 4` let "memused=100-memfree*100/memtotal" mon-put-data --metric-name "FreeMemoryMBytes" --namespace "System/Linux" --dimensions "InstanceId=$instanceid" --value "$memfree" --unit "Megabytes" mon-put-data --metric-name "UsedMemoryPercent" --namespace "System/Linux" --dimensions "InstanceId=$instanceid" --value "$memused" --unit "Percent"

Migrating enterprise applications to AWS

There are many infrastructure artifacts that need to be addressed when migrating enterprise workloads to AWS: compute, storage, database, security, load balancers, firewalls, data encryption, management, monitoring, patching, anti-virus, and intrusion detection to name a few.  There are also development artifacts that need to be addressed: packaging, testing, deployment, versioning, and upgrades to name a few. These on premise constructs need to the mapped to the same, equivalent, or new constructs on AWS.  

There are also a number of migration approaches that can be employed: lift and shift, leverage and extend, or re-engineering.  The approach taken depends upon the application attributes - Oracle and SAP Commercial Off-The-Shelf (COTS), Microsoft and other 3RD party packaged applications, or custom systems.   There are strength and weaknesses of each approach.

AWS offerings services that are not readily accessible in your on premise environment.  There are services, including CloudFront and Auto Scaling, that can be used to increase performance and reduce cost without changing a line of application code.

In future blogs, I will began to identify and address the mappings, approaches, and services that can be used to migrate enterprise workloads to AWS.