DEV Community: Alon Shrestha

How EC2 Instance in Private Subnet Connects to the Internet in AWS

Alon Shrestha — Thu, 18 Sep 2025 16:56:10 +0000

Step by Step Workflow of Traffic from NAT Gateway to Internet

Note: This post was originally published on my main blog site.

If you’ve ever launched an EC2 instance in a private subnet, you’ll notice it can’t reach the internet.

But what if your instance needs to connect to external services while still staying private and hidden from the public internet?

That’s where a NAT Gateway comes in.

A NAT Gateway allows private resources to securely access the internet without being exposed to it.

It’s simple to set up, but many AWS engineers get confused about how the traffic actually flows. From an EC2 instance, through the NAT Gateway, and out to the internet.

In this blog, we’ll walk through the step-by-step workflow of how an EC2 instance in a private subnet reaches the internet.

If you prefer a quick visual walkthrough, here’s a short video explanation:

Creating NAT Gateway in AWS

Before we dive into the workflow, let’s first understand how a NAT Gateway is created.

The most important thing to know is that a NAT Gateway must be created in a public subnet.

A public subnet is simply a subnet that has an Internet Gateway (IGW) in its route table.

Without a public subnet you cannot create a NAT Gateway because the NAT Gateway ultimately relies on the Internet Gateway to reach the internet.

So, when you create a NAT Gateway in a public subnet, AWS automatically provisions an Elastic Network Interface (ENI) with both a private IP and a public IP.

The private IP comes from the CIDR range of the public subnet you selected. This is very similar to how an EC2 instance receive IP address.

Once the NAT Gateway is created, it can be linked to a route table.

Any subnet that uses this route table will function as a private subnet, because its traffic will be routed through the NAT Gateway.

💡 Interested in optimizing AWS costs? This article breaks down AWS data transfer pricing.

Traffic Flow from NAT Gateway to the Internet

Now let’s understand how traffic flows from an EC2 instance in a private subnet to the internet using the figure below.

Suppose a private EC2 instance wants to reach google.com. The traffic first leaves the EC2, but it can only do so if the Security Group attached to the instance allows outbound traffic.

After passing through the Security Group, the traffic must also pass through the private subnet’s Network Access Control List (NACL). Just like Security Groups, the NACL must allow outbound traffic to 0.0.0.0/0.

Since google.com is outside the VPC, the instance uses the private subnet’s route table to determine the path. To reach the internet, the route must send traffic to 0.0.0.0/0 via the NAT Gateway.

Once these checks are satisfied, the traffic reaches the NAT Gateway.

The NAT Gateway translates the private IP of the EC2 instance into its own public IP, hiding the original private address.

At this point, the traffic moves toward the internet. But the NAT Gateway itself resides in a public subnet, so the request must also pass through the public subnet’s NACL and route table, which must have a route 0.0.0.0/0 → Internet Gateway.

Only after passing these checks, the request reach the Internet Gateway and go out to the internet.

📝 Key point: The NAT Gateway depends on the public subnet’s NACL and route table.

Any changes to these configurations can break internet access not only for resources in the public subnet but also for all private subnets relying on the NAT Gateway.

I hope this gives you a clear understanding of how traffic flows from a NAT Gateway to the internet.

Thanks for reading.

– Alon

AWS Spot Instances: Maximize Savings, Minimize Interruptions

Alon Shrestha — Thu, 04 Sep 2025 14:27:20 +0000

Note: This post was originally published on my main blog site.

AWS claims that Spot Instances can save you up to 90% compared to On-Demand pricing.

But here’s the real question:

Do you always save 90% with Spot Instances?

Not quite. That 90% is the maximum possible discount and not a guaranteed discount.

In reality, most users save around 50% to 70%, and only a few manage to reach 80% or more. However, with a solid understanding of how Spot Instances work and the right strategies in place, you can get much closer to that 90% mark.

In this post, we’ll explore:

What Spot Instances are
How Spot pricing works and ways to maximize savings
Strategies to minimize interruptions

What are Spot Instances?

AWS has a large pool of servers for its customers. When demand is low, some of these servers remain unused. These spare servers are offered as AWS Spot Instances. Instead of leaving them idle, AWS makes them available at a much lower price, up to 90% cheaper than On-Demand.

There’s no difference in how they run. A Spot Instance is the same EC2 instance you’d get with On-Demand.

The only difference is:

If AWS needs that capacity back when demand rises, your Spot Instance gets interrupted and the capacity reassigned to customers paying the regular price.

Then what happens to your EC2 instance?

By default, AWS will terminate your Spot Instance during an interruption, which means any data stored on the instance will be lost. To control this behavior, you can configure the interruption action to either stop, hibernate, or terminate the instance based on your needs.

Learn more about Spot Instance interruption behavior.

Truth About “Up to 90%” Savings

AWS advertises Spot Instances as “up to 90% cheaper” but that doesn’t mean you will get 90% off on every Spot Instance you launch.

Spot Instance prices aren’t fixed. They change frequently based on region, instance type, and demand.

Before launching a spot instance, you can check its potential savings by viewing its price history in the AWS Console:

EC2 > Spot Requests > Pricing History

us-east-1a

us-east-1d

This shows how Spot prices have changed over the last 3 months, updating every minute. Each instance type and Availability Zone (AZ) may have different prices.

For example, us-east-1a vs us-east-1d:

c5d.18xlarge: ~57% vs ~64% savings
c6gd.2xlarge: ~83.6% vs ~85% savings
m8i.metal-96xlarge: ~89.99% vs ~89.98% savings

These differences are driven by supply and demand. You always pay the current market price for that capacity.

Also note: Spot pricing today is more predictable than in the past. Before 2017, AWS used a bidding system where prices spiked rapidly, but now Spot follows a smoother demand-based model.

To get more value out of Spot Instances, try these approaches:

Use newer instance generations
Newer families often have more unused capacity, which translates into higher discounts and fewer interruptions.
Spread across multiple Availability Zones (AZs)

The same instance type can have different Spot prices depending on the AZ. By running across multiple zones, you increase your chances of finding cheaper pools.
Setting maximum price
While setting maximum price when launching a Spot Instance can help control costs. However, it’s no longer recommended, as it often increases the chance of interruptions.
Price capacity optimized allocation strategies
You can choose the price capacity optimized strategy when running a fleet of Spot Instances. AWS automatically identifies instance pools with the highest availability (i.e., lowest chance of interruption) and, among those, selects the one with the lowest price.

Strategies to Minimize Interruptions

Spot Instances should only be used for applications that can tolerate faults. Even then, frequent interruptions can impact your business.

Since interruptions occur when AWS needs capacity back, here are strategies to reduce their impact:

AWS Spot Instance Advisor

The Spot Instance Advisor provides the frequency of interruptions for different instance types. A higher frequency indicates a higher chance that your instance will be interrupted, helping you choose instances with fewer disruptions.

Recommended to use instance type with <5% frequency of interruption.

Capacity-Optimized Allocation Strategy

It's best to use Spot Instances with an Auto Scaling Group or EC2 Fleet. This helps manage interruptions more effectively and keeps your applications running smoothly.

To improve reliability even further, you can use the Capacity-Optimized Allocation Strategy.

This AWS feature selects Spot Instance pools that are less likely to be interrupted, giving you better stability.

Learn more about Capacity-Optimized Allocation Strategy.

Spot Instance interruption notices

AWS provides a 2-minute interruption notice before reclaiming capacity. You can capture this signal from instance metadata or EventBridge to gracefully stop workloads, checkpoint data, or shift traffic.

Learn more

With Spot Instances, cost savings and interruption risk are a tradeoff. It is not always easy to achieve both at the same time. The key is to use the right strategies: monitor pricing trends, choose low interruption pools, diversify across instance types and Availability Zones, and design workloads that can tolerate failures.

When applied correctly, Spot Instances can deliver near maximum savings while still keeping your applications reliable.

I hope this page has made you clear about AWS Spot Instances.

Thanks for reading.

- Alon

AWS Free Tier (2025): What's Free & For How Long

Alon Shrestha — Sun, 03 Aug 2025 13:59:25 +0000

AWS Free Tier feels like a myth until you understand the rules

Note: This post was originally published on my main blog site.

You saw “Free Tier” and spun up a few services. It looked safe and simple.

But at the end of the month?

Surprise charges. Confusion. Frustration.

// Detect dark theme var iframe = document.getElementById('tweet-1854506750415921294-559'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1854506750415921294&theme=dark" }

That’s when many realize: maybe AWS Free Tier is just a myth after all.

But here's the truth, AWS Free Tier isn’t a myth. It has limits, and those limits are often misunderstood.

Some are time-based and some are usage-based.

This guide clears up that confusion, so you know exactly what to expect before you get billed.

Recently, AWS upgraded its Free Tier offerings, introducing changes that took effect after July 15, 2025.

In this guide, we’ll cover both the previous Free Tier plan (before July 15) and the updated one, so you have a full picture.

Free Tier Plan Before July 15, 2025

This image was generated using Google AI Studio.

If your AWS account was created before July 15, 2025, AWS offers three types of Free Tier plans:

12 Months Free
Always Free
Short-Term Trials

12 Months Free

This plan gives you access to some of AWS’s most popular services like EC2, S3 for free for the first 12 months after you create your account. After that, standard pay-as-you-go pricing applies.

Even during the free 12 months, there are limits, and if you go beyond them, you’ll be billed.

Take EC2, for example:

AWS lets you run a t2.micro or t3.micro EC2 instance for free, up to 750 hours per month.
You can launch multiple instances, but their total combined usage must not exceed 750 hours in a month.
For example, if you run 2 instances, you can only use each one for up to 375 hours (750 ÷ 2) to stay within the free limit.
Also, launching EC2 instance requires:
- Amazon Machine Image (AMI): If you choose a paid AMI from the AWS Marketplace, you will be charged for it.
- EBS volume. The Free Tier gives you 30 GB of EBS per month. If you exceed that, you will be billed for the extra usage.

After 12 months, the Free Tier ends automatically and your account switches to standard pay-as-you-go billing, even though you may still see the Free Tier label when selecting a t2.micro instance.

Always Free

This plan includes services that are free forever, not just for the first 12 months.

Examples:

AWS Lambda: 400,000 GB-seconds of compute time per month.
Amazon SQS: 1 million requests per month.
And other more services.

These limits reset at the beginning of each month.

If you exceed these limits, you'll be charged according to standard pay-as-you-go pricing.

Short Term - Trial

This plan is different from the 12 Months Free and Always Free tiers. It usually applies to newly launched services that AWS wants customers to try. These offers are time-bound trials and only start after you activate the service.

Example:

Amazon Inspector gives you a 15-days free trial.
After you enable it, the trial starts.
Once the trial ends, you’ll be charged based on standard pricing.

AWS doesn’t notify you when a trial period ends. To avoid unexpected charges, make sure to stop or terminate any trial-based resources before the period expires.

Free Tier Plan After July 15, 2025

This image was generated using Google AI Studio.

After July 15, 2025, AWS updated its Free Tier offerings. While the Always Free and Short-Term Trial plans remain the same, the previous 12 Months Free plan has been replaced with two new categories:

Free Plan (New)
Paid Plan (New)
Always Free
Short-Term Trials

Free Plan (New)

This plan replaces the previous "12 Months Free" plan. Instead of giving you monthly usage limits, AWS now provides $200 in free credits.

You get $100 in credits when you create your account.
You can earn another $100 by exploring more AWS services.

This plan supports more features but has limited services available. For example, you can launch EC2 instances with types like T3.micro, T3.small, T4g.micro, T4g.small, C7i-flex.large, and M7i-flex.large.

Even though you're required to enter your payment details when creating the account, you won’t be charged even if you exceed your credits. Instead, AWS will suspend your account while still retaining your data, giving you the option to upgrade to a paid plan later.

The plan is valid for 6 months or until you use up the $200, whichever comes first. It's ideal for students, startups, and new users who want to try AWS without risk.

You can switch to the Paid Plan anytime, either after your credits expire or earlier if you're ready to build real production workloads.

→ Make sure to read the Free Tier FAQ. It answers most common questions clearly.

Paid Plan (New)

This plan is similar to the Free Plan but is designed for real production workloads.

You’ll still receive $200 in free credits and your account will not be suspended when the credits run out or after 6 months.

Instead, once you exceed the $200 credit limit, you’ll start receiving bills based on standard AWS pricing.

Think of this as a regular AWS account where you can access all AWS services just like any other paying customer.

💰 Looking to cut AWS costs? Don’t miss this guide: [15 AWS Native Tools to Master Cost Optimization].

Ways to Find Free Tier Plan for AWS Services

Official AWS Free Tier Page

Start by visiting the official AWS Free Tier page. It gives you a comprehensive overview of all services available under Free Tier, categorized into Always Free, 12-Month Free, and Trials.
Service-Specific Documentation

Check the pricing section in each service’s documentation. It clearly outlines both standard pricing and Free Tier eligibility, if available.
AWS Console Resource Launch

When creating resources in your AWS account, some services display Free Tier eligibility before launching. This is useful for verifying if the service you’re about to use is covered.

Free Tier Usage Dashboard

Inside your AWS account, go to Billing and Cost Management → Free Tier. This dashboard shows how much Free Tier usage you've consumed per service, including remaining quotas.

Understanding how AWS Free Tier works helps you make the most, even for production use. In the end, every business aims to reduce cloud costs.

For beginners, the Free Tier is a great way to learn AWS. I have been there myself, running small projects using EC2, S3, and Lambda to build real-world applications without spending a single penny.

I hope this clears up your confusion about the AWS Free Tier.

Thanks for reading.

- Alon

15 AWS Native Tools to Master Cost Optimization

Alon Shrestha — Sun, 20 Jul 2025 16:14:42 +0000

You don’t need third party tools to master AWS cost optimization.

Note: This post was originally published on my main blog site.

AWS often feels expensive, and it usually is if you don’t know what you're spending on.

But the top companies like Netflix and Airbnb have shown that with the right visibility and practices, it’s possible to achieve the best ROI on cloud spending.

This is possible if you have dedicated FinOps teams focused on monitoring and optimizing costs using advanced tools and strategies.

However, for most organizations, cloud costs are complex, and they may not have the expertise or budget to use advanced tools.

This post focuses on native AWS tools that can help you gain visibility, optimize, and set controls to manage your cloud spend effectively.

I’ll list and briefly explain them, categorizing them according to the FinOps phases: Inform, Optimize, and Operate, for better clarity.

If you're not familiar with the FinOps lifecycle, I recommend reading following first before moving on.

→ Understanding FinOps Lifecycle and Implementing it in AWS

This image was generated using Google AI Studio.

Phase: Inform

In this phase, we explore AWS tools that offer cost visibility, helping us understand where the spending is happening and how much is being spent.

Cost Explorer

Cost Explorer helps you visualize your AWS spending with easy-to-read graphs.

You can see how much you’re spending, which services cost the most, and spot daily or monthly trends.

The tool is free, updates daily, and allows you to export data as CSV for further analysis

Where to find it:

AWS Console → Billing and Cost Management → Cost Explorer

Cost and Usage Report (CUR 2.0)

This tool provides all the detailed billing and usage reports you'll ever need.

The reports are comprehensive and delivered in CSV format, automatically saved to your S3 bucket.

A key feature is its ability to breaks down costs by time (hourly, daily, monthly), service, resource, and custom tags, giving you full visibility into your AWS usage.

To access this report, you’ll need to create a job.

How to create it:

AWS Console → Billing and Cost Management → Data Exports → Create export

Once the report is available, you can analyze it more effectively using tools like Amazon QuickSight, or query it with Athena or Redshift for deeper insights.

Cost Categories

AWS Cost Categories help you organize your cloud spend by grouping costs based on accounts, services, tags, regions, charge types, and more.

You can define custom rules to group expenses by business units, projects (like tag Project = ProjectA), or services (like EC2 and S3). This gives you a clear view of where your costs are coming from.

How to access:

AWS Console → Billing and Cost Management → Cost Categories

Cost Allocation Tags

Cost Allocation Tags help you track and organize AWS costs by assigning labels to your resources(EC2, Snapshot, RDS etc).

These tags can be custom labels that reflect business details such as environment, owner, or project.

There are two types:

User-defined tags (e.g., Environment=PROD)
AWS-generated tags (like aws:createdBy)

To use these tags in billing and reports, you must activate them so they appear in tools like Cost Explorer or AWS Budgets.

AWS Console → Billing and Cost Management console → Cost Allocation Tags.

Example:

Tag your resources with Environment=DEV, STAGE, or PROD. Once activated, you can filter and analyze costs by environment making it easier to allocate costs to projects or teams and improve visibility.

AWS Budget

With AWS Budgets, you can set custom budget limits for cost utilization. When thresholds are exceeded, you get alerts, and optionally, you can automate actions using Lambda.

AWS Console → Billing and Cost Management → Budgets

You can start with pre-built templates or create custom budgets based on your needs.

Common Use Cases:

Alert when monthly AWS bill exceeds $10,000 (trigger at 80%, 100%, or forecasted).
Notify if EC2 instance hours exceed $1,000 per month.
Track cost for resources tagged Environment:Dev, and alert if over $5,000.
Enforce action: Deny ec2:RunInstances using an IAM policy via SNS + Lambda if cost exceeds $30,000.

AWS Cost Anomaly Detection

AWS Cost Anomaly Detection uses machine learning to automatically detect unusual spikes in your AWS spending, helping you catch unexpected cost increases early.

When an anomaly is detected, you receive alerts, along with insights into what caused it, where it occurred, and why.

The system checks for anomalies three times daily, and detection/reporting may take up to 24 hours.

Phase: Optimize

In this phase, we’ll explore AWS tools that help optimize compute and storage resources.

Since optimization is the first step toward achieving cost savings in FinOps, these tools play a critical role in driving meaningful changes.

Saving Plans(SPs) and Reserved Instances(RIs)

Savings Plans offer up to 72% savings on compute services like EC2, Fargate, and Lambda.

You agree to spend a fixed amount per hour (for example, $75/hour) for 1 or 3 years. In return, AWS gives you lower prices.

It is flexible because you do not need to commit to a specific instance type, operating system, or region.

Example:

If you usually run EC2 instances that cost $75/hour at On-Demand rates, you can commit to that same $75/hour spend through a Savings Plan. AWS will then charge you less for that usage, often around 30 to 70 percent cheaper, depending on the plan and term.

But once you commit, you must pay that amount whether you use it fully or not.

Reserved Instances also provide long-term savings similar to Savings Plans, but with less flexibility. You must commit to specific instance attributes (type, OS, region, tenancy).

Example:

If you run 3 EC2 t3.large instances 24/7 in one region, On-Demand costs about $7,200 per year.

With Reserved Instances, you commit to those instances for 1 year and pay around $1,800 to $3,600, saving up to 75%.

But you must stick to the same instance type, region, and OS, and pay whether you use them or not.

You can buy RI for EC2 instances, RDS, ElastiCache, Redshift and OpenSearch.

AWS Console → Billing and Cost Management

Spot Instances

Spot Instances let you use EC2 compute capacity at up to 90% discount compared to On-Demand prices.

This discount is possible because you're using AWS’s unused EC2 capacity.

However, Spot Instances can be interrupted at any time when AWS needs the capacity back. That's why Spot Instances are ideal for fault-tolerant and flexible workloads.

AWS EC2 Auto Scaling Groups

While EC2 Auto Scaling might not appear to be a cost-saving feature at first, it can actually help reduce costs by automatically adjusting your EC2 capacity based on real-time demand.

You define minimum, desired, and maximum instance counts to match your workload.

However, poor configuration can lead to over-scaling (higher costs) or under-scaling (performance issues).

Properly tuned, Auto Scaling ensures you only pay for the compute you actually need avoiding over-provisioning.

AWS Console → EC2 → Auto Scaling groups

AWS Compute Optimizer and Trusted Advisor

AWS Compute Optimizer helps you right-size compute resources like EC2, Auto Scaling groups, EBS, Lambda, RDS, and ECS on Fargate by analyzing historical usage.

It provides cost and performance recommendations, such as:

Flagging EC2 instances as underutilized, over utilized, or optimized.
Suggesting EBS volume changes in IOPS, throughput, type or storage size.

AWS Console → AWS Compute Optimizer

AWS Trusted Advisor offers a broader view. It audits your AWS environment for cost, security, performance, fault tolerance, and service limits.

It helps reduce costs by identifying idle, unassociated, or unused resources that can be safely removed or downsized.

AWS Console → AWS Trusted Advisor

AWS Cost Optimization Hub

AWS Cost Optimization Hub is a new tool that acts as a centralized dashboard that helps you discover and manage cost-saving opportunities across your entire AWS organization.

It provides recommendations on cost optimization, such as EC2 rightsizing, Graviton migration, Idle resource cleanup, RDS and Aurora optimization, Reserved Instances and Savings Plan suggestions and more.

It quickly answers key questions like:

How much can I save by rightsizing resources?
Which account has the most unused or costly resources?
What are the top actions I should take right now to reduce costs?

AWS Console → Billing and Cost Management → AWS Cost Optimization Hub

S3 Storage Lens

It’s a central dashboard that gives you full visibility into your S3 usage and activity across all AWS accounts.

With its built-in metrics, you can easily spot issues like incomplete multipart uploads, too many noncurrent versions, missing lifecycle rules, and fast-growing buckets all of which help you save money on S3.

Phase: Operate

In this phase, we focus on tools and services that help control cloud costs through governance and policy enforcement.

AWS Organization

AWS Organizations is a powerful tool for managing multiple AWS accounts. It lets you consolidate billing across all accounts into a single central account, making it easier to track and pay for usage. You can also apply policies, automate tasks, and manage access centrally across all linked accounts.

Service Control Policies (SCPs)

This tool lets you create rules that apply across all AWS accounts in your organization. These rules help you control what services and actions users can use.

For cost optimization, you can:

Block expensive instance types like p, u, or x families.
Prevent users from creating resources in unwanted regions.
Allow only Spot Instances in development accounts.

SCPs work like IAM policies, so you can write custom rules to fit your needs.

Tag Policies

Tag Policies enforce consistent tagging across AWS resources by requiring specific tags during resource creation. This reduces tag clutter, improves cost visibility, and enables accurate cost allocation and tracking.

By leveraging these AWS-native tools, even small teams can gain control over their cloud spend.

The first rule is to start simple: set up budgets, apply tagging policies, and optimize low-hanging resources.

There are other helpful tools such as the AWS Free Tier, AWS Cost Calculator, CloudWatch and more, but I’ve kept things brief for now. I’ll cover those in a separate post.

As we wrap up, I’d love to hear your thoughts or feedback.

Thanks for reading!

- Alon

Apply FinOps Lifecycle in AWS Using Built-in Tools

Alon Shrestha — Tue, 01 Jul 2025 15:46:16 +0000

Note: This post was originally published on my main blog site.

By now, you may already have some knowledge of FinOps, or perhaps you’ve come across the term somewhere.

If not, feel free to check out my post: What is FinOps and Why It Really Matters Today?

Now, coming back to this post.

Progress in any area requires a repeatable process.

Take growing a plant as an example:

You plant the seed, water it, give it sunlight, and repeat the process. With consistent care, the plant grows over time.

Similarly, FinOps is an ongoing journey, not a one-time fix. It evolves as your cloud usage and organization grow.

To see real progress and grow the value of your business through cost optimization, you need to follow a consistent lifecycle.

FinOps Framework

The FinOps Foundation defines its framework in three phases: Inform, Optimize, and Operate. Each cycle builds momentum by enabling better decisions and greater efficiency.

Image source: FinOps Foundation

Let’s break down in brief what each phase is all about.

Inform

The main goal of this phase is to understand your cloud costs.

It's all about gathering information on what resources you have, how they're being used, who is using them, and how much they're costing, using the right tools and techniques.

With this data, you gain clear visibility into your cloud spending and understand the business value of that spend. This helps you plan better for optimization, budgeting, and cost allocation.

Optimize

Once you understand your cloud spending, this phase is about making improvements.

Start by sharing cost reports with both technical and finance teams. Identify unused or underutilized resources, rightsize them, and explore pricing options such as commitment-based savings plans.

If needed, consider re-architecting for long-term efficiency and value as well.

Collaboration between engineering, finance, and business teams is key to success in this phase. Not just focusing on reducing costs but on maximizing the value of your cloud investment.

Operate

You have the data, and you've started optimizing. Now it's time to put these practices into daily operations.

Establish policy rules and governance for cloud usage. Set up monitoring for resource usage and alerts for spending thresholds to ensure compliance.

Educate teams and individuals about cloud cost ownership. Use insights from the Inform phase and strategies from the Optimize phase to create actionable guidelines.

Most importantly, leverage automation to improve efficiency and consistency.

These three phases are ongoing and repeat over time. As your organization grows, the process should evolve to drive continuous improvement and better outcomes.

AWS Cloud Financial Management Framework (CFM)

Similar to the FinOps framework, AWS has its own Cloud Financial Management (CFM) Framework, which includes four key pillars: See, Save, Plan, and Run.

AWS CFM aligns with the core concepts of FinOps but is designed specifically for the AWS environment, using native tools and services to achieve its goals.

Its primary goal is to help customers achieve their business outcomes in the most cost-efficient way, accelerating economic and business value while maintaining the right balance between agility and control.

Image source: AWS

See

This pillar focuses on gaining visibility into where your cloud costs are coming from. It enables the finance team to track spending patterns and hold teams accountable for their usage.

You can get started by implementing a strong AWS tagging strategy and, if using multiple accounts, setting up a structured account hierarchy for achieving cost transparency.

AWS Services: AWS Control Tower, AWS Organizations, Cost Allocation Tags, Tag Policies, AWS Resource Groups, AWS Cost Categories, AWS Cost Explorer, AWS Cost and Usage Report, RIs and SPs

Save

This pillar is about cost optimization through strategic use of pricing models and efficient resource management.

Examples include:

Purchasing Reserved Instances or Savings Plans
Using Spot Instances for fault-tolerant workloads
Scaling efficiently with Auto Scaling Groups
Rightsizing resources
Terminating wasteful and idle resources

AWS Services: RIs and SPs, Amazon EC2 Auto Scaling Groups, Spot Instances, AWS Compute Optimizer, AWS Trusted Advisor, AWS Instance Scheduler

Plan

Once you gain visibility into spending, the next step is forecasting and budgeting. AWS allows you to build flexible, dynamic budgeting processes that help you monitor if spending aligns with expectations.

AWS Services: AWS Cost Explorer, AWS Cost and Usage Report, AWS Budgets

Run

The Run pillar is about operational cost control and governance. It includes setting up guardrails, automating policies, and using monitoring tools to stay within budget and detect anomalies.

AWS Services: AWS Billing and Cost Management Console, AWS Identity and Access Management, Service Control Policies (SCP), AWS Service Catalog, AWS Cost Anomaly Detection, AWS Budgets

→ You may want to know: 15 AWS Native Tools to Master AWS Cost Optimization

Mapping FinOps and AWS CFM Frameworks

To better understand how the FinOps lifecycle aligns with AWS’s Cloud Financial Management (CFM) pillars, I created the following mapping.

This table illustrates how both frameworks complement each other and highlights the AWS-native tools and services that support each phase.

Note: ‘See’ and ‘Plan’ align with the Inform phase.

FinOps Phase	AWS CFM Pillar	Purpose	AWS Services & Tools
Inform	See	Gain visibility into cloud spend and usage	AWS Control Tower, AWS Organizations, Cost Allocation Tags, Tag Policies, AWS Resource Groups, AWS Cost Categories, AWS Cost Explorer, AWS Cost and Usage Report, RIs and SPs
	Plan	Forecast usage, set budgets, and plan financial goals	AWS Cost Explorer, AWS Cost and Usage Report, AWS Budgets
Optimize	Save	Eliminate waste, rightsize, and apply pricing models	RIs and SPs, Amazon EC2 Auto Scaling Groups, Spot Instances, AWS Compute Optimizer, AWS Trusted Advisor, AWS Instance Scheduler
Operate	Run	Manage costs operationally, enforce governance	AWS Billing and Cost Management Console, AWS IAM, Service Control Policies (SCP), AWS Service Catalog, AWS Cost Anomaly Detection, AWS Budgets

I hope you found this information helpful. I'd love to hear your thoughts or experiences in the comments below.

Thank you for reading,

– Alon

Understanding AWS Data Transfer Costs

Alon Shrestha — Thu, 26 Jun 2025 17:18:47 +0000

Note: This post was originally published on my main blog site.

Data transfer costs are often overlooked when developing AWS cloud cost strategies.

Most engineers focus primarily on optimizing storage and compute capacity, assuming that's sufficient for maximum savings. However, data transfer costs can be significant, because AWS's billing for data transfer is complex and opaque.

The lack of transparency makes it difficult to track and understand, causing many customers to miss opportunities for potential savings.

This article explains the general billing principles and provides optimization tips for AWS data transfer.

There are four main ways data can be transferred in AWS:

Data Transfer into AWS (Ingress): Data coming from the internet into AWS.
Data Transfer within AWS: Data transferred within AWS, such as between different AWS services.
Data Transfer out of AWS (Egress): Data transferred from AWS to the internet.
Data Transfer between AWS and On-Premises: Data transferred between AWS and your on-premises infrastructure.

AWS charges these data transfers based on factors such as region, availability zones, service, data transfer volume, and applicable taxes.

Data Transfer into AWS

AWS does not charge for inbound data. This applies to traffic coming into AWS, whether from the internet or your on-premises network.

Instead, the requester (e.g., the user or system initiating the connection) may incur charges based on the medium they use to connect to AWS, such as data packages, ISP fees, or VPN costs.

But here's the twist: Communication is always two-way.

When AWS sends a response to the requestor, that outbound traffic is subject to charges (data transfer out of AWS). We’ll cover these charges in more detail in the next sections.

Data Transfer within AWS

AWS has over 200 services, and many of them can communicate with each other. Data transfer within AWS typically happens in two ways:

A workload making requests to AWS services. (e.g., an app running in EC2 instance accessing S3)
One AWS service making requests to another AWS service. (e.g., Lambda accessing DynamoDB)

Charges for data transfer within AWS depend on the specific scenario and location of the resources. Let’s look at different situations:

Data Transfer within AWS in Same Region

When data is transferred within the same region, you’ll typically incur lower charges than for cross-region data transfer. Here are some key points:

Same Availability Zone with Private IPv4 and IPv6: Data transfer between compute resources like EC2 or containers within the same Availability Zone (AZ) using private IPv4 or v6 is free.
Same Availability Zone with Public IP and Elastic Ip: When data is transferred using Public IP or Elastic IP, even within the same AZ and VPC, data transfer costs apply for both sending(egress) and receiving(ingress).
Same Availability Zone with Different VPC: Data transfer is free if traffic stays within the same AZ and uses private IPs over VPC Peering.
Different Availability Zone: Data transfer between different AZs and VPCs, regardless of the network type(private or public), incurs charges for both ingress and egress. This type of cost is called Bi-direction data transfer.
- For example, if an EC2 instance makes a request to an RDS instance in a different AZ, you will incur charges for: EC2 data out, RDS data in, RDS data out, and EC2 data in.
Load Balancer: Data transfer between a Classic Load Balancer or an Application Load Balancer and EC2 instances across AZs within the same region is free.
Multi-AZ Replication: Data transfer between multiple AZs for replication purposes, such as with Amazon RDS, is free within the same region.
NAT Gateway: When a compute resource (e.g., EC2 instance or container) accesses AWS services like S3, SQS, SNS, or ECR through a NAT Gateway, there are charges for both the NAT Gateway and the data processed by the gateway before being sent to the destination. However, accessing these services via a Public IP or VPC Endpoint is free, with costs only applying for the Public IP or VPC Endpoint usage.
CloudFront: Data fetches from origin like EC2, S3, or ELB to CloudFront is free.
Route53: The Alias record type in Amazon Route 53 is free of charge, unlike other record types such as CNAME, A, and AAAA, which incur costs for DNS queries.

Data Transfer within AWS in Different Region

Data transfer across regions using VPC Peering or Transit Gateway is charged based on the source region. For example, data transfer from US West (N. California) costs $0.02/GB, from Ohio costs $0.01/GB, while transfers from US East (Verizon) - Nashville and Tampa are free.

If you pull data from an S3 bucket located in the US West (N. California) region, the cost will be $0.02/GB.

Data transfer out of AWS

AWS provides 100 GB of free data transfer from AWS to the internet each month for all customers. This allowance applies across all services and regions, excluding China and AWS GovCloud.

Any data transfer beyond this 100 GB is charged based on the service, region, and amount of data transferred.

Data Transfer between AWS and On-Premises

You can connect to AWS from on-premises using either site-to-site VPN or direct connect.

Site-to-Site VPN

When you set up a Site-to-Site VPN connection, AWS charges for the time the VPN connection is active, based on hourly rates.

In addition, you'll incur standard AWS data transfer charges for any data sent over the VPN connection.

Data transfer into AWS is free.
Data transfer out from AWS is charged based on the amount of data transferred from AWS to your on-premises infrastructure.

For example, if you transfer 1,000 GB into AWS and 500 GB out, you'll only be charged for the 500 GB transferred out of AWS.

Direct Connect

AWS Direct Connect charges are based on three main factors:

Data Transfer Capacity: The maximum transfer rate of the connection.
Port Speed and Port Hours: The speed of the connection and the duration for which the port is provisioned.
Connection Type:
- Dedicated Connection: A physical connection between your on-premises network and AWS.
- Hosted Connection: A logical connection provided by an AWS Direct Connect partner, typically more affordable than dedicated connections.

Like Site-to-site VPN, data transfer into AWS via Direct Connect is free.

Ways to Save on Data Transfer in AWS

Use VPC Endpoints: Avoid routing traffic over the internet when accessing AWS services. VPC Endpoints are generally more cost-effective, reduce latency, and keep traffic within AWS's private network.
Avoid Public IP or Elastic IP: Even when transferring data within the same Availability Zone (AZ) and region, using Public IPs or Elastic IPs incurs charges. Stick to private IPs to avoid extra costs.
Use Direct Connect for On-Premises Transfers: For transferring data to on-premises infrastructure, consider using Direct Connect. This option is more cost-effective than using the internet for large-scale data transfer.
Stay Within the Same AZ When Possible: While multiple AZs provide high availability, keeping your resources within the same AZ can save costs on cross-AZ data transfer.
Avoid Cross-Region Data Transfers: Transferring data between AWS regions typically incurs additional charges. Only transfer data across regions if it's absolutely necessary for your business requirements.
Avoid NAT Gateways When Possible: While NAT Gateways provide secure access to AWS services, they come with high data processing costs. Instead, use custom NAT Instance where possible to reduce costs.
Consider Amazon CloudFront: When transferring data to internet users, Amazon CloudFront is usually cheaper than transferring data directly from AWS regions. It also reduces latency for global content delivery.
Choose Cost-Effective Regions: Data transfer pricing varies by region. If you don’t have strict compliance or latency requirements, choose the most cost-effective region for your workloads.
Use S3 Requester Pays: If you store large objects in Amazon S3 and other AWS accounts need to access them, you can enable the Requester Pays feature. This feature shifts the cost of downloading the objects from the bucket owner to the requester. The requester must be a valid AWS account holder (not an anonymous user) in order to incur the download costs.
Sign Up for the AWS Data Transfer Private Pricing Program: If your organization has significant data transfer needs, enroll in the AWS Data Transfer Private Pricing Program to negotiate better rates based on your usage.
Use Monitoring Tools: Leverage tools like AWS Cost & Usage Reports or third-party monitoring tools to track your data transfer costs and identify areas where you can optimize.

I hope this article was helpful to you. Please share your feedback in the comments below.

Thanks for reading,

-Alon

What is FinOps and Why It Matters in Cloud Era?

Alon Shrestha — Wed, 18 Jun 2025 16:56:58 +0000

Note: This post was originally published on my main blog site.

According to Precedence Research, 96% of organizations use at least one cloud service, and the cloud market is projected to surpass $1 trillion by 2028. Organizations are investing heavily in technology, and a significant portion of that spend is going to the cloud.

For instance, estimates suggest that Netflix pays approximately $115 million annually to AWS, Pinterest spends between $190 million and $225 million per year, and Snapchat allocates around $400 million annually to AWS services.

These costs are expected to grow each year and that’s where the real challenge lies.

CLOUD COST MANAGEMENT

Cloud spending has become a hot topic. 75% of organizations report that around 32% of their cloud budget goes to waste. This waste can be controlled and optimized, but the bigger issue is that nearly half struggle with it due to a lack of knowledge, tools, or strategy.

And this is exactly where FinOps comes in.

FinOps focuses on optimizing cloud resources for efficient usage and implementing governance to gain visibility into spending so costs can be controlled effectively.

What is FinOps?

Many people mistakenly believe that FinOps is just about cutting costs through resource optimization, but that is not true.

As per the FinOps Foundation,

FinOps is an operational framework and cultural practice which maximizes the business value of cloud and technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams.

After working in this field for a while, I see it as a set of principles that delivers business value aligned with cloud spending. It involves team collaboration, cost visibility, resource optimization, forecasting, and governance.

In the early days, FinOps focused on maximizing business value from cloud provider spending. But today, it’s scope has extended beyond just cloud and includes AI, SaaS platform, and increasingly, any technology-related spend.

Key Principles of FinOps

FinOps isn’t just about saving money. It’s about making cloud spend meaningful. Here’s how it works in practice:

Imagine a product engineering team builds a new feature that needs extra cloud resources. During testing, they spin up resources, and the DevOps team adds auto-scaling and CI/CD pipelines to streamline deployment.

But no one informs finance, and there’s no cost estimate shared.

By the next billing cycle, the finance team sees a spike in the cloud bill but has no context. They don’t know what caused it, and the engineering team isn’t sure either.

This disconnect between teams is common in cloud environments, often leading to finger-pointing, delayed responses, and sometimes wasted budget.

This is where FinOps steps in to bring clarity and alignment.

By fostering collaboration between engineering, DevOps, and finance, FinOps helps teams understand the financial impact of their decisions.

It enables them to optimize usage and take ownership of their spending.

Ultimately, it ensures that every cloud dollar is used with intention and delivers meaningful business value.

Core Principles of FinOps:

Collaborate Early Across Teams: Finance, engineering, and operations work together early to plan and estimate cloud costs.
Own What You Use: Each team is responsible for their own cloud usage and understands what they are spending and why.
Optimize Continuously: Teams reduce waste by rightsizing and automating resources.
Get Timely Insights: Regular cost reports help engineering teams adjust quickly and support finance teams in forecasting.
Set Clear Policies: Clear policies and rules keep cloud usage in check and prevent budget surprises.

Why FinOps Matters in the Cloud Era?

In traditional IT environments, hosting an application often required overestimating server capacity. Companies would invest significant upfront capital in hardware that frequently went underutilized.

Cloud computing eliminates this burden. It allows organizations to provision exactly the resources they need, when they need them, using a consumption-based pricing model.

Although cloud computing simplifies operations, it also introduces new challenges, particularly in cost visibility and control.

One reason cloud costs are often opaque is the pay-as-you-go pricing model, which fluctuates based on usage. This variability makes it difficult to predict monthly bills and complicates financial planning.

Many cloud services include hidden costs, such as charges for data transfer, API requests, software licenses, and managed service fees. These charges often go unnoticed until they appear unexpectedly on the invoice.

Beyond pricing complexity, many cost-related issues also stem from within the organization. A lack of governance can lead to overspending due to unused resources that continue running.

Unless there is a dedicated FinOps role focused on cost management, most employees remain focused on their individual tasks and often overlook the broader impact of cloud spending.

This results in delays in identifying which teams, projects, or services are driving costs, making it challenging to manage expenses effectively.

Also, missing opportunities to optimize pricing, such as leveraging Reserved Instances, Savings Plans, or right-sizing resources.

With these issues, business spending on the cloud delivers poor return on investment (ROI).

FinOps bridges these gaps by enabling shared accountability, real-time insights, and proactive cost management, turning cloud spend into a strategic advantage rather than a blind expense.

Getting Started with FinOps

Gain Visibility

Begin by collecting and organizing cloud spending data. Know where every penny goes. Organize data in a way that provides insights from finance, tech, and business views. Use resource tagging, and look for high-cost drivers, usage patterns, and unusual spikes.

Enable Collaboration and Ownership

Once you have the data, bring finance, engineering, and operations together. Help teams see that cost is a shared responsibility. Work together to build a strategy for optimization and accountability.

Set Up Reporting

Transparency is key. Create dashboards and reports to give every stakeholders real-time visibility into cloud costs.

Start Small and Scale

Don’t try to fix everything at once. Start with one team or service. Learn, show results, and scale gradually. FinOps is a journey, not a one-time fix.

Learn and Implement

Research how other organizations implement FinOps. Study real examples and apply what works to your environment.

Want to dive deeper?

→ Learn the FinOps lifecycle and how you can implement it in AWS using its built-in tools.

→ 15 AWS Native Tools to Master AWS Cost Optimization.

I hope you found this post helpful. I’m diving deeper into FinOps and working to grow in this space. This is my first post on the topic, and I’d love your feedback.

Follow me on my FinOps journey. Let’s learn and grow together!

Thanks for reading,

-Alon

DEV Community: Alon Shrestha

How EC2 Instance in Private Subnet Connects to the Internet in AWS

Creating NAT Gateway in AWS

Traffic Flow from NAT Gateway to the Internet

AWS Spot Instances: Maximize Savings, Minimize Interruptions

What are Spot Instances?

Truth About “Up to 90%” Savings

Strategies to Minimize Interruptions

AWS Spot Instance Advisor

Capacity-Optimized Allocation Strategy

Spot Instance interruption notices

AWS Free Tier (2025): What's Free & For How Long

Free Tier Plan Before July 15, 2025

12 Months Free

Always Free

Short Term - Trial

Free Tier Plan After July 15, 2025

Free Plan (New)

Paid Plan (New)

Ways to Find Free Tier Plan for AWS Services

Official AWS Free Tier Page

Service-Specific Documentation

AWS Console Resource Launch

Free Tier Usage Dashboard

15 AWS Native Tools to Master Cost Optimization

Phase: Inform

Cost Explorer

Cost and Usage Report (CUR 2.0)

Cost Categories

Cost Allocation Tags

AWS Budget

Common Use Cases:

AWS Cost Anomaly Detection

Phase: Optimize

Saving Plans(SPs) and Reserved Instances(RIs)

Spot Instances

AWS EC2 Auto Scaling Groups

AWS Compute Optimizer and Trusted Advisor

AWS Cost Optimization Hub

S3 Storage Lens

Phase: Operate

AWS Organization

Service Control Policies (SCPs)

Tag Policies

Apply FinOps Lifecycle in AWS Using Built-in Tools

FinOps Framework

Inform

Optimize

Operate

AWS Cloud Financial Management Framework (CFM)

See

Save

Plan

Run

Mapping FinOps and AWS CFM Frameworks

Understanding AWS Data Transfer Costs

Data Transfer into AWS

Data Transfer within AWS

Data Transfer within AWS in Same Region

Data Transfer within AWS in Different Region

Data transfer out of AWS

Data Transfer between AWS and On-Premises

Site-to-Site VPN

Direct Connect

Ways to Save on Data Transfer in AWS

What is FinOps and Why It Matters in Cloud Era?

What is FinOps?

Key Principles of FinOps

Core Principles of FinOps:

Why FinOps Matters in the Cloud Era?

Getting Started with FinOps