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

Use EC2 with Amazon EFS to meet the application's need for a shared, scalable, POSIX-compliant, highly available file system with minimal operational management.

C: The only option with file system

HOW EFS is suitable here as it has a maximum file size limit of 52 TiB, so it cannot store a single file that exceeds this size. But in question it has mentioned that output files may vary in size from tens of gigabytes to hundreds of terabytes. Isn't it contradictory?

The question is not clear. None of the options suit the 100s of TB requirements. EFS max file size is clearly specified as 49.5TB. But lets assume for a minute that the app is capable of multipart files, then EFS would be a great fit. (requirement: Must be a file system)

EFS is the only file system structure here so it it most suitable.

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.