3 ms·
You'll probably have no issue sending the image to you backend directly, doing whatever you want to it (compression, validation, etc), and then uploading it to
by jjice 2y ago
You'll probably have no issue sending the image to you backend directly, doing whatever you want to it (compression, validation, etc), and then uploading it to S3 from there. It's not a lot of overhead (and I'd argue more testable and easy to run locally).
You can do the math on the ingress to your service (let's say it's EC2), and then the upload from EC2 to S3.
It appears that AWS doesn't charge for ingress [0]. "There is no charge for inbound data transfer across all services in all Regions".
S3 is half a cent per 1000 PUT requests [1], but you were already going to pay that anyway. Storage costs would also be paid anyway with a presigned URL.
You'll have more overhead on your server, but how often do people upload files? It'll depend on your application. Generally, I'd lean towards sending it to your backend until it becomes an issue, but I doubt it ever will. Having the ability to run all the post processing you want and validate it is a big win. It's also just so much easier to test when everything is right there in your application.
[0] https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/ https://aws.amazon.com/blogs/architecture/overview-of-data-t...
[1] https://aws.amazon.com/s3/pricing/ https://aws.amazon.com/s3/pricing/
- JimDabell 2y agoAside from the extra load (and long requests, which is a bigger factor for non-async app servers), you need to take into account the physical location of your app servers. Depending on where the user is, there can be drastic differences in performance uploading to, say, us-east-1 vs ap-southeast-1. With S3, you can enable transfer acceleration so that the user uploads to whichever is their nearest region and then AWS handles it from there. This can give huge speedups.