Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 52 discussion

EFS is a standard file system, it scales automatically and is highly available.

I have absolutely no idea... Output files that vary in size from tens of gigabytes to hundreds of terabytes Simit size for a single object: S3 5To TiB https://aws.amazon.com/fr/blogs/aws/amazon-s3-object-size-limit/ EBS 64 Tib https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_constraints.html EFS 47.9 TiB https://docs.aws.amazon.com/efs/latest/ug/limits.html

Keyword Must store in standard file system -> ignore A Minimum operational -> ignore B Scalable + Terabytes-> pick C

Ans C - S3 unlimited storage in both scope and size of individual objects

C : EFS as It is built to scale on demand to petabytes without disrupting applications, growing and shrinking automatically as you add and remove files. Multiple compute instances, including Amazon EC2, Amazon ECS, and AWS Lambda, can access an Amazon EFS file system at the same time, providing a common data source for workloads.

Key words: Standard File System and Scales Automatically. S3 is object Store, hence if fails with the "Standard File System" requirement, so we can discard A. EBS does not scale automatically, failing with the "Scales Automatically" requirement, so we can discard B and D

C is the only option which supports standard file system when we talk about high availability. EBS scope is within a availability zone but EFS has scope of a region.

Standard file system that is highly available: EFS Autoscaling highly available system: EC2 or ECS or EKS can work A: Not suitable due to S3 which is BLOB not file system B: EKS is ok but EBS is not HA D: EBS is not HA So by elimination, C is best option.

"File system structure" = EFS, which also meets all the other requirements.

Technically the A could work, ECS is often recommended by AWS in case of minimum operational overhead, and S3 is durable and highly scalable BUT it is not a "traditional" file system structure. In an S3 bucket, there is no real file structure, only files and prefixes that simulate a structure. B is wrong because of EKS which require more management EFS is recommended for minimum operational overhead instead of EBS. So C (EC2 + EFS) is recommended here over D (EC2 + EBS).

Palabras clave: autoescalado y ficheros

The key is Multi-AZ ,EBS does not support it.

Standard file system structure, scales automatically, requires minimum operational overhead = Amazon Elastic File System (Amazon EFS)

Option C is the correct answer

EFS provides a scalable and fully managed file system that can be easily mounted to multiple EC2. It allows you to store and access files using the standard file system structure, which aligns with the company's requirement for a standard file system. EFS automatically scales with the size of your data. A suggests using ECS for container orchestration and S3 for storage. ECS doesn't offer a native file system storage solution. S3 is an object storage service and may not be the most suitable option for a standard file system structure. B suggests using EKS for container orchestration and EBS for storage. Similar to A, EBS is block storage and not optimized for file system access. While EKS can manage containers, it doesn't specifically address the file storage requirements. D suggests using EC2 with EBS for storage. While EBS can provide block storage for EC2, it doesn't inherently offer a scalable file system solution like EFS. You would need to manage and provision EBS volumes manually, which may introduce operational overhead.

Option C meets the requirements.

Keywords: file system structure, scales automatically, highly available, and minimal operational overhead