Unless your friend's website serves hundreds of millions of static files a month, it's impossible to pay $hundreds to host a static site on AWS with S3 and CloudFront. Just look at the pricing and do the math: how many static HTTP requests does he have to serve to even get to $100?
1 Million HTTP requests on CloudFront costs $0.75.
Consider 25 Kb per request, on average, and you'll pay extra $2,12 for bandwidth
If you store this data in S3 and use CloudFront cache wisely, you'll pay very little to S3 Get requests. Even without using cache at all (which is absurd):
You'd pay only $0.40 for 1 Million S3 Get requests.
A little over $3 for 1 Million requests per month.
And that's for you to have:
Robustness: one of the greatest cloud infrastructures on Earth
Peace of mind: everything managed by one of the best DevOps teams money can buy
I did not say he hosted a static site making simple http requests, I said he made several bad architectural design decisions. This is the only real point of reference I have, so I was asking if any one else had similar experiences.
That explains, than. EC2 should be used for dynamic processing. Static data should be in S3 and CloudFront, ideally. Even for dynamic needs, I'd recommend using Lambda, if technically possible.
As the math shows, it's darn cheap for small and mid-sized needs. If you ever get to hundreds of millions or billions of requests/month (or really large files), than it's worth looking at cheaper alternatives to AWS.
True. On average, though, website static files are updated infrequently. You might have one or another file updated more regularly, but the overall update rate will be very low in comparison to the total number of files stored.
And if you are indeed updating some things very frequently, depending on what it is (e.g. a JSON string), it might be worth considering a more dynamic storage solution.
The equivalent to an S3 PUT operation is 4x cheaper on DynamoDB (Write op), for instance. "S3 GET" operation is 1.6x more expensive than a DynamoDB Read op. And that is for Dynamo On-demand. If you have a somewhat stable and predictable demand, Provisioned Throughput would be even cheaper. That is considering a small object with <4kb in size for Reads and <1kb for writes.
You seem pretty knowledgeable on AWS. I’m thinking about the following... I plan to setup a Gatsby site. I plan to use GitHub actions to push to S3 on commit to master. Adding cloud front to CDN it. Then I will write either a Rust or Node comments system and put it on EC2 so when a person comments that will push a commit to GitHub to be merged later by me and redeploy that commit to S3. I know this may sound like a bit of effort but the goal for me is to learn Rust, Gatsby and AWS. I also may use serverless for the comments system. I know I could just use Lightsail but I already have a fully managed hosting solution that I could use. It’s more about having fun! Does this sound like a decent/correct approach in your opinion? I haven’t done any kind of DevOps for about 15 years, I only decided yesterday that I will learn some AWS. Thanks!
As a project for learning, it seems very interesting. For production workloads, this doesn't seem like an efficient architecture.
Personally, I tend to stay away from EC2 as much as I can. You can probably run 80-90% of workloads on AWS Lambda nowadays. Looking superficially at your idea, I don't see a reason why you couldn't go Serverless. I would also use AWS API Gateway to interface HTTP requests with Lambda. That would be my primary choice.
I don't know if it would be possible, but maybe you can use API Gateway as a proxy to the Github API directly. You can transform incoming requests to match Github specs, and also customize responses to the clients commenting.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Unless your friend's website serves hundreds of millions of static files a month, it's impossible to pay $hundreds to host a static site on AWS with S3 and CloudFront. Just look at the pricing and do the math: how many static HTTP requests does he have to serve to even get to $100?
If you store this data in S3 and use CloudFront cache wisely, you'll pay very little to S3 Get requests. Even without using cache at all (which is absurd):
A little over $3 for 1 Million requests per month.
And that's for you to have:
I did not say he hosted a static site making simple http requests, I said he made several bad architectural design decisions. This is the only real point of reference I have, so I was asking if any one else had similar experiences.
I don't see how one could make such bad architectural decisions in S3 and CloudFront that would make a regular Joe website hosting cost $hundreds.
He's probably using EC2, renting fancy servers with multi-region high availability, load balancer, etc, perhaps?
He was using EC2 and allowing users to upload images and videos, he did zero compression and simply re-served the content full-size images and videos.
That explains, than. EC2 should be used for dynamic processing. Static data should be in S3 and CloudFront, ideally. Even for dynamic needs, I'd recommend using Lambda, if technically possible.
As the math shows, it's darn cheap for small and mid-sized needs. If you ever get to hundreds of millions or billions of requests/month (or really large files), than it's worth looking at cheaper alternatives to AWS.
If you change your Objects in s3 very often/ updating code frequently will costs for CRUD in s3.Considering that makes little bad for me. But its ok.
True. On average, though, website static files are updated infrequently. You might have one or another file updated more regularly, but the overall update rate will be very low in comparison to the total number of files stored.
And if you are indeed updating some things very frequently, depending on what it is (e.g. a JSON string), it might be worth considering a more dynamic storage solution.
The equivalent to an S3 PUT operation is 4x cheaper on DynamoDB (Write op), for instance. "S3 GET" operation is 1.6x more expensive than a DynamoDB Read op. And that is for Dynamo On-demand. If you have a somewhat stable and predictable demand, Provisioned Throughput would be even cheaper. That is considering a small object with <4kb in size for Reads and <1kb for writes.
You seem pretty knowledgeable on AWS. I’m thinking about the following... I plan to setup a Gatsby site. I plan to use GitHub actions to push to S3 on commit to master. Adding cloud front to CDN it. Then I will write either a Rust or Node comments system and put it on EC2 so when a person comments that will push a commit to GitHub to be merged later by me and redeploy that commit to S3. I know this may sound like a bit of effort but the goal for me is to learn Rust, Gatsby and AWS. I also may use serverless for the comments system. I know I could just use Lightsail but I already have a fully managed hosting solution that I could use. It’s more about having fun! Does this sound like a decent/correct approach in your opinion? I haven’t done any kind of DevOps for about 15 years, I only decided yesterday that I will learn some AWS. Thanks!
As a project for learning, it seems very interesting. For production workloads, this doesn't seem like an efficient architecture.
Personally, I tend to stay away from EC2 as much as I can. You can probably run 80-90% of workloads on AWS Lambda nowadays. Looking superficially at your idea, I don't see a reason why you couldn't go Serverless. I would also use AWS API Gateway to interface HTTP requests with Lambda. That would be my primary choice.
I don't know if it would be possible, but maybe you can use API Gateway as a proxy to the Github API directly. You can transform incoming requests to match Github specs, and also customize responses to the clients commenting.