DEV Community: Soumyaranjan Palatasingh

Day 19: AWS Database — Relational (RDS and DMS)

Soumyaranjan Palatasingh — Thu, 20 Aug 2026 10:05:12 +0000

Days 17-18 covered storage. Today we shift into databases, starting with the relational side — RDS, which most applications lean on for their primary database, and DMS, the service that gets data into it in the first place.

Amazon RDS (Relational Database Service)

RDS is a service where you can set up, configure, maintain, and secure RDBMS (relational) databases — but here's the important distinction: RDS is not a database, it's a database *service*. You don't install MySQL or PostgreSQL yourself; you tell RDS which database engine you want, and it provisions, patches, backs up, and manages the underlying infrastructure for you.

RDS supports 7 database engines, and it's worth knowing all of them: MySQL and PostgreSQL (both open-source), MariaDB (community-driven, MySQL-compatible), Oracle and Microsoft SQL Server (commercial, licensed engines), IBM DB2, and Aurora — which is AWS's own proprietary engine, built to be compatible with MySQL and PostgreSQL but re-engineered for better performance and availability on AWS infrastructure specifically.

What "fully managed" actually means here: you connect to an RDS database instance only through client tools — a MySQL client, a PostgreSQL client, whatever fits your engine — over the standard database port. You can't RDP or SSH into the underlying instance the way you can with a self-managed database on EC2, because the platform itself is managed by AWS. That's the trade-off: you give up direct OS-level access in exchange for AWS handling patching, backups, and infrastructure maintenance for you.

A few things worth knowing beyond the basics, since these come up constantly in real deployments:

Multi-AZ deployments give you high availability by maintaining a synchronous standby replica of your database in a different Availability Zone. If the primary fails, RDS automatically fails over to the standby — this is the database-layer equivalent of the failover concept we covered back on Day 13, just applied to a stateful database instead of a stateless web server.
Read Replicas are a separate concept from Multi-AZ, aimed at scaling read traffic rather than availability. You can create one or more read-only copies of your database, and route read-heavy traffic (reports, analytics queries) to them instead of hammering your primary instance. Aurora specifically supports up to 15 read replicas, far more than the standard engines.
Automated backups and snapshots — RDS can automatically take daily backups and retain transaction logs, letting you restore to any point within your retention window. You can also take manual snapshots on demand before a risky change.
Storage autoscaling lets RDS increase your storage automatically as your data grows, instead of you having to manually resize it (similar in spirit to the EBS scaling we covered on Day 17, but handled at the database layer).
Parameter groups and option groups let you configure database engine settings (like memory allocation or logging behavior) without needing shell access to the underlying instance — the AWS-managed way of tuning a database you can't directly log into.
Aurora specifically deserves a mention on its own: it auto-scales storage up to 128TB, separates compute and storage for faster failover, and even offers an Aurora Serverless option that scales capacity automatically based on load rather than requiring you to pick a fixed instance size upfront.

AWS DMS (Database Migration Service)

DMS exists for one specific purpose: migrating databases into (or between) AWS, with minimal downtime. It's what you'd reach for when moving an on-premises database to RDS, or migrating between two different database engines entirely.

The mechanics involve three pieces: a source endpoint (your existing database — on-premises, EC2, another cloud, or another AWS database), a target endpoint (typically an RDS instance, though it doesn't have to be), and a replication instance — the actual compute DMS uses to read from the source and write to the target.

Two kinds of migration are worth distinguishing. A homogeneous migration moves data between the same database engine — MySQL to MySQL, for example — which is comparatively simple since the schema and data types line up directly. A heterogeneous migration moves data between different engines entirely — say, Oracle to Aurora PostgreSQL — which requires converting the schema itself, not just copying data. For that, AWS provides the Schema Conversion Tool (SCT), which translates schema objects, stored procedures, and functions from the source engine's dialect into the target engine's equivalent before DMS handles the actual data movement.

One more detail that matters a lot in practice: DMS supports continuous data replication (CDC — Change Data Capture), not just a one-time copy. This means you can keep your source database live and serving production traffic while DMS continuously replicates ongoing changes to the target, and only cut over once the target is fully caught up — minimizing downtime during the actual switch, rather than requiring a long maintenance window to migrate everything at once.

How they work together

A typical migration flow: your existing database (on-premises or elsewhere) becomes the DMS source endpoint, a DMS replication instance continuously copies data — and if needed, the Schema Conversion Tool translates the schema first — into a target RDS instance, and once replication has caught up, you cut your application over to the new RDS database with minimal downtime.

Quick Recap Questions

Why is it accurate to say "RDS is not a database, it's a database service"?
What's the difference between Multi-AZ and Read Replicas — what problem does each actually solve?
What's the difference between a homogeneous and a heterogeneous migration, and why does the second one need the Schema Conversion Tool?
Why would continuous replication (CDC) matter more than a one-time data copy for a production migration?

Where to read & follow

Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/

Coming up next

Day	Topic	Services
20	Database — NoSQL, Warehouse & Cache	DynamoDB, Redshift, ElastiCache

aws #devops #cloudcomputing #learning

Day 18: AWS Storage — Extended (EFS, Snow Family, Glacier, Storage Gateway)

Soumyaranjan Palatasingh — Wed, 19 Aug 2026 10:46:11 +0000

Day 17 covered S3 and EBS — object storage and block storage for a single instance. Today we round out storage with four services that each solve a specific gap those two leave open: sharing storage across instances, moving huge volumes of data physically, archiving cheaply, and bridging on-premises storage with the cloud.

Amazon EFS (Elastic File System)

EBS has one hard limitation: a volume attaches to only one EC2 instance at a time. If you need multiple instances to read and write the same shared storage — a common web content directory, shared application state — EBS simply can't do it. That's exactly the gap EFS fills.

EFS is a shared file system that multiple EC2 instances can mount and access simultaneously, even across different Availability Zones. It works on the NFS (Network File System) protocol — the same standard on-premises teams have used for decades to share a file system across multiple laptops or servers from one central store. In AWS, EFS effectively replaces that on-premises file server, fully managed by AWS.

A few defining characteristics: EFS is file-based storage, unlike EBS's block-based model or S3's object-based model. It's only for Linux EC2 instances — Windows instances use a separate service (FSx) instead. It offers unlimited storage and, unlike EBS, requires no pre-provisioning — it automatically grows or shrinks based on the data you actually put in it, so you're not guessing a size upfront. To use it, you mount EFS to a directory inside each EC2 instance, the same way you'd mount any file system. EFS is Regional, but can be replicated to other Regions if you need that.

Worth knowing beyond the basics: EFS offers two storage classes — Standard, for actively accessed files, and Infrequent Access (EFS-IA), which costs less for files you don't touch often, with Lifecycle Management able to move files between them automatically based on actual access patterns. There are also two throughput modes: Bursting (throughput scales with the amount of data stored, suitable for most workloads) and Provisioned (you set a fixed throughput independent of storage size, useful for latency-sensitive or bursty workloads that don't have much data stored yet). And if you're on Windows and need something similar, Amazon FSx is the equivalent family of managed file systems — FSx for Windows File Server for SMB-based Windows workloads, and FSx for Lustre for high-performance computing workloads that need very fast, parallel file access.

AWS Snow Family — Physical data transfer

Sometimes the amount of data you need to move between on-premises and AWS is simply too large to transfer efficiently over a network connection — even a fast one. Moving petabytes of data over the internet could take weeks or months. The Snow Family solves this with physical data transfer: AWS ships you a rugged, secure storage device, you load your data onto it locally, and ship it back to AWS, who then uploads it directly into S3 on their end (or, in reverse, loads AWS data onto the device and ships it to you).

Three devices, scaled for different volumes:

Snowcone — up to 8TB, small and portable, can even be used as an edge compute device in the field
Snowball Edge — up to 100TB, the workhorse of the family for large migrations
Snowmobile — literally a shipping container on a truck, moving petabytes of data — used for truly massive migrations, like an entire data center's worth of storage

All three devices are encrypted (256-bit) during transit for security, and they're used for both directions: migrating existing data into AWS, and in some cases, exporting data out of AWS back to a physical device.

Amazon S3 Glacier

Glacier is S3's archival counterpart — built specifically for data you need to retain but rarely, if ever, access: compliance records, old backups, historical logs. It's significantly cheaper than S3 Standard, in exchange for slower retrieval times.

The structure mirrors S3's bucket/object model but with different terminology: a vault is a container for archives (think of it like a bucket, but for archived data, often literally zip files), and an archive is the actual stored data — a single archive can be up to 40TB, and you can store an unlimited number of them. You can create up to 1,000 vaults per account.

Retrieval isn't instant, which is the trade-off for the lower cost, and Glacier actually offers a few retrieval speed tiers: Expedited (minutes, at a premium cost), Standard (a few hours), and Bulk (up to half a day or more, the cheapest option for retrieving large amounts of archived data at once). There's also Glacier Deep Archive, an even cheaper tier for data you essentially never expect to touch, with retrieval times measured in hours rather than minutes.

AWS Storage Gateway

Storage Gateway is AWS's answer to a very specific hybrid problem: what if you want to keep using local, on-premises storage for day-to-day work, but back it with the cloud instead of (or alongside) physical infrastructure? It's a hybrid storage service — a virtual appliance you run on-premises that connects your local environment to AWS storage services (S3, EBS, Glacier) behind the scenes.

Instead of company laptops writing directly to local private storage with no cloud tie-in, Storage Gateway sits between them and AWS: you get a local cache for low-latency access to frequently used data, while the bulk of your data actually lives durably in the cloud. It comes in a few flavors depending on what you're replacing: File Gateway presents cloud storage as a standard file share (backed by S3), Volume Gateway presents it as iSCSI block storage volumes (backed by EBS/S3, in either cached or fully-stored modes), and Tape Gateway presents it as a virtual tape library for organizations still running tape-based backup software, quietly backing those "tapes" with S3 and Glacier instead of physical tape.

Which one do you actually reach for?

Service	Solves	Typical Use
EFS	Shared file access across instances	Shared web content, shared app state, Linux-only
Snow Family	Moving huge data volumes physically	Data center migrations, offline/edge locations with poor connectivity
Glacier	Cheap long-term archival	Compliance records, old backups, rarely-accessed logs
Storage Gateway	Bridging on-prem storage with the cloud	Hybrid environments not ready to fully move to the cloud

Quick Recap Questions

Why can't EBS handle a scenario where 5 EC2 instances all need to read and write the same shared files?
Why would a company ship a physical Snowball device instead of just transferring data over the internet?
What's the trade-off Glacier makes to be cheaper than S3 Standard?
What problem does Storage Gateway solve that pure cloud storage doesn't?

Where to read & follow

Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/

Coming up next

Day	Topic	Services
19	Database — Relational	RDS, DMS

aws #devops #cloudcomputing #learning

Day 17: AWS Storage Core — S3 and EBS

Soumyaranjan Palatasingh — Tue, 18 Aug 2026 12:32:56 +0000

Day 17: AWS Storage Core — S3 and EBS

Days 15-16 covered networking. Today we move into storage — starting with the two foundational storage services almost everything else builds on: S3 and EBS. They solve fundamentally different problems, and knowing which one fits which use case is one of the most practical things to get right early.

Amazon S3 (Simple Storage Service)

S3 is used to store files — and in AWS, a consistent naming pattern shows up across a lot of services: it starts with "Simple" and ends with "Service" (Simple Notification Service, Simple Email Service, Simple Queue Service all follow the same pattern). S3 can store any kind of flat file, and with it you can upload, download, and access files — but you can't execute anything inside S3. You can't install an OS, run a database, or run executables there. S3 is serverless, much like Google Drive — there's no server for you to manage, patch, or scale; AWS handles high availability, performance, and scalability for it entirely.

The structure maps cleanly to a familiar mental model: a bucket is a container of objects — think of it like a folder. An object is a file. And the key is the object's name — including its full path, like docs/report.pdf. Buckets are Regional, meaning a bucket created in Mumbai lives in Mumbai, and bucket names have to be globally unique across all of AWS, not just your account.

S3 is object-based storage — this is the key distinction from EBS, which is block-based. You're storing and retrieving whole files by key, not managing raw disk blocks.

Static website hosting is a genuinely common real-world use of S3: if you have a static website — meaning no server-side processing, just HTML/CSS/JS files — S3 supports hosting it directly. Create a bucket, upload your HTML files, enable static website hosting, and you're done. No need to worry about HA, performance, or scalability, because S3 handles all of that for you the same way it does for any other object stored there.

A few things worth knowing beyond the fundamentals:

Storage classes let you trade off cost against retrieval speed and availability. S3 Standard is for frequently accessed data; S3 Standard-IA (Infrequent Access) is cheaper for data you don't touch often but still need quickly when you do; S3 Intelligent-Tiering automatically moves objects between tiers based on actual access patterns, which is useful when you don't know your access pattern in advance. (Glacier, for archival, gets its own dedicated post shortly.)
Versioning keeps multiple versions of an object in the same bucket, so an accidental overwrite or delete isn't permanent — you can always roll back to a previous version.
Lifecycle policies automate moving objects between storage classes, or deleting them entirely, based on age — for example, automatically shifting logs to a cheaper tier after 30 days and deleting them after a year.
Encryption is available both server-side (S3 manages the keys, or you use KMS-managed keys for more control) and via HTTPS in transit.
Bucket policies and IAM policies both control access to S3, but at different levels — a bucket policy is attached directly to the bucket and can grant or deny access to anyone (including other accounts), while an IAM policy is attached to a user or role and defines what that identity can do.
Presigned URLs let you grant temporary, time-limited access to a private object without making the whole bucket public — useful for things like letting a user download a file they paid for.
Large uploads use multipart upload, splitting a big file into parts that upload in parallel and get reassembled — much more resilient than uploading a huge file in one shot.

Amazon EBS (Elastic Block Storage)

Where S3 stores files as objects, EBS gives you raw block storage — the AWS equivalent of a hard disk. In fact, the simplest way to think about it: hard disk = volume = EBS volume.

When you launch an EC2 instance, it automatically gets a default volume called the root volume, which contains the operating system. Windows instances get a 30GB root volume by default; Linux instances get 8-10GB. An EC2 instance can only ever have one root volume, but you can attach multiple additional volumes to it for extra storage.

Creating and managing volumes follows a specific lifecycle: if you want a volume, you create it and then attach it to an instance; if you want to remove it, you detach it first and then delete it — you can't delete a volume while it's still attached. Volumes need to be pre-provisioned — you decide the size upfront (say 50GB or 100GB), up to a maximum of 16TB per volume.

A detail that trips a lot of people up: volume size can be increased on the fly, with zero downtime and no need to stop the instance — but it can never be decreased. If you over-provisioned and want a smaller volume, your only option is to create a new, smaller one and migrate the data over, then delete the old one.

Availability Zone matters a lot here. Both an EC2 instance and its volumes live in a specific Availability Zone, and a volume can only attach to an instance in the same AZ — you can't attach a volume from AZ 1a to an instance running in AZ 1b. One volume also can't be shared across multiple instances at the same time; it's a one-to-one relationship (this is different from EFS, which we'll cover in an upcoming post, and which is specifically built for sharing storage across instances).

Device naming conventions: the root volume is typically mounted as /dev/sda1 (or /dev/xvda on some instance types), while additional volumes get names like /dev/sdb, /dev/sdf, /dev/sdg, and so on.

Can you detach the root volume while the instance is running? No — because it holds the operating system the instance is actively running on. You'd need to stop the instance first, then detach it (though this is rarely something you'd actually want to do). Additional volumes, on the other hand, can technically be detached while the instance is running, though it's not generally recommended without properly unmounting the filesystem first to avoid data corruption.

A couple of things worth knowing beyond the class notes:

EBS offers different volume types for different performance needs: gp3/gp2 are general-purpose SSD (the default choice for most workloads), io1/io2 are provisioned-IOPS SSD for high-performance, latency-sensitive workloads like large databases, and st1/sc1 are lower-cost HDD options for throughput-heavy or infrequently accessed workloads.
Snapshots are point-in-time, incremental backups of a volume, stored in S3 behind the scenes. Only the changed blocks since the last snapshot are actually saved, which keeps them fast and cost-efficient — and you can create a new volume from a snapshot at any time, including in a different Availability Zone.

S3 vs EBS — the core distinction

	S3	EBS
Storage type	Object-based	Block-based
Attached to	Nothing — accessed independently	A specific EC2 instance
Scope	Regional, accessible from anywhere	Regional, tied to one AZ
Can be shared across instances?	Yes, inherently	No, one-to-one only
Typical use	Files, static assets, backups, website hosting	The "hard disk" behind a running instance

Quick Recap Questions

What's the actual difference between object-based storage and block-based storage?
Why can't you attach an EBS volume to an instance in a different Availability Zone?
Can you decrease an EBS volume's size? What's your only real option if you over-provisioned?
What is a bucket, an object, and a key, in S3 terms?
Why can't a single EBS volume be shared across multiple EC2 instances the way an S3 bucket effectively can be accessed by many things at once?

Where to read & follow

Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/

Coming up next

Day	Topic	Services
18	Storage — Extended	EFS, Snow Family, Glacier, Storage Gateway

aws #devops #cloudcomputing #learning

Day 16: AWS Networking — Connectivity & Delivery

Soumyaranjan Palatasingh — Mon, 17 Aug 2026 03:55:17 +0000

Day 16: AWS Networking — Connectivity & Delivery

Day 15 covered VPC and Route 53 — how your infrastructure is structured and how a domain name resolves to it. Today we cover the two services that decide how traffic actually travels between your users, your company, and AWS: Direct Connect and CloudFront.

AWS Direct Connect

By default, your company reaches AWS the same way everyone else does — over the public internet, usually through a VPN for anything sensitive. Direct Connect replaces that with a dedicated, leased-line connection straight from your premises to AWS, bypassing the public internet entirely.

Why not just use a VPN, since it already encrypts traffic? Two reasons come up constantly: consistency and cost. A VPN over the public internet is still subject to the internet's variability — congestion, unpredictable latency, and jitter that no security team can fully control, because the traffic is still hopping across a chain of ISPs you don't own. Direct Connect gives you a private, dedicated line with consistent, guaranteed bandwidth and predictable latency, which matters a lot for latency-sensitive workloads (real-time trading systems, VoIP, live data replication) or for a steady, high-volume flow of confidential data between an on-premises data center and AWS. On the cost side, transferring large volumes of data out of AWS over the public internet gets expensive at scale — Direct Connect's data transfer rates are generally lower, so heavy data-transfer workloads (nightly backups, large analytics pipelines, ongoing replication) can actually save money over time despite the connection itself not being cheap (pricing runs into the thousands of dollars per month depending on port speed, and the notes mention figures around $16,000/month for higher-capacity connections).

How the pieces fit together. A Direct Connect connection physically terminates at an AWS Direct Connect location — a facility, often run by a third-party colocation provider, where AWS has a direct presence. You typically don't wire your own cable there yourself; you go through an AWS Direct Connect Partner who already has infrastructure at that location and can provision the cross-connect for you, unless your company happens to already have equipment physically present there.

From that physical connection, you provision Virtual Interfaces (VIFs) to actually reach specific AWS resources:

A private VIF connects to resources inside a single VPC — this is what you'd use to let your on-premises data center talk to EC2 instances or an RDS database sitting in a VPC.
A public VIF reaches AWS's public services (like S3 or DynamoDB) using their public endpoints, but over the dedicated connection instead of the internet — useful when you want private connectivity to a service that doesn't live inside a VPC.
A transit VIF connects to a Transit Gateway, which is how you extend Direct Connect access to multiple VPCs at once instead of just one.

Connections use BGP (Border Gateway Protocol) to exchange routing information between your network and AWS's, so routes update automatically rather than being manually maintained.

Redundancy is a real design decision here, not an afterthought. A single Direct Connect connection is still one physical link through one location — if that link or that location has an outage, you lose connectivity entirely unless you've planned for it. Common patterns: pairing two Direct Connect connections through different locations for full redundancy, using a Link Aggregation Group (LAG) to bundle multiple connections into one logical, higher-bandwidth connection, or keeping a VPN as an automatic failover path if Direct Connect goes down. AWS explicitly recommends against treating a single Direct Connect connection as your only path to critical infrastructure.

Amazon CloudFront

CloudFront is AWS's Content Delivery Network (CDN) — a service that caches your content at locations physically close to your users, so they're not making every request all the way back to your origin server.

The problem it solves, concretely: say your application runs in Mumbai, but you have users in Tokyo, Ireland, Sydney, and Canada. Without CloudFront, every one of those users' requests travels all the way to Mumbai and back — that round trip is where most of the perceived slowness in a global application actually comes from, often more than anything happening on your server itself. You could deploy your application in every region your users are in, but that's expensive, operationally heavy, and creates data-consistency headaches across regions. CloudFront's answer is to cache your content at edge locations — AWS-managed points of presence spread globally, numbering in the hundreds — so a user in Tokyo gets served from a nearby edge location instead of round-tripping to Mumbai.

How a distribution actually works. You create a distribution in CloudFront, pointing it at an origin — the actual source of your content, which could be an S3 bucket (for static assets), an Application Load Balancer (for dynamic content), or basically any HTTP/HTTPS endpoint, even one outside AWS entirely. From then on, requests hit the nearest edge location first: if that edge already has the requested content cached, it serves it directly (a "cache hit") — no trip back to the origin at all. If not (a "cache miss"), it fetches the content from the origin once, caches it at that edge, and serves subsequent nearby requests from the cache until it expires.

A single distribution can also define multiple cache behaviors — rules based on the URL path pattern. You might cache /images/* aggressively for a long time since images rarely change, while routing /api/* straight to the origin with no caching at all since API responses need to be fresh every time. This is how a single CloudFront distribution can sit in front of both a static frontend and a dynamic backend.

TTL (Time to Live) controls how long content stays cached at an edge location before CloudFront checks the origin again for a fresh copy. If you update your content before the TTL expires, users will keep seeing the old cached version until it does — unless you explicitly invalidate the cache, which forces CloudFront to drop the cached copy at every edge and fetch fresh content on the next request. This is one of the most common gotchas in real deployments: shipping a fix to your origin doesn't mean users see it immediately if a stale copy is already sitting at the edge nearest them, and teams that forget this step spend a confusing amount of time debugging "it's fixed on the server but not in the browser."

Security and access control features worth knowing:

Signed URLs and signed cookies let you serve private content — a paid video, a licensed document — without making your entire origin publicly accessible. Access is granted per-URL or per-session rather than to the whole bucket.
Origin Access Control (OAC) locks down an S3 origin so it can only be reached through CloudFront, not accessed directly via its raw S3 URL. This is the standard, current best practice for keeping an S3-backed website or asset bucket from being bypassed entirely.
CloudFront integrates directly with ACM (AWS Certificate Manager) to serve your content over HTTPS with a free, auto-renewing certificate, and with AWS WAF to filter malicious requests (SQL injection attempts, bot traffic) before they ever reach your origin.
Price classes let you control which edge locations your distribution actually uses — you can restrict delivery to a cheaper subset of regions if you don't have users everywhere and want to control cost.

CloudFront is a global service, same as Route 53 — a distribution isn't tied to one Region, since its entire purpose is serving content from wherever the user happens to be.

How they're different

Direct Connect and CloudFront solve opposite-feeling problems that are actually related: Direct Connect is about your company reaching AWS privately and consistently for internal, often confidential traffic. CloudFront is about your users reaching your public-facing content quickly, wherever in the world they happen to be. One tightens a single path between you and AWS; the other widens the number of places your content can be served from.

Quick Recap Questions

Why would a company choose Direct Connect over a VPN if a VPN already encrypts traffic?
What's the difference between a private VIF, a public VIF, and a transit VIF?
What's a Link Aggregation Group, and why would you use one with Direct Connect?
If you update content at your origin, why might users still see the old version — and what fixes it?
What does Origin Access Control actually prevent?

Where to read & follow

Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/

Coming up next

Day	Topic	Services
17	Storage Core	S3, EBS

aws #devops #cloudcomputing #learning

Day 15: AWS Networking Basics — VPC and Route 53

Soumyaranjan Palatasingh — Sun, 16 Aug 2026 03:35:44 +0000

(Days 13-14) covered compute, from raw EC2 up through Beanstalk, Lightsail, Lambda, and EventBridge. Today we move into networking — starting with the two services that sit underneath almost everything else you'll deploy: VPC and Route 53.

Amazon VPC (Virtual Private Cloud)

Whatever you launch in EC2 — instances, load balancers, databases — it lives inside a VPC. It's the network boundary for your entire AWS infrastructure in a Region, isolating your resources from every other AWS customer's.

AWS gives every Region a default VPC you can use right away, or you can create your own. Each Region can contain a maximum of 5 VPCs, and VPCs are Regional — a VPC in Mumbai is a completely separate, unrelated thing from a VPC in Ireland, even within the same account. By default, two VPCs cannot communicate with each other at all. If you need that — say, two teams' environments that occasionally need to talk — you have to explicitly set it up.

CIDR blocks and IP addressing. A VPC is defined by a CIDR block — a range of IP addresses written like 10.0.0.0/16. The /16 tells you how many addresses are in that range (a /16 gives you roughly 65,000 addresses); a smaller number after the slash means a bigger range. AWS reserves 5 IP addresses in every subnet for internal use (network address, VPC router, DNS, future use, and broadcast), so your usable address count is always a bit less than the raw math suggests. Picking a CIDR range that doesn't overlap with your on-premises network or other VPCs matters a lot if you ever plan to connect them together — overlapping ranges are one of the most common real-world networking headaches.

Subnets. Within a VPC, you carve out subnets — smaller IP ranges, each tied to exactly one Availability Zone. Subnets typically come in two flavors:

Public subnets have a route to the internet through an Internet Gateway. This is usually where your load balancer or any internet-facing resource sits.
Private subnets have no direct internet route. Databases, internal application servers, and anything that shouldn't be reachable from outside sit here.

A well-architected VPC usually spreads public and private subnets across multiple Availability Zones — the same high-availability principle from Day 13, applied at the network layer.

Gateways. An Internet Gateway is what actually connects a VPC to the internet. Attach one to your VPC, add a route to it in your route table, and resources in public subnets can reach — and be reached from — the outside world. For private subnets that still need outbound internet access (downloading OS patches, calling an external API) without being directly reachable from outside, you use a NAT Gateway instead — traffic flows out through it, but nothing can initiate a new connection back in through it.

Route tables are the actual traffic-direction rules: which subnet's traffic goes to the Internet Gateway, which goes to the NAT Gateway, which stays entirely internal. Every subnet is associated with exactly one route table (though one route table can be shared across multiple subnets).

Security at two layers. Security groups (which we touched on with EC2) are stateful firewalls attached at the instance level — if you allow inbound traffic on a port, the response traffic is automatically allowed out. Network ACLs (NACLs) sit at the subnet level instead, are stateless (you have to explicitly allow both inbound and outbound), and are evaluated in rule-number order. In practice, most day-to-day security is handled with security groups; NACLs are more of a coarse, subnet-wide backstop.

VPC Peering creates a private, direct network connection between two VPCs that genuinely need to talk to each other — this is the "if required, yes" answer to the two-VPCs-communicating question. It's not transitive, though: if VPC A peers with B, and B peers with C, A still can't reach C without its own direct peering connection.

Amazon Route 53

Route 53 is AWS's DNS (Domain Name System) service — the name comes from DNS running on port 53. Unlike VPC, it's a global service, not tied to any Region.

At its core, Route 53 handles the mapping between a human-readable domain (like boom.com) and the actual AWS resource behind it — an ELB, a CloudFront distribution, an S3 bucket, and so on. You create records inside Route 53 to define that mapping. This is where the "translation" from a URL to an actual endpoint happens, and it's typically the very first hop when a user's request reaches your infrastructure.

Hosted zones. Records live inside a hosted zone — a container for all the DNS records belonging to one domain. A public hosted zone routes traffic on the internet; a private hosted zone routes traffic only within one or more VPCs, useful for internal-only services that shouldn't be resolvable publicly.

Record types worth knowing, beyond just "a record maps a name to an address":

A record — maps a domain to an IPv4 address
CNAME record — maps a domain to another domain name (an alias)
Alias record — an AWS-specific enhancement of a CNAME-like mapping that works even at the root domain, and lets you point directly at an AWS resource (like an ELB's DNS name) instead of a static IP — this matters because AWS resource IPs can change, and an Alias record automatically stays current
MX record — routes email for the domain
TXT record — arbitrary text, commonly used for domain verification (proving you own a domain to a third-party service)

Routing policies go well beyond simple one-to-one mapping:

Simple routing — one record, one resource; the default
Weighted routing — split traffic by percentage across multiple resources, useful for gradual rollouts or A/B testing
Latency-based routing — send users to whichever Region responds fastest for them
Failover routing — automatically route to a backup resource if the primary is unhealthy
Geolocation routing — route based on the user's physical location, useful for serving region-specific content or complying with data residency rules
Geoproximity routing — similar, but lets you shift traffic between resources by adjusting a "bias" value, without needing exact geographic boundaries

Route 53 also runs its own health checks — separate from the ELB-level health checks we covered on Day 13 — which continuously monitor an endpoint and can automatically pull it out of rotation for failover routing if it stops responding.

How it fits together

A typical request flow looks like this: a user types boom.com → Route 53 resolves that to your Elastic Load Balancer's DNS name (often via an Alias record) → the ELB distributes the request across EC2 instances sitting in your VPC's public subnets. Route 53 answers "where do I send this," and the VPC's structure — subnets, gateways, route tables — answers "how does traffic actually get there once it arrives."

Quick Recap Questions

Why can't two VPCs communicate with each other by default, and how do you fix that if you need it?
What's the difference between a public and a private subnet, and which one typically holds a database?
What's the practical difference between a Security Group and a Network ACL?
Why would you use an Alias record instead of a plain CNAME for pointing at an ELB?
Which Route 53 routing policy would you use to send users to the fastest-responding Region?

Where to read & follow

Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/

Coming up next

Day	Topic	Services
16	Networking — Connectivity & Delivery	Direct Connect, CloudFront/CDN

aws #devops #cloudcomputing #learning

Day 14: AWS Compute — Managed & Serverless

Soumyaranjan Palatasingh — Sat, 15 Aug 2026 04:20:39 +0000

We started the compute layer on Day 13 with EC2, ELB, and Auto Scaling — where you launch and manage everything yourself. Today we move one level up the abstraction ladder: services where AWS takes over more of the operational burden. By the end of this post you'll know what each one does, how it differs from plain EC2, and when to actually reach for it.

AWS Elastic Beanstalk

Elastic Beanstalk is a Platform-as-a-Service (PaaS) offering built on top of EC2. You upload your application code and a bit of configuration; Beanstalk provisions the EC2 instances, load balancer, and Auto Scaling Group for you.

The IaaS/PaaS/SaaS framing from Day 13 explains why this exists: with EC2 you cook the meal yourself, with Beanstalk you eat at a restaurant — someone else runs the kitchen. In practice, that means you pick a platform (Tomcat for Java, .NET, Python, Docker, Go, and so on), upload your application, and Beanstalk launches and manages the EC2 instances behind the scenes, handing you back a URL.

One nuance worth calling out: in general, PaaS means you have zero control over the underlying servers. Beanstalk is a bit more generous than that — you still have full access to the EC2 instances it creates, you can SSH in and tweak things, Beanstalk just manages the lifecycle for you instead of you doing it manually.

Reach for Beanstalk when you want to ship an app fast without building out your own CI/CD-to-EC2 pipeline, but you're not ready to go fully serverless. It's a strong middle ground for small-to-mid teams. Where it gets awkward is long-term: because it abstracts the infrastructure, teams that eventually need fine-grained control — custom networking, non-standard scaling logic — often end up moving out of Beanstalk into raw EC2 with their own CI/CD later. Treat it as a fast on-ramp, not necessarily a forever-home for a growing production system.

Amazon Lightsail

Lightsail is a simplified virtual private server (VPS) service. You spin up an instance that comes pre-installed with common stacks — WordPress, GitLab, Node.js, Joomla, Drupal, Redmine, Nginx, cPanel, and more.

It doesn't support Auto Scaling, and it's built for small businesses and non-technical users who just want a working server without navigating EC2, VPC, security groups, and everything else that comes with raw EC2. Pricing is also flat and predictable, unlike EC2's more granular pay-as-you-go model.

Think of Lightsail as EC2 with the training wheels on. If a client just needs a WordPress blog or a small internal tool and will never need to scale past one or two servers, Lightsail is genuinely the right call — it's cheaper to reason about and harder to misconfigure. The moment scaling, high availability, or custom networking enters the conversation, that's the signal to migrate to EC2 + ELB + Auto Scaling instead.

AWS Lambda

Lambda is a serverless compute service. You write a function — a set of instructions — and Lambda runs it in response to a trigger, with no server to provision, patch, or manage. It supports Java, Python, Ruby, Node.js, and more, and you're charged for actual execution time and requests, not for idle capacity, since there's no persistent server sitting around.

A classic automation example: automatically stopping all EC2 instances at 11 PM and starting them again at 9 AM to save cost outside business hours — no cron job on a server needed, Lambda just runs on schedule.

A couple of details worth knowing beyond the basics. Cold starts happen on the first invocation after a period of inactivity, since AWS has to spin up the execution environment — worth factoring in if you're building latency-sensitive APIs. And Lambda functions can run for a maximum of 15 minutes per invocation — it's built for short, event-driven tasks, not long-running processes. Common real-world uses include resizing images on upload to S3, lightweight API backends (often paired with API Gateway), glue logic between AWS services, and scheduled housekeeping tasks like the EC2 start/stop example above.

Amazon EventBridge

EventBridge is a serverless event bus. It captures events happening across your AWS environment — and even from SaaS apps — and routes them to targets, most commonly Lambda functions, based on rules you define.

Tying it back to the Lambda example: you define a rule in EventBridge (say, "every day at 11 PM"). When that rule triggers, EventBridge invokes a target — a Lambda function written in Python, for instance — and that function executes its logic, in our case stopping EC2 instances.

It's easy to conflate EventBridge with SNS since both deal with "something happened, now do something." The distinction: SNS is primarily a pub/sub messaging service for pushing notifications to subscribers (email, SMS, other services), while EventBridge is built specifically around rules matching event patterns and routing them to targets — including third-party SaaS event sources, not just internal AWS activity. If you're building event-driven automation within AWS, EventBridge is usually the right tool; if you just need to fan out a notification, SNS is simpler.

Which one do you actually reach for?

Service	Control Level	Best For
Elastic Beanstalk	Managed infra, full app control	Fast deployment without building your own pipeline
Lightsail	Minimal control, pre-built stacks	Small business sites, simple non-technical use cases
Lambda	No servers at all	Short, event-driven tasks and automation
EventBridge	No servers at all	Routing events to the right target based on rules

Quick Recap Questions

What's the key difference between EC2 and Elastic Beanstalk in terms of who manages the underlying servers?
Why doesn't Lightsail support Auto Scaling, and what does that tell you about its target audience?
In the EC2 stop/start automation example, what role does EventBridge play versus what role does Lambda play?
What's the maximum execution time for a single Lambda invocation?

Where to read & follow

Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/

Coming up next

Day	Topic	Services
15	Networking Basics	VPC, Route 53

aws #devops #cloudcomputing #learning

Day 13: AWS Compute Core — EC2, ELB, and Auto Scaling

Soumyaranjan Palatasingh — Fri, 14 Aug 2026 09:05:59 +0000

We are beginning where most people start their AWS journey — the raw compute layer: EC2, Elastic Load Balancer, and Auto Scaling.

1. Amazon EC2 (Elastic Compute Cloud) — Your virtual server

EC2 lets you create virtual machines in the cloud, called instances. It's the AWS service where you launch and fully control servers yourself.

IaaS vs PaaS vs SaaS — the model that explains why EC2 looks the way it does:

Layer	Who manages it in IaaS (EC2)	Who manages it in PaaS	Who manages it in SaaS
Application + Data	You (customer)	You (customer)	Provider
OS	You (customer)	Provider	Provider
Virtualization, Data Center, Network	Provider (AWS)	Provider	Provider

The simplest way to remember it: IaaS = you cook the biryani yourself — full control, full responsibility (EC2). PaaS = you eat at a restaurant — someone else runs the kitchen (Elastic Beanstalk). SaaS = you order on Swiggy/Zomato — everything's handled, you just consume (Gmail, Salesforce).

With EC2, you get a physical host machine → hypervisor → your VM instances. You choose the OS, install what you need, and manage patching, scaling, and availability yourself — which is exactly why the rest of this post exists.

A few building blocks are worth understanding before we get to ELB and Auto Scaling, since both depend on them. An AMI (Amazon Machine Image) is the template an instance launches from — it bundles the OS and any pre-installed software. AWS provides default AMIs (Amazon Linux, Ubuntu, Windows Server), and you can also create your own custom AMI from a configured instance so you don't have to redo setup every time. The instance type is the CPU, memory, and network combination the instance runs on — t3.micro, m5.large, and so on — and it's exactly what you change when you do vertical scaling (more on that below). A key pair is the public/private key AWS uses so you can securely SSH into a Linux instance or RDP into a Windows instance instead of relying on a password. And a security group is the virtual firewall attached to the instance, controlling exactly what traffic is allowed in and out, by port and protocol.

2. Elasticity — Handling traffic that goes up and down

The setup: a Load Balancer sits in front of a group of EC2 instances running your application (an Auto Scaling Group). As traffic increases, you need more instances; as it drops, you don't want to keep paying for idle capacity.

Elasticity = automatically increasing or decreasing the number of servers based on load. Scale out means adding instances, scale in means removing them. This is achieved in AWS through Auto Scaling, and it's considered short-term — a reaction to traffic spikes, not a permanent capacity change. Elasticity is also called horizontal scaling, since you're adding more machines rather than making one machine bigger.

3. Scalability — Making a single server bigger

Where elasticity is about the number of servers, scalability is about the size of a server. Example from class: a database server running on an 8GB RAM machine starts slowing down as data grows toward 10TB across 100 databases — the fix is bumping it up to 32GB RAM.

Scalability means scaling up (bigger instance) or scaling down (smaller instance). In AWS, this is done by changing the instance type — that CPU + memory combination from earlier. Unlike elasticity, this requires stopping the instance first. Scalability is considered long-term and is also called vertical scaling.

Elasticity vs Scalability, side by side:

	Elasticity	Scalability
Changes	Number of servers	Size of one server
Direction	Scale out / Scale in	Scale up / Scale down
Term	Short-term	Long-term
Also known as	Horizontal scaling	Vertical scaling
Downtime needed?	No	Yes (instance must be stopped)

4. High Availability — Staying up when things go wrong

High Availability (HA) is the percentage of time a service is actually available to customers. The flip side — the time it's not available — is downtime.

HA in AWS rests on three pillars. Redundancy means running the same application on multiple servers, so no single point of failure exists. Monitoring means the Load Balancer continuously runs health checks against the application itself (not the server) roughly every 30 seconds — a success response (HTTP 200) means the app is considered healthy. And failover means that if one server goes down, the Load Balancer automatically routes traffic to the remaining healthy servers.

Put together: Auto Scaling + zero downtime = fault tolerance.

5. Elastic Load Balancer (ELB) — The traffic cop

ELB is a fully managed AWS service that distributes incoming traffic across multiple EC2 instances, spread across Availability Zones.

The first thing that surprises people coming from on-premises setups: it's not a server. You can't SSH into it, patch it, or log into it at all — you access it only through a DNS name (URL) that AWS provides, not an IP you manage yourself. It's also created at the Regional level and isn't tied to a specific Availability Zone the way an EC2 instance is. On-premises, teams typically install their own web server (like Nginx or Apache) to act as a load balancer — and still have to build HA, Auto Scaling, and scalability by hand. ELB gives you all of that out of the box, managed by AWS.

AWS actually offers three types of load balancer. The Application Load Balancer (ALB) operates at Layer 7 and works with HTTP/HTTPS traffic, supporting content-based routing — you can send a request for /api to one group of servers and /images to another. The Network Load Balancer (NLB) operates at Layer 4, built for extreme performance and very low latency on TCP/UDP traffic. And the Classic Load Balancer (CLB) is the legacy option you'll mostly see in older setups. When people say "ELB" generically, they usually mean ALB today — it's the default choice for most web applications.

Two more concepts that matter once you're actually configuring one: a listener checks a specific port and protocol for incoming connection requests — for example, listening on port 443 for HTTPS. A target group is the actual set of EC2 instances (or IP addresses, or even Lambda functions) that a listener forwards traffic to. You register and deregister instances from the target group rather than pointing the ELB directly at instances, which is what makes it possible to add or remove capacity without ever touching the load balancer itself. There's also cross-zone load balancing — when enabled, traffic gets distributed evenly across every registered instance in every enabled Availability Zone, rather than staying balanced only within the AZ where it first arrived.

This is where the health checks from earlier actually live: they happen at the target group level, and a success response is what tells the ELB an instance is healthy enough to keep receiving traffic.

6. Auto Scaling

Auto Scaling is what actually delivers the elasticity concept in practice — automatically increasing or decreasing the number of EC2 instances based on load, without anyone doing it by hand.

Setting it up comes down to three pieces working together. The Launch Template defines what a brand-new instance should look like — its AMI, instance type, key pair, and security groups. Every instance the Auto Scaling Group creates is essentially a clone of this template. The Auto Scaling Group (ASG) itself defines the boundaries: the minimum, desired, and maximum number of instances, along with which Availability Zones or subnets instances are allowed to launch into. And the scaling policy is the actual rule that decides when scaling should happen.

There are a few ways to define that rule. Target tracking is the simplest — you pick a metric, say average CPU utilization, set a target like 50%, and AWS automatically adds or removes instances to hold that target. Step scaling gives you more control: you define specific thresholds and exactly how many instances to add or remove at each one. And scheduled scaling is useful when your traffic follows a predictable pattern rather than reacting to load in real time — for example, scaling up every weekday at 9 AM and back down at 11 PM.

One detail that trips people up early on: after a scale-out or scale-in event, there's usually a cooldown period — a window where the ASG deliberately won't trigger another scaling action, to avoid reacting to the same spike twice before the first batch of instances has stabilized.

Putting it together

Put an ELB in front of an Auto Scaling Group and you get the complete picture: traffic arrives at the ELB's DNS name, gets spread across the healthy instances registered in the target group, and Auto Scaling quietly adjusts capacity up or down as demand shifts — all without manual intervention, and without downtime even if an individual server fails.

Quick Recap Questions

What's the difference between elasticity and scalability, and which one requires downtime?
How does a Load Balancer know whether an application is healthy?
Why can't you SSH into an ELB the way you can into an EC2 instance?
In the biryani analogy, which service model does EC2 represent, and why?

Where to read & follow

GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/

Coming up next

Day	Topic	Services
14	Compute — Managed & Serverless	Elastic Beanstalk, Lightsail, Lambda, EventBridge

aws #devops #cloudcomputing #learning

Day 12: Creating an AWS Free Tier Account + Q&A Recap (Days 9-11)

Soumyaranjan Palatasingh — Thu, 13 Aug 2026 03:14:04 +0000

Time to get hands-on. Today: how to create an AWS Free Tier account, plus a quick Q&A recap covering everything from Days 9-11.

How to Create an AWS Free Tier Account

Go to aws.amazon.com and click "Create an AWS Account"
Enter your email address and choose an AWS account name
Verify your email with the confirmation code sent to you
Set a strong root password for your account
Enter your contact information (name, phone number, address)
Enter payment information — a valid credit/debit card is required even for free tier usage, mainly for identity verification
Complete phone number verification via SMS or call
Choose a support plan — select the Basic Support (Free) plan
Your account is created, and you're taken to the AWS Management Console

Q&A Recap — Days 9-11

Q: What is AWS?
A: A secure cloud service platform offering compute, database, storage, and other resources to help businesses scale.

Q: How many services does AWS provide?
A: 175+.

Q: What is an AWS Region?
A: A separate geographic area containing a set of Availability Zones.

Q: How many Regions does AWS currently have?
A: 34.

Q: Do Regions communicate with each other by default?
A: No — only if required/configured.

Q: What is an Availability Zone (AZ)?
A: A data center (or group of data centers) within a Region.

Q: What gives each AZ independent reliability?
A: Independent power supply, cooling system, and physical security.

Q: What are Local Zones used for?
A: Deploying workloads needing single-digit millisecond latency, closer to population centers without a full Region.

Q: What does AWS Direct Connect provide?
A: A private, dedicated network connection between AWS and your own datacenter/office.

Q: What are POP (Points of Presence) locations used for?
A: Caching content closer to end users, powering Amazon CloudFront's low-latency delivery.

Q: What is Elasticity?
A: Increasing or decreasing the number of servers based on load — short-term, achieved via Auto Scaling.

Q: What is Scalability?
A: Increasing the capacity of a single server — long-term, achieved by changing instance type.

Q: What is Elasticity also called?
A: Horizontal Scaling.

Q: What is Scalability also called?
A: Vertical Scaling.

Q: What are the three pillars of High Availability?
A: Redundancy, Monitoring, and Failover.

Q: How often does a Load Balancer perform health checks?
A: Every 30 seconds.

Q: What does AWS Elastic Beanstalk represent in terms of service model?
A: PaaS — you upload your app, and AWS handles the rest.

Q: What does EC2 represent in terms of service model?
A: IaaS — you manage most of the setup yourself.

Q: Name three AWS Compute services.
A: EC2, Auto Scaling, Lambda.

Q: Name three AWS Storage services.
A: S3, EBS, S3 Glacier.

Q: Name three AWS Database services.
A: RDS, DynamoDB, Aurora.

Q: What does AWS IAM manage?
A: Secure access to AWS services and resources.

Q: What are the three ways to access AWS resources?
A: AWS CLI, Management Console, and SDKs.

Where to read & follow

GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/

Coming up next: Introduction to AWS Services.

aws #devops #cloudcomputing #learning

Day 11: AWS Service Categories — Compute, Storage, Database, Security & How to Access AWS

Soumyaranjan Palatasingh — Wed, 12 Aug 2026 03:02:03 +0000

Wrapping up AWS fundamentals. Today: a tour of AWS's major service categories, and the three ways you can actually access and manage AWS resources.

Compute

Amazon EC2 — virtual servers in the cloud
Amazon EC2 Auto Scaling — scales compute capacity to meet demand
Elastic Load Balancer — routes traffic equally to healthy instances
AWS Elastic Beanstalk — executes and manages applications (PaaS)
AWS Lambda — executes code without servers

Storage & CDN

Amazon S3 — scalable storage in the cloud
Amazon EBS — block storage volumes for EC2
AWS Storage Gateway — hybrid storage integration
Amazon S3 Glacier — low-cost archive storage in the cloud
AWS CloudFront — global content delivery network
Amazon EFS — fully managed file system for EC2

Database

Amazon Aurora — high-performance managed relational database
Amazon RDS — managed database service for MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server
Amazon QLDB — fully managed ledger database
Amazon Redshift — quick, simple, cost-effective data warehouse
Amazon Neptune — fully managed graph database service
Amazon DynamoDB — NoSQL managed database
Amazon ElastiCache — in-memory caching system

Security and Identity Management

AWS WAF — filters malicious web traffic
AWS IAM — securely manages access to services and resources
AWS Shield — DDoS protection
AWS KMS — manages creation and encryption of keys
AWS Directory Service — hosts or manages Active Directory
AWS CloudHSM — hardware-based key storage for regulatory compliance
AWS GuardDuty — managed threat detection service
Amazon Cognito — identity management for apps

Development Tools

AWS CodeCommit — stores code in a private repository
AWS CodeBuild — builds and tests code
AWS CodeDeploy — automates code deployment
AWS CodePipeline — releases software using continuous delivery
AWS CodeStar — develop and deploy AWS applications

Management Tools

AWS OpsWorks — automated operations with Chef and Puppet
AWS Config — tracks resources, inventory, and changes
AWS CloudTrail — tracks user activity and API usage
AWS CloudWatch — monitors resources and applications
AWS CloudFormation — creates and manages resources with templates
AWS Trusted Advisor — optimizes performance and security

Application Integration

Amazon SES — used to send emails via applications
Amazon SNS — manages message topics for pub/sub
Amazon SQS — manages messages in a queue
Amazon MQ — managed message broker for ActiveMQ
Amazon EventBridge — serverless event bus for SaaS apps and AWS

Networking

Amazon VPC — isolated cloud resources
Amazon Route 53 — scalable Domain Name System
AWS Direct Connect — dedicated network connection to AWS
AWS PrivateLink — secure access to services hosted on cloud
Amazon API Gateway — build, manage, and deploy APIs
AWS Transit Gateway — easily scalable VPC and account connections

How to Access AWS — CLI, SDKs, and Management Console

There are three main ways to access AWS resources:

1. AWS CLI (Command Line Interface)

A tool used to manage AWS resources and automate service management with scripts
Supports Mac, Linux, and Windows OS

2. AWS Management Console

A simple web-based user interface
AWS has different GUIs for Android and iOS to access some services like EC2, DynamoDB, ELB, Beanstalk, CloudWatch, etc.

3. SDKs (Software Development Kits)

All major programming languages have compatibility with AWS SDKs, including Java, .Net, PHP, Ruby, Python, Go, C++, Node.js, etc.

Where to read & follow

GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/

Coming up next: AWS free tier account creation and QA.

aws #devops #cloudcomputing #learning

Day 10: Elasticity, Scalability & High Availability — AWS's 3 Core Value Props

Soumyaranjan Palatasingh — Tue, 11 Aug 2026 03:09:53 +0000

Continuing AWS fundamentals. Today: the 3 T's of AWS — Elasticity, Scalability, and High Availability — what they actually mean and how they're achieved.

Elasticity

EC2 (Elastic Compute Cloud) is where applications run — instances behind a Load Balancer that distributes traffic to them.

If the Load Balancer starts seeing more traffic, more EC2 instances are launched to handle the load. The increasing and decreasing of the number of servers based on load is called Elasticity.

Elasticity is short-term
Elasticity is achieved in AWS using Auto Scaling
Auto Scaling works in two directions:
- Scale out — increasing/adding instances
- Scale in — decreasing/removing instances
Elasticity is also called Horizontal Scaling

Scalability

Increasing the capacity of a single server (instead of adding more servers) is called Scalability.

Example: a database server running 100 databases sized 10TB on an 8GB RAM machine needs its RAM increased due to slowness — that's scaling the existing server up
Scalability = Scale Up and Scale Down
To scale, you typically need to stop the server/instance
Instance Type = combination of CPU + Memory
Scalability can be achieved in AWS by changing the instance type
Scalability is long-term
Scalability is also called Vertical Scaling

High Availability (HA)

The period of time a service is available to customers is called High Availability
The period of time a service is NOT available to customers is called Downtime
High Availability is measured in percentage
Zero Downtime = Auto Scaling + Fault Tolerance

The three pillars of High Availability:

Redundancy — keeping the same application running on different servers (duplicate setups)
Monitoring — the Load Balancer continuously checks if the application is working, using health checks
- If the Load Balancer gets a success code (200), it considers the application healthy
- Health checks happen every 30 seconds
Failover — if one server goes down, another server takes over the requests from the Load Balancer

IaaS vs PaaS vs SaaS — Applied to AWS

AWS also offers PaaS and SaaS, not just IaaS:

AWS Elastic Beanstalk uses PaaS — you only upload your application, and it takes care of the rest (infrastructure, scaling, deployment)
With EC2, you have to do all of this manually (that's IaaS)
Elastic Beanstalk enables easy and quick deployment of applications in AWS

The biryani analogy, applied to AWS:

Preparing biryani and eating it = IaaS (EC2 — you do the work)
Going and eating in a restaurant = PaaS (Elastic Beanstalk — mostly handled for you)
Ordering via Swiggy/Zomato = SaaS (fully managed, ready to use)

Recap: The 3 T's of AWS

Elasticity — short-term, horizontal scaling, achieved via Auto Scaling
Scalability — long-term, vertical scaling, achieved by changing instance type
High Availability — achieved via Redundancy + Monitoring + Failover

Where to read & follow

GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/

Coming up next: AWS Service Categories, plus how to access AWS — CLI, SDKs, and the Management Console.

aws #devops #cloudcomputing #learning

Day 9: Introduction to AWS — Global Infrastructure, Regions & Availability Zones

Soumyaranjan Palatasingh — Mon, 10 Aug 2026 04:03:12 +0000

Moving into AWS now. Today: what AWS actually is, and how its global infrastructure — Regions, Availability Zones, and Local Zones — is structured.

What is AWS?

AWS (Amazon Web Services) is a secure cloud service platform that offers compute power, database, storage, content delivery, and other resources to help businesses scale and grow.

Provides 175+ services
Client security is a major focus — AWS's infrastructure successfully satisfies the security needs of military, global banks, and other high-sensitivity organizations
Has 230+ security, compliance, and governance services, with 90+ security standards and compliance certifications, and 117+ AWS services can encrypt data

Benefits of AWS

Easy to use
Scalable, with high performance
Dominant market position
Cost effective
Reliable
Secure
Flexible
Can support large organizations

AWS Global Infrastructure

Regions

A Region is a separate geographic area containing a set of Availability Zones — e.g., AWS Region = Mumbai
AWS currently has 34 Regions
Regions don't communicate with each other by default (only if required/configured)
Choosing the right region depends on: pricing, user/customer location, latency, service availability, and security/compliance requirements

Availability Zones (AZs)

An Availability Zone is a data center (or group of data centers) within a Region
A Region contains multiple AZs
Each AZ has an independent power supply, cooling system, and physical security
Each AZ is connected to other AZs in the same Region via a redundant, low-latency network
AZs make applications and databases highly available, fault-tolerant, and scalable compared to traditional data centers
Best practice: distribute instances across AZs — very unlikely that more than one AZ goes down at once
Data can be shared across AZs if required
An EC2 instance is specific to a Region and AZ — e.g., if you launch an EC2 instance in Mumbai, it stays in Mumbai unless you explicitly launch in another region like Ireland

Local Zones

An AWS infrastructure deployment option that places AWS compute, storage, database, and other services closer to large population centers and industry hubs where no AWS Region exists today
Used to deploy workloads requiring single-digit millisecond latency, like video rendering and virtual desktop applications

Direct Connect

Lets organizations establish private connections between AWS and their datacenter, office, or colocation environment
Results in reduced network costs, increased bandwidth, and a more consistent network experience than internet-based connections

Latency

Latency is the measure of time required for data to transfer from client to server and back
The higher the latency, the lower the efficiency
AWS has clients throughout the world, so to reduce latency and avoid overloading servers, they use Edge Locations
Low latency = good (fast); High latency = bad (slow)
Always choose the region closest to your customer's location for the best latency

POP (Points of Presence) Locations

Small setups in different locations where AWS caches content and delivers it quickly to the end user
As of a recent count, AWS provides 217+ Points of Presence (205 Edge Locations and 12 Regional Edge Caches)
POP locations are used by Amazon CloudFront (AWS's CDN service) — a fast content delivery network that securely delivers data, videos, and applications to customers globally with low latency
We can cache data to the POP location nearest the end-user using CloudFront
If you use AWS origins such as Amazon S3, Amazon EC2, you don't pay for any data transferred from your origin to CloudFront Edge Locations

Data Replication Between Regions

Data present in one region can be replicated to a different region to maintain data availability during failure.

Benefits of data replication:

Increases fault tolerance
Increases redundancy
Reduces latency

Availability — the Core Idea

Availability refers to the ability of a system or component to be operational and accessible anytime. It ensures that data and services are available in normal and even disaster recovery operations — it always answers the question "Can I access my data right now?" This is achieved by maintaining reliable engineering, redundancy, and management techniques that minimize system failures and time to repair.

Where to read & follow

GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/

Coming up next: Elasticity, Scalability, and High Availability — AWS's three core value props.

aws #devops #cloudcomputing #learning

Day 8: Complete Q&A Recap — Cloud, Architecture, Virtualization & Networking + 'nslookup' Command Practical

Soumyaranjan Palatasingh — Sun, 09 Aug 2026 03:05:50 +0000

Recap day. Testing everything from Day 0 through Day 7 with quick single-line answers, plus a hands-on nslookup practical to try yourself.

Cloud Computing & Service/Deployment Models

Q: What is Cloud Computing?
A: Accessing computing resources remotely over the internet instead of managing infrastructure on-premises.

Q: What does NIST define cloud computing as?
A: A model for on-demand network access to a shared pool of configurable computing resources.

Q: What are the three main service models?
A: IaaS, PaaS, SaaS.

Q: In IaaS, who manages the OS and runtime?
A: You do — the vendor only provides the infrastructure.

Q: In PaaS, who manages the OS and runtime?
A: The vendor does — you only manage your application and data.

Q: In SaaS, what do you manage?
A: Nothing — you just use the finished application.

Q: What are the four deployment models?
A: Public, Private, Hybrid, Community.

Q: Which deployment model is dedicated to one organization?
A: Private Cloud.

Q: Which deployment model mixes public and private?
A: Hybrid Cloud.

Q: Which deployment model serves a group of organizations with shared concerns?
A: Community Cloud.

Client-Server Architecture

Q: What is a client?
A: A device or application that requests services from a server.

Q: What is a server?
A: A system that provides services or resources to clients.

Q: What defines 1-tier architecture?
A: Everything — UI, logic, database — lives on a single machine.

Q: What defines 2-tier architecture?
A: The client talks directly to the database server.

Q: What defines 3-tier architecture?
A: The client talks to an app server, which talks to the database — no direct client-to-database access.

Q: Why is 3-tier architecture more secure than 2-tier?
A: The client never has direct access to the database.

Data Centers, Virtualization & Hypervisors

Q: What is a classic data center made up of?
A: Compute, storage, network, application, and DBMS.

Q: What is virtualization?
A: Abstracting physical resources so they function as logical/virtual resources.

Q: What problem does virtualization solve?
A: Underutilization and complex management caused by dedicating resources per business unit.

Q: What is a hypervisor?
A: The software layer that creates and manages virtual machines.

Q: What's the difference between Type 1 and Type 2 hypervisors?
A: Type 1 runs directly on hardware; Type 2 runs on top of an existing OS.

Q: What is a virtual machine?
A: A software-based emulation of a physical computer, sharing hardware but running its own OS.

OSI Model

Q: How many layers does the OSI model have?
A: 7.

Q: What's a mnemonic to remember the OSI layers?
A: "All People Seem To Need Data Processing."

Q: Which OSI layer handles encryption and data formatting?
A: Presentation layer.

Q: Which OSI layer manages sessions between devices?
A: Session layer.

Q: Which OSI layer handles MAC addressing?
A: Data Link layer.

Q: Which OSI layer is the actual physical medium (cables, Wi-Fi)?
A: Physical layer.

DNS, Load Balancers, Firewalls & Protocols

Q: What does DNS stand for?
A: Domain Name Server.

Q: Where is Local DNS stored on a machine?
A: In /etc/host.

Q: What does the Root Name Server identify?
A: The TLD (Top Level Domain).

Q: What is an SOA record?
A: Start of Authority — the record holding the actual IP for a domain.

Q: What does a Firewall do?
A: Stops unauthorized access by allowing or denying traffic based on rules.

Q: What does a Load Balancer do?
A: Distributes incoming traffic across multiple servers.

Q: What is the Round Robin method?
A: Equally distributing traffic across servers in rotation.

Q: What port does HTTP use by default?
A: Port 80.

Q: What port does HTTPS use by default?
A: Port 443.

Q: What port does SSH use?
A: Port 22.

Q: What port does RDP use?
A: Port 3389.

Q: Why is HTTP not secure?
A: It sends data in plain text, readable by anyone intercepting it.

Q: What does TCP do?
A: Establishes a reliable, tracked connection between two hosts.

Q: How is UDP different from TCP?
A: Faster, but connectionless and not reliable.

Q: What status code means success?
A: 200.

Q: What status code means "page not found"?
A: 404.

Q: What status code means "internal server error"?
A: 500.

nslookup Command Practical

nslookup is a command-line tool that resolves a domain name to its IP address — a hands-on way to see DNS resolution actually happen.

Try it yourself:

Open Command Prompt
Type nslookup
Enter any domain (e.g., facebook.com, google.com) to see its resolved IP
Try entering an IP address directly to see the reverse — it'll return the hostname behind that IP

(Screenshot of my own nslookup practical run attached below as proof.)

Where to read & follow

GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/

Coming up next: Moving into AWS.

aws #devops #networking #cloudcomputing #learning