Каждая новая версия приложения генерит логи, объём которых удваивается каждый день и которые полностью заполняют ES объёмом 900 ГБ за 90 дней.
Сколько дней потребуется новой версии для заполнения ES объёмом 450ГБ?
Сколько дней потребуется новой версии для заполнения ES объёмом 450ГБ?
Anonymous Quiz
12%
39
21%
45
6%
60
62%
89
Slack: Customers may have trouble loading channels or connecting to Slack at this time.
https://status.slack.com/2021-01/9ecc1bc75347b6d1
https://status.slack.com/2021-01/9ecc1bc75347b6d1
Slack
Slack System Status
Resources for real-time and historical information about the Slack service.
В реальности много что упало, не только Slack. У меня iCloud работает почти нет.
https://downdetector.com/
https://downdetector.com/
Forwarded from Записки админа
⚙️ Не спите ещё? Тут кажется ещё одна рассылка намечается интересная. На этот раз по теме AWS. Предлагаю последить, вдруг что-то хорошее их этого выйдет - AWS Security Digest. AWS Security Digest Weekly Newsletter. #aws #security #напочитать
В документе AWS Service Terms в пункте
...we may store such AI Content in an AWS region outside of the AWS region where you are using such AI Service...
То бишь, ежели вы используете AI сервисы, то их данные могут быть сохранены вне региона, где вы работаете, что может нарушить compliance требования и про что хотя бы нужно знать.
На текущий момент AI сервисы это следующий список:
🔹 Amazon CodeGuru Profiler
🔹 Amazon CodeGuru Reviewer
🔹 Amazon Comprehend
🔹 Amazon Comprehend Medical
🔹 Amazon DevOps Guru
🔹 Amazon Forecast
🔹 Amazon HealthLake
🔹 Amazon Kendra
🔹 Amazon Lex
🔹 Amazon Lookout for Metrics
🔹 Amazon Personalize
🔹 Amazon Polly
🔹 Amazon Rekognition
🔹 Amazon Textract
🔹 Amazon Transcribe
🔹 Amazon Transcribe Medical
🔹 Amazon Translate
Амазону можно запретить использовать данные AI сервисов для улучшения их качества:
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out.html
Для этого нужно выполнить в management (главном) аккаунте специальные команды, которые добавят политики запрета к организации.
Про всё это и как такое сделать — в блоге крутейшего безопасника по AWS, Scott Piper:
https://summitroute.com/blog/2021/01/06/opting_out_of_aws_ai_data_usage/
В общем, всё как обычно — стоит читать мелкий шрифт в лицензионных соглашениях. 😀
#security
50.3 есть такая строчка:...we may store such AI Content in an AWS region outside of the AWS region where you are using such AI Service...
То бишь, ежели вы используете AI сервисы, то их данные могут быть сохранены вне региона, где вы работаете, что может нарушить compliance требования и про что хотя бы нужно знать.
На текущий момент AI сервисы это следующий список:
🔹 Amazon CodeGuru Profiler
🔹 Amazon CodeGuru Reviewer
🔹 Amazon Comprehend
🔹 Amazon Comprehend Medical
🔹 Amazon DevOps Guru
🔹 Amazon Forecast
🔹 Amazon HealthLake
🔹 Amazon Kendra
🔹 Amazon Lex
🔹 Amazon Lookout for Metrics
🔹 Amazon Personalize
🔹 Amazon Polly
🔹 Amazon Rekognition
🔹 Amazon Textract
🔹 Amazon Transcribe
🔹 Amazon Transcribe Medical
🔹 Amazon Translate
Амазону можно запретить использовать данные AI сервисов для улучшения их качества:
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out.html
Для этого нужно выполнить в management (главном) аккаунте специальные команды, которые добавят политики запрета к организации.
Про всё это и как такое сделать — в блоге крутейшего безопасника по AWS, Scott Piper:
https://summitroute.com/blog/2021/01/06/opting_out_of_aws_ai_data_usage/
В общем, всё как обычно — стоит читать мелкий шрифт в лицензионных соглашениях. 😀
#security
EC2 виртуалки — выбираем регион в Европе
На текущий момент в Европе уже есть 6 действующих регионов, а вскоре прибавется ещё парочка. Когда стоит вопрос о выборе региона, где размещать окружение, то обычно выбирают тот, который привычен. Исторически первым была Ирландия, после Франкфурт. Потому многие в наших широтах используют один из этих регионов, поднимая во Франкфурте, чтобы было "географически поближе" - пинг получше.
Однако ситуация меняется. На собственном опыте могу сказать, что появившийся два года назад Стокгольм давал пинг из Минска хуже, чем до привычного Франкфурта. Однако на текущий момент положение сильно изменилась — он теперь для меня однозначно лучший по пингу (в среднем на пару десятков процентов по сравнению следующим за ним Франкфуртом).
https://www.cloudping.info/
Вот характерная картинка, сделана прямо сейчас при написании поста, отражает обычный расклад (из Минска):
Вообще регионы по пингу подравнялись, частенько Париж и Лондон могут быть лучше Франкфурта. Потому у кого проекты локальные, т.е. не глобальные и нужно побыстрей из своей локации — стоит потестировать, прежние представления могут быть не верны.
Стоимость EC2
Однако есть ещё и стоимостной момент. Разброс цен на EC2 виртуалки есть и в купе с пингом вполне может заставить по-другому смотреть на выбор региона. Если взять Ирландию как 100% цены, то на текущий момент получается следующая картина:
Самый дорогой Франкфурт! Не знали, да? Я вот помнил, что он дорогой, однако уже подзабыл и считал самым дорогим недавно появившийся Милан. А вот и нет.
Однако интересно отметить относительно дешёвый Стокгольм. В случае Минска получается и дешевле и быстрей — хороший повод подумать. Особенно, если сидите во Фракфурте, то получаете при переезде в Стокгольм -10% в ценнике и при этом быстрей!
https://aws.amazon.com/ec2/pricing/on-demand/
Короче, всё течёт, всё меняется. И появляется повод сэкономить и ускориться!
#AWS_Region #cost_optimization #EC2
На текущий момент в Европе уже есть 6 действующих регионов, а вскоре прибавется ещё парочка. Когда стоит вопрос о выборе региона, где размещать окружение, то обычно выбирают тот, который привычен. Исторически первым была Ирландия, после Франкфурт. Потому многие в наших широтах используют один из этих регионов, поднимая во Франкфурте, чтобы было "географически поближе" - пинг получше.
Однако ситуация меняется. На собственном опыте могу сказать, что появившийся два года назад Стокгольм давал пинг из Минска хуже, чем до привычного Франкфурта. Однако на текущий момент положение сильно изменилась — он теперь для меня однозначно лучший по пингу (в среднем на пару десятков процентов по сравнению следующим за ним Франкфуртом).
https://www.cloudping.info/
Вот характерная картинка, сделана прямо сейчас при написании поста, отражает обычный расклад (из Минска):
Ireland 67 msLondon 49 msFrankfurt 46 msParis 57 msStockholm 34 msВообще регионы по пингу подравнялись, частенько Париж и Лондон могут быть лучше Франкфурта. Потому у кого проекты локальные, т.е. не глобальные и нужно побыстрей из своей локации — стоит потестировать, прежние представления могут быть не верны.
Стоимость EC2
Однако есть ещё и стоимостной момент. Разброс цен на EC2 виртуалки есть и в купе с пингом вполне может заставить по-другому смотреть на выбор региона. Если взять Ирландию как 100% цены, то на текущий момент получается следующая картина:
Stockholm 94.7%Ireland 100.0%London 103.5%Paris 103.5%Milan 105.0%Frankfurt 105.3%Самый дорогой Франкфурт! Не знали, да? Я вот помнил, что он дорогой, однако уже подзабыл и считал самым дорогим недавно появившийся Милан. А вот и нет.
Однако интересно отметить относительно дешёвый Стокгольм. В случае Минска получается и дешевле и быстрей — хороший повод подумать. Особенно, если сидите во Фракфурте, то получаете при переезде в Стокгольм -10% в ценнике и при этом быстрей!
https://aws.amazon.com/ec2/pricing/on-demand/
Короче, всё течёт, всё меняется. И появляется повод сэкономить и ускориться!
#AWS_Region #cost_optimization #EC2
CloudFormation vs Terraform
Впервые за время с появления Terraform, команда CloudFormation обогнала по количеству поддерживаемых ресурсов (664 ресурса) команду Terraform (654 ресурса).
Сверху — за последнее время, снизу — за всё время.
И вновь продолжается бой!
Первоисточник:
https://twitter.com/iann0036/status/1347381025723203585
#CloudFormation #Terraform
Впервые за время с появления Terraform, команда CloudFormation обогнала по количеству поддерживаемых ресурсов (664 ресурса) команду Terraform (654 ресурса).
Сверху — за последнее время, снизу — за всё время.
И вновь продолжается бой!
Первоисточник:
https://twitter.com/iann0036/status/1347381025723203585
#CloudFormation #Terraform
Forwarded from CloudTechRU
Забирайте бесплатный курс "Terraform - From Zero to Certified Professional. HashiCorp Certified: Terraform Associate and much more" от Дениса Астахова.
На русском у Дениса лучше выходит. Это как сериалы в переводе Кураж Бомбей смотреть, когда перевод лучше оригинала )
Ссылка доступна 3 дня.
https://www.udemy.com/course/terraformcertified/?couponCode=TERRAFORM-ON-ENGLISH
На русском у Дениса лучше выходит. Это как сериалы в переводе Кураж Бомбей смотреть, когда перевод лучше оригинала )
Ссылка доступна 3 дня.
https://www.udemy.com/course/terraformcertified/?couponCode=TERRAFORM-ON-ENGLISH
Udemy
Terraform - From Zero to Certified Professional
2023 HashiCorp Certified: Terraform Associate and much more
Forwarded from Человек и машина
#машины_aws
Ваше выходное чтиво - третья глава по DynamoDB.
В этой части: что такое консистентность, почему ее так тяжело достичь и как воспроизвести в DynamoDB, как отлавливать изменения данных, а также особенности кеширования с использованием DAX и построение гео-распределенных таблиц.
Ваше выходное чтиво - третья глава по DynamoDB.
В этой части: что такое консистентность, почему ее так тяжело достичь и как воспроизвести в DynamoDB, как отлавливать изменения данных, а также особенности кеширования с использованием DAX и построение гео-распределенных таблиц.
Medium
Amazon DynamoDB Deep Dive. Chapter 3: Consistency, DynamoDB streams, TTL, Global tables, DAX
The story of one of the world’s fastest database in a human-friendly format
Хорошее место для знакомства, проверки и углубления своих знаний по CloudFormation:
https://scaleyourcloudformation.com/
Фичи, популярные заблуждения и ошибки, проблемы и места скопления бесплатных шаблонов. Советую.
#CloudFormation
https://scaleyourcloudformation.com/
Фичи, популярные заблуждения и ошибки, проблемы и места скопления бесплатных шаблонов. Советую.
#CloudFormation
Scaleyourcloudformation
Scale Your CloudFormation
Success tactics for getting more out of Infrastructure as Code on AWS
Forwarded from запуск завтра
Супер история о том, как Амазон чуть не умер и переехал с серверов Sun на Linux. Это — история зарождения Amazon Web Services — облака, на котором сегодня работает добрая половина интернета.
Рассказывает один из непосредственных участников.
Самые впечатляющие моменты:
❧ в 2000 лопнул пузырь доткомов — технические компании обесценились в сотни раз, на фондовом рынке кончились деньги и Amazon начал жечь собственные средства — 1 миллиард долларов в год; самой крупной статьей расходов были серверы — их делал Sun, они стоили дорого;
❧ можно было перекупить серверы Sun у компаний, обанкротившихся на пузыре доткомов, но техдир Амазона пошел ва-банк — решил переехать с Sun на обычное железо Hewlett Packard на Линуксе; ядру лунукса тогда было всего 6 лет;
❧ на время переезда они остановили ВСЮ продуктовую разработку! ВСЕ занимались только переездом. В бэклоге лежали сотни функций для увеличения продаж, но все ждали, пока закончится переезд;
❧ заморозка развития сервиса привела к падению продаж → пришлось повышать цены на товары → продажи упали ещё сильнее, запустилась «спираль смерти»;
❧ у Амазона оставалось буквально несколько кварталов до смерти, когда деньги на счету кончатся, но они успели и запустили всё нормально, стоимость масштабирования инфраструктуры упала на 80%;
❧ продажи — сезонный бизнес и Безос придумал, почему бы не сдавать простаивающие серверы в низкий сезон другим компаниям? На презентации он привел аналогию с электрической сетью — в 1900 годы каждый завод строил свою собственную электростанцию, почему бы не сделать «электрическую сеть» для IT? Плюс это круто сочеталось с его идеей разделить команды внутри компании, чтобы команды могли развиваться самостоятельно — каждая команда стала независимым API.
Ну а дальше вы знаете. Сегодня Амазон — это не только интернет-магазин, но и одна из крупнейших IT компаний планеты.
https://twitter.com/DanRose999/status/1347677573900242944
Рассказывает один из непосредственных участников.
Самые впечатляющие моменты:
❧ в 2000 лопнул пузырь доткомов — технические компании обесценились в сотни раз, на фондовом рынке кончились деньги и Amazon начал жечь собственные средства — 1 миллиард долларов в год; самой крупной статьей расходов были серверы — их делал Sun, они стоили дорого;
❧ можно было перекупить серверы Sun у компаний, обанкротившихся на пузыре доткомов, но техдир Амазона пошел ва-банк — решил переехать с Sun на обычное железо Hewlett Packard на Линуксе; ядру лунукса тогда было всего 6 лет;
❧ на время переезда они остановили ВСЮ продуктовую разработку! ВСЕ занимались только переездом. В бэклоге лежали сотни функций для увеличения продаж, но все ждали, пока закончится переезд;
❧ заморозка развития сервиса привела к падению продаж → пришлось повышать цены на товары → продажи упали ещё сильнее, запустилась «спираль смерти»;
❧ у Амазона оставалось буквально несколько кварталов до смерти, когда деньги на счету кончатся, но они успели и запустили всё нормально, стоимость масштабирования инфраструктуры упала на 80%;
❧ продажи — сезонный бизнес и Безос придумал, почему бы не сдавать простаивающие серверы в низкий сезон другим компаниям? На презентации он привел аналогию с электрической сетью — в 1900 годы каждый завод строил свою собственную электростанцию, почему бы не сделать «электрическую сеть» для IT? Плюс это круто сочеталось с его идеей разделить команды внутри компании, чтобы команды могли развиваться самостоятельно — каждая команда стала независимым API.
Ну а дальше вы знаете. Сегодня Амазон — это не только интернет-магазин, но и одна из крупнейших IT компаний планеты.
https://twitter.com/DanRose999/status/1347677573900242944
Forwarded from Devops Talks (Alex 🎲 Green)
the IAM and RBAC terminology resource - понятное объяснение таких вещей как AWS Identity and Access Management (IAM) и Kubernetes Role-based Access Control (RBAC) с примерами.
https://mhausenblas.info/rbIAM/terminology/
https://mhausenblas.info/rbIAM/terminology/
mhausenblas.info
Terminology - rbIAM
Unified AWS IAM & Kubernetes RBAC access control
Forwarded from Sysadmin Tools 🇺🇦
A how to for setting up Kubernetes to use AWS EC2 spot instances to reduce cost and maintain a zero-downtime cluster as instances come and go.
https://medium.com/riskified-technology/run-kubernetes-on-aws-ec2-spot-instances-with-zero-downtime-f7327a95dea
#k8s #kubernetes #aws
https://medium.com/riskified-technology/run-kubernetes-on-aws-ec2-spot-instances-with-zero-downtime-f7327a95dea
#k8s #kubernetes #aws
Medium
Run Kubernetes on AWS EC2 Spot Instances With Zero Downtime
A Complete Guide of running all your k8s environments with Spot Instances
Forwarded from CloudSec Wine
🔸AWS Lambda $LATEST is dangerous
You should always use function versioning. You should almost always use function aliases, which have a handful of benefits involving metrics in CloudWatch, IAM permissions, traffic-shifting, etc.
https://awsteele.com/blog/2020/12/24/aws-lambda-latest-is-dangerous.html
#aws
You should always use function versioning. You should almost always use function aliases, which have a handful of benefits involving metrics in CloudWatch, IAM permissions, traffic-shifting, etc.
https://awsteele.com/blog/2020/12/24/aws-lambda-latest-is-dangerous.html
#aws
Aidan Steele’s blog (usually about AWS)
AWS Lambda $LATEST is dangerous
AWS Lambda has supported function versions since October 2015, only a couple of months after the service itself was publicly launched. Versions are an optional feature - you can develop and use Lambda functions without versioning, in which case you are working…
Как сделать дешёвый и практичный сайт для фотохостинга:
https://manbehindlens.com/how_is_made.html
#Amplify
https://manbehindlens.com/how_is_made.html
#Amplify
Manbehindlens
ManBehindLens.com | How less than a cup of coffee per month photo sharing website is made
ManBehindLens.com is a static website to share publicly my pictures
Лучшие практики по AWS безопасности от Scott Piper:
https://summitroute.com/downloads/aws_security_maturity_roadmap-Summit_Route.pdf
#security
https://summitroute.com/downloads/aws_security_maturity_roadmap-Summit_Route.pdf
#security
Интересный инструмент для конвертации on-demand виртуалок в spot и обратно:
https://github.com/jcjorel/ec2-spot-converter
#spot
https://github.com/jcjorel/ec2-spot-converter
#spot
GitHub
GitHub - jcjorel/ec2-spot-converter: A tool to convert AWS EC2 instances back and forth between On-Demand and Spot billing models.
A tool to convert AWS EC2 instances back and forth between On-Demand and Spot billing models. - jcjorel/ec2-spot-converter