Hardware Requirements for AWS Developers

No matter how many services AWS offers, you still need some amount of hardware to use the services. The amount of hardware you need when working with services in the cloud is minimal because AWS hardware does all the heavy lifting. When working with services locally, you need additional hardware because AWS no longer does the heavy lifting for you. Therefore, you should keep in mind the different hardware requirements depending on where you are hosting your AWS service.
Hosting services locally
Hidden in the AWS documentation are all sorts of useful information about the different services. For example, AWS Storage Gateway will connect an on-premises software device (an embedded application with sufficient operating system capacity to run on hardware or on a virtual machine) to cloud-based storage.
In other words, you can use the gateway to connect your application with the data storage it requires. It may seem as if running the gateway in the cloud would be a good idea because you won’t need to invest in additional hardware. However, when you look at the requirements, you see that the AWS Storage Gateway comes with specific devices, instances, and storage requirements. The important thing to understand is that the cloud introduces limits that you must consider during any stage of planning.
After making sure that you can run the intended configuration, you can start thinking about the advantages and disadvantages of working in the cloud. For example, when you host your service in the cloud, you get automatic expansion as needed, and Amazon performs many administrative tasks for you. However, for a realistic perspective, these advantages must be offset by realizing disadvantages, such as:

• Low speed application possible
• You need to maintain a reliable internet connection
• loss of flexibility
• Vendors stopped working

Although the basic hardware needs are becoming less expensive, you need to consider additional expenses in the form of redundancy. Most organizations find that the hardware costs of moving to the cloud are much lower than maintaining an entire IT department, which is why they’re making the move. However, you should do this step with the understanding that you have other things to consider when doing so.
Hosting services in the cloud
When hosting services locally, you need to provide all the required infrastructure, which can be very expensive. AWS provides guidance on the minimum requirements for hosting a service on-premises.
A good rule of thumb when hosting services locally is to display as a minimum any requirements the vendor provides. If you don’t plan to load the service heavily, these minimums usually work. However, when you click on the Improve Gateway Performance link, the first suggestion you see is to add resources to your router. Planning for too large a capacity is better than not enough, but getting the configuration as close as possible to what you need will always help you financially.
Not all services will work locally, but you may be surprised to find that many of them do. The problem is precisely how you plan to use a particular service and the trade-offs you wish to make. For example, when hosting a service on-premises, you may find it difficult to provide the same level of connectivity that you can provide to third parties when hosting the same service in the cloud.
Define a good development environment
After you know the resources required for AWS and have the basics of setup in mind, you need to consider your development environment. The first issue you should think about is the issue of language. AWS doesn’t care what IDE you’re using (although choosing an IDE determines what features you have for remote access), but it does care about language. You must verify that AWS supports the language you choose for the service you want to access.
You can create a deployment environment with EC2. This tutorial describes how to perform this task. The main advantage of this approach is that you can theoretically develop AWS applications from anywhere because development no longer requires an on-premises system with specific resources.
However, this approach is certainly not free, meaning that you must have a reliable internet connection from wherever you want to perform development tasks – which is not a problem at work, but perhaps an issue at home. The cloud-based development approach uses the AWS Command Line Interface (CLI).
The main reason to use a local development environment is that you retain access to the local resources and code libraries that your organization currently relies on to perform development tasks.
This option also has an advantage in reliability because you do not depend on a remote connection to use it. If your Internet connection drops, you can continue developing the code (but testing is not possible until the connection is restored). When you use this option, you need additional bandwidth – at least for testing purposes and permissions to access AWS through an enterprise firewall.

You are not limited to only two options when working with AWS. For example, you can use a local development environment but put your code on S3. Using cloud-based data storage means you can have localized settings in multiple locations (so you retain access to local resources) and still get the benefits of cloud-based development, such as accessing your code from wherever you are configuring a development environment .
This tutorial is also interesting because it tells you how to configure your development environment to use Elastic Beanstalk for the project, control sources, and use the repository. As with the local development environment, you still need the required permissions for internet access and enough bandwidth to handle the increase in data requests to make this option work well. In fact, the bandwidth requirements are higher than the local configuration, and the development environment must work with remote resources.
Choosing the right development environment is not easy. In many cases, choice becomes a personal preference and organizational requirement. For example, using a cloud-based development solution may not be an option when dealing with sensitive development tasks; Security needs can trump other desires.