There are two aspects to your question:
- How do you keep data/files in sync across multiple instances
- How do you bring up new nodes that follow the same 'rules'.
Syncing:
Installing a Wordpress plugin makes changes to the files and database. Therefore, to mimic the changes across all your servers, you will need to modify both the files and databases of each instance. The specific implementation will be dependent on whether all your instances are identical (i.e. all run both a web server and database server) or if you run your web servers and database servers on different instances.
There is likely a good argument to be made for running one instance with your web server (and then autoscaling that instance) and another instance with your database server (e.g. http://www.mysqlperformanceblog.com/2006/10/16/should-mysql-and-web-server-share-the-same-box/ ). Of course, as soon as you autoscale databases, you run into the issue of keeping the data consistent across all instances.
Syncing Files:
The simplest solution to synchronizing the data is to use rsync. You can have it run periodically (via cron), or can trigger it using incron, which will allow it to run when the contents of directories change. Another option lsyncd which uses inotify to monitor changes to a directory and trigger rsync.
Another approach to file synchronization is to use network/distributed/cluster file systems. For instance, you can use Gluster to keep replicated (multiple copies) and/or distributed (spread out).
You will also probably want to share your PHP sessions between your nodes.
Syncing Databases:
Arguably, keeping the files in sync is the easy part. Keeping databases in sync is more of a challenge. When used with a varying number of nodes, the difficulty increases.
- The simplest solution is to just have your databases on a separate instance.
- Replication is the common solution - but maintaining a master node when you are not certain which instance will be terminated is a problem. If you are using a configuration framework, you may have an easier time controlling this. Using something such as 'pacemaker' (from Linux-HA) may also help on this front. Or just keep the master node out of the auto-scaling group (but that would make it a single point of failure).
- MySQL cluster has some promise, but I don't know if WordPress will run on NDBCluster (it also requires a management node).
- There are some claims of MySQL running on a shared file system (specifically Gluster) - it may work, but I wouldn't put a lot of faith in it.
I would recommend using a separate MySQL instance, and one of the rsync based scripts (probably lsyncd) to keep the files in sync. Autoscale your web servers, and it will probably be a while before you need to worry about the database server. If you autoscale the database, keep the master node out of the group, and scale the slaves.
Deployment:
On this front, you may want slight differences in each node (e.g. one a master, one a slave, etc). Frameworks (as mentioned in voretaq7's answer) would be the way to go here. In many ways, the better your implementation, the less need you have for auto-scaling though. One setup might include Corosync and Pacemaker to monitor the state of each node and the services running on it - to choose a master node, and then to run a script to scale your cluster as needed.
Best Answer
I would say there are two approaches:
Use the AWS API to determine the IP of all group members and then do SSH. -- This itself is possible on different levels, ranging from a shell script using aws-cli (describe-auto-scaling-instances and describe-instances) to a more sophisticated setup e.g. with Python boto and Fabric.
Have all instances register themselves in some orchestration or cluster management tool, e.g. serf or MCollective, and then use that channel to send commands to all group members.
Possibly third approach: do not explicitly run shell scripts at all, but have all instances get their setup from a Puppet or Chef server.