Manage AWS costs on non-production environments
microtica.com
microtica.com
But then their docs [1] give you this admin policy to use.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}[1] https://microtica.atlassian.net/servicedesk/customer/portal/...
Ultimately, the user has the complete control over what access he will give to Microtica.
Since this policy was primarily intended for DevOps module, and Cost Optimizer needs only a subset of those permissions we will update the documentation to avoid the confusion.
I log into our management account and switch to the read only role for our prod account. If I have to switch to admin role I have the toolbar display as red.
If I’m that paranoid about me making a mistake, why would I trust a third party with those rights?
I completely agree with your approach, we also encourage our users to start with the base permissions and then give more when necessary. Even more, to give an access only on resources provisioned by our system. As we automatically tag all resources, using IAM policy conditions this could be easily done. The control is always on the user's side.
And this is the first time I’ve ever said that on HN in four years. I’m suppose to give a third party full access to my infrastructure with a cross account role??
This isn’t even hosted on your own account? But even then with full access they could do anything.
Any company that would tell you to do something this crazy even if they don’t have any bad intent, is far too immature to trust with my infrastructure.
This isn't as straightforward as it might be - it takes a blog-post to explain it: https://schen1628.wordpress.com/2014/02/04/auto-start-and-st... , https://www.thinkforwardmedia.com/automating-ec2-instances-a...
My own notes and a relevant AWS Lambda script, in Python: https://pinboard.in/u:MaxBarraclough/b:f0b059256f32 , https://gist.github.com/MaxBarraclough/211e569cb57b46c0ddb48...
Imagine if you have to use different tags as selectors with different schedule times for each. You would have to control each of them through CloudFormation or even manually log into EC2 instance to update the script.
In addition, the solution provides few more benefits: 1. Auto-tagging 2. Native integration with infrastructure provisioned with Microtica 3. Cost and Saving dashboard 4. You don't need to manage your own infrastructure which will handle start/stop operations for EC2 and RDS 5. Schedule notifications
If anyone here is on the team, can you provide a bit more details as to what's happening behind the scenes?
Maybe I am misunderstanding the product and it's really an orchestration tool around when an environment is spun up and down, but then I'm having a hard time seeing the benefit over CloudWatch Events -> Lambda -> Pipeline.
I discuss issues like this with customers regularly, and I'd really love to be able to introduce this into conversations, but I need a bit more to go on :)
The benefit of Microtica Cost Optimizer over using CloudWatch+Lambda comes when you have to manage more different schedules. With CloudWatch+Lambda solution you also have to manage the schedule infrastructure no matter how simple that infrastructure is, this could become an overwhelming repetitive task.
We added additional features like: 1. automated resource tagging 2. enable/disable schedule 3. manual start/stop of resources assigned to a particular scheduler 4. cost and saving dashboard 5. notifications
Cost Optimizer is just one feature of the Microtica product. Microtica is a DevOps automation tool that you can use to provision complete cloud infrastructure and deliver applications on Kubernetes using CI/CD.
The components you are referring are ready peaces of infrastructure that you can just pick up, combine and provision in the cloud.
Behind the scenes, we register a schedule in our system and when start/stop event is fired, first we obtain temporary credentials (assume role) for the AWS account where resources to be scheduled reside, then we call AWS APIs to perform scheduling operations over EC2 and RDS.
- most of our costs for Aurora was data. Shutting down the database didn't save us too much of anything. We were already running some of the smallest instances. Aurora Serverless wasn't an option. It was missing features we needed.
- We only had a few small T* pet servers in DEV that we could shut down.
- Most of our greenfield projects are either Lambda (no cost when you aren't using, very cheap when you are) or Fargate (Docker). We could iterate through all of our clusters and set it to 0 at night and spin them back up as needed I guess
- You can't just shut down your ElasticSearch cluster.
- Do you really want to deprovision load balancers and your NAT gateway?
Did I mention that we have an entire team that works opposite hours than we do?
-
Don't even need a big team actually, just takes 1 person who decides they want to do some work during a 'sleep cycle'. Pretty common where I work, you never know when someone might be interested in picking up some work.
This is working well. A few guys used to complain about having to wait for that first boot, but in reality, it's almost always the same guy who's first in the office that gets it started, so complaints quickly went away.
The scheduling part is close to AWS instance scheduler solution. The added value of Microtica Saving Schedules is that it's much easier to manage compared to aws saving schedule where you have to update CloudFormation whenever you would need to change configuration. This could become hard to manage especially when you have multiple accounts and multiple different resource groups with different schedule configs.
On-demand start/stop of resources associated with the schedule is also something that is hard to deal with when solution is done with CloudFormation.
We also added additional features like: 1. automated resource tagging 2. enable/disable schedule 3. cost and saving dashboard 5. notifications
You can find more information about our cost optimizer in this blog post: https://microtica.com/reduce-aws-costs-on-non-production-env...
If you are aiming at a technical audience, the first thing we all did was look at what permissions were required because our first concern was security. Especially if we are handing over cross account permissions.
The second thing I want to know is how you are doing it?
But honestly, if you have a cloud native implementation like we do, just controlling EC2 and RDS only scratches the surface. We have DynamoDB, Fargate services, ElasticSearch clusters, Redshift clusters, etc.
We wanted to start with something. There are other aspects of cloud cost optimization like rightsizing, unused resources, use of spot and reserved instances that are as important as instance scheduling. As well as additional supported services you've mentioned that we are planning to support in the future.
The solution is fully serverless, the scheduling as you are already familiar, is based on triggers that initiate calling certain AWS APIs to manage state of the resources. On top of it, we added support for enabling/disabling the schedule, on-demand start/stop of resources in case somebody needs the environment immediately, auto-tagging, cost per schedule etc. all integrated in one solution.
There are tools similar to ours on the market that could solve more complex saving workflows but are also more complicated to manage and are pretty expensive.
If you are interested in how it works, feel free to try it out it's free. Any feedback is welcome.