Cloud Networking & Security Made Clear
Beginner-friendly explanations on networking, cloud architecture, traffic flow, and security fundamentals — focused on clarity, not vendor marketing.
Our Mission
Free, foundational education in cloud networking and security — for anyone, anywhere. Clarity makes learning accessible to everyone.
Explore Topics
Cloud Networking
Flow, Connection, Session — firewall fundamentals explained clearly.
Cloud Security
DDoS attack types and how modern networks defend against them.
Blog
Deep-dives including A Packet Journey — from bits to the cloud.
What You Will Learn
- Networking fundamentals — OSI, TCP/IP, routing
- Traffic flow — DNS, ICMP, TCP handshakes
- Firewall concepts — Flow, Connection, Session
- Cloud architecture — data centers, virtualization
- Security basics — firewalls, IDS/IPS, TLS, DDoS
About Me
I bring over two decades of experience in networking and security, and I continue to share my knowledge through research and blogging, with a strong focus on clarity and practical understanding.
- Network Architecture — Private and Public cloud environments for enterprise customers
- Cloud Infrastructure Design — AWS, Azure, and Oracle Cloud Infrastructure (OCI)
- Network Automation & IaC — Terraform, K8s Cilium
I currently lead Cloud Network & Security for a large bank, managing a large-scale multi-cloud environment. Before this, I spent 16 years with GBM, IBM's representative office in the Middle East.
I strongly believe that anyone with curiosity, consistency, and a willingness to learn can reach meaningful levels in their career.
Connect
Cloud Networking
Core networking concepts mapped to cloud — from firewall fundamentals to AWS routing architecture.
Flow
One direction of traffic, defined by the 5-tuple. Two flows make a full conversation.
Connection
Both directions combined — a full conversation between two devices.
Session
The firewall's internal state entry tracking a connection in its session table.
Flow
- Unidirectional — one direction only
- Used in monitoring systems — NetFlow, IPFIX, sFlow
- Used in cloud flow logs — AWS VPC Flow Logs, Azure NSG Flow Logs
Think of a flow as one direction of traffic.
Connection
- Bidirectional — both directions combined
- TCP connections begin with the SYN handshake
- Often used in traditional firewall terminology
- UDP is connectionless but firewalls still track it
Think of a connection as a full conversation.
Session
- Original and translated IPs/ports — pre and post NAT
- Policy ID — which rule matched
- Timeout values — when to expire the entry
- Security profile information — AV, IPS, URL filtering
- Byte and packet counters — traffic statistics
Think of a session as the firewall's memory of a conversation.
How They Relate
2 flows, 1 connection, and 1 session in the firewall's state table.From Cisco VRF to AWS Transit Gateway
AWS networking is not mysterious — it's just routing concepts implemented differently. This guide maps Cisco VRF, routing, and BGP fundamentals directly to AWS constructs so cloud routing makes intuitive sense.
1 — Revisiting Cisco Fundamentals
What Is a Router?
A Cisco router maintains a routing table, performs destination-based forwarding, supports dynamic routing protocols (BGP, OSPF, EIGRP), has multiple interfaces, and can run multiple VRFs. At its core, routing is simple: match destination → lookup route → forward out interface. Everything else is control-plane sophistication.
What Is a VRF?
A VRF (Virtual Routing and Forwarding) is a separate routing table inside the same router. Each VRF has isolated routes, can reuse overlapping IP ranges, has dedicated interfaces, and does not see other VRFs unless you explicitly leak routes.
Think of a VRF as a virtual router inside a physical router. This is the key to understanding AWS Transit Gateway.
| VRF Example | Address Space | Isolation |
|---|---|---|
| VRF-PROD | 10.0.0.0/16 | Fully isolated |
| VRF-DEV | 10.0.0.0/16 | Same range — no conflict |
2 — The VPC Router
Every VPC in AWS has an internal router. You never see it, but it exists. It routes traffic between subnets and forwards to Internet Gateway, NAT Gateway, VPC Peering, or Transit Gateway. But it is very basic.
🔹 VPC Router — Can
- Route between subnets in one VPC
- Forward to IGW, NAT-GW, TGW
- Use static route tables
🔹 VPC Router — Cannot
- Connect VPCs together
- Run BGP
- Support VRFs
- Perform dynamic routing
- Do NAT or firewalling
Think of the VPC Router as a simple internal L3 gateway for one VPC only. It is not the cloud equivalent of a Cisco ISR or ASR.
3 — What Is AWS Transit Gateway?
Transit Gateway is a managed Layer 3 routing device that supports multiple routing domains. This is where Cisco engineers should think: TGW route tables = VRFs.
🔷 Transit Gateway
- Connects many VPCs
- Connects VPN & Direct Connect
- Connects SD-WAN
- Multiple route tables (like VRFs)
- Supports BGP via DX/VPN attachments
- Centralized routing control
🔷 TGW Architecture
Think of TGW as: a large AWS-managed core router with multiple VRFs, dynamic routing at the edge, but no firewall, no NAT, no inspection.
4 — Cisco → AWS Concept Mapping
Once you internalize this table, AWS networking becomes logical.
| Cisco Concept | AWS Equivalent | Notes |
|---|---|---|
| Router | Transit Gateway | Managed Layer 3 routing device |
| Interface | TGW Attachment | VPC, VPN, or DX connection |
| VRF | TGW Route Table | Isolated routing domain |
| Assign interface to VRF | Association | Attachment → Route Table |
| Route leaking | Propagation | Share routes between tables |
| BGP neighbor | Direct Connect / VPN edge | BGP at attachment edge only |
Each attachment (VPC, VPN, Direct Connect) behaves like an interface on a router.
5 — How Traffic Flows Inside TGW
Example: VPC-A 10.1.0.0/16 → VPC-B 10.2.0.0/16, both attached to TGW.
EC2 in VPC-A sends traffic
VPC-A route table says: 10.2.0.0/16 → TGW. Packet is forwarded to the TGW attachment ENI.
Packet enters TGW
TGW receives the packet on the VPC-A attachment. Each attachment is associated with a specific TGW route table — like assigning an interface to a VRF.
TGW route lookup
TGW route table contains: 10.2.0.0/16 → VPC-B attachment. TGW selects the correct attachment.
Packet forwarded to VPC-B
TGW forwards packet to VPC-B attachment.
VPC-B delivers to EC2
VPC-B route table delivers the packet to the destination EC2 instance.
TGW is stateless — no session table, no NAT, no inspection. Pure Layer 3 destination-based forwarding. Just like a router.
6 — TGW with Direct Connect & BGP
Connecting on-premises networks to AWS via Direct Connect and BGP.
BGP at the Edge
Your Cisco router establishes a BGP session over Direct Connect. You advertise 10.0.0.0/16 — AWS learns this route.
DX Gateway association
DX Gateway associates with Transit Gateway. TGW installs: 10.0.0.0/16 → DX attachment.
TGW route table populated
10.0.0.0/16 → DX attachment10.1.0.0/16 → VPC-A attachment10.2.0.0/16 → VPC-B attachment
EC2 to On-Prem
EC2 → TGW → DX Gateway → Direct Connect → On-prem router
Return traffic
On-prem → Direct Connect → DX Gateway → TGW → correct VPC
TGW does NOT run BGP internally. BGP happens at the DX/VPN attachment edge. TGW simply installs learned routes — it is the forwarding plane, not the control-plane engine.
7 — TGW vs Cisco ISR / ASR
| Feature | Transit Gateway | Cisco ISR / ASR |
|---|---|---|
| Layer 3 routing | ✅ Yes | ✅ Yes |
| Multiple routing domains | ✅ Route Tables (VRF-like) | ✅ Full VRFs |
| ECMP support | ✅ Yes | ✅ Yes |
| BGP | ⚠️ Edge only (DX/VPN) | ✅ Full control |
| OSPF / EIGRP | ❌ No | ✅ Yes |
| NAT | ❌ No | ✅ Yes |
| Stateful inspection | ❌ No | ⚠️ Optional |
| Hardware visibility | ❌ Managed / hidden | ✅ Yes |
Transit Gateway is…
- A managed cloud core router
- AWS owns the control plane
- No direct hardware access
Cisco ISR/ASR is…
- A fully controllable enterprise router
- You own the control plane
- Full protocol stack
8 — The Complete Mental Model
| AWS Component | Think of it as |
|---|---|
| VPC Router | Basic internal L3 gateway for one VPC only |
| Transit Gateway | Cloud core router |
| TGW Route Table | VRF |
| TGW Attachment | Router interface |
| Association | Assign interface to VRF |
| Route Propagation | Route leaking between VRFs |
| Direct Connect / VPN | BGP edge peer |
For network engineers transitioning to AWS — the key is not learning new theory, it's translating familiar concepts. Cloud routing is still routing. The difference is control: in Cisco, you own the control plane. In AWS, AWS owns the control plane. But the fundamentals remain: destination lookup → next-hop selection → forwarding. And that's something every network engineer already understands.
Cloud Security
Traditional vs cloud security models, DDoS protection, and how AWS enforces identity-driven policy at every action.
Traditional Data Center Security vs AWS Cloud Security
As enterprises move critical workloads to the cloud, the real transformation is not just tooling — it is architectural and philosophical. Security shifts from protecting network boundaries to enforcing identity and policy at every action.
The Traditional Data Center Security Model
Traditional data center security is primarily network-centric and perimeter-driven. The foundational assumption is simple: if a user or system is inside the trusted network, it is generally trusted.
🔹 Security Controls
- Edge firewalls — North-South traffic
- Internal firewalls — East-West segmentation
- VLAN isolation
- VPN concentrators
- Active Directory for identity
- IDS/IPS appliances
⚠️ Inherent Risks
- Lateral movement within trusted zones
- Static credential compromise
- Insider misuse
- Limited API-level tracking
- Broad internal trust after perimeter
Protection focuses heavily on securing the perimeter. Once traffic passes through the firewall, implicit trust increases significantly.
The AWS Cloud Security Model
In AWS, security becomes identity-driven, API-controlled, and policy-enforced. Every action performed in AWS is an API call that must be authenticated, authorized, and logged.
🔷 Security Controls
- IAM — identity & access management
- Security Groups — workload-level firewall
- CloudTrail — every API action logged
- Temporary credentials via STS
- Service Control Policies (SCPs)
- VPC isolation + private subnets
⚠️ Cloud-Specific Risks
- Over-permissioned IAM roles
- Publicly exposed storage or services
- Security Group misconfigurations
- Governance gaps across accounts
- Configuration drift
This is a Zero Trust approach: trust is not based on network location — trust is based on identity and explicit permission. Even inside a private VPC, access is denied unless IAM allows it.
Real-World Example: A Banking Application
Three-tier app: Web servers → Application servers → Database servers.
Traditional Deployment
- Firewall rules allowing specific ports between tiers
- AD groups controlling server access
- Service account passwords stored in config files
- VLAN segmentation between environments
AWS Deployment
- Security Groups restricting traffic at instance level
- IAM roles attached to EC2 — no stored passwords
- Temporary credentials via STS (auto-rotate)
- CloudTrail logging every API action
- SCPs for multi-account governance
Engineer attempts to terminate production EC2
An API request is generated and sent to AWS.
IAM evaluates permissions
Does this identity have ec2:TerminateInstances on this resource?
SCPs evaluated
Organization-level Service Control Policies are checked if configured.
Action denied — and logged
If permission is denied, the action fails. The attempt is recorded in CloudTrail regardless.
Service Account Security
| Aspect | Traditional DC | AWS |
|---|---|---|
| Credential type | Static passwords | Temporary STS tokens |
| Rotation | Manual — often infrequent | Automatic |
| Storage | Config files, scripts | Not stored — assumed via IAM role |
| Reuse risk | High — same creds across systems | Low — scoped, time-limited tokens |
| Compromise window | Until manually rotated | Minutes (token expiry) |
East-West Control & Audit Visibility
🔹 Traditional East-West
- Internal firewalls and VLAN rules
- Broad policies to reduce ops complexity
- Logs spread across firewall, AD, OS
- Manual correlation during investigations
🔷 AWS East-West
- Security Groups attached per workload
- Explicit, stateful rules only
- App server → DB on port 3306 only
- CloudTrail centralises all API activity
CloudTrail records: who performed the action, what action, which resource, when, and from where — providing strong forensic capability by default.
The Fundamental Security Shift
| Dimension | Traditional DC | AWS Cloud |
|---|---|---|
| Primary control | Network perimeter firewall | IAM — identity & policy |
| Trust model | Trust based on network location | Zero Trust — explicit permission required |
| Segmentation | VLAN-based, broad zones | Workload-level Security Groups |
| Credentials | Static, long-lived | Temporary, auto-rotating |
| Audit | Distributed, manual correlation | Centralised API-level logging |
| Enforcement | Hardware-enforced trust zones | Software-defined policy governance |
Cloud does not eliminate risk — it shifts risk from infrastructure weakness to configuration discipline. The shift is from "Protect the network" to "Control identity, policy, and every action."
How modern networks protect applications from volumetric, protocol, and application-layer attacks.
What is a DDoS Attack?
A Distributed Denial of Service (DDoS) attack is an attempt to make an online service unavailable by overwhelming it with traffic from multiple sources.
Testing & Resilience Validation
L3 / L4 Lab Tools
Use only in environments you own or are authorised to test.
- hping3 Protocol behaviour testing
- iperf3 Throughput baseline
- tcpdump Packet inspection
Layer 7 Load Testing
Simulate real users and APIs to validate WAF, caching, and autoscaling.
- ab Apache Benchmark — quick concurrency test
- k6 Scripted HTTP tests
- JMeter API workflows
- Locust User behaviour simulation
- Gatling High-performance load
The Goal of DDoS Protection
The objective is not just to block traffic, but to ensure legitimate users always get through while attacks are absorbed at the network edge.
Blog
Deep-dives on cloud networking and security concepts.
A Packet Journey — From Your Computer to the Cloud
Follow data from 0s and 1s all the way to the cloud — binary, transistors, OSI layers, MAC vs IP, network media, and real-world bandwidth explained.
Flow, Connection, and Sessions in Firewalls
A flow is unidirectional, a connection is bidirectional, and a session is the firewall's state record. Three terms — clearly explained.
A Packet Journey
From Your Computer to the Cloud
The Binary World: 0s and 1s
Have you ever wondered how data from your computer actually moves across the internet and ends up in the cloud? Let's start from the very basics.
Computers operate using the binary number system — only two digits: 0 and 1.
Example: To convert 13 into binary:
13 = 8 + 4 + 1 = 2³ + 2² + 2⁰ → 1101
How Are 0s and 1s Created?
At the lowest level, computers use transistors — On (1) or Off (0). Each switch is a bit; eight bits form a byte.
How Does the Computer Understand Them?
- Hardware layer
- Kernel and device driver layer
- Operating system layer
- Application layer
When you save a file, the application informs the OS, which uses drivers to write data to the drive.
Encoding of Data
Every character is encoded using ASCII or UTF (Unicode). The word network uses 7 characters → file size is 7 bytes.
MAC vs IP Address
Systems care about IP addresses at the software level. At the local network level, devices use MAC addresses — 48-bit identifiers (IEEE 802.3) that never leave the local network.
OSI Layers and Packet Formation
- Transport → Segment
- Network → Packet
- Data Link → Frame
- Physical → Bits
Each layer adds its own header. At the destination, headers are removed in reverse order.
Network Media
- Ethernet: electrical pulses over copper or fiber
- Fiber: light pulses over glass
- Wireless: radio waves (WiFi)
- PAN: Bluetooth
Network Topologies
- Bus · Ring · Star (most common) · Mesh
Speed, Bandwidth, Latency & Throughput
Bandwidth: Maximum data capacity (bps).
Latency: Time taken for a packet to travel (ms).
Throughput: Actual successful data rate.
Speed: Physical signal rate of the medium.
A 1 Gbps connection = 128 MB/s. A 1 GB file downloads in ~8 seconds.
The Journey Ends in the Cloud ☁️
The data you're reading travelled from a VS Code editor, across multiple networks, and reached you via this page hosted in the cloud.