Amazon Web Services does a good job of thinking through data security, both within Amazon Simple Storage Service...
and the databases they provide as a service. This includes access and encryption services that are native to Amazon Web Services, and the service itself.
Amazon Web Services (AWS) approaches security as something systemic. While there are certainly sub-systems around each service, the architecture and security services are designed to work together. However, it also requires that those who implement security in AWS understand both the architecture and the mechanisms.
Starting at the storage level, Simple Storage Service (S3) provides encryption services for both data in flight and data at rest. When the data is in flight, you can leverage Amazon Secure Socket Layer (SSL) or use client-side encryption. Those of us who have created distributed Internet connected systems should already be familiar with this approach. However, some enterprises don't leverage SSL for regulatory or policy reasons. For those enterprises, other encryption standards should be considered.
As for data at rest, options include service-side encryption and client-side encryption. When leveraging server-side encryption, users request that S3 encrypt the object before it's persisted to storage. The object is decrypted once users download the objects for use in applications. Client-side encryption allows users to encrypt data on the client side and upload the encrypted data to S3.
Of course, access management to secure data is required as well, for both simple storage and more sophisticated database services. For this scenario, look to AWS Identity and Access Management (IAM), a full-blown identity management system and form of security in AWS that allows users to control access to AWS services, including database services such as Amazon Relational Database Service and DynamoDB.
IAM allows users to create and manage specific AWS users and groups by assigning permissions to allow and restrict access to data. IAM provides the ability to manage who can access what, and in what context.
The use of identity-based security is much more flexible. It's systemic to the entire AWS cloud, and can integrate with existing enterprise on-premises security. In many instances, the data and other resources are actually more secure in AWS because many enterprises don't support systemic and distributed access management.
To create a strategy that works, first consider the requirements in detail. Include compliance issues that are necessary to address, especially if users are in the healthcare or finance vertical. Second, the security design should span all employed AWS systems. If possible, include existing enterprise systems as well. Security is most valuable when it's systemic. Finally, plan testing to validate that the security solutions do their job. Users will quickly discover the issues, and can then take steps to correct them.