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 following presentation was created by Adrian Cockcroft - Director, Cloud Architecture at Netflix Inc. It contains slides from his talk at AWS Re:Invent November 2021. Adrian describes the architecture, how to make highly available application code and data stores, a taxonomy of failure modes, and actual failures and effects.
AWS cloud products facilitate the way you can easily and in a reasonable time, deploy a scalable online service on Amazon cloud infrastructure. The slides include schemes that deal with the different cloud aspects such as elasticity, performance and security. The architectures demonstrated uses some advanced AWS products such as Auto-scaling, RDS, Route53 and much more. The presentation is a bit long, take your time and you will find these AWS features that can help you understand how to get more of your AWS cloud account.
S3Sync is a tool written in Ruby to synchronize system folders (EBS) and S3 buckets. In this guide we will shown you how to sync your EBS data with S3 bucket and vice versa.
We will run an EBS-backed Linux instance and sync data between our instance and S3 bucket.
To execute the S3Sync from your instance, you need Ruby (version 1.8.7 or above ) installed in your local machine. If you are running a Windows instance, download and install Ruby from http://rubyinstaller.org/downloads/ for a Windows local machine.
AWS Shared Security Model - Slideshare presentation brought to you by the AWS cloud guys. The presentation gives a nice basic overview on AWS Security including the “Shared responsibility model”, features and products. If you are new on AWS this is a must in order to quickly understand what are the public cloud vendor’s expectation and will support your plans to move and utilizing the public cloud while outsourcing part of your IT security.
WordPress is one of the most popular open source blog platforms out there. It is used to power anything from simple blogs to complex portals, thanks to the variety of plugins the community has developed.
In this article we will describe the architecture options for deploying WordPress in AWS with scalability and high availability in mind. We will take advantage of the elasticity of the cloud and use more servers when we need them and less when we don’t (auto-scaling).
It happened again… this was the second AWS outage in the same month. Did you fail to protect your service online? Don’t forget – you can’t pass your liability onto your IaaS vendor.
Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. Amazon Cloud Computing is a good choice if you want to deploy very a large scale network on the cloud that requires high availability, auto scaling and load balancing features.
In this article I will explain how you can configure High Availability for Microsoft SQL Server 2005/2008 & Web server (IIS) in Amazon EC2. I assume that you have some basic knowledge of how Amazon EC2 works.
After tracking more than $200,000,000 in AWS EC2 spend, Newvem has identified that more than 35% of its users operate an AWS cloud that is highly vulnerable to outages. Many cases were identified in which users had improperly configured Elastic Load Balancers (ELBs) and as much as 40% of users’ cloud data wasn’t backed up. High availability when deploying applications is crucial. This article will explain how Newvem analyzes your availability levels but first let’s talk about best practices when deploying applications in the cloud.
Following Max B. post on KnowYourCloud and based on questions received at AWS Usergroup meetups I realized that there is a reasonable (but sometimes exaggerated) concern about the level of lock-in to AWS. In this article we will try to put the problem in the right perspective and explain the practical lock-in considerations for the various services of Amazon’s cloud.
What is vendor lock-in? Vendor lock-in is the situation where a business becomes overly dependent on a specific service or product provider.
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.
