In this article I describe how we created a redundant PostgreSQL database on the Amazon cloud using EBS snapshots as backups to deploy a PostgreSQL DB server DR mobile application for one of our customers.
PostgreSQL 9.1 includes new capabilities for asynchronous fast replication syncing between master and slaves. The master server streams new data to the current available slave. This version includes great improvements that generated significant fast WAL (Write Ahead Log) processing, which generates replication and fast launching capabilities for the slave servers.
Read More
We have noticed that at least one unnecessary port is open on your DB server, meaning that your DB server is potentially vulnerable. Typically this issue occurs when using the same security groups to secure DB and non-DB servers. We suggest setting security groups specifically for the DB server and limiting access to recommended DB-related ports only.
Read More
We have found that you have at least one of your security groups’ IP ports open to all internal AWS servers. This can potentially make some of your servers vulnerable. This issue can occur if one of your security groups was configured to allow access to the following IP range - 10.0.0.1/8.
We suggest limiting access of internal AWS servers to these open ports in one of the following ways:
- IP Address: Limit access to a specific IP address of an instance that is yours (e.g. 10.17.48.156/32)
- Security Group: Limit access to a certain security group (i.e. use another security group’s rules to limit access (e.g. sg-3c02c053).
Read More
Newvem monitors your security groups’ ports, and notifies you if it finds that at least one of them is currently open to all IP addresses. An open IP port may mean that some servers are exposed to access from any IP address worldwide, making them vulnerable. We suggest that you reduce the number of open ports to a minimum, limiting access from the outside world only to web-facing services. For example, port 80 for HTTP and port 443 for HTTPS.
Read More
It can be risky to publicly share Amazon Machine Images (AMIs), as they may contain sensitive data that you do not want to be publicly accessible.
There are two options:
- Shared inadvertently: If the AMIs have been shared inadvertently, their access policy can be changed to private.
- Shared intentionally: If the AMIs have been intentionally shared, sensitive data should be removed from them.
Read More
Newvem monitors your security groups’ critical IP ports, and notifies you if it finds that at least one of them is open. An open critical IP port may mean that some security group servers are exposed to access from public IP addresses, making them vulnerable. We suggest that critical IP ports be locked down, limiting access to critical ports from your private network only.
Read More
Newvem continuously monitors servers’ CPU load and notifies on high CPU loads. We consider an average CPU load of 80% and above as a high load. As high CPU load can lead to a major service availability risks, which results in service degradation. In order to protect the system one should consider changing the instance size or implementing a different scaling method. We suggest that you either:
- Scale up your computer instances – vertical scaling; move your workload to larger servers.
- Scale out your compute instances – horizontal scaling; use additional servers.
- Auto-scaling – AWS offers the ability to dynamically and automatically scale up or down according to conditions you define. With Auto Scaling, you can ensure that the number of Amazon EC2 instances you’re using increases seamlessly during demand spikes to maintain performance, and decreases automatically during demand lulls to minimize costs. Auto Scaling is enabled by Amazon CloudWatch and available at no additional charge beyond Amazon CloudWatch fees.
Read More
Newvem continually monitoring your servers CPU load and notifies you on high loads. High-load lead to a major down time risk, you might need to consider changing the instance type or implement a different scaling method. We consider an arbitrary of 80% CPU load and above as an high load and suggest that you scale up or scale out your compute instances (i.e. move your workload to larger servers or use additional servers).
Read More
An EBS Snapshot is a copy of an EBS volume at a particular point in time.
A snapshot can be taken of a volume, regardless of whether or not the volume is attached to a running instance. A snapshot comprises data blocks that are incrementally saved to Simple Storage Service (S3), meaning that only the blocks on the device that have changed since your last snapshot are saved. When saved to S3, the snapshot is assigned a timestamp and unique AWS ID.
It is crucial to back up your EBS volumes with EBS snapshots, to prevent losing important data.
It is best practice to have at least one backup snapshot per volume. It is especially recommended that you take periodic snapshots when running a DB.
AWS Elastic Load Balancing (ELB) automatically distributes incoming traffic to your application to multiple EC2 instances that are attached to your Elastic Load Balancer. At any time, Elastic Load Balancing detects the unhealthy instances in the pool, and distributes the incoming traffic only to the healthy instances until the unhealthy ones are restored.
In order to achieve greater fault tolerance and thus higher availability, it is recommended to distribute your instances in different geographical zones so that if all the instances in a single datacenter are not healthy, as may occur when there is an outage, your application will run in a datacenter in a different zone.
Read More
