<p>I can think of a few different ways to achieve this.</p>

<ol>
<li>First and easiest way is to create a new <strong>CloudWatch Events Rule</strong> <a href="http://crontab.guru" rel="nofollow noreferrer">1</a>, set its "Event Source" to run on a schedule and "Target" to EC2 StopInstances API call with Instance IDs provided. Look at this screenshot for clarity:</li>
</ol>

<p><a href="https://i.sstatic.net/XdQBL.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/XdQBL.png" alt="Creating a CloudWatch Event"></a></p>

<p>With this example, An event will start at every night at midnight and it will stop Instances by their IDs. You can change the schedule with cron expressions. See: <a href="http://crontab.guru" rel="nofollow noreferrer">https://crontab.guru</a></p>

<ol start="2">
<li>You can implement any kind of custom logic with <a href="https://docs.aws.amazon.com/lambda/latest/dg/welcome.html" rel="nofollow noreferrer">AWS Lambda functions</a> and schedule them to be run with <a href="https://docs.aws.amazon.com/lambda/latest/dg/invoking-lambda-function.html" rel="nofollow noreferrer">a variety of AWS services</a> (including CloudWatch Events). </li>
</ol>

<p>For example, with a Lambda function you can implement logic to find instances by a tag, like <em>"GoodBefore=2018-08-10"</em>, and stop these instances. In fact you could even make use of API Gateway to expose an API for requesting instances, only to be terminated after a few days by their <em>"GoodBefore</em>" tag.</p>

<p>Of course, while this way is much more customizable and sophisticated, it may prove hard especially if you don't have experience in programming.</p>

<ol start="3">
<li>If you don't want to implement custom logic with Lambda, but also need more than what CloudWatch Events can provide, you can make use of <a href="https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/" rel="nofollow noreferrer">Instance Scheduler</a> solution provided by AWS. It's a similar solution to what I described in previous method, but this time AWS already did the hard work for you.</li>
</ol>

<p><a href="http://crontab.guru" rel="nofollow noreferrer">1</a> URL for us-east-1 region: <a href="https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#rules:action=create" rel="nofollow noreferrer">https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#rules:action=create</a></p>

<p>Note: While I haven't used Instance Scheduler myself, I'm pretty sure it wouldn't decide on such things, and I think it only makes sense if it wouldn't do much more than simply making a stop call for the instance. So, on any stop event, either made by an automated solution or you, if your instances' root volume was created "EBS-backed", it will retain the data. If it is "instance store backed", it will lose the data. You can find this information from AWS EC2 console. If you want to retain data after stopping instances, make sure all volumes are EBS-backed when creating a new instance.</p>

CC BY-SA 4.0
2018-08-20T20:12:04.387Z
With the Instance Scheduler solution, does this keep the data separate from the computing instance? That is, when the instance shuts down is my data still retained on the server?
learningasigo
CC BY-SA 4.0
2018-08-21T00:01:14.197Z
While I haven't used Instance Scheduler myself, I'm pretty sure it wouldn't decide on such things, and I think it only makes sense if it wouldn't do much more than simply making a stop call for the instance.

So, on any stop event, either made by an automated solution or you, if your instances' root volume was created "EBS-backed", it will retain the data. If it is "instance store backed", it will lose the data. You can find this information from AWS EC2 console. If you want to retain data after stopping instances, make sure all volumes are EBS-backed when creating a new instance.
Yekta Leblebici
CC BY-SA 4.0
2018-08-10T19:37:21.637Z
2019-10-05T16:24:55.737Z
2019-10-05T16:24:55.737Z
Yekta Leblebici
<p>This feature has <a href="https://azure.microsoft.com/en-us/blog/announcing-auto-shutdown-for-vms-using-azure-resource-manager/" rel="nofollow noreferrer">been available in Azure</a> for a couple of years now, it's as simple as ticking a box and setting a time for shutdown. You can also have it fire a webhook if you need any notifications, or scripts run, or anything else when it shuts down. </p>

<p>Also on Azure there are pre-configured <a href="https://docs.microsoft.com/en-us/azure/machine-learning/data-science-virtual-machine/overview" rel="nofollow noreferrer">data science VMs</a> and <a href="https://docs.microsoft.com/en-us/azure/machine-learning/data-science-virtual-machine/deep-learning-dsvm-overview" rel="nofollow noreferrer">deep learning VMs</a> with all the tools you need including <a href="https://mran.microsoft.com/open" rel="nofollow noreferrer">R</a> already installed, you just pick a size and spin one up. You can go small just to try the software, or go for one with multiple GPUs, all already set up with the tools and usable straight away. You can even reboot the same box in different sizes depending on what you need that day!</p>

<p>You are correct that while a VM is not running, you will be charged only for the storage used. </p>

CC BY-SA 4.0
2018-11-08T21:48:36.803Z
2018-11-09T08:00:45.410Z
2018-11-09T08:00:45.410Z
Gaius
<p>I'm looking for recommendations on which cloud service provider we should be looking at.</p>

<p>The situation:</p>

<p>I'm part of a small team looking to leverage more powerful analytics. Most of our day to day can be done on local machines but we want to explore using more powerful hardware through a cloud platform before committing to anything in house. As far as software we use Excel, MSSQL, and R, although these cloud instances only need to run R.</p>

<p>Our ideal use case would be uploading data to the cloud, spinning up an instance to run whatever we need to run, then shutting down the instance while keeping the data and software (eg R packages) stored. This way (I think) we would only be charged for the storage while we aren't actively running a project.</p>

<p>Additionally we'd like an auto shutdown feature where the computing instances are automatically shut down if they aren't used for a certain period of time or if that isn't possible, at a given time each day.</p>

<p>We're really outside of our area of expertise here so user friendly is a big plus.</p>

<p>Any advice?</p>

<amazon-web-services><azure>
AWS or Azure with usage auto shutdown occasional usage
learningasigo
# AWS or Azure with usage auto shutdown occasional usage

(Asked by: username_0 on 2018-08-10)

I'm looking for recommendations on which cloud service provider we should be looking at.

The situation:

I'm part of a small team looking to leverage more powerful analytics. Most of our day to day can be done on local machines but we want to explore using more powerful hardware through a cloud platform before committing to anything in house. As far as software we use Excel, MSSQL, and R, although these cloud instances only need to run R.

Our ideal use case would be uploading data to the cloud, spinning up an instance to run whatever we need to run, then shutting down the instance while keeping the data and software (eg R packages) stored. This way (I think) we would only be charged for the storage while we aren't actively running a project.

Additionally we'd like an auto shutdown feature where the computing instances are automatically shut down if they aren't used for a certain period of time or if that isn't possible, at a given time each day.

We're really outside of our area of expertise here so user friendly is a big plus.

Any advice?

**Tags:** amazon-web-services, azure


---

## 2 answers

### Answer by username_1 on 2018-08-10. Score: 2

I can think of a few different ways to achieve this.

1. First and easiest way is to create a new **CloudWatch Events Rule** [1](http://crontab.guru), set its "Event Source" to run on a schedule and "Target" to EC2 StopInstances API call with Instance IDs provided. Look at this screenshot for clarity:

[![Creating a CloudWatch Event](https://i.sstatic.net/XdQBL.png)](https://i.sstatic.net/XdQBL.png)

With this example, An event will start at every night at midnight and it will stop Instances by their IDs. You can change the schedule with cron expressions. See: [https://crontab.guru](http://crontab.guru)

2. You can implement any kind of custom logic with [AWS Lambda functions](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) and schedule them to be run with [a variety of AWS services](https://docs.aws.amazon.com/lambda/latest/dg/invoking-lambda-function.html) (including CloudWatch Events).

For example, with a Lambda function you can implement logic to find instances by a tag, like *"GoodBefore=2018-08-10"*, and stop these instances. In fact you could even make use of API Gateway to expose an API for requesting instances, only to be terminated after a few days by their *"GoodBefore*" tag.

Of course, while this way is much more customizable and sophisticated, it may prove hard especially if you don't have experience in programming.

3. If you don't want to implement custom logic with Lambda, but also need more than what CloudWatch Events can provide, you can make use of [Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/) solution provided by AWS. It's a similar solution to what I described in previous method, but this time AWS already did the hard work for you.

[1](http://crontab.guru) URL for us-east-1 region: <https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#rules:action=create>

Note: While I haven't used Instance Scheduler myself, I'm pretty sure it wouldn't decide on such things, and I think it only makes sense if it wouldn't do much more than simply making a stop call for the instance. So, on any stop event, either made by an automated solution or you, if your instances' root volume was created "EBS-backed", it will retain the data. If it is "instance store backed", it will lose the data. You can find this information from AWS EC2 console. If you want to retain data after stopping instances, make sure all volumes are EBS-backed when creating a new instance.

> **Comments:**
> **username_0**: With the Instance Scheduler solution, does this keep the data separate from the computing instance? That is, when the instance shuts down is my data still retained on the server?  
> **username_1**: While I haven't used Instance Scheduler myself, I'm pretty sure it wouldn't decide on such things, and I think it only makes sense if it wouldn't do much more than simply making a stop call for the instance.  So, on any stop event, either made by an automated solution or you, if your instances' root volume was created "EBS-backed", it will retain the data. If it is "instance store backed", it will lose the data. You can find this information from AWS EC2 console. If you want to retain data after stopping instances, make sure all volumes are EBS-backed when creating a new instance.  

---

### Answer by username_2 on 2018-11-08. Score: 2

This feature has [been available in Azure](https://azure.microsoft.com/en-us/blog/announcing-auto-shutdown-for-vms-using-azure-resource-manager/) for a couple of years now, it's as simple as ticking a box and setting a time for shutdown. You can also have it fire a webhook if you need any notifications, or scripts run, or anything else when it shuts down.

Also on Azure there are pre-configured [data science VMs](https://docs.microsoft.com/en-us/azure/machine-learning/data-science-virtual-machine/overview) and [deep learning VMs](https://docs.microsoft.com/en-us/azure/machine-learning/data-science-virtual-machine/deep-learning-dsvm-overview) with all the tools you need including [R](https://mran.microsoft.com/open) already installed, you just pick a size and spin one up. You can go small just to try the software, or go for one with multiple GPUs, all already set up with the tools and usable straight away. You can even reboot the same box in different sizes depending on what you need that day!

You are correct that while a VM is not running, you will be charged only for the storage used.


---

