Which architecture change could you introduce to reduce costs and still keep your web application secure and scalable?
Replace the Auto Scaling launch configuration to include c3.8xlarge instances; those instances can potentially yield a network throuthput of 10gbps.
Re-architect your ingest pattern, have the app authenticate against your identity provider, and use your identity provider as a broker fetching temporary AWS credentials from AWS Secure Token Service (GetFederationToken). Securely pass the credentials and S3 endpoint/prefix to your app. Implement client-side logic to directly upload the file to Amazon S3 using the given credentials and S3 prefix.
Re-architect your ingest pattern, and move your web application instances into a VPC public subnet. Attach a public IP address for each EC2 instance (using the Auto Scaling launch configuration settings). Use Amazon Route 53 Round Robin records set and HTTP health check to DNS load balance the app requests; this approach will significantly reduce the cost by bypassing Elastic Load Balancing.
Re-architect your ingest pattern, have the app authenticate against your identity provider, and use your identity provider as a broker fetching temporary AWS credentials from AWS Secure Token Service (GetFederationToken). Securely pass the credentials and S3 endpoint/prefix to your app. Implement client-side logic that used the S3 multipart upload API to directly upload the file to Amazon S3 using the given credentials and S3 prefix.
Explanations:
While using larger EC2 instances like c3.8xlarge can increase network throughput, it does not address the rising costs effectively. Larger instances typically have higher costs, and simply scaling up the instance size may lead to inefficient resource usage and doesn’t optimize the architecture for handling uploads directly to S3.
This option suggests authenticating against an identity provider and using it to fetch AWS credentials, which is a step in the right direction. However, it does not implement direct uploads to S3. This means the application would still need to handle uploads through the EC2 instances, which can lead to higher costs and increased complexity.
Moving the application into a public subnet and using Route 53 for DNS load balancing could reduce some costs related to Elastic Load Balancing. However, this approach does not scale efficiently, as it still relies on EC2 instances to handle uploads, which could lead to higher operational costs as the traffic increases. Furthermore, exposing instances directly to the internet raises security concerns.
This option proposes a complete re-architecture by allowing the application to authenticate against an identity provider, fetch temporary AWS credentials, and implement direct uploads to S3 using the multipart upload API. This reduces load on EC2 instances, minimizes the need for expensive instance types, and leverages S3’s scalability and cost-effectiveness. Direct uploads also enhance user experience by allowing resumable uploads without relying on the server.
I classify that the answer is:
Re-architect your ingest pattern, have the app authenticate against your identity provider, and use your identity provider as a broker fetching temporary AWS credentials from AWS Secure Token Service (GetFederationToken). Securely pass the credentials and S3 endpoint/prefix to your app. Implement client-side logic that used the S3 multipart upload API to directly upload the file to Amazon S3 using the given credentials and S3 prefix.
If memory serves me right, the answer is:
Re-architect your ingest pattern, have the app authenticate against your identity provider, and use your identity provider as a broker fetching temporary AWS credentials from AWS Secure Token Service (GetFederationToken). Securely pass the credentials and S3 endpoint/prefix to your app. Implement client-side logic that used the S3 multipart upload API to directly upload the file to Amazon S3 using the given credentials and S3 prefix.