Now, if one of the features of your workload offers the ability to your end users to upload content to Amazon S3, they may benefit from the same acceleration provided to CloudFront customers using Amazon S3 Transfer Acceleration (S3TA). Similar to CloudFront, the further away your end users are from your S3 buckets, for instance, for end users far away from your buckets Region, the more S3TA will help. And the good thing is that you only pay for the transfers to S3 that are actually accelerated.
Remember the direct requirements your workload may have as provided below:
If you plan to use EC2 instances for your workload, make sure to pick up instances that support the network throughput you expect. The recent generations of EC2 instances (from the fifth generation, for instance, M5) provide enhanced networking leveraging the AWS custom Nitro card and an Elastic Network Adapter (ENA). That allows some of the instances from the N series, such as M5n, to deliver up to 100 Gbps of network throughput. If your workload heavily relies on inter-node communication, Elastic Fabric Adapter (EFA) is a network interface available on some EC2 instances, for example on M5n, that allows low-latency inter-node communication. EFA enables HPC applications to efficiently run at a scale of hundreds or thousands of interconnected EC2 instances.
Similarly, if you rely on EBS volumes to store data, leverage EBS-optimized EC2 instances to reduce resource contention between EBS I/O and other network traffic. EBS optimization is enabled by default on recent EC2 instance types, since the fourth generation of instances (such as M4). It is also available on older instance types, although it is not enabled by default. If you want to make sure your instance is properly sized for your EBS I/O traffic, monitor the EBSIOBalance% and EBSByteBalance% metrics available in CloudWatch. If these metrics consistently stay low, you should consider increasing your instance size, because if you don’t, EBS I/O traffic could be throttled. Inversely, if these metrics stay at 100% all the time, you may want to consider downsizing your instance. Note that this is only regarding the EBS I/O aspect; before downsizing an instance, you should also look at the overall picture, considering other factors such as CPU usage, memory usage, and network traffic to make sure you will still have enough of those resources after the size reduction.
In recent years, AWS has also added a number of options so that you can now deploy workloads supporting ultra-low latency on AWS. Local Zones were mentioned earlier. Local Zones are located close to areas with a large population or industry and let you run workloads closer to your end users on an infrastructure managed by AWS. Unlike AZs, Local Zones offer a reduced set of AWS services, including EC2, EBS, ECS, EKS, ALB, EMR, and RDS. A Local Zone is connected to a Region and lets you expand your VPCs in that Region and have subnets in the Local Zone as you do in the Region’s AZs. You simply rely on the attached Region to access AWS services not supported in Local Zones. For more details on network connectivity, please refer to Chapter 2, Designing Networks for Complex Organizations.
However, you might need to consider a situation in which your end users do not have a Local Zone nearby or if you require additional services not supported yet by Local Zones? One option is using AWS Outposts to actually run AWS services and infrastructure on-premises. Outposts comes in various form factors: either an industry-standard 42U rack or 1U or 2U servers. The servers can be deployed standalone or mounted on industry-standard racks. Similar to Local Zones, Outposts lets you expand your VPCs on-premises and provides a subset of AWS services. You simply rely on the attached Region to access AWS services not supported on Outposts. It is a useful option when you need ultra-low latency for some applications, for instance, to provide your AWS resources with single-digit millisecond latency access to your systems on-premises. That gives you an extra opportunity to efficiently process data locally using AWS services but without actually moving that data into an AWS Region. It is also a valid option in other cases unrelated to performance, for instance, to enforce data residency in locations where you might be constrained by the local legislation or your industry regulators.
You have just been through the major building blocks constituting the foundations of any solution built on AWS. In particular, you have examined for each layer the rationale that should guide you to select the best fit for your workload among those components. You are now ready to learn how you can ensure you eventually reach your performance objectives.