When should you use AWS?

On the market, there are plenty of companies that deliver Infrastructure as a Service (IaaS) functionality. Among the biggest ones from the US, such as AWS, Azure, and GCP, there are also smaller players like Hetzner, OVH, Digital Ocean, IBM Cloud, and more. Some of these providers primarily operate as data centers renting bare metal servers, while others are well-established cloud providers.

When choosing a computing services provider, several factors should be considered. Let’s take a look at some critical factors and questions:

Vendor lock-in

• Service Cost Changes: If your organization relies on proprietary cloud services, would it still be feasible to continue using them if the provider significantly increases its pricing?
• Compliance Policy Adjustments: If AWS or another provider modifies its compliance policies, can your organization adapt accordingly?
• Cloud service requirements: Do you intend to use additional services beyond computing and storage from your cloud provider?
• Computing provider strategy: Do you know how the desired computing provider business works? Which services are safe to use, which may be risky? Sometimes it’s good to do an investigation in that manner. Luckily your you, I have already done it and it’s available for you – How AWS business works.

Human resources

• DevOps Expertise: Does your team have experienced DevOps professionals with knowledge of data centre management?
• Provider Familiarity: Are your employees well-versed with the specific service providers you are considering?
• Initial guidance: Do you have people who will properly drive cloud-native development?

Project Phase

• Project type: Is your project part of a startup ecosystem?
• Regulatory Compliance: Does your project need to comply with any existing regulations or standards?
• Timeline: Do you have any strict deadline that cannot be exceeded?

Technical aspects

• Service Level Agreements (SLA): Are there specific SLAs that your project needs to meet?
• Expected Load: Do you have an estimate of the expected load on your application, and how much will this load fluctuate?
• Global Presence: Does your project require a global presence, and are your customers located in particular geographic regions?

Costs

• Initial Investments: What are your initial capital investments?
• CAPEX and OPEX: How much can your organization allocate to capital expenditures (CAPEX) versus operational expenditures (OPEX)?
• Discounts and Negotiations: Is your organization able to secure discounts or favourable terms from the cloud provider?
• Employee training: Have you secured a budget for training employees who may not be familiar with the required technology stack, whether it be cloud-based or data centre solutions?

As demonstrated, there are multiple variables to consider when choosing a computing services provider. It is not feasible to universally recommend renting bare metal servers over cloud providers, or vice versa. The optimal choice depends on the specific requirements and goals of your organization. However, for non-corporate-level applications that primarily require computing power, utilizing AWS may sometimes be excessive.

In case AWS was chosen

1. Maximize AWS Service Utilization: AWS is known for being one of the most expensive cloud providers, so if you’ve chosen it, you likely had compelling reasons. To fully leverage this decision, go beyond just using compute and storage services. Take advantage of AWS’s ready-made solutions, such as API Gateway, Cognito, Backup, EFS, SFN, and S3. These services can significantly reduce development costs and time, which are typically high. The more AWS-native services you utilize, the more you can benefit from the platform’s efficiency.
2. Favor Open Source Solutions: When choosing between AWS proprietary tools and open-source alternatives offered by AWS, lean towards the open-source options. Your development teams will appreciate the ease of testing and integrating with open-source projects. This choice can also provide greater flexibility and reduce vendor lock-in.
3. Prioritize Testing: Using AWS services doesn’t eliminate the need for thorough testing, especially for integrations. While it’s unnecessary to test AWS’s internal services (e.g., verifying if a PUT request to an S3 bucket actually creates an object), it’s crucial to ensure that your custom code correctly interacts with these services. Ensure that requests are being sent and received as expected in your application.
4. Enable Local Testing: Always aim to enable your services to run locally, even if just for testing purposes. This is essential even when your service depends on external resources not managed by you. Local testing can speed up development cycles and increase reliability. For more details on effective integration testing within AWS, refer to my blog post, Integration Testing in AWS. The more granular your testing, the greater the benefits in terms of speed and reliability.
5. AWS Custom code services: If your project utilizes a service that requires custom-written code (e.g., Lambda, SFN, SWF), never assume that it can be treated differently from your other services. Regardless of whether the code is written in JSON, XML, or YAML, you should apply the same rigorous testing strategy as you do for any other service in your ecosystem.