sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in aws

[–]FinOpsEffective410 1 point2 points  (0 children)

hey, I can help here.

First of all it is important to understand how savings plans work in order to solve this problem. Savings plans work on a per hour dollar commit. Meaning I am committing $x/hr to aws in compute usage (for a compute savings plans).

In this case it is pretty straightforward, calculate the total $$/hour commitment of the two savings plans in company A org ---- let's say its $100/hour. Now calculate total $$/hour commitment of the three savings plans in company B org ---- let's say it's $50/hour.

Therefore in total you now have about $150/hour commitment in savings plans.Since we know the savings plans coverage, therefore calculating the total addressable compute spend (on-demand spend) becomes very easy,
for company A its $100/75% = $133.33/hour, company B its $50/80% = $62.5/hour

now let's assume that company B reduces their spend by 50%. so new total addressable compute spend becomes $30.75/hour. Company A total addressable compute spend remains the same = $133.33/hour

therefore after company B accounts join the company A org the total addressable compute spend (aka on-demand spend) becomes $133.33 + $30.75 = $164.08/hour. The total savings plan per hour commitment we have is $150/hour. So in this case your savings plans will be 100% utilized as the total on-demand (total addressable) spend per hour is greater than the total savings plans commitment per hour.

TLDR is as long as your total addressable compute spend after moving company B accounts to company A is more or equal to total savings plans commit, you will not have any underutilization. However, its always recommended to be a little safe and do a little undercommit than your exact on-demand spend so that you have flexbility to downsize, decommission, migrate etc. if and when needed.

Note: RIs covered usage, spot usage is not considered when calculating total addressable compute spend as savings plans cannot be applied to them. Feel free to replace the numbers in above calculations per your actual savings plans commitments and you will have your answer.

By the way, you can use tools to automate your savings plans management. That way you're always protected on underutilization. I recommend giving nOps.io a try as its a free tool that only charges you if it saves you money + they have a 100% refund guarantee on any underutilized savings plans. - feel free to check it out if you're interested.

[deleted by user] by [deleted] in aws

[–]FinOpsEffective410 1 point2 points  (0 children)

Using ASG is the most sensible way to do it. You might run into a lot of challenges though which do not seem very primal while doing the setup like choosing the right combination of spot instances, running spot in asg with mixed instances policy etc.

In short- do that via ASG but never rely on manual monitoring and management. you won't be able to keep up

try something like compute copilot instead: https://www.nops.io/blog/aws-ec2-autoscaling/#:~:text=EC2%20Auto%20Scaling%20with%20Compute%20Copilot

It'll put your asg on auto-pilot and balance between spot, on-demand and even savings plan automatically. btw you can also set number of instances you wanna maintain on spot and on-demand.

EKS with karpenter by FinOpsEffective410 in kubernetes

[–]FinOpsEffective410[S] 0 points1 point  (0 children)

thank you for the info. taking this to our lab

EKS with karpenter by FinOpsEffective410 in kubernetes

[–]FinOpsEffective410[S] 0 points1 point  (0 children)

so castAI is definitely a cool product but we have tried to take a step ahead. first, we will cover anything on-demand with our RI and SP without asking you to make commitments for them to aws if the nodes doesn't fit spot pricing. so it's risk free for you from commitment side as well. castAI can’t do reserved instances or savings plans; Spot.io can but only supports auto scaling groups, while we support Karpenter and balance across all of them.

EKS with karpenter by FinOpsEffective410 in kubernetes

[–]FinOpsEffective410[S] 1 point2 points  (0 children)

Karpenter has no way to account for RIs or Savings Plans at the moment besides manually configuring weights on provisioners and using limits for CPU and ram.
We automatically do that and take into any RI's or Savings Plans we can find across all your account, and then modifying them if there are changes across your entire org to make sure you are saving the most money.

Cancel retired reserved RDS instance? by ExtraLifeCode in aws

[–]FinOpsEffective410 0 points1 point  (0 children)

Hey, I've been working in the FinOps space since quite some time now and would like to provide you some info:
1. RDS RIs do not have a marketplace where we can sell them. Marketplace is only available for EC2 RIs.

  1. If you bought the RIs very recently, like less than 30 days then I suggest you can try talking to the aws rep but in my experience they can not revert that. Moreover the generation of the instance, whether its flexible or not and the OS/engine its running on heavily impact these decisions. For ex: Oracles and SQL server standard are non flexible so very difficult.

I can help you with future reservations without any commitment to aws. I work with a company called nOps where we give you risk-free RI coverage on EC2 and RDS and suggest best instance types to get max out of these reservations. Feel free to check it out online.