Amazon SAA-C03: Veri Aktarımı ve Migrasyon — Çalışma kılavuzu

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Şunun bir parçası: AWS SAA-C03 — Eksiksiz çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Amazon sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Bant Genişliği-Fiziksel Taşıma Karşılaştırması

Her geçiş projesi aritmetikle başlar. Bir araç seçmeden önce teorik aktarım süresini hesaplayın:

Transfer days = (Dataset size in bits) / (Usable bandwidth in bps × 86,400)
Usable bandwidth = Link speed × Allowed utilization %

Rakamlar acımasızdır. Sürekli 100 Mbps hızda 1 TB yaklaşık 24 saat sürer; 1 Gbps’de ise yaklaşık 2,5 saat. %70 kullanım oranına sabitlenmiş 15 Mbps’lik bir bağlantı günde yalnızca ~113 GB sunar, bu nedenle 20 TB için 175 günden fazla süre gerekir. 150 TB’ı bir gecede (100 Mbps’nin %80’i ile 10 saatte) aktarmak, gecelik ~360 GB veya aylık 10,5 TB anlamına gelir ki bu, 30 günlük bir teslim tarihinin yanına bile yaklaşamaz. 7/24 tam kapasite çalışsa bile 100 Mbps günde yalnızca ~1 TB taşır, bu nedenle 150 TB için minimum 150 gün gerekir. Petabayt ölçeğinde durum daha da kötüleşir: gerçek dünya verimliliğinde 500 Mbps’lik bir bağlantı, teorik olarak günde yaklaşık 5,4 TB verim sağlar, bu da 10 PB’nin beş yıldan fazla sürekli aktarım gerektireceği anlamına gelir — bu süre, çoğu Direct Connect devresinin sağlanmasından daha uzundur.

Makul bir pratik kural olarak:

Geçiş senaryolarındaki en yaygın yanlış cevap, matematiksel olarak belirlenen süre içinde tamamlanamayacak bir WAN aktarımını seçmektir. Bununla ilişkili bir diğer tuzak olan “bunu her gece WAN üzerinden çalıştırırız” yaklaşımı sadece daha yavaş değildir. Üretim bant genişliğini tüketir, yeniden yükleme gerektiren kısmi veya bozuk aktarımları riske atar ve bant genişliği ücretleri ile mühendislik süresi hesaba katıldığında genellikle daha maliyetli olur. Bir Snowball birim ücreti artı kargo ücreti, sabit ve öngörülebilir bir kalemdir.

Çevrimdışı Toplu Aktarım için Snow Ailesi

Snowball Edge cihazları iki farklı modelde sunulur:

Snowcone, küçük form faktörlü (~8 TB SSD), dayanıklı ve kuryeyle gönderilebilen bir cihazdır. Alan kısıtlı yerler için kullanışlıdır ve uç (edge) senkronizasyonu için önceden yüklenmiş DataSync aracıları ile birlikte gelir. 100 PB’a kadar veri taşıyan 45 fitlik bir konteyner olan Snowmobile, eksabayt ölçeğindeki veri merkezi tahliyelerini hedefliyordu, ancak çoğu bölgede yerini paralel Snowball Edge filolarına bırakarak kullanımdan kaldırılmıştır. Bir petabaytın altındaki herhangi bir iş için Snowmobile seçmek bir çeldiricidir.

Compute modeli sadece daha büyük bir disk değildir. EC2 AMI’lerini, Lambda fonksiyonlarını ve Greengrass iş yüklerini yerel olarak çalıştırır. Bu da onu, verilerin alımdan önce dönüştürülmesi, filtrelenmesi veya PII (Kişisel Tanımlayıcı Bilgiler) verilerinin temizlenmesi gerektiğinde, bir iş yükünün alımdan hemen sonra AWS’de devam etmesi gerektiğinde veya tesisin bağlantısız ya da kesintili bağlantıya sahip olduğu durumlarda (gemiler, uzak madencilik sahaları, taktiksel konuşlandırmalar, uzaktan araştırma) doğru bir seçim haline getirir. Cihaz üzerinde işleme gerektiğinde Compute Optimized’ı, iş yükü yalnızca toplu kopyalama olduğunda ise Storage Optimized’ı seçin.

Her Snow cihazı, AWS’den asla ayrılmayan KMS anahtarlarını kullanarak bekleyen veriler için 256-bit şifreleme gerçekleştirir. Kasalar, E Ink kargo etiketine ve donanımsal bir Trusted Platform Module’e sahip olup kurcalamaya karşı korumalıdır. Cihaz üzerindeki veriler Snowball istemcisi, S3 uyumlu uç nokta veya bir NFS bağlama noktası kullanılarak yazılır; TLS, alım ve kargo manifestosu değişimi sırasında aktarılan verileri korur. Geri döndüğünde, içerikler S3’e alınır ve cihaz NIST 800-88 standardına göre kriptografik olarak silinir.

Tesis başına petabayt ölçeğindeki işler için paralelleştirme esastır. 1–2 Gbps bağlantı kapasitesine sahip bir ofisin bile 1 PB’yi çevrimiçi olarak taşıması için aylarca süren sürekli tam kapasite kullanım gerekir; tesis başına paralel olarak gönderilen ~13 adet Storage Optimized cihazından (her biri 80 TB) oluşan bir filo, ofisin internet bağlantısını meşgul etmeden dört haftalık bir teslim tarihini yakalar. Doymuş 100 Mbps’lik bir bağlantıda iki haftalık 600 TB’lık bir iş için, küçük bir paralel filo tek doğru cevaptır — maliyeti göz ardı etsek bile, fizik kuralları DataSync veya yeni bir Direct Connect bağlantısını imkansız kılar.

Çevrimiçi, Doğrulanmış, Artımlı Aktarım İçin DataSync

Bant genişliği yeterli olduğunda ancak iş yükü özellikleri — milyonlarca küçük dosya, derin dizin ağaçları, devam eden artımlı senkronizasyonlar veya dosya sistemleri arası geçiş — basit araçları işlevsiz bırakacaksa, doğru araç DataSync’tir. aws s3 cp ile kopyalanan 20 milyon 4 KB’lık dosyadan oluşan bir dizin, aktarım hızından değil, gidiş-dönüş gecikmesinden dolayı darboğaza girer; her PutObject işlemi bir TLS/HTTP gidiş-dönüşü ve bir API isteği ücreti doğurur. Arşivlere paketlemek işe yarar ancak dosya başına adreslenebilirliği ortadan kaldırır. DataSync’in aracısı (agent), birçok TCP akışı üzerinden paralelleştirme yapar, üstveriyi (metadata) yerel olarak işler, her dosyayı uçtan uca SHA-256 ile sağlama toplamı yaparak doğrular, şeffaf bir şekilde yeniden dener ve CloudWatch’a raporlar — aracı başına ~10 Gbps’ye kadar hıza ulaşırken GB başına öngörülebilir bir fiyatlandırma sunar.

Kaynaklar ve hedefler NFS, SMB, HDFS, kendi kendine yönetilen nesne depoları, S3, EFS, FSx for Windows File Server, FSx for Lustre, FSx for OpenZFS ve FSx for NetApp ONTAP’ı kapsar. Aktarımlar, aktarım sırasında TLS 1.2 kullanır ve genel internete çıkmamak için VPC arayüz uç noktalarından geçebilir.

Kritik bir ayrıntı: DataSync, şirket içi (on-premises) NFS/SMB kaynakları için bir aracı (agent) gerektirir. Aracı, VMware, Hyper-V veya KVM üzerinde bir sanal makine (VM) olarak, EC2’de veya Snowcone üzerinde çalışır. DataSync’in şirket içi için aracısız olduğuna inanmak yaygın bir tuzaktır — yalnızca her iki uç nokta da AWS’in yerel servisleri olduğunda aracısızdır.

Minimal bir dağıtım:

# Activate the on-prem agent
aws datasync create-agent \
  --activation-key ABCDE-12345-FGHIJ-67890-KLMNO \
  --agent-name onprem-nfs-agent \
  --vpc-endpoint-id vpce-0a1b2c3d

# Define source (NFS) and destination (S3)
aws datasync create-location-nfs \
  --server-hostname 10.0.5.20 \
  --subdirectory /export/video \
  --on-prem-config AgentArns=arn:aws:datasync:...:agent/agent-0abc

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::video-archive \
  --s3-config BucketAccessRoleArn=arn:aws:iam::111122223333:role/DataSyncS3Role

# Task with bandwidth cap, verification, and a nightly schedule
aws datasync create-task \
  --source-location-arn <nfs-arn> \
  --destination-location-arn <s3-arn> \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,BytesPerSecond=104857600,PreserveDeletedFiles=PRESERVE,PosixPermissions=PRESERVE \
  --schedule ScheduleExpression="cron(0 2 * * ? *)"

İki operasyonel özellik önemlidir. Bant genişliği kısıtlama (BytesPerSecond), paylaşılan bir bağlantının doyuma ulaşmasını engeller — bu, “diğer departmanlarla paylaşılan 1 Gbps bağlantı” senaryolarına doğrudan bir yanıttır. Filtreleme ve zamanlama, mesai dışı senkronizasyonlara ve geçici dosyaların hariç tutulmasına olanak tanır. Kullanıcıların okuma ve yazmaya devam ettiği 10 Gbps’lik bir Direct Connect üzerinden, tekrarlanan görevleri zamanlamak standart modeldir: ilk tarama verinin büyük kısmını aktarır, ardışık artımlı çalıştırmalar farkları yakalar ve 700 TB’lık veri, kısmi kullanımda bile bir haftadan çok daha kısa sürede aktarılabilir.

Daha incelikli bir tuzak, üstveri (metadata) doğruluğu ile ilgilidir. DataSync, özenle seçilmiş bir POSIX veya SMB nitelikleri setini — NFS için UID/GID/mod/zaman damgaları, SMB için sahiplik ve DACL’ler — korur, ancak her üreticiye özgü NAS niteliğini yakalamaz. Üreticiye özgü ACL’ler, protokolün sunduğunun ötesindeki genişletilmiş nitelikler, anlık görüntüler (snapshot) ve tekilleştirme üstverisi kapsamı dışındadır. Uyumluluk, satıcı özelliklerini de içeren tam bir NAS kopyası gerektirdiğinde, tek başına DataSync yetersizdir; FSx for ONTAP ile SnapMirror gibi NetApp’a özgü bir yol veya Storage Gateway aracılığıyla bir lift-and-shift (olduğu gibi taşıma) gereklidir.

DataSync ayrıca Snowball’u da tamamlar: Snowball ilk 150 TB’ı taşır ve DataSync daha sonra 500 GB’lık bir çalışma setinin haftalık devam eden farkını (delta) yönetir.

Storage Gateway: Hibrit Sunum, Taşıma Değil

Storage Gateway bir taşıma aracı değildir — hibrit bir sunum katmanıdır. Şirket içi uygulamalar NFS, SMB, iSCSI veya iSCSI-VTL konuşmaya devam ederken, veriler S3, S3 Glacier veya EBS anlık görüntülerine (snapshot) iner. Storage Gateway’i DataSync ile karıştırmak sık yapılan bir hatadır: File Gateway, 70 TB’ı aceleyle taşımak için tasarlanmamıştır ve DataSync, şirket içi istemcilere kalıcı bir paylaşım sunmaz.

File Gateway, bu işin yükünü çeken temel bileşendir. \\gateway\share\reports\2024\report.pdf yoluna yazmak, s3://bucket/reports/2024/report.pdf nesnesini üretir — bu, Athena, Lambda, EMR veya herhangi bir S3 istemcisi tarafından yerel olarak tüketilebilir. Bu bire bir dosya-nesne eşlemesi, kara kutu yedekleme hedeflerine göre büyük bir avantajdır. Yerel önbellekleme, sık erişilen dosyaların LAN hızında dönmesi anlamına gelir; seyrek erişilen dosyalar ise S3’ten talep üzerine akışla alınır.

Cihazın kilit noktası önbellektir. Sık erişilen veriler için okumalar yerel olarak sunulur; yazmalar önce yerel diske iner ve asenkron olarak yüklenir. Yaygın bir tasarım hatası, S3 destekli olmasının her okumanın internet gidiş-dönüş gecikmesine maruz kalacağı varsayımıdır — çalışma seti önbelleğe sığdığı sürece bu doğru değildir. Tersine, önbelleği yetersiz boyutlandırmak sürekli önbellek isabetsizliklerine (cache miss) neden olur ve iş yükü “yavaş” görünür. Pratik kural: önbellek = toplam veri setinin %20’si veya sık erişilen çalışma setinin %100’ü, hangisi daha büyükse.

Cached ve Stored modu tuzağı özel bir ilgiyi hak eder. Cached (Önbellekli) mod, birincil kopyayı S3’te tutar ve sık erişilen blokları yerelde barındırır — ucuz, esnektir, ancak bir önbellek isabetsizliği WAN gidiş-dönüşü demektir. Stored (Depolanmış) mod, birincil kopyayı yerel diskte tutar ve S3’e EBS anlık görüntüleri olarak asenkron anlık görüntüler alır — her okuma yerel ve düşük gecikmelidir, ancak tüm veri setinin şirket içine sığması gerekir. “Veriler AWS’ye yedeklenirken tüm verilere yerel erişim” gerektiren bir yedekleme senaryosu için Stored modu doğrudur; Cached modu bu gereksinimi ihlal ederdi. Tüm veri setine düşük gecikmeyle ihtiyaç duyan bir iş yükü için Cached modunu seçmek tasarımı boşa çıkarır; sitenin tüm veri setini barındıramadığı durumlarda Stored modunu seçmek ise tanım gereği imkansızdır.

Tape Gateway çok özel bir senaryoya yanıt verir: Veeam, NetBackup veya Commvault iş akışlarını olduğu gibi koruyarak fiziksel bir teyp kütüphanesini kullanımdan kaldırmak. Bunu, iSCSI üzerinden bir VTL sunarak ve verileri S3’ten Glacier veya Deep Archive’a yaşam döngüsüne sokarak yapar. Yasal saklama süreleri teyp medyası cinsinden tanımlandığında ve mevcut yedekleme yazılımı değiştirilemediğinde paha biçilmezdir.

AWS Transfer Family

Transfer Family, S3 veya EFS tarafından desteklenen tamamen yönetilen SFTP, FTPS, FTP ve AS2 uç noktaları sağlar. Değer önerisi, iş ortağına yönelik protokol sözleşmelerinin korunmasıdır: dosyaları yalnızca SFTP aracılığıyla yayan tedarikçi sistemleri bunu değiştirmeden yapmaya devam ederken, alıcı taraf yaşam döngüsü politikaları, Lambda tetikleyicileri ve analitik entegrasyonu ile yerel S3 olur.

Buradaki tuzak, eski tip bir tedarikçinin “doğrudan S3 API’lerine geçebileceğini” varsaymaktır. Birçok tedarikçi sistemi; cihazlar, hastane HL7 beslemeleri, bankacılık toplu işlem sistemleri veya SFTP istemcisi üretici yazılımına ya da imzalı ikili dosyalara gömülü olan B2B EDI işlem hatlarıdır. Bunlara dokunmanın değişiklik yönetimi, güvenlik incelemesi ve yeniden sertifikasyon maliyeti genellikle tüm AWS migrasyonunu aşar. Transfer Family bunu tamamen bertaraf eder. AS2 desteği ayrıca, B2B uyumluluğu için MDN alındıları ve mesaj imzalama/şifreleme ile EDI iş yüklerini mümkün kılar.

Kimlik doğrulama; hizmet tarafından yönetilen kullanıcıları, AWS Directory Service’i (şirket içi AD için Managed Microsoft AD veya AD Connector) veya API Gateway/Lambda aracılığıyla özel bir kimlik sağlayıcıyı destekler. Bu sayede mevcut kurumsal kimlik bilgileri doğruluk kaynağı olarak kalmaya devam eder. Bir Lambda yetkilendiricisi, kullanıcı başına IAM rolleri, ana dizin eşlemeleri ve oturum politikaları döndürerek, tedarikçi başına altyapı olmadan tedarikçi başına izolasyon sağlar.

Type: AWS::Transfer::Server
Properties:
  Protocols: [SFTP]
  IdentityProviderType: AWS_DIRECTORY_SERVICE
  IdentityProviderDetails:
    DirectoryId: d-9067f4a1c2
  Domain: S3
  EndpointType: VPC
  EndpointDetails:
    VpcId: vpc-0abc123
    SubnetIds: [subnet-0a, subnet-0b]
    SecurityGroupIds: [sg-0sftp]

Amazon AppFlow

AppFlow, SaaS’tan AWS’e veri hareketi için yönetilen entegrasyon katmanıdır: Salesforce, ServiceNow, Google Analytics, Slack, Marketo, SAP OData, Zendesk ve düzinelerce diğer kaynaktan S3, Redshift veya Snowflake’e akan veriler. Sayfalandırma, artımlı çıkarma, alan eşleme, filtreleme, maskeleme ve doğrulamayı elle yazılmış bir ETL işi olmadan halleder.

Güvenlik açısından kritik özellik, desteklenen bağlayıcılar (özellikle Salesforce) için PrivateLink entegrasyonudur. Akış, SaaS kiracısına ulaşmak için genel internete çıkıp AWS’e geri dönmek yerine, özel bir VPC uç noktası üzerinden geçer. Bu, çıkarılan veri yüklerinin genel internete maruz kalmasını ortadan kaldırır ve sağlık, finans ve Kişisel Tanımlanabilir Bilgi (PII) iş yükleri için denetim duruşunu basitleştirir. Akışlar zamanlanabilir, SaaS kayıt değişiklikleriyle olay tetiklemeli olabilir veya isteğe bağlı çalıştırılabilir ve akış yürütme başına 100 GB’a kadar destekler.

AppFlow, DataSync veya Storage Gateway’den daha yüksek bir katmanda çalışır: kaynak bir dosya sistemi veya veritabanı değil de API güdümlü bir SaaS olduğunda doğru araçtır.

Veritabanı Migrasyonu: DMS ve SCT

AWS Database Migration Service, kaynak tam olarak çalışır durumda kalırken kaynak ve hedef veritabanları arasında verileri çoğaltır. Homojen (MySQL → RDS MySQL, Oracle → RDS Oracle) ve heterojen (Oracle → Aurora PostgreSQL, SQL Server → MySQL) migrasyonları destekler ve hedefler RDS’in ötesine Aurora, Redshift, S3, DynamoDB ve Kinesis’e kadar uzanır. Kaynaklar arasında Oracle, SQL Server, MySQL, PostgreSQL, MongoDB ve Db2 bulunur.

Bir görev üç moddan birinde çalışır:

Minimum kesintiyle geçişin motoru Değişiklik Verisi Yakalama (Change Data Capture - CDC)‘dir. Tam yükleme ve CDC sırasında DMS, kaynak işlem günlüğünü (Oracle redo, MySQL binlog, SQL Server MS-CDC veya MS-Replication) ayrıştırırken mevcut satırları toplu olarak kopyalar. Tam yükleme tamamlandığında, CDC kuyruktaki değişiklikleri uygular ve uygulama geçiş yapana kadar hedefi sürekli güncel tutar. Uygulamanın yazılabilir kalması gerektiğinde CDC’yi etkinleştirmemek yaygın bir mimari hatadır: yalnızca tam yükleme, yükleme tamamlandığı anda hedefi bayat bırakır.

{
  "MigrationType": "full-load-and-cdc",
  "ReplicationTaskSettings": {
    "TargetMetadata": { "ParallelLoadThreads": 8 },
    "ChangeProcessingTuning": { "BatchApplyEnabled": true }
  }
}

Heterojen işler için, AWS Schema Conversion Tool (veya buluttaki benzeri DMS Schema Conversion), DDL, saklı yordamlar, görünümler ve fonksiyonları çevirir ve manuel olarak yeniden yazılması gereken öğeleri işaretler. DMS veriyi taşır; SCT şemayı dönüştürür. SCT değerlendirme raporunu atlamak, migrasyonların geçişten üç gün önce başarısız olmasına neden olur.

Motora özgü önkoşullar ve sınırlamalar göz ardı edilirse ciddi sorunlar yaratır. 64 KB üzerindeki Oracle LOB’ları, sabit bir maksimum değere sahip sınırlı LOB modu gerektirir; LONG RAW‘ın kendine özgü durumları vardır. PostgreSQL, wal_level=logical ve bir replikasyon rolü gerektirir. MySQL, yeterli binlog_row_image ile ROW formatında ikili günlük kaydı (binary logging) ve yükseltilmiş CDC ayrıcalıkları (REPLICATION CLIENT, REPLICATION SLAVE) gerektirir. Oracle Spatial, RAC’a özgü davranışlar ve SQL Server CLR assembly’leri genellikle desteklenmez. Replikasyon örneği (instance) ve uç noktalar arasında TLS, require, verify-ca veya verify-full SSL modları ile zorunlu kılınır.

DMS Serverless, iş yükü profili öngörülemez veya anlık yoğunluklu olduğunda (örneğin, gündüzleri ani yoğunluklar yaşayan ve geceleri sakin olan şirket içi bir Oracle sistemi) doğru seçimdir. DCU (DMS Kapasite Birimleri) cinsinden MinCapacityUnits ve MaxCapacityUnits tanımlarsınız ve DMS, CPU ve bellek baskısına göre replikasyon kapasitesini ölçeklendirir:

ReplicationConfigIdentifier: oracle-to-rds-cdc
ReplicationType: full-load-and-cdc
SourceEndpointArn: arn:aws:dms:...:endpoint:oracle-onprem
TargetEndpointArn:  arn:aws:dms:...:endpoint:rds-oracle
ComputeConfig:
  MinCapacityUnits: 4
  MaxCapacityUnits: 64
  MultiAZ: true

Sık düşülen bir tuzak, sağlanmış (provisioned) bir DMS örneğinin (ör. dms.c5.4xlarge) otomatik olarak ölçekleneceğini varsaymaktır. Ölçeklenmez — sağlanmış örnekler sabit boyutlu EC2 sunucularıdır. İş hacmi kapasiteyi aşarsa, replikasyon gecikmesi artar ve görevleri yeniden başlatarak örnek sınıfını manuel olarak değiştirmeniz gerekir. Sağlanmış DMS, bilinen iş hacmine sahip kararlı durumdaki migrasyonlara uygundur; Serverless ise öngörülemeyenler için uygundur.

İki haftalık bir zaman aralığı ve kısıtlı kesinti süresi olan 20 TB’lık bir MySQL migrasyonu için, Aurora MySQL veya RDS MySQL’e tam yükleme artı CDC ile DMS kullanmak maliyet etkin bir hamledir. Yerel mysqldump/mysqlpump geri yüklemeleri kabul edilemez kesinti sürelerine neden olur; Snowball ise nakliye gecikmesi ve çevrimdışı kalma boşlukları ekler.

DMS Fleet Advisor, şirket içi veritabanı envanterlerini keşfeder ve dalga planlaması için kullanışlıdır.

Sunucu Geçişi: AWS Application Migration Service (MGN)

AWS Application Migration Service, birincil lift-and-shift (“rehost”) hizmetidir ve çoğu kullanım durumu için CloudEndure Migration ve Server Migration Service’in yerini almıştır. MGN, her bir kaynak sunucuya (fiziksel, VMware, Hyper-V veya başka bir bulut) hafif bir AWS Replication Agent kurar. Bu aracı, hedef VPC’deki düşük maliyetli bir hazırlık alanına — bağlı EBS birimlerine sahip küçük T3 örnekleri (instance) — blok seviyesinde ilk anlık görüntüyü (snapshot) alır ve ardından blok seviyesindeki değişiklikleri sürekli olarak eşzamansız bir şekilde çoğaltır (replicate). Çoğaltma blok seviyesinde ve sürekli olduğu için, geçiş (cutover) dakikalar içinde tamamlanır: MGN, geçiş anında hazırlık birimlerini hedef örnek türündeki üretim EC2 örneklerine dönüştürür.

1. Install replication agent on each source (or use agentless for vCenter)
2. Configure launch template (instance type, subnet, IAM role, tags)
3. Run "Test" launches → validate → "Cutover" launch → decommission source

Test başlatmaları çok önemlidir ve genellikle atlanır. MGN, devam eden çoğaltmayı kesintiye uğratmadan mevcut çoğaltma durumundan yalıtılmış test örnekleri başlatır. Uygulama davranışını doğrular, testi sonlandırır, yineleme yapar ve yalnızca testler başarılı olduğunda geçişi başlatırsınız — geçiş, çoğaltmayı durdurur, son örneği başlatır ve geçiş dalgasını (wave) tamamlandı olarak işaretler.

Yanlış yaklaşım, VM’leri manuel olarak OVF’ye aktarmak, aws ec2 import-image aracılığıyla yüklemek ve yeni sağlanan EC2 örneklerine uygulamaları yeniden yüklemektir. Bu yavaş, hataya açık bir yöntemdir, VM başına dışa aktarma süresine eşit kesinti gerektirir, delta çoğaltma sağlamaz ve kesintisiz test imkanı sunmaz. MGN tüm bunları ortadan kaldırır — kaynak, son geçiş saniyesine kadar çalışmaya devam eder ve kaynak ile hedef arasındaki sapma (drift) neredeyse sıfırdır.

Genel portföy kılavuzu, önce rehost yapmak, ardından yineleme maliyetinin daha düşük olduğu Bölge (Region) içinde re-platform veya refactor yapmaktır. Eş zamanlı refactor ve geçiş, telafi edici bir fayda sağlamadan riski katlar.

Hibrit Bağlantı: Direct Connect ve VPN

AWS Direct Connect, şirket içi (on-prem) bir yönlendiriciden bir Direct Connect konumuna tahsis edilmiş bir Katman 2 (Layer 2) devresi sağlar ve tutarlı bant genişliği (1, 10, 100 Gbps tahsis edilmiş; iş ortağı tarafından barındırılan bağlantılar aracılığıyla 1 Gbps’nin altı) ve öngörülebilir gecikme süresi sunar. Sanal Arayüzler (Virtual Interface) devreyi bölümlere ayırır:

• Özel VIF (Private VIF) — bir Sanal Özel Ağ Geçidi (Virtual Private Gateway) aracılığıyla tek bir VPC’ye erişim.
• Transit VIF — bir Transit Gateway’e bağlı bir Direct Connect Gateway aracılığıyla birçok VPC’ye erişim. Bu, büyük, çoklu VPC’li, çoklu sahalı ortamlar için standart modeldir.
• Genel VIF (Public VIF) — internet üzerinden geçmeden AWS genel hizmet uç noktalarına (S3, DynamoDB) erişim.

DX, tek başına yüksek oranda erişilebilir (highly available) değildir: tek bir DX konumundaki tek bir devre, tek bir fiber yoluna bağlıdır. İki esneklik (resilience) modeli önemlidir:

1. DX + internet üzerinden Site-to-Site VPN yedeği, minimum uygulanabilir HA’dır. BGP, kararlı durumda DX’i tercih etmek için AS-path prepending, MED veya local-pref kullanarak otomatik yük devretmeyi (failover) yönetir.
2. Ayrı DX konumlarında çift DX devresi, kritik görevli iş yükleri için maksimum esneklik modelidir ve DX SLA’sı için gereklidir.

Herhangi bir yedek yol sağlamamak, bilinen bir tuzaktır: DX başarısız olduğunda ve VPN olmadığında, hibrit uygulamalar, DataSync işleri ve Storage Gateway yüklemeleri, operatör onarımı süresince durur. Sadece VPN kullanmak, daha düşük verim gerektiren iş yükleri için veya haftalar sürebilen DX kurulumu sırasında bir köprü olarak kabul edilebilir.

On-prem Router ──── DX (primary, BGP MED=100) ────┐
                                                   ├── VGW/DXGW ── VPC
On-prem Router ──── VPN over Internet (backup) ────┘

# Multi-VPC access via DX Gateway
DirectConnectGateway:
  Associations:
    - TransitGateway: tgw-corp
    - VirtualPrivateGateway: vgw-prod-vpc
  AllowedPrefixes:
    - 10.0.0.0/8

Fiziksel katman şifrelemesinin zorunlu olduğu durumlarda, MACsec özellikli bir DX bağlantısı seçin. Bant genişliği için DX, orkestrasyon için DataSync ve sürekli yerel erişim için Storage Gateway’i birleştirmek, kesinti süresine toleransı olmayan büyük, canlı veri setleri için standart hibrit modeldir.

Şirket İçi AWS Altyapısı için AWS Outposts

Outposts, AWS altyapısını tam olarak yönetilen bir kabin (rack) (veya 1U/2U Outposts sunucuları) olarak bir müşteri tesisine genişletir. Belirli bir hizmet setini — EC2, EBS, ECS, EKS, RDS, S3 on Outposts, EMR — ana Bölge (Region) ile aynı API’leri kullanarak yerel olarak çalıştırır. Kontrol düzlemi (control-plane) işlemleri, yedekli şifreli tünellerden oluşan bir hizmet bağlantısı (service link) üzerinden ana Bölge’ye geri akar; bir WAN kesintisi geçici olarak yeni örneklerin başlatılmasını engeller ancak çalışan iş yüklerini durdurmaz.

Paylaşılan sorumluluk ayrımı, operatörleri tuzağa düşüren noktadır. AWS, donanımı, hipervizörü (hypervisor) ve yönetilen hizmetleri teslim eder ve bakımını yapar. Müşteri şunlardan sorumludur:

• Outposts özelliklerini karşılayan fiziksel alan, güç, soğutma ve ağ (yedekli güç kaynakları, yukarı akış anahtarları (upstream switch), uygun PDU’lar).
• Tesisin fiziksel güvenliği.
• Yerel ağ yapılandırması — şirket içi (on-prem) trafik için Yerel Ağ Geçidi (Local Gateway - LGW) ve hizmet bağlantısı yukarı bağlantısı (uplink).
• İş yüklerinin işletim sistemi ve uygulama sorunları, tıpkı Bölge’de olduğu gibi.
• Ana Bölge’ye geri dönen yeterli WAN bağlantısı.

Outposts, operasyonları ortadan kaldırmaz — soyutlama katmanını değiştirir. AWS’nin veri merkezi gücünden veya yukarı akış ağından sorumlu olduğunu varsaymak temel bir yanlış anlamadır. Ayrıca “herhangi bir AWS hizmetini şirket içinde çalıştırmak” anlamına da gelmez: desteklenen liste sınırlıdır ve Route 53 veya IAM gibi hizmetler Bölge tabanlı kalır.

Verilerin yasal nedenlerle şirket içinde kalması gereken bir Hadoop/Spark modernizasyonu için doğru model EMR on Outposts’tur — Bölge içi araçlarla ve yerel veri yerleşimiyle (data residency) yönetilen, elastik Spark kümeleri. Storage Gateway veya DataSync, yerleşim gereksinimini karşılamaz; Bölge içi EMR’ye lift-and-shift yapmak ise uyumluluğu ihlal eder.

Uç Filolarına İçerik Dağıtma

Outposts sunucuları, perakende mağazaları veya uç cihazlar, örneğin gecelik bir yazılım sürümü gibi aynı büyük veriyi tekrar tekrar çektiğinde, tek bir Bölge’deki (Region) bir S3 bucket’ından doğrudan çekim yapmak, uplink bağlantılarını doyurur ve dağıtım süresini artırır. Doğru desen, S3 origin’li CloudFront ve imzalı URL’ler (signed URLs) kullanmaktır:

S3 bucket (ap-northeast-1)  ← Origin Access Control
        │
   CloudFront distribution (global edge PoPs)
        │
   Signed URLs (short expiry, per-server or per-release)
        │
   Edge devices download from nearest PoP

Bir bölgedeki ilk cihaz, uç önbelleği (edge cache) ısıtır; sonraki her cihaz uç gecikme süresiyle (edge latency) veri çeker. İmzalı URL’ler, cihaz başına IAM kimlik bilgileri olmadan yetkisiz indirmeleri önler ve yönetilecek bir bölgesel replika filosu yoktur.

Kaçınılması gereken iki anti-desen şunlardır: sürümü tek bir EC2 web sunucusunda barındırmak (bir ölçeklendirme ve gecikme felaketi) ve sadece indirme gecikmesini azaltmak için S3 bucket’ını Bölgeler Arası Replikasyon (Cross-Region Replication) aracılığıyla her Bölge’ye çoğaltmak (CloudFront önbelleklemenin ücretsiz olarak çözdüğü gereksiz depolama maliyeti ve operasyonel karmaşıklık).

Karar Özeti

← Depolama ve Veri Yaşam Döngüsü · Tüm alanlar · Ağ Oluşturma ve Bağlanabilirlik →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Amazon'a göz atın →