Welcome to Day 7 of the "How to AWS" series: Your first workload (part 2)
Today we will be continuing on with defining your first workload. If you missed the introduction and drivers behind this series, check it out here.
- Identified your first workload
- Thought about your requirements
- Discussed your workload architecture and network security
Today we’ll continue with defining your first workload by considering:
- Compute and storage requirements
- Leveraging AWS building blocks
- Workload integrations
- Cost estimations
How much oomph do you need?
It is time to sit down and work out what resources your first workload is going to require. This can come from many different sources such as vendor supplied system requirements for off-the-shelf software, or perhaps you’ve got a previous example of your workload deployed somewhere that you can review to determine your resource requirements.
The key components we will discuss in this blog post are CPU, GPU, memory and storage requirements. These four components will help determine which EC2 instance types and associated EBS volumes (i.e. the storage) you need for your workload.
You should take the time to work out your best starting point for your workload now. Is your workload CPU or memory intensive? These are key considerations which will influence your choice of EC2 instance type. AWS provides many different instance types (resource configurations) to cater for your workload profile - check them out here. Once you’ve worked out your starting point write them down, these will be the specs you deploy your workload with.
As a quick aside, I heavily endorse getting started with any workload under the On-Demand pricing model within AWS. This will allow you to right-size your instances down the track if your initial estimates or calculations were incorrect. Once your workload baseline is known, efficient and stable, then consider reserving your instances for a period of time.
How much storage do you need for your workload?
What performance do you need from your storage layer?
For the vast majority of workloads on AWS, the General Purpose SSD option is the best fit. With 3 IOPS per GB provisioned and the ability to bust to 3000 IOPS, what is not to love? Remember that EBS is network attached storage, so if throughput to the disks is important, make sure to look at EBS-Optimized Instances.
Whilst we’re on the topic of storage, make sure to note down that you’ll be encrypting your EBS volumes at rest. It’s super easy - leveraging AWS Key Management Service (KMS) - and should be a default across your AWS environment.
Lets Talk Building Blocks
AWS is more than just a provider of virtual machines and associated storage (though they do these really well). AWS provides the fundamental building blocks for architecting your system to be fault tolerant, redundant, highly available, scalable, secure and many other desirable traits for your workload.
These building blocks are the other 100+ products and services that AWS offers, often managed by AWS, covered by SLAs and enables you to build and run your workloads on AWS without requiring specialised technical expertise to deploy, run, upgrade and troubleshoot these components. We continue to have customers leveraging the AWS-native products and services at scale with very low operational overhead.
The service that I am recommending to you in this blog post is Amazon RDS, the AWS-managed Relational Database service. If your workload database is a fit for RDS, definitely consider using it. Database backups, upgrades, failover and licensing made easy!
Make sure you review the AWS provided products and services to see if they will be a good fit for your workload/environment. It is well worth the time and investment in reviewing these!
Will you be integrated?
Many workloads do not operate in isolation and must be integrated with third-party systems or other workloads that you may be operating. This will vary for every workload, but is a key consideration which can impact upon network architecture, security and the overall application architecture for your workload.
Will your workload require private connectivity back to your office or that factory down the road? Do you integrate with a bank, payment processor or business partners? Each integration you have may require (or support) only specific methods of communication.
We all know that third party that will only accept connections from whitelisted IP addresses and they take 2 months to action a firewall change request. If this sounds familiar, make sure you consider how you’re managing and retaining your IP addresses within AWS!
Time for some maths!
Now that you’ve worked out the resources and instance types required for your workload, it is best to make sure you understand the cost implications of running your workload. To this end AWS provide the AWS Simple Monthly Calculator which you can use to estimate the monthly cost of running your resources.
Make sure to select the correct region upfront as costs can vary between regions and currently there is no easy way to shift resources between regions within the calculator. Hopefully I just saved you 10 minutes :)
Take your time and input your expected workload resources and you’ll be able to review and save the cost estimation. This information can help you adjust your workload architecture to be more cost effective and set any requisite budgets for your workloads.
Keep up the doco!
You’ve just made many decisions, defined your workload specifications and estimated your monthly AWS costs. Take the time to document and communicate these with relevant stakeholders within your business!
Document your decisions, keep it concise, and explain the reasoning for bonus points.
In this blog post we finished defining your first workload, looked at the available AWS building blocks, considered your workload integration requirements and estimated your monthly AWS costs.
The next blog post in this series will focus on DevOps and building out automation for your workload.