Service: Amazon Elastic Compute Cloud
Region: 🇬🇧Europe (London)
URL: http://status.aws.amazon.com/#ec2-eu-west-2_1612194087

We're continuing to address connectivity issues to impacted instances in a single Availability Zone (euw2-az3) in the EU-WEST-2 Region. The elevated error rates that impacted some new instance launches in the affected Availability Zone have fully recovered.

#ec2 #euwest2

Service: Amazon Elastic Compute Cloud
Region: 🇬🇧Europe (London)
URL: http://status.aws.amazon.com/#ec2-eu-west-2_1612196992

We have resolved the connectivity issues for the vast majority of affected instances in a single Availability Zone (euw2-az3) in the EU-WEST-2 Region. We are also seeing recovery for the vast majority of EBS volumes experiencing degraded performance due to this event. Services that use EC2 and EBS including RDS, EFS, Elasticache, ECS Fargate, Managed Streaming for Apache Kafka, EMR and Sagemaker are also seeing recovery. We continue to work towards full recovery for the remaining instances and volumes.

#ec2 #euwest2

Service: Amazon Elastic Compute Cloud
Region: 🇬🇧Europe (London)
URL: http://status.aws.amazon.com/#ec2-eu-west-2_1612198409

Starting at 2:57 AM PST we experienced power and network connectivity issues for some instances, and degraded performance for some EBS volumes in the affected Availability Zone (euw2-az3). By 3:59 AM PST, power and networking connectivity had been restored to the majority of affected instances and, by 7:32 AM PST, degraded performance for the majority of affected EBS volumes had been resolved. Since the beginning of the impact, we have been working to recover the remaining instances and volumes. A small number of remaining instances and volumes are hosted on hardware which was adversely affected by the event. We continue to work to recover all affected instances and volumes and have opened notifications for the remaining impacted customers via the Personal Health Dashboard. For immediate recovery, we recommend replacing any remaining affected instances or volumes if possible.

#ec2 #euwest2

ребята, подскажите, а можно ведь обращаться напрямую с инстанса с соответствующей IAM ролью к S3 не имея access_key/secret_key?

да, возможно

ага, может там какая-то хитрость есть, у меня access denied все равно, хотя я на тестовом аккаунте открыл s3fullaccess и все что нужно, и бакет полиси максимально открыт, и все равно не пускает. А везде в гугле используют ключи сверху роли еще

на acloudguru чем basic план от plus отличается?

там в basic невозможно свободно создать ресурсы в облаке видимо, может с этой точки зрения Linuxacademy будет выгоднее взять за ту же цену

Привет! Была ли у кого-то такая проблема?
У нас есть Lambda которая коннектится к Postgres (в RDS). Чтобы Lambda не плодила миллион коннекшенов настроили RDS Proxy.

Но вчера (сегодня ночью) было много вызовов к этой лямбде и у нас уже более чем 12 часов висят 100 коннекшенов к базе и не закрываются. Lambda давным давно не работает, и они должны были закрыться хотя бы из-за того что там idle timeout стоит 30 минут

RDS proxy явно что-то чудит (не закрывает те connections)

В плюсе есть доступ к лабам в gcp/aws/azure

но вот мне кажется что в Linuxacademy это есть в подписке тоже а она дешевле

Линукс академи уже давно нету вроде

Они же вместе с acg щас

У них даже сайта нету

Вообще acg это спорное явление

есть

и курсы там есть и подписка там есть, просто переадресация, но есть возможность залогиниться

в каком плане?

Почему на скачку  может выдаваться 403 ошибка, при формировании временного линка через aws s3 presign  ?
key/secret добавлены в полиси, через aws cli файл загружается