💻
Cheet Sheets
  • 🦁Başlarken
  • 🟧DevOps Pre-Requisite
    • ❤️Why Linux? | Linux Basics #1
    • 💛Vi Editor | Linux Basics #2
    • 💙Basics Commands | Linux Basics #3
    • 🧡Package Managers | Linux Basics #4
    • 💚Services | Linux Basics #5
    • 💛Networking Basics
    • 🤎DNS Basics
    • 🩶Applications Basics
    • 🟨Java introduction
    • 🟩NodeJS Introduction
    • 🟦Python Introduction
    • 🟪GIT Introduction
    • 🟧Apache Web Server Introduction
    • ⬛Apache Tomcat
    • 🟫Python Flask
    • 🟥Node.js Express App
    • 🟨Databases
    • 🟩MySQL
    • 🟪MongoDB
    • 🟨SSL & TLS
    • 🟦YAML & JSON - JSON Path
    • ⬛Labs Resources
  • 🍎Kubernetes
    • 🍏Kubernetes: Nedir ?
    • 🍒Bileşenler
    • 🍵Kubectl ve Versiyon
    • ❤️Pod
    • 🏷️Label ve Selector
    • 🔎Annotation
    • 📲Namespaces
    • 📦Deployments
    • 🔁ReplicaSet
    • 🔙Rollout & Rollback
    • 🌐Networking - 1
    • 🌏Service
    • 🛠️Liveness Probe & Readiness Probe
    • 🥐Resource Limits
    • 💰Environment Variables
    • 📃Ephemeral Volumes
    • 🔑Secrets
    • 🌂ConfigMap
    • 🖥️Node Affinity
    • 🔌Pod Affinity
    • ✍️Taint and Toleration
    • 🔦DaemonSet
    • 🧀PV/PVC
    • 🌜Storage Class
    • 🗿StatefulSet
    • 🕹️Job & Cronjob
    • 🔐Authentication
    • 📏Role-based access control (RBAC)
    • 🈷️Service Account
    • 📈Ingress
    • 📂ImagePullPolicy & ImageSecret
    • 📖Static Pods
    • 🌐Network Policy
    • 🫐Helm Nedir?
    • 📽️Prometheus Stack - Monitoring
    • 💼EFK Stack - Monitoring
    • 🥳CRD & Operator
  • 🧑‍⚕️GIT & GITHUB
    • 👉Girizgah
    • 🌴Branch
    • 🤝Merge
    • 🤔Conflict - Rebase
    • 🇸🇴Alias
    • 🛑Gitignore
    • 🥢Diff
    • ◀️Checkout
    • 🔦Stash
    • 👉Other
  • ☁️AWS
    • 🪣S3
    • 🚙EC2
    • ⚖️ELB
    • 🤝Auto Scaling
    • 🗄️EFS
    • 🔐VPC
    • 🎆CloudFront
    • ❤️Route53
    • 🦈RDS
    • 🏢ElastiCache
    • 🔭CloudWatch
    • 👀CloudTrail
    • 📃CloudFormation
    • 🔕SNS
    • 📬SQS
    • 🎇SWF
    • 📧SES
    • 📦Kinesis
    • 📐AWSConfig
    • 👩‍🏭OpsWork
    • 🚀Lambda - Api Gateway
    • 📌ECS - EKS
    • 🔑KMS
    • 📂Directory Service
    • 🏐Snowball
    • 💾Storage Gateway
    • 💽Volume Gateway
    • 📼Tape Gateway
    • 🏠Organizations
    • 🔙Backup-Transfer-CloudShell
    • 🆔IAM
    • 📀DataSync
    • 🗃️FSx
    • 🎒Aurora Serverless
    • 🌐Global Accelerator
    • 💪HPC
    • 🎰Outposts
    • 🗼Others
  • 👨‍🔬Ansible
    • 👉Girizhah
    • 📔YAML
    • ⚙️Komponentler
    • 🎒Inventory
    • 🏑ad-hoc
    • ▶️Playbook
  • 👨‍⚕️PROMETHEUS
    • 📈Terminoloji
    • 🦯Ubuntu 20.04 Prometheus Kurulum
    • 🗒️prometheus.yml dosyasına ilk bakış:
    • 🧭promQL up query
    • 📇Exporters
    • 🔦promQL Data Types
    • 🦯Selectors & Matchers
    • 🔢Binary Operators
    • 💀ignoring and on
    • ✍️Aggregation Operators
    • 🧠Functions
    • 🖊️Alıştırma
    • 💻Client Libraries
    • 🐍Examining the data of our Python application
    • 🐐Examining the data of our GO application
    • ⏺️Recording Rules
    • 💡rate functions
    • ⏰Alerting
    • ⌚Alert Routing
    • ⏰Slack integration with Prometheus
    • 🤯PagerDuty integration with Prometheus
    • ◼️BlackBox exporter
    • 📍Push Gateway
    • 🪒Service Discovery
    • 🧊kube cadvisor with external prometheus
    • 👉aws with prometheus
    • ☁️CloudWatch Exporter
    • 👨‍🚒mysql exporter
    • 🛃Custom exporter with Python
    • ⚙️Prometheus with HTTP API
    • 🤖Prometheus Federation For Kubernetes
    • 📺Grafana
    • ⁉️Prometheus: Ne zaman kullanılmalı? Ne zaman kullanılmamalıdır?
  • 🍪Sheets
    • 🛳️Docker Sheets
    • 🐐Kube Sheets
  • 🔢12 Factor APP
    • 🏗️Introduction
    • 1️⃣Codebase
    • 2️⃣Dependencies
    • 3️⃣Concurrency
    • 4️⃣Processes
    • 5️⃣Backing Services
    • 6️⃣Config
    • 7️⃣Build, release, run
    • 8️⃣Port binding
    • 9️⃣Disposability
    • 🔟Dev/prod parity
    • 🕚Logs
    • 🕛Admin processes
  • ☁️Azure 104
    • 👨‍👨‍👧‍👧Azure Active Directory ( Entra ID )
    • 💰Subscriptions
    • 🌎Virtual Network (VNET)
    • 💻Virtual Machines
    • 🧑‍🌾Load Balancing
    • 🥍Network Advanced
    • 🪡Automating Deployment and Configuration
    • 💂Securing Storage
    • 📓Administering Azure Blobs and Azure Files
    • 🔧Managing Storage
    • 🎁App Service
    • 🛳️Azure Container
    • 🥇Backup And Recovery
    • 🪐Network Watcher
    • ⏰Resource Monitoring And Alerts
  • ⛅AZURE 305
    • 🆔identity and access management
    • 💼Desing Azure AD (Entra ID)
    • 👨‍💼Desing for Azure B2B
    • 🛃Desing for Azure B2C
    • 💳Design for MFA and Conditional Access
    • ⛑️Design for Identity Protection
    • 🚶Access Reviews
    • 🚦Managed identity Demostration
    • 🔐Key Vault Demostration
    • 👑Governance hierarchy
    • 💠Design for Management Groups
    • 🔑Desing for Subscriptions
    • 🍇Desing for resource groups
    • 📟Design for resource tags
    • 🚷Azure Policy & RBAC
    • 🫐Desing For Blueprints
    • 🪡Desing for Virtual Networks
    • 🛫Design for on-premises connectivity to Azure
    • 🔽Design for network connectivity
    • 📦Design for application delivery
    • 🥞Design for network security and application protection
    • 📕Choose a compute solution
    • 🌊Design for virtual machines
    • 🔋Azure Batch Demostration
    • 🛰️Design for Azure App Service
    • ⛲Design for Azure Container Instances
    • 🎢Design for Azure Kubernetes Service
    • 📠Azure Functions Demostration
    • 💪Azure Logic Apps Demostration
    • 🧑‍💼Design for data storage
    • 🎞️Design for Azure storage accounts
    • 🌟Choose the storage replication
    • 📹Azure blob storage - Lifecycle & immutable demo
    • 🥌Azure Files Demostration
    • 🕸️Design Azure disks
    • 🦼Design for storage security
    • 🔮Azure Table Storage And Cosmos DB Demostration
    • 🟧Azure SQL Solutions
    • 🎡Azure SQL Database - Purchasing models
    • 🕯️Database availability
    • 📜Data security strategy
    • 🧮Azure SQL Edge
    • 🚲Azure Data Factory
    • 🔅Azure Data Lake Storage
    • 🧘‍♂️Azure Databricks
    • 🎒Azure Synapse Analytics
    • 🅰️Azure Stream Analytics
    • 📼Data flow strategy
    • 🍥Cloud Adoption Framework
    • ☣️Azure Migration Framework
    • 🦿Assessing workloads
    • 🪡Migration tools
    • 🤖Azure Database migration
    • 👥Storage migration
    • 👜Azure Backup
    • ⏲️Azure Blob Backup and Recovery
    • 💈Azure files backup and recovery
    • 🎞️Azure VM backup and recovery
    • 🧺Azure SQL backup and recovery
    • ⏰Azure Site Recovery
    • 📩Differentiate event and message
    • ✈️Azure messaging solutions
    • 🚜Event Hub
    • 🥍Application optimization solution
    • 🎁Application lifecycle
    • 📺Azure Monitor
    • 🅱️Log Analytics
    • 👥Azure workbooks and Insights
    • 🚌Azure Data Explorer
  • Github Actions
    • Github Actions Nedir?
    • Workflow & Schedule Triggers
    • Single and Multiple Events
    • Manuel Events
    • Webhook Events
    • Conditional Keywords For Steps
    • Expressions - 1
    • Expressions - 2
    • Runners
    • Workflow Commands
    • Workflow Context
    • Dependent Jobs
    • Encrypted Secrets
    • Configuration Variables
    • Default & Custom Env Varb
    • Set Env Varb with Workflow Commands
    • Github Token Secret
    • Add Script to workflow
    • Push Package #1
    • Push Package #2 Docker
    • Service Containers
    • Routing workflow to runner
    • CodeQL Step
    • Caching Package and Dependency Files
    • Remove workflow Artifact
    • Workflow Status Badge
    • Env Protection
    • Job Matrix Configuration
    • Disable & Delete Workflows
    • Actions type for Action
    • Inputs and Outputs for actions
    • Action Versions
    • Files and Directories for Actions
    • Exit Codes
    • Reusable Workflow & Reuse Templates for Actions and Workflows
    • Configure Self Hosted Runners for Enterprise
  • Loki
    • What is Loki?
    • Architecture of Loki
    • Install Loki For Ubuntu
    • Install Promtail For Ubuntu
    • Querying Logs
    • Loki in Kubernetes
    • Deploying Loki in Kubernetes
    • Connecting to Grafana
    • Viewing Kubernetes logs
    • Promtail Customize & Pipeline
  • Ansible
    • Ansible Introduction
    • Introduction to Ansible Configuration Files
    • Ansible Inventory
    • Inventory Formats
    • Ansible Variables
    • Variable Types
    • Registering Variables and Variable Precedence
    • Variable Scoping
    • Magic Variables
    • Ansible Facts
    • Ansible Playbooks
    • Verifying Playbooks
    • Ansible lint
    • Ansible Conditionals
    • Ansible Conditionals based on facts, variables, re-use
    • Ansible Loops
    • Ansible Modules
    • Introduction to Ansible Plugins
    • Modules and Plugins Index
    • Introduction to Handlers
    • Ansible Roles
    • Ansible Collections
    • Introduction to Templating
    • Jinja2 Templates for Dynamic Configs
  • 🅰️Ansible Advanced
    • Playbook run options
    • Facts
    • Configuration files
Powered by GitBook
On this page
  • Single network approach;
  • Multiple peered networks;
  • Hub spoke architecture;
  • Design outbound connectivity;
  • Routing;

Was this helpful?

  1. AZURE 305

Design for network connectivity

PreviousDesign for on-premises connectivity to AzureNextDesign for application delivery

Last updated 1 year ago

Was this helpful?

Single network approach;

Azure'da "Single network approach" (Tek ağ yaklaşımı), tüm kaynakların tek bir sanal ağ içerisinde yerleştirildiği ve ağ segmentasyonunun alt ağlar (subnets) kullanılarak gerçekleştirildiği bir ağ tasarım stratejisini tanımlar. Ekran görüntüsündeki örnekten yola çıkarak, Sanal ağın içinde üç farklı alt ağ (subnet) bulunur: frontendSubnet, midSubnet ve dbSubnet.

  • frontendSubnet: Genellikle kullanıcıların erişim sağladığı web sunucuları veya uygulama ön yüzleri gibi kaynakları barındıran alt ağdır.

  • midSubnet: Uygulamanın iş mantığı veya işlemlerini yürüten arka uç sunucular (backend servers) gibi ara katman kaynakları için ayrılmıştır.

  • dbSubnet: Veritabanı sunucuları gibi veri depolama kaynaklarının yer aldığı alt ağdır.

Bu yapı, farklı türdeki kaynakları mantıksal olarak ayırarak yönetimi kolaylaştırmayı ve güvenliği artırmayı amaçlar. Örneğin, dbSubnet içindeki SQL sunucuları genellikle yalnızca midSubnet içindeki uygulama sunucularından gelen trafiğe izin verecek şekilde kısıtlanabilir, bu da veritabanı katmanını doğrudan dış tehditlere karşı daha güvenli hale getirir.


Multiple peered networks;

Azure'da "Multiple peered networks", birbiriyle eşleştirilmiş birden fazla sanal ağın olduğu bir yapıyı ifade eder. Bu, farklı sanal ağlar arasında doğrudan, güvenli ve özel bir bağlantı kurulmasını sağlar, ve bu Azure'un Virtual Network Peering özelliği aracılığıyla mümkündür.

Örnekteki ekran görüntüsü, Azure'da "Multiple peered networks"ın nasıl yapılandırılabileceğini gösterir. İki farklı Azure Bölgesi gösterilmekte: Bölge A ve Bölge B. Her bölgede ayrı sanal ağlar bulunmakta ve bu ağlar (Virtual Network A, B ve C olarak gösterilmiş) birbirleriyle eşleştirilmiş durumda:

  • Azure Region A içinde iki sanal ağ (Virtual Network A ve B) bulunmaktadır. Her biri kendi frontendSubnet ve dbSubnet'lerine sahip olacak şekilde yapılandırılmıştır.

  • Azure Region B içinde ise bir sanal ağ (Virtual Network C) ve içinde bir appSubnet bulunmaktadır.

Bu çoklu eşleştirilmiş ağ yapısı, farklı coğrafi bölgelerde veya farklı ağlar arasında yüksek kullanılabilirlik ve yük dengesi sağlamak için kullanılabilir. Örneğin, bir bölgede sorun olması durumunda, diğer bölge ağ trafiği devralabilir.

Virtual Network Peering, Azure'daki ağlar arasında düşük gecikme süresi ile yüksek bant genişliğinde veri aktarımına izin verir ve çeşitli ağlar arasında kaynakların birbirleriyle sorunsuz bir şekilde iletişim kurmasını sağlar.


Hub spoke architecture;

Azure'da "Hub and Spoke architecture" (Merkez ve Spoke mimarisi), bir merkez (Hub) sanal ağın, bir dizi Spoke sanal ağ ile eşleştirildiği bir ağ topolojisini ifade eder. Bu yapı, özellikle geniş ve karmaşık ağ yapılarında tercih edilir. Genel olarak, merkez sanal ağ ortak kaynakları (örneğin, güvenlik hizmetleri, VPN bağlantıları veya Azure'daki diğer ortak hizmetler) barındırırken, Spoke sanal ağlar ise özel iş yüklerini, uygulamaları veya hizmetleri içerir.

Örnekteki ekran görüntüsünde, iki Azure Bölgesi (A ve B) içerisinde bu topoloji gösterilmektedir:

  • Her iki bölgede de merkezde bir "Hub" ağ bulunmaktadır. Bu merkez ağlar, çevresindeki Spoke ağlara bağlantılar sağlar.

  • Her Spoke ağı, özel iş yüklerini veya servislerini barındırır ve merkez ağa bağlıdır, böylece merkezdeki kaynaklardan yararlanabilir.

  • Ayrıca, Bölge A'daki Hub, Bölge B'deki Hub ile eşleştirilebilir, böylece farklı bölgeler arasında da kaynak paylaşımı ve iletişim mümkün hale gelir.

Bu yapı, farklı iş yüklerini ve servisleri merkezi bir konumdan yönetmeyi kolaylaştırır ve ağ güvenliği ile izolasyonunu artırır. Örneğin, güvenlik politikaları ve erişim kontrol listeleri (ACL) merkez ağda merkezi olarak yönetilebilir ve Spoke ağlar arasında tutarlılık sağlanabilir. Ayrıca, bu yapı esneklik ve ölçeklenebilirlik sunar; yeni Spoke ağlar kolayca eklenebilir ve mevcut ağ yapılarına entegre edilebilir.


Design outbound connectivity;

Azure'da "Design outbound connectivity" (Dışa çıkış trafiğini tasarlamak), bir sanal ağdan dış ağlara (örneğin, internete) yapılan trafiğin nasıl yönlendirileceğini ve kontrol edileceğini planlamak anlamına gelir. Azure sanal ağlarında dışa çıkış trafiğini yönetmek için kullanılabilecek üç farklı servisi inceleyelim.

  1. Azure Firewall: Sanal ağdan gelen tüm dışa çıkış trafiğini kontrol etmek için kullanılır. Kullanıcı Tanımlı Yönlendirme Kuralları (UDRs) ile birlikte kullanılarak, tüm dışa çıkış trafiği belirli güvenlik politikaları ve kurallar setine uymak üzere zorlanabilir.

  1. Azure Load Balancer: Dışa çıkış trafiğini yönlendirmek ve dengelenmesini sağlamak için kullanılır. Özellikle, yüksek kullanılabilirlik ve ölçeklenebilirlik gerektiren senaryolarda, çıkan trafiğin Azure Load Balancer üzerinden geçmesi ve buna göre dağıtılması sağlanabilir.

  2. NAT Gateway: Dışa çıkış trafiğinin, tanımlı bir dizi genel IP adresi (Public IP) kullanarak NAT yoluyla yönlendirilmesini sağlar. Bu, özellikle sanal ağdaki kaynakların internete çıkış yaparken kullanacakları IP adreslerini kontrol etmek ve özelleştirmek istediğinizde kullanışlıdır.

Bu üç servis, bir Azure sanal ağının güvenlik, yönetim ve ölçeklenebilirlik ihtiyaçlarını karşılamak için birlikte veya ayrı ayrı kullanılabilir. Tasarım, ihtiyaçlara göre yapılandırılabilir, örneğin bazı sunuculara veya sanal ağlara ait trafiğin Azure Firewall üzerinden filtrelenmesi gerekebilirken, diğer trafikler için LB veya NAT daha uygun olabilir.


Routing;

  1. Sistem Yönlendirmesi (System Route): Azure, bir sanal ağ oluşturduğunuzda otomatik olarak sistem yönlendirmelerini ekler. Bu yönlendirmeler, sanal ağ içindeki kaynakların birbiriyle ve internetle iletişim kurmasını sağlar. Sanal ağlar arası eşleme yapıldığında, eşlenen ağın adres alanı da bu yönlendirme tablosuna dahil edilir.

  2. Kullanıcı Tanımlı Yönlendirme (User Defined Route - UDR): Sistem yönlendirmelerinin üzerine yazarak daha spesifik trafik akışı kuralları belirlemenizi sağlar. UDR'ler, trafik akışının belirli bir sonraki adıma (next hop) - örneğin bir Azure Firewall'a - yönlendirilmesini sağlamak için kullanılır.

Diagramda, sistem yönlendirme kullanılarak front-end ve veritabanı alt ağlarının (subnets) internete nasıl bağlandığı ve bir UDR kullanılarak bu trafik akışının Azure Firewall üzerinden nasıl yönlendirildiği gösteriliyor.

BGP Protokolü yönlendirmeleri, sistem yönlendirmelerine göre daha yüksek önceliğe sahipken, UDR'ler her zaman en yüksek önceliğe sahiptir ve sistem veya BGP yönlendirmelerinin üzerine yazabilir. Bu, ağ yöneticilerine trafik akışını çok detaylı bir şekilde kontrol etme yeteneği verir.

⛅
🔽