Why is Azure SQL database so expensive? - sql

For a small personal coding project I recently created a SQL database in Azure. For the past weeks I have been hardly using the database, out of 2 GB available space I have been using only 13 MB.
However, the database costs me 6,70 EUR per day and I don't understand why this is the case. Read a few topics/posts stating that the costs with similar use should be around 5-7 EUR per month, not per day.
This is the configuration for the database:
No elastic pool
General purpose, Gen5, 2 vCores
West Europe
Does anyone have an idea about what could be causing the costs per month to be so high?

You choosed the General purpose, Gen5, 2 vCores price tier. Here is the cost every month:
This means that you must pay for it no matter how many space you used. As you said you just used only 13M. So you must change the Pricing tier.
What I suggest you is configure you database price to Bacic which only cost you 4.99 USD per month. Basic price tier provides 5 DTUs and Max size 2GB for you.
You can change the price tier on the database overview site:
Hope this helps.

You're paying for the entire infrastructure is why. It really only saves on upfront cost. A dedicated server, Windows Server + SQL Server Web will run you, at least $5K. Performance wise, a dedicated server at a colo center will be a lot cheaper to run once you get the hardware. I know, I've switched several companies off of Azure and, instead of paying $2500/mo, they pay $200/mo (after the server) for 4U at a colo + $100/mo basic maintenance and 1TB/mo bandwidth, so it adds up. For example, I built 2 custom 1U servers (12 core/32GB) for $8500 and an opensource router for another $500 (pfSense), including OSes & SQL Server Web. Initial setup of both servers including SQL and the router for 16 IP Addresses was about $1K. Total cost was $10K up front. The equivalent horsepower and storage from Azure was $2500/mo. In 1 year on Azure it ran $30K! 1 year on colo (hosting + maintenance) was $13600, the following year was $3600. So far in 5 years, they saved ~$122,000. There was only 15mins of downtime during the entire period. Cloud hosting is a great idea, but it will never save you time nor money at the rates these company's charge. As far as downtime, I have been hosting for 2 decades and the worst downtime happened due to a network failure (that also took out multiple cloud providers) and it was 13 hours. The only other one was due to a fried router (about 3 hours). Just my take on it - Cloud hosting is still way too expensive for what you actually get & redundancy is nice but you can buy a new server every 2 months for the price difference (just get good equipment w/redundant power supplies and hot swap drives - in a 55 degree colo center, failures are rare)

It seems you don't know Azure offers a free tier. Please refer to this StackOverflow thread for details on how to take advantage of the free tier that supports databases of 32 MB of space.

If it is a small project you can run it on Ubuntu Linux and it's $3.80/month or $0.0052/hour.
On top of this, you can install MySql or SQL Express. I personally find MySql easier to access/configure

It's sure that Azure offers a free tier but still you can optimize it with very low cost if you use any purchased plan.
Here I provided some direction on the picture below that how to create free App Service Plan
Now let's see how we can optimize the cost for small database size for your purchased plan.
Go to the option of Create SQL Database
Click on the link Configure Database as per the below picture
Then Select the Basic option under DTU-Based as per the below picture
As the above picture shows, the default selected option is General Purpose option under VCore-Based section, so it costs $410 as it provides you 32 GB database.
As Basic option is selected, so DB Size is changed into 2 GB instead of 32 GB, hence cost is changed into just $5.64 instead of $410

Related

How to minimize the cost for a sql database

I have a website that need a database to store some user information and a blob storage to save some files.
I want to minimize the cost as much as possible so I played around in Microsoft Azure Pricing Calculator with a Azure SQL Database. For the database I think that over it's hole lifetime 2GB of storage would be enought.
I arrived to 2 options that where dirt cheap but I don't really understand what it gives me.
First is with a serverles computer for 3600 seconds (of runtime?)
Is that time the time that my database is processing the request? For example if I have a select statement that takes 1 sec to complete I'll be left with 3599 sec for that month?
If that's the case what happens if I run out of time?
Second option is using a Hardware Type: Gen 4
but for this one I don't have any other options to configure my needs. Is this obsolete? Can I rely on it for production?
If you need a very cheap one use the Basic or S0.
Keep in mind that Basic are very slow: try to connect to it through SSMS.
Serverless is for databases that you pause for 3/4 of the day. It might be the case for you but keep in mind that when you use them they will cost a lot. I don't think this will be suitable for you.

Is it normal to lose 30 minutes of data on a SQL Server crash?

We have worked with Oracle for a number of years and we now need to develop a new application using SQL Server in AWS for the first time.
What surprised us, is that the new SQL Server DBA told us off the bat that SQL Server uses some kind of replication every 30 minutes (or with 30 minutes delay, I don't remember): in short, he said that on an AWS SQL Server crash, when the secondary server comes up "we will lose only 30 minutes of data in Production".
EDIT: By "crash", we mean the primary server is dead/unrecoverable.
We never expected this as a normal behavior and we haven't seen something like this in Oracle... ever.
Is it normal to expect to lose 30 minutes of commits on a SQL Server crash? This would include payments, invoices, and other transactions that we would consider quite important.
Should I push back about this, or this is considered normal in SQL Server?
Yes, if that's you pay for or have setup.
For Oracle, I'm pretty sure that that you did not ask. Clients always assume RTO and RPO are 0. When you explain what RTO and RPO, they request 0 for RTO and PRO. Then when you explain the complexity and cost, the client is likely okay okay with 24 hours while we do our best for our default 15 minutes. Take a look at
https://www.brentozar.com/archive/2017/10/sql-server-architecture-review/
I love Brent's response for one of the questions:
"For Infrastructure-as-a-Service, there are no changes. For Platform-as-a-Service, thereโ€™s no chart โ€“ just put in your credit card and turn the knob to the level of protection that you want. ๐Ÿ˜€"
So, what's in your wallet? ๐Ÿ˜€
Here is one definition of RTO and RPO, from the AWS Well-Architected documentation:
Recovery Time Objective (RTO) is ...the maximum acceptable delay between the interruption of service and restoration of service. This determines what is considered an acceptable time window when service is unavailable.
Recovery Point Objective (RPO) is ... the maximum acceptable amount of time since the last data recovery point. This determines what is considered an acceptable loss of data between the last recovery point and the interruption of service.
The architecture or features determine what RPO and RTO are possible. For a platform as a service, you do not define the implementation. If you pay for near zero RTO and RPO, then I'd expect something more than a single instance for HA and backup/restore for DR.
The following link might help explain some of this. It's a complex subject. The complexity can be a risk for RTO and RPO. For example, our first SQL cluster did not failover correctly because some resources where not configured correctly as cluster resources...we lost a 9 for that. I like this link because of the image that shows the feature relation to RTO and RPO - copied here.
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/an-overview-of-high-availability-and-disaster-recovery-solutions/ba-p/370479
The following link indicates the Azure instance or database has a 12h and 1h RTO and RPO, respectively, using geo restore. You can use auto failover to improve this to 1h and 5s. It's all very vendor specific.
https://learn.microsoft.com/en-us/azure/azure-sql/database/business-continuity-high-availability-disaster-recover-hadr-overview?view=azuresql
This link shows that paying more allows the use of features and resources that provide a better RTO and RPO. I would expect "Hyperscale service tier zone redundant availability" to drain the wallet.
https://learn.microsoft.com/en-us/azure/azure-sql/database/high-availability-sla?view=azuresql&tabs=azure-powershell
If doing it yourself, the feature selection is not enough. Having an old SAN go down for 3 days (yes) can be a real show stopper, no matter what features are used.

Amazon S3 & EC2 for hosting?

I have a little dot com site, personal portfolio, running HTML w/ CSS right now. I'm thinking of eventually running something like node.js w/ a custom CMS. But I'm paying over $110 a year for hosting when I use about .5 gigs of bandwidth a month & just a few domains I don't need.
Will EC2 with my own Server be cheaper on a micro instance? Not to mention nerdy :-)
It's cheaper but, only by a little (except while your in the 1st year of trial service where some things are totally free). After the first year its $85 for a 3-yr micro instance (or $54 for 1/yr) with the following:
613 MB memory
Up to 2 EC2 Compute Units (for short periodic bursts)
EBS storage only
32-bit or 64-bit platform
I/O Performance: Low
API name: t1.micro
It is indeed cheaper, and if you go small enough it's free for the first year (if you only have one instance).
Getting node.js to run on ec2 is a bit interesting but it can be done (I've done it). Good luck.
Well - micro instance is 2 cents per hour which gives 365*24*0.02 = 173$. Stay with your current hosting if you don't have problem with reliability there.
You can also check price for other cloud providers with cloudorado.com.

Amazon Web Services Apache Server

I am trying to get a feel for the costs imposed by running apache on AWS continually. Assuming that the service is scarcely used, does anyone know how many cpu hours that would eat up in a month just by sitting there and running? I understand that this is slightly impractical but I am trying to figure out what the cost of entry is to deploy an application on this platform (as compared to GAE). I suspect it to be small but I would like to know.
Amazon charges for EC2 instances by uptime, not CPU time. The cheapest Linux instance type costs 8.5c / hour, or about $37 / month. You can reduce this by either signing up for a reserved instance that you plan to run for an extended period, or by using a spot priced instance where you bid the price you're prepared to pay.
You will also incur bandwidth charges for data transfer in and out of the EC2 network, and storage charges if you store any data permanently on AWS. These should be small compared with the cost of running the instance.
You can always have an estimates here:
http://calculator.s3.amazonaws.com/calc5.html

Affordability of Amazon Simple Storage Service (S3)

I have a website that attracts about 30,000 visitors per month. It has a lot of photos and PDF files which eat up a good deal of bandwidth. It's hosted by site5.com, which offers unlimited bandwidth & storage for ~$5 per month. According to site5's statistics, my site has about 20 GB of downloads per day, but I've seen it as high as 116 GB. Uploads range from 5-15 GB daily. (Though, I don't really upload things everyday, so I don't know where they get those numbers from.)
In anticipation of growing my site even more, perhaps by hosting videos, high-res photos, etc., I was looking into other storage options, even though site5 has been pretty good. Specifically, amazon.com's Simple Storage Service (S3) looks pretty good and is supposed to be a "highly scalable, reliable, fast, inexpensive data storage infrastructure."
Using Amazon's Simple Monthly Calculator, I multiplied out my worst-case scenario numbers:
Storage: 2 GB
Data Transfer-in: 15 GB/day * 31 days = 465 GB/month
Data Transfer-out: 116 GB/day * 31 days = 3596 GB/month
With those numbers alone, the calculator estimates my monthly bill to be a whopping $658.27!!! That's insane! Is anyone here using S3? Are your bills outrageous?
Wow, are you sure about those stats? I suppose that's possible, but you're lucky that your host hasn't given you the boot. Leasing a dedicated server will typically get you somewhere in the neighborhood of 1.5TB/month for at least 20 times what you are paying now. If you're doing 3.5TB for $5 per month and your host isn't complaining, don't even think about moving.
(note: most unlimited plans are indeed limited by the company's terms of service, which usually allows them to give anyone the boot for using "too many" resources.)
I would try to find some way to verify your stats before you continue.
$5/3500GB is $0.0014 per gig. That's insane.
3.6TB/month is kind of a lot. Just as a sanity-check, my internet connection seems to deliver somewhere around 100kB/sec reception if I'm lucky (I assume the send/receive rat are about the same). At that bandwidth limit it would take my computer 417 days sending continuously to deliver that amount of data.
10c per gigabyte seems pretty reasonable to me. NearlyFreeSpeech.net charges $1/gigabyte delivered but that decreases to 20c/gigabyte at high volumes. Mosso charges 22c/GB delivered.
If you are paying $5 for unlimited transfer and storage I would stick with your current provider as they are offering something that no-one else is going to be able to offer you for that price.
S3 is also a content distribution network, it has certain uptime guarantees, data storage guarantees, your host probably does not. When Amazon says they can deliver your 116 GB a day they really mean it, whereas your host is probably overselling their capacity and hoping people don't really use their unlimited transfer.
You are getting a steal in terms of what you use. Good luck finding that elsewhere.