Why Amazon S3 Makes More Technical Sense Today (Especially After MinIO’s Shift)

Ishara Niwarthana — Wed, 10 Dec 2025 09:01:22 +0000

For years, MinIO was the easiest way to run S3-compatible storage on your own infrastructure. It provided developers with a familiar API without forcing them to commit to a specific cloud provider. However, with MinIO now in maintenance mode and several features pulled behind commercial licensing, using it for long-term workloads has become increasingly difficult to justify.

From a technical and operational perspective, Amazon S3 simply provides more reliability, better integrations, and a cleaner operational model. Here's a breakdown of what actually matters when choosing between the two.

Operational Load: S3 vs MinIO

Running MinIO means managing everything underneath it:

server capacity
disks and I/O performance
replication between nodes
upgrades and patches
HA configuration
certificates
monitoring and alerting
backup and restoration procedures

S3 removes the entire operational surface.
No cluster design, no storage expansion planning, no tracking disk failures, no manual failover.

This instantly reduces your operational risk and eliminates the "hidden cost" of managing object storage.

Durability and Consistency Guarantees

S3 is designed with multi-AZ replication built into the service. You get:

11 nines durability
strong read-after-write consistency
automatic redundancy
built-in protection against AZ-level failures

Reproducing this with MinIO requires:

multiple nodes
distributed mode
a reliable network layer
external load balancing
proper quorum management

And even then, you won't match AWS's durability guarantees.

Security and Access Control

S3 integrates with AWS security features out of the box:

IAM with fine-grained permissions
Bucket policies and condition keys
KMS-managed encryption
Access logging and CloudTrail auditing
VPC endpoints for private traffic
Object Lock for immutability

With MinIO, these capabilities require manual configuration or external tools. Some features, like Object Lock with legal hold, are not equivalent to the AWS implementation.

Event-Driven and Analytics Integrations

This is where S3 is simply in a different category.

S3 events can trigger:

Lambda functions
SQS queues
SNS topics
EventBridge event patterns
Step Functions workflows

And S3 integrates directly with analytics services such as:

Athena
Glue
EMR
Redshift Spectrum

MinIO can emit notifications, but the overall ecosystem integration is nowhere near as seamless or deeply supported.

Cost Efficiency Through Lifecycle Management

S3 storage classes give you fine-grained control over cost:

S3 Standard
Standard-IA
One Zone-IA
Glacier Instant Retrieval
Glacier Flexible Retrieval
Glacier Deep Archive

Lifecycle policies can automatically transition objects or expire them.

While MinIO can tier data to external storage, it's far more manual, requires additional configuration, and doesn’t come with clear cost modelling.

How I Structure Buckets for Production

Here's a pattern that works well across most systems:

├── app-logs/
│   ├── versioning: enabled
│   ├── lifecycle: move to IA in 30 days, delete in 180
│   └── encryption: SSE-S3
│
├── media/
│   ├── versioning: enabled
│   ├── lifecycle: IA after 90 days
│   └── encryption: SSE-KMS
│
└── static-assets/
    ├── public access: blocked
    ├── cloudfront origin: yes
    └── caching: configured via headers

This setup keeps costs controlled while maintaining both security and durability.

Most large companies follow four core principles when designing their S3 structure:

Separation by data purpose (logs ≠ media ≠ analytics)
Isolation by environment (dev, staging, prod)
Least privilege access (per-bucket IAM policies)
Strong lifecycle controls (move cold data automatically)

Using these principles, here is a battle-tested structure you can adopt directly:

abc-company-s3/
├── global/
│   ├── shared-artifacts/
│   ├── security-logs/
│   └── compliance/
│
├── prod/
│   ├── app-data/
│   ├── media/
│   ├── analytics/
│   ├── backups/
│   └── logs/
│
├── staging/
│   ├── app-data/
│   ├── media/
│   ├── analytics/
│   ├── backups/
│   └── logs/
│
└── dev/
    ├── sandbox-<team>/
    ├── sandbox-<engineer>/
    └── temp/

Conclusion

With MinIO no longer actively evolving and key features moving behind paid editions, the operational and long-term risks have increased. For production workloads, especially ones that need durability, compliance, and strong integration with other services, S3 remains the more stable and future-proof choice.

It's not just "using a cloud service instead of self-hosting."
It's choosing a storage layer that removes operational overhead, scales automatically, and integrates cleanly with the rest of the AWS ecosystem.

Final Thoughts

This structure comes from my own experience working with S3 in production setups, combined with research into how larger engineering teams organise their storage at scale. There's no "one perfect layout", but the patterns above tend to hold up well as applications grow and infrastructure becomes more complex.

If you manage S3 differently or follow another pattern that works well for your team, I'd love to learn from it. Feel free to share your approach, improvements, or any suggestions that could make this layout even stronger in a real production environment.

💸 How I Cut AWS EC2 S3 Data Transfer Costs to $0

Ishara Niwarthana — Sun, 09 Nov 2025 19:37:58 +0000

😅 The Problem

At my previous company, in one of our AWS accounts, our AWS bill showed ~$300/month in “Data Transfer” even though all workloads were in the same region.

Our setup:

EC2 batch jobs
Uploading results/logs to Amazon S3
Same region, no cross-region calls

I assumed:

“Same region = no cost.”

Wrong. 😬

🔍 The Root Cause

After checking Cost Explorer and VPC Flow Logs, I found the issue.
EC2 instances were talking to S3 using the public endpoint.

Example:

aws s3 sync /data s3://abccompany-logs/

That meant:

Traffic left the VPC via NAT Gateway
Crossed AWS’s public network
Re-entered AWS to reach S3

So even though both were in the same region, we paid:

NAT Gateway data processing: $0.045 per GB
Regional data transfer charges for EC2 → S3 path

💰 At ~6 TB/month = $270+ in pure data movement.

Per AWS Docs:

“If data leaves a VPC through an Internet Gateway or NAT Gateway, standard data-processing charges apply.”

🧠 The Fix - VPC Gateway Endpoint for S3

The solution: keep the traffic inside AWS’s private network.

Here’s the Terraform snippet we used:

resource "aws_vpc_endpoint" "s3" {
  vpc_id          = aws_vpc.main.id
  service_name    = "com.amazonaws.eu-central-1.s3"
  route_table_ids = [aws_route_table.main.id]
}

Once created:

EC2 → S3 traffic stays internal
NAT Gateway no longer handles uploads
Zero data-processing or transfer charges

Confirmed by AWS docs
:

“Gateway endpoints for Amazon S3 have no additional cost.”

💰 Results

After one billing cycle:

Metric                  Before  After
EC2 → S3 Transfer Cost    ~$300   $0
NAT Gateway Data    High    Minimal
Performance         Same    Same

🧩 Common Mistakes to Avoid

❌ Mistake                        ✅ Fix
Assuming “same region = free”       Verify network path
Using public S3 endpoint            Use Gateway Endpoint
Ignoring NAT data charges           Track via Cost Explorer
No flow visibility                  Enable VPC Flow Logs

🧠 Lessons Learned

This experience taught me that AWS cost optimization isn’t just reserved instances or savings plans, it’s about network awareness.

A single endpoint change saved us hundreds per month, with zero downtime or refactor.
It’s one of the simplest, most underrated optimizations you can make.

🪶 TL;DR

✅ EC2 → S3 via NAT = $$
✅ EC2 → S3 via VPC Endpoint = Free
✅ Check your data paths, even in the same region

Forem: Ishara Niwarthana

Why Amazon S3 Makes More Technical Sense Today (Especially After MinIO’s Shift)

💸 How I Cut AWS EC2 S3 Data Transfer Costs to $0