When hosting becomes infrastructure
Migrating two operations from shared hosting to AWS was not about technology. It was about deciding whether the platform is a cost or an asset.
Code and Soul
Engineering Team
There is a fundamental difference between hosting a website and operating an infrastructure. The first is a cost decision. The second is an engineering decision. And that difference only shows when the site actually needs to work.
Over the past months, we migrated two operations to dedicated infrastructure on AWS. Mercado de Terras and Chauar Terras. Two different businesses, two different stacks, one shared problem: the digital platform was operating below what the business demanded. Not for lack of content or strategy. For lack of foundation.
The problem nobody sees until they see it
Mercado de Terras is a Drupal portal with 7.3 GB of media files. Chauar Terras runs a custom PHP system with 37 GB of high-value real estate images. Both operations ran on shared hosting at HostGator. The Business plan costs around R$ 35 per month. It seems cheap. And it is, until the site goes down on a Friday at 6 PM and support has no access to your nginx.conf.
In a shared environment, those volumes mean upload timeouts, slow cold starts, zero control over PHP version, and manual FTP deploys that more than once brought down the production site. It is not a matter of if something will go wrong. It is a matter of when.
The distance between hosting and infrastructure is the distance between reacting and deciding.
What it means to treat hosting as infrastructure
Migrating to AWS was not switching providers. It was redesigning the operation. A single EC2 t3.medium instance with 2 vCPUs, 4 GB of RAM, and 150 GB SSD hosts both sites. On the same AWS account, the complete stack includes CloudFront as a global CDN with automatic invalidation on every deploy, CodePipeline with CodeDeploy for automated deploys via git push with automatic rollback on failure, WAF with protection rules against bots, SQL injection, and XSS, Route 53 with managed DNS and health checks, ACM for automatically managed SSL certificates, and S3 for automated versioned backups.
The deploy is atomic. The script verifies data integrity before touching any file, creates symlinks to separate code from uploads, reloads services, and invalidates the CDN cache. If any check fails, the deploy aborts. Data is never lost.
Zero FTP. Zero manual intervention. Git push to production in 90 seconds.
The real cost is not on the invoice
The monthly AWS cost is around USD 60 across EC2, EBS, CloudFront, and Route 53. That is roughly 8 times the shared hosting price in absolute terms. But the real math is different. How much does 4 hours of downtime on a weekend cost? How much does a broken deploy with no rollback cost? How much does zero visibility into what is happening on the server cost? On shared hosting, deploy was manual FTP. Now it is git push to production in 90 seconds. Rollback that used to take hours restoring backups now happens in seconds, automatically. SSL that was manually renewed Let's Encrypt is now managed via ACM. Control over the stack, which was zero, is now total. Nginx, PHP, operating system, firewall.
| HostGator Business | AWS Stack | |
|---|---|---|
| Monthly cost | ~R$ 35 (~USD 7) | ~USD 60 |
| Deploy | Manual FTP | Git push → production in ~90s |
| Rollback | Restore backup (hours) | Automatic (seconds) |
| CDN | Basic/shared | CloudFront, 450+ edge locations |
| WAF | Not included | AWS WAF, custom rules |
| SSL | Manual Let's Encrypt | Managed via ACM |
| Stack control | None | Full (nginx, PHP, OS, firewall) |
| Scalability | Upgrade plan | Change instance type in minutes |
WAF with custom rules, CDN with over 450 edge locations, atomic deploy with automatic rollback. None of this exists in shared hosting. Not because the provider does not want to offer it. Because the architecture does not allow it.
Infrastructure that knows how to grow because it was designed for it.
Infrastructure ready for the next step
The architecture is already designed to scale. The natural next step is an Auto Scaling Group with instances behind an Application Load Balancer. When traffic justifies it, the migration is a configuration change. Not a rebuild. That is the difference between hosting and infrastructure. In hosting, scaling means upgrading your plan and hoping the provider allocates enough resources. In infrastructure, scaling is a parameter. The system knows how to grow because it was designed for it.
Mercado de Terras and Chauar Terras did not switch providers. They switched mindset. The platform stopped being a monthly expense and became an asset with engineering, observability, and capacity to evolve.
Hosting as commodity or infrastructure as decision
Shared hosting solves a specific problem: putting a site online at the lowest possible cost. And it does that well. But when the operation depends on the platform, when content has real commercial value, when downtime has consequences, the question changes. It is not how much it costs to host. It is how much it costs to have no control. The answer is almost always more than it seems.
This is what changes when you treat hosting as infrastructure, not as a commodity.
Code and Soul — Applied Engineering. AWS Partner Network.
"This is what changes when you treat hosting as infrastructure, not as a commodity. The cheapest decision is not always the most economical one."
Continuity: Intelligence, Engineering and Strategy
The thinking behind this article connects directly to Code and Soul's vision: systems that learn, platforms that evolve, and applied intelligence that transforms complex operations into sustainable competitive advantage.
