IT Fundamentals: Hardware, Networking, Cloud, Security, and Databases from a 13-Hour Course

Kaynak
en
Apr 28, 2026 Sep 24, 2026
Video preview
Paylaş:

This 13-hour course provides a high-level IT foundation covering hardware, operating systems, networking, IP addressing and subnetting, cloud computing with AWS, security, databases, and DevOps. It includes hands-on labs such as creating custom VPCs, launching EC2 instances, configuring security groups and network ACLs, and using Bash for automation.

Course Overview and Instructor Introduction ⏱ 0:00

  • •The course provides a high-level IT foundation covering networking, IP addressing, DevOps, site reliability engineering, hardware, AWS cloud, Docker, and Kubernetes; taught by Asa, a certified Cisco and AWS instructor with close to three decades in IT.
  • •The instructor argues modern IT entry no longer requires spending 6 to 12 months and significant money on A+, Network+, CCNA, and MCSA; content should move you from point A to point B quickly without fluff, minimize effort and cost, and not overwhelm beginners.
  • •The course blends topics in a scaffolding approach: computer and hardware components (CPU, memory, GPU, NIC), PC vs server, virtualization, data centers, cloud, networking devices, IP addressing, public vs private IPs, cloud VPC design, security groups and network ACLs, AWS hands-on practice with an account and $100 free credit, DevOps, site reliability engineering, and platform engineering.
  • •No career commitment is required before taking the course; learners can explore roles like network engineer, cloud engineer, DevOps engineer, cloud security specialist, and decide next steps afterward.
  • •Supplemental material at www.dolinet.com/courses/itf-course includes free lifetime access to updates (AI, machine learning, MLOps), quizzes, assignments with recorded video answers, a PDF student guide with all slides, a Q&A support channel, a recorded career coaching session, and an IT primer covering Git, GitHub, Linux, Docker, Kubernetes, Terraform, and bash scripting.
  • Hardware Components, Units of Measurement, and Software Types ⏱ 0:00

  • •Computing devices include mobile phones, laptops (Windows, Mac, Linux), iPads, tablets, desktops, digital cameras, IPTV set-top boxes, smart TVs, servers, and more; the five key hardware components are CPU, RAM, storage drives, network interface cards, and monitors, plus GPUs for graphics acceleration.
  • •The CPU (central processing unit) is the mediator between applications/software and hardware and is involved in all operations; RAM runs all software on the device; storage (HDD, slower and older; SSD, faster and more expensive) provides persistent storage that survives power-off; network interface cards (wired or wireless/Wi-Fi/WLAN) connect the device to the outside world; monitors display data and can be built-in or external; GPUs accelerate graphics for games, movies, and video rendering. Power supplies, USB ports, and fans are excluded as not relevant to an IT career.
  • •Units of measurement: CPU speed is measured in gigahertz (e.g., 1.66 GHz, 2.3 GHz) — higher numbers mean faster, more modern CPUs; memory and storage are measured in gigabytes, with 1,000 gigabytes equal to terabytes (e.g., a 10 terabyte SSD is a good size); network interface cards are measured by bits or bytes per second (e.g., 100 gigabits per second).
  • •Software is anything not hardware — instructions written by programmers/developers in a specific computer language telling the CPU and computer what to do; examples include Uber, games, operating systems, and websites. The first type is system software or operating systems: Windows, Mac OS, iOS, and Android — system software manages the hardware resources of the computing device it is installed on. Module 1 covers important IT concepts including computing device hardware components, software, software types, operating systems, and applications.
  • Operating Systems and Software Types ⏱ 20:00

  • •The operating system (OS) runs installed applications, coordinates them with hardware, handles files and permissions, and provides user authentication (face recognition, fingerprint, password). It exists on phones and laptops alike.
  • •Two interface types: GUI (Graphical User Interface) uses icons/mouse/touch (e.g., MacOS Launchpad, FaceTime); CLI (Command Line Interface) uses typed commands (e.g., MacOS terminal, Windows CMD).
  • •CLI examples demonstrated: mkdir IT foundation, cd IT foundation, date (shows current date/time), touch ITF.text, and ls (lists files in folder) — creating a file under path Downloads/online user (Dolphinet).
  • •System software = the operating system (Linux, Windows, MacOS). Applications = software built for a specific task, running on top of system software.
  • Windows vs Linux, Applications, and Overview ⏱ 20:00

    FeatureWindowsLinux
    InterfaceMostly GUIMostly CLI
    CostPaidFree/open source
    Popular useDesktops/laptops, corporate user sideServers (common in cloud)
    FlexibilityLimited controlHighly customizable
  • •Speaker recommends Linux over Windows for modern IT (cloud, ML, AI, data analytics, containerization, Docker, Kubernetes) due to industry demand.
  • •Open source software: source code is publicly available to download, update, and change for free — Linux is a prime example.
  • •Application types: desktop (PowerPoint, Word, Excel), mobile (Google Maps, Uber), web (Gmail, Canva, online banking, accessed via browser), and cloud apps (Google Docs, Zoom). Other examples: Chrome, WhatsApp, Outlook, Uber Eats, DoorDash, Amazon.
  • Physical Server Limitations and Virtualization (Hypervisors, VMs, Types) ⏱ 40:03

  • •Physical servers suffer from low utilization, hard isolation, security issues, poor scalability, rising costs, slow procurement/shipping/backups, and hardware-dependent restores; this led to virtualization, which divides a physical server into virtual servers.
  • •A hypervisor (virtualization engine) sits above bare metal hardware, creating multiple isolated VMs that share physical resources (virtual CPU, memory, disk, network cards) and can each run a different OS (Windows, Mac, Linux).
  • •VM count is limited by physical resources (e.g., 10 TB disk split into 2 TB each = 5 VMs); oversubscription allows more; snapshots/backups of whole VMs can move between compatible hypervisors.
  • •Vendors include VMware (vSphere, Workstation), Xen, Microsoft Hyper-V, Linux KVM, Oracle VM VirtualBox; Type 1 (bare metal, e.g., Hyper-V, vSphere, Xen) installs directly on hardware with a mini OS, Type 2 (e.g., VirtualBox, Workstation) runs atop a full OS, common on laptops.
  • Data Centers and AWS Account Setup ⏱ 40:03

  • •Physical servers are hosted in data centers, specially equipped, purpose-built locations rather than under desks or in storage rooms.
  • •Hands-on labs use AWS cloud (aws.amazon.com); create a free account for labs; free plan gives $100 credits on signup, plus another $100 by completing select AWS service explorations within 6 months, totaling $200; account closes after 6 months; some services are inaccessible/unscalable; free usage of select services; no charges.
  • •Paid plan also offers 100 credits plus another 100 for exploration, full OWS service access, scaling beyond credit thresholds but charged beyond thresholds; upgrade available within 6 months; FAQ explains differences and additional credit activities.
  • •Signup requires: email and nickname (verify email); CAPTCHA security check; email code verification; root user password (most powerful user; use a passphrase; at least 8 characters with at least 3 of: uppercase, lowercase, numbers, non-alphanumeric); choose free or paid; personal details accurate (personal use selected); accurate phone, country, phone code verification; credit card information (identity verification, may hold $1/€1/1 small amount, released in a few days, no charge on free plan); identity confirmation by call or SMS code; CAPTCHA.
  • PlanCreditsAccessScalingDuration
    Free$100 + $100Limited servicesThreshold-capped6 months
    Paid$100 + $100All OWS servicesBeyond thresholds (charged)Ongoing

    AWS Account Setup, Console Walkthrough, and Launching a Virtual Machine ⏱ 60:03

  • •After signing up with the basic support plan, the AWS Management Console is the portal for orchestration, automation, and management; the home page shows account ID, billing and cost management, and a full list of AWS regions with Stockholm, Sweden as the default (switch to a closer region for lower latency).
  • •Key services include EC2 for creating virtual machines (instances), launched by naming the VM (e.g., "first virtual machine"), choosing an OS (Amazon Linux, Ubuntu, Windows, Red Hat, SUSE, Mac OS), and a size like T3 micro (2 vCPUs, 1 GB memory) or T3 nano; VPC (virtual private cloud) and default subnets, route tables, and security settings are pre-created by AWS.
  • •A remote-access key pair is optional ("proceed without"); after filling in settings, clicking Launch Instance creates a running VM in the cloud in ~10–15 seconds with no local hypervisor (VirtualBox/VMware), partitioning, or laptop virtualization required.
  • •New AWS users get $100 credits plus another $100 for exercises, valid for six months; after that, upgrade to a paid plan and control costs by usage, then terminate the instance to avoid charges (which shuts down and terminates it in no time).
  • On-Premises Data Centers vs. Cloud Computing ⏱ 60:03

  • •Servers and applications are hosted in client-specific purpose-built data centers — air-conditioned, physically secured, manned 24-7, with redundant power, generators, networking, and cables connecting racks (e.g., the large AWS data center in Mumbai, India); "on-premises/on-prem" means a location owned and controlled by the customer.
  • •On-prem gives 100% customer control and responsibility: real estate, physical security, network, persistent storage, hardware (servers, monitors, storage), virtualization/hypervisor licensing, operating systems, middleware/message brokers, runtimes (e.g., Python), applications, and data; the customer pays upfront under the Capex (Capital Expenditure) model — establishing a data center can cost up to $50,000 million and a similar amount to operate ongoing.
  • •Cloud computing pre-builds everything (infrastructure, network, physical, storage, applications, databases) so customers sign up online, connect to services without knowing where the data center is, and pay only for what they use as a utility bill — the vendor (AWS, Azure, GCP) bears the Capex, while the customer gets an Opex (operational expenditure) model.
  • •Opex is attractive to startups and remote teams who can't afford to buy 3–5 servers and handle power, cooling, and storage; paying little upfront to reduce monthly bills is optional, and unused services cost nothing.
  • Cloud Economics: Opex Model, Cloud vs. Data Center, and Service Models ⏱ 80:03

  • •Cloud uses a pay-as-you-go Opex (operational expenditure) model like electricity, phone, Netflix, or Zoom bills: you pay only when you use, and nothing up front.
  • •This Opex model makes cloud attractive for startups building proofs of concept, since they can turn resources on for a demo and switch them off afterwards.
  • •Cloud is not just a data center; the data center is only a component. Networking knowledge is only ~10–15% of the cloud knowledge needed, and AWS's Mumbai facility illustrates that automation, orchestration, and a management console provide services (storage, security, AI, machine learning, etc.) beyond networking.
  • •Cloud service models:
  • ModelCustomer Responsible ForCloud Provider Responsible For
    On-premisesEverything from network to applicationNothing
    IaaSOS, middleware, runtime, data, applicationNetwork, storage, hardware, virtualization
    PaaSApplication and dataRuntime, middleware, OS, and everything below
    SaaS (e.g., Uber, Netflix)Only signing up and using the serviceEverything

    Cloud Deployment Models: Public, Private, Hybrid, Multicloud, and Market Landscape ⏱ 80:03

  • •Deployment models:
  • ModelKey Characteristics
    Public (AWS, Azure, GCP)Shared multitenant infrastructure, internet connectivity, best for less confidential data; banks/hospitals hesitate to move sensitive data
    PrivateBuilt in-house by banks, corporates, or hospitals; single customer or group of companies; high-speed connectivity (own fiber, hundreds of gigabits per second); best for confidential data
    HybridMix of public and on-premises private cloud orchestrated for a single task; used for disaster recovery, backup, and cost optimization; proving to be the direction most companies take
    MulticloudSplitting workloads among providers (e.g., AI/ML on Azure or Google, e-commerce on AWS) to avoid vendor lock-in; advocate learning at least two of the three major clouds
    Hybrid multicloudPrivate cloud/data center connected to multicloud; main challenge is orchestrating security, users, and access across environments
  • •Gartner Magic Quadrant (completeness of vision vs. ability to execute): in 2021 AWS led, Azure and Google trailed; by 2023 gaps narrowed; by 2025 Azure and Google are very close in both vision and execution, AWS still leads in ability to execute and market share.
  • •Public cloud market share: AWS 30%, Azure 20%, Google 13%. For AI and machine learning, Azure and GCP are much better than AWS.
  • •Advice: check reputable job boards to see how many Microsoft, AWS, and GCP jobs exist and follow that for two weeks before deciding which cloud to start with.
  • Choosing a Cloud Provider and Networking Fundamentals Overview ⏱ 100:04

  • •Decide on a cloud provider by researching job demand, salaries, and preference in your country via forums and social media; if no clear preference, start with AWS for infrastructure, but move to Azure or GCP for machine learning and AI (generally never wrong with Azure or GCP).
  • •Cloud models now understood: private, public, hybrid, and multicloud.
  • •Beginning the networking fundamentals module: a deep dive sufficient for modern IT roles without needing A+, Network+, or CCNA.
  • •Module covers: what a network is, network types (LAN, wireless LAN/WLAN, WAN, CAN), network traffic/flow, wired network devices, cabling, Data Center Network (DCN), campus area networks, what the internet is, and wireless network devices.
  • What Is a Network: Definition, Devices, and Addressing ⏱ 102:43

  • •A network is a group of two or more computers and other devices connected to a medium to share data (files, images, videos) or connect to servers/websites.
  • •Devices are not limited to servers/computers/VMs; they include printers, laptops, phones, tablets, security/surveillance cameras, and smart TVs.
  • •Example: a home wireless network where desktops, phones, tablets, and a printer connect so you can print or reach the internet.
  • •Each device must be uniquely addressable (a name or address) to connect and communicate, called an IP address (covered later).
  • Network Types: LAN, WLAN, WAN, and the Internet ⏱ 104:47

  • •LAN (Local Area Network): connects computers and devices in a small area such as a home, office, business, school, building, or company; used to connect servers, printers, and users, share files, print, or access the internet; example is a school with library internet access, smart boards, and CCTV cameras.
  • •WLAN (Wireless LAN): like a LAN but wireless in a relatively small area (shopping mall, school, airport, or connected campus buildings); uses Wi-Fi via a wireless router connected to the internet (subscribed through an ISP like AT&T or Bridge Telecom).
  • •WAN (Wide Area Network): connects computers and networks over long distances (across cities, states, countries, or the globe); can connect many LANs, e.g., a US headquarters and a Germany branch linked by a costly high-speed cross-continent connection.
  • •The internet is the largest WAN in the world, connecting home offices and company branches globally to exchange or access data.
  • Network Traffic Flow: Unicast, Multicast, Broadcast ⏱ 110:01

  • •Unicast: one-to-one communication, e.g., online banking where you talk to the bank server and share data with no one else; data goes from one device to a specific device (client to server).
  • •Multicast: one-to-a-group, e.g., an IPTV server in a hospital or hotel where patients/guests watch the same movie, or Netflix streaming to many. There is also another type called Anycast, not covered now.
  • •Broadcast: one-to-all, e.g., a PA system at an airport announcing boarding; everyone on that network receives the traffic.
  • Wired Network Devices: Hubs and Switches ⏱ 113:08

  • •Hub: an old, rarely encountered device that connects multiple computing devices in a LAN (printers, laptops, servers, CCTV cameras) but is not intelligent; it sends data to all connected devices (like a broadcast), wasting bandwidth and media for devices that don't need the traffic; no filtering or intelligence, all devices share the same bandwidth, and it is lower and less secure.
  • •Switch: the intelligent, faster version of a hub that can do isolation; example is a 24-port switch (8 times 3) from a company like Dell, with LED indicators (green = normal, orange = possible errors, red = major problem or switched off); each physical port/interface connects one device via cable, and a switch can be physical or virtual (software switches covered later).
  • •Switch advantages: sends data only to the intended device, segmenting bandwidth so separate conversations don't see each other; faster and more secure with isolation and configurable security features; each connection uses its full speed (e.g., 100 Mbps or 1 Gbps per port) and handles many devices more efficiently than hubs.
  • VLANs (Virtual Local Area Networks) ⏱ 117:46

  • •A switch can be configured or virtualized into multiple isolated segments called VLANs, which cannot talk to each other without extra configuration or devices; similar to virtual machines on a physical server.
  • •Create separate segments (e.g., VLAN 10, VLAN 20, VLAN 30) and map switch ports to the needed VLAN; devices needing VLAN 10 have their physical ports mapped to VLAN 10, likewise for VLAN 20, 30, and so on.
  • •Use case: keeping sensitive teams (e.g., accounting) on a separate VLAN so they can communicate with each other and their server, while guests cannot communicate, sniff, or copy that traffic.
  • •Example: four leftmost (blue) ports mapped to one VLAN and the next four (red) ports mapped to another (e.g., VLAN 200); devices on red ports can never communicate with blue-port devices without extra configuration.
  • •Advantages: better security, isolation, and segmentation within the LAN, and data goes only to the right VLAN.
  • Routers and Switch-Router Combo Devices ⏱ 120:37

  • •Routers connect different networks together (e.g., LAN to WAN); they have more intelligence than switches and can also be software virtual.
  • •To connect a Germany branch LAN to a US head office LAN, procure a router at each site, connect each router to the local LAN, then contract a service provider (AT&T, Verizon, Bell Canada) — signing contracts, waiting for installation and configuration.
  • •Within a LAN, a router is needed to forward traffic between isolated VLANs; separate router interfaces must connect to each VLAN.
  • •Intelligent switches, switch-router combos, or multi-layer switches perform both switching and routing, often marked with a small icon, eliminating the need for an external router to bridge VLANs (e.g., red to blue).
  • •Key distinction: a switch connects devices in the same VLAN (or multiple VLANs); a router connects different VLANs or separate LANs.
  • Network Cabling, Data Center Networks, and Wireless Access ⏱ 125:44

  • •Ethernet/copper twisted-pair cables (UTP/STP) use RJ45 connectors with 8 pins/8 wires; common types are Cat 5E, Cat 6, and 6A; distances limited to roughly 100 meters (or 90 depending on source); speeds from 100 Mbps to 10 Gbps; traffic carried as electrical signals (voltage or no voltage).
  • •Fiber optic cables carry light signals, support long distances and higher speeds than copper, and are used by ISPs, data centers, and WANs; undersea cables connect continents and outages affect dependent countries.
  • •A Data Center Network (DCN) is a LAN connecting servers, storage, and networking equipment; it favors fiber cables (UTP only at server ends), uses higher-capacity switches with multiple power supplies and processor engines for availability, and one data center may have 8, 10, 16, or 20 such switches plus one or more internet connections for redundancy.
  • •Nearby LANs (10 m to 1 km) connect to a data center via fiber uplinks (copper limited to 100 m), with multiple uplinks for redundancy, sharing the data center's high-speed internet; distant LANs (200–500 miles) rely on WAN routers instead.
  • •Two data centers interconnect via larger routers with separate internet connections for backup and failover; a Campus Area Network (CAN) links multiple nearby buildings (university, hospital, ministry) with fiber uplinks over 500 m to 1 km.
  • •Wireless networks require Wireless Access Points (WAPs) that broadcast Wi-Fi and authenticate users; WAPs are not routers and lack routing functions — they connect via cable to the wired LAN, so a router is still needed for internet access; large areas need multiple WAPs, and outdoor units must be rugged/industrial grade.
  • Wireless Routers, the Internet, and IP Addressing Fundamentals ⏱ 140:06

  • •A wireless router combines a wireless access point, routing, and a built-in mini switch; ports labeled internet/WAN go to the service provider, back ports serve wired devices like printers, and wireless handles the rest.
  • •The internet is millions of LANs, data centers, home offices, and WANs connected via routers and high-speed links into one global network; data centers, branch offices (e.g., India to Germany), and home offices (e.g., UK) all connect through it.
  • •Module 5 introduces networking fundamentals: IP addresses are needed as unique identifiers for anything connected to the internet, analogous to names, phone numbers (unique with country/area codes), mailing addresses, and emails; IP stands for Internet Protocol, the globally standardized rules governing data sent/received, and IP routing (through routers) connects different networks.
  • •IP addresses come as IPv4 (32 bits, four dot-separated fields, requires a subnet mask) and IPv6 (128 bits, eight fields, hexadecimal notation, requires subnet mask); both can have public or private ranges, and computers read them in binary. Find your IP with ``ipconfig` on Windows or `ipconfig getifaddr en0`` on Mac/Linux.
  • Numbering Systems and Binary Conversion for IP Addresses ⏱ 160:08

  • •Decimal system uses 10 symbols (0-9); binary uses 2 symbols (0,1); hexadecimal uses 16 symbols (0-9, A-F).
  • •In decimal, each position has a weight: units (1), tens (10), hundreds (100), thousands (1000), etc. In binary, weights are powers of 2: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, etc.
  • •A 32-bit IP address consists of four 8-bit numbers; each 8-bit string ranges from 0 to 255, giving 256 possible values. The largest 8-bit number is 255 (128+64+32+16+8+4+2+1).
  • •To convert decimal to binary, select weights that sum to the target number; to convert binary to decimal, sum the weights where bits are 1. For example, 00001100 = 12 (8+4), 10011000 = 156 (128+16+8+4).
  • •Exponents: 2^4 = 16 (2×2×2×2), 2^0 = 1, 2^5 = 32, 2^6 = 64, 2^7 = 128. The weight of the nth bit position is 2^(n-1).
  • Binary to Decimal Conversion and Practice ⏱ 180:09

  • •Binary-to-decimal conversion uses bit weights: rightmost = 1, then doubles (2, 4, 8, 16, 32, 64, 128) for eight bits; rule: wherever a bit is 0 ignore its weight, wherever it is 1 add its weight.
  • •Worked examples: 00010010 → 12; 01001100 maps to positions 3,4,6,7 → 64+16+8+4 = 108; 10001100 → 128+16+8+4 = 156; 10100011 → 128+32+2+1 = 163; 11001100 → 128+64+8+4 = 204.
  • •Only eight-bit strings matter, relating to IP addresses for networking, cybersecurity, development, and cloud.
  • •Keep a bit-weight table handy; mind math or a calculator both work.
  • Decimal to Binary, IPV4 Addresses, Subnet Masks ⏱ 180:09

  • •Decimal-to-binary (reverse method): decide each weight, if adding it keeps the sum ≤ target take it (set bit to 1), otherwise skip (set to 0); e.g., 191 → 1011 and the rest ones; 238 → 11011110. Any number ≤255 is representable in eight bits; more than eight bits is irrelevant to IP address study.
  • •Use ChatGPT/AI to verify conversions (e.g., confirming 238 → 11011110, 191 → 10111111), as a way to augment learning quickly.
  • •IPV4 addresses are the decimal representation of 32-bit addresses written as four bytes or octets (four decimal fields separated by dots), each 0–255; any field over 255 makes the address invalid. Example: 192.68.1.0 is valid.
  • •Host vs network: analogy of street = network and house number = host; a host is any device with an IP address on a network (router, switch, printer, laptop, iPhone). Computing devices must separate network part from host part, done via subnet masks.
  • •Subnet mask tells the computer which part of the IP address is network and which is host; representable in decimal or CIDR notation. Example subnet mask: 255.255.0.0. IPV6 is 128 bits (eight 16-bit fields separated by colons), not covered here; the course focuses on IPV4.
  • Subnet Masks, CIDR Notation & Network vs Host Identification ⏱ 200:10

  • •A subnet mask in binary has 1s in the network part and 0s in the host part; e.g., 255.255.255.0 = three fields of eight 1-bits (network) plus one field of eight 0-bits (host), giving 24 network bits and 8 host bits out of 32 total. The network and host parts must be contiguous — zeros cannot appear between the ones.
  • •Devices use the mask to tell which portion is the network (street name) and which is the host; for 192.168.1.10 with /24, network = 192.168.1.0 and host = .10. Hosts like .50, .100, .254, .2338 on the same network communicate without a router intervening.
  • •CIDR notation (e.g., /24) replaces the decimal mask, where the number after the slash is how many bits are used for the network; 32 total bits minus the network bits leaves the host bits. Examples: /16 = first two fields network, next two hosts; /8 = first field only network, rest hosts.
  • •Mask boundaries convert easily: /8 = 255.0.0.0, /16 = 255.255.0.0, /24 = 255.255.255.0, /9 = 255.128.0.0, /10 = 255.192.0.0, /11 = 255.224.0.0, /12 = 255.240.0.0. CIDR ranges from /8 to /32, and tools like ChatGPT/CoPilot/Gemini can convert decimal masks to binary and vice versa.
  • Subnetting Practice Examples (Network ID, Host, Decimal Mask) ⏱ 209:57

  • •For each example, find the network ID, host, and decimal subnet mask by writing the IP in 8-bit binary and zeroing the host part. Example 192.168.1.2/24 → binary 192 = 128+64 = 11000000, 168 = 128+32+8, .1 = 00000001, .2 = 00000010; network ID = 192.168.1.0, host = .2, mask = 255.255.255.0.
  • •/26 examples (mask 255.255.255.192, since 128+64 = 192, leaving 12 host bits):
  • IP/CIDRNetwork IDHostMask
    192.168.1.12/26192.168.1.0.12255.255.255.192
    192.168.1.80/26 (80 = 64+16)192.168.1.64.80255.255.255.192
    192.168.1.138/26 (138 = 128+8+2)192.168.1.128.138255.255.255.192
    192.168.1.217/26 (217 = 128+64+16+8+1)192.168.1.192.17 (host /26 = 64+16+8)255.255.255.192
  • •These examples deliberately reuse the 192.168.1 network so the same network ID (192.168.1.0) keeps recurring alongside different hosts, before practicing with different networks later.
  • IP Address Classes and Subnetting Fundamentals ⏱ 220:10

  • •IP addresses are divided into classes: Class A (1–126, default /8, 126 usable networks, 16 million hosts each, for big corporates), Class B (128–191, default /16, 16,384 possible networks, more than 65,000 hosts each, for medium networks), Class C (192–223, default /24, 2 million+ networks, 256 IP addresses per network but 254 usable, for small networks); 127 is reserved for local hosts, and classes D and E are out of scope (multicast).
  • •Subnetting divides one IP block into smaller equal-sized subnets, and you can only split into powers of 2 (2, 4, 8, 16, 32, 64); if you need 5 subnets, go for 8 and keep 3 spare; if you need 12, go for 16 and keep 4 spare.
  • •Key questions before subnetting: how many hosts per subnet, how many subnets, and anticipated growth rate (e.g., 10%, 20%, 30%) for both hosts and subnets to avoid redesign later.
  • •Subnetting is like slicing a pizza: the IP range is the pizza, each slice is a subnet; you cannot divide by 3, 5, 7, 9, 11 — only by 2, 4, 8, 16, 32, 64.
  • Calculating Subnets with Online Tools ⏱ 220:10

  • •For a range like 192.168.1.0/24: network ID is 192.168.1.0, broadcast address is 192.168.1.255 (last IP, all host bits = 1), first usable IP is 192.168.1.1, last usable is 192.168.1.254, total hosts 256, usable 254 (minus network ID and broadcast).
  • •Dividing a /24 into 4 equal subnets extends the subnet mask by 2 bits to /26 (because 2^2 = 4); dividing into 8 subnets extends it by 3 bits to /27; the first subnet becomes 192.168.1.0/26.
  • •Recommended online tools: 'calculate quick' (highly recommended) and SolarWinds Subnet Calculator; you can also ask ChatGPT for popular IP subnet calculators.
  • •For each subnet you need: subnet mask, network ID, broadcast IP, number of usable IP addresses, and first/last usable IP addresses.
  • Subnetting and IP Address Breakdown ⏱ 240:12

  • •Subnetting extends the subnet mask to create more subnets while reducing hosts per subnet: /24 to /25 = 2 subnets; to /26 = 4; to /27 = 8; to /28 = 16. A /28 leaves 4 host bits (max 16 hosts); /26 leaves 6 bits (2^6 = 64 hosts).
  • •For an IP range with a subnet mask: network ID is the address with all host bits set to 0; broadcast IP has all host bits set to 1. Example: 192.168.2.0/24 has broadcast 192.168.2.255, first usable 192.168.2.1, last usable 192.168.2.254, and 254 usable IPs (2^8 - 2).
  • •Host bits = 32 minus prefix length. Total IPs = 2^(host bits). Usable IPs = total minus 2 (network ID and broadcast). A /30 leaves 4 IPs, 2 usable, useful for point-to-point router links.
  • •Example /20 breakdown (192.168.209.33/20): 12 host bits, so 2^12 = 4096 total IPs, 4094 usable. Network ID = 192.168.208.0, broadcast = 192.168.223.255, first usable = 192.168.208.1, last usable = 192.168.223.254.
  • Purpose of Subnetting and Practice Example ⏱ 255:10

  • •Subnetting divides an IP block into smaller chunks to support different offices, LANs, WANs, wireless LANs, and separate data center functions (databases, applications, monitoring, Active Directory, accounting, finance). It also enables security filtering between networks.
  • •Practice: given 192.168.240.0/24, create 4 equal subnets of 64 total IPs each. Original network has 8 host bits, 256 total IPs, 254 usable (first .1, last .254, broadcast .255). Dividing 256 by 4 yields 64 IPs per subnet.
  • Subnetting a /24 into Four Subnets (/26) and the Resulting Ranges ⏱ 260:12

  • •Starting from a /24 (256 addresses, 0–255), splitting into 4 equal chunks requires borrowing 2 host bits, because 2 bits give the 4 combinations 00, 01, 10, 11. Resulting mask is /26 = 255.255.255.192 (128 + 64 = 192).
  • •The four subnets and their ranges: 0/26 (0–63), 64/26 (64–127), 128/26 (128–191), 192/26 (192–255) — each block has 64 IPs, 62 usable (e.g., subnet 1 usable = 1–62, broadcast = 63).
  • •6 host bits are needed for 64 addresses (2^6 = 64); with /26, 6 bits remain for hosts and the fixed 2 subnet bits distinguish the subnets (00, 01, 10, 11). Each subnet wastes 2 addresses (network ID + broadcast), so total usable across 4 subnets is 4 × 62, not 254.
  • •Rule: divide into 1 subnet = no change; 2 subnets = borrow 1 bit (/25, 128 hosts each, 126 usable, 252 total usable); 3 or 4 = 2 bits (/26); 5–8 = 3 bits; 9–16 = 4 bits. More subnets = fewer host bits = fewer hosts per subnet (e.g., /30 leaves only 2 usable IPs). You must ask how many hosts per subnet and how many subnets are needed to check if the given block is enough.
  • Public vs. Private IP Addresses and the IP Address Hierarchy ⏱ 260:12

  • •A public IP address can be accessed over the internet; private IP addresses cannot be reached directly — traffic must go through a public IP address, with the router converting/masking the internal private address before sending traffic out.
  • •Any device or network communicating directly with the internet must use a public IP address: home routers, office routers, airport Wi-Fi, and any internet entity (Amazon.com, CNN.com, British Telecom.com). Your ISP/telecom company provides your router's public IP. Postal-system analogy: without a registered address you are off the grid.
  • •Public IPs are globally unique (no two devices, homes, or entities share one), visible on the internet (reachable unless security measures block incoming traffic), routable, and used by websites, servers, emails, computers, laptops, and iPhones online.
  • •IP addresses are not random: they are assigned and managed globally by official organizations in an IP address hierarchy (IANA, then Africa, Europe, Asia-Pacific, Latin America), which allocates blocks to countries, then to ISPs and national IP registries, tracking what is used and unused — like license plate numbers with city codes. Uniqueness is required so the internet knows where to send data.
  • Internet IP Address Management and Private IP Ranges ⏱ 280:12

  • •Public IP addresses are globally unique and assigned by a hierarchy: IANA (top-level, U.S.), regional Internet registries (ARIN for North America, RIPE for Europe/Middle East, APNIC for Asia-Pacific, LACNIC for Latin America, AFRINIC for Africa), national registries, and ISPs. Private IP ranges (RFC 1918) can be used freely within private networks but are not routable on the internet; they must be hidden behind a public IP via a gateway/router.
  • •Private ranges: 10.0.0.0/8 (Class A, ~16 million addresses), 172.16.0.0/12 (172.16–172.31, ~1 million per /16), and 192.168.0.0/16 (homes and small offices). Example: a home with ~12–15 devices would exhaust public IPv4 addresses if each needed one, so private IPs are used internally. A home router gets a public IP from the ISP, and devices use private IPs (e.g., 192.168.68.108).
  • •Network Address Translation (NAT) — sometimes Port Address Translation (PAT) — on the router swaps the private source IP for the router's public IP. The router claims to be the source, forwards traffic to the internet (e.g., CNN.com), and translates responses back to the correct private IP.
  • •Demo on a Windows AWS instance: open Command Prompt via search (type CMD) and run ipconfig to see the private IP address.
  • IP Routing, Routing Tables, and Dynamic Routing Protocols ⏱ 280:12

  • •Devices on the same LAN/VLAN communicate without a router; routers are required to forward traffic between different networks/subnets, VLANs, or over a WAN. A multi-layer switch can perform routing internally. Routing is the process of selecting paths to forward traffic between hosts; routers use routing tables (forwarding databases) and algorithms to determine the best path, akin to a GPS.
  • •When a router receives a packet, it checks the destination against its routing table. If the destination is known, it forwards to the appropriate interface/IP (e.g., destination 10.0.24.0/24 → send to 10.0.2.1.1); if not, it drops the packet silently — the router never guesses.
  • •Routing tables can be populated manually (static routing, suitable for small infrastructures) or dynamically via routing protocols. Examples: BGP (Border Gateway Protocol, used on the internet backbone) and OSPF (Open Shortest Path First). Large networks make manual configuration impractical and error-prone, so dynamic protocols allow routers to share known networks with neighbors and build the table automatically.
  • •The router does not come pre-configured with a routing table; it must be configured. The segment previews an AWS module on VPCs (Virtual Private Clouds), subnets, route tables, public vs. private subnets, and NAT, with hands-on building of a virtual data center in AWS.
  • Default Routes and Router Table Configuration ⏱ 300:14

  • •Routers forward packets based on their routing (root) table; if no matching entry exists they drop the packet — impractical for home users since the full internet table holds millions of networks and needs gigs of storage that small wireless routers cannot support.
  • •The solution is the default route (written as /0 or 0.0.0.0/0) — a last-resort entry telling the router: if no specific entry matches, forward the packet to this IP instead of dropping it; only drop if no default route exists.
  • •Example topology: Router A (LAN side, 192.168.0.0/24, 172.18.0.0/30 WAN to Router B at 172.18.0.2) and Router B (data center side, 10.0.0.0/16 with app subnet 10.0.2.0 and DB 10.0.1.0/24, 10.0.2.0/30 switch-router link at .1/.2, internet via 120.254.2.2).
  • •Router A needs 4 entries (LAN, WAN, data center via Router B, internet via Router B using default route); Router B needs 5 entries (switch-router subnet 10.0.2.0/30, 10.0.0.0/16 via 10.0.2.5.1, internet via 120.254.2.2, WAN 172.18.0.0/30, and LAN via Router A) — manual config suffices for a small network, or BGP/OSPF can be enabled.
  • What an IP Packet Carries ⏱ 300:14

  • •An IP packet is like a sealed envelope carrying a digital message from one computer to another; like postal mail it includes a from (source IP) and to (destination IP) field.
  • •Example: a user with public IP 100.2.55.3 (not 10.x, not 172.16–31, not 192.168.x, which are private ranges) requests a server at public IP 205.111.37.86; the source address is the user's address and the destination is the server's.
  • •Public IP addresses must be allocated according to the registry/hierarchy of the global public IP control system and cannot be freely used in a private network.
  • •The response packet reverses the fields: the server's IP becomes the source and the user's IP becomes the destination, allowing routers to carry it back hop by hop.
  • IP Packet Headers and Payload ⏱ 320:15

  • •The IP packet includes the message data (payload) plus IP addresses and other delivery details, called headers.
  • •Headers are the source and destination IP addresses and related info needed to deliver a message from host A to host B on an IP network.
  • •The header is like the envelope; once the message is received, the envelope is discarded and a new one is written for the next hop.
  • AWS Global Infrastructure and VPC Fundamentals ⏱ 321:47

  • •AWS has 38+ geographic regions and 120 availability zones (AZs); a region is a group of data centers in one country (the US has 4 regions).
  • •Each region has 3 or more AZs (North Virginia has 6); an AZ is 1+ interconnected data centers within ~10–50 km, linked by high-speed connections.
  • •AWS recommends distributing workloads across multiple AZs for high availability; a workload in multiple AZs is considered highly available.
  • •A VPC is an isolated virtual data center, confined to one region and spanning all its AZs; a default VPC is auto-created per region per account.
  • •VPC components: CIDR block required (AWS default /16; range /28 to /16; /16 = 65,000+ hosts, /28 = 16 hosts; /15 or /14 not allowed), an auto-created implied router, route tables, and internet gateway (IGW).
  • •The implied router connects all subnets, routes between them by default (cannot be disabled), and is fully managed by AWS; you can create custom route tables assigned to subnets.
  • •A subnet is confined to a single AZ; subnets are chunks of the CIDR block; the main route table can serve multiple subnets, but a subnet attaches to only one route table at a time.
  • •Internet access requires an IGW (only one per VPC); a subnet's route table must point to the IGW (send non-listed IPs to the IGW).
  • Hands-on Custom VPC Setup ⏱ 337:22

  • •Default VPC walkthrough: AWS auto-creates a VPC with the same specs in all enabled regions (usually 16 or more) when an account is created.
  • •Custom VPC "custom_VPC" is created in Ohio (US East 2), CIDR 172.31.0.0/16.
  • •Four subnets created: Subnet 1 in US East 2A (172.31.0.0/20), Subnet 2 in 2B (172.31.16.0/20), Subnets 3 and 4 at 32.0 and 48.0, both /20.
  • •Route tables: RT1 (green) with Subnet 1; RT2 (gray) with Subnet 2; RT3/4 (blue) with Subnets 3 and 4 together.
  • Exploring AWS Default VPCs and Creating a Custom VPC with Subnets ⏱ 340:17

  • •The AWS Management Console VPC dashboard allows switching regions instantly (e.g., from North Virginia to Mumbai to Ireland) to manage global infrastructure centrally; the speaker demonstrates in Ireland, noting each account gets one default VPC per region. In Ireland, the default VPC has 3 subnets because there are 3 availability zones (eu-west-1a, 1b, 1c); North Virginia has 6 AZs, California has 2 (fewest). The default VPC CIDR is 172.31.0.0/16 and AWS automatically creates one subnet per AZ, all associated with a main route table and an internet gateway.
  • •Route tables contain two default routes: the local route 172.31.0.0/16 (for any subnet within the VPC CIDR) and 0.0.0.0/0 pointing to the internet gateway. The speaker explains that AWS reserves the first 4 and the last IP address in each subnet (network ID, AWS reserved, broadcast), so a /20 subnet (4,096 IPs) yields 4,094 usable addresses minus 3 more reserved by AWS = 4,091 usable. Subnets without explicit route table associations use the main route table.
  • •The speaker then switches to US East 2 (Ohio) to create a custom VPC named "Custom_unders_VPC" with CIDR 172.31.0.0/16 using the "VPC only" option (no automatic subnets/routes). They create four subnets: subnet_1 (172.31.0.0/20 in us-east-2a), subnet_2 (172.31.16.0/20 in 2b), subnet_3 (172.31.0.0/20 in 2c), and subnet_4 (172.31.48.0/20 in 2c). The speaker notes that attempting to create a subnet outside the VPC CIDR (e.g., 172.31.0.0/30) returns an error because it's not within the VPC's address range.
  • •The demonstration highlights cloud orchestration: creating a virtual data center in Ohio from Dubai via clicks, with AWS automatically allocating VPC, route table, and subnet IDs. The speaker notes that with infrastructure-as-code tools like Terraform, this could be scripted in under a minute.
  • Creating Custom Route Tables and Associating Subnets in AWS VPC ⏱ 360:17

  • •All 4 subnets (1-4) initially attach to the VPC's default main route table; the task is to create RT_1 for subnet 1, RT_2 for subnet 2, and RT_34 for subnets 3 and 4, all in the custom VPC.
  • •Each new route table auto-creates a "local" entry only (the VPC CIDR); associate subnets via Edit subnet associations — after setup all 4 subnets have explicit associations and 0 remain on the main route table.
  • •A subnet can only be associated with one route table at any given time, though associations can be switched.
  • •An Internet Gateway (custom VPC IGW) was created and attached to the custom VPC, completing a full virtual data center: 1 VPC, 4 subnets, 3 route tables, and 1 internet gateway.
  • Public vs Private Subnets and Network Address Translation (NAT) ⏱ 368:00

  • •A subnet is public only if BOTH conditions are met: (1) its VPC has an internet gateway attached, and (2) its route table has a default route (0.0.0.0/0) pointing at the IGW — neither is default; both must be configured.
  • •Making subnet 1 public required adding the 0.0.0.0/0 route to RT_1 pointing at the IGW; subnets 3 and 4 (on RT_34) keep only the local route and are therefore private.
  • •Public subnets should host internet-facing resources (e.g., websites/VMs); private subnets should hide sensitive data (databases, credit card, order, payment, patient health records) from hackers.
  • •NAT hides a sender's private IP behind the router's public IP: a laptop at 172.31.1.118 sending to cnn.com (205.111.37.86) has its source rewritten by the router to its public IP 100.2.55.33; a mapping table tracks this so returning traffic is routed back correctly.
  • •The VPC, subnets, route tables, and internet gateway are all free (non-chargeable) resources on AWS.
  • Network Address Translation (NAT) and Public Subnets in AWS ⏱ 380:17

  • •NAT swaps a private source IP for a public IP on outbound traffic and reverses the process on the response; the destination (previously the source) is swapped back to the private IP — the same mechanism used by home wireless routers, where a router might have .1.254 on the WLAN side and the laptop has .1.120.
  • •In AWS, a virtual machine's public IP is NOT configured on the instance; it is configured on the IGW (internet gateway) with mapping between the private IP and the assigned public IP. In the demo: private IP 172.31.4.177 on the ENX0 interface (mask /20, broadcast 172.31.5.255), public IP 3.146.78.137.
  • •NAT is crucial to conserve public IP address space by masking private IPs for internal use in WLANs/LANs and converting to public IPs only when internet communication is required.
  • •On the internet, source IP addresses in logs let investigators identify country, service provider, and from provider logs, the user — so be a good citizen online.
  • Hands-on: converting subnet 1 to public:

  • •AWS setup: create a VM in subnet 1; edit RT_1 (subnet 1's route table) to add a route sending all non-VPC traffic to the IGW of the custom VPC (Ohio region). Label subnet 1 as public.
  • •Create a security group (testing_security_group, description testing VM public subnet) in the correct VPC with inbound: all traffic from anywhere; outbound: all traffic to anywhere. Every AWS VM is protected by a security group — here it is forced to allow all traffic so nothing is filtered during the test.
  • •Launch instance testing_public_subnets, Amazon Linux 2023, t2.micro, without a keypair, in the custom VPC and public subnet, with a public IP assigned, using the existing testing security group. Open the VPC and EC2 dashboards in separate tabs, then connect via EC2 Instance Connect.
  • Connectivity test results:

    bash
    sudo su
    ping 8.8.8.8        # 7 transmitted, 7 received, 0% packet loss
  • •Outbound works: the VM on a public subnet can reach the internet (Google DNS 8.8.8.8).
  • •Inbound works: pinging the public IP 3.146.78.137 from the laptop succeeds — 6 packets sent, 6 received, 0% packet loss.
  • •After removing the IGW route from RT_1 (making it a private subnet), pings from the laptop time out even though the VM still holds its public IP — nothing can reach or respond without the IGW route. Re-adding the route immediately restores connectivity.
  • •Conclusion: an internet-accessible AWS workload needs a public IP address, placement in a public subnet, and a security group allowing the needed in/out communication.
  • Proving the public IP is not on the instance:

  • •ip a (or IP config on Windows) lists all IPs on the VM and shows only the private IP 172.31.4.177 on the vNIC — no public IP exists on the instance.
  • •curl ifconfig.me asks the internet what source IP it sees; it returns 3.146.78.137, the public IP. This confirms a device (the IGW) is swapping the private source IP 172.31.4.177 for the public IP on the way out, as documented in AWS.
  • •The same check from a home or office laptop shows that router's public IP performing the same NAT.
  • •The instance was terminated at the end of the lab.
  • Instance Cleanup, NAT Demo, and Network Reference Models ⏱ 400:19

  • •Terminate the instance or virtual machine when you don't need it (root table and VPC are free resources, but the VM is not); demo shows a wireless router does NAT between the private IP and the public IP seen on the internet, with most private IPs being 192.168.x.x.
  • •Demo uses a Windows PC on AWS as a stand-in for a home PC: ipconfig shows the private IPv4 address 172.31.80.56 with subnet mask 255.255.240.0, which is a /20 subnet (240 = 4 + 16), and curl ifconfig.me shows the public IP 52.87.238.95; if curl isn't recognized, install it and check curl ifconfig.me.
  • •Network reference models and protocols matter for multi-vendor interop: cables, connectors, electrical/optical signals, and packet layout must follow standards so gear from different vendors works.
  • •Upcoming topics: why more headers than source/destination IP are needed, the OSI reference model, TCP/UDP protocols, and other common networking protocols; the postal analogy shows a letter needs the unit number (not just the building address) — similarly a packet needs more than source and destination IP.
  • •Source and destination IPs alone aren't enough because multiple VMs and apps run on the server and multiple apps (Chrome, Safari, Firefox, mail, Zoom) run on the client; that's why we need ports (source and destination port).
  • •Response example: server at port 80 sends to 100.2.55.33 at the original source port 55,000; think of ports as units/doors in a condo building or a phone extension number, so multiple browser tabs always get their own responses correctly.
  • •The OSI reference model is a seven-layer framework breaking down how data travels from the client application through the LAN/WAN to the server; layer 1 (physical) defines cabling, signals, connectors and lengths; layer 2 (data link) defines standards for switching, LAN/WAN/data center protocols, and NICs; layer 3 (network) covers routers, interfaces, routing protocols, ping ICMP, IPsec, IP OSPF; layer 4 (transport) establishes the connection and covers TCP, UDP, SSL/TLS; layer 5 (session) manages the session between the two sides (e.g., browser to Amazon.com); layer 6 (presentation) defines session info and how sessions open/close; layer 7 is the application — layers 3, 4, and 7 are the ones you must know.
  • OSI Model Layers, Encapsulation, and Data Flow ⏱ 420:21

  • •OSI model has 7 layers; session layer manages messages/sessions, presentation layer formats and encrypts data, application layer defines protocols like DNS, HTTP, HTTPS.
  • •Encapsulation: data originates at the user application (e.g. browser), flows down through all 7 layers (application → presentation → session → transport → network → data link → physical) adding headers at each step; physical layer converts to electrical, light, or wireless signals. De-encapsulation reverses this on the receiving end.
  • •Transport layer handles connection-oriented vs connection-less, sequencing, flow control, retransmission; adds source/destination ports (e.g. HTTP port 80). Network layer adds source/destination IP addresses, performs routing, NAT, and runs protocols like BGP.
  • •Data link layer uses switch-level delivery; physical layer defines cable/Wi-Fi standards. Benefits of layering: standardization, interoperability, modularity, and easier troubleshooting.
  • •Example: browser sends HTTP GET (layer 7) → TCP header added with random source port and destination port 80 (layer 4) → IP source/destination added (layer 3) → out to network.
  • TCP/IP Model, Protocols, and Networking Devices ⏱ 420:21

  • •TCP/IP model has 4 layers, combining OSI's application, presentation, and session into one application layer, and OSI's data link and physical into a network access layer.
  • •Routers operate at the network layer (layer 3); switches operate at the data link layer (layer 2); firewalls can function at either layer.
  • •A protocol is a standard set of documented rules for formatting and processing data, enabling devices to communicate; developers must follow these protocols (e.g., a new browser must understand existing website protocols to interoperate).
  • Network Protocols and Transport Layer: TCP vs UDP ⏱ 440:23

  • •A protocol is a standard set of formats for messages, details, and errors that enables communication between parties regardless of the application's developer, e.g., HTTP/HTTPS for websites works across Taiwan, China, Vietnam, US, Germany, and India.
  • •Application layer protocols include HTTP, HTTPS, DNS, SMTP for email, FTP for file transfer, NFS for file system, and SSH for connectivity; presentation layer includes TLS and SSL (TLS is the successor of SSL); network layer includes IP, ICMP, NAT, and IPsec.
  • •TCP (protocol number 6) at layer 4 establishes a connection via a three-way handshake: client sends SYN, server responds with SYN-ACK, client sends ACK; it ensures sequencing, error control, flow control, acknowledgements, and retransmission for 100% reliable delivery, but is slower. Use cases: websites, email, file downloads.
  • •UDP (protocol number 17) at layer 4 does not establish a connection, and does not use sequencing, error control, flow control, or acknowledgement — it is best-effort and faster but not reliable. Use cases: online games, voice calls, video calls, live video streaming; the communicating parties fix issues (e.g., voice breaking up).
  • Common TCP/IP Protocols: ICMP and SSH ⏱ 440:23

  • •ICMP is used to send a ping (echo request) and wait for an echo reply to check if a server is alive; it operates at layer 3 and is useful in troubleshooting. A reply 100% means the server is alive; no reply could indicate blocking (some networks block ping to prevent hacking scans).
  • •SSH is a secure way to log into remote devices; it is a connection-oriented protocol running on TCP port 22 at layer 4, operating at the application layer (layer 7) since presentation handles encryption. The client and server negotiate connection parameters and exchange a key to scramble data (man-in-the-middle cannot read it). Windows 10 and above has SSH client and server available (OpenSSH).
  • •In AWS, an EC2 Linux instance has an SSH server by default. When creating the instance, you create an SSH key pair: the public key stays in AWS, and the private key is downloaded to your computer (e.g., SSH demo.pem, RSA format). The SSH server acts like a security guard checking the private key against the matching public key; without the right private key, the connection is refused. The key pair authenticates the connection, and the same key is used for encryption.
  • SSH into EC2 from Mac: Key Permissions, Networking, and Verification ⏱ 460:25

  • •Locate the private key file (e.g., in Downloads folder) before connecting; upload the key, set security group wide open for testing, and ensure instance uses custom VPC and public subnet with auto-assign public IP enabled.
  • •Review settings before launch: Amazon Linux, t2.micro free tier, correct VPC and public subnet (not private) to avoid failure; AWS keeps the public key and provides the private key, though documentation may say otherwise.
  • •On Mac, use SSH client from terminal; key file must have permissions 400 via chmod 400 SSH-demo.pem; initial connection will fail with "Bad permissions" if the key is publicly viewable. Then run ssh -i SSH-demo.pem ec2-user@<public-IP>.
  • •Connection creates packets: source IP is laptop private IP, translated by router (NAT) to public IP; destination port TCP 22; after successful connection, verify private IP matches instance, test internet with ping 8.8.8.8, and confirm communication is encrypted via key pair.
  • SSH into EC2 from Windows: Same Process, Different Client ⏱ 471:18

  • •In AWS console, create another Amazon Linux t2.micro free tier instance in Ohio, create and download a new key pair (e.g., win-key.pem), and configure custom VPC, public subnet, auto-assign public IP enabled, and testing security group.
  • •On Windows, download the key file (stored in Downloads), open Command Prompt, navigate with cd Downloads, and run ssh -i win-key.pem ec2-user@<public-IP>; chmod 400 is not available on Windows CMD, so skip it.
  • •After connecting, verify Amazon Linux 2023 prompt, run sudo su then ping 8.8.8.8 to confirm internet access; 0% packet loss indicates success. Exit SSH and terminate the instance when done.
  • Cleaning Up the Cloud Instance and Intro to HTTP/HTTPS ⏱ 480:26

  • •Terminate unused cloud instances to avoid charges: check the instance state and click terminate and delete, then confirm it is shutting down. CLS clears the terminal in Windows and clear in Linux/Mac.
  • •HTTP (Hypertext Transfer Protocol) is the set of rules browsers and websites use to communicate; HTTPS is its secure version, ciphered/encrypted so nobody can read the traffic even if intercepted (man-in-the-middle).
  • •HTTP functions at layer 7 (application layer) and uses TCP port 80 at layer 4; TCP means client and server establish a connection and agree on rules (sequencing, retransmission, error codes) via SYN/ACK beforehand. HTTPS runs at layer 7 over TLS (Transport Layer Security) and uses TCP port 443.
  • •Because HTTP defines rules, formats, and error messages, its language was adopted between application components; HTTP headers are only understood by devices processing up to layer 7 (web servers, security filters). Ports can be reconfigured (e.g. 8000 or 8080), but client and server must match or communication breaks.
  • TCP/IP Packet Anatomy and Port Ranges ⏱ 480:26

  • •TCP is protocol number 6; UDP (User Datagram Protocol) is protocol number 17. The payload is only one part of a TCP packet; many other fields are added. HTTP-related data is added at layer 7 (e.g. HTTP headers, type of service, version, length). TTL decrements per node and is dropped at 0 to prevent endless circulation.
  • •The protocol field tells layer 4 whether to establish a reliable connection (TCP, 6 — retransmission, airflow, flow control) or just de-encapsulate and deliver (UDP, 17). Source and destination IP addresses occur at layer 3 (IP headers); source and destination ports occur at layer 4 (TCP/UDP headers); source and destination reverse in the response.
  • Port RangeNameNotes
    0–10023Well-known / assignedHTTP 80, HTTPS 443, SSH 22, DNS 53 (TCP or UDP), RDP (Microsoft), MySQL 3306
    RegisteredRegistered portsCompanies usually avoid using deliberately
    94152–655335Dynamic/private (ephemeral)Clients use freely without permission or conflict
  • •The browser picks a random unused port from the dynamic range for each session; the server replies by reversing source/destination, so the client knows which session or app to deliver to. Example: source IP and source port (e.g. 50000) belong to the client, destination port 80 and destination IP to the server; in the response these are reversed (protocol still 6).
  • Network Flows, Ports, and Firewall Configuration ⏱ 500:28

  • •When configuring packet filtering, firewalls, or security, draw the diagram: identify client, server, source, and destination for each direction; the reverse direction reverses source/destination.
  • •If a server initiates a connection (e.g., to an update server on port 443), the server becomes the source with a random ephemeral port (49152–65535) and the update server is the destination.
  • •Example with one server running SSH on port 22 TCP, DNS, and web server on ports 80 and 443: a client connects to SSH using a random source port (e.g., 61234) with destination 22 TCP, then opens HTTP with another unused port (e.g., 50000) with destination 80 TCP; responses reverse the ports.
  • •There are over 16,000 ports in the ephemeral range; no one needs 16,000 simultaneous sessions, but this range provides ample source ports.
  • Key ports to remember:

    ServicePort
    SSH22 TCP
    HTTP80 TCP
    HTTPS443 TCP

    Cybersecurity vs. Network Security and Firewall Fundamentals ⏱ 506:39

  • •Cybersecurity protects computers, networks, and data from theft, attacks, damage, and loss; network security is just one part of cybersecurity.
  • •Analogy: protecting your house involves locking doors (passwords), closing curtains (encryption), alarm systems (antivirus/monitoring), and checking who's at the door (authentication).
  • •Specializations under cybersecurity include network security, application security, endpoint security, cloud security, identity and access management, physical security, and compliance/auditing.
  • •Firewalls are security gates that can be layer 4 (understand IP and transport layer only) like AWS security groups and network ACLs, or next-generation/web application firewalls (layer 7) that can inspect headers and payload; they can be hardware or software-based, placed in front of switches, servers, or routers.
  • Security Zoning Architecture and Security Groups in Cloud ⏱ 520:28

  • •Security zoning architectures divide networks into zones based on criticality and risk: zero trust (internet), low trust (external DMZ), medium trust (WAN corporate users), high trust (applications, user systems), highest trust (databases, mission critical applications). Firewalls between zones enforce trust boundaries.
  • •Workloads in external DMZ include VoIP servers, FTP servers, web, DNS, VPN, and other internet-exposed services that are not high-risk or highly critical.
  • •Security groups are virtual stateful firewalls applied at the instance network interface (ENI) in AWS (also Azure and Google). They only support allow rules; anything not allowed is implicitly denied. Changes take effect immediately.
  • •Inbound rules specify source IP, protocol, and destination port range; outbound rules specify destination and port. Stateful security groups automatically allow return traffic; stateless firewalls require explicit rules for both directions.
  • •Example inbound rules: allow HTTP (port 80) from IP 98.123.73.2/32; allow SSH (port 22) from IP 95.126.59.1/32. Requests from other IPs or to other ports are implicitly denied.
  • AWS Security Group Rules: Inbound, Outbound, and Default Behavior ⏱ 540:28

  • •Inbound rules: source is the client/initiator; port is on the instance. Outbound rules: destination IP and port are on the destination, not the instance; source is the instance (introducer) since the firewall already knows its IP and port.
  • •Security groups have only allow rules — no deny rules — with an implicit deny all at the end. Only exceptions apply; everything else is blocked.
  • •Default VPC security group: inbound allows all traffic, all protocols, all ports only if the source is the same security group ID (an instance with the same SG applied); outbound allows all IPv4 traffic, all protocols, all ports to all destinations. Default VPC and custom VPC security groups share the same behavior.
  • •Security groups are stateful: if traffic is allowed in one direction, the response is automatically allowed in the reverse direction, e.g. outbound HTTP port 80 allowed, inbound response passes even with no inbound rule.
  • •Examples: allow IPv4 HTTP on port 80 outbound to a specific IP (needs to be known); allow HTTPS port 443 outbound to another specific IP; ping or SSH not matching those rules is blocked. Example stress-test: no inbound rules + wide-open outbound means outbound pings succeed (e.g. ping to 8.8.8.8) and the response passes due to statefulness.
  • Security Group Walkthrough in the AWS Console ⏱ 540:28

  • •Security groups found under EC2 and VPC consoles. Default security groups named "default" with description "default VPC security group"; each VPC (default and custom) comes with one default SG.
  • •Default SG inbound shows no rule name, only a rule ID, and allows all traffic, all protocols, all ports — but the source is the security group's own ID (A11 and EA11), meaning only instances with the same SG (same or different subnet) can pass.
  • •Console warnings note that rules with a 0.0.0.0/0 source allow all IP addresses and can be dangerous — only known IP addresses should be allowed. Editing rules: choose type (Custom TCP/UDP, ICMP, SSH, SMTP, all traffic), protocol, port, source; for outbound, destination port is on the destination server.
  • •To restrict outbound to a specific server, use custom TCP with a port (e.g. 8000 for a server expecting requests there) and optionally restrict to a single destination IP. Outbound must account for every possible communication leaving the instance (e.g. database access, ping, HTTP to a third IP).
  • •Creating a new SG: no inbound rules added means zero allows — all outside-originated traffic is dropped by the implicit deny; outbound remains wide open. Practice inbound rules examples: rule 1 — HTTP/TCP port 80, source 0.0.0.0/0 (any subnet, VPC, or internet), allowed, with implicit deny at end; rule 2 — allow SSH on port 22 from a specified source.
  • Security Group Rule Interpretation and Hands-On Lab Setup ⏱ 560:28

  • •Inbound rule /0 on HTTP port 80 allows anyone to access the instance over HTTP regardless of source IP; inbound rule on TCP port 22 (SSH) restricted to a specific IP (e.g., the administrator's 192.x.x.x) allows only that address to SSH in.
  • •Outbound rule 'all traffic, all protocols, all port ranges, 0.0.0.0/0' means the instance can send any traffic anywhere on any port (e.g., download updates); this is the default in AWS and is not recommended, as AWS defaults to allow all outbound and block all inbound.
  • •Example with custom TCP port 5432 outbound to 10.0.20.0/24: instance A can connect to any of the 254 usable hosts in that /24 subnet on port 5432; reserved IPs (broadcast, subnet ID, and first 3) mean 251 usable; traffic must also be allowed inbound at the destination's security group or it will be blocked, so rules must be allowed along the entire path.
  • •Inbound example with custom TCP port 3306 and source 10.0.1.0/24: port 3306 is a well-known database port (MySQL); the rule allows access only if the request comes from within the same subnet, e.g., another instance in that subnet; security groups are stateful, and it is advised to draw flows until comfortable.
  • •Lab setup requires creating two security groups (SGA and SGB) in the custom VPC with default inbound/outbound rules; security groups are tied to a VPC, not an account, so they are not visible in other VPCs.
  • •Create two instances (instance_A and instance_B) in the public subnet (subnet 1 public) of the custom VPC, each with a key pair (instance_A key, instance_B key), a public IP assigned, and associated with SGA and SGB respectively.
  • •Use Amazon Linux, t2.micro (free tier eligible); both instances in the same subnet implies the same availability zone, since subnets do not extend beyond an availability zone; the speaker notes infrastructure is normally built via scripts (Terraform, CloudFormation) rather than manually, but this lab is manual.
  • Security Groups in Practice & Network ACLs Introduction ⏱ 580:29

  • •SSH into instance B timed out because the security group dropped the request; responses to ping/SSH must come from the instance. Adding "allow SSH inbound from anywhere" to SGB and SGA fixed it, then chmod was needed for the unprotected private key file. After SSH from instance A to B succeeded, instance A was confirmed at private IP 172.31.4.157.
  • •The Network ACL is a virtual firewall at the subnet level; it does not understand upper layers. It's optional unless specializing in cloud/network engineering or security, but important for anyone building AWS infrastructure. Rules are numbered and evaluated from the lowest number until a match is found; parameters include traffic type, protocol, port range, source/destination, and allow/deny action. An explicit deny (*) applies if no match is found. It functions at the implied router and applies to all instances in the subnet.
  • •NACLs are stateless — both directions must be allowed for SSH. AWS default NACLs in default and custom VPCs (rule 100 inbound/outbound) allow all traffic, all protocols, all ports to all sources/destinations — not good security practice. They can be associated to subnets via subnet associations; one default ACL per VPC applies to every subnet unless custom ACLs are created. Use cases include denying specific malicious IP ranges at the subnet level, and for compliance-heavy environments requiring multiple layers of protection.
  • Network ACLs: Editing Rules, Evaluation Order, and Stateless Behavior ⏱ 600:30

    Inbound rule order (evaluated lowest to highest):
    - Rule 50:  Deny ICMP IPv4 from anywhere
    - Rule 100: Allow all traffic from anywhere
  • •Network ACLs inspect traffic only at the subnet boundary; rules are always evaluated starting from the lowest numbered rule and stop at the first match, so adding a rule with a lower number (e.g., 50) takes precedence over 100, while a higher number (e.g., 150) is checked after the allow-all rule.
  • •Deny rules can be made more specific and placed at the top so later rules define what is allowed; ACLs work the same for inbound and outbound directions, but they are stateless — both directions of a communication must be configured explicitly.
  • •Hands-on demo steps: create security groups SGA and SGB allowing all traffic inbound and outbound on all ports in a custom VPC, create EC2 instances A and B in public subnet 1 with public IPs and keys instance_a_key / instance_b_key, then ping the public IPs from a laptop — ping succeeds because the NACL allows all traffic and the security groups block nothing.
  • •Blocking ICMP inbound with rule 50 (and allowing all other traffic with rule 100) stops pings from the laptop; both instances A and B are in the same subnet, so a subnet-wide NACL deny applies to everyone in that subnet, and a laptop ping to either public IP fails once rule 50 is in place.
  • Subnet-Local Traffic and NACL Scope ⏱ 600:30

  • •If ICMP is blocked inbound and outbound at rule 50 with rule 100 allowing all other traffic, SSH from a laptop into instance A still works while pinging instance B's public IP from the laptop fails.
  • •From inside instance A, pinging instance B's private IP succeeds even with ICMP denied in both directions — the NACL and implied router are not involved because traffic stays local within the subnet; the router (and thus the NACL) only intervenes when traffic leaves or enters the subnet.
  • •The segment closes by adding a rule number 50 on the default NACL in the custom VPC to block SSH from anywhere.
  • Network ACL Hands-On: Stateless Behavior and Cleanup, Then a Preview of Module 9 ⏱ 620:32

  • •NACL rules are evaluated in order by number: added deny SSH as rule 70 and deny ICMP remained at 15; allow all traffic was 100. Because SSH rule 70 is hit before allow-all 100, SSH to instance A and ICMP ping from the laptop both failed and the existing SSH connection was lost.
  • •Tested stateless behavior: inbound allowed all traffic, but outbound was edited to leave only the explicit deny all. SSH then failed because the instance's response was blocked on the outbound side; traffic leaving the instance's subnet must pass through the router and that subnet's network ACL. Restored the outbound allow-all rule at number 100 and verified SSH worked again.
  • •Module 9 will cover monitoring and alerting to confirm infrastructure/network performs as expected in real time, logging for compliance and troubleshooting, DNS, an introduction to databases (why we need them and types), and drawing professional architecture diagrams.
  • [s:37568] DNS translates names like www.dolphin.com into public IP addresses; clients receive a DNS server via automatic Wi-Fi/DHCP configuration or static configuration. A DNS query goes from the browser to that DNS server's IP, which checks its database and returns the destination IP so the packet can be formed.

  • •Commands: nslookup (also dig) for domain lookups; ipconfig /all on Windows; cat /etc/resolv.conf, systemd-resolve --status (systemd), and nmcli (NetworkManager/Red Hat) on Linux.
  • •Demo on an AWS Linux EC2 (t2.micro, custom VPC, public subnet, public IP, security group allowing all in/out) showed /etc/resolv.conf DNS server 172.31.0.2 (second usable IP in the subnet) and dig www.google.com resolving to 142.250.190.68 with IPv4 and IPv6.
  • •Editing /etc/hosts with 172.31.0.55 www.google.com made ping resolve to the private IP instead, demonstrating that ping checks local DNS files before querying the DNS server. Cleanup returned the ACL to the default allow-all in/out.
  • Dig vs Local Hosts Files, AWS Route 53, and Monitoring/Alerting/Logging ⏱ 640:33

  • •dig www.google.com bypasses local files like /etc/hosts and queries DNS directly, while tools like curl and ping may respect local host file entries; this was demonstrated by editing the hosts file so ping used the local IP but dig returned the correct DNS IP.
  • •AWS Route 53 is a DNS service for hosting domains and creating hosted zones/records (e.g., www.din.com, marketing.dinite.com), allowing corporates to rely on AWS DNS in the cloud, though it is beyond fundamentals.
  • •Monitoring watches system metrics in real time for health, performance, and security (e.g., macOS Activity Monitor showing CPU utilization, memory, energy, disk, network; Windows Task Manager); metrics like CPU utilization, memory, disk space, and network in/out indicate system status.
  • •Alerting notifies on pre-identified events or thresholds (e.g., failed SSH attempts, critical server CPU reaching 80% or 90%), such as an AWS budget alarm set to notify at 60% of a $6 budget, with a projected $4.84 cost; logging archives events/errors for auditing and troubleshooting, with AWS CloudTrail enabled by default (free, events kept 90 days, then purged unless exported) and CloudWatch providing metrics, alarms, dashboards, and log groups.
  • Databases: Purpose, Types, SQL, and Operations ⏱ 652:38

  • •A database is an organized collection of data easily stored, searched, updated, and retrieved by software; it persists even if the application fails and supports backups/restores. Applications need databases to store user data, orders, patient records, and transactions via write (input) and read (query) operations.
  • •Database types include relational (tables; e.g., Postgres, MySQL, SQL Server), NoSQL (e.g., MongoDB, AWS DynamoDB), in-memory (e.g., Redis), and time series (e.g., InfluxDB, Amazon Timestream); relational is most common, with NoSQL gaining popularity.
  • •SQL (Structured Query Language) lets applications read/write relational databases using queries, e.g., SELECT * FROM orders WHERE customer = 'Bob', or queries to count how many pizzas Bob ordered, total revenue today, or show all orders with pepperoni pizza.
  • •Databases are persistent, maintaining data even when infrastructure issues occur.
  • Database Fundamentals and SQLite Hands-On ⏱ 660:34

  • •Databases are an integral part of any infrastructure and are needed for AI, machine learning, cybersecurity, and more; data persists even if an application fails, provided backups, copies, or snapshots are taken regularly so data can be restored into a new database.
  • •A hands-on demo uses SQLite (free online at SQLLonline.com); in the cloud there are many AWS, Azure, and Google database services, and here the application role is done manually.
  • •The demo builds a table with columns ID, name, and city: ID 1 = Alice / New York, ID 2 = Muhammad / Cairo, ID 3 = George / London.
  • •SQL script deletes the table if it exists, then creates the customers table (ID as integer, name as text, city as text), inserts the three rows, then queries the full table, where ID equals 1, and where name equals George; a drop table removes it.
  • •These statements are normally encoded into application code — e.g. a school UI's "check your GPA" translates into select from the grade table where the subject is chemistry and the user is George.
  • sql
    delete table if it exists customers;
    create table customers (ID integer, name text, city text);
    insert into customers values (1, 'Alice', 'New York');
    insert into customers values (2, 'Mohammad', 'Cairo');
    insert into customers values (3, 'George', 'London');
    select * from customers;
    select * from customers where ID = 1;
    select * from customers where name = 'George';

    Architecture Diagrams in draw.io (app.diagrams.net) ⏱ 667:47

  • •Practice drawing professional-looking architecture diagrams: an AWS VPC with Region US East 1 (North Virginia), CIDR block 10.016, Availability Zone 1A (public subnet + private subnet with their IP ranges, security groups, web server 1, and a database), Availability Zone 1B (public subnet 2 and private subnet 2), plus route table info, IGW, internet, and users; the VPC stretches across zones.
  • •Use app.diagrams.net or draw.io (same site); choose where to save (device, OneDrive, Google Drive), create a new blank diagram, and save it to a folder such as downloads or "drawings".
  • •Search the left pane for icons (e.g. AWS 2025 open library, 3D) to drag shapes onto the canvas; keep it to one page to save and print easily.
  • •Layers matter: if a shape can't be clicked, the layer in front is blocking it — click the blocking shape and send it to back; use Control+D to duplicate, Control+B for bold, adjust fill, line color, and line size to distinguish elements, and change text color as needed.
  • •Steps shown: drag the AWS region (rename to US East 1), add two availability zones (1A, 1B), add the VPC and send it back, add the internet icon and users, then add two public subnets and two private subnets (one of each per zone).
  • Building an AWS VPC Architecture Diagram (Public/Private Subnets, IGW, Route Tables, RDS) ⏱ 680:35

  • •Layout starts by placing the internet/IGW on one side so the two public subnets (10.0.0.0/24, 10.0.1.0/24) sit closer to the internet and the private subnets (10.0.100.0/24, 10.0.200.0/24) stay behind; VPC CIDR set as 10.0.0.0/16.
  • •Two EC2 "Web Server 1/2" instances are drawn inside the public subnets, each wrapped in a security group; an internet gateway sits at the VPC border and connects to the implied router, which is linked (via the icon arrow) to all four subnets.
  • •Route tables use two columns (destination/target): public route table(s) share 10.0.0.0/16 → local and 0.0.0.0/0 → IGW, applying to both public subnets ("public RT"); private route tables are named "private RT 1" and "private RT 2" and omit the 0.0.0.0/0 → internet gateway row because they have no internet access.
  • •Final additions are the RDS database under each private subnet's security group (icon resized/shrunk to fit, copy via Control D); tables need cells highlighted individually for fill color to take effect (set fill to solid, e.g. blue), and no security group is yet placed in the private subnets beyond the database.
  • •Export options include PNG, JPEG, SVG and PDF; PNG allows a transparent background for dropping the diagram into PowerPoint or documents without gridlines.
  • What the Diagram Demonstrates and Icon Library Options ⏱ 680:35

  • •The drawing shows understanding that a VPC is confined to a region while extending workloads across multiple availability zones, with AZs horizontal that would look identical if shifted 90 degrees; different colors distinguish different route tables, and IP addresses and web server names are labeled.
  • •Beginners can start simpler with one availability zone, one subnet, one implied router or IGW, and a small VPC, then grow skills; larger drawings can expand into other pages but become hard to fit and keep visible in documents.
  • •Beyond AWS, icons are available for Azure, GCP (Google Cloud), Cisco (networking), and Kubernetes, plus general-purpose shapes (rectangles, circles, triangles, arrows); Docker has some icons, Terraform/HashiCorp does not have many, and users can download additional icon libraries.
  • Why Linux and Bash Are Essential for Modern IT ⏱ 700:45

  • •Linux runs ~95% of internet servers powering cloud, AI, DevOps; learning Linux is advocated over Windows Server, and it's the prerequisite for Docker, Kubernetes, Terraform, Git/GitHub. It's free, and Linux admin offers a quick entry into IT. Minimum skills: file system navigation, files/folders/permissions, users/groups, terminal shell, common commands, package install/tune. Certifications: Red Hat Certified Systems Administrator (prep: 1.5–3 months; exam cost ~$350–$450) or LPIC; either enables learning any distribution (Ubuntu, Red Hat, Kali).
  • •Linux CLI basics: whoami (current user), pwd (location), ls (list), cd (change directory), mkdir (create directory), cat (print file), touch (create file), nano (edit file), echo with redirection (write to file).
  • •Demo scenario: Launch Amazon Linux 2023 (AL2023) t2.micro EC2 in a custom VPC public subnet with public IP, existing key, security group allowing all traffic; connect via EC2 Instance Connect; sudo su to root; practice navigating, creating/deleting files/folders, moving files, then terminate the instance to avoid charges.
  • •Bash (Bourne Again Shell): Linux's default shell and scripting language for automating tasks, chaining commands. Used in cloud, DevOps, cybersecurity; enables automated backups (e.g., database copy nightly at 1 a.m.), VM start/stop (7 a.m./6 p.m.), and routine cleanup.
  • Automation with Bash, Role Requirements, and a Comparison with PowerShell and Python ⏱ 720:46

  • •Cloud setup, security, and monitoring can be automated: launch and configure instances, install packages, scan logs for failed logins, and generate reports (e.g., disk usage via email) using Bash scripts.
  • •Bash is needed for IT support, network engineers, technical support, sysadmins (fix/manage files, generate reports, troubleshoot via CLI, create/manage users), DevOps (CI/CD, server management, cloud scripts to bootstrap VMs), cloud engineers (user data scripts to install packages/services and start them at boot), cybersecurity analysts (log analysis, automating tools, network scans), and sysadmins/SREs/platform engineers (system health checks, backups, updates). Most US jobs ask for Bash, PowerShell, or Python.
  • •Comparison of the three tools:
  • AspectBashPowerShellPython
    OS/AudienceLinuxWindows / Active Directory; now cross-platformAny OS (needs runtime)
    SyntaxSimple Linux commandsVerbose, harder but powerfulClean, readable programming language
    Best forNative Linux tasks/automationWindows/ADFull-featured applications, complex automation, data manipulation, event-driven tasks
    Learning curveEasy for beginnersSlightly steeper than BashProgramming language
    AWS usageExcellent for EC2 user data scriptsLess commonWriting programs that interact with AWS services
  • •Recommended path: learn Linux fundamentals, then Bash, then Python. With RHCSE you can find entry-level jobs in about 4 months; Python automation is in high demand.
  • •Demo goal: bootstrap an Amazon EC2 Linux instance in a public subnet with a security group allowing at least port 80 inbound (and SSH for troubleshooting).
  • Bootstrapping an EC2 Instance with a Bash User Data Script: Manual vs Automated Workflow ⏱ 727:01

  • •The user data script installs Apache as the instance boots:
  • bash
    #!/bin/bash
    dnf update -y
    dnf install -y httpd
    systemctl start httpd
    systemctl enable httpd
    echo "<h1>Welcome to my EC2 instance</h1>" > /var/www/html/index.html
  • •Manual instance: launched without a script, connected via EC2 Instance Connect (SSH inbound must be open), ran sudo su, then dnf update -y, dnf install -y httpd, systemctl start httpd, systemctl status httpd, systemctl enable httpd; Apache then served its default "It works!" page on port 80. Using echo "Hello from Apache" > /var/www/html/index.html replaced it.
  • •Automated instance: launch with the same settings (key, custom VPC, public subnet, public IP, security group) and paste the script under Advanced Details → User Data. Common problem: line breaks get scrambled when copying from PDF/Word; fix by pasting into a plain text editor or adding a line break after every command, so each is treated as a separate line. Comments can be removed.
  • •After launch, no waiting, SSH, or typing is needed; once the instance boots, the script runs line by line. The public IP showed "Welcome to my EC2 instance" from the echo statement. This demonstrates the power of scripting/cloud automation (zero clicks, no SSH), which can also schedule backups, read logs, and build complex logic. Terminate unneeded instances, and note the module also introduces DevOps, SRE, platform engineering, and DevOps; the SDLC (requirements → planning → code → test → deploy) relates to all of these.
  • Software Development Life Cycle, Waterfall, and Agile ⏱ 740:48

  • •SDLC workflow: planning → team assignment/coding → build → testing → feedback → release → deployment → operations/monitoring, then repeats; benefits include systemic approach, measurable process, early bug detection, faster delivery, and higher quality.
  • •Old way was siloed teams (dev, QA, release, ops) handing off sequentially with no collaboration, causing long bug lists and slow releases.
  • •Waterfall is the legacy sequential model: requirements → design → coding → build/test → deployment → operations/maintenance; fits only well-defined requirements, releases every 6 or 12 months, manual testing, doesn't accommodate new requirements.
  • •Agile is an iterative/flexible methodology using sprints of 2 to 4 weeks to deliver working software more frequently; testing is continuous but semi-manual, and it ends at code handoff to ops, creating friction since ops teams remain slow/manual.
  • DevOps, CI/CD, and Programming Skills ⏱ 752:08

  • •DevOps increased automation and merged development, QA/testing, and operations into one team; it extends Agile beyond coding into deployment, infrastructure, operation, monitoring, and maintenance with collaboration and shared responsibility.
  • •DevOps goals/benefits: faster delivery, improved collaboration, more reliable releases, automated testing/deployment/monitoring, better scalability, performance, and quality.
  • •DevOps practices: continuous integration (commit changes to a repo like GitHub auto-triggers build/test), continuous delivery (software ready for release, manual approval/scheduling into production), continuous deployment (deployed automatically without human intervention — risky, not common for critical apps), infrastructure as code (Terraform, Python, CloudFormation scripts), automated testing, and configuration management.
  • •You do not have to be a full stack/back-end developer, but you must know programming fundamentals — logic, data types, data structures, budgeting, and scripting (Terraform, Bash, Python, SDKs) for automation, monitoring, and alerting; recommended languages are Python or Go, learnable in a 6 to 10 hour course.
  • SRE, Platform Engineering, and DevSecOps: Evolution Beyond DevOps ⏱ 760:48

  • •SRE emerged because DevOps overlooked post-deployment reliability: DevOps focuses on speed and frequent releases, but does not define who handles uptime, performance, capacity planning, incident management, or being awake at 3 o'clock in the morning; Google created Site Reliability Engineering (SRE) to fill this gap.
  • •SRE vs DevOps: SRE focuses on reliability, uptime, performance, incident response, monitoring, alerting, capacity planning, error budgets, SLIs, and SLOs, and performs root cause analysis as a team; DevOps focuses on CI/CD, release automation, testing, configuration management, infrastructure as code, and faster delivery. Core skills overlap (Kubernetes, cloud, logging, Linux, Bash), but monitoring and capacity planning tools are more specialized for SREs; the two can coexist and are complementary.
  • •Platform engineering emerged to solve two DevOps scaling issues: (1) DevOps teams get overwhelmed with infrastructure, Kubernetes, CI/CD, IaC, security, and monitoring, becoming a bottleneck that slows developers; (2) decentralizing DevOps engineers across teams causes inconsistency, lack of standardization and governance, extra cost, minimal reuse, and harder troubleshooting. Platform engineering builds an Internal Development Platform (IDP) enabling self-service—developers click to get a repository, a Kubernetes cluster, and a CI/CD pipeline. The IDP integrates tools like Kubernetes, OpenShift, Docker, Terraform, Jenkins, GitLab, Pulumi, Git, GitHub, GitHub Actions, Python, and cloud environments.
  • •DevSecOps integrates security into every DevOps stage: from planning (security requirements, threat modeling) and coding (static code analysis) to building (dependency scanning with Snyk, Trivy, Dependabot), CI/CD (secret scanning, policy checks), containers (image scanning), IaC (Checkov, Terraform Sentinel), secrets management (HashiCorp Vault, AWS Secrets Manager, Sealed Secrets), and production monitoring (Falco, OPA, AWS GuardDuty). Core message: think security in every action, step, technology, code, and image.
  • Key Takeaways

  • •Cloud computing uses a pay-as-you-go Opex model, in contrast to the large upfront CapEx investment required for on-premises data centers.
  • •Subnetting divides an IP block into smaller chunks to support different offices, LANs, WANs, and separate data center functions, with each subnet having its own network ID and broadcast address.
  • •A subnet is public only if its VPC has an internet gateway attached and its route table has a default route to that internet gateway; otherwise it is private.
  • •Security groups are stateful and control inbound and outbound traffic at the instance level, while network ACLs are stateless and operate at the subnet level with rules evaluated in order by number.
  • •Linux runs approximately 95% of internet servers and is a prerequisite for Docker, Kubernetes, and DevOps tools; Bash is used to automate cloud setup, security, monitoring, and reporting.
  • •DevOps merged development, QA, and operations into one team with increased automation; SRE emerged to address reliability and uptime after deployment, and DevSecOps adds security throughout the lifecycle.
  • Conclusion

    The course covers IT fundamentals from hardware and operating systems through networking, cloud computing with AWS, security, databases, and DevOps practices. It emphasizes hands-on labs and automation skills essential for modern IT roles.

    Bu video hakkında soru sor