AWS Notes
5.6K subscribers
467 photos
43 videos
10 files
2.83K links
AWS Notes — Amazon Web Services Educational and Information Channel

Chat: https://xn--r1a.website/aws_notes_chat

Contacts: @apple_rom, https://www.linkedin.com/in/roman-siewko/
Download Telegram
Forwarded from infosec
• Awesome Cloud Security Labs - объемный набор бесплатных лаб для самостоятельного изучения безопасности облачных сред и технологий:

AWS;
Azure;
GCP;
Kubernetes;
Container;
Terraform;
Research Labs;
CI/CD.

https://github.com/iknowjason/Awesome-CloudSec-Labs

#Cloud #ИБ
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7🔥32
Скрипач не нужен или dynamodb_table — всё.

terraform {
 # S3 Conditional Writing configuration (locks without DynamoDB)
 required_version = "~> 1.10" # with use_lockfile
 backend "s3" {
  bucket     = "my-tf-state"
  # dynamodb_table = "my-tf-state-lock" # deprecated from 1.11
  use_lockfile  = true
  key      = "devops/us-east-1/kms.tfstate"
  region     = "us-east-1"
  encrypt    = "true"
  kms_key_id   = "arn:aws:kms:us-east-1:34567890:key/15a-6736"
 }
}


Начиная с Terraform v1.10 появляется опция use_lockfile и больше не нужно создавать/указывать dynamodb_table для блокировки стэйта. Для этого используется нативная фича S3 Conditional Writes, появившаяся в 2024-м году.

Начиная с Terraform v1.11 dynamodb_table уже deprecated, хотя её можно по-прежнему указывать (даже вместе с use_lockfile = true).

#Terraform
🔥45👍4
🆕 Terraform v1.11:

🔸 Write Only атрибуты для ресурсов, которые не записываются в стэйт
🔹 DynamoDB lock теперь deprecated, для лока по дефолту использует чисто S3
🔹 поддержка JUnit XML: terraform test -junit-xml

https://github.com/hashicorp/terraform/releases/tag/v1.11.0

Избавление от DynamoDB было ещё в прошлой версии, теперь же это GA и окончательно deprecated для dynamodb_table = "my-tf-state-lock".

Главная фича — возможность использования ephemeral ресурсов, которые существуют лишь на этапе plan + apply первый раз при создании ресурса (то есть временно/однократно). Они не попадают в стэйт, точней имеют там значение null и после никогда там не обновляются.

Вот как теперь может выглядеть создание RDS с генерацией случайного пароля с передачей его через секреты:

provider "aws" {
region = "us-east-1"
}

ephemeral "random_password" "db_password" {
length = 16
}

resource "aws_secretsmanager_secret" "db_password" {
name = "db_password"
}

resource "aws_secretsmanager_secret_version" "db_password" {
secret_id = aws_secretsmanager_secret.db_password.id
secret_string_wo = ephemeral.random_password.db_password.result
secret_string_wo_version = 1
}

ephemeral "aws_secretsmanager_secret_version" "db_password" {
secret_id = aws_secretsmanager_secret.db_password.id
}

resource "aws_db_instance" "example" {
instance_class = "db.t4g.small"
allocated_storage = "20"
engine = "postgres"
username = "myuser"
skip_final_snapshot = true

password_wo = ephemeral.aws_secretsmanager_secret_version.db_password.secret_string
password_wo_version = 1
}


Сто лет изначально ожидаемая фича. Можно, наконец, забороть сложные compliance требования, где сохранение паролей в state всегда вызывало претензии со стороны безопасников.

Отдельно добавляю, что появление фичи password_wo вполне можно считать результатом конкуренции с OpenTofu. И это очень хорошо.

#Terraform
👍371😁1
#aws #aurora #terraform #finops
Материал уровня senior

Мы умеем определять тип инстанса - по нагрузке на CPU/Memory и другим факторам.
Но насколько эффективно мы выбрали Cluster storage configuration Авроры вашего проекта?
Эффективно ли это спустя год или два?
А никто не знает, давайте разбираться.

- сперва пилим Dashboard к нашему существующему кластеру
https://gist.github.com/kruchkov-alexandr/d9335d7927e58d06557b994dc9f194de
- применяем, видим панель в CloudWatch
Сверху у нас панель чтения/записи хранилища, снизу размер базы данных (+снепшоты?).
Разделение нужно из-за разницы масштабов и удобства экспорта.
- выбираем период три месяца и кликаем на трех точках у обоих панелей и выбираем Download as .csv и качаем оба файла
- заходим в cost explorer и экспортируем дату за три месяца по кластеру
- заходим в вашу любимую AI(я спрашивал у клаудии, перплексити и грок3, все платные) и пилим промт нечто типа(можете писать свой, если мой вам кажется тупым):
"Help me decide if we should switch to Amazon Aurora I/O-Optimized. Use the attached billing screenshot/csv, three-month IOPS data from the CSV, and the IOPS/storage graphs to analyze our costs. Calculate our current I/O expenses, compare them to I/O-Optimized costs and check if our I/O costs exceed AWS’s 25% threshold for switching. Look at IOPS and storage trends, then recommend whether to switch, including specific cost figures. I’ve attached all files (billing, CSV, graphs).
based on this article
https://aws.amazon.com/blogs/database/estimate-cost-savings-for-the-amazon-aurora-i-o-optimized-feature-using-amazon-cloudwatch/"

- ждём ответа и все 4 нейронки мне выдали на 95% одинаковый подробнейший расчёт ответ. Вкратце "Переходить пока рано".
- пишем менеджеру/боссу
I've analyzed our infrastructure costs over the last three months billing and IOPS data, to see if switching to Amazon Aurora I/O-Optimized makes sense. Right now, it's not cost-effective. Our I/O costs an average of $******* monthly (************ I/Os at $**** per million). Moving to I/O-Optimized would increase instance costs by ***%, from $******* to $******* - a $******* jump, which is $415.21 more than our current I/O expenses.
Our IOPS trends show peaks up to *** but no major growth, averaging ~** Write and ~**** Read IOPS hourly in February. Storage usage is growing at *** GB/month, but that doesn't impact the I/O-Optimized cost comparison. AWS suggests I/O-Optimized when I/O costs exceed **% of total Aurora spend, but ours ($******) are only **% of the $******* total, so we're below that threshold.
I recommend sticking with our standard configuration for now. We should keep monitoring I/O activity -if it exceeds **** I/Os monthly or I/O costs reach **% of our Aurora spend, we can revisit I/O-Optimized.

Прикладываем все файлы,скрины,расчёты.
- закрываем таску и трекаем время

Всё вышеописанное заняло у меня минут 15, а вот подготовительные работы(чтение про фичу, особенности, лимиты, как считать, написание борды, особенности биллинга и тп) почти половину дня.
* Если не верите ИИ, можете пересчитать вручную🐒

Дополнительные полезные ссылки(а вдруг вы мне не верите):
- анонс фичи
https://aws.amazon.com/about-aws/whats-new/2023/05/amazon-aurora-i-o-optimized/
- обзор менеджер уровня
https://aws.amazon.com/awstv/watch/b9bfc040ac5/
- пример расчётов (там руками считают, без ИИ)
https://aws.amazon.com/blogs/database/estimate-cost-savings-for-the-amazon-aurora-i-o-optimized-feature-using-amazon-cloudwatch/
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21👍3🤔21👏1
EKS Terraform demo

https://github.com/setheliot/eks_demo/

Deploys:

▪️ EKS cluster using EC2 nodes
▪️ DynamoDB table
▪️ EBS volume used as attached storage for the Kubernetes cluster (a PersistentVolume)
▪️ Demo "guestbook" application, deployed via containers
▪️ ALB to access the app

#EKS #Terraform
👍5💊5
Начиная с Terraform AWS Provider v6.0.0 алиасы уже не нужны — можно указывать AWS Region непосредственно в ресурсах, используя лишь один провайдер.

#Terraform
👏42👍9🔥96😍1👀1🦄1
Roman Siewko
Зарелизился terraform-provider-aws v6.0.0 с поддержкой регионов для ресурсов: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/enhanced-region-support Полный список изменений в шестой версии: https://github.com/hashicorp/terraform…
BREAKING CHANGES: Terraform AWS Provider v.6

Обновлённый AWS провайдер содержит под сотню (93 шт.) BREAKING CHANGES, так что если у вас вдруг что-то перестало работать — не удивляйтесь.

Версии нужно пинить, господа. А то...

#Terraform
22💯4😭2
AWS Organizations Tag Policies 🎉

https://aws.amazon.com/blogs/mt/enforce-consistent-tagging-across-iac-deployments-with-aws-organizations-tag-policies/

Теперь, наконец-то, можно реально заставить прописывать нужные теги — иначе terraform plan не пройдёт.

https://github.com/hashicorp/terraform-provider-aws/blob/main/website/docs/guides/tag-policy-compliance.html.markdown

provider "aws" {
tag_policy_compliance = "error"
}

When set to error, tag policy violations will trigger an error diagnostic.

When set to warning, tag policy violations will trigger a warning diagnostic. Planned changes will be able to proceed, but the diagnostic will not be silenced until the tag policy violation is resolved.

When set to disabled, the tag policy will not be enforced. This is equivalent to leaving the value unset.

#CloudFormation #Terraform #Pulumi
🔥16