Which AWS storage and database architecture meets the requirements of the application?
Web servers: store read-only data in S3, and copy from S3 to root volume at boot time. App servers: share state using a combination of DynamoDB and IP unicast. Database: use RDS with multi-AZ deployment and one or more read replicas. Backup: web servers, app servers, and database backed up weekly to Glacier using snapshots.
Web servers: store read-only data in an EC2 NFS server; mount to each web server at boot time. App servers: share state using a combination of DynamoDB and IP multicast. Database: use RDS with multi-AZ deployment and one or more Read Replicas. Backup: web and app servers backed up weekly via AMIs, database backed up via DB snapshots.
Web servers: store read-only data in S3, and copy from S3 to root volume at boot time. App servers: share state using a combination of DynamoDB and IP unicast. Database: use RDS with multi-AZ deployment and one or more Read Replicas. Backup: web and app servers backed up weekly via AMIs, database backed up via DB snapshots.
Web servers: store read-only data in S3, and copy from S3 to root volume at boot time. App servers: share state using a combination of DynamoDB and IP unicast. Database: use RDS with multi-AZ deployment. Backup: web and app servers backed up weekly via AMIs, database backed up via DB snapshots.
Explanations:
While S3 is a suitable option for storing read-only data, copying from S3 to the root volume at boot time introduces complexity and potential delays. IP unicast for session state is acceptable, but the backup method to Glacier is not ideal as it does not facilitate quick recovery for web and app servers.
Using an EC2 NFS server introduces a single point of failure and does not leverage AWS’s scalable storage options. IP multicast for session state is not supported in AWS. The backup strategy lacks efficiency as AMIs can be time-consuming to restore compared to other methods.
This option effectively uses S3 for read-only data storage, which is scalable and efficient. Using DynamoDB with IP unicast for shared session state is a viable solution. RDS with multi-AZ and read replicas provides high availability and scalability. The backup strategy with AMIs and DB snapshots ensures robust recovery.
This option omits the use of read replicas in the database tier, which is critical for scaling. While S3 is used appropriately for read-only data and the backup strategy is solid, the lack of read replicas limits the overall architecture’s scalability and performance.
I figure that the answer is:
Web servers: store read-only data in S3, and copy from S3 to root volume at boot time. App servers: share state using a combination of DynamoDB and IP unicast. Database: use RDS with multi-AZ deployment and one or more Read Replicas. Backup: web and app servers backed up weekly via AMIs, database backed up via DB snapshots.