Author name: Shivam Pokhriyal

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. 

S3 is easy to start with — you create a bucket, upload files, and you are done. The problem is that S3 Standard, which is what most people use by default, costs about 3x more than it needs to for data you are not actively reading.  AWS has six S3 storage classes. Using the right one for each type of data is one of the fastest ways to cut your cloud storage bill.  The Six Storage Classes  Storage Class  Use Case  Retrieval Time  Cost (per GB/month)  S3 Standard  Frequently accessed data  Milliseconds  ~$0.023  S3 Intelligent-Tiering  Unknown or variable access patterns  Milliseconds  ~$0.023 + monitoring fee  S3 Standard-IA  Infrequently accessed, needs fast retrieval  Milliseconds  ~$0.0125  S3 One Zone-IA  Infrequent access, can tolerate single-AZ  Milliseconds  ~$0.01  S3 Glacier Instant  Archival data accessed occasionally  Milliseconds  ~$0.004  S3 Glacier Flexible  Archival data, retrieval can wait  Minutes to hours  ~$0.0036  S3 Standard: When to Use It  For data that is read frequently — application assets, user uploads that are accessed in real time, static website files, database backups you might need today. If you are accessing the data more than once a month, Standard is appropriate.  S3 Intelligent-Tiering: The Easy Win  If you are not sure how often your data is accessed, Intelligent-Tiering monitors access patterns and automatically moves objects between Standard and infrequent-access tiers. There is a small per-object monitoring fee (around $0.0025 per 1,000 objects), but for large buckets with variable access, the storage savings outweigh it.  This is the easiest change to make on existing S3 buckets — enable it via a bucket lifecycle rule without touching your application.  S3 Standard-IA and One Zone-IA  Standard-IA is for data you need quickly when you do need it, but do not access regularly — monthly reports, quarterly exports, compliance documents. The cost is about half of Standard, but there is a retrieval fee per GB.  One Zone-IA stores data in a single Availability Zone, which reduces cost further. Only use it for data you can regenerate or that is already replicated elsewhere. It is not appropriate for backups you cannot afford to lose.  S3 Glacier: Long-Term Archival  Glacier Instant Retrieval costs roughly 80% less than Standard, with millisecond retrieval. It is designed for data you access perhaps once a quarter — old financial records, archived media, historical logs.  Glacier Flexible Retrieval takes minutes to hours. Use it for regulatory archives where you might need the data in a compliance audit but can wait. The cost is minimal.  How to Move Your Existing Data  You do not need to manually move objects. Use S3 Lifecycle policies to automatically transition objects based on age. For example: move objects older than 30 days to Standard-IA, then to Glacier Instant after 90 days.  This runs automatically and requires no changes to your application. The objects stay in the same bucket at the same S3 path. 

For most Indian businesses hosting on AWS, ap-south-1 (Mumbai) is the obvious choice. It is the closest AWS region to the majority of Indian users, which means lower latency for applications, faster database queries, and better performance for end users on the subcontinent.  But choosing the right region involves more than just geography. Here is what actually matters.  Latency: Mumbai vs Other Regions  The difference in latency between Mumbai and other regions is significant for user-facing applications. A web application hosted in ap-south-1 will typically deliver page responses in 20–60ms to users in major Indian cities. The same application in us-east-1 will see 180–250ms.  For a transactional application — e-commerce, fintech, SaaS — that latency difference directly affects conversion rates and user experience.  Data Residency and Compliance  Indian regulations around data residency are evolving. The Digital Personal Data Protection Act (DPDP) has specific requirements around where personal data can be stored and how it can be transferred. Hosting in ap-south-1 keeps your data physically within India, which simplifies compliance for regulated industries including BFSI, healthcare, and government.  RBI guidelines for regulated entities have already mandated Indian data storage for payment systems. If your business falls under similar regulatory frameworks, ap-south-1 is not just a performance choice — it is a compliance requirement.  What ap-south-1 Lacks Compared to US Regions  Mumbai has fewer Availability Zones than us-east-1 (3 vs 6). Some newer AWS services launch in US regions first and arrive in Mumbai months later. Reserved Instance availability and spot pricing can also differ.  This does not make Mumbai a bad choice — it is the right choice for most Indian workloads. But if you are building a globally distributed system that also serves users in the US and Europe, a multi-region architecture with us-east-1 or eu-west-1 as your primary and ap-south-1 as a secondary is worth considering.  Cost Considerations in ap-south-1  AWS pricing in ap-south-1 is slightly higher than in us-east-1 for most services. Data transfer out to the internet costs more per GB. If your application moves large amounts of data — video, large file downloads, media — factor this into your architecture and consider CloudFront as a CDN layer to reduce origin transfer costs.  Our Recommendation for Indian Businesses  Start with ap-south-1 for all production workloads serving Indian users  Use CloudFront to cache static assets globally and reduce latency for users outside India  Enable Multi-AZ for your databases and critical services — ap-south-1 has 3 AZs, which is sufficient for high availability  Review data residency requirements before storing any personally identifiable information  IHA Cloud is based in Chennai and architects AWS infrastructure for Indian businesses every day Contact us at IHACloud to discuss your setup

You cannot manage what you cannot see. In complex AWS environments — multiple services, microservices, databases, queues, and serverless functions — understanding what’s happening at any given moment requires a comprehensive observability strategy.  Monitoring tells you something is wrong. Observability tells you why. The difference can be the gap between a 5-minute incident and a 5-hour outage. At IHA Cloud, observability is built into every production environment we manage.  The Three Pillars of Observability  Metrics — Numeric measurements over time: CPU utilisation, request latency, error rate, queue depth. Metrics tell you the current state of your system.  Logs — Detailed records of events: application errors, access logs, audit trails. Logs tell you what happened and in what order.  Traces — End-to-end visibility into a single request as it flows through multiple services. Traces tell you where time was spent and where failures occurred.  AWS Native Observability Stack  Amazon CloudWatch (Metrics + Logs)  CloudWatch is the core of AWS observability. Every AWS service publishes metrics to CloudWatch automatically.  Key capabilities:  CloudWatch Metrics — Built-in metrics for EC2, RDS, Lambda, ALB, and 100+ services  CloudWatch Logs — Centralised log storage and search for applications and AWS services  CloudWatch Alarms — Trigger alerts or auto-remediation when metrics breach thresholds  CloudWatch Dashboards — Real-time visualisation of infrastructure and application health  CloudWatch Contributor Insights — Identify top contributors to high-volume log patterns  AWS X-Ray (Distributed Tracing)  X-Ray provides end-to-end tracing for distributed applications. When a user request touches API Gateway, Lambda, RDS, and an external API — X-Ray shows you the complete path, latency at each step, and where errors occur.  Essential for: Microservices architectures, serverless applications, and any system where a single user request touches multiple services.  Amazon OpenSearch Service (Log Analytics)  For large-scale log analytics, IHA Cloud deploys OpenSearch — formerly Elasticsearch — to index and analyse logs from across the entire infrastructure. Combined with Kibana dashboards, OpenSearch enables powerful search, pattern detection, and long-term log retention for compliance.  Building an IHA Cloud Observability Framework  Step 1 – Unified Log Aggregation: Ship all application and infrastructure logs to CloudWatch Logs using the CloudWatch Agent or Fluent Bit on ECS/EKS.  Step 2 – Custom Application Metrics: Instrument applications to publish custom CloudWatch metrics — API response times, business events, queue processing rates.  Step 3 – Distributed Tracing: Enable X-Ray on API Gateway, Lambda, and application code to trace requests end-to-end.  Step 4 – Alerting Strategy: Define alert tiers — critical (page immediately), warning (ticket), informational (log only). Avoid alert fatigue by alerting on symptoms not causes.  Step 5 – Dashboards: Build CloudWatch dashboards showing the golden signals for every service: latency, traffic, errors, and saturation.  Step 6 – Runbooks: Every alert links to a runbook that tells the on-call engineer exactly what to check and what actions to take.  See everything. Miss nothing. Talk to IHA Cloud about AWS Observability