Short answer: Don't discount the t1.micro - it is a capable instance and can definitely run a PHP site - but if you can't make it work with one t1.micro, then get a larger instance (as opposed to multiple t1.micros).
Long Answer:
The t1.micro instance is quite capable of generating dynamic content - and can run fairly smoothly serving multiple small sites. For a well optimized setup (let's say Wordpress with caching), I would say that the t1.micro should handle at least 50k hits/month, if not more. One of the key ideas though, is that things are well optimized - a default Apache install will bring down a t1.micro fairly fast - since each request spawns a new process - with all the associated overhead.
Additionally, the t1.micro has no swap space by default (it may be helpful to setup a 1GB EBS volume to use as swap space - more as a safety measure than to actually use it. If you find it being used a lot, then something needs to change.
If you are going to run multiple instances, I would advise against going for multiple t1.micro instances. The performance per dollar is far better on the larger instances (memory, i/o, and CPU). One of the other points about the t1.micro is that while you can 'burst' additional CPU, cycles can also be 'stolen'. Definitely go with a 32-bit instance if you are going the t1.micro route - the added overhead of 64-bit registers will simply lead to the instance running out of memory easier, without any tangible performance gain.
If possible, I would recommend use php-fpm instead of mod_php - while slightly slower, it is able to withstand a far higher volume of traffic with less load on the instance. Additionally, if possible, offload the serving of static content. For the latter you could use a CDN such as Cloudfront (or even using S3) - the idea being that these requests don't consume the bandwidth, disk i/o, or processing power (or memory) of the instance. Alternatively, you can use a lightweight front-end server (e.g. nginx) to handle static content and then proxy dynamic requests back to apache (if you can't switch entirely to using that front-end server) - this does add complexity to the setup - but especially if your pages are cached (i.e. static versions generated whenever the page changes) the performance gain can be substantial. It may also be advisable to cache dynamic content with a front-end server (the duration will depend on the site's popularity) - to avoid unnecessary processing of dynamic requests.
One final suggestion - which may not be possible - consider using Amazon's Linux as your operating system instead of Ubuntu. I have found it to be extremely lightweight and efficient on a t1.micro - it comes with the minimum of installed packages and has a very small footprint.
Running a dyanmic website on a t1.micro is certainly possible to do - I have run several small sites (Wordpress/Drupal/Joomla) on a single t1.micro - both using nginx/apache/php-fcgi and varnish/nginx/php-fpm - including a mail server (postfix), imap (dovecot), database (mysql), and ftp server (pure-ftp/vsftp) - with decent performance (Wordpress sites load in a 1-2s), low load averages (typically under 0.1, on a request every 15s), and about 150-200MB of used memory). It wouldn't be my choice for performance, but it is the least costly solution for a site that simply needs to reliably be online, without expecting much traffic.
I would say that the t1.micro makes a very good platform to work on your optimization skills - it lets you see how much you can get out of the bare minimum, and what optimizations will be more costly than they are worth. If however, your site is simply too large for a single t1.micro, use a larger instance not additional t1.micro instances (unless your specific purpose is fail over - but chances are at that stage you will be using larger instances anyway.). Do not load balance t1.micro instances - there is very little to gain from that approach - a larger instance will serve you better. However, you definitely want to find out why those instances are dying - I would wager it is a memory issue, over a CPU one. You definitely want to try to launch a copy of your site, and run ab (or seige, etc) on it and see what the server can stand - and whether or not it the design of the application (which you probably can't change) or the setup of the server.
(Unless you are using spot instances, you can upgrade the instance type fairly easily - just stop (not terminate), and use ec2-modify-instance-attribute to change the type, before restarting).
