Amazon Aurora is now generally available in three AWS regions after a lengthy beta-testing period, but without certain features that are available for regular MySQL databases on the Relational Database Service.

Two features Amazon discussed last year at its re:Invent conference, automated cross-region replication through the AWS Relational Database Service (RDS) console, and integration with the AWS Key Management System, are not supported with Aurora yet, according to Amazon's documentation.

Instead, Aurora on RDS supports up to 15 read replicas across availability zones within the same region for redundancy, and users must maintain a separate MySQL database instance outside of RDS to achieve cross-region replication. This is despite the fact that Amazon has offered cross-region replication through RDS for regular MySQL databases since 2013. Amazon Aurora database clusters and any RDS-based MySQL database instances must be in the same region to replicate.

Aurora is also the only database in RDS that does not yet support encryption at rest or the AWS Key Management System.

Still, AWS users are eager to try Aurora.

"It would be nice to have the Key Management Service integrated as tightly as it is with the other RDS solutions, but it's not a deal breaker for us right now," said Charles Sullivan, director of technical operations for Full Contact Inc., a content management software maker in Denver who was part of the nine-month beta testing process for Amazon Aurora.

For Full Contact, Aurora's support for multiple read replicas presented to the database master as one virtual storage volume solved MySQL performance problems that required sharding the database across eight different servers on-premises.

"There are going to be significant cost savings for us …. We will be removing eight servers from our fleet, consolidating down to a single database server," Sullivan said. "And it's going to reduce complexity for our application greatly because instead of having to implement sharding logic so we know what servers to target for queries, we'll just have a single endpoint that they hit and not have to think about that."

For some AWS customers, the nine-month beta period was too long to base projects on Amazon Aurora. Amazon beta periods vary, but the public beta process for Aurora passed by the delivery date of early 2015 estimated at last year's re:Invent.

At Robert Half International, a staffing firm based in Menlo Park, Calif., there was a project that intended to test out Aurora, but the IT team waited for Aurora's general availability. Since the general availability date was unknown, the company selected Oracle's database instead. The Oracle database on RDS offers cross-region replication through Oracle GoldenGate, as well as encryption at rest.

"At this point, I'm not sure we'll switch over to Aurora due to time constraints," said James Fogerson, senior solutions architect for Robert Half. "It was really lack of visibility into the Aurora release date that caused us to choose Oracle over Aurora."

Amazon Aurora is now generally available in the U.S. East (Northern Virginia), U.S. West (Oregon), and Europe (Ireland) regions, and will expand over time, according to an AWS blog post. Each Amazon Aurora instance can deliver on a performance target of up to 100,000 writes and 500,000 reads per second, Amazon said in the same post.

Database instances in the memory-optimized category are supported for Aurora, ranging from 2 vCPUs and 15.5 GB of memory for $0.29 per hour to 32 vCPUs and 244 GB memory for $4.64 per hour. Users must pay for database instances used for primary servers as well as replicas, plus $0.10 per GB per month for storage, and $0.20 per every million I/O requests the database makes. The database can scale up to 64 terabytes.

Amazon declined to comment for this story.

Beth Pariseau is senior news writer for SearchAWS. Write to her at bpariseau@techtarget.com or follow @PariseauTT on Twitter.