You should probably consider using RDS for your database rather than implementing on EC2 unless you have a very unique database that requires a high degree of customization (i.e. clustered configurations, etc.). Running on EBS-backed volume (which you would need to do to be able to persist the physical data files), will subject you to slow disk I/O. If you are not running on EBS-backed EC2, then your data is transient and can not be considered as being on reliable physical storage. If this is OK for your design (you just need transient info in your database), then you would probably be even better served but just putting your information into Elasticache or some form of in-memory cache.
RDS uses MySQL (well, you can also opt to use Oracle). You would access it EXACTLY like you would access your own MySQL server (same PHP abstraction, same SQL, same almost everything (you don't get root access, but rather a form of super-user access). RDS also provide you easy to implement (i.e. push button) configuration for multi-az (high-availability, synchronously-updated standby), replication slaves, DB instance re-sizing, and data snapshots.
In either case (for RDS or EC2), you would need to make sure that your EC2 or RDS security groups allows access from the EC2 instances (or other servers) that host your application. In case of EC2 only you could either place the servers in the same security group, and provide port 3306 access on that group, or better would be to create two security groups (one for app and one for db). In the db security group provide port 3306 (or whatever port you are using) to the security group(s) to which the app server(s) belong.
For an RDS, you would need EC2 security group for app server(s) and a DB security group for the RDS instance). You would need to provide access to the app server security group in the RDS security config.