Понятно, что у AWS есть специальные алерты и ограничения бюджета на такой случай, вроде AWS Cost Anomaly Detection, но они появились только недавно, и не все о них знают.
Это не так. Упомянутые "ограничения бюджета", видимо подразумевают AWS Budgets, и данный сервис появился давно:
Это не так. Поддержка AWS всегда старается помочь пользователям (с любыми суммами - для кого-то и сотня это много) и помогает им с проблемами, даже когда они забывают что-то выключить, а не будучи взломанными, как в данном случае.
В комментариях пользователи рассказывают про свои случаи, когда им были "прощены" проблематичные биллинги. В частности, анализ данного случая и популярные проблемы с биллингом AWS можно почитать здесь:
Также много лет использовал 3 монитора 16:10 24" в горизонтальных и портретном режиме. Тоже придерживался подобной аргументаций и пару лет назад отказался от 27" по тем же «забольшой» и «вертеть головой».
Но вот недавно решился на радикальные 43" 3840×2160 в качестве основного монитора. Основной проблемой-ограничением оказалось рабочее место — нужен банально широкий и достаточно большой в глубину (чтобы отодвинуть монитор дальше привычного, увеличив масштаб).
Про «вертеть головой» забылось на следующий день. Сейчас лишь жалею, что не взял изогнутый — теперь понимаю, что это такие же предрассудки, которые развеваются через пару дней реального использования, когда представить возвращение к предыдущему «мелкоскопу» нереально.
Скромный вывод и совет от похожего по тону консерватора — попробуйте, не знаю как, но попробуйте пару дней поработать. Всё не так, как кажется.
Если точнее, то BIOS-ы того времени представляли собой целые костылехранилища с правками для кучи всякого железа, что было завязано на BIOS (читай — всё).
Absolute Software предлагает различные методы защиты от угона. В частности, её клиент должен периодически регистрироваться на её сервере, иначе ноутбук считается угнанным — типа работая локально (это сейчас кажется нелепым, но технология старая и тогда такое — чисто локальная работа — было актуально), в результате через некоторое время он блокируется.
Раз уж стюардессу снова откопали, то внесу несколько пояснений.
Я не знаю почему в панели управления Intel нет такого набора функций, но факт есть факт: Ylian Saint-Hilaire берет от жизни ощутимо больше.
Это дефолтный клиент из прошлого, а «нормальный» для Интел как раз и разрабатывает Ylian Saint-Hilaire.
Само по себе однозначное наличие доступа к машине, если она подключена по кабелю, либо, если на ней установлен Windows, то и по WiFi.
Если опустить детали, то к моему, когда-то в далёком прошлом, большому сожалению, получим следующие уточнения в этом месте. А конкретно правильно будет «наличие доступа к машине, если она подключена по кабелю» (то есть у неё есть Ethernet — читай, это десктоп) и если это, всё же, ноутбук, то плюс, что «он подключён к питанию».
Не выяснено, работает ли она на SSD отличных от Intel.
Только Intel и только серии Pro (типа Pro 2500 или Pro 1500).
Остается нерешенной проблема отложенного выполнения, иными словами: нужно караулить когда машина войдет в сеть чтобы выполнить к ней подключение. Полагаю, что этому тоже есть какое-то решение.
Есть. Можно специальным образом настроить периодическое соединение и тогда при появлении интернета вы сразу же про это узнаете.
Говорю так уверенно, потому что был причастен к Intel AMT проекту в начале десятых, где из описанного (и не описанного) Вами многое было сделано, причём в облачном (AWS) исполнении. Условно говоря, Meshcentral сервер для управления автоматически поднимался на ближайшей к вашей локации виртуалке для лучшего пинга управления (Вы же уже отметили неприятность и важность лага при работе в CIRA-режимие?) Но если отбросить ностальгические сопли, Интел выбрал то, что вы описали в своей статье, а не то, что у нас было 8 лет назад.
Почему? Во-первых, потому что попытка монетизации Intel AMT провалилась (внутри этой сухой фразы в реальности целый детектив, но это другая история и важно, что внутри компании Intel это расценили именно так). Она была сделана с выходом AMT 4, где и появился CIRA режим с работой через Intel MPS (интеловский вариант Meshcentral) и окончательно похоронена начиная с AMT 7. После была предпринята ещё попытка какого-то коммерческого использования в виде Intel SMB (AMT 8), но факт — направление было признано бесперспективным (нельзя монетизировать), а потому закрыть. Точней — лишь поддержка (то, что делает Ylian).
Во-вторых, тогда ещё не знали, что внутри Интел уже принято решение по закрытию их Atom архитектуры и полному отказу от борьбы на рынке мобильников (помните Asus Zenphone?), что сильно сужало процент систем, потенциально поддерживающих Intel vPro (а планы поддержки Intel vPro а значит, возможно, после и Intel AMT — в Intel Atom были), в то время как поддержка Intel vPro это 1-2% от общего количества Intel чипсетов на 10 лет назад.
Ну, а через несколько лет в брошенной технологии поковырялись монстры из PositiveTechnologies со всем известным результатом. То, что десять лет назад могло быть суперовской вещью (ведь описанное в статье работало уже десять лет назад в точности также) — было закрыто. Как много других проектов Intel — не только в Google есть своё кладбище оных, даже как-то вёл список, но забросил, слишком уж их много оказалось.
Грустно наблюдать, когда стандартный функционал разработки пятнадцатилетней давности вдруг обнаруживается в заголовках с фразами «удалось обнаружить» и «высококвалифицированных подразделений киберразведки».
Переход на UEFI в течение десяти лет со времени оглашения Intel «всеобщей ефизации морально устревшего BIOS» — Вы считаете, отражает выражение «всех обрадовал»?
Хороший ответ и вполне характерный набор используемых Amazon AWS сервисов. Можно даже сказать классический. Как раз в том числе для обладателей подобной инфраструктуры данная статья — повод задуматься, а после спланировать и ввести преобразования. Перечисленный набор для обеспечения эффективного DevOps-процесса почти всегда дополняет:
CodeCommit
CodePipeline
Lambda
Если проект не заморожен, а развивается — удобно (и правильно) подключать различные сервисы через APIGateway. При этом цель не задействовать максимум сервисов Amazon AWS. Просто грамотное проектирование подразумевает microservises/serverless архитектуру, что как раз подразумевается и реализуется через максимальное задействование AWS-сервисов.
С другой стороны, понятно, если у вас «все процессы на своём и давно отлажены» или же «проект сделан и работает» — то внедрение таких практик (как описаны в статье — использование Code-сервисов Amazon AWS) от затратно до бессмысленно.
Равно как и справедливо было сказано про распространённое заблуждение, когда пытаются оценить «решения Амазона» с точки зрения стоимости виртуалок. Как простой довод я обычно привожу следующий факт. Например, из ваших расчётов один из значимых параметров — это стоимость аренды мощных виртуалок типа m4.4xlarge, которые идут по $0.862 за час. В то время как это «обычная» цена. Есть скидка, которая может быть получена при аренде на год или три — она может составлять десятки процентов, но подобные скидки есть у всех. Однако редко кто говорит про Spot-виртуалки, в то время, как их стоимость в разы меньше. Например, за эти же m4.4xlarge-виртуалки на данный момент можно платить в 4 раза дешевле!
Согласитесь, калькуляция при таком раскладе резко изменится.
В качестве примера могу сказать, что достаточно популярный Битрикс24 в своей работе использует как раз такие Spot-instances. Да, они имеют некоторые особенности, которые должны быть учтены (и заложены в архитектуру) и те же Битрикс24, в случае отсутствия в нужный момент Spot-виртуалок — поднимают обычные (дорогие). Но при первой возможности они их убивают и снова пользуются дешёвыми. Что при грамотной реализации кластерной системы работы им даёт и надёжность, и весьма существенную экономию.
Всё же стоит уточнить, что «кратковременный boost», применительно для указанных — это 5.4 часов в сутки, что отлично подходит большинству «обычных» задач. Вы правильно добавили про «нюансы Google», лишний раз подтвердив, скажем дипломатично, «сложность сравнения» даже выраженной в конкретных цифрах стоимости аренды, не говоря уже про всё остальное (что, всё же, важней — если не рассматривать облака как «просто хостинг»).
В статье используется термин «обычный пользователь», тогда в случае Amazon AWS я бы рекомендовал инстанс t2.xlarge с такими же характеристиками (4 ядра, 16 ГБ памяти) за $0.257 (x64/Windows/Frankfurt). Да, у него есть моменты (особенности инстансов линейки T2), но стоимость и «настоящие» четыре ядра (не гипертрейдинг), предположу, поставили бы его на первое место в ваших тестах (по скорости, не говоря уже о стоимости).
Рассматривать (равно как и сравнивать) облака по производительности, которая (сильно) зависит от настройки и конкретных целей использования — весьма бесперспективное занятие. И, да, ценовая политика ещё более всё путает — кроме упомянутых Reserved Instance вы же не сравнивали Spot-инстансы, которые конкретно на данный момент для тестируемых вами m4.xlarge стоят:
Это не умаляет ваших тестов, все делают подобную ошибку, пытаясь разобраться «а что же лучше/выгодней». Лишь после, с опытом, приходит понимание, что, оказывается, производительность и «выгодность» — это вторично, а первична экосистема предлагаемых провайдером сервисов, их законченность, интеграция в ваши процессы, удобность поддержки и эксплуатации.
наличие такой дыры делает очень вероятным наличие других дыр
Наличие «такой дыры» обозначает всего лишь недостаточное тестирование. А недостаточное тестирование обозначает то, что технология AMT, выражаясь дипломатично, не является «приоритетным направлением» для Intel и давно.
грустная история
Эта тема — Intel AMT зарождение, распил расцвет и осиновый кол под номером CVE-2017-5689 закат — вообще, грустная история, достойная отдельной статьи, постараюсь написать, когда будет совсем плохо.
Немного про «эксплуатация этой дыры». Intel AMT в общем случае подразумевает корпоративный сегмент — защищённая от посторонних локальная сеть, политики безопасности и т.п. При их несоблюдении, вам, действительно, в каком-то интернет-кафе шутники запросто смогут вероломно выключить/включить/перезагрузить АМТ-систему. Однако на этом длинный список ваших неприятностей обычно заканчивается и его сложно выделить на фоне белого шума всех других уязвимостей, которые возникают каждый день. Это никак не попытка замазать грубую, имеющую место, ошибку, однако с учётом многолетнего опыта работы с Intel AMT, я относился бы к таким потенциальным взломщикам даже с некоторой долей сочувствия — хорошо понимая, через что им пришлось пройти, чтобы нагло перезагрузить ваш ноутбук.
Касаемо же фобии Intel ME — это ещё одна отдельная больш(н)ая тема, в большей степени имеющая не техническую основу, а психологическую.
Это не так. Упомянутые "ограничения бюджета", видимо подразумевают AWS Budgets, и данный сервис появился давно:
https://aws.amazon.com/about-aws/whats-new/2015/06/aws-introduces-budgets-a-simple-way-to-manage-your-aws-costs/
Упомянутый сервис AWS Cost Anomaly Detection, использующий ML/AI, действительно, появился относительно недавно.
Это не так. Поддержка AWS всегда старается помочь пользователям (с любыми суммами - для кого-то и сотня это много) и помогает им с проблемами, даже когда они забывают что-то выключить, а не будучи взломанными, как в данном случае.
Например, можно почитать здесь:
https://twitter.com/__steele/status/1218453873834086401
В комментариях пользователи рассказывают про свои случаи, когда им были "прощены" проблематичные биллинги. В частности, анализ данного случая и популярные проблемы с биллингом AWS можно почитать здесь:
https://t.me/aws_notes/473
Спасибо за публикацию полезнейшей статистики по такой важной теме.
aws.amazon.com/ru/premiumsupport/knowledge-center/ec2-server-refused-our-key
Посекундно:
RDS — Amazon RDS now supports per-second billing
ECS Fargate — vCPU and memory resources are calculated from the time your container images are pulled until the Amazon ECS Task* terminates, rounded up to the nearest second.
aws.amazon.com/blogs/security/post-quantum-tls-now-supported-in-aws-kms
Но вот недавно решился на радикальные 43" 3840×2160 в качестве основного монитора. Основной проблемой-ограничением оказалось рабочее место — нужен банально широкий и достаточно большой в глубину (чтобы отодвинуть монитор дальше привычного, увеличив масштаб).
Про «вертеть головой» забылось на следующий день. Сейчас лишь жалею, что не взял изогнутый — теперь понимаю, что это такие же предрассудки, которые развеваются через пару дней реального использования, когда представить возвращение к предыдущему «мелкоскопу» нереально.
Скромный вывод и совет от похожего по тону консерватора — попробуйте, не знаю как, но попробуйте пару дней поработать. Всё не так, как кажется.
Вы в слове «забота» сделали девять ошибок.
Intel® Remote Secure Erase Yes
Это дефолтный клиент из прошлого, а «нормальный» для Интел как раз и разрабатывает Ylian Saint-Hilaire.
Если опустить детали, то к моему, когда-то в далёком прошлом, большому сожалению, получим следующие уточнения в этом месте. А конкретно правильно будет «наличие доступа к машине, если она подключена по кабелю» (то есть у неё есть Ethernet — читай, это десктоп) и если это, всё же, ноутбук, то плюс, что «он подключён к питанию».
Только Intel и только серии Pro (типа Pro 2500 или Pro 1500).
Есть. Можно специальным образом настроить периодическое соединение и тогда при появлении интернета вы сразу же про это узнаете.
Говорю так уверенно, потому что был причастен к Intel AMT проекту в начале десятых, где из описанного (и не описанного) Вами многое было сделано, причём в облачном (AWS) исполнении. Условно говоря, Meshcentral сервер для управления автоматически поднимался на ближайшей к вашей локации виртуалке для лучшего пинга управления (Вы же уже отметили неприятность и важность лага при работе в CIRA-режимие?) Но если отбросить ностальгические сопли, Интел выбрал то, что вы описали в своей статье, а не то, что у нас было 8 лет назад.
Почему? Во-первых, потому что попытка монетизации Intel AMT провалилась (внутри этой сухой фразы в реальности целый детектив, но это другая история и важно, что внутри компании Intel это расценили именно так). Она была сделана с выходом AMT 4, где и появился CIRA режим с работой через Intel MPS (интеловский вариант Meshcentral) и окончательно похоронена начиная с AMT 7. После была предпринята ещё попытка какого-то коммерческого использования в виде Intel SMB (AMT 8), но факт — направление было признано бесперспективным (нельзя монетизировать), а потому закрыть. Точней — лишь поддержка (то, что делает Ylian).
Во-вторых, тогда ещё не знали, что внутри Интел уже принято решение по закрытию их Atom архитектуры и полному отказу от борьбы на рынке мобильников (помните Asus Zenphone?), что сильно сужало процент систем, потенциально поддерживающих Intel vPro (а планы поддержки Intel vPro а значит, возможно, после и Intel AMT — в Intel Atom были), в то время как поддержка Intel vPro это 1-2% от общего количества Intel чипсетов на 10 лет назад.
Ну, а через несколько лет в брошенной технологии поковырялись монстры из PositiveTechnologies со всем известным результатом. То, что десять лет назад могло быть суперовской вещью (ведь описанное в статье работало уже десять лет назад в точности также) — было закрыто. Как много других проектов Intel — не только в Google есть своё кладбище оных, даже как-то вёл список, но забросил, слишком уж их много оказалось.
Если проект не заморожен, а развивается — удобно (и правильно) подключать различные сервисы через APIGateway. При этом цель не задействовать максимум сервисов Amazon AWS. Просто грамотное проектирование подразумевает microservises/serverless архитектуру, что как раз подразумевается и реализуется через максимальное задействование AWS-сервисов.
С другой стороны, понятно, если у вас «все процессы на своём и давно отлажены» или же «проект сделан и работает» — то внедрение таких практик (как описаны в статье — использование Code-сервисов Amazon AWS) от затратно до бессмысленно.
Равно как и справедливо было сказано про распространённое заблуждение, когда пытаются оценить «решения Амазона» с точки зрения стоимости виртуалок. Как простой довод я обычно привожу следующий факт. Например, из ваших расчётов один из значимых параметров — это стоимость аренды мощных виртуалок типа m4.4xlarge, которые идут по $0.862 за час. В то время как это «обычная» цена. Есть скидка, которая может быть получена при аренде на год или три — она может составлять десятки процентов, но подобные скидки есть у всех. Однако редко кто говорит про Spot-виртуалки, в то время, как их стоимость в разы меньше. Например, за эти же m4.4xlarge-виртуалки на данный момент можно платить в 4 раза дешевле!
Согласитесь, калькуляция при таком раскладе резко изменится.
В качестве примера могу сказать, что достаточно популярный Битрикс24 в своей работе использует как раз такие Spot-instances. Да, они имеют некоторые особенности, которые должны быть учтены (и заложены в архитектуру) и те же Битрикс24, в случае отсутствия в нужный момент Spot-виртуалок — поднимают обычные (дорогие). Но при первой возможности они их убивают и снова пользуются дешёвыми. Что при грамотной реализации кластерной системы работы им даёт и надёжность, и весьма существенную экономию.
Рассматривать (равно как и сравнивать) облака по производительности, которая (сильно) зависит от настройки и конкретных целей использования — весьма бесперспективное занятие. И, да, ценовая политика ещё более всё путает — кроме упомянутых Reserved Instance вы же не сравнивали Spot-инстансы, которые конкретно на данный момент для тестируемых вами m4.xlarge стоят:
Это не умаляет ваших тестов, все делают подобную ошибку, пытаясь разобраться «а что же лучше/выгодней». Лишь после, с опытом, приходит понимание, что, оказывается, производительность и «выгодность» — это вторично, а первична экосистема предлагаемых провайдером сервисов, их законченность, интеграция в ваши процессы, удобность поддержки и эксплуатации.
Наличие «такой дыры» обозначает всего лишь недостаточное тестирование. А недостаточное тестирование обозначает то, что технология AMT, выражаясь дипломатично, не является «приоритетным направлением» для Intel и давно.
распилрасцвет иосиновый кол под номером CVE-2017-5689закат — вообще, грустная история, достойная отдельной статьи, постараюсь написать, когда будет совсем плохо.Немного про «эксплуатация этой дыры». Intel AMT в общем случае подразумевает корпоративный сегмент — защищённая от посторонних локальная сеть, политики безопасности и т.п. При их несоблюдении, вам, действительно, в каком-то интернет-кафе шутники запросто смогут вероломно выключить/включить/перезагрузить АМТ-систему. Однако на этом длинный список ваших неприятностей обычно заканчивается и его сложно выделить на фоне белого шума всех других уязвимостей, которые возникают каждый день. Это никак не попытка замазать грубую, имеющую место, ошибку, однако с учётом многолетнего опыта работы с Intel AMT, я относился бы к таким потенциальным взломщикам даже с некоторой долей сочувствия — хорошо понимая, через что им пришлось пройти, чтобы нагло перезагрузить ваш ноутбук.
Касаемо же фобии Intel ME — это ещё одна отдельная больш(н)ая тема, в большей степени имеющая не техническую основу, а психологическую.