#credits и #baseline для #t2 и #t3 инстансов - не забываем, что у #t3 два процессора даже для #nano, накопленные кредиты не сбрасываются в течении недели после остановки, да и просто всё выгодней, а цена ниже (чем у #t2).
Amazon
Key concepts for burstable performance instances - Amazon Elastic Compute Cloud
Understand the key concepts and definitions of CPU performance for burstable performance instances.
Использование T2/T3 инстансов в проде
Можно ли использовать T2/T3 для #EC2, #RDS и прочих сервисов в продовских окружениях? Запросто. Нужно лишь помнить и учитывать моменты, которые отличают их от "полноценных" инстансов. Это baseline (нагрузка) и сеть (задержки).
Baseline (нагрузка)
Если у вас постоянная/долговременная нагрузка на проде выше #baseline (правая колонка):
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html
То он будет тормозить. Что плохо, точней, обычно недопустимо, потому ставим "полные" c4/c5/m4/m5 и т.д.
Если у вас нагрузка никогда (обычно, редко и очень ненадолго - чтобы хватило накопленных кредитов) не достигает baseline - запросто можно использовать эти полезные и более дешёвые инстансы (не только для виртуалок, но и для RDS, ES и др.).
Сеть (задержки)
Если с первым (загрузкой) более-менее всем понятно, то вот второй фактор многие не учитывают - скорость сети у T2/T3 инстансов не только ниже, а временами хромает, ковыляет, страдает и даже просто, бывает, лежит. Дипломатично в документации это называется "не гарантирована".
Для каких-то сервисов это может быть не столь критично, а вот лаги RDS на T2/T3 могут стать неприятным откровением. В таком случае активно используйте кэширование, мониторинг и здравый смысл.
Реальную скорость сетевого интерфейса и её катастрофу, когда кончаются бурсты - можно посмотреть по следующей полезной ссылке:
https://cloudonaut.io/ec2-network-performance-cheat-sheet/
Итого
Не умеешь - не обгоняй. Боишься, деньги казёные или лень разбираться - ставь "полные версии".
Хочешь (нужно) сэкономить, протестировано, мониторинг, кэширование и прочий фарш помноженный на рассудок - смело используем T2/T3, в том числе на проде.
#t2 #t3 #prod
Можно ли использовать T2/T3 для #EC2, #RDS и прочих сервисов в продовских окружениях? Запросто. Нужно лишь помнить и учитывать моменты, которые отличают их от "полноценных" инстансов. Это baseline (нагрузка) и сеть (задержки).
Baseline (нагрузка)
Если у вас постоянная/долговременная нагрузка на проде выше #baseline (правая колонка):
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html
То он будет тормозить. Что плохо, точней, обычно недопустимо, потому ставим "полные" c4/c5/m4/m5 и т.д.
Если у вас нагрузка никогда (обычно, редко и очень ненадолго - чтобы хватило накопленных кредитов) не достигает baseline - запросто можно использовать эти полезные и более дешёвые инстансы (не только для виртуалок, но и для RDS, ES и др.).
Сеть (задержки)
Если с первым (загрузкой) более-менее всем понятно, то вот второй фактор многие не учитывают - скорость сети у T2/T3 инстансов не только ниже, а временами хромает, ковыляет, страдает и даже просто, бывает, лежит. Дипломатично в документации это называется "не гарантирована".
Для каких-то сервисов это может быть не столь критично, а вот лаги RDS на T2/T3 могут стать неприятным откровением. В таком случае активно используйте кэширование, мониторинг и здравый смысл.
Реальную скорость сетевого интерфейса и её катастрофу, когда кончаются бурсты - можно посмотреть по следующей полезной ссылке:
https://cloudonaut.io/ec2-network-performance-cheat-sheet/
Итого
Не умеешь - не обгоняй. Боишься, деньги казёные или лень разбираться - ставь "полные версии".
Хочешь (нужно) сэкономить, протестировано, мониторинг, кэширование и прочий фарш помноженный на рассудок - смело используем T2/T3, в том числе на проде.
#t2 #t3 #prod