Step 1: Launching an Amazon ElastiCache Cluster
Just go to AWS console, select an Amazon EC2 region and launch a cache cluster. By default if the Amazon EC2 region is not chosen US-EAST will be used. Provide the following details like:
Name: This is the Cache Identifier name and should be unique for an Amazon EC2 region(per account).
Node Type: Cache Capacity type with Memory and CPU. If you want 20 GB of distributed Cache you can choose either 3 Cache.M1.Large or 2 Cache.M1.Xlarge Node types. Usually users prefer Node types with more memory rather than High CPU node types (Not sure what kind of workload needs cache.c1.Xlarge capacity on memory hungry applications). Recently AWS has introduced Cache.M3.Class Node type which fits Memcached kind of use cases very well. The Node type cannot be modified after creating an Amazon ElastiCache Cluster, so please plan your base capacity in advance with some thought. To know more about ElastiCache deployment strategies refer URL: http://harish11g.blogspot.in/2012/11/amazon-elasticache-memcached-ec2.html
Number of Nodes: Number of Node types you want the Amazon ElastiCache Cluster to launch. There is a limit to Cache nodes you can launch per account. Please increase this limit using ElastiCache Limit Increase Request form.
Engine: Currently only MemCached, I assume AWS Team will adding new cache engines in future.
Version: Memcached 1.4.5
Cache Port: The default port 11211 in which the Amazon ElastiCache node accepts connections.
Preferred Zone: It is the Preferred Amazon EC2 Availability Zone in which you want to launch the Amazon ElastiCache Cluster. It is recommended to keep the Web/App EC2 instances and Amazon ElastiCache nodes on same Availability zone for low latency processing. In case multi-AZ is applicable your architecture, standard Amazon EC2 Regional Data Transfer charges of $0.01 per GB in/out apply when transferring data between an Amazon EC2 instance and an Amazon ElastiCache Node in different Availability Zones of the same Region, you are only charged for the Data Transfer in or out of the Amazon EC2 instance. Also to note, currently Amazon ElastiCache Cluster cannot span across multiple Availability zones inside Amazon EC2 region. To know more about Amazon EC2 regions and Availability zones refer URL: http://harish11g.blogspot.in/2012/07/amazon-availability-zones-aws-az.html
Topic of SNS notification: Lets you specify whether you would like to receive SNS notifications related to your cache nodes/cluster using Amazon Simple Notification Service (SNS) system. You can either select an existing SNS topic or disable notifications completely as well for the entire Amazon ElastiCache Cluster.
Step 2: Additional details during launch
As part of the additional configuration during launch process:
You may need to configure the Cache security group and Parameter group for your Amazon ElastiCache Cluster in this section.
The Cache security group will allow request access between your EC2 instances and ElastiCache Nodes. The Security group of your EC2 instances should be added in this ElastiCache Security group for opening the access. This setting applies to all the existing and new cache nodes inside the Amazon ElastiCache cluster. You can either create a new Amazon ElastiCache Security group or make changes in the default security group as well. In case you have Multitude of cache clusters with variety of EC2 tiers accessing them on various workflows I would strongly recommend creating your own cache security groups as best practice. Currently Amazon ElastiCache cannot be accessed outside Amazon EC2 (It does not make sense unless you have Gigabit NW to make productive use of Cache with low latency). Also in future, we can expect Amazon ElastiCache to work inside Amazon Virtual Private Cloud (VPC) network as well.
Cache Parameter Group: You can either create a new parameter group or use the default memcached parameter group. AWS provided default will suffice for most use cases. The parameters will be applied to all the cache nodes in the Amazon ElastiCache cluster.
Maintenance window: Amazon ElastiCache is a Managed service and AWS team will take care of certain routine management activities without your intervention automatically. Maintenance window is one such period in which AWS team will carry out scheduled maintenance like software patching in this configured time. In case your instances are rebooted after the maintenance window period, the cache node(s) have to be properly warmed. Since Amazon ElastiCache currently relies only on RAM which is ephemeral in nature, such cold state is unavoidable. If you have multiple Redundant ElastiCache clusters in Multi-AZ you can rotate the maintenance window to your advantage and keep the cache entries warm in your cache nodes. Refer URL: http://harish11g.blogspot.in/2012/11/amazon-elasticache-memcached-ec2.html to know more about this technique.
Step 3: Review and Launch
Review your configuration and proceed to launch. In case any of the details configured need to be modified you can always go back from this screen. Usually a launch of 5 X cache.m1.large nodes in US-East will take around ~320 seconds. This may vary time to time depending upon the cache node type, number of cache nodes and Amazon EC2 regions in consideration.
Exploring Amazon EC2 Availability Zones
Part 1: Understanding Amazon ElastiCache Internals : Connection overhead
Part 2: Understanding Amazon ElastiCache Internals : Elasticity Implication and Solutions
Part 3: Understanding Amazon ElastiCache Internals : Auto Discovery
Part 4: Understanding Amazon ElastiCache Internals : Economics of Choosing Cache Node Type
Launching Amazon ElastiCache in 3 Easy Steps
Caching architectures using Memcached & Amazon ElastiCache
Web Session Synchronization patterns in AWS