8 Best Practices to manage servers deployed in AWS
When Cloud Computing arrived more than decade ago, it was not clear how its implication will affect the business world, but now Cloud technology is a new buzz in the market and most of the mid-level and small businesses are widely using Cloud Computing. Here are the eight best practices to manage your servers which are deployed in AWS services:
1. Use IAM Service
There are two cases where you must use IAM
Case 1: Never distribute your root account credentials among your team, instead create an IAM user by giving the access permission what he needs to access. Which makes your account more manageable when it comes to who has made the changes and why.
Case 2: When you need to use AWS services programmatically through your server then don’t use root account keys, instead create an IAM user having limited resources with programmatic access and use the keys created in IAM, which protects your account from any unusual activities like creating new services without your knowledge by a hacker or without your involvement.
Click here to read getting started guide for IAM
2. Update EC2 Inbound rules
Never make your Server or Database instances open to world in EC2 Security groups even if the instance is created for development/testing purpose, and if its production environment then it’s highly recommended that you don’t make ports open to the world unless there is a strong use cases like HTTP & HTTPS access.
3. Stop the instances when you are not using them
As we know that AWS charges based on the usage, as a Mid-level or Small business it’s very important to reduce the server maintenance costs, In order acheive this it is advisable to stop the service when you know that the service is always idle at a particular time period & start again when required. You can stop and start the AWS services by using AWS Lambda and Cloud watch events.
4. Configure alerts with AWS config
It’s better to use AWS config service alerts, to get notified when any configuration has been changed in your AWS account. If annoyingly or mistakenly anyone modified the security group inbound rule open to the internet in your account then you may never know that its changed, and you may realise about the change after getting hacked or after you lose your data. Instead if config alerts are created then you will get notified about the change and it will help to update the configuration before the damage. Click here to read AWS getting started guide for AWS Config service
5. Configure VPC
Make your servers and databases run private to the world and no direct inbound connection to them with AWS VPC, With VPC you can create secured architecture for your application. It’s highly recommended to use VPC architecture in production environments.
Click here to read AWS getting started guide for AWS VPC
6. Don’t keep sensitive credentials in the code
Most of the developers store sensitive information like database connection details such as domain name, username, passwords in server configuration files, which is vulnerable if the code is exposed to someone else who is trying to steal your data. There is a way to use these credentials in a secured way by using AWS Secrets Manager, which will automatically include the required connection details into the instance environment variable and users can’t access them.
Click here to read AWS getting started guide for AWS Secrets Manager
7. Automating the Amazon EBS snapshot lifecycle
To recover from data failures/ damages we all do data backups daily, after a long time if you look into your backup list it’s a very huge number which you may not require. Instead you need only the latest backups always. The main drawback here is charges incurring for the backup storage plus maintenance difficulty. To avoid these difficulties you can make use of AWS Lifecycle manager which automatically creates the snapshots and removes older ones. Click here to read AWS getting started guide for AWS Lifecycle manager
8. Use AWS Systems Manager
Sometimes developers makes SSH connection open to internet which makes some one outside may have chances to connect your instances and damage it, Instead you can use AWS Systems manager to connect through console(Starting a shell session) not from the SSH terminals, you can even remove SSH rule from the security group inbound rules which is not needed when you use Systems manager. We can even securely access the EC2 instances which are in a private cloud without SSH connection by starting a shell session. Click here to read AWS getting started guide for AWS SSM
As we know, Cloud Computing becomes first choice for many organisations and at the same time it’s very important to manage your servers without any security implications otherwise your applications become vulnerable to security and data loss. Following the 8 Best Practices listed above in this article would help you manage servers very effectively in the AWS Cloud ensuring safety, security, availability and manageability of the Web Services.