Author name: Shivam Pokhriyal

Every AWS project eventually runs into the same question: where should this actually run? The answer is not the same for every workload, and picking the wrong one either costs you more than it should or slows your team down with infrastructure work nobody wanted to do.  Here is how the three main compute options actually differ.  EC2 — Full Control, Full Responsibility  EC2 gives you a virtual machine. You choose the operating system, install what you need, and manage patching, scaling, and security yourself.  If your application looks the same today as it did last month in terms of load, EC2 is usually the most cost-predictable choice.  Lambda — Pay Only When Code Runs  Lambda runs your code in response to an event — an API call, a file upload, a scheduled trigger — and disappears when it is done. There is no server to patch or manage.  For workloads that run occasionally or spike unpredictably, Lambda often costs a fraction of an equivalent EC2 setup.  Fargate — Containers Without Managing Servers  Fargate runs your Docker containers without you provisioning or managing the underlying EC2 instances. You define the container, and AWS handles the infrastructure.  A Practical Way to Decide  Many businesses end up running all three side by side — EC2 for a core application, Lambda for background processing, and Fargate for containerized services. The mistake is picking one and forcing every workload into it. Match the compute model to what the workload actually needs, and the AWS bill usually takes care of itself. 

An AWS bill has dozens of line items, cryptic service names, and charges that appear without obvious explanation. Most business owners hand it to their technical team and hope for the best. That is understandable — but the business owner who understands their cloud spend has a significant advantage when it comes to controlling costs.  Here is what the main charges actually mean and where your money is most likely going.  Where to Find Your Bill  Go to the AWS Console → Billing and Cost Management → Bills. You will see a monthly summary broken down by service. Click into any service to see the regional breakdown.  AWS Cost Explorer is more useful for analysis — it lets you visualise spending over time, filter by service, region, and tag, and spot trends before they become problems.  The Biggest Cost Categories  EC2 (Elastic Compute Cloud)  This is usually the largest line item. It covers the compute instances running your servers. Within EC2 you will see:  RDS (Relational Database Service)  Database instance hours plus storage. If you see Multi-AZ in the description, you are paying for two instances (primary + standby). That is the right choice for production but unnecessary for non-critical environments.  S3  Storage cost per GB, PUT/GET request costs, and data transfer out. Most businesses are surprised by request costs — a high-traffic application making millions of S3 API calls can accumulate significant charges even with modest storage.  Data Transfer  AWS charges for data moving out of its network to the internet. Data transfer between AWS services in the same region is free. Data transfer between regions is not. This is a commonly overlooked cost driver for applications that move data between accounts or regions frequently.  What ‘Usage Type’ Means  Each line item has a Usage Type field that explains exactly what was consumed. For example:  Once you learn to read Usage Types, the bill becomes much clearer.  The Most Common Billing Surprises  Immediate Actions to Take 

Backup strategies fail in two ways: people do not set them up properly, or they set them up and never verify they actually work. Both lead to the same outcome when something goes wrong.  AWS Backup is a centralised service that automates backups across EC2, RDS, Aurora, EFS, DynamoDB, FSx, and Storage Gateway. One console, one set of policies, one audit trail.  What AWS Backup Covers  Before AWS Backup, you had to set up snapshot policies separately for each service. Now you define a Backup Plan — frequency, retention period, lifecycle to cold storage — and assign it to resources by tag.  Setting Up a Backup Plan  A Backup Plan has two components: rules and resource assignments.  Rules define when backups happen and how long they are kept. A typical production setup:  Resource assignments use tags. Tag your production RDS instance with Environment: production and assign that tag to your backup plan. Every resource with that tag is automatically backed up.  Cross-Region and Cross-Account Backup  For serious disaster recovery, copy backups to a different AWS region or a separate AWS account. AWS Backup supports both natively.  Cross-account backup is the most resilient option — even if someone accidentally deletes your AWS account or a ransomware attack encrypts your data, backups in a separate account remain untouched.  The Most Important Step: Test Your Restores  A backup you have never tested is not a backup — it is a hope. Schedule restore tests quarterly at minimum. Pick a random backup, restore it to a test environment, and verify the data is complete and usable.  AWS Backup has a restore testing feature that automates this. Configure it, run it, and get evidence that your backups are valid. This is also required for SOC 2 and ISO 27001 compliance.  Backup vs Replication  Backup and replication are not the same thing. Multi-AZ RDS replication gives you high availability — if one AZ fails, the standby takes over. But replication copies everything, including accidental deletions. Backup gives you point-in-time recovery — the ability to go back to before something went wrong.  You need both for a complete data protection strategy.

You’ve just launched your web app. The code is clean, the design looks great, and you’re proud of it. You share the link with a friend in Sydney, Australia. They click it. And then… they wait. And wait. The page finally loads — slowly, images dragging in one by one — and your friend quietly wonders if your app is actually finished. Meanwhile, your users in New York? Totally fine. This is the classic problem of geographic latency — and it’s exactly what AWS CloudFront was built to solve. So, What Is AWS CloudFront? AWS CloudFront is Amazon’s Content Delivery Network (CDN). In plain terms, it’s a global system of servers that stores copies of your content — images, videos, HTML files, JavaScript, APIs — closer to your users, so they don’t have to travel halfway around the world just to load your homepage. It sits between your users and your origin server (which could be an S3 bucket, an EC2 instance, an Application Load Balancer, or even a custom server on-premises). When someone requests your content, CloudFront serves it from the nearest location it can — reducing latency, cutting load on your origin, and making the whole experience feel snappier. Think of it like a chain of mini warehouses spread across the globe. Instead of shipping everything from one factory (your origin), you stock popular items in local warehouses (edge locations) so delivery is faster. Amazon built this infrastructure at a massive scale, and CloudFront plugs you into it. The Core Concepts You Need to Understand Before we get into setup, let’s make sure the vocabulary makes sense. These are the terms you’ll keep running into. Edge Locations These are CloudFront’s physical data centers scattered around the world. As of 2025, CloudFront has over 450 points of presence across 90+ cities in 47 countries. When a user in Mumbai requests your site, CloudFront routes that request to the nearest edge location — probably in Mumbai or Chennai — rather than all the way back to your server in us-east-1. Origin Your origin is where your actual content lives. It could be: CloudFront doesn’t replace your origin — it sits in front of it. Distribution A CloudFront distribution is basically your CDN configuration. You set one up per domain (or use one for multiple), define your origins, set caching rules, and configure behaviors. It’s the control plane for how CloudFront handles requests. Cache Behavior This is where you define how CloudFront caches different types of content. You might cache your static images for 30 days, but never cache your API responses. Cache behaviors let you define these rules per URL path pattern. TTL (Time to Live) TTL is how long CloudFront keeps a cached copy before checking back with your origin for a fresh version. Set it too low and you defeat the purpose of caching. Set it too high and users might see stale content. Finding the right balance is one of the key skills of working with CloudFront effectively. How a CloudFront Request Actually Works Here’s what happens behind the scenes when someone visits your CloudFront-powered site: That’s the fundamental loop. The first request for any piece of content in any region will always hit your origin. Every subsequent request until the cache expires is served from the edge. Why Does CloudFront Actually Matter? CDNs feel like an infrastructure detail — the kind of thing you “deal with later.” But here’s why that thinking can hurt you: 1. Speed Is a Product Feature Studies consistently show that page load time directly affects user behavior. A one-second delay in load time can reduce conversions by up to 7%. Mobile users on slower connections are even more sensitive. If your users are global, a CDN isn’t optional — it’s a necessity. 2. It Protects Your Origin Every request that hits your CDN instead of your origin is one less request your servers need to handle. During traffic spikes — say, you go viral or run a big promotion — CloudFront absorbs the surge. Without it, your origin can buckle under the load. 3. Built-In Security CloudFront integrates deeply with AWS’s security stack: 4. Cost Savings Serving content from the edge is cheaper than serving it from your origin — especially if your origin is EC2. You pay for CloudFront data transfer, but AWS charges less per GB through CloudFront than direct EC2 egress in many cases. And since fewer requests hit your origin, your compute costs drop too. 5. It Plays Well With the Rest of AWS If you’re already using S3, EC2, API Gateway, or Lambda@Edge, CloudFront plugs in almost seamlessly. The integrations are native, the IAM permissions are familiar, and the monitoring flows right into CloudWatch. Lambda@Edge and CloudFront Functions: Going Beyond Simple Caching Here’s where CloudFront gets genuinely interesting for developers. Lambda@Edge Lambda@Edge lets you run serverless functions at CloudFront’s edge locations — not in a central AWS region. This means you can execute code closer to your users without managing servers. Common use cases include: The latency savings are real. Code running 20ms from your user is fundamentally different from code running 200ms away. CloudFront Functions Launched in 2021, CloudFront Functions are a lighter-weight alternative to Lambda@Edge. They run at the edge for simpler operations — URL normalization, header manipulation, cache key customization — and are significantly cheaper and faster to execute. If you don’t need the full power of Lambda, reach for CloudFront Functions first. How to Get Started with CloudFront Enough theory. Let’s walk through setting up a basic CloudFront distribution for an S3-hosted static site. This is the most common starting point. Step 1: Have an S3 Bucket Ready If you don’t already have one, create an S3 bucket with your static site files (HTML, CSS, JS, images). Make sure static website hosting is enabled in the bucket properties. Step 2: Open CloudFront in the AWS Console Go to the AWS Management Console → search for CloudFront → click Create Distribution. Step

Connecting your office network to AWS securely — or giving remote employees access to cloud resources — comes down to two AWS VPN products. They look similar but solve different problems.  Site-to-Site VPN: Connecting a Location to AWS  A Site-to-Site VPN creates an encrypted tunnel between your on-premises network (office, data centre, branch) and your AWS VPC. Once connected, resources on your network and resources in AWS can communicate as if they are on the same local network.  How it works: you set up a Customer Gateway in AWS (which represents your on-premises router) and a Virtual Private Gateway on your VPC. AWS creates two redundant IPsec tunnels for high availability.  Use Site-to-Site VPN when:  Cost: AWS charges around $0.05 per VPN connection hour plus data transfer. For a permanent office connection, this is typically $36–40 per month — far less than a dedicated leased line.  AWS Client VPN: Access for Individual Users  Client VPN gives individual users — remote employees, contractors, developers — encrypted access to your VPC from wherever they are. Each user installs an OpenVPN-compatible client, authenticates (via Active Directory, certificate-based auth, or SAML with SSO), and gets a private IP address on your VPC.  Use Client VPN when:  Cost: you pay per endpoint association hour and per active client connection hour. For small teams, the cost is low. For large teams with constant connectivity, it adds up — evaluate whether a Site-to-Site VPN from a centralised office is more cost-effective.  Side-by-Side Comparison  Factor  Site-to-Site VPN  Client VPN  Connects  Location to AWS VPC  Individual user to AWS VPC  Authentication  Router/firewall certificate  AD, SAML, certificate  Setup complexity  Moderate (router config required)  Low to moderate  Best for  Offices, hybrid cloud  Remote workers, developers  Redundancy  Built-in (dual tunnels)  High availability endpoints available  Cost basis  Per connection hour  Per endpoint + per client hour  Can You Use Both?  Yes. Many businesses use Site-to-Site VPN to connect their office to AWS and Client VPN for remote employees. Both land on the same VPC, so all users — office-based and remote — access the same AWS resources securely. 

Most businesses provision servers for their peak load and leave them running 24 hours a day. At 2 AM when traffic drops, those servers sit idle and you still pay for them. When traffic spikes beyond your estimate, you either run out of capacity or scramble to add more manually.  Auto Scaling fixes both problems. You define the minimum and maximum number of instances you want, set scaling policies based on metrics like CPU or request count, and AWS handles the rest.  How Auto Scaling Works  An Auto Scaling Group (ASG) is a collection of EC2 instances that are managed together. You define:  When a scaling policy triggers — say, average CPU crosses 70% — AWS launches new instances automatically. When load drops, it terminates them. The Application Load Balancer routes traffic only to healthy instances.  Types of Scaling Policies  Target Tracking  The simplest and most commonly used. You set a target metric value — for example, keep average CPU at 50% — and AWS adds or removes instances to maintain it. You do not define the number of instances to add; AWS figures that out.  Step Scaling  You define rules: if CPU is between 70% and 80%, add 1 instance. If CPU is above 80%, add 3 instances. More granular control, slightly more configuration.  Scheduled Scaling  If your traffic patterns are predictable — higher during business hours, lower at night — you can schedule capacity changes. Scale up to 10 instances at 8 AM, scale down to 3 at 11 PM. No metric triggers needed.  What Auto Scaling Does Not Fix  Auto Scaling helps with stateless compute. It does not help if your bottleneck is the database. If your RDS instance is maxed out during traffic spikes, adding more EC2 instances will not help — they will all queue up waiting for the database.  A proper scaling architecture addresses each tier: compute, database (read replicas, connection pooling), and caching (ElastiCache to absorb repetitive queries).  Real-World Impact  A typical e-commerce application running 10 instances at all times costs roughly the same as one that scales between 3 instances at night and 10 at peak — but the flat configuration wastes 70% of its compute budget overnight.  With Auto Scaling, you pay for what you use. For businesses with variable traffic — retail, SaaS with working-hours usage patterns, platforms that see seasonal peaks — the savings are substantial.