​​▪️ 11:44 AM PDT We are investigating increased API error rates in the US-EAST-1 Region.
▪️ 12:17 PM PDT We are working to resolve the issue resulting in increased error rates for the following EC2 APIs in the US-EAST-1 Region: RunInstances, *SecurityGroups, *NetworkInterfaces, *RouteTables, *AccountAttributes, and *NetworkAcls. These APIs will affect the ability to launch new EC2 instances and make mutating changes to Virtual Private Cloud (VPC) network configuration(s). Existing instances and networks continue to work normally. We have identified the root cause and are working towards resolution.
▪️ 12:56 PM PDT We continue to work toward recovery for the issue resulting in increased API error rates for the EC2 APIs in the US-EAST-1 Region. We have identified the root cause and applied mitigations to reduce the impact, while we continue to work towards full mitigation. Some APIs may experience errors or “request limit exceeded” when calling an affected API or using the EC2 Management Console. In many cases, a retry of the request may succeed as some requests are still succeeding. Other AWS services that utilize these affected APIs for their own workflows may also be experiencing impact. These services have posted impact via the Personal Health and/or Service Health Dashboards. We will provide an update in 30 minutes.
▪️ 1:22 PM PDT We continue to work towards full resolution for the issue resulting in increased error rates for the EC2 APIs in the US-EAST-1 Region. We have applied some request throttling for the affected APIs, which has reduced error rates, allowing several APIs to see early recovery. We are adjusting these throttling for some of the affected APIs, which are causing some additional API errors and elevated errors in the EC2 Management Console. We would expect API error rates to continue to recover with the mitigation steps we have taken as we work towards full recovery.

https://status.aws.amazon.com/

#interview #amazon

Дара рассказываето своем опыте прохождения в Амазон

https://youtu.be/ridWXjoPGCY

Обратите внимание — интересный канал https://t.iss.one/webapparch 👇🏼, где автор много пишет про интервью, вебархитектуру, ML и прочие айтишные вещи, в том числе пересекающиеся с AWS. Рекомендую.

Создание Least Privilege политик для выбранной роли на базе активности в CloudTrail logs теперь в AWS Console:

https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/

You can now use IAM Access Analyzer to generate fine-grained policies, based on your access activity in your AWS CloudTrail logs. When you request a policy, IAM Access Analyzer gets to work and identifies your activity from CloudTrail logs to generate a policy. The generated policy grants only the required permissions for your workloads and makes it easier for you to implement least privilege permissions.

#IAM #security

IAM аттрибут sts:SourceIdentity для удобного определения пользователей, переключившихся из других ролей:

https://aws.amazon.com/blogs/security/how-to-relate-iam-role-activity-to-corporate-identity/

С помощью установки sts:SourceIdentity легко делать аудит логов CloudTrail, идентифицируя, например, пользователей из Active Directory (AD), посредством добавления какого-то поля из AD, которое будет присутствовать в логах для любой роли любого аккаунта (т.е. в том числе после переключения).

Документация:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_monitor.html

#IAM #security

Здесь проскакивала статья от eCrazy Technologies про оптимизацию затрат с помощью Lambda, но на английском. Для легкости чтения выпустил перевод.
https://habr.com/ru/post/552462/

Всем привет!
Новый бесплатный курс - Machine Learning Essentials for Business and Technical Decision Makers
Curriculum description
In this three-course curriculum, you will learn about best practices and recommendations for machine learning (ML). The course explores how to roadmap for integrating ML into your business processes, explores requirements to determine if ML is the appropriate solution to a business problem, and describes what components are needed for a successful organizational adoption of ML.
• Course level: Foundational
• Duration: 90 minutes
https://www.aws.training/Details/Curriculum?id=70878

Настройка Amazon Managed Prometheus (AMP) для EKS

Prometheus как сервис появился на AWS в самом конце 2020-го года. На момент написания поста он всё ещё в открытом превью, означающее, что он спокойно доступен в консоли (в отличие от Amazon Managed Grafana, для доступа к которой нужно писать челобитную).

Материалов по AMP не так много. Основные на сейчас это:

Анонс AMP:
🔹 Getting Started with Amazon Managed Service for Prometheus
🎥 AWS re:Invent 2020: Introducing Amazon Managed Service for Prometheus (AMP)

Настройка AMP в cross-acount варианте (когда AMP в другом AWS аккаунте по отношению к окружению, с которого снимаются метрики):
🔹 Setting up cross-account ingestion into Amazon Managed Service for Prometheus

Даже если просто полистать ссылки, то настораживает обилие баша в процессе настройки, что если и поможет, то лишь в повторении демки создания с нуля VPC+EKS сотоварищи, но не особо годится для интеграции в собственные решения.

Документация в сложных моментах содержит те же простыни баша (всё на текущий момент, очень надеюсь, что после это изменится):
🔹 Set up IAM roles for service accounts

Основные моменты AMP + EKS:
▪️ метрики из EKS шлются в AMP (активный режим)
▪️ AMP может быть в то том же или другом аккаунте/регионе
(дополнительные расходы на трафик, если в другом аккаунте/регионе)
▪️ метрики должны быть авторизованы IAM, для чего вместе с Prometheus-сервером водружается sidecar-контейнером IAM-прокси
▪️ для безопасности, чтобы не отправлять метрики через интернет, можно использовать VPC endpoints

Для реализации в EKS потребуется настроить IAM roles for service accounts (если они ещё не были настроены).

⚠️ Отдельно обращу внимание, чтобы во избежание проблем настраивать всё лучше с последними версиями AWS CLI и eksctl.

Главный сложный момент возникает с ролью (в статьях это EKS-AMP-ServiceAccount-Role), в которую переключается сервисный аккаунт для отсылки метрик. У неё весьма сложная структура с хитрыми Conditions. Как раз во многом из-за неё понаписаны простыни баша.

Вместо баша для объяснения особенностей создания этой роли приведу рабочий пример кода на CloudFormation:

AssumeRolePolicyDocument: !Sub
 - |
  {
   "Version": "2012-10-17",
   "Statement": [
    {
     "Effect": "Allow",
     "Principal": {
      "Federated": "arn:aws:iam::${AWS::AccountId}:oidc-provider/oidc.eks.${AWS::Region}.amazonaws.com/id/${Id}"
     },
     "Action": "sts:AssumeRoleWithWebIdentity",
     "Condition": {
      "StringEquals": {
       "oidc.eks.${AWS::Region}.amazonaws.com/id/${Id}:sub": "system:serviceaccount:${NameSpace}:${ServiceAccount}"
      }
     }
    }
   ]
  }
 - Id:       !Ref OidcProviderId
  Namespace:   !Ref KuberNamespace
  ServiceAccount: !Ref ServiceAccountName

👉 Это лишь фрагмент, полный код в репозитории.

Переменные, которые участвуют в создании роли:
• Id - EKS Cluster OIDC Provider ID, в данном случае лишь его численная часть (без https и др. элементов)
• Namespace - это --namespace, в котором находится Prometheus сервер в EKS кластере
• ServiceAccount - имя сервисного аккаунта Prometheus сервера

Стоит обратить внимание, что в yaml-коде выше используется вкрапление json. Это потому, что в Conditions в качестве ключа нужно передать переменную "oidc.eks.${AWS::Region}.amazonaws.com/id/${Id}:sub", что невозможно сделать в yaml.

Вариант выше для случаев, когда роль создаётся "сбоку", когда ей передаётся OIDC ID. Однако это значение ID такое же и для EKS API server endpoint, которое можено получить при создании кластера и тогда создание данной роли можно делать прямо при создании EKS кластера.

- Id: !Select [0, !Split ['.', !Select [1, !Split ['://', !GetAtt eksCluster.Endpoint]]]]

👉 пример фрагмента для EKS репозитории.

От EKS кластера получаем айдишник вида, https://1CF1A05E85DFDB5D489942FCC82AD99E.gr7.eu-west-1.eks.amazonaws.com, которому первым селектом (по "баяну" '://') отсекаем https://, а потом берём всё до первой точки. На выходе получаем то же значение, что и для OpenID!

#AMP

Amazon Managed Grafana (AMG) доступна в консоли:

https://aws.amazon.com/blogs/mt/amazon-managed-service-for-grafana-amg-preview-updated-with-new-capabilities/

Новые фичи AMG:

• доступен апгрейд до Enterprise версии
• Grafana version 7.5
• поддержка Open Distro for Elasticsearch

p.s. И ведь только вчера пожаловался, что нужно писать запрос и ждать, пока включат доступ к Preview. 😀 Очень хорошо, не нужно ничего писать — можно сразу пользоваться.

#AMG

AWS multi-account CI/CD with Gitlab runners

#aws #gitlab #terraform

Чтобы указать последнюю версию SSM Parameter в CloudFormation шаблоне — просто не указываем поле version:

version
If you do not specify the exact version, CloudFormation uses the latest version of the parameter whenever you create or update the stack.

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html#dynamic-references-ssm-pattern

#SSM #CloudFormation

Создание веб-сервера на AWS:

https://www.youtube.com/watch?v=9FKzLVdFfKo

#начинающим #video

Очистка S3 multipart uploads:

https://aws.amazon.com/blogs/aws-cost-management/discovering-and-deleting-incomplete-multipart-uploads-to-lower-amazon-s3-costs/

If the complete multipart upload request isn’t sent successfully, Amazon S3 will not assemble the parts and will not create any object. The parts remain in your Amazon S3 account until the multipart upload completes or is aborted, and you pay for the parts that are stored in Amazon S3.

#S3 #cost_optimization

Бесплатный курс на русском!!!

AWS Cloud Practitioner Essentials Day
вторник, 11 мая | 9am MSK (GMT+3)

На этом вебинаре вы ознакомитесь с концепциями облака AWS, сервисами, архитектурой, технологиями безопасности, ценами и условиями поддержки, чтобы расширить свои знания об облаке AWS.

Зарегистрироваться - https://pages.awscloud.com/EMEA-event-OE-CPE-May-11-2021-reg-event-RU.html?sc_channel=em&sc_campaign=Traincert_AlwaysOn_2021&sc_publisher=aws&sc_medium=em_AlwaysOnWebinars&sc_content=event_ev_field&sc_country=RUCIS&sc_geo=EMEA&sc_outcome=event&trkCampaign=EMEA-FY21-TrainCert-AlwaysOnWebinar_RU

Ваш первый проект будет легче запустить с бонусом в $300 долларов

Бесплатная программа AWS Proof of Concept предназначена для того, чтобы помочь вам воплотить ваши идеи в реальность, создав их пробные версии на платформе AWS.

Эксклюзивное предложение для предприятий малого и среднего бизнеса: наша программа поможет вам быстро начать работу на AWS, а также позволит воспользоваться рядом других преимуществ, включая бонусные суммы* от AWS в размере $300 долларов, доступ к бесплатным инструментам, ресурсам и многое другое.

Познакомьтесь с платформой AWS без каких-либо рисков и узнайте, как она может помочь вам решить ваши задачи в сфере бизнеса и ИТ.

Миллионы малых и средних предприятий уже используют облачные решения AWS для преображения своего бизнеса, привлечения новых клиентов, снижения операционных расходов и расширения своей деятельности. Поэтому подайте заявку на получение бонуса и подтвердите жизнеспособность своей идеи уже сегодня – мы уделим вам все внимание!
https://pages.awscloud.com/GLOBAL-acq-GC-New_Proof_of_Concept_UKIR-2021-reg.html?Languages=Russian

Прокидываем AWS Secrets в поды с помощью ASCP (AWS Secrets & Configuration Provider):

https://aws.amazon.com/blogs/security/how-to-use-aws-secrets-configuration-provider-with-kubernetes-secrets-store-csi-driver/

С помощью ASCP можно примонтировать AWS Secrets в под:

kind: Pod
apiVersion: v1
metadata:
name: nginx-secrets-store-inline
spec:
serviceAccountName: aws-node
containers:
- image: nginx
name: nginx
volumeMounts:
- name: MySecret2
mountPath: "/mnt/secrets-store"
readOnly: true
volumes:
- name: MySecret2
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: "aws-secrets"

Они могут ротироваться, динамически изменяясь внутри подов и могут применяться в деплойментах.

AWS Secrets можно синхронизировать с куберовскими секретами, на текущий момент поддерживаются следующие типы:

• opaque
• kubernetes.io/basic-auth
• bootstrap.kubernetes.io/token
• kubernetes.io/dockerconfigjson
• kubernetes.io/dockercfg
• kubernetes.io/ssh-auth
• kubernetes.io/service-account-token
• kubernetes.io/tls

#Secrets #EKS

Graviton 2 — переходим на светлую сторону, часть 1

Процессоры ARM уже не первый год на AWS, а теперь ещё и в Макбуках (которые тоже на AWS :) ). Многие наверняка слышали про них, но, как это часто бывает, придерживаются фразы "Ну, вот, скажи мне — где я, а где ARM?!?"

И действительно, мало выбрать новую виртуалку, нужно ж ещё и разбираться, что-то там пересобирать, а вдруг что не зарабоает, ну его нафиг, овчинка выделки не стоит.

Далее мой личный опыт и впечатления от работы c6g/m6g/t4g в, так сказать, "повседневной жизни" условного девопса или админа. Спойлер — овчинка стоит.

Возьмём популярный вариант — у вас что-то крутится в docker-compose, например, Node.js, Mongo или какой-нибудь Jenkins. Или даже возьмём всё вместе. Итак, что нужно будет сделать, чтобы пощупать гравитончик?

К примеру, у вас использовалась популярная виртуалка t3.medium. Значит для теста поднимаем t4g.medium - условный аналог на ARM.

Запустили, заходим, ставим докер привычным способом, например, для Amazon Linux 2:

yes | sudo amazon-linux-extras install docker

Docker поставили, пока никаких отличий.

Будем ставить docker-compose, гуглим и узнаём про первый облом ARM — а вот и нет такого:

https://github.com/docker/compose/issues/6831

Заходим, ставим лайк, чтобы таки когда-нибудь получить официальную версию. Но, понятно, проблема насущная и кто-то наверняка её решил. Всё верно, можно использовать докер для докера!

sudo curl -L --fail https://raw.githubusercontent.com/linuxserver/docker-docker-compose/master/run.sh -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

И получаем неофициальную, но вполне рабочую версию docker-compose под ARM.

Дальше проходимся по сервисам, которые у вас поднимаются в docker-compose. Если это что-то известное/популярное, например, упомянутые Node.js или Монга, то проблем, скорей всего, не будет – вообще ничего менять не придётся, т.к. у них вместе выложены докеры сразу под несколько платформ, в том числе под arm64. Оговорочку можно сделать лишь если у вас шибко старые версии, т.к. поддержка ARM появилась относительно недавно. Например, для Mongo версий 3.5 и древней поддержки ARM не будет, зато 3.6+ работает на ARM отлично.

Для не столь крупных проектов может не быть arm64 версий. Например, дефолтный репозиторий для Jenkins имеет образы лишь под amd64. Конечно, всегда можно пойти и собрать образ под arm64 самому, скачав исходники с GitHub. Это справедливо и для большого количества других open source проектов. Но погуглив часто можно найти готовое, в случае Jenkins это будет jenkins4eval/jenkins.

Для наглядности поставим популярные вещи под ARM — kubectl, eksctl, helm, kustomize:

curl -o https://amazon-eks.s3.us-west-2.amazonaws.com/1.19.6/2021-01-05/bin/linux/arm64/kubectl

curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_arm64.tar.gz" | tar xz

curl --silent --location https://get.helm.sh/helm-v3.5.4-linux-arm64.tar.gz | tar xz linux-arm64/helm

curl --silent --location https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v4.1.2/kustomize_v4.1.2_linux_arm64.tar.gz | tar xz

Если под ваш какой-то проект нет ARM-варианта — что ж, значит придётся обождать. Однако часто выясняется, что от чего-то можно безболезненно избавиться и всё же попробовать.

Отдельно скажу, что у вышеупомянутой неофициальной версии docker-compose под ARM есть некоторые проблемы — например, у меня с ней не заработал нормально jwilder/docker-gen для получения LetsEncrypt-овских сертификатов. Я не пробовал другие, используя сертификаты на ALB, однако возможность таких вещей стоит учесть. Но, всё же, в большинстве случаев (и точно, если это что-то популярное) никаких принципиальных моментов не возникает.

#ARM #Graviton

​​Houston, we have a problem the new AWS Local Zones!

Если вы зайдёте посмотреть стоимость виртуалок и обнаружите там регионы:

🔹 US East Boston
🔹 US East Houston
🔹 US East Miami
🔹 US East (Verizon) - Atlanta
🔹 US East (Verizon) - Boston
🔹 US East (Verizon) - Dallas
🔹 US East (Verizon) - Miami
🔹 US East (Verizon) - New York
🔹 US East (Verizon) - Washington DC
🔹 US West (Verizon) - Denver
🔹 US West (Verizon) - Las Vegas
🔹 US West (Verizon) - San Francisco Bay Area
🔹 US West (Verizon) - Seattle
🔹 Asia Pacific (KDDI) - Osaka
🔹 Asia Pacific (KDDI) - Tokyo
🔹 Asia Pacific (SKT) - Daejeon

То не пугайтесь. Это не регионы, это AWS Local Zones, которые теперь добавлены в список наряду с регионами (например, N.Virginia). Последние AWS Local Zones были анонсированы в декабре 2020-го года:

https://aws.amazon.com/blogs/aws/in-the-works-more-aws-local-zones/

Как видно, пока там выбор виртуалок небольшой (и дорого). Однако для бизнесов, желающих получить минимальный пинг (единицы миллисекунд) в данных городах (а это от AR/VR до рабочих столов с графикой/видео) ­­- отличная возможность получить максимум от AWS.

#LocalZones

Graviton 2 — переходим на светлую сторону, часть 2

Тесты ARM виртуалок в нагруженных приложениях не есть предмет данного поста - их можно найти в интернете или в официальном разделе:

https://aws.amazon.com/ec2/graviton/#Partner_Blogs

Здесь же, как было оглашено в первой части, рассмотрим "народные", то бишь популярные-недорогие типы виртуалок, обычно это 1-2 ядра и 1-4 ГБ памяти. В этой нише рулят Tx виртуалки — с поправкой на поколения это t2, t3, t3a и присоединившаяся к ним t4g на Graviton 2. Это так называемый burstable-тип виртуалок, которые не предназначены для постоянной нагрузки и производительность которых падает до своего baseline уровня, ежели "бурсты" иссякают.

Однако в эту нишу недорогих виртуалок Graviton 2 добавил не только t4g, под вышеприведенные правила 1-2 ядра и 1-4 ГБ памяти попадают и две "полноценные" виртуалки (которые не "burstable") - c6g.medium и m6g.medium! Да, у них по одному ядру, но, во-первых, очень многие системы прозябают с минимальной загрузкой в единицы процентов, а, во-вторых, если нагрузка вдруг станет постоянной, то baseline этих Tx виртуалок убьёт производительность двух ядер в 5-10 раз, что даст кратное преимущества "полноценным виртуалкам".

Сеть

Кроме того стоит добавить, что у "полноценных" виртуалок ещё и более быстрая сеть. У Tx типа это до 5 Gbit (если не считать старую t2, где аморфное Low to Moderate условно обозначает "до 1 Gbit"), в то время как у c6g/m6g это "до 10 Gbit". И это просто видно в обычной работе - привычные операции с копированием файлов на другие виртуалки/S3/итп банально на глаз быстрей. У кого много таких операций, сразу заметит, что работать стало комфортней.

И да, если уж про сеть, то правильно добавить ещё одну "полноценную" виртуалку, попадающую в наш диапазон: c6gn.medium, у которой сетка ещё более быстрая — до 25 Gbit!

Стоимость

Сведём всё в одну таблицу:

тип      цена   CPU   RAM сеть    baseline
t2.micro   $0.0116 1vCPU 1GB до 1 Gbit 10%
t2.small   $0.023  1vCPU 2GB до 1 Gbit 20%
t2.medium   $0.0464 2vCPU 4GB до 1 Gbit 20%
t3.micro   $0.0104 2vCPU 1GB до 5 Gbit 10%
t3.small   $0.0208 2vCPU 2GB до 5 Gbit 20%
t3.medium   $0.0416 2vCPU 4GB до 5 Gbit 20%
t3a.micro   $0.0094 2vCPU 1GB до 5 Gbit 10%
t3a.small   $0.0188 2vCPU 2GB до 5 Gbit 20%
t3a.medium $0.0376 2vCPU 4GB до 5 Gbit 20%
t4g.micro   $0.0084 2vCPU 1GB до 5 Gbit 10%
t4g.small   $0.0168 2vCPU 2GB до 5 Gbit 20%
t4g.medium  $0.0336 2vCPU 4GB до 5 Gbit 20%
c6g.medium  $0.034  1vCPU 2GB до 10Gbit 100%
m6g.medium  $0.0385 1vCPU 4GB до 10Gbit 100%
c6gn.medium $0.0432 1vCPU 2GB до 25Gbit 100%

Если отбросить морально устаревшие t2, которые дороже t3, а при этом медленней и отсортировать по возрастанию цены, то получаем следующую картину:

тип      цена   CPU   RAM сеть    baseline
t4g.micro   $0.0084 2vCPU 1GB до 5 Gbit 10%
t3a.micro   $0.0094 2vCPU 1GB до 5 Gbit 10%
t3.micro   $0.0104 2vCPU 1GB до 5 Gbit 10%
t4g.small   $0.0168 2vCPU 2GB до 5 Gbit 20%
t3a.small   $0.0188 2vCPU 2GB до 5 Gbit 20%
t3.small   $0.0208 2vCPU 2GB до 5 Gbit 20%
t4g.medium  $0.0336 2vCPU 4GB до 5 Gbit 20%
c6g.medium  $0.034  1vCPU 2GB до 10Gbit 100%
t3a.medium  $0.0376 2vCPU 4GB до 5 Gbit 20%
m6g.medium  $0.0385 1vCPU 4GB до 10Gbit 100%
t3.medium   $0.0416 2vCPU 4GB до 5 Gbit 20%
c6gn.medium $0.0432 1vCPU 2GB до 25Gbit 100%

Очень показателен нижний сегмент, где "полноценные" виртуалки расположились не равномерно внизу, как можно было бы предположить, а вполне себе тягаются с дешёвыми Tx!

Выводы

👉 Graviton 2 хорош. Не верьте на слово — попробуйте. Сделать это для простых вещей если не совсем просто, то точно не так сложно.

👉 Graviton 2 добавил в список "народных виртуалок" две полноценные и конкурентно недорогие виртуалки c6g.medium и m6g.medium. И если вы, как и я, раньше держали свои популярные повседневные вещи на t3/t3a small/medium, то очень стоит попробовать c6g.medium и m6g.medium. Я перевёл несколько проектов на оные и теперь радуюсь — как скорости работы, так и прайсу!

#ARM #Graviton