DEV Community: Soumyaranjan Palatasingh

Day 24: AWS Database — Extended (QLDB and Neptune)

Soumyaranjan Palatasingh — Wed, 26 Aug 2026 03:44:03 +0000

Day 23 wrapped up the original 11-day core service tour. Starting today, we move into the extended 7-day arc — services that didn't make the first pass but round out a genuinely complete picture of AWS. We're kicking it off back in the database world, with two specialized engines built for problems that neither relational databases nor DynamoDB handle particularly well: an immutable record of history, and deeply connected data.

Amazon QLDB (Quantum Ledger Database)

QLDB is a fully managed ledger database — purpose-built for applications that need a complete, verifiable, and unchangeable history of every change ever made to their data, not just the current state.

Here's the problem it solves that a regular database doesn't: in a typical relational database, when you update a row, the old value is simply gone (unless you built your own audit-log table to track it, which most teams don't do consistently, and which itself can be edited or deleted). For systems like financial transaction ledgers, supply chain tracking, or HR records, that's a real liability — you often need to prove not just what the current state is, but the exact, tamper-proof sequence of changes that got you there.

QLDB works by maintaining an append-only journal — every change is written as a new entry, and nothing is ever overwritten or deleted. Each entry is cryptographically chained to the one before it (similar in spirit to a blockchain's hash-linking), which means if anyone tried to alter a past entry, the cryptographic chain would break and the tampering would be immediately detectable. You can query both the current state of your data and its complete historical journey using PartiQL, a SQL-compatible query language that also understands QLDB's document-oriented, nested data.

A distinction worth being precise about, since it comes up constantly: QLDB is not a blockchain, even though the "immutable, cryptographically verified history" pitch sounds similar. Blockchain is built for scenarios where multiple parties who don't trust each other need to agree on a shared history without a central authority — that's why it needs distributed consensus, which is inherently slower and more complex. QLDB assumes a single trusted owner (your organization) maintaining the ledger; you don't need consensus across untrusted parties, just an unchangeable record that you yourself can't quietly alter after the fact. That trade-off makes QLDB dramatically faster and simpler to operate than running your own blockchain network, while still delivering the "tamper-evident history" property most companies actually need.

Amazon Neptune

Neptune is a fully managed graph database service — built specifically for data where the relationships between things matter as much as the things themselves.

The problem it solves: relational databases represent relationships through foreign keys and joins, and both DynamoDB and a typical relational schema get noticeably slower and more awkward as you ask questions that involve traversing many hops of connection — "find friends of friends of friends who also follow this person," or "find everyone connected to this fraud ring within 4 degrees." Each additional hop in a relational database means another join, and performance degrades fast. A graph database stores data explicitly as nodes (the entities — a person, a product, an account) and edges (the relationships connecting them — "follows," "bought," "works at") from the start, which makes traversing those connections dramatically faster, since the relationships are already stored as first-class, directly-connected data rather than something you have to reconstruct via a join at query time.

Neptune supports two different graph models and query languages, which is worth knowing since they solve slightly different problems: the property graph model, queried with Gremlin or openCypher, which is generally the more common choice for application-style graph use cases (social networks, recommendation engines, fraud detection); and the RDF (Resource Description Framework) model, queried with SPARQL, which is more common in knowledge-graph and semantic-web style use cases where you're representing formal, standardized relationships between concepts.

Common real-world use cases make the fit obvious: social network features (mutual friends, "people you may know"), recommendation engines (customers who bought X also bought Y, several hops deep), fraud detection (spotting rings of connected fraudulent accounts that wouldn't look suspicious individually), and knowledge graphs (representing and querying complex, interconnected facts).

Worth knowing beyond the fundamentals: Neptune supports high availability through read replicas spread across Availability Zones — up to 15, the same ceiling as Aurora — and automatic failover if the primary instance fails. It's also fully managed the way RDS and DynamoDB are: no manual patching or infrastructure management, and it scales storage automatically as your graph grows.

Why these two, specifically

QLDB and Neptune both exist because forcing certain data shapes into a relational or even a NoSQL key-value model creates real friction: QLDB because relational databases don't preserve history by default and can't cryptographically prove nothing was altered after the fact, and Neptune because relational joins get expensive fast once you're asking questions that are fundamentally about traversing relationships rather than looking up records. Neither is a replacement for RDS or DynamoDB in general — they're specialized tools for genuinely specialized shapes of problem.

Quick Recap Questions

What does QLDB give you that a regular database with an audit-log table doesn't?
Why is QLDB not a blockchain, despite both offering tamper-evident history?
Why does a graph database traverse deep relationships faster than a relational database with joins?
What's the difference between Neptune's property graph model and its RDF model, in terms of when you'd reach for each?

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
25	Security — Identity & Threat Protection	AWS Directory Service, CloudHSM, GuardDuty, Cognito

aws #devops #cloudcomputing #learning

Day 23: AWS Security — Encryption (ACM/KMS), Secrets Manager, AWS Backup, WAF, and Shield

Soumyaranjan Palatasingh — Mon, 24 Aug 2026 11:43:16 +0000

Day 22 covered how you observe and audit your environment. Today closes out the original 11-day service tour with the layer that actually protects it: encryption, secrets, backups, and the two services that guard the request path itself against attack. This is deliberately the last stop before we move into the extended set of services, since security genuinely underpins everything covered in the previous 10 days.

Encryption: In Transit vs At Rest

There are two fundamentally different moments where data needs protecting, and AWS treats them as separate problems with separate tools.

Encryption in transit protects data while it's traveling — between a user's browser and your server, or between two AWS services. This is what HTTPS provides, and in AWS, ACM (AWS Certificate Manager) is the service that makes HTTPS practical at scale: it issues free SSL/TLS certificates and, critically, handles automatic renewal — no more manually renewing a certificate every year and forgetting until it expires in production. ACM integrates directly with ELB, CloudFront, and API Gateway, so you attach a certificate to one of those and traffic is encrypted end-to-end without you managing certificate files by hand.

Encryption at rest protects data while it's sitting still — on a disk, in a database, in a backup. This relies on encryption keys, and KMS (Key Management Service) is where AWS manages the creation and lifecycle of those keys. KMS integrates with most storage and database services (S3, EBS, RDS, DynamoDB, and more) — when you enable encryption on a resource, you're almost always pointing it at a KMS key behind the scenes. AWS-managed keys are the default and require no setup, while customer-managed keys give you more control — you can define who's allowed to use the key, rotate it on a schedule (KMS supports automatic annual rotation for customer-managed keys), and revoke access entirely if needed. This is genuinely one of the most consequential security defaults in AWS: enabling encryption at rest on a resource costs almost nothing in setup effort, and skipping it is one of the most common, avoidable security gaps in real deployments.

AWS Secrets Manager

Secrets Manager exists to store secrets — database credentials, API keys, and other sensitive values — rather than the extremely common (and extremely risky) alternative of hardcoding them directly into application code or configuration files.

Beyond just storage, its standout feature is automatic rotation: Secrets Manager can rotate a database password on a schedule (say, every 30 days) by invoking a Lambda function that updates both the secret's value and the actual database credential in sync, so your application never has to be manually updated when a credential changes — it just fetches the current secret at runtime. This closes a real operational gap: rotating credentials manually is tedious enough that many teams simply never do it, which means a leaked credential from years ago can still be valid.

Worth knowing: AWS Systems Manager Parameter Store solves a similar problem for configuration values and secrets, and is cheaper (with a free tier), but doesn't offer Secrets Manager's built-in automatic rotation out of the box. Parameter Store tends to be the choice for general configuration and infrequently-changing secrets; Secrets Manager is the choice specifically when automatic rotation matters, like production database credentials.

AWS Backup

AWS Backup centrally manages and automates backups — instead of configuring backup schedules separately for EBS, RDS, DynamoDB, EFS, and every other service that needs one, you define a backup plan once (how often to back up, how long to retain each backup) and apply it across multiple resource types and services from a single place.

This matters more than it might sound like at first: without a centralized approach, backup configuration tends to drift — someone sets up EBS snapshots but forgets DynamoDB, or retention policies end up inconsistent across services because they were each configured separately, at different times, by different people. AWS Backup also supports cross-region and cross-account backup copies, which is important for disaster recovery scenarios where you specifically don't want your only backup living in the same Region (or even the same account) as the resource it's backing up — if that Region or account has a serious problem, you don't want your backup to be affected by the exact same problem.

AWS WAF (Web Application Firewall)

WAF protects web applications from common web exploits — it sits in front of your application (attached to an ALB, CloudFront distribution, or API Gateway) and inspects incoming HTTP/HTTPS requests before they reach your actual application.

What it actually filters for: AWS provides managed rule groups that catch well-known attack patterns without you having to write detection logic yourself — things like SQL injection attempts, cross-site scripting (XSS), and known bad IP addresses or bot signatures. You can also write custom rules, including rate-based rules that automatically block an IP address making an abnormally high number of requests in a short window — a simple but effective defense against both brute-force login attempts and certain denial-of-service patterns. WAF operates at the application layer (Layer 7), meaning it actually understands HTTP requests — headers, query strings, request bodies — rather than just raw network packets, which is what lets it catch attacks that live inside the content of a request rather than just its source or volume.

AWS Shield

Shield is a managed DDoS (Distributed Denial of Service) protection service — it defends against attacks designed to overwhelm your infrastructure with sheer volume of traffic rather than exploiting a specific vulnerability in your application code.

Shield Standard is automatically enabled on every AWS account at no additional cost, providing protection against the most common, frequently occurring network and transport layer (Layer 3/4) DDoS attacks. Shield Advanced is a paid tier that adds protection against larger, more sophisticated attacks, near real-time visibility into attacks as they happen, and — notably — access to the AWS DDoS Response Team (DRT) for direct help during an active attack, plus cost protection, which credits back the charges you'd otherwise incur from the scaling that an attack triggers (since a DDoS attack driving up your Auto Scaling Group could otherwise leave you with a legitimate-looking but attack-caused bill).

How they fit together

Together, these five form layered protection around two different things: encryption, Secrets Manager, and Backup protect your data — whether it's moving, sitting still, being authenticated against, or being recovered after something goes wrong — while WAF and Shield protect the request path itself, filtering out malicious or overwhelming traffic before it ever reaches your application. Neither layer substitutes for the other: airtight encryption doesn't stop a DDoS attack, and DDoS protection doesn't stop an unencrypted database from leaking data if someone gets unauthorized access to it.

Quick Recap Questions

What's the practical difference between what ACM protects and what KMS protects?
Why is automatic rotation such a meaningful feature in Secrets Manager, beyond just "storing secrets safely"?
Why does AWS Backup's cross-region/cross-account capability matter specifically for disaster recovery?
What's the difference between what WAF defends against and what Shield defends against?

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
24	Database — Extended	QLDB, Neptune

aws #devops #cloudcomputing #learning

Day 22: AWS Monitoring & Management — Trusted Advisor, Inspector, CloudWatch, CloudTrail, Config

Soumyaranjan Palatasingh — Sun, 23 Aug 2026 12:52:00 +0000

Day 21 covered who can access what (IAM) and how multiple accounts are governed (Organizations). Today's five services answer a different question entirely: once your infrastructure is running, how do you actually know what's happening inside it — what's misconfigured, what's vulnerable, what's healthy, who did what, and what changed? Each of these services answers one specific version of that question, and together they form the operational backbone of running AWS responsibly rather than just deploying and hoping.

AWS Trusted Advisor

Trusted Advisor is AWS's built-in advisor — it scans your account and gives you recommendations across five categories: cost optimization (idle or underutilized resources you're paying for), performance (things like over-provisioned instances or services approaching their limits), security (open security groups, missing MFA, exposed access keys), fault tolerance (single points of failure, missing backups, resources not spread across AZs), and service limits (approaching a hard AWS quota that could block you from scaling further). Think of it as an automated consultant constantly looking over your shoulder for things you're doing suboptimally, without you having to ask.

On the free Basic Support tier, you get a limited set of core checks — the notes mention 5 free checks — enough to catch some genuinely important issues, like a wide-open security group or a root account without MFA enabled. The full set of checks, which runs into the dozens and covers much deeper cost and performance analysis, unlocks with Business or Enterprise support plans. Even at the free tier, it's worth checking in on periodically — the security checks alone are often worth acting on immediately, since they tend to flag the kind of misconfiguration that leads directly to a real incident.

AWS Inspector

Inspector is a vulnerability management service — it inspects your AWS environment and tells you about security issues, specifically around known, documented vulnerabilities. It automatically and continuously scans three types of resources: EC2 instances (checking installed software packages against known vulnerabilities and looking at network reachability — is a vulnerable port actually exposed to the internet, not just present), container images in ECR (scanning layers for vulnerable packages before or after you deploy them), and Lambda functions (checking function code and dependencies for known issues).

The scanning itself cross-references against CVEs (Common Vulnerabilities and Exposures) — the industry-standard public database of documented software vulnerabilities. The real value here isn't the initial scan; it's that Inspector is continuous. As new CVEs get published — which happens constantly — Inspector automatically re-evaluates your existing, already-deployed resources against them. That means you find out about a vulnerability discovered in a package you deployed six months ago, not just at the moment you originally deployed it. Inspector also assigns a risk score to findings, which helps prioritize what to actually fix first instead of facing an undifferentiated wall of alerts.

Amazon CloudWatch

CloudWatch is used to monitor all AWS resources — EC2, ELB, S3, RDS, and effectively everything else — by tracking their metrics: CPU utilization, network traffic, disk activity, request counts, memory usage, and more, depending on the specific service.

The core workflow is alarm-based. You define alarms against specific metrics — for example, "alert me if CPU utilization stays above 80% for 5 minutes." When that threshold is breached, the alarm state changes (from OK to ALARM), and that state change is what actually triggers something. You can get notified by SMS or email by integrating CloudWatch with SNS (Simple Notification Service). Alarms aren't limited to notifications either — they can trigger real infrastructure actions, most notably scaling an Auto Scaling Group up or down, which ties directly back to the elasticity mechanics from Day 13: CloudWatch is often the actual thing watching the metric that an Auto Scaling target-tracking policy reacts to.

Two tiers of monitoring control how quickly you actually notice a problem: basic monitoring gives you a data point every 5 minutes and is free; detailed monitoring gives you a data point every 1 minute but is billable. The difference matters more than it sounds — a traffic spike or resource issue that lasts only 2-3 minutes could be completely invisible on basic monitoring's 5-minute granularity, showing up as barely a blip (or not at all) in the averaged data, while detailed monitoring would catch it clearly.

Beyond metrics and alarms, CloudWatch has a few other components worth knowing:

CloudWatch Logs centralizes log storage and searching for your applications and AWS services — instead of SSHing into individual instances to tail log files, your applications ship logs to CloudWatch and you search them centrally, including setting up metric filters that turn specific log patterns into their own trackable metrics.
CloudWatch Dashboards are customizable visual views combining metrics from multiple services into a single at-a-glance operational view — useful for an ops team that wants one screen showing overall system health instead of clicking through a dozen individual service consoles.
CloudWatch Events/EventBridge (which we actually covered back on Day 14) is closely related — CloudWatch traditionally handled scheduled and reactive triggers before that functionality was expanded into the standalone EventBridge service.

AWS CloudTrail

Where CloudWatch tells you how your resources are performing, CloudTrail tells you who did what. It tracks your entire AWS environment by recording, monitoring, tracking, and auditing activity — specifically, every API call made in your account gets logged, including which IAM user or role made it, from what IP address, at what time, and what the actual request and response looked like.

This is essential for both security auditing and plain operational troubleshooting: if a resource gets deleted unexpectedly, or a security group gets modified in a way that shouldn't have happened, CloudTrail is what tells you exactly which identity made that specific API call and when — turning "something changed and nobody knows why" into a five-minute lookup instead of a mystery.

By default, AWS keeps a rolling 90-day event history you can search immediately with zero setup. For longer retention, more structured analysis, or integration with other tools, you create a trail, which delivers logs continuously to an S3 bucket (and optionally CloudWatch Logs), where they can be retained indefinitely and queried with tools like Athena.

A distinction worth knowing: CloudTrail separates management events (control-plane actions — creating an EC2 instance, deleting an S3 bucket, modifying an IAM policy) from data events (data-plane actions — reading or writing an individual object inside an S3 bucket, invoking a specific Lambda function). Management events are logged by default at no extra cost. Data events, being vastly higher in volume in any active system, need to be explicitly enabled if you want that level of granular detail, and typically cost more to log as a result.

AWS Config

Config rounds out the picture by answering yet another distinct question: what changed, and is it compliant? It continuously monitors the configuration of your AWS resources — not just that an action happened (that's CloudTrail's job) but the actual resulting state of the resource — and keeps a detailed configuration history over time. If anyone modifies a resource's configuration, Config records exactly what changed, when, and what the configuration looked like both before and after, giving you a browsable timeline for any tracked resource.

Beyond just tracking history, Config's more actionable feature is Config Rules — you define what a compliant configuration actually looks like (for example, "all S3 buckets must have encryption enabled," or "all EBS volumes must be encrypted"), and Config continuously evaluates your real resources against that rule, flagging each one as compliant or non-compliant in something close to real time as configurations drift. Some rules go a step further and support automated remediation — instead of just alerting a human, Config can trigger a Lambda function or SSM automation document that actually fixes the non-compliant configuration automatically, closing the loop without manual intervention.

How they fit together

Each of these looks at your AWS environment through a genuinely different lens, and together they cover a full operational picture: Trusted Advisor tells you what you should fix based on best practices, Inspector tells you what's vulnerable, CloudWatch tells you how things are performing right now, CloudTrail tells you who did what, and Config tells you what changed and whether it's still compliant. None of them substitute for the others — a mature AWS setup genuinely runs all five together, because each one would miss something the others catch.

Quick Recap Questions

What's the difference between what CloudWatch monitors and what CloudTrail tracks?
Why does the difference between basic and detailed CloudWatch monitoring actually matter in practice?
What's the difference between a CloudTrail management event and a data event, and why are they treated differently?
How is AWS Config different from CloudTrail, if both involve "tracking changes" in some sense?
Why does Inspector's continuous re-scanning matter more than a one-time scan at deployment?

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
23	Security	Encryption (ACM/KMS), Secrets Manager, AWS Backup, WAF, AWS Shield

aws #devops #cloudcomputing #learning

Day 21: AWS Identity & Governance — IAM and Organizations

Soumyaranjan Palatasingh — Sat, 22 Aug 2026 09:40:31 +0000

Day 20 wrapped up databases. Today we shift gears entirely, into the layer that decides who can do what in your AWS account: IAM and Organizations. This is arguably the most important security topic in the whole series — misconfigured permissions are one of the most common ways real companies get breached.

AWS IAM (Identity and Access Management)

IAM is how you control access to the entirety of AWS — every service, every resource — by granting proper permissions to identities. It's a global service, not tied to any Region, since identity and access control needs to apply consistently across your whole account regardless of where your resources live.

The starting point for every AWS account is the root account — the one you create the account with, using an email and password. The root account has full, unrestricted permissions over everything, including billing. Because of that, using the root account for day-to-day work is a bad practice: if those credentials are ever compromised, an attacker has complete control. This is exactly why IAM users exist — individual identities you create for actual people, each logging in with their own username and password, and each given only the specific permissions they need to do their job.

A concrete example makes this click: imagine one person needs EC2 access, another needs S3 and IAM access, a third needs only Lambda, a fourth needs RDS and EFS, and a fifth needs admin access to everything except billing. Rather than sharing the root account (or giving everyone full access "just in case"), IAM lets you create a separate user for each person with exactly the permissions their role requires — nothing more. This is the principle of least privilege, and it's the foundational idea behind almost everything else IAM does.

A few building blocks beyond individual users:

IAM Groups let you bundle users who need the same permissions — instead of attaching a policy to five individual developers, you create a "Developers" group, attach the policy once, and add users to it. Permissions changes then happen in one place instead of five.
IAM Roles are different from users in an important way: a role isn't tied to one specific person logging in with a password — it's an identity that gets assumed temporarily, often by an AWS service itself (like an EC2 instance needing to read from S3) or by a user/account that doesn't normally have that access. Roles issue temporary credentials through AWS's STS (Security Token Service) rather than permanent ones, which is a meaningfully safer pattern than embedding long-lived access keys directly into an application.
IAM Policies are the actual documents that define permissions — written in JSON, specifying which actions are allowed or denied on which resources. AWS provides managed policies (pre-built, maintained by AWS, like "AmazonS3ReadOnlyAccess") that you can attach directly, or you can write inline policies custom-tailored to a specific user, group, or role.
MFA (Multi-Factor Authentication) adds a second verification step beyond just a password — AWS strongly recommends enabling it on the root account at minimum, and ideally on every IAM user, since a password alone is a single point of failure.

Worth knowing: IAM Identity Center (formerly AWS SSO) extends this further for organizations managing many users across multiple AWS accounts — letting people log in once and access everything they're permitted to, rather than juggling separate credentials per account.

AWS Organizations

IAM controls access within one AWS account. Organizations solves a different problem: controlling and structuring multiple AWS accounts under one company.

Here's the scenario it's built for: a company doesn't run everything in a single AWS account — different teams (DevOps, Development, Testing, Support) often get their own separate accounts, each acting as its own isolated root account with its own resources and permissions. Left unmanaged, that's a lot of separate root accounts to track, secure, and bill. Organizations brings structure to that: one account becomes the management account (essentially the company's overarching root account), and the rest become member accounts underneath it.

In a typical setup, each member account is still its own root account with its own specific scope — a DevOps account might have access to IAM and EC2, a Developer account to Lambda, a Testing account to Route 53, a Support account to admin-level access. Organizations lets the management account oversee and control all of them centrally, rather than each team's account being a completely disconnected island.

SCPs (Service Control Policies) are how that central control actually gets enforced — they're policies attached at the organization or account level that define the maximum permissions a member account can ever have, regardless of what IAM policies exist inside that account. Even if someone inside a member account grants themselves a broad IAM policy, an SCP can still hard-block access to specific services entirely across that account — it's a guardrail that sits above IAM, not a replacement for it.

A couple of things worth knowing beyond the fundamentals: Organizational Units (OUs) let you group accounts logically (say, all "Engineering" accounts together) so you can apply SCPs to a whole group at once instead of one account at a time. And consolidated billing is a major practical benefit — instead of separate invoices per account, the management account gets one combined bill, and usage can even pool together to hit volume discount thresholds faster than any single account would alone.

How they work together

IAM and Organizations operate at different layers, but they're deeply connected: IAM controls who can do what within an account, while Organizations (via SCPs) controls the outer boundary of what an entire account is even allowed to do, regardless of its internal IAM setup. Think of SCPs as the walls of the room, and IAM policies as what you're allowed to do inside that room — you can't use an IAM policy to break through a wall an SCP has put up.

Quick Recap Questions

Why is using the root account for day-to-day work considered bad practice?
What's the actual difference between an IAM user and an IAM role?
What does an SCP control that a regular IAM policy can't override?
Why would a company want a management account and multiple member accounts instead of one big shared account?

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
22	Monitoring & Management	Trusted Advisor, AWS Inspector, CloudWatch, CloudTrail, Config

aws #devops #cloudcomputing #learning

Day 20: AWS Database — NoSQL, Warehouse & Cache (DynamoDB, Redshift, ElastiCache)

Soumyaranjan Palatasingh — Fri, 21 Aug 2026 10:52:00 +0000

Day 19 covered RDS and DMS — the relational side of AWS databases. Today we cover three services that each solve a problem relational databases weren't built for: flexible, high-speed data access at massive scale (DynamoDB), heavy analytical queries over huge datasets (Redshift), and shaving latency off frequently accessed data (ElastiCache).

Amazon DynamoDB

DynamoDB is AWS's NoSQL database service — a non-relational database, and it's one of the most commonly used AWS database services among developers, largely because of how little operational overhead it carries.

The core distinction from RDS: a relational database organizes data into tables with a fixed schema and relationships between tables (joins). DynamoDB instead stores data as items (similar to rows) inside tables, but without a fixed schema — different items in the same table can have different attributes. Every item is identified by a primary key, which can be just a partition key (a single unique identifier) or a composite of a partition key and a sort key (letting you group related items together and query them efficiently, like all orders for one customer, sorted by date).

Performance is the headline feature. DynamoDB is built for single-digit millisecond latency at virtually any scale — it doesn't slow down as your table grows the way a poorly-indexed relational table might. This is exactly why it's a common choice for things like session storage, shopping carts, gaming leaderboards, and IoT data ingestion — workloads that need to read and write huge volumes of simple, predictable data extremely fast.

Capacity modes matter for cost and performance planning: on-demand mode automatically scales to handle your traffic with no capacity planning at all, billing per request — good for unpredictable or spiky workloads. Provisioned mode lets you specify read/write capacity units upfront, which is cheaper at steady, predictable traffic levels but requires you to actually estimate your load correctly.

A couple of things worth knowing beyond the fundamentals: DAX (DynamoDB Accelerator) is an in-memory cache built specifically for DynamoDB, sitting in front of it to push response times from single-digit milliseconds down to microseconds for read-heavy workloads. And Global Tables let you replicate a DynamoDB table across multiple AWS Regions automatically, with multi-region, multi-active read and write access — useful for globally distributed applications that need low latency for users everywhere, not just near one Region.

Amazon Redshift

If RDS is "database in AWS," Redshift is "data warehouse in AWS" — and that distinction matters a lot, because a data warehouse is built to solve a fundamentally different problem than a regular database.

A regular database (RDS) is optimized for transactional workloads — lots of small, fast reads and writes, like a checkout process or a user login. A data warehouse is optimized for analytical workloads instead — running complex queries that aggregate and analyze huge volumes of historical data, like "what were our total sales by region for the last three years." Trying to run that kind of query against a transactional database can bring it to a crawl; that's precisely the gap Redshift fills.

The performance difference comes down to architecture. Redshift uses columnar storage instead of row-based storage — meaning it stores each column of data together rather than each row together. For analytical queries that typically only touch a handful of columns out of a much wider table (like just "region" and "sales" out of a table with fifty columns), this means Redshift only has to read the relevant columns rather than scanning entire rows, which is dramatically faster at scale. Redshift also uses Massively Parallel Processing (MPP) — a cluster made up of a leader node (which plans and coordinates queries) and multiple compute nodes (which actually execute the query in parallel across their own slice of the data), so a query that would take a single server a long time gets split across many nodes working simultaneously.

Worth knowing: Redshift Spectrum lets you run SQL queries directly against data sitting in S3, without having to load it into Redshift first — useful when you have huge volumes of raw data in S3 and only want to pay for querying it occasionally, rather than the cost of always keeping it loaded into a warehouse cluster.

Amazon ElastiCache

ElastiCache is an in-memory database caching service, and its whole purpose is reducing latency and increasing performance for data your application needs frequently.

Here's the underlying idea: an application server normally talks to a database server for every piece of data it needs. But a lot of real-world traffic is repetitive — the same product page, the same user profile, the same search result, requested over and over by different users in a short window. Instead of hitting the database every single time for data that hasn't changed, ElastiCache sits in front of the database as a cache memory layer: frequently accessed data gets stored in fast, in-memory cache, and subsequent requests for that same data get served straight from the cache instead of round-tripping to the database.

ElastiCache offers two engines, and they're not interchangeable — they solve caching differently:

Redis supports rich data structures (lists, sets, sorted sets, hashes, not just simple key-value pairs), offers built-in replication and persistence (so cached data can survive a restart), and supports pub/sub messaging — making it suitable for more than just caching, like leaderboards or real-time messaging.
Memcached is simpler and purely a caching layer — no persistence, no complex data structures — but it's easy to scale horizontally across multiple nodes and is a good fit when all you need is straightforward key-value caching without the extra features Redis brings.

A common real-world pattern: a user searches for a product on an e-commerce site ten times in an hour. Without caching, that's ten separate trips to the database for identical data. With ElastiCache in front of the database, the first search hits the database and gets cached; the next nine are served instantly from cache memory, dramatically reducing both latency for the user and load on the database.

How they fit together

These three services rarely compete with each other — they usually sit alongside RDS/DynamoDB, each handling a different part of the same application's traffic: DynamoDB (or RDS) handles the actual transactional reads and writes, ElastiCache absorbs the repetitive, frequently-requested reads to keep latency low and database load down, and Redshift sits off to the side entirely, periodically ingesting data for heavy analytical reporting that has nothing to do with live application traffic.

Quick Recap Questions

What's the fundamental structural difference between how DynamoDB stores data and how a relational database does?
Why is columnar storage such a big performance advantage for Redshift's typical analytical queries?
What's the practical difference between Redis and Memcached, and when would you pick one over the other?
Why would you put ElastiCache in front of a database instead of just scaling the database itself?

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
21	Identity & Governance	IAM, Organizations

aws #devops #cloudcomputing #learning

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