Introduction
What could be more detrimental than becoming addicted to something that significantly impacts your finances? Addictions to gambling, cigarettes, or drugs can have severe financial consequences. Have you ever wondered about the origins of these addictions?
Imagine having disposable income and seeking entertainment. Among your options, you decide to seek thrills at a casino. You begin playing on slot machines, roulette, or even poker, and at first, you start winning. There are occasional losses, but overall, you see some gains. However, over time, the odds begin to favor the casino more and more. Eventually, you find yourself broke for the day but still craving another opportunity to win. This marks the beginning of addiction. Casinos recognize potentially profitable clients and strategically offer occasional wins to entice them to continue playing, knowing the calculated risks involved.
This same pattern is mirrored by drug dealers. They often provide initial samples at no cost to demonstrate the effects and stimulate desire. As the saying goes, “appetite comes with eating,” and before long, what began innocuously becomes a serious problem. It’s no surprise that this tactic is effective and has been adopted by many cloud providers today.
AWS Business model
To introduce users to AWS services, Amazon Web Services (AWS) has established a program known as the ‘Free Tier.’ This initiative allows new customers to explore and test AWS services without incurring costs for a limited period. The Free Tier is designed to provide hands-on experience with AWS, enabling users to evaluate its capabilities and potential benefits for their projects or businesses. Typically, AWS offers a specified amount of credits that users can utilize to experiment with various AWS services. These credits are subject to expiration dates and usage limits
Here are some of the key components included in the AWS Free Tier:
- Amazon EC2 (Elastic Compute Cloud):
- 750 hours of EC2 usage per month for Linux, RHEL, or SLES t2.micro instances. This is enough to run a micro instance continuously each month.
- Amazon S3 (Simple Storage Service):
- 5 GB of standard storage,
- 20,000 GET requests, and 2,000 PUT requests per month. This includes Amazon S3 standard storage, data transfer, and requests.
- Amazon RDS (Relational Database Service):
- 750 hours of RDS single-AZ db.t2.micro instances running MySQL, PostgreSQL, MariaDB, Oracle BYOL, or SQL Server (running SQL Express edition) per month.
- AWS Lambda:
- 1 million free requests and 400,000 GB-seconds of compute time per month. This allows you to execute functions in response to events without provisioning or managing servers.
- Amazon CloudWatch:
- 10 custom metrics, 10 alarms, and 1,000,000 API requests per month with basic monitoring and detailed monitoring for Amazon EC2 instances, Elastic Load Balancing, and Amazon RDS DB instances.
- AWS SNS (Simple Notification Service):
- 1 million publishes 100,000 HTTP/s deliveries, 1,000 email deliveries, and 1,000 SMS deliveries per month.
- AWS SQS (Simple Queue Service):
- 1 million requests per month for Amazon SQS standard queues.
- AWS CloudFront:
- 50 GB of data transfer out and 2,000,000 HTTP/HTTPS requests per month for one year.
- AWS Step Functions:
- 4,000 state transitions per month for AWS Step Functions state machine executions.
- AWS Glacier:
- 10 GB of retrieval per month for free for the first 12 months.
- (…)
How does the AWS free-tier mechanism operate? Similar to strategies employed by casinos or drug dealers, it is designed to foster dependence. By utilizing AWS services such as AWS SQS, Step Functions, S3, Lambda, or RDS, users become closely integrated with AWS’s proprietary technology. Applications become heavily reliant on resources exclusively available within AWS, often without compatible alternatives. This scenario is commonly referred to as vendor lock-in.
If your project exhausts its free tier resources, it’s not uncommon for AWS to offer ‘free’ credits as an incentive to keep you progressing in your early-stage development. Recently, AWS has been sending me a flurry of emails with these offers.
As a golden rule, always remember that nothing in this world comes without a cost. There is usually a hidden motive behind receiving something ‘for free.’
After integrating AWS proprietary technologies extensively into your application stack, many companies hesitate to discontinue their usage due to various factors, including the high cost of transition, the risks associated with application migration, and the pressure to meet project deadlines..
Initially, AWS often presents a cost-effective solution. Moreover, current IT trends strongly promote the adoption of cloud-native technologies. This might be very tempting to immerse into AWS services and build application only basing on their own technology. Why should somebody be afraid of common solution that everybody in the industry follows, right?
The pivotal moment arrives when the application begins to experience significant traffic from clients. At this stage, costs typically escalate rapidly. Increased demand for computing services correlates directly with higher expenses incurred with AWS. The trick is that, at the beginning of a project, it is difficult for stakeholders and development teams to accurately predict the total cost of AWS services. Since many AWS services scale based on application load, costs during the initial phase of the project are often negligible. When the cost starts raising it is usually too late for the companies to migrate because of the reasons mentioned above.
It may happen that starting from very low costs we ended up in an unprofitable business. The transition from this state is not trivial. It always varies depending on the project’s internal situation.
How AWS tries to discourage your project from migrating?
Costs
I have seen many situations when clients were incapable of leaving the cloud platform because of… costs. AWS have no cost policy for ingress data but outrageous egress fees. This means that it is free to upload your data, but tremendously expensive for downloading it. Egress fees are applied when data is leaving the AWS cloud (e.g. during data migration to on-premise). For example in order to move 500.000 GiB of data from S3 to on-premise you would have to pay approximately ~ 35000$, just for moving the data. This might be enough to block any migration plans for companies that can’t afford that price.
Proprietary technology
Once a project starts relying on services like DynamoDB, ECS, S3, and Cognito, migrating away from them becomes a complex challenge. Take S3, for example. While there are alternatives like MinIO that claim full compatibility with the AWS S3 API, your project likely uses more than just basic storage. Features such as S3 Events, Versioning, and Object Lock are often critical and not fully replicated by alternative solutions.
Migrating from ECS to Kubernetes can also be problematic, especially if your project uses direct AWS API Gateway integration with ECS or relies on ECS Service Connect. Additionally, project pipelines are likely built around AWS APIs, further complicating the migration.
As for Cognito, there is no fully API-compatible alternative. While options like StrongDM or ORY exist, converting to these would require significant effort and adaptation
Is it possible to embrace AWS without becoming so dependent that migrating away becomes difficult?
This is a question that I asked myself many times, and as always in IT, the answer is – it depends.
From a proprietary technology standpoint, it’s possible to shift away from AWS-specific services by adopting open-source alternatives, many of which are supported by AWS itself. For instance, instead of relying on CloudWatch, you could use Prometheus and Grafana hosted on AWS. Similarly, Argo Workflows can replace Step Functions for orchestration, and Kubernetes can be used instead of AWS ECS. There’s almost always an open-source project addressing the same needs as AWS services. But this raises a critical question:
If we stop using AWS proprietary services altogether, why keep our application on AWS? What’s the benefit then?
AWS is notoriously one of the most expensive cloud providers. If you’re no longer using its proprietary services, why not run your project on GCP, Azure, or even Hetzner, where costs can be significantly lower? Paying $200 for EC2 instances when you could get similar compute power for $50 on Hetzner doesn’t make much sense. It seems that AWS is only worth the investment if you’re deeply integrated with its services, which, in turn, leads to a dependency that traps you within its costly ecosystem.
Is there an ideal balance?
Here are a few key considerations to help you decide when to use AWS proprietary services:
- Be cautious with AWS offerings. Thoroughly read the documentation to ensure a service meets 90-100% of your requirements. Just because AWS claims that it will fit your project well, doesn’t mean it will really do!
- Always review pricing for each AWS service, considering not only your current development load but also potential future spikes—even unexpected ones.
- Explore open-source alternatives and compare costs. Is the price comparable?
- Consider using multiple compute/cloud providers. There’s no rule that you must rely solely on AWS!
- Make sure that the AWS offering allows you to test those solutions in isolation. We should not validate if AWS services are working correctly but we should certainly validate if our custom code solutions are integrating with them correctly.
- Hybrid cloud: Host the core of your services with a cost-effective provider and leverage AWS for on-demand scalability.