Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 days ago.
Improve this question
We would like the following :
Dev Env will reside on AWS free tier account (both EC2 & RDS )
Once Dev env is ready and QA are finished, we will image this instance and open an additional 1 EC2 reserved instance.
Questions :
Can we benefit / use AWS free tier account for DEV and reserved instance for PROD at the same time, meaning we won't pay for Dev (1yr) and Prod we will pay for the 1 instance reserved price ?
If We would like to use PROD with reserved instance and activate autoscale (using on-demand or additional paid reserved instances) is it possible ?
To be honest I don't think it's worth the hassle as you can spin very cheap instances for development purposes. You can even automatically shut them down after office hours and on weekends when nobody is using them.
To address your questions:
It is possible to share an AMI with another account. See Sharing an AMI with Specific AWS Accounts
So once your instance has been approved on the dev account you can create an image, make it available to your prod account only, without making it public, and launch an instance based on that image.
According to AWS documentation it's possible to use auto-scaling with reserved instance benefits:
You can use Auto Scaling or other AWS services to launch the On-Demand instances that use your Reserved Instance benefits. For information about launching On-Demand instances, see Launch Your Instance.
Source: Reserved Instances
Let's look at each element individually...
Dev Env will reside on AWS free tier account (both EC2 & RDS )
The AWS Free Usage Tier provides free access to specific services within specific limits for the first 12 months of an AWS Account. In the case of Amazon EC2:
750 hours of Amazon EC2 Linux t2.micro instance usage (1 GiB of memory and 32-bit and 64-bit platform support) – enough hours to run continuously each month*
750 hours of Amazon EC2 Microsoft Windows Server t2.micro instance usage (1 GiB of memory and 32-bit and 64-bit platform support) – enough hours to run continuously each month*
A t2.micro instance in the USA is 1.3c per hour. So, the benefit gained from one instance (eg Linux) in the free tier is worth $113 (0.013*24*365).
For Amazon RDS, the value is approximately $150 (depending upon the chosen database):
750 hours of Amazon RDS Single-AZ db.t2.micro Instances,for running MySQL, PostgreSQL, MariaDB, Oracle BYOL or SQL Server (running SQL Server Express Edition) – enough hours to run a DB Instance continuously each month*
So, you really need to ask yourself whether doing strange things is really worth saving $263, given that it will be limiting you to micro-sized EC2 and RDS instances. A few hours of your time is presumably worth more than this, so it would be better for you to create infrastructure that is needed to successfully deliver your system rather than trying to focus on how to avoid spending money.
As an example, it is possible that these instance types might be too small for your development work and you will spend more time trying to get it to work (or waiting for it if it is slow), rather than productively spending your time on delivering a successful project.
Once Dev env is ready and QA are finished, we will image this instance and open an additional 1 EC2 reserved instance.
Reserved Instances are a great way to reduce your Amazon EC2 costs. However, you do not want to lock yourself into a particular instance type which might later prove inappropriate. For example, you might purchase a Reserved Instance for a medium instance, but later find that you actually need a large instance. This would mean your Reserved Instance is wasted.
It is much better to run your system for 2-3 months to understand your usage patterns before committing yourself to a Reserved Instance.
If We would like to use PROD with reserved instance and activate autoscale (using on-demand or additional paid reserved instances) is it possible ?
You can certainly use Auto Scaling to add additional instances. These additional instances would be charged at on-demand rates. If you purchase additional Reserved Instances, then you should run those instances all the time since you are already paying for them. There would be no benefit in reducing your number of instances to below the number of Reserved Instances you have purchased.
Bottom line: The cost of a couple of Amazon EC2 instances is not very high. Spend your time producing a great app rather than focussing on how you can reduce your expenditure by a couple of hundred dollars.
Related
Our organization has many EC2 on-demand instances. We never looked at the reserved instance pricing because we thought we had to pay up-front. But I see that now there are reserved instance with no up-front costs, but monthly.
This looks like what we need to keep costs down, but I am unclear as to how the reserved instance pricing is applied.
For example, we have 10 t3.medium ec2 instance. Let's say that there are 6 always running 24/7, but the other 4 are not running 24/7, they are turned off when not in use.
If I buy a reserved instance for t3.medium, how does AWS know to apply it to the instances running 24/7 and not part time?
For example, we have 10 t3.medium ec2 instance. Let's say that there
are 6 always running 24/7, but the other 4 are not running 24/7, they
are turned off when not in use.
If I buy a reserved instance for t3.medium, how does AWS know to apply
it to the instances running 24/7 and not part time?
Amazon doesn't apply reserved pricing to a specific instance at all. It basically just applies reserved pricing to your bill. It's like a discount at the time your bill is processed. If you have reserved pricing for N instances, and you have at least N instances running 24/7 reflected in your bill, then the reserved pricing gets applied to those N instances.
Amazon doesn't really care if you are running a single specific instance 24/7, or deleting and recreating instances once a minute. In the end it's just the total number of seconds you have a specific type of instance running each month that they care about, and bill you for.
Be aware that when you setup instance reservations it is actually a capacity reservation. You are telling Amazon you are committing to running this type of instance 24/7 for either 1 year or 3 years. By letting Amazon know this, it helps with their capacity planning, and in return they give you a cost discount. But it also means that they are going to charge you for that reserved capacity even if you don't actually have that instance running 24/7.
I'm getting ready to launch a mobile app that I have hosted on AWS with an EC2 instance. ($0.0464 per On Demand Linux t2.medium Instance Hour).
This past month I was charged $112 for the EC2 usage, but only had a handful of internal users testing the private version of the app. It's a fairly simple app, not anything that should require a lot of computing power.
So what I'm wondering is if 10 users and dev team costs $112/mo, what happens if I get 1,000 users, or 10k users? Would the cost increase 100x, 1000x? I can't imagine getting auto-billed for $112,000 for a month of service with a small user base like 10k users.
Thanks for any help and guidance, I don't know much about AWS.
Here are the details of my billing for last month:
The billing page shows 2219 hours of t2.medium during this billing month.
That is the equivalent of 92 days. So, it might be 3 instances running for a full month.
Amazon EC2 is charged when the instance is in the Running state. If you are not using an instance, you can Stop the instance. The attached disks (EBS) will still be charged, but there will be no charge for the instance itself.
The charge is not based on the number of users, nor how 'busy' the instance is. It is simply charged when the instance is 'running'. This is because computer resources are exclusively assigned to instances (CPU, RAM) that nobody else can use.
Bottom line: Stop instances that you don't need. Use the smallest instance type for your use-case to reduce costs.
If you were not aware of the charges involved, you can contact AWS Customer Service and request a refund.
FYI, the T2 and T3 family are great for workloads that occasionally 'burst' but then have low-usage periods, but they are not great for sustained workloads. See: Burstable performance instances - Amazon Elastic Compute Cloud
I am new to AWS so please bear with me as my question might not make sense. BUT I had one ec2 instance running a single flask web application for about 3 months and my bills were in the $0-$0.50 range. However, I started to experiment with docker images, and such, I had these docker images running in their own containers on a separate ec2 instance. So for the month of April, I got charged $35 instead of the usual $0.50, so after a call with AWS they said my ec2 instances went over the limit of 750 hrs of time. So my thought process is I have only one ec2 instance running which in turn has multiple docker containers running serving different applications, could this help keep my costs from ballooning? Or would each docker container count towards the 750 hrs of montly time?
If my question did not make sense, please ask questions to my question :P
Hello Abhishek Hotti,
I can understand your frustation, I came on AWS while ago by experimenting like you and I can tell you I was billed my first month with more than 300€ due my "missunderstanding" of the AWS services and the Freetier layer.
I can tell you now, that Amazon ECS uses mainly two different approaches to launch containers:
EC2 Launch Type: which lets you choose your EC2 instances as the computational node.
Fargate Launch Type: which is fully managed by AWS. Your containers run without you managing and configuring individual Amazon EC2 instances. That means that despite you doesn't see the EC2 instances they are in the background and you are billed for that.
AWS Source documentation
The issue here seems to be that you are using two EC2 instances.
According to the free tier layer in AWS:
750 hours per month of Linux, RHEL, or SLES t2.micro or t3.micro
instance dependent on region
Making a fast calculation: each month are 24h * 30 days = 720h. Gf you are using two instances that will be = 1440 hours. That is above of the free tier layer and you are billed in consequence.
If you will be using the Fargate launch type option your bills will contain the use of the Fargate infrastructure that will be located in the background.
I hope this helps
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
AWS provides services like Elasticache, redis, databases and all are charged on hourly basis. But these services are also available in form of docker containers in docker hub. All the AWS services liste above use an instance. Meaning, an independent instance for databases and all. But what if one starts using an ec2 instance, and start downloading all the images for all the dependancies on databases. That would save them a lot of money right?
I have used docker before and it has almost all the images for the services aws provides.
EC2 is not free. You can run, for example, MySQL on an EC2 instance. It will be cheaper than using RDS, but you still need to pay for the compute and storage resources it consumes. Even if you run a database on a larger shared EC2 instance you need to account for its storage and CPU cycles, and you might need more or larger instances to run more tasks there.
(As of right now, in the us-east-1 region, a MySQL db.m5.large instance is US$0.171 per hour or US$895 per year paid up front, plus US$0.115 per GB of capacity per month; the same m5.large EC2 instance is US$0.096 per hour or US$501 per year, and storage is US$0.10 per GB per month. [Assuming 1-year, all-up-front, non-convertible reserved instances.])
There are good reasons to run databases not-in-Docker. Particularly in a microservice environment, application Docker containers are stateless, replicated, update their images routinely, can be freely deleted, and can be moved across hosts (by deleting and recreating them somewhere else). (In Kubernetes/EKS, look at how a Deployment object works.) None of these are true of databases, which are all about keeping state, cannot be deleted, cannot be moved (the data has to come with), and must be backed up.
RDS has some useful features. You can change the size of your database instance with some downtime, but no data loss. AWS will keep managed snapshots for you, and it's straightforward (if slow) to create a new database from a snapshot of your existing database. Patch updates to the database are automatically applied for you. You can pay Amazon for these features, in effect, or pay your own DBA to do the same tasks for a database running on an EC2 instance.
None of this is to say you have to use RDS, you do in fact save on AWS by running the same software on EC2, and it may or may not be in Docker. RDS is a reasonable choice in an otherwise all-Docker world though. The same basic tradeoffs apply to other services like Elasticache (for Redis).
We are running 6 Java Spring Boot based microservice projects in one AWS t2.large(2 CPU & 8GB RAM) EC2 machine. When we see the CPU and RAM utilization of this EC2 machine, CPU is underutilized, hardly hits 1% but the RAM usage is always above 85%.
Now we want to add 2 more microservice. We definitely can't deploy these 2 services in the EC2 which we already have as the RAM will be exhausted. So, we need to add one more EC2 machine or we need to upgrade t2.large to t2.xlarge(4 CPU & 16GB RAM) to deploy the 2 new services but we also want to be cost-effective.
We are studying some of the AWS articles and it says that running ECS services will be cost-effective as the billing is based on how much CPU and RAM is being used(reference - ECS Fargate Pricing). As our CPU is always underutilized, we are thinking that ECS Fargate pricing policy will reduce our cost.
So, 3 questions with respect to cost saving for the above case,
If we prefer ECS, will that be really cost-effective than adding one more EC2 instance as ECS pricing is based on how much resources are utilized?
If we need to deploy 8 projects in ECS, will that create 8 EC2 instances or we can still use 1 or 2 EC2 machines for all 8 projects deployment?
Should we completely re-think about our deployment process in a different way?
If we prefer ECS, will that be really cost-effective than adding one more EC2 instance as ECS pricing is based on how much resources are utilized?
This is worded a little awkward, but I think what you're asking is will Fargate be more cost effective than standard EC2 instances. That, I think, is pretty difficult for us to determine for you, though you should be able to do some quick estimations based on your real-world usage and compare that with the cost of the smallest necessary instance type.
To throw another option in the mix, consider Reserved Instances, as they come at a pretty steep discount if you're willing to reserve them for some period of time. From the linked doc, you'd be looking at somewhere around a 40% discount (compared to on-demand) for a 1 year reservation, and 60% for a 3 year reservation.
Additionally, consider different instance types, specifically the memory optimized instances r4 and x1. These let you purchase more memory and less cpu.
If we need to deploy 8 projects in ECS, will that create 8 EC2 instances or we can still use 1 or 2 EC2 machines for all 8 projects deployment
Assuming you're not referring to Fargate here, the answer is ... it depends; it depends on how you design your system. You can host as many containers on an instance as you want (assuming you have the resources) -- but whether or not that's what you want from a high-availability / disaster scenario is for you to decide.
Should we completely re-think about our deployment process in a different way?
This will be answered when you come to a conclusion on your first question.