DEV Community: huykhanh

AWS EC2 Fundamentals: Renting Computing Power Without Breaking the Bank

huykhanh — Thu, 14 May 2026 09:13:31 +0000

AWS EC2 Fundamentals: Renting Computing Power Without Breaking the Bank

Have you ever faced this nightmare: a looming deadline, a massive batch job or a machine learning model to train, but your local machine is literally "gasping for air"? Or perhaps you want to experiment with a new tech stack but are terrified of "bricking" your daily driver's operating system with messy dependencies?

Welcome to the world of Amazon EC2 (Elastic Compute Cloud) – the place where you can summon one (or a thousand) servers with a few clicks. The best part? You only pay for what you actually use.

1. What Exactly is EC2? (And Why Does Everyone Care?)

In the most practical terms, EC2 is a Virtual Machine (VM) running on Amazon's massive global infrastructure. Instead of going to a store, buying hardware, cabling it up, and worrying about cooling, you simply "rent" a slice of AWS's resources.

The name Elastic Compute Cloud wasn't chosen just because it sounds cool:

Elastic: You can scale your RAM from 8GB to 128GB in a heartbeat, or scale from 1 instance to 100 when traffic spikes.
Compute: It provides the raw CPU, Memory, and Network muscle—everything your application needs to "stay alive."
Cloud: It lives somewhere on the internet, secure, and ready 24/7.

2. The Instance Type "Menu": Picking the Right Tool for the Job

AWS doesn't sell just one type of server. They have an entire "family tree" of Instance Families optimized for different purposes. Picking the wrong one is a classic rookie mistake: either your app will crawl like a turtle, or you’ll be "burning cash" unnecessarily.

Family	Name	"Identity"	Best For...
General Purpose	T-series, M-series	Balanced CPU/RAM.	Small web servers, Dev/Test environments.
Compute Optimized	C-series	High-performance CPUs.	Batch processing, video encoding, Gaming servers.
Memory Optimized	R-series, X-series	Massive RAM capacity.	High-performance Databases, In-memory caches (Redis).
Storage Optimized	I-series, D-series	High-speed local storage.	Big Data systems, Data Warehousing.

Pro-Tip from a Senior Architect: Never pick at random! Start with a t3.micro (if you're on the Free Tier) to test your baseline. Monitor CloudWatch to see if your app is "hungry" for CPU or RAM, then scale up accordingly.

3. The "Vital Organs" of an EC2 Instance

When you launch an EC2 instance, you’ll be interacting with these four critical components:

3.1. AMI (Amazon Machine Image)

Think of this as a "Golden Image" or a blueprint. The AMI contains the OS, pre-installed software, and system configurations. You can choose Ubuntu, Amazon Linux, Windows Server, or even custom AMIs pre-baked with Docker and Python.

3.2. EBS (Elastic Block Store) - Your "Network Drive"

EBS is where your data lives. The beauty of EBS is that it’s persistent; you can detach a volume from one instance and attach it to another, or take Snapshots (backups) before you do something "brave" (and potentially destructive) to your OS.

3.3. Security Groups - The Strict Bouncer

This is your virtual firewall. It controls which traffic can enter or leave your instance.

Want to SSH in? Open port 22.
Running a Web App? Open port 80/443.
Warning: Never, ever open port 0.0.0.0/0 for all services unless you want your server to become a playground for hackers within minutes.

3.4. Key Pairs

Forget traditional passwords. AWS uses Public-Private key pairs for authentication. You keep the .pem or .ppk file, and AWS handles the public key. If you lose this file, you are essentially locked out of your own server (unless you’re a Linux forensics wizard).

4. The "Expensive" Lessons: Understanding AWS Pricing

This is where many developers experience heartbreak when the end-of-month invoice arrives. There are three main ways to buy EC2:

On-Demand: You pay by the second. It’s the most expensive but the most flexible. Perfect for short-term projects or when you’re still figuring out your requirements.
Reserved Instances (RI): Think of this as a "1-year or 3-year lease." You commit to a long-term duration, and AWS rewards you with up to a 75% discount. This is ideal for stable, always-on production databases.
Spot Instances: This is "AWS Surplus." They sell unused capacity at a massive discount (up to 90% off). But there’s a catch: if someone pays more or AWS needs the capacity back, they will "evict" your instance with only a 2-minute warning. Use this for resume-able tasks like video rendering or data scraping.

5. Automating Life with User Data

Instead of manually SSH-ing into every server to run apt-get update or install nginx, you can use User Data. This is a script that runs automatically the very first time your server boots up.

#!/bin/bash
# Update the system and install Nginx in a heartbeat
yum update -y
amazon-linux-extras install nginx1 -y
systemctl start nginx
systemctl enable nginx
echo "<h1>Welcome to my Automated EC2 Server!</h1>" > /usr/share/nginx/html/index.html

Conclusion

EC2 is more than just a virtual machine; it is the cornerstone of modern cloud architecture. Mastering Instance Types, securing your perimeter with Security Groups, and choosing the right pricing strategy will transform you from a "code-only" developer into a true Cloud Engineer.

If you are beginning your journey toward the AWS Certified Solutions Architect (SAA-C03), EC2 is the first chapter you must master. Happy scaling, and may your bills always stay low!

TL;DR (Key Takeaways)

EC2 = Virtual Servers in the cloud.
Instance Families = Optimized for different workloads (C=Compute, R=RAM, M=General).
Security Groups act as your first line of defense (Firewall).
Spot Instances are incredibly cheap but "unstable" by design.
Use User Data to automate your deployment and avoid "manual labor."

Design Patterns: The "Secret Scrolls" to Rescue Devs from Spaghetti Code Nightmares

huykhanh — Thu, 14 May 2026 03:33:15 +0000

Design Patterns: The "Secret Scrolls" to Rescue Devs from Spaghetti Code Nightmares

Every dev has been there: You wake up feeling like a coding rockstar, open your IDE to add one tiny feature, but the more you touch, the more things start to feel... "wrong." Changing a line in the UI breaks a service in the backend, the logic is as tangled as a bowl of cheap noodles, and suddenly you realize you're drowning in a "Big Ball of Mud."

This is exactly when you need Design Patterns.

Some say Design Patterns are academic overhead, reserved for Architects who spend their days drawing complex diagrams. But in reality, they are "recipes" distilled by industry veterans over decades to solve the most painful problems in software development. Instead of "reinventing the wheel"—and accidentally making a square one—why not use patterns that are proven to work?

In this deep dive, we’re going to dissect the three main pillars of Design Patterns: Creational, Structural, and Behavioral. Let's see how they can turn your "spaghetti" into a Michelin-star codebase.

1. Creational Patterns: The Art of "Crafting" Objects Without Getting "Sticky"

The Creational group focuses on one fundamental question: How can we instantiate objects in the smartest way possible?

In standard coding, we often over-rely on the new keyword. But new-ing everything, everywhere, leads to "tight coupling." Imagine you're building a logging system, and you’ve sprinkled new FileLogger() across hundreds of files. One day, your lead says, "Hey, we’re moving to the cloud; use CloudLogger instead." Now you're stuck manually editing every single file. That's a one-way ticket to "Burnout City."

Core Characteristics:

Abstractions of the Instantiation Process: They hide how objects are created, who creates them, and when.
Flexibility: You can swap the type of object being created at run-time without touching the code that actually uses those objects.

Quick Classification:

Scope	Implementation	Purpose
Class-scope	Uses Inheritance	Defers the choice of which class to instantiate to subclasses.
Object-scope	Uses Delegation	Hand over the instantiation task to a specialized object (like a Factory or Builder).

💡 Pro-Tip: Don't let instantiation logic leak all over your codebase. Centralize it (using a Factory) so that when the "main character" changes, you only have to update a single file.

2. Structural Patterns: Assembling Components Like Tech Lego

If Creational patterns handle "casting" the parts, Structural patterns handle how to snap them together to form larger, more complex structures without messing with the original parts' DNA.

Have you ever had an ancient Interface from the "dinosaur era" that you wanted to use with a shiny, modern library? Instead of rewriting the entire library (good luck with that), you use the Adapter Pattern—the software equivalent of a travel power plug.

Core Characteristics:

Seamless Integration: Allows classes/objects to work together even if they have incompatible interfaces.
Minimizing Bloat: Instead of creating massive "God Classes" that do everything, Structural patterns help you break features into small components and assemble them on demand.

Class vs. Object Structural Patterns:

Class Structural: Uses multiple inheritance (or interface inheritance) to merge features. This is rigid because it's set in stone at compile-time.
Object Structural: This is where the magic happens. It uses composition (wrapping objects). You can literally change your system's structure while the program is running. Peak flexibility.

JavaScript

`// Example: Decorator Pattern - Adding "toppings" to an object
class Coffee {
cost() { return 10; }
}

class MilkDecorator {
constructor(coffee) { this.coffee = coffee; }
cost() { return this.coffee.cost() + 5; }
}

// You can add milk to your coffee whenever you want at runtime!
let myCoffee = new Coffee();
myCoffee = new MilkDecorator(myCoffee);
console.log(myCoffee.cost()); // 15`

3. Behavioral Patterns: Teaching Objects to "Communicate" Civilly

Finally, we have Behavioral patterns. This group doesn't care how you create objects or how they are structured; it only cares about how they interact and distribute responsibilities.

Have you ever seen a nested if-else block a mile long just to handle different states of an order? If so, you owe yourself the State Pattern. Behavioral patterns transform complex control flows into organized interactions between objects.

Core Characteristics:

Responsibility Assignment: Ensures no single object is doing too much (staying true to the Single Responsibility Principle).
Communication Flow Management: Allows objects to exchange data without needing to know too much about each other (Loose Coupling).

Two Main Approaches:

Class-based: Uses inheritance to vary algorithms (like the Template Method).
Object-based: Uses a group of "peer objects" to collaborate on a massive task that no single object could handle alone. Observer Pattern is the classic example here—when the "boss" changes, the "subscribers" get notified and update themselves automatically.

The "Lightning Fast" Cheat Sheet

Criteria	Creational	Structural	Behavioral
Main Goal	Object Creation	Object Assembly	Object Interaction
Keywords	"Cast", "Build", "Factory"	"Lego", "Adapter", "Wrapper"	"Messaging", "Responsibility", "Events"
Solves...	Overuse of `new`	Bloated classes	Messy `if-else` & tangled logic
Classic Examples	Singleton, Factory Method	Adapter, Proxy, Facade	Observer, Strategy, State

Conclusion: When Should You Use What?

A word of caution: Don't force Design Patterns into your code just to look "fancy." That leads to Over-engineering, which is a different kind of nightmare.

If creating objects is becoming a headache -> Look at Creational.
If your classes are hard to combine or the system feels "stiff" -> Look at Structural.
If your objects are calling each other in circles or your logic is buried in if-else hell -> Look at Behavioral.

The journey to becoming a Senior Developer isn't just about making code run; it's about organizing it so that when you look at it a year from now, you actually understand what you wrote (and your coworkers don't want to chase you with a pitchfork).

Happy coding, and may your code always stay Clean!

TL;DR (Key Takeaways):

Creational: Focuses on how objects are born; keeps your "supply chain" flexible.
Structural: Focuses on how objects are connected; keeps your architecture modular.
Behavioral: Focuses on how objects talk to each other; kills messy logic and spaghetti flows.
Golden Rule: Patterns are tools, not the goal. Use them where they make sense!