Archive for the ‘Amazon Elastic Compute Cloud (EU)’ Category.
October 16, 2011, 4:56 pm
We are currently investigating increased EBS API error rates in the EU-WEST-1 region.
September 6, 2011, 3:18 am
[RESOLVED] We experienced an issue where some Elastic IP address ranges were incorrectly blacklisted by some Internet anti-spam organizations. We already handled the issue and the Elastic IP ranges were successfully whitelisted.
September 6, 2011, 3:18 am
We experienced an issue where some Elastic IP address ranges were incorrectly blacklisted by some Internet anti-spam organizations. We already handled the issue and the Elastic IP ranges were successfully whitelisted.
August 13, 2011, 1:09 am
We have posted a full summary and post mortem of the recent EU West service event here.
August 11, 2011, 8:52 pm
Amazon EC2 continues to operate normally in the EU-West Region. A more detailed postmortem on the cause of the recent service disruption will be forthcoming.
August 11, 2011, 2:18 am
Please refer to the Status History below for the prior day’s entries
Aug 11, 1:10 AM PDT The vast majority of recovery snapshots have now been created and are in customer accounts. Recovery snapshots can be identified by looking at the Description field which will contain “Recovery Snapshot vol-xxxx,” where vol-xxxx is the id of the impacted volume. If you have a snapshot or volume that is in “error” state, you should have a recovery snapshot for it and can delete the volumes and snapshots that are described as “error.” Less than 2% of the affected volumes are still in the process of having their recovery snapshot created. You can tell if your volume is part of the remaining 2% being recovered if it is in the “error” state and you do not yet see a recovery snapshot. We are continuing to work to create recovery snapshots for these remaining few volumes.
August 10, 2011, 4:59 am
The API issue we previously identified has been corrected and all of the volumes that we identified as potentially having inconsistent writes are now correctly displaying the “error” state in API calls or in the AWS Management Console.
August 10, 2011, 2:13 am
Please refer to the Status History below for the prior day’s entries
Aug 10 12:30 AM PDT We continue to make regular progress on creating recovery snapshots for customers. Recovery snapshots can be identified by looking at the Description field which will contain “Recovery Snapshot vol-xxxx,” where vol-xxxx is the id of the impact volume. This process requires us to move and process large amounts of data, which is why it is taking a long time to complete, particularly for some of the larger volumes. As recovery snapshots become available, customers will see them appear in their accounts.
Additionally we have discovered that not all of the volumes that we identified as potentially having inconsistent writes are correctly displaying the “error” state in API calls or in the AWS Management Console. Volumes in “error” that are still attached to instances are still displaying their state as “in-use.” Customers can detach those volumes, and the error state will display correctly. We are actively working on a fix to always display the correct state.
Volumes that have been detached and are in an “error” state can be deleted, however they may remain in “deleting” for an extended period of time. Customers will not be billed for any resources that are either in an “error” or “deleting” state.
If a recovery snapshot has been added to your account referring either to “Recovery snapshot for snap-xxxx” or “Recovery snapshot for vol-xxxx” in the snapshot Description field, the recovery efforts for those volumes or snapshots have been completed. You can create a new volume from these snapshots, and should run a recovery tool against them (e.g. a file system recovery tool like fsck).
Aug 10, 3:59 AM PDT The API issue we previously identified has been corrected and all of the volumes that we identified as potentially having inconsistent writes are now correctly displaying the “error” state in DescribeVolumes API calls or in the AWS Management Console.
Aug 11, 1:10 AM PDT The vast majority of recovery snapshots have now been created and are in customer accounts. Recovery snapshots can be identified by looking at the Description field which will contain “Recovery Snapshot vol-xxxx,” where vol-xxxx is the id of the impacted volume. If you have a snapshot or volume that is in “error” state, you should have a recovery snapshot for it and can delete the volumes and snapshots that are described as “error.” Less than 2% of the affected volumes are still in the process of having their recovery snapshot created. You can tell if your volume is part of the remaining 2% being recovered if it is in the “error” state and you do not yet see a recovery snapshot. We are continuing to work to create recovery snapshots for these remaining few volumes.
August 10, 2011, 1:31 am
Please refer to the Status History below for the prior day’s entries
Aug 10 12:30 AM PDT We continue to make regular progress on creating recovery snapshots for customers. Recovery snapshots can be identified by looking at the Description field which will contain “Recovery Snapshot vol-xxxx,” where vol-xxxx is the id of the impact volume. This process requires us to move and process large amounts of data, which is why it is taking a long time to complete, particularly for some of the larger volumes. As recovery snapshots become available, customers will see them appear in their accounts.
Additionally we have discovered that not all of the volumes that we identified as potentially having inconsistent writes are correctly displaying the “error” state in API calls or in the AWS Management Console. Volumes in “error” that are still attached to instances are still displaying their state as “in-use.” Customers can detach those volumes, and the error state will display correctly. We are actively working on a fix to always display the correct state.
Volumes that have been detached and are in an “error” state can be deleted, however they may remain in “deleting” for an extended period of time. Customers will not be billed for any resources that are either in an “error” or “deleting” state.
If a recovery snapshot has been added to your account referring either to “Recovery snapshot for snap-xxxx” or “Recovery snapshot for vol-xxxx” in the snapshot Description field, the recovery efforts for those volumes or snapshots have been completed. You can create a new volume from these snapshots, and should run a recovery tool against them (e.g. a file system recovery tool like fsck).
August 9, 2011, 8:58 pm
Please refer to the Status History below for the prior day’s entries
Aug 10 12:30 AM PDT We continue to make regular progress on creating recovery snapshots for customers. Recovery snapshots can be identified by looking at the Description field which will contain “Recovery Snapshot vol-xxxx,” where vol-xxxx is the id of the impact volume. This process requires us to move and process large amounts of data, which is why it is taking a long time to complete, particularly for some of the larger volumes. As recovery snapshots become available, customers will see them appear in their accounts.
Additionally we have discovered that not all of the volumes that we identified as potentially having inconsistent writes are correctly displaying the “error” state in API calls or in the AWS Management Console. Volumes in “error” that are still attached to instances are still displaying their state as “in-use.” Customers can detach those volumes, and the error state will display correctly. We are actively working on a fix to always display the correct state.
Volumes that have been detached and are in an “error” state can be deleted, however they may remain in “deleting” for an extended period of time. Customers will not be billed for any resources that are either in an “error” or “deleting” state.
If a recovery snapshot has been added to your account referring either to “Recovery snapshot for snap-xxxx” or “Recovery snapshot for vol-xxxx” in the snapshot Description field, the recovery efforts for those volumes or snapshots have been completed. You can create a new volume from these snapshots, and should run a recovery tool against them (e.g. a file system recovery tool like fsck).
Aug 10, 3:59 AM PDT The API issue we previously identified has been corrected and all of the volumes that we identified as potentially having inconsistent writes are now correctly displaying the “error” state in DescribeVolumes API calls or in the AWS Management Console.
Aug 11, 1:10 AM PDT The vast majority of recovery snapshots have now been created and are in customer accounts. Recovery snapshots can be identified by looking at the Description field which will contain “Recovery Snapshot vol-xxxx,” where vol-xxxx is the id of the impacted volume. If you have a snapshot or volume that is in “error” state, you should have a recovery snapshot for it and can delete the volumes and snapshots that are described as “error.” Less than 2% of the affected volumes are still in the process of having their recovery snapshot created. You can tell if your volume is part of the remaining 2% being recovered if it is in the “error” state and you do not yet see a recovery snapshot. We are continuing to work to create recovery snapshots for these remaining few volumes.
