Given the information you've provided above, I'd recommend compartmentalisation or abstraction of services from each other if you are going to keep them on one box. As a sysadmin, I'm loath to recommend relying on a single box for your entire architecture, but if you are not concerned with high availability and you have a suitable backup solution in place for any data that you wish to retain in the case of failure, then go ahead (even if you are distributing your architecture one box per service, you should still be backing up your data and configs!)
If however you are willing to spread your services over multiple EC2 instances - which will aid with scalability later - remember to use DNS names or EC2 elastic IP addresses, as the internal IP addresses of the boxes can change. Because traffic between the internal IP addresses is cheaper though, you might want to investigate using these and dynamic DNS if you are going to have a lot of inter-component traffic.
Remember too that if you will need to scale beyond a single instance per service at some stage, your design should take into consideration the possible future use of AWS' Elastic Load Balancers and Auto Scaling.
If you need your CEO to be able to spin up a new stack quickly in case of issues, I'd recommend investigating AWS' Cloud Formation service. This allows you to use JSON configuration files to define a stack comprised of multiple AWS resources, and launch and terminate your service with minimal interaction.