Another trick is to use ECR. You can transfer 5TB out to the internet each month for free. The container image must be public, but you can encrypt the contents. Useful when storing media archives in Glacier.
Slashing data transfer costs in AWS
51–60 of 268 posts
Re: Slashing data transfer costs in AWS
#52Earlier quoted context omitted.
> A lot of org move to cloud based hosting because it enable them to go way further in FinOps / cost control I think a lot of orgs move to cloud simply because it's popular and gartner told them so. But taking a step away from that, it's really about self-service. When the alternative is logging a ticket for someone to manually misconfigure a VM and then fail to send you the login credentials, then your delivery is s…
> I think a lot of orgs move to cloud simply because it's popular and gartner told them so. Nah, I think it's mostly about the second part of your comment. Everyone hates waiting for months to get a VM or a database or a firewall rule because the infrastructure/DBA teams are stuck ten years in the past and take pride in their artisanal infrastructure building. So moving to the cloud eliminates a useless layer of time…
If only that were the case.
Even when everything is in IaC and 100% cloud-native, I’ve still seen dev teams bypass the approved methods because ClickOps is easier.
Re: Slashing data transfer costs in AWS
#53An alternative to sophisticated cloud cost minimization systems is…….. don’t use the cloud. Host it yourself. Or use Cloudflare which has 0 cents per gigabyte egress fees. Or just rent cloud servers from one of the many much cheaper VPS hosting services and don’t use all the expensive and complex cloud services all designed to lock you in and drain cash from your at 9 or 12 or 17 cents per gigabyte. Seriously, if you…
> Host it yourself. If you're actually using the features of cloud - i.e. managed services - then this involves building out an IT department with skills that many companies just don't have. And the cost of that will easily negate or exceed any savings, in many cases. That's a big reason that the choice of cloud became such a no brainer for companies.
Next you’ll tell me that full-stack is a lie, and devs don’t actually know how to run a DB.
Re: Slashing data transfer costs in AWS
#54[deleted]
Re: Slashing data transfer costs in AWS
#55I'll share my trick :) Lightsail instances can be used to "proxy" data from other AWS resources (eg EC2 instances or S3 buckets). Each Lightsail instance has a certain amount of data transfer included in it's price ($3.5 instance has 1TB, $5 instance has 2TB, $10 instance has 3TB, $20 instance has 4TB, $40 instance has 5TB). The best value (dollar per transferred data) is the $10 instance, which gives you 3TB of traf…
Nice!
Nitpick: $5 for 2TB is better than $10 for 3TB.
Re: Slashing data transfer costs in AWS
#56I reduced them to 0 by not using AWS. This simple trick lets you install and configure dedicated servers that work just fine. Most of your auto scaling needs can be solved using a CDN. But by the time you reach such needs you'd have hired competent engineers to properly architect things - it will be cheaper than using amazon anyway.
Re: Slashing data transfer costs in AWS
#57Earlier quoted context omitted.
> I think a lot of orgs move to cloud simply because it's popular and gartner told them so. Nah, I think it's mostly about the second part of your comment. Everyone hates waiting for months to get a VM or a database or a firewall rule because the infrastructure/DBA teams are stuck ten years in the past and take pride in their artisanal infrastructure building. So moving to the cloud eliminates a useless layer of time…
It also allows management to hide bad decisions and poor planning. Project is a dud? just nuke the cloud project and no more charges for it. Project is poorly architected and running like a dog? throw more resources at it. Both of the above are harder to hide when you have to order equipment for on prem.
If you're running an internal cloud, you can likely absorb that.
I think comes down to a couple of things:
- Small orgs don't have the resources to run internal clouds, nor should they be doing so. This limits the pipeline of available candidates. - Large orgs promote the wrong people to management, and they make decisions based on their mental model of the world that was developed 20 years ago. They're filled with people who don't understand the difference between cloud and virtualization. - Large consultancies make more money by throwing raw numbers at the problem rather than smart automation. i.e. it's easier for IBM to bill T&M and a whole project wrapper to patch the server than automate it. - Finance & HR teams want you to bend to their ways of working rather than the opposite.
Of the rest, you get into many of them are simply in ops because they're less skilled software developers, or they're now being asked to assure security, and that scares them so they try to lock everything down.
Re: Slashing data transfer costs in AWS
#58This is a loophole. Hitting some loss leader at AWS, but if everyone only buys the $1 hotdog and nothing else then the $1 hotdog gets removed.
It’s not a loss leader. Cloud bandwidth pricing is almost pure profit.
It's absolutely amazing that so many devs don't realise this. They seem to think that bandwidth should cost a few cents a month, when in reality it is virtually free. Perhaps the 7c/GB charge was reasonable when AWS came out 15 years ago, but networking has got orders of magnitude cheaper and faster in the intervening time period.
What's more odd now that 1gigabit+ home connections are available, it should be obvious to anyone doing the math that it can't cost that much, otherwise a 200GB CoD install would be costing the ISP $20.
Re: Slashing data transfer costs in AWS
#59S3 is a nice trick. More tricks: 1. Ask for discounts if you are a big AWS customer (e.g., spend $1mln+/year). At some point, they were huge for inter-AZ transfers. 2. Put things in one AZ. Running DB in "b" zone and your only server in "a" is even worse than just standardizing on one zone. 3. When using multiple AZ do load aware AZ balancing.
> Running DB in "b" zone and your only server in "a" There must be use cases for this, but I lack imagination. Cost? But not cost?
Defaults. Either as a code or using click ops.
Many companies run servers without considering AZ. Then you can get the "best" of the worlds:
1. Your service is down if either of AZs gets hiccups.
2. You pay network charges and latency cost.
Re: Slashing data transfer costs in AWS
#60S3 is a nice trick. More tricks: 1. Ask for discounts if you are a big AWS customer (e.g., spend $1mln+/year). At some point, they were huge for inter-AZ transfers. 2. Put things in one AZ. Running DB in "b" zone and your only server in "a" is even worse than just standardizing on one zone. 3. When using multiple AZ do load aware AZ balancing.
> Running DB in "b" zone and your only server in "a" There must be use cases for this, but I lack imagination. Cost? But not cost?
Cost, unlimited cost- but no cost.