The greatest incentive to move to the cloud is to reduce cost. Organizations invest a lot to that end, but that investment is for not if your cloud isn’t protected. Most often, these mistakes are attributable to either a misinterpreted security policy or cluttered, nearly illegible security rules.
The latest trends on major sites is to serve content using HTTPS only. It actually offers several interesting advantages, like:
The cloud definitely marks a new era. Not only can we manage our resources in a flexible way and with no capital investment, but we can also enjoy the state-of-the-art infrastructure of large cloud providers, like AWS cloud. Specifically, when we use EC2 to compute endless resources, we know that in terms of the durability of our virtual servers, power supply, and storage, we can trust AWS to have the best of the best.
In case of a disaster we would like to make sure that our applications are still up and running, while taking advantage of our failover hosting/cloud provider. The Disaster Recovery (DR) architecture is driven by the criticality of applications and data. The decision regarding what to back up and deploy eventually translates into ongoing costs that can be extremely significant. Every IT organization has its own high level policy guidelines. These policies are eventually translated into the policy deployed for each of the different applications the enterprise runs. The CIO and its team need to make sure they define both the high level policies and the actual budget that can be spent for DR matters.
The policies for Disaster Recovery (DR) in an enterprise are driven by the criticality of applications and data. As the public cloud has gained in credibility, more and more IT teams are taking advantage of the failover public cloud provider as a way of addressing DR and ensuring business continuity.
On the following presentation Lahav Savir, architect and CEO of Emind Systems, gives an introduction to Disaster Recovery and presents his insights based on Emind’s best practices.
In this part we will dig a bit deeper and detail the standards and regulations that some of the most common infrastructure (IaaS) Cloud Service Providers (CSPs) comply with and are certified for. CSPs are not always obliged to follow all regulations, but normally they have procedures to make their consumer cloud compliant. We also look at four of the IaaS giants and how they handle making you become cloud ready. To highlight some basic differentiators between EU and US CSPs, a well-known European CSP is included too.
AWS Direct Connect is a dedicated, secure, high-speed interconnection between AWS and a customer’s equipment in a Direct Connect location. For AWS customers with high data transfer needs, this will result in improved performance at substantially lower cost. By bypassing the public Internet, companies can improve performance, reduce costs, increase security, and leverage cloud computing for more applications. With AWS Direct Connect, you can treat AWS instances as part of your data center LAN, allowing full integration between cloud services and your internal applications.
The AWS Elastic Load Balancer functions as a gateway for all the traffic to your data servers. The SSL, additionally, is used to encrypt data in transit. In order to keep your data safe, it’s not enough just to encrypt data in transit. There are more considerations that need to be made to keep your Amazon environments safe. For now, let’s discuss how to update the SSL Certificate of an AWS ELB. At the end of this post, I will circle back to the security issues that need to be taken into consideration.
An AWS account has full permission to perform all actions on the Amazon Glacier Vault that are part of the account. However, the AWS Identity and Access Management (IAM) users don’t have any permission by default. You can control access by setting vault-level access policies using the AWS IAM service.
With AWS IAM you can create a policy for a specific user or group. This guide shows you how to set an access level policy for a vault.
