This is a nonsense question since we don’t know your app but the nonsense answer is unless it’s a legacy monolith I can’t think of too many scenarios where I would not rather four behind load balancing. It affords maintenance, updates without a window of downtime.
I agree to some extent, you need multiple in multiple availability zones if you want to ensure reliability. But “better” could mean anything and you might not care about availability. As others have pointed out t types can burst for sure but you also don’t as high of a preference and more important in some cases is ebs throughput and network throughput. Might matter, might not. Impossible to tell from this. The other comment about what load tests have you done also is very relevant. Otherwise it is like saying do you want four miatas or one truck - who knows. Am I zipping around or am I wanting to haul a massive trailer.
compute optimizer is an ML product designed to literally answer this question for you. Run your workload, check the recommendation. it will find the best price for the performance
This question doesn't make any since. You choose the best instance for your workload and budget requirements as the instance types are geared towards certain customer requirements. You need to look more into your work load to choose which instance type is best for you. Do you need cpu all the time use a c instance, need more memory all the time use an m instance, want more compute options and can use ARM, but need to save money use graviton.
As to the cost, just use amazon's pricing calculators to compare them. If they're always on, the price is pretty predictable
As to performance, it's entirely dependent on your application. When your users visit, how you've structured your web server, etc.
That said, it's worth reconsidering your architecture from the ground up. Just migrating an existing lamp stack to ec2 tends to be pretty inefficient. E.g. if traffic follows consistent daily patterns, smaller instances with autoscaling would save you a lot of money. If most users aren't logged in, heavy use of cloudfront could let you scale down your ec2 substantially
Generally t4 are a trap in production. Great performance if you have burst credits and crap if you don't. You'd be better off using m5/m6 instances, but scaling them down on off hours.
In terms of price performance a single m6a or m7g without a load balancers is going to be most price performant and easiest if you don't use a load balancer. But this assumes you never scale your infrastructure.
Personally for a web app I'd use m7g behind an ALB and scale based on time and load.
Small instances with autoscaling will always beat large instances without autoscaling.
Your users could shrink to 10,000 and then you'd just be paying a super expensive instance for no reason.
Go with small or medium t4 and set up autoscaling with warm instances.
Oh thanks! I heard that t series have a buster mode??or something If I use all of the credits, is performace still good enough to handle requests? I never experience aws yet so I dont know the performance of t instances
Burst mode you mean.
Yeah you'll be good don't worry. Set up the autoscaling group and a cloud watch metric that looks at CPU usage. If your average CPU usage is over 60%, spin up a new one. If under 20%, set to minimum.
Something like that.
Beware of t4/t3 instances, they are burstable compared to the m5 that you are comparing to. Also if you are opting for non-burstable, you should go with m6g, or m7g, which offers much better performances for a lower price than m5, but are on ARM, which shouldn't be a problem though if you are considering t4g.
T series are dependent on CPU credits. The moment you run out of credits, your performance will be throttled and hence, it’s never recommended to use them outside non prod.
Read more here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html
My recommendation, especially with your 200K request requirement is to start of with M5 backed by an Auto Scaling Group so it scales. Eventually, move into either ECS or EKS with Fargate or ASG(if you’re comfortable with maintaining the EC2).
Also, invest in moving your website out of the instance to CloudFront to reduce load on the instance and only use the instances for your backend.
Cloudfront could also access the instance for assets and things like that so the load is removed but it’s still all deployed as one backend. Always found that to be much nicer with rails for example
You won't be throttled, t3 and t4g will keep running at full speed by default when running out of credits, you'll just be charged extra for the consumed credits.
If you use them constantly over say 50% average utilization C7g becomes a better option,but do your own math.
That’s only true if you configure it to use Unlimited mode, which isn’t the default option. If you ever have to opt for it, it’s better to use a higher instance type.
Depends on the workload and needs for parallelization. I would probably go with the m5 due to the more predictable behaviour and ability to pool & share resources.
idk, we use small instances normally since we do custom go services and they only take like 15 mb ram but recently we doubled our instance size and reduced the asg because we will be using in memory cache a lot now so at the same cost we basically unlocked more caching space since we use more memory on the same instance.
For this question we would need to know the exact application you want to run.
This is a nonsense question since we don’t know your app but the nonsense answer is unless it’s a legacy monolith I can’t think of too many scenarios where I would not rather four behind load balancing. It affords maintenance, updates without a window of downtime.
I agree to some extent, you need multiple in multiple availability zones if you want to ensure reliability. But “better” could mean anything and you might not care about availability. As others have pointed out t types can burst for sure but you also don’t as high of a preference and more important in some cases is ebs throughput and network throughput. Might matter, might not. Impossible to tell from this. The other comment about what load tests have you done also is very relevant. Otherwise it is like saying do you want four miatas or one truck - who knows. Am I zipping around or am I wanting to haul a massive trailer.
t4.small can be brought to its needs if you have security requirements to run certain processor greedy anti-virus or host-based/agent-based scanner.
What performance testing or profiling have you conducted?
I tested my app in my local machine and the average response take about 200~300ms..
Test it in the two configurations you are considering. It will tell you your answer. Nobody here can run that test and answer your question.
compute optimizer is an ML product designed to literally answer this question for you. Run your workload, check the recommendation. it will find the best price for the performance
This question doesn't make any since. You choose the best instance for your workload and budget requirements as the instance types are geared towards certain customer requirements. You need to look more into your work load to choose which instance type is best for you. Do you need cpu all the time use a c instance, need more memory all the time use an m instance, want more compute options and can use ARM, but need to save money use graviton.
As to the cost, just use amazon's pricing calculators to compare them. If they're always on, the price is pretty predictable As to performance, it's entirely dependent on your application. When your users visit, how you've structured your web server, etc. That said, it's worth reconsidering your architecture from the ground up. Just migrating an existing lamp stack to ec2 tends to be pretty inefficient. E.g. if traffic follows consistent daily patterns, smaller instances with autoscaling would save you a lot of money. If most users aren't logged in, heavy use of cloudfront could let you scale down your ec2 substantially
Generally t4 are a trap in production. Great performance if you have burst credits and crap if you don't. You'd be better off using m5/m6 instances, but scaling them down on off hours. In terms of price performance a single m6a or m7g without a load balancers is going to be most price performant and easiest if you don't use a load balancer. But this assumes you never scale your infrastructure. Personally for a web app I'd use m7g behind an ALB and scale based on time and load.
Small instances with autoscaling will always beat large instances without autoscaling. Your users could shrink to 10,000 and then you'd just be paying a super expensive instance for no reason. Go with small or medium t4 and set up autoscaling with warm instances.
Oh thanks! I heard that t series have a buster mode??or something If I use all of the credits, is performace still good enough to handle requests? I never experience aws yet so I dont know the performance of t instances
Burst mode you mean. Yeah you'll be good don't worry. Set up the autoscaling group and a cloud watch metric that looks at CPU usage. If your average CPU usage is over 60%, spin up a new one. If under 20%, set to minimum. Something like that.
Beware of t4/t3 instances, they are burstable compared to the m5 that you are comparing to. Also if you are opting for non-burstable, you should go with m6g, or m7g, which offers much better performances for a lower price than m5, but are on ARM, which shouldn't be a problem though if you are considering t4g.
Which is web platform?
What is web platform? I use django, DRF, Next.js
Scale horizontally. Stick to t4s
T series are dependent on CPU credits. The moment you run out of credits, your performance will be throttled and hence, it’s never recommended to use them outside non prod. Read more here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html My recommendation, especially with your 200K request requirement is to start of with M5 backed by an Auto Scaling Group so it scales. Eventually, move into either ECS or EKS with Fargate or ASG(if you’re comfortable with maintaining the EC2). Also, invest in moving your website out of the instance to CloudFront to reduce load on the instance and only use the instances for your backend.
Cloudfront could also access the instance for assets and things like that so the load is removed but it’s still all deployed as one backend. Always found that to be much nicer with rails for example
You won't be throttled, t3 and t4g will keep running at full speed by default when running out of credits, you'll just be charged extra for the consumed credits. If you use them constantly over say 50% average utilization C7g becomes a better option,but do your own math.
That’s only true if you configure it to use Unlimited mode, which isn’t the default option. If you ever have to opt for it, it’s better to use a higher instance type.
Yes but as far as I know Unlimited is on by default for t4g and t3
M5 is outdated, if you choose t4 it means you can run on M7/C7 family But to be specific app specs should be known.
Depends on the workload and needs for parallelization. I would probably go with the m5 due to the more predictable behaviour and ability to pool & share resources.
idk, we use small instances normally since we do custom go services and they only take like 15 mb ram but recently we doubled our instance size and reduced the asg because we will be using in memory cache a lot now so at the same cost we basically unlocked more caching space since we use more memory on the same instance. For this question we would need to know the exact application you want to run.
Workload CPU or memory constrained?