I am having a query related to pricing for Azure File Service that how pricing happens like as per usage of GB data of file or will it be based on available size for file share like 5TB per share.
I am referring this link http://azure.microsoft.com/en-us/pricing/details/storage/ but this is not giving me the exact pricing.
My Scenario is like let’s say:-
1) for two months I would require 4GB file data on File Share and then for another 4 month I would require 5GB of file data so how the costing will happen?
2) Would I require two VMs for this to maintain the availability and how the costing will happen for two VMs usage?
Kindly help me on this.
The price is per GB used.
Regarding your questions:
The share has a maximum if 5TB size, but you are only billed for what you actually use, not the maximum size. In your example, you will be billed for 4GB for the first 2 months, and 5GB for the next 4.
You do not require any VMs to maintain availability of the shares themselves - Azure Storage offers SLA on the share uptime. Of course, if you have an app that is running in a VM, and you need uptime guaranteed for the app, you have to look at how many VMs you need, but that is one level above storage - and those needs are not based on storage uptime considerations.
Related
Backdrop
I develop a forecasting engine (time series) for different purposes. Processing, modeling and forecasting modules are written in Python, and data is currently stored in an Azure SQL database. Currently the database is General Purpose (vCore-based) service tier, Provisioned compute tier and Gen5 (12 vCores) hw config. I'm approaching the limit of maximum storage (approx 3 TB), but since I read almost the entire database daily (cold start models only), I do not see many other options than increasing the storage size. Truncating parts of historical data is out of the question.
Problem
At 12 vCores, maximum storage is approx 3 TB, and increasing vCores to enable the approx 4 TB maximum storage size is not feasible in a $-perspective (especially since it is storage, not compute, that is the bottleneck). I have read a bit about the alternative services / tiers on the Azure platform, and see that Hyperscale could possibly solve my problem: I can keep vCores untouched and have up to 100 TB storage. A config with zero secondary replicas (other things equal) will end up in the same $-range as before (see "Backdrop"). I get the impression that secondary replicas (read only nodes) are central to the Hyperscale architecture, so I'm not sure if such an outlined setup with zero secondary replicas is abuse / misuse. E.g. would it give the same performance, or could I expect a performance hit (even with the same vCore config)? Will the primary read / write node basically resemble a non-Hyperscale node? Other aspects I should think about? Adding a secondary replica (or several) might be relevant in the future (e.g. in combination with decreasing vCores), but is $-wise not an option atm.
Microsoft states that "The capability to change from Hyperscale to another service tier is not supported" (really?), so I would like clarify this to avoid doing a semi manual data migration (and delta migration) and having two instances side-by-side if the shait hits the fan. Given the scope of such a reconfig and the forecasting system as a whole, I feel it is not feasible to do small / full scale testing in advance to get representtive benchmarks. If there is anything else I should think about (related or semi related), feel free to point me in the right direction.
Since Hyperscale service tier is the newly added service tier in Azure SQL Database, it would be difficult to get the solid answer for your question.
It's true that it provides upto 100 TB database size, but the beauty is it will only charge for the capacity you use.
The Hyperscale service tier removes many of the practical limits
traditionally seen in cloud databases. Where most other databases are
limited by the resources available in a single node, databases in the
Hyperscale service tier have no such limits. With its flexible storage
architecture, storage grows as needed. In fact, Hyperscale databases
aren't created with a defined max size. A Hyperscale database grows as
needed - and you're billed only for the capacity you use. For
read-intensive workloads, the Hyperscale service tier provides rapid
scale-out by provisioning additional replicas as needed for offloading
read workloads.
You can have primary and secondary replica in Hyperscale service tier.
Primary replica serves read and write operations
Secondary replica provides read scale-out, high availability, and geo-replication
Secondary replicas are always read-only, and can be of three different types:
High Availability replica (recommended)
Named replica (in Preview, no guaranteed SLA)
Geo-replica (in Preview, no guaranteed SLA)
You should consider Hyperscale service tier because:
you need more size than 4 TB
require fast vertical and horizontal compute scaling, high performance, instant backup, and fast database restore
Note: Users may adjust the total number of high-availability replicas from 0-4, depending on the need.
You can check the Hyperscale pricing model here.
Considering above points, Hyperscale is the good, if not the best, solution for your requirement.
These two links will definitely help you to take your decision. Hyperscale service tier, Hyperscale secondary replicas
I'm one of the PM on the Azure SQL DB team. I see that UtkarshPal-MT already gave you extensive answer, so I'm chimining in on to complete the picture. Azure SQL DB Hyperscale offers different type of secondary replicas. The replicas that can help to get an higher SLA are named High-Availability replica. You can use 0 replicas without any issue. What will happen is that if the primary replicas for any reason is not available, we need to spin up a new (compute) replica from scratch (as there are no HA replica available) so that can take some time (minutes, usually) which means that your service will not be available that amount time. Having an HA replica, drastically diminish the time in which the database is not available.
You can read all the details here:
https://learn.microsoft.com/en-us/azure/azure-sql/database/service-tier-hyperscale-replicas?tabs=tsql
The SLA are defined here:
https://www.azure.cn/en-us/support/sla/sql-data/
Regarding the performances: unless you are specifically using secondary replicas also to offload read-only workload, you'll not have performance hit by not having an HA replica
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
I am thinking to store some of the data of my services in an Azure blob storage. I really require the retention of data for 15 days and I would access it rarely one file in a day. I may get max 5 MB of data per day to store.
I am not sure which Access tier (Hot, cold, Archive) could be a better option in pricing wise. I am not clear after reading the doc. Does any one give some pointers. Thanks.
I really require the retention of data for 15 days and I would access it rarely one file in a day.
Azure storage offers three storage tiers for Blob object storage so that you can store your data most cost-effectively depending on how you use it.
The Azure hot storage tier is optimized for storing data that is accessed frequently.
The Azure cool storage tier is optimized for storing data that is infrequently accessed and stored for at least 30 days.
The Azure archive storage tier is optimized for storing data that is rarely accessed and stored for at least 180 days with flexible latency requirements (on the order of hours). The archive storage tier is only available at the blob level and not at the storage account level.
So according to your demand, I suggest that you could choose cool Acces tier.
For more details, you could refer to this article.
I've spent a number of days looking into putting up two Windows Servers on Amazon, a domain controller and a remote desktop services server but there are a few questions that I can't find detailed or any answers for:
1) When you have an EBS backed instance I assume this means that all files (OS/Applications/Pagefile) etc are all stored on EBS? Physically in the datacentre, lets assume I have 50 gig of OS files/application data etc, are these all stored on just one SAN type device? What happens if that device blows up or say that particular data centre gets destroyed. Is the data elsewhere? What is the probability that your entire EBS volume can just disappear?
2) As I understand it you can backup your EBS instance to S3 with snapshotting. I assume you can choose how often to snapshot (say daily?). In my above scenario if I have 50 gig of files, and snapshot once a day. Over 7 days will my S3 storage be 350 gig or will it be 50 gig + incremental changes I have made over the week?
3) I remember reading somewhere that the instance has to go offline to snapshot. If that is the case does it do this by shutting down the guest OS, snapshotting then booting up or does it just detach the data, prevent you from connecting while it snapshots, then bring it back to the exact moment before it went for a snapshot.
4) I understand the concept of paying per month per gig of space but how I am concerned about the $0.11 per 1 million I/O requests. How does that work when I am running a windows server? I have no idea how many I/O requests a server makes to its disks. I am assuming a lot of the entire VM is being stored on an EBS volume. Is running a server on the standard EBS going to slow it down radically?
5) Are people using the snapshot to S3 as their main backup are are people running other types of backup for Data?
Sorry for the noob questions - I'd appreciate any partial answers, answers or advice anyone could offer me. Thanks in advance!
1) amazon is fuzzy on this. They say that data is replicated within the AZ it belongs to and that if you have less than 20GB of data changed since the last snapshot your annual failure rate is ~ 0.1-0.4%
2) snapshots are triggered manually, and are done incrementally
3) Depends on your filesystem. For example on a linux box with an xfs volume you can freeze IO to the volume, do your snapshot (takes only a second or so) and then unfreeze. If you take a snapshot without doing something similar you run the risk of the data being in an inconsistent state. This will depend on your filesystem
4) I run all my instances on EBS. You probably wouldn't want your pagefile on EBS, it would make more sense to use instance storage for that. The amount of IOs you use will be very dependant on the workload. The IO count depends heavily on your workload - an application server does a lot less IOPs than a database server for example. You're unlikely to use more than a few dollars a month per volume if you're running particularly IO heavy operations
5) Personally I don't care about the installed software/configuration (I have AMIs with that all setup so I can restore that in minutes), I only care about the data. I back that data up separately (S3 & Glacier). Partly that's because I was bitten by a bug EBS had about a year ago or so where they lost some snapshots
You also use multiple strategies, as Fantius commented. For example on the mongodb servers I run the boot volume is small (and never snapshotted or backed up since it can be restored automatically from an AMI), with a separate data volume containing the actual mongodb data. The mongodb volume is snapshotted as well as storing dumps on S3. Snapshots are an efficient way of creating backups (since you're only storing incremental changes) however you can't transfer them out of your EC2 region, whereas a tarball on S3 can easily be copied anywhere.
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.