大多数的现代化应用都依赖于DB层来对数据进行集成、查询和管理。在AWS上部署一个数据库需要相应的监控和管理功能，使应用更容易纵向扩展，从而降低宕机影响并保持较低的成本。
AWS在改善其核心数据库和自动化管理以及监控等相关功能上做了很多工作。与此同时，AWS的竞争对手也在改善它们自身的管理功能。企业在选型的时候需要更仔细，以便权衡AWS以及其他第三方数据库服务商。
理解系统需求
在软件开发团队的工作启动之前，对应用需求有一个深刻的理解是非常关键的。一般来说，在此之前进行架构变动是相对容易的。虽然要预估一个系统的规模并非易事，但是要对所要求的一致性进行评估并不困难。
例如，Netflix用AWS存储了Apache Cassandra 数据库中的大量数据。在这个大型系统中，对于Netflix来说，其在线可用性要比精确记录所观看过电影的存储位置更加重要。
企业需要考虑是否要将可用性和可扩展性纳入最重要的考量范畴。很多企业在进行过可用性优化的NoSQL平台上部署应用，而这需要调整以保证一致性。对于此类应用更好的一个方法是使用类似PostgreSQL的传统关系型数据库，它可以更有效地提供所需的一致性。
相反，很多企业错误的地使用基于事务的关系型数据库来提供一致性，但并不具备高可用性——例如一个推荐系统应用。在这些案例中，企业可能从一开始就应避免使用类似Cassandra的数据库。
本地化
另一个***实践就是考虑利用本地AWS服务替代传统数据库架构。当开发人员将应用程序从传统环境迁移至AWS时，建立数据库服务器和集群是很常见的。
AmazonRDS提供的功能可以将数据库作为一个托管服务来使用，它可以很好的支持MySQL、PostgreSQL、Oracle以及SQL Server。 这是因为RDS包含大量的监控和管理功能来支持诸如升级，打补丁以及故障检测等内容。 但是，这并没有免除所有DBA的责任。企业仍需要配置备份，决定数据库的需求并指定诸如内存和存储等事务。
AWS包含大量的数据库服务，这些服务内置有类似SimpleDB和DynamoDB的管理和监控功能。这些服务是以扩展的方式加以提供，这样就相对简单并且可以减少对专门服务的需求。但是其他的NoSQL数据库倾向于为很多用例提供更为丰富的功能集，这也是它们快速成长并广受欢迎的原因。
随着AWS不断完善其基础功能，这种情况可能会有所改变。例如，AWS刚刚在DynamoDB上添加了对JSON数据模型的支持，这对于MongoDB这类产品来说一直是一个非常重要的优势。但在目前阶段，根据文档的大小，对文本搜索功能和地理空间功能的支持上，与第三方产品相比，AWS服务有着更多严格的限制。
平衡可扩展性和功能
诸如MongoDB之类的NoSQL数据库的主要挑战是在提供新实例，更新软件以及进行扩展方面所面临的困难。例如，一般来说，要配置一个运行在12台服务器之上的MongoDB集群需要操作150多个步骤。而最近添加进MongoDB MMS的自动化功能可以将此手动工作大为简化。有了MMS，你就不需要了解其内部实现，而且工作效率也会大为提高。
Decisive是一家提供互联网广告管理服务的公司，他们的系统运行在AWS上。对于一个用于创建和优化移动广告活动的新API来说，Decisive可以利用MMS来简化对新增MongoDB实例的自动部署和扩展。Decisive之所以选择MongoDB是因为其数据模型的灵活性。MongoDB可以收集某个活动相关的各种数据，例如观看广告以及进行点击的用户数量和类型。
虽然AWS在数据库上层提供了一些基本的监控和管理功能，但是这对于很多需求来说还不够。MMS可以让Decisive监测客户端的磁盘I/O流量以及延迟。MMS还可以协助访问数据库集群的健康状况，这样可以在发生问题的时候更容易找出问题所在。随着读写负载变得更高，MMS会报告它们发生的位置并给出通过扩展系统来应对这些挑战的***途径。
与此同时，类似AWS Redshift服务对于很多数据仓库应用是足够实用的，且提供了很好的性价比。而对于企业分析之类的工作，Redshift表现也是极为出色。你可以在MongoDB上存储事件，在需要的时候可以快速迁移至Redshift。这里你损失的只是一定的灵活性。
