Drastycznie obniż koszty swoich środowisk developerskich w AWS

Jak Instance Scheduler może oszczędzić Twojej firmie tysiące złotych rocznie?

Od lat, przemawiając na konferencjach branżowych, zachęcam do prostego, lecz często pomijanego działania: automatycznego wyłączania nieużywanych zasobów w chmurze AWS. Kiedy w czasie mojej ostatniej prezentacji na AWS Community Days zapytałem publiczność:

“Kto z was wyłącza serwery i bazy developerskie na noc i weekendy?“,

podniosło się może pięć rąk. A mówiłem do sali pełnej inżynierów!

Ciągle spotykam się z tym samym problemem. Skoro jesteśmy w chmurze, to dlaczego wciąż płacimy za zasoby, których nikt nie używa?

Jednak dopiero niedawno, na moim prywatnym koncie AWS, doświadczyłem na własnej skórze, jak kosztowne może być ignorowanie tego zalecenia. Po prostych obliczeniach okazało się, że mogę ograniczyć koszty aż o 70%.

Na potrzeby współpracy z jednym klientem potrzebowałem uruchomić własny serwer EC2 typu t3.xlarge. Początkowo pracował przez całą dobę, generując koszty, mimo że używany był jedynie w standardowych godzinach pracy wyłącznie przeze mnie. To marnotrawstwo skłoniło mnie do wdrożenia rozwiązania, które pozwoliło na natychmiastową redukcję wydatków! Oraz posłużyło za pretekst do napisania tego artykułu.

 

Spis treści

• Problem biznesowy
• Gotowe rozwiązanie od AWS: Instance Scheduler
• Tutorial: Wdrożenie Instance Scheduler: Krok po kroku dla DevOpsów
  • Etap 1 - Instalacja rozwiązania
  • Etap 2 - Konfiguracja własnych harmonogramów
  • Etap 3 - Konfiguracja maszyny EC2
• Mój harmonogram
• Kalkulacja oszczędności
• Podsumowanie

Problem biznesowy (albo jak przypadkiem drenujemy budżet)

Wiele firm korzysta z AWS jako podstawowej platformy dla swoich środowisk developerskich i testowych. Zazwyczaj takie środowiska składają się z:

• Instancji EC2 (wirtualnych serwerów)
• Baz danych RDS
• Klastrów ECS lub EKS
• I wielu innych usług…

Problem? Wszystkie te zasoby często pracują 24 godziny na dobę, 7 dni w tygodniu, mimo że zespoły deweloperskie zazwyczaj pracują 8-10 godzin dziennie, 5 dni w tygodniu.

Typowa instancja EC2 lub baza RDS, działająca 24/7, jest istotnym źródłem zbędnych kosztów, szczególnie w środowiskach developerskich, które potrzebne są tylko w określonych godzinach. Dla przykładu, działanie instancji EC2 t3.xlarge w regionie Frankfurt, 24 godziny na dobę, kosztuje miesięcznie ($0.1920x730h) około 140 USD (czyli jakieś 530 PLN).

W rzeczywistości jednak większość zespołów developerskich potrzebuje zasobów maksymalnie przez 5 dni w tygodniu po około 10 godzin dziennie. Taki realny czas pracy wynosi około 30% całkowitego czasu, co oznacza, że nawet 70% kosztów generowanych jest niepotrzebnie.

A co jeśli macie 10 takich środowisk? Albo 50? Mnożymy przez 12 miesięcy i… no właśnie.

Gotowe rozwiązanie od AWS: Instance Scheduler

Instance Scheduler to gotowe, skalowalne rozwiązanie AWS, które automatycznie włącza i wyłącza instancje EC2 oraz bazy RDS zgodnie z predefiniowanym harmonogramem. Dzięki temu zasoby działają tylko wtedy, gdy faktycznie są potrzebne, eliminując zbędne koszty. Od pewnego czasu również wspiera Auto Scaling Grupy - coś czego brakowało przez lata.

Główne cechy rozwiązania:

• Bezagentowość i natywność – nie wymaga instalacji dodatkowych komponentów na serwerach, którymi zarządza.
• Konfigurowalne harmonogramy – pełna elastyczność dostosowania godzin pracy.
• Skalowalność – łatwo dostosowuje się do rosnących potrzeb organizacji, obsługuje zasoby na wielu kontach AWS w organizacji.
• Tag-driven – sterowanie odbywa się za pomocą prostych, predefiniowanych tagów.
• CloudWatch Metrics – umożliwia monitoring działania schedulera i wykorzystania zasobów.
• Obsługa EC2 i RDS – wspiera najczęściej używane usługi AWS oraz kilka innych np. DocumentDB.

Kluczowe zalety dla biznesu:

• Darmowe rozwiązanie - brak kosztów licencji, AWS udostępnia za darmo.
• Niski koszt eksploatacji – opiera się na funkcjach Lambda i DynamoDB o minimalnym koszcie.
• Szybki zwrot z inwestycji (ROI) – natychmiastowe obniżenie kosztów operacyjnych.

Co szczególnie cenię w tym rozwiązaniu, to fakt, że jest ono w pełni natywne dla AWS. Nie ma potrzeby integracji z zewnętrznymi usługami ani instalacji dodatkowego oprogramowania. Eliminuje też potrzebę pisania własnego oprogramowania czy skryptów, co oszczędza czas wielu inżynierów.

⚠️ Jeśli nie interesują Cię kwestie techniczne, to przeskocz bezpośrednio do sekcji
→ Kalkulacja oszczędności.

Tutorial: Wdrożenie Instance Scheduler: Krok po kroku dla DevOpsów

Teraz przejdźmy do konkretów. Oto jak wdrożyć Instance Scheduler na swoim koncie AWS.

Cały proces w uproszczeniu składa się z trzech etapów:

1. Instalacja rozwiązania
2. Konfiguracja → dodanie własnych harmonogramów
3. Otagowanie maszyn, które mają być objęte harmonogramem.

Etap 1 - Instalacja rozwiązania

Na samym początku logujemy się na swoje konto AWS, gdzie chcemy wdrożyć rozwiązanie. Następnie idziemy na stronę Launch the instance scheduler hub stack i klikamy niebieski przycisk “Launch solution”. Zostaniemy przekierowani do konsoli CloudFormation.
ℹ️ Tip: istnieje też wersja w Terraform dostarczona przez społeczność.

Konsola CloudFormation powita nas takim ekranem.

Domyślnie będziemy w regionie us-east-1 , ja zmieniłem u siebie na Szwecję, z której aktywnie nie korzystam, po to aby odseparować swoje zasoby.
ℹ️ Tip: Dla wdrożeń enterprise proponuję zdobyć osobne konto AWS w organizacji, dedykowane tylko dla tego rozwiązania.

Po kliknięciu Next, w kolejnym kroku podajemy parametry stacka, które wpłyną na konfigurację rozwiązania. Ja zmieniłem następujące wartości:

• Stack name → AWS-instance-scheduler
• Time Zone → Europe/Warsaw
• Regions → us-east-1, eu-west-1, eu-west-2, eu-west-3, eu-central-1 - to jest ważne ustawienie, gdyż pozostawinie tego pola pustym spowoduje, że Instance Scheduler będzie tyllko działał w regionie, w którym został wdrożony, a tego raczej nie chcemy.

Dodatkowo wyłączyłem obsługę serwisów AWS, z których nie korzystam, czyli: klastrów RDS, oraz DocumentDB.

W trzecim kroku potwierdzamy, że CF może tworzyć role IAM, idziemy dalej.

A w czwartym kroku: Review klikamy Submit.

Po około trzech minutach wdrożenie stosu CloudFormation zostaje zakończone. Teraz możemy przejść do drugiego etapu.

Etap 2 - Konfiguracja własnych harmonogramów

Tutaj się zatrzymam na chwilkę i trochę porozpływam 🫠 nad tym rozwiązaniem. Dodawanie własnych harmonogramów to istna wisienka na torcie dla inżyniera chmurowego. Są na to dwa sposoby, ale tylko jeden wspaniały przez IaC.

Harmonogram(y) dodajemy przez deployment kolejnego stacka CloudFormation. Dzięki czemu mamy historię zmian z poziomu Gita oraz samego stacka w AWS. To rozwiązanie znacząco ułatwia pracę DevOps-ów i inżynierów chmurowych. Zastosowanie Infrastructure as Code (IaC) pozwala utrzymać pełną kontrolę nad zmianami i zapewnia doskonałą przejrzystość. No po prostu bajka 🫠🧡

Technicznie harmonogramy są trzymane w tabeli DynamoDB, którą stworzyliśmy w Etapie 1. I aby dodać do nich coś nowego wykorzystamy CloudFormation Custom Resource. Nie ma się co bać, bo w praktyce jest to trywialne.

Poniżej znajduje się mój szablon z dość specyficznym harmonogramem, o którym opowiem później. Aby wdrożyć ten szablon, należy podać ARN ServiceInstanceScheduleServiceToken, który można znaleźć w konsoli AWS CloudFormation, wybierając wcześniej wdrożony stack, a następnie wybierając zakładkę Outputs.

AWSTemplateFormatVersion: 2010-09-09
Parameters:
  ServiceInstanceScheduleServiceTokenARN:
    Type: String
    Description: (Required) service token arn taken from InstanceScheduler outputs
Metadata:
  'AWS::CloudFormation::Designer': {}
Resources:
  SampleSchedule1:
    Type: 'Custom::ServiceInstanceSchedule'
    Properties:
      ServiceToken: !Ref ServiceInstanceScheduleServiceTokenARN #do not edit this line
      NoStackPrefix: 'True'
      Name: OpenOps-server
      Description: custom schedule with various shutdown times
      Timezone: Europe/Warsaw
      StopNewInstances: 'True'
      Periods:
      - Description: run from 9 to 19 on Monday, Thursday
        BeginTime: '9:00'
        EndTime: '19:00'
        WeekDays: 'Mon, Thu'
      - Description: run from 9 to 17 on Tuesday and Wednesday, and Friday
        BeginTime: '09:00'
        EndTime: '17:00'
        WeekDays: 'Tue, Wed, Fri'
      - Description: run from 10 to 15 on Saturday
        BeginTime: '10:00'
        EndTime: '15:00'
        WeekDays: 'Sat'

Taki szablon CloudFormation deployujemy jak każdy inny, ja go nazwałem AWS-instance-scheduler-schedules.

Zaś efektem jego wdrożenia nie będą kolejne zasoby, ale nowe elementy w tabeli DynamoDB (tak wiem, magia 🧙).

Tabela konfiguracyjna przed deploymentem - 10 elementów:

Tabela konfiguracyjna po deploymencie - 14 elementów:

Etap 3 - Konfiguracja maszyny EC2

Aby objąć serwer naszym nowym harmonogramem, należy dodać do niego odpowiednie tagi. W tym celu należy użyć klucza tagu zdefiniowanego podczas początkowej konfiguracji (domyślnie klucz tagu to Schedule) i ustawić wartość tagu na nazwę harmonogramu, który powinien mieć zastosowanie do instancji. Łatwo sobie wyobrazić w dużej firmie potrzebę wielu harmonogramów, natomiast ja dodałem w poprzednim korku tylko jeden o nazwie OpenOps-server. I właśnie w taki sposób otagowałem swój serwer EC2.

Już po paru minutach Instance Scheduler odnalazl moja maszynę, ale jeszcze nic z nią nie zrobił ponieważ byliśmy jeszcze w okresie (period)w którym powinna być uruchomiona.

Działanie

Kilka minut później, po godzinie 19-stej maszyna została wyłączona zgodnie z harmonogramem. W metadanych EC2 można zobaczyć State transition reason**:** User initiated (2025-05-19 17:00:24 GMT).

Całe wdrożenie Instance Scheduler’a wraz z konfiguracją zajęło około pół godziny.

Mój harmonogram

Zanim przejdziemy do wyliczeń, chciałbym Ci jeszcze przedstawić podstawowe założenia na temat konfiguracji harmonogramu. Każdy harmonogram schedule składa się z jednego lub więcej okresów period, których “suma” decyduje o tym kiedy dana maszyna ma być włączana i wyłączona.

Mój harmonogram jest dostosowany pod moje godziny pracy:

• Poniedziałek i czwartek: 9:00 - 19:00
• Wtorek, środa, piątek: 9:00 - 17:00
• Sobota: 10:00 - 15:00

W tych wszystkich godzinach mój serwer będzie włączony, a poza nimi wyłączony.

Nie jest to może najbardziej trywialny przykład jaki można sobie wyobrazić (ten zapewne by wyglądał następująco Mon-Fri i 8-18), ale za to pokazuje elastyczność tego rozwiązania. W istocie to tylko czubek góry lodowej i autorzy rozwiązania przewidzieli dużo więcej opcji konfiguracji, tutaj link do dokumentacji.

Natomiast jest coś, na co pragnę jeszcze zwrócić Twoją uwagę mimo iż tego nie używam, mianowicie Adjacent periods (Sąsiadujące okresy). Rozwiązanie nie zatrzyma uruchomionych serwerów, jeśli harmonogram zawiera dwa sąsiednie okresy działania. Na przykład, jeśli masz harmonogram z jednym okresem z godziną zakończenia 23:59 i innym okresem z godziną rozpoczęcia o północy następnego dnia, to rozwiązanie nie zatrzyma uruchomionych maszyn. Zatem możemy prosto łączyć ze sobą okresy, a rozwiązanie zadba o ciągłość działania.

Kalkulacja oszczędności

Na poniższym wykresie zielone pole pokazuje godziny, w których serwery są włączone. To tylko 29% całego czasu w tygodniu. Udało nam się zmniejszyć koszty o ponad 70%, nawet z pracującą sobotą! I to wszystko bez żadnych kompromisów na wydajności czy ilości serwerów.

Na początku artykułu napisałem, że mój serwer t3.xlarge kosztuje miesięcznie ($0.1920x730h) około 140 USD (530 PLN) działając non-stop. Po wdrożeniu harmonogramu, jego koszt spadł do 41 USD (około 154 PLN). To jest 4500 PLN (netto) oszczędności w skali roku na tej jednej konkretnej maszynie.

A co jeśli macie 10 takich środowisk? Albo 50? No właśnie! 😀

Podsumowanie

Rozwiązanie Instance Scheduler on AWS to szybki i skuteczny sposób na znaczącą redukcję kosztów w środowiskach developerskich i testerskich. Proste wdrożenie oraz natychmiastowy efekt finansowy czynią je idealnym narzędziem zarówno dla osób decyzyjnych w organizacji, jak i zespołów technicznych. Jeśli jeszcze nie korzystasz z harmonogramowania zasobów, to prawdopodobnie co miesiąc wyrzucasz pieniądze w błoto. Automatyzacja zarządzania zasobami pozwala zaoszczędzić wymierne sumy pieniędzy, zwiększa efektywność kosztową organizacji oraz promuje świadomość kosztów wśród inżynierów.

Owocnego cięcia kosztów!

Jeśli Twoja organizacja potrzebuje pomocy w optymalizacji kosztów AWS, chętnie z Tobą porozmawiam. Odezwij się do mnie na LinkedIn lub napisz maila na pawel@cloudpouch.dev.