AWS EC2 Nedir? Şirketler İçin Doğru EC2 Yapısı Nasıl Kurulur?

Kısaca

AWS EC2, Amazon Web Services üzerinde sanal sunucu çalıştırmaya yarayan temel compute servisidir. Ancak production ortamında doğru EC2 yapısı yalnız instance seçmekten ibaret değildir; instance family, EBS storage, network, Availability Zone, monitoring, backup, patching ve maliyet modeli birlikte tasarlanmalıdır.

Dynamis Teknoloji'de EC2 altyapısını yalnız "hangi instance daha güçlü?" sorusuyla değil, workload profili + availability + storage + network + operasyon + maliyet birlikte değerlendirilerek ele alıyoruz.

AWS EC2 nedir?

Amazon EC2 (Elastic Compute Cloud), AWS üzerinde sanal sunucu kapasitesi sağlayan compute servisidir.

EC2 ile:

• Linux veya Windows instance çalıştırabilirsiniz
• farklı CPU ve memory profilleri seçebilirsiniz
• EBS block storage bağlayabilirsiniz
• VPC içinde private/public network tasarlayabilirsiniz
• load balancer ve Auto Scaling ile kapasiteyi dağıtabilirsiniz
• CloudWatch ile monitoring kurabilirsiniz

EC2'nin esnekliği güçlüdür; ancak yanlış instance, storage veya network seçimi production performansını ve maliyeti doğrudan etkiler.

EC2 instance tipi nasıl seçilir?

AWS instance aileleri farklı workload profillerine göre tasarlanır.

Genel yaklaşım:

• general purpose: dengeli CPU/memory ihtiyacı
• compute optimized: CPU yoğun workload
• memory optimized: yüksek RAM ihtiyacı
• storage optimized: yüksek local storage / I/O ihtiyacı olan özel workload'lar
• accelerated computing: GPU veya accelerator gerektiren işler

Ancak aile seçimi tek başına yeterli değildir.

Kontrol edilmesi gerekenler:

• vCPU
• memory
• network throughput
• EBS bandwidth
• CPU architecture
• peak kullanım
• workload büyümesi
• licensing

Instance boyutu yalnız ortalama CPU'ya göre seçilmemeli

Örneğin ortalama CPU %20 görünürken peak saatlerde %85 olabilir.

Bu nedenle:

• p95 CPU
• memory
• disk IOPS
• network
• application latency
• peak window

birlikte incelenmelidir.

Cloud Rightsizing Nedir? instance boyutlandırmasını daha ayrıntılı ele alır.

General Purpose ne zaman uygundur?

General purpose instance'lar compute ve memory arasında dengeli profil sunar.

Tipik kullanım:

• web application
• API
• küçük/orta application server
• development/staging
• bazı backend servisleri

Workload belirgin şekilde CPU veya memory yoğun değilse iyi başlangıç noktası olabilir.

Compute Optimized ne zaman kullanılmalı?

CPU yoğun workload'larda compute optimized instance'lar daha uygun olabilir.

Örnek:

• high-throughput API
• batch processing
• encoding
• bazı build runner workload'ları

Ancak yalnız benchmark sonucu değil, production kullanım paterni üzerinden karar verilmelidir.

Memory Optimized ne zaman gerekli?

Yüksek RAM ihtiyacı olan workload'larda memory optimized aileler değerlendirilir.

Örnek:

• in-memory cache
• memory yoğun application
• bazı database workload'ları
• büyük data processing

Memory ihtiyacı düşük workload'u memory optimized instance üzerinde çalıştırmak gereksiz maliyet yaratabilir.

EC2 storage nasıl tasarlanmalı?

EC2 ile en sık Amazon EBS kullanılır.

EBS seçerken:

• kapasite
• IOPS
• throughput
• durability
• snapshot
• growth

birlikte değerlendirilmelidir.

Storage yalnız GB fiyatı üzerinden seçilmemelidir.

Örneğin database workload'u düşük latency ve yüksek IOPS isterken, sıradan application server daha düşük storage performansıyla çalışabilir.

Root volume ile application data'yı ayırmak gerekir mi?

Her zaman zorunlu değildir; ancak bazı production workload'larda işletim sistemi ile application/database data'yı ayrı volume'larda tutmak:

• lifecycle yönetimini
• snapshot politikasını
• migration'ı
• storage tuning'i

kolaylaştırabilir.

EC2 network tasarımı

Production EC2 instance'ları VPC içinde planlanmalıdır.

Temel konular:

• public/private subnet
• route table
• security group
• NAT
• load balancer
• DNS
• private connectivity

Database veya internal servislerin gereksiz yere public IP ile internete açılması önerilmez.

Security Group nasıl kullanılmalı?

Security Group kuralları least privilege yaklaşımıyla tanımlanmalıdır.

Örnek:

• web server: yalnız gerekli HTTP/HTTPS portları
• application server: yalnız load balancer veya belirli kaynaklardan erişim
• database: yalnız application subnet/security group
• SSH/RDP: mümkün olduğunca sınırlı yönetim kaynağı

0.0.0.0/0 erişimi yalnız gerçekten gerekli servislerde kullanılmalıdır.

Production EC2 tek instance üzerinde çalıştırılabilir mi?

Evet, teknik olarak çalıştırılabilir.

Ancak tek instance:

• host failure
• maintenance
• application crash
• AZ problemi

durumlarında single point of failure olur.

Yüksek erişilebilirlik ihtiyacı business impact'e göre belirlenmelidir.

Availability Zone kullanımı

HA gereken sistemlerde workload birden fazla Availability Zone'a dağıtılabilir.

Tipik yaklaşım:

• en az iki AZ
• load balancer
• birden fazla application instance
• database HA modeli

Ancak multi-AZ tasarımın:

• network
• database
• operasyon
• maliyet

etkileri vardır.

Her uygulamaya otomatik olarak multi-AZ kurmak yerine downtime toleransı ve RTO/RPO üzerinden karar verilmelidir.

Load Balancer ne zaman gerekli?

Birden fazla EC2 instance arasında trafik dağıtmak veya health check üzerinden unhealthy instance'ları devreden çıkarmak için load balancer kullanılabilir.

Tek instance'lı küçük sistemde zorunlu olmayabilir.

Auto Scaling ne zaman kullanılmalı?

Trafiği dalgalanan workload'larda Auto Scaling:

• minimum kapasiteyi koruyabilir
• demand arttığında instance ekleyebilir
• demand düşünce kapasite azaltabilir

Ancak yanlış threshold veya yüksek minimum kapasite maliyeti artırabilir.

Autoscaling rightsizing'in yerine geçmez.

CloudWatch monitoring

EC2 production operasyonunda monitoring minimum olarak şunları kapsamalıdır:

• CPU
• network
• disk
• instance health
• application latency
• error rate

Memory ve uygulama-level metrikler için ek agent veya application telemetry gerekebilir.

Alarmın yalnız üretilmesi değil, kimin aksiyon alacağının tanımlı olması gerekir.

EC2 backup nasıl yapılmalı?

EC2 backup politikası workload'a göre farklı olabilir.

Yaygın yöntemler:

• EBS snapshot
• AWS Backup
• application-aware backup
• database-native backup

Snapshot tek başına her application için tutarlı recovery garantisi değildir.

Restore testleri düzenli yapılmalıdır.

EC2 patching ve image yönetimi

Production EC2 instance'larında:

• operating system patch
• security update
• runtime update
• AMI lifecycle

tanımlı olmalıdır.

Manuel ve plansız patch süreci zamanla drift oluşturur.

Immutable image yaklaşımı ne zaman avantajlı?

Değişiklikleri çalışan instance üzerinde elle yapmak yerine yeni image üretip instance'ı yeniden deploy etmek bazı ekiplerde:

• tekrar üretilebilirlik
• rollback
• drift azaltma

sağlayabilir.

Ancak küçük ve stabil sistemlerde daha basit patch modeli yeterli olabilir.

Windows EC2 için ek dikkat noktaları

Windows workload'larda ayrıca:

• Windows Server licensing
• RDP erişimi
• patching
• antivirus/EDR
• storage latency
• SQL Server lisanslama

gibi konular değerlendirilmelidir.

EC2 maliyeti nasıl oluşur?

Toplam EC2 maliyeti yalnız instance fiyatı değildir.

Ek kalemler:

• EBS
• snapshot
• data transfer
• Elastic IP / network kaynakları
• load balancer
• monitoring/logging
• backup
• lisans

olabilir.

Bu nedenle yalnız instance hourly price üzerinden TCO hesabı eksik kalabilir.

EC2 maliyeti nasıl optimize edilir?

Sağlıklı sıra:

1. idle kaynakları temizle
2. rightsizing yap
3. EBS/storage kontrol et
4. data transfer ve NAT maliyetini incele
5. stable baseline ölç
6. commitment değerlendir

Savings Plan mı, Reserved Instance mı? commitment kararını ayrıntılı açıklar.

Savings Plan ne zaman anlamlı?

Uzun süre stabil compute kullanımında Savings Plans değerlendirilebilir.

Ancak overprovisioned EC2 instance'a Savings Plan almak verimsizliği yalnız daha ucuz hale getirir.

Önce rightsizing yapılmalıdır.

Spot Instance production'da kullanılabilir mi?

Evet, uygun workload'larda.

Spot interruption riskine dayanabilen:

• batch
• stateless worker
• queue consumer
• fault-tolerant compute

gibi workload'larda maliyet avantajı sağlayabilir.

Ancak kritik stateful workload için kesinti modeli dikkate alınmadan kullanılmamalıdır.

Graviton ne zaman değerlendirilmeli?

ARM uyumlu uygulamalarda AWS Graviton tabanlı instance'lar fiyat/performance açısından avantajlı olabilir.

Geçiş öncesi:

• application compatibility
• container image
• dependency
• native binary

kontrol edilmelidir.

EC2 ve container arasında nasıl seçim yapılır?

EC2 üzerinde uygulamayı doğrudan çalıştırmak daha basit olabilir.

Container yaklaşımı ise:

• packaging
• deployment consistency
• portability

sağlayabilir.

Kubernetes ise bunların üzerine ayrı bir orchestration ve platform operations katmanı ekler.

Her EC2 workload'unun Kubernetes'e taşınması gerekmez.

EC2 production checklist

• workload profili
• doğru instance family
• rightsizing
• VPC/subnet
• security group
• EBS
• backup
• monitoring
• alert owner
• patching
• IAM
• load balancer gerekiyorsa
• HA gerekiyorsa multi-AZ
• restore testi
• cost review
• commitment

AWS EC2 ne zaman yanlış seçim olabilir?

EC2 her workload için en iyi seçenek değildir.

Örneğin ekip:

• altyapı yönetmek istemiyorsa
• serverless event workload çalıştırıyorsa
• tamamen managed database/service kullanabiliyorsa
• container platformu operasyonel olarak daha uygunsa

başka AWS servisleri daha doğru olabilir.

Dynamis EC2 altyapısında neyi yönetir?

Dynamis mevcut AWS hesabınız üzerinde ihtiyaca göre:

• EC2 mimarisi
• VPC/network
• EBS/storage
• monitoring
• backup
• patching
• security hardening
• rightsizing
• cost optimization
• incident response

katmanlarını yönetebilir.

Başka platforma migration zorunlu değildir.

AWS yönetim hizmeti mevcut AWS hesabınızın production operasyonunu uçtan uca ele alır.

Sık yapılan hatalar

Instance'ı yalnız vCPU'ya göre seçmek: Memory, network ve storage profilini de değerlendirin.

Database'i public subnet'e açmak: Private network ve erişim modeli kurun.

Backup var ama restore testi yok: Recovery doğrulanmalıdır.

Auto Scaling var diye rightsizing yapmamak: Minimum kapasite yine pahalı olabilir.

Savings Plan'ı ilk optimizasyon adımı yapmak: Önce waste ve rightsizing.

Tek EC2 instance'ı HA sanmak: Failure domain'i bilin.

Sonuç

AWS EC2 production altyapısı yalnız instance seçmek değildir.

Doğru yapı; workload'a uygun compute, storage, network, monitoring, backup, security ve maliyet modelinin birlikte tasarlanmasıyla oluşur.

En iyi EC2 mimarisi en büyük instance değil, business gereksinimini güvenilir ve sürdürülebilir maliyetle karşılayan yapıdır.

Sırada ne var

• AWS Nedir?
• Cloud Rightsizing Nedir?
• Savings Plan mı, Reserved Instance mı?
• Yazılım Şirketleri İçin Production Altyapısı Nasıl Kurulur?
• AWS yönetim hizmeti

Kaynaklar

• Amazon EC2 User Guide
• Amazon EC2 Instance Types
• Amazon EBS User Guide
• AWS Auto Scaling User Guide
• Amazon CloudWatch EC2 metrics