I would like to use a EC2 instance for accounting purpose as the instance is required to be accessed by multiple party. Since EC2 charges are per hour basis. I am planning to turn on the instance only when some one needs to use then turn if off. The instance is not required to be live 24x7.
Start the instance with a mouse click. (maybe some script or panel or url.
Remote Desktop Connect- My accountant finishes the work.
User shutdown the instance or auto shutdown after 30 mins of inactivity.
How do we go about it ?
Thanks,
Dwija
You can Start an Amazon EC2 instance that was previously Stopped by sending a StartInstance command. This can be done from many different programming languages, or via the AWS Command-Line Interface (CLI) (available for Windows, Mac and Linux).
Turning off the instance when it is not in use is harder because you need to identify when it is appropriate to turn it off. You could have a program on the instance itself (much like a screensaver) that detects when the system is 'idle' and issues a Shutdown command on the virtual machine (just like Choosing Shutdown from the Start menu). This will Stop the Amazon EC2 instance.
An alternative, depending on your use-case, would be to use Amazon Workspaces, which is a virtual desktop -- a computer that is running in the cloud that you can connect with from Windows, Mac, iOS or Android devices. It is charged either on a monthly subscription or on a combination of subscription + hourly charge. It automatically turns off after the user has disconnected for a period of time. An Amazon Workspace is typically used by one person as their 'personal' computer, but it could be shared amongst other users.
Related
I have a java process on AWS. It is not dockerised for business reasons. But if the process goes down. It should spawn a new EC2 instance. Is this possible with Cloud watch?
What you are looking for is AWS Autoscaling.
AWS Auto Scaling is a service that automatically monitors and adjusts
compute resources to maintain performance for applications hosted in
the Amazon Web Services (AWS) public cloud.
Essentially what it does is, it integrates with AWS Cloud Watch to set alarms for specific situations.
For example, if the instance gets hit with x number of requests within a time period of y mins. Or for example, the health check of an instance fails (your situation).
When you are launching your EC2 instance, explore and check out Autoscaling groups and Launch Configuration. Check out this link below
https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html
Now you mentioned that there is a process which is running in your EC2 instance.
Launch Configurations give you a way to provide a bash script which is executed when your instance starts.
This bash script should contain the logic to pull your business logic from wherever you are hosting it, and then run that process.
Let me know if you have any confusions.
I found the answer in the below link. AWS Cloud watch will help us monitor applications and reboot EC2 instance if application doesn't respond.
https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-action-reboot-ec2-instance/
I want to create an Azure Virtual Machine that I only need to run approximately for 1 or 2 hours once or twice per day. I don't want to pay for the server when I'm not using it.
I know I can just go to the dashboard and shut it off, but I often forget to do so, I'm getting senile! I would like for a timer to start when the system (Windows 10) is started, and when the timer reaches zero, the image is made inactive (no charges incurred) unless I request more time.
Any ideas would be appreciated.
The dashboard has an automatic shutdown feature. This can also be configured to send a webhook notification with a link which will delay the shutdown. Currently in-machine notifications are not supported.
Although there are many tools like PowerShell scripts and apps that you could use from within the VM to trigger automatic shutdown, there are some billing gotchas to be aware of.
With an Azure VM, you pay per second and cease paying only when the machine is completely deallocated and no longer reserving memory and cores on the platform. (There is still a nominal storage charge associated with storage of the VM image). You cannot deallocate the VM from within itself.
To ensure the VM isn't incurring charges, check that the status is 'Stopped (deallocated').
I'd like to use a GCE server and VNC to run some desktop programs I've written. However, I'd like to not have the GCE server running all the time (to save money) and I'd like to have the setup of my VNC desktop persisted (to save time). It seems like the easiest way to accomplish this is to somehow hibernate the GCE instance. Is there a way to do this either from a script or from the command line?
The only currently supported technique that I'm aware of would be to use a bootable persistent disk, which outlives the virtual machine so you could delete and restart the VM with moderately quick (under 30s) startup time but I don't think that would meet your needs because unless your app has built-in, robust checkpoint/resume logic, you might not be able to pick up where you left off on the desktop.
Another way to approach this would be to use a lightweight container, like Docker, which has suspend/resume and checkpointing built into its design. You can't currently run Docker containers on Google Compute Engine but we're interested in exploring the potential of Docker on GCE so stay tuned.
Sounds like what you'd really like is a native suspend capability with near instantaneous resume and no or very low charge for VMs in the suspended state. I think that's an interesting idea - I've submittted an internal feature request to the Compute Engine engineering team for future consideration.
Compute Engine has alpha support for suspending virtual machines. A quote from that documentation:
gcloud alpha compute instances suspend is used to suspend a Google Compute Engine virtual machine. Suspending a VM is the equivalent of sleep or standby mode: the guest receives an ACPI S3 suspend signal, after which all VM state is saved to temporary storage. An instance can only be suspended while it is in the RUNNING state. A suspended instance will be put in SUSPENDED state.
The command is not yet available in the Compute Engine web UI but can be invoked from the command line like:
gcloud alpha compute instances suspend my-vm
There is a huge variance in the launch times of Windows AMIs (EBS-backed) that I am using. Some start up in just 3 minutes. Others can take 20+ minutes. My understanding is that the default Windows AMIs can be slow as they require two reboots to get active, but in my case these are all customized machines, either public or snapshots I have created.
On a similar note, I was retrieving the log files in the EC2 console to know when my machine is started. However, some of the machines DO NOT seem to generate any logs?? So, realistically, I have a variable startup time and variable logging, in which case how can I even really tell that a Windows machine has become avialable?
It does take a varying amount of time to launch a Windows AMI in EC2. You can minimize it, a bit, by setting a fixed machine name for the instance. Do this as you would on any Windows computer - in the properties of "My Computer", "Computer Name" tab. Then, run "EC2ConfigService Settings" from the Start Menu's "All Programs" list. That program is installed there by Amazon on most base AMIs. In that program, on the "General" tab, UnCheck "Set Computer Name". This eliminates the system from re-booting itself once while starting up the image, as it would have to, in order to set the name.
Still, you would like to be notified when your instance is ready! This is a perfect job for Amazon's Simple Notification Service. The service (also known as SNS) is simple to use programmatically (from a windows .NET project for example), free (for the first 100,000 messages, less than 1gb in total), and the notifications are immediate.
Code to send a notification (in VB.NET):
Imports Amazon.EC2.AmazonEC2Client
Imports Amazon.SimpleNotificationService
DIM LabSNS As New AmazonSimpleNotificationServiceClient(Lab_AWSKey, Lab_AWSSecretKey)
Dim PubReq As New Amazon.SimpleNotificationService.Model.PublishRequest
Dim Msg As String 'Messege to be built up, then be sent. It is body of eMail.
Msg = "The instance is running and ready!"
Msg = Msg + vbCrLf + "Previous State of machine was:" & PreviousState 'A made-up global
Msg = Msg + [Any other info. I want to send myself about the start of the instance.]
PubReq.WithTopicArn(Topic)'Topic is a global. It's value is a key from SNS topic setup.
PubReq.WithSubject("EC2 Instance is Ready!")
PubReq.WithMessage(Msg)
LabSNS.Publish(PubReq)
The code requires Amazon's SDK for .NET which is free. Write a program including some code like the above. Set the program to run after the computer starts, and before login, using the Windows Task Scheduler - create a task triggered "at system startup" that calls the program.
The setup for SNS is documented here:SNS Documentation
It looks like a lot of trouble to send eMail, however, Amazon's EC2 environment is highly restrictive when it comes to sending eMail. Many have tried to use EC2 as a spam platform, so Amazon has been thorough in blocking SMTP (eMail) traffic, except as prescribed by Amazon. You can't just open up a port on the Amazon security group to bypass Amazon's blocks.
Amazon does have a general eMail facility one can use from within EC2. It is called, Amazon Simple Email Service (SES). That will not work well for you, as it is designed for bulk eMail. So, SES's pricing, exception handling and messaging won't fit well with what you need, I don't think.
SNS, on the other hand works great for this. It includes an initial eMail to the recipients (you, and perhaps others you may want to notify of your server coming on-line) asking if they want to receive future messages of the topic; they are given an option to opt out, and must reply to receive further.
The setup process (shown in blocks above) is all easily doable from Amazon's AWS Management Console. (Your question implies you that you already have an AWS EC2 account needed for this.) Once setup, any instance launched from the AMI would send out an eMail containing any information (available to your program) of your choosing as soon as the machine is ready.
It'll be gotcha-free in setting up, and solid as a rock in operation.
Regardless of the source of your Windows AMI, it will reboot a number of times during its startup process before it becomes available via RDP. All Windows AMIs are derived from the Windows AMIs produced by Amazon, which have this boot process by design. [It's been suggested that this boot process is hard-coded into a custom kernel that is running inside the guest VM.]
Console logs typically take between 2 and 5 minutes to appear.
Unfortunately, Windows on EC2 is more difficult to automate and track than linux. The RightScale and Scalr folks have done some excellent work integrating Windows into their management platform. And the Opscode Chef configuration Management tool also supports Windows in EC2 and can help you discover when your instances are ready for use.
We're running a lightweight web app on a single EC2 server instance, which is fine for our needs, but we're wondering about monitoring and restarting it if it goes down.
We have a separate non-Amazon server we'd like to use to monitor the EC2 and start a fresh instance if necessary and shut down the old one. All our user data is on Elastic Storage, so we're not too worried about losing anything.
I was wondering if anyone has any experience of using EC2 in this way, and in particular of automating the process of starting the new instance? We have no problem creating something from scratch, but it seems like it should be a solved problem, so I was wondering if anyone has any tips, links, scripts, tutorials, etc to share.
Thanks.
You should have a look at puppet and its support for AWS. I would also look at the RightScale AWS library as well as this post about starting a server with the RightScale scripts. You may also find this article on web serving with EC2 useful. I have done something similar to this but without the external monitoring, the node monitored itself and shut down when it was no longer needed then a new one would start up later when there was more work to do.
Couple of points:
You MUST MUST MUST back up your Amazon EBS volume.
They claim "better" reliability, but not 100%, and it's SEVERAL orders of magnitude off of S3's "12 9's" of durability. S3 durability >> EBS durability. That's a fact. EBS supports a "snapshots" feature which backs up your storage efficiently and incrementally to S3. Also, with EBS snapshots, you only pay for the compressed deltas, which is typically far far less than the allocated volume size. In another life, I've sent lost-volume emails to smaller customers like you who "thought" that EBS was "durable" and trusted it with the only copy of a mission-critical database... it's heartbreaking.
Your Q: automating start-up of a new instance
The design path you mention is relatively untraveled; here's why... Lots of companies run redundant "hot-spare" instances where the second instance is booted and running. This allows rapid failover (seconds) in the event of "failure" (could be hardware or software). The issue with a "cold-spare" is that it's harder to keep the machine up to date and ready to pick up where the old box left off. More important, it's tricky to VALIDATE that the spare is capable of successfully recovering your production service. Hardware is more reliable than untested software systems. TEST TEST TEST. If you haven't tested your fail-over, it doesn't work.
The simple automation of starting a new EBS instance is easy, bordering on trivial. It's just a one-line bash script calling the EC2 command-line tools. What's tricky is everything on top of that. Such a solution pretty much implies a fully 100% automated deployment process. And this is all specific to your application. Can your app pull down all the data it needs to run (maybe it's stored in S3?). Can you kill you instance today and boot a new instance with 0.000 manual setup/install steps?
Or, you may be talking about a scenario I'll call "re-instancing an EBS volume":
EC2 box dies (root volume is EBS)
Force detach EBS volume
Boot new EC2 instance with the EBS volume
... That mostly works. The gotchas:
Doesn't protect against EBS failures, either total volume loss or an availability loss
Recovery time is O(minutes) assuming everything works just right
Your services need to be configured to restart automatically. It does no good to bring the box back if Nginx isn't running.
Your DNS routes or other services or whatever need to be ok with the IP-address changing. This can be worked around with ElasticIP.
How are your host SSH keys handled? Same name, new host key can break SSH-based automation when it gets the strong-warning for host-key-changed.
I don't have proof of this (other than seeing it happen once), but I believe that EC2/EBS _already_does_this_ automatically for boot-from-EBS instances
Again, the hard part here is on your plate. Can you stop your production service today and bring it up RELIABLY on a new instance? If so, the EC2 part of the story is really really easy.
As a side point:
All our user data is on Elastic Storage, so we're not too worried about losing anything.
I'd strongly suggest to regularly snapshot your EBS (Elastic Block Storage) to S3 if you are not doing that already.
You can use an autoscale group with a min/max/desired quantity of 1. Place the instance behind an ELB and have the autoscale group be triggered by the ELB healthy node count. This allows you to have built in monitoring by cloudwatch and the ELB health check. Anytime there is an issue the instance be replaced by the autoscale service.
If you have not checked 'Protect against accidental termination' you might want to do so.
Even if you have disabled 'Detailed Monitoring' for your instance you should still see the 'StatusCheckFailed' metric for your instance over which you can configure an alarm (In the CloudWatch dashboard)
Your application (hosted in a different server) should receive the alarm and start the instance using the AWS API (or CLI)
Since you have protected against accidental termination you would never need to spawn a new instance.