229 captures

10 Jan 2015 - 07 Mar 2026

About this capture

Organization: Archive Team

Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.

History is littered with hundreds of conflicts over the future of a community, group, location or business that were "resolved" when one of the parties stepped ahead and destroyed what was there. With the original point of contention destroyed, the debates would fall to the wayside. Archive Team believes that by duplicated condemned data, the conversation and debate can continue, as well as the richness and insight gained by keeping the materials. Our projects have ranged in size from a single volunteer downloading the data to a small-but-critical site, to over 100 volunteers stepping forward to acquire terabytes of user-created data to save for future generations.

The main site for Archive Team is at archiveteam.org and contains up to the date information on various projects, manifestos, plans and walkthroughs.

This collection contains the output of many Archive Team projects, both ongoing and completed. Thanks to the generous providing of disk space by the Internet Archive, multi-terabyte datasets can be made available, as well as in use by the Wayback Machine, providing a path back to lost websites and work.

Our collection has grown to the point of having sub-collections for the type of data we acquire. If you are seeking to browse the contents of these collections, the Wayback Machine is the best first stop. Otherwise, you are free to dig into the stacks to see what you may find.

The Archive Team Panic Downloads are full pulldowns of currently extant websites, meant to serve as emergency backups for needed sites that are in danger of closing, or which will be missed dearly if suddenly lost due to hard drive crashes or server failures.

To use ArchiveBot, drop by #archivebot on EFNet. To interact with ArchiveBot, you issue commands by typing it into the channel. Note you will need channel operator permissions in order to issue archiving jobs. The dashboard shows the sites being downloaded currently.

There is a dashboard running for the archivebot process at http://www.archivebot.com.

ArchiveBot's source code can be found at https://github.com/ArchiveTeam/ArchiveBot.

Demand for Spot Instances can vary significantly from moment to moment, and the availability of Spot Instances can also vary significantly depending on how many unused EC2 instances are available. It is always possible that your Spot Instance might be interrupted. Therefore, you must ensure that your application is prepared for a Spot Instance interruption.

An On-Demand Instance specified in an EC2 Fleet or Spot Fleet cannot be interrupted.

• Reasons for interruption
• Interruption behaviors
• Specifying the interruption behavior
• Preparing for interruptions
• Preparing for instance hibernation
• Spot Instance interruption notices
• Finding interrupted Spot Instances
• Determining whether Amazon EC2 interrupted a Spot Instance
• Billing for interrupted Spot Instances

Reasons for interruption

The following are the possible reasons that Amazon EC2 might interrupt your Spot Instances:

Interruption behaviors

You can specify that Amazon EC2 should do one of the following when it interrupts a Spot Instance:

The default is to terminate Spot Instances when they are interrupted. To change the interruption behavior, see Specifying the interruption behavior.

Stopping interrupted Spot Instances

You can specify the interruption behavior so that Amazon EC2 stops Spot Instances when they are interrupted if the following requirements are met.

• For a Spot Instance request, the type must be persistent. You cannot specify a launch group in the Spot Instance request.

• For an EC2 Fleet or Spot Fleet request, the type must be maintain.

• The root volume must be an EBS volume, not an instance store volume.

After a Spot Instance is stopped by the Spot service, only the Spot service can restart the Spot Instance, and the same launch specification must be used.

For a Spot Instance launched by a persistent Spot Instance request, the Spot service restarts the stopped instance when capacity is available in the same Availability Zone and for the same instance type as the stopped instance.

If instances in an EC2 Fleet or Spot Fleet are stopped and the fleet is of type maintain, the Spot service launches replacement instances to maintain the target capacity. The Spot service finds the best pools based on the specified allocation strategy (lowestPrice, diversified, or InstancePoolsToUseCount); it does not prioritize the pool with the earlier stopped instances. Later, if the allocation strategy leads to a pool containing the earlier stopped instances, the Spot service restarts the stopped instances to meet the target capacity.

For example, consider a Spot Fleet with the lowestPrice allocation strategy. At initial launch, a c3.large pool meets the lowestPrice criteria for the launch specification. Later, when the c3.large instances are interrupted, the Spot service stops the instances and replenishes capacity from another pool that fits the lowestPrice strategy. This time, the pool happens to be a c4.large pool and the Spot service launches c4.large instances to meet the target capacity. Similarly, Spot Fleet could move to a c5.large pool the next time. In each of these transitions, the Spot service does not prioritize pools with earlier stopped instances, but rather prioritizes purely on the specified allocation strategy. The lowestPrice strategy can lead back to pools with earlier stopped instances. For example, if instances are interrupted in the c5.large pool and the lowestPrice strategy leads it back to the c3.largeorc4.large pools, the earlier stopped instances are restarted to fulfill target capacity.

While a Spot Instance is stopped, you can modify some of its instance attributes, but not the instance type. If you detach or delete an EBS volume, it is not attached when the Spot Instance is started. If you detach the root volume and the Spot service attempts to start the Spot Instance, instance start fails and the Spot service terminates the stopped instance.

You can terminate a Spot Instance while it is stopped. If you cancel a Spot request, an EC2 Fleet, or a Spot Fleet, the Spot service terminates any associated Spot Instances that are stopped.

While a Spot Instance is stopped, you are charged only for the EBS volumes, which are preserved. With EC2 Fleet and Spot Fleet, if you have many stopped instances, you can exceed the limit on the number of EBS volumes for your account.

Hibernating interrupted Spot Instances

You can specify the interruption behavior so that Amazon EC2 hibernates Spot Instances when they are interrupted if the following requirements are met.

• For a Spot Instance request, the type must be persistent. You cannot specify a launch group in the Spot Instance request.

• For an EC2 Fleet or Spot Fleet request, the type must be maintain.

• The root volume must be an EBS volume, not an instance store volume, and it must be large enough to store the instance memory (RAM) during hibernation.

• The following instances are supported: C3, C4, C5, M4, M5, R3, and R4, with less than 100 GB of memory.

• The following operating systems are supported: Amazon Linux 2, Amazon Linux AMI, Ubuntu with an AWS-tuned Ubuntu kernel (linux-aws) greater than 4.4.0-1041, and Windows Server 2008 R2 and later.

• Install the hibernation agent on a supported operating system, or use one of the following AMIs, which already include the agent:

  • Amazon Linux 2

• Amazon Linux AMI 2017.09.1 or later

• Ubuntu Xenial 16.04 20171121 or later

• Windows Server 2008 R2 AMI 2017.11.19 or later

• Windows Server 2012 or Windows Server 2012 R2 AMI 2017.11.19 or later

• Windows Server 2016 AMI 2017.11.19 or later

• Windows Server 2019

• We strongly recommend that you use an encrypted Amazon EBS volume as the root volume, because instance memory is stored on the root volume during hibernation. This ensures that the contents of memory (RAM) are encrypted when the data is at rest on the volume and when data is moving between the instance and volume. Use one of the following three options to ensure that the root volume is an encrypted Amazon EBS volume:

  • EBS “single-step” encryption: In a single run-instances API call, you can launch encrypted EBS-backed EC2 instances from an unencrypted AMI. For more information, see Using encryption with EBS-backed AMIs.

• EBS encryption by default: You can enable EBS encryption by default to ensure all new EBS volumes created in your AWS account are encrypted. For more information, see Encryption by default.

• Encrypted AMI: You can enable EBS encryption by using an encrypted AMI to launch your instance. If your AMI does not have an encrypted root snapshot, you can copy it to a new AMI and request encryption. For more information, see Encrypt an unencrypted image during copy and Copying an AMI.

When a Spot Instance is hibernated by the Spot service, the EBS volumes are preserved and instance memory (RAM) is preserved on the root volume. The private IP addresses of the instance are also preserved. Instance storage volumes and public IP addresses, other than Elastic IP addresses, are not preserved. While the instance is hibernating, you are charged only for the EBS volumes. With EC2 Fleet and Spot Fleet, if you have many hibernated instances, you can exceed the limit on the number of EBS volumes for your account.

The agent prompts the operating system to hibernate when the instance receives a signal from the Spot service. If the agent is not installed, the underlying operating system doesn't support hibernation, or there isn't enough volume space to save the instance memory, hibernation fails and the Spot service stops the instance instead.

When the Spot service hibernates a Spot Instance, you receive an interruption notice, but you do not have two minutes before the Spot Instance is interrupted. Hibernation begins immediately. While the instance is in the process of hibernating, instance health checks might fail. When the hibernation process completes, the state of the instance is stopped.

Resuming a hibernated Spot Instance

After a Spot Instance is hibernated by the Spot service, it can only be resumed by the Spot service. The Spot service resumes the instance when capacity becomes available with a Spot price that is less than your specified maximum price.

For more information, see Preparing for instance hibernation.

For information about hibernating On-Demand Instances, see Hibernate your Linux instance.

Specifying the interruption behavior

If you do not specify an interruption behavior, the default is to terminate Spot Instances when they are interrupted. You can specify the interruption behavior when you create a Spot request. The way in which you specify the interruption behavior is different depending on how you request Spot Instances.

If you request Spot Instances using the launch instance wizard, you can specify the interruption behavior as follows: Select the Persistent request check box and then, from Interruption behavior, choose an interruption behavior.

If you request Spot Instances using the Spot console, you can specify the interruption behavior as follows: Select the Maintain target capacity check box and then, from Interruption behavior, choose an interruption behavior.

If you configure Spot Instances in a launch template, you can specify the interruption behavior as follows: In the launch template, expand Advanced details and select the Request Spot Instances checkbox. Choose Customize and then, from Interruption behavior, choose an interruption behavior.

If you configure Spot Instances in a launch configuration when using the request-spot-fleet CLI, you can specify the interruption behavior as follows: For InstanceInterruptionBehavior, specify an interruption behavior.

If you configure Spot Instances using the request-spot-instances CLI, you can specify the interruption behavior as follows: For --instance-interruption-behavior, specify an interruption behavior.

Preparing for interruptions

Here are some best practices to follow when you use Spot Instances:

Preparing for instance hibernation

You must install a hibernation agent on your instance, unless you used an AMI that already includes the agent. You must run the agent on instance startup, whether the agent was included in your AMI or you installed it yourself.

The following procedures help you prepare a Linux instance. For directions to prepare a Windows instance, see Preparing for instance hibernation in the Amazon EC2 User Guide for Windows Instances.

1. Verify that your kernel supports hibernation and update the kernel if necessary.

2. If your AMI doesn't include the agent, install the agent using the following command.

   
   
   
   
   sudo yum update; sudo yum install hibagent

3. Add the following to the user data:

   
   
   
   
   #!/bin/bash
   /usr/bin/enable-ec2-spot-hibernation

1. If your AMI doesn't include the agent, install the agent using the following command. The hibernation agent is only available on Ubuntu 16.04 or later.

   
   
   
   
   sudo apt-get install hibagent

2. Add the following to the user data.

   
   
   
   
   #!/bin/bash
   /usr/bin/enable-ec2-spot-hibernation

Spot Instance interruption notices

The best way for you to gracefully handle Spot Instance interruptions is to architect your application to be fault-tolerant. To accomplish this, you can take advantage of Spot Instance interruption notices. A Spot Instance interruption notice is a warning that is issued two minutes before Amazon EC2 stops or terminates your Spot Instance. If you specify hibernation as the interruption behavior, you receive an interruption notice, but you do not receive a two-minute warning because the hibernation process begins immediately.

We recommend that you check for these interruption notices every 5 seconds.

The interruption notice is made available as a CloudWatch event and as an item in the instance metadata on the Spot Instance.

EC2 Spot Instance interruption notice

When Amazon EC2 is going to interrupt your Spot Instance, it emits an event two minutes prior to the actual interruption (except for hibernation, which gets the interruption notice, but not two minutes in advance, because hibernation begins immediately). This event can be detected by Amazon CloudWatch Events. For more information about CloudWatch events, see the Amazon CloudWatch Events User Guide. For a detailed example that walks you through how to create and use event rules, see Taking Advantage of Amazon EC2 Spot Instance Interruption Notices.

The following is an example of the event for Spot Instance interruption. The possible values for instance-action are hibernate, stop, and terminate.

{
    "version": "0",
    "id": "12345678-1234-1234-1234-123456789012",
    "detail-type": "EC2 Spot Instance Interruption Warning",
    "source": "aws.ec2",
    "account": "123456789012",
    "time": "yyyy-mm-ddThh:mm:ssZ",
    "region": "us-east-2",
    "resources": ["arn:aws:ec2:us-east-2:123456789012:instance/i-1234567890abcdef0"],
    "detail": {
        "instance-id": "i-1234567890abcdef0",
        "instance-action": "action"
    }
}

instance-action

If your Spot Instance is marked to be stopped or terminated by the Spot service, the instance-action item is present in your instance metadata. Otherwise, it is not present. You can retrieve instance-action as follows.

The instance-action item specifies the action and the approximate time, in UTC, when the action will occur.

The following example indicates the time at which this instance will be stopped.

{"action": "stop", "time": "2017-09-18T08:22:00Z"}

The following example indicates the time at which this instance will be terminated.

{"action": "terminate", "time": "2017-09-18T08:22:00Z"}

If Amazon EC2 is not preparing to stop or terminate the instance, or if you terminated the instance yourself, instance-action is not present and you receive an HTTP 404 error when you try to retrieve it.

termination-time

This item is maintained for backward compatibility; you should use instance-action instead.

If your Spot Instance is marked for termination by the Spot service, the termination-time item is present in your instance metadata. Otherwise, it is not present. You can retrieve termination-time as follows.

The termination-time item specifies the approximate time in UTC when the instance receives the shutdown signal. For example:

2015-01-05T18:02:00Z

If Amazon EC2 is not preparing to terminate the instance, or if you terminated the Spot Instance yourself, the termination-time item is either not present (so you receive an HTTP 404 error) or contains a value that is not a time value.

If Amazon EC2 fails to terminate the instance, the request status is set to fulfilled. The termination-time value remains in the instance metadata with the original approximate time, which is now in the past.

Finding interrupted Spot Instances

In the console, the Instances pane displays all instances, including Spot Instances. You can identify a Spot Instance from the spot value in the Lifecycle column. The Instance State column indicates whether the instance is pending, running, stopping, stopped, shutting-down, or terminated. For a hibernated Spot Instance, the instance state is stopped.

1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.

2. In the navigation pane, choose Instances. In the top right corner, choose the Show/Hide Columns icon, and under Instance Attributes, select Lifecycle. For Spot Instances, Lifecycleisspot.

   Alternatively, in the navigation pane, choose Spot Requests. You can see both Spot Instance requests and Spot Fleet requests. To view the IDs of the instances, select a Spot Instance request or a Spot Fleet request and choose the Instances tab. Choose an instance ID to display the instance in the Instances pane.

3. For each Spot Instance, you can view its state in the Instance State column.

To find interrupted Spot Instances (AWS CLI)

You can list your interrupted Spot Instances using the describe-instances command with the --filters parameter. To list only the instance IDs in the output, add the --query parameter.

aws ec2 describe-instances \
    --filters Name=instance-lifecycle,Values=spot Name=instance-state-name,Values=terminated,stopped \
    --query Reservations[*].Instances[*].InstanceId

Determining whether Amazon EC2 interrupted a Spot Instance

If a Spot Instance is stopped, hibernated, or terminated, you can use CloudTrail to see whether Amazon EC2 interrupted the Spot Instance. In CloudTrail, the event name BidEvictedEvent indicates that Amazon EC2 interrupted the Spot Instance. For more information about using CloudTrail, see Logging Amazon EC2 and Amazon EBS API calls with AWS CloudTrail.

Billing for interrupted Spot Instances

When a Spot Instance (not in a Spot block) is interrupted, you’re charged as follows.

When a Spot Instance in a Spot block is interrupted, you’re charged as follows.

If you've got a moment, please tell us what we did right so we can do more of it.

If you've got a moment, please tell us how we can make the documentation better.