Apache Cassandra is a massively scalable open source NoSQL database that’s widely deployed in the AWS cloud. It’s ideal for managing large amounts of structured, semi-structured, and unstructured data across multiple distributed locations. Cassandra is a masterless, peer-to-peer distributed system where data is distributed among all nodes in the cluster. Each node has knowledge on the topology of the cluster and exchanges information across the cluster every single second. Running your own Cassandra deployment on Amazon Elastic Cloud Compute (Amazon EC2) is a great solution for any business that runs applications with high throughput requirements.

AWS released a whitepaper with some best practices for using Apache Cassandra, and whether you’ve never touched it or consider yourself a pro, these are great tips to remember. Filled with information and recommendations from DataStax, the whitepaper is recommended to ensure your Cassandra deployment on AWS is as smooth as possible. Here are the highlights:

Planning Regions and Availability Zones

The AWS cloud infrastructure is built on Regions and Availability Zones (AZs). The Region refers to a physical location somewhere in the world, while the AZs consist of one or more discreet data centers housed in separate facilities. Rather than limiting yourself to one data center, the AZs allow the ability to operate applications and databases that are more highly available, scalable, and fault tolerant. A business can use AWS’ global infrastructure to manage network latency and to address compliance needs.

Be careful, though. Data in one region is not automatically replicated outside that region. If your business needs higher availability, you’ll have to replicate that data across regions. Since Cassandra nodes all serve identical purposes, there’s no single point of failure. Because of this, it’s not a bad idea to spread Cassandra nodes across multiple AZs to enable and maintain high availability and uptime. 

Planning an Amazon Virtual Private Cloud

Amazon Virtual Private Cloud (Amazon VPC) gives you complete control over your virtual networking environment. This includes IP address range, creation of subnets, and configuration of route tables and network gateways. AWS strongly recommends launching a Cassandra cluster within a VPC—the enhanced networking feature being a big reason why.

Enabling enhanced networking on an instance results in higher performance, lower latency, and lower jitter. Currently, there are six different instance families that are supported for enhanced networking within a VPC: C3, C4, D2, I2, M4, and R3. If your business uses any of those instance families, it’s a wise idea to utilize a VPC to optimize your overall performance.

Deploying Cassandra on AWS

Not only does Cassandra provide native replication capabilities, it can also scale horizontally. The illustration below demonstrates:

It’s possible to scale vertically using high-performance instances, but vertically scaled instances don’t provide the impressive fault tolerance benefits that come with a replicated topology. Since AWS has a nearly unlimited pool of resources, it’s usually better to scale horizontally. Let’s face it—mistakes happen. Components of the setup can be automated to limit mistakes, For example, using auto-scaling to automate the steps required for replacing a dead node allows less manual intervention. The more you can do to limit mistake and manual intervention, the better.

The AWS cloud provides a unique platform for running NoSQL applications including Cassandra. Its capacities can meet a variety of needs, has a cost based on use, and is easily integrated with other AWS products. Cassandra and AWS provide a robust platform in which a business can develop scalable, high-performance applications. If you have an existing Cassandra cluster that you’d like to migrate onto AWS, the whitepaper gives you the best practices for doing so.

Datapipe’s DataStax Enterprise-as-a-Managed-Service is now available worldwide via our Database Management service—we can plan, build, and run a Cassandra deployment on AWS. As a partner with both of these leading providers–Datastax and AWS–Datapipe engineers are well versed in best practices for these types of deployments. Along with AWS Direct Connect, there are a handful of options for businesses of all sizes to improve their overall performance and address any regulatory or compliance requirements. To learn if a solution like Cassandra is right for you, please visit our Database Services page.

Experts estimate there are more than 14,000 attacks on networks and systems every day, with new vulnerabilities in critical software increasing by 50% annually. These are alarming stats for any IT organization, but especially those in sensitive industries like banking. These stats are also why security is one of the key hesitations when it comes to migrating to the public cloud. In fact, big U.S. banks have been referred to as one of the last major strongholds of old-line technology companies. No wonder, then, that Amazon Web Services (AWS) has been approaching banks like Citigroup, Goldman Sachs, and J.P. Morgan Chase to educate them on the benefits and advanced security features of the public cloud.

However, winning business from companies with such high security and regulatory compliance standards is no easy task. According to an article from Dow Jones Business News, “the offering in theory could help banks shift their tech spending to newer areas and away from maintaining so many data centers. The hurdle is that Amazon’s is a public cloud business, open to anybody. Banks, which have relied on their own private infrastructure to this point, would need to feel comfortable about security and ease any concerns from regulators before moving ahead.”

Not only does AWS offer hundreds of tools and features to help banks meet security requirements around visibility, auditability, controllability, and agility, but AWS also partners with third party security firms and managed service providers (MSPs) – like Datapipe – to provide expertise and help guide companies through the best practices of AWS policies, architecture, and operational processes necessary to satisfy the requirements of security sensitive customers, like big banks.

What AWS and its partners are able to offer is Defense in Depth, a proven security model that meets the most rigorous standards of confidentiality, integrity, and availability, ensuring the ongoing security of all mission-critical digital assets. This means layered security that goes beyond the basic security features of AWS – continuous audit, data encryption, DDoS protection, intrusion detection services, etc. – to include the best third party security features and comprehensive compliance services on the market. This offers anyone – even big banks – the security they need. A quick highlight of two of Datapipe’s own AWS-specific security features that play into this defense model:

• 2Factor Secure Cloud Access: An integration of our own two-factor authentication service, Datapipe Auth, with FortyCloud’s SaaS security model to deliver enhanced security, access, and control by providing the capability for managing the two-factor authentication soft token service with role-based access control.
• Datapipe Access Control Model for AWS: DACMA lets enterprise businesses take advantage of Datapipe’s AWS managed services without requiring them to hand over the administrator-level credentials. The model also allows for an enhanced level of security and control through role based access and tracking, clearly establishing and tracking the accountability and actions of all users.

Even with these expansive security options, however, the Dow Jones article makes the point that “some banks still have concerns about privacy and security, and even the banks that are using the cloud are keeping their core banking activities and data on their own platforms.”

The good news, though, is that times are changing and more banks are becoming more willing to consider the public cloud. Of the banks AWS has approached, J.P. Morgan is exploring using the public cloud in some instances to trim expenses and increase flexibility in storage space. Capitol One is planning to reduce its data centers to three from eight by using AWS for a range of processes, including its mobile banking app. The comprehensive yet flexible security features and compliance services offered by AWS and its partners are no doubt a large part of these banks’ decision to move to the cloud.

At AWS re:Invent last year, we joined Amazon as a Relational Database Services (RDS) database migration partner. RDS is back in the news as Amazon announced several new updates this month. Among the new features is the ability to share encrypted database snapshots with other AWS accounts, and adding encryption to a previously unencrypted database instance.

AWS Database Migration Service is currently available in preview mode; as an RDS partner, we’ve had some good practice with this service and can address some features and benefits of it.

Minimize Downtime During Migrations: After the initial database migration is complete, the target database remains in sync with the source for as long as you’d like. This minimizes risk and application downtime.

Supports All Widely Used Databases: AWS Database Migration Service supports homogenous migrations, like Oracle to Oracle and it also supports heterogeneous migrations between different database platforms, like SQL server to Amazon Aurora. Additionally, this service can migrate on-prem databases to Amazon RDS or Amazon EC2, and can migrate one RDS database to another.

Fast and Easy Setup: A migration task is where you define the set of information based on the AWS Database Migration Service that is executing the migration. Once setup is complete, you can test the task against a development or test environment to verify each step of your entire process. After that’s done, the same task can be used for any other environments.

Low Cost: You’re only paying for the compute resources used during the migration. According to Amazon, a terabyte-size database can be migrated for as little as $3.

Reliability: AWS Database Migration Service is constantly monitoring source and target databases, network connectivity, and the replication instance. Occasionally, an error may pop up that can’t be automatically resolved. In this case, AWS provides a detailed diagnostic report for you to respond accordingly. This is an important benefit–without this strong monitoring presence, the source and target databases could become unsynchronized, resulting in unreliable data.

There are additional useful features of AWS’s service, as well – the change data capture capability is always capturing and applying all data changes from the source database to the target. This enables the user to keep the source database operational during the migration process, and puts them in the driver’s seat for when to move an application over to the target database. AWS Database Migration Service also provides an end-to-end view of the load and replication processes, including the latency and throughput of the data transfer. As mentioned earlier, this data and monitoring will help resolve any errors or challenges that may occur during database migration.

If you’ve worked in a data migration project before, you know it’s no walk in the park. Previously, developers would need to write their own migration scripts, constantly testing them out until they worked flawlessly. A number of other roles are involved with data migration, as well, including solutions and infrastructure architects, database administrators, engineers, and quality assurance testers. With AWS’s Database Migration Service, it’s easier and less time-consuming to migrate data to AWS.

To learn more about AWS RDS Database Migration Service, visit their FAQ, or get in touch with us. As an AWS partner, our Managed Amazon RDS Solution provides a complete lifecycle approach to designing, migration, and management of databases with certified DBAs, deployed with best practices for security, architecture, and performance.

Post from 2016:

Take a look back at the past year and you’ll see a number of companies that have experienced data breaches, hacks, and other security issues. It’s not limited to a certain industry, either: Experian (financial), BlueCross BlueShield (medical), Ashley Madison (online)…and the list goes on. While breaches are obviously bad news to the companies involved, they can also spell disaster for their customers, too. And the thought of being hacked or experiencing another security threat has still proven to be a top deterrent in moving to the cloud.

In fact, a Dell survey found that while 75 percent of IT decision makers believe C-Suite executives recognize the importance of data security, only 25 percent feel the C-Suite is adequately educated about the issues to make informed decisions. As a result, nearly two-fifths of all respondents restrict access to the public cloud within their organization, and almost 80 percent said they wouldn’t be willing to upload critical data to the cloud.

This seems like a bit of a rash move. Yes, there have been several breaches in the past year, but oftentimes, that’s a result of a company’s own doing. There’s nothing inherently riskier about the cloud than other IT environments, but most companies aren’t as aware of the proper ways to secure the cloud. We’ve discussed some proactive steps you can take to ensure a successful experience in the cloud; this includes ensuring everyone within an organization is on the same page when it comes to security, and being ready with an incident response plan should the worst happen.

Then again, perhaps migrating to the cloud isn’t the right move for your business. Maybe you’re running on-premise applications that simply wouldn’t function within the cloud, or your organization might not have the high-speed, high-quality WAN connection needed to ensure cloud connectivity and productivity. That’s completely fine—but the organization should come to that conclusion as a whole. The key is to have a strategy around your decision, not simply one or two people making quick choices.

We really cannot overstate the importance of education when it comes to the cloud, and there’s no harm in asking for assistance. We’ve called 2016 the Year of the MSP, with managed service providers playing an ever more crucial role in architecting and overseeing IT infrastructure, explaining and educating on the complexity of platforms and services, and ensuring organizations meet regulatory requirements. Despite some of the security concerns cited in the Dell study and similar surveys, more enterprises continue to move to the cloud. As a result, more of these organizations are working with MSPs to ensure their business remains productive, efficient, and secure.

Security has been–and may continue to remain–a concern for enterprises, but when you have the support of a trusted partner, it can put those fears to rest. There’s a lot of knowledge out there to be had, and educating yourself is a great start. Visit the AWS or Azure security blogs for more information on how to stay safe in the public cloud.

This week Jeff Barr announced the 10^th anniversary of AWS Cloud and we at Datapipe would like to congratulate them on the immense milestone! Jeff notes:

Looking back at the past decade, it is pretty impressive to see just how much the IT world has changed. Even more impressive, the change is not limited to technology. Business models have changed, as has the language around it. At the same time that changes on the business side have brought about new ways to acquire, consume, and pay for resources (empowering both enterprises and startups in the process), the words that we use to describe what we do have also changed! A decade ago we would not have spoken of the cloud, microservices, serverless applications, the Internet of Things, containers, or lean startups. We would not have practiced continuous integration, continuous delivery, DevOps, or ChatOps. While you are still trying to understand and implement ChatOps, don’t forget that something even newer called VoiceOps (powered by Alexa) is already on the horizon. 

Of course, dealing with change is not easy. When looking in to the future, you need to be able to distinguish between flashy distractions and genuine trends, while remaining flexible enough to pivot if yesterday’s niche becomes today’s mainstream technology. I often use JavaScript to illustrate this phenomenon. If you (like me), as a server-side developer initially brushed off JavaScript as a simple, browser-only language and chose to ignore it, you were undoubtedly taken by surprise when it was first used to build rich, dynamic Ajax applications and then run on the server in the form of Node.js.

Today, keeping current means staying abreast of developments in programming languages, system architectures, and industry best practices. It means that you spend time every day improving your current skills and looking for new ones. It means becoming comfortable in a new world where multiple deployments per day are commonplace, powered by global teams, and managed by consensus, all while remaining focused on delivering value to the business!

We at Datapipe couldn’t agree more. One thing we all know for sure, AWS brings amazing growth potential to the cloud market. Did you know Datapipe has believed in the power of AWS from the beginning? In 2010 Datapipe launched the company’s managed services for AWS, transforming the managed service provider industry and defining best practices for public cloud management. Since the launch, Datapipe has been a close AWS partner, bringing public and hybrid cloud solutions and best practices to enterprises around the world.

There have been so many noteworthy highlights from the progress we’ve made since initiating our relationship with AWS 5 years ago. Today we’re proud to say we’ve supported AWS for these past few years and look forward to continuing to do so in the future.

For more articles on the significant AWS milestone:

• http://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html
• https://aws.amazon.com/blogs/aws/ten-years-in-the-aws-cloud-how-time-flies/
• https://aws.amazon.com/10year/

Check out our page here if you’d like to learn more about Datapipe’s relationship with the company. And if you’re unfamiliar with our longstanding relationship with AWS, see here:

Have you ever gone to see a movie that would have been amazing if not for one person? The plot was engaging, the dialogue was well-written, and there were strong performances from most of the cast. But there was just that one actor who simply didn’t live up to the rest of the film, and it made every scene he was in that much worse? Simply put, that actor was bad, and brought down the whole operation.

That idea of the “bad actor” can be applied to Internet clients, as well. Fortunately, you’re not hurting any feelings by sussing them out: the bad actors are usually automated processes that can harm your systems. The two most common forms are content scrapers, which dig into your content for their own profit, and bad bots, who will misrepresent who they are to get around any restrictions stopping them.

We’d all like to believe that everyone accessing content will use it appropriately. Unfortunately, we can’t always assume the best, and being proactive in dealing with these bad actors will reduce security threats to your infrastructure and apps.

Even better, blocking bad actors will also lower your operating costs. When these bots access your content, you’re serving the traffic to them, whether you want to or not. That adds more to your overall costs. By blocking them, you’re restricting traffic from a number of undesired sources. Luckily, AWS has a pair of tools you can combine to say goodbye to these bad actors: Amazon CloudFront with an AWS web application firewall (WAF).

With AWS WAF, you can define a set of rules known as a web access control list (web ACL). Every single rule contains a set of conditions, plus an action. Any request that’s received by CloudFront gets handed over to AWS WAF for further inspection; if the request matches, the user can access the content as attempted. If the request doesn’t match the conditions in a specified rule, the default action of the web ACL is taken. These conditions will remove quite a bit of unwanted traffic, as you can set filters by source IP address, strings of text, and a whole lot more. As for the web ACL actions, you can count the request for later analysis, allow it, or block it.

Perhaps the best attribute of the WAF is that you can smoothly integrate it within your existing DevOps, and automate workflows to react. Since bad actors are always switching their methods to mask their actions, your proactive detection methods must constantly change, as well. Having those automations in place is immensely helpful in finding bad actors and restricting their access.

There’s a great walkthrough of how to set up this solution on the AWS Security Blog, step-by-step. Feel free to check it out for more information, or get in touch with us if you have any additional questions. And for AWS customers that need even more than what the AWS WAF has to offer, there are services that are complimentary to the AWS WAF that provide enhanced protection for business critical applications on AWS. You won’t even need to thank the Academy when all of those bad actors are removed.

A strong IT strategy is a must for any enterprise, regardless of its level of involvement in the cloud. The very foundation of a business depends on its ability to operate smoothly, swiftly, and efficiently while limiting security risks.

Our partners at VMware and EMC developed a white paper entitled “The State of IT Transformation” that discusses the crucial elements a business should have to support their modern and digital needs. The report is based on feedback gathered from CIOs and IT leaders workshops held by the two companies with participation from over 660 organizations. It’s comforting to see that progress has been made, though there are still some areas of improvement. What are some of the areas where CIOs would still like to improve?

Defining a Strategic Platform

It shouldn’t come as a surprise that CIOs are constantly thinking of ways to be cost-effective. Also not a shocker: companies want to reach between 80 and 100 percent in compute, storage, and application virtualization. Only the top companies are hitting above the 80 percent mark in those categories, so overall, there’s still a ways to go, particularly in the storage and application areas.

Similarly, while most companies want a well-engineered hybrid cloud architecture, very few are where they hope to be. Over 90 percent of respondents are only in the evaluation or proof of concept stage of a hybrid cloud environment. Perhaps even more alarming, a similar percentage of organizations have no organized, consistent way to evaluate workloads for hybrid cloud. This leads to trouble down the line, as evaluations are done few and far between, take up a lot of time, and are difficult to repeat. It’s also a reason why the adoption of hybrid cloud across the enterprise is still not a uniform decision. A managed service provider can help ease some of the workload, particularly in monitoring an environment, and while there’s no one best answer for migrating to the cloud, it’s worth it for a business to take the time and see what the best option is for them.

Transforming Operations

The majority of CIOs expressed a desire to run their IT like a customer-focused business. 80 percent said they hoped to increase automation to improve IT service delivery and come up with a standard set of services to efficiently manage user and customer requests through a service catalog and self-service portal. Most respondents have either no self-service portal or service catalog, or have an underdeveloped one. Even the most mature companies only have a partial catalog.

As always, having a road map of the moves and changes your business makes in its strategy is a good idea, and 90 percent of CIOs agree, saying they believe a documented IT transformation strategy, complete with executive and line-of-business support, is a crucial step. But saying and doing are two different things: more than half of those CIOs admitted to having absolutely nothing documented.

To get started on a successful business strategy, it’s a good idea to look at your DevOps practice as a whole. That involves getting back to the basics—these three steps are a good place to begin.

Empowering and Accelerating Application Development

According to more than two-thirds of all respondents, the development of a new application takes at least six months, and in many cases, more than a year. The biggest reason for this delay? Fewer than 20 percent of companies have a scalable, infrastructure-independent application framework. Without that, it’s difficult to build mobile, cloud-native apps quickly or even consistently. Especially as the industry continues to shift, having a framework that’s both scalable and able to stand independently will ensure a business can adapt and take advantage of newer infrastructure capabilities down the line. 

Making Progress

It’s very good to see that companies have made significant progress in their IT initiatives over the past few years. A great example of this is looking at the percentage of areas that participants rated themselves as being at the lowest level of maturity. These areas include Healthcare, Government, Telecommunication Services, Retail, and Financial Services. Just a couple of years ago, the overall average of “lowest level” in these areas was 69 percent; today, they’re at 58 percent.

The reports results, featured on VMware’s CIO Vantage and on EMC’s State of IT Transformation, provides leadership strategies and insights on priorities for IT transformation initiatives. Granted, there’s still plenty of work to be done, but CIOs are headed down the right path in prioritizing the areas – like the hybrid cloud – that will provide them and their businesses the greatest benefits in the long run.

Though more businesses than ever moving to the cloud, the space is still not completely devoid of risk. To address some of these threats, the Cloud Security Alliance developed the “Treacherous Twelve” report. While these are certainly plausible threats, there are ways to limit your exposure to harmful effects.

In the first of a two-part series, we’re going to break down six of these threats. What are they? What kind of harmful effects can they have on a business? How can you stop them? We’ll start with one of the more well-known threats out there.

Data Breaches

A data breach can happen in both a cloud environment and a more traditional on-prem network. Your company’s data may have different value to certain parties. For example, organized crime will likely go after financial, health, or personal information to aid in fraudulent activities. Meanwhile, competitors might want to get proprietary information or intellectual property. Or you may run into someone that simply wants to expose an embarrassing or damaging secret. When a data breach occurs, companies may incur large fines, and may be subject to civil lawsuits and criminal charges in some cases.

Cloud providers have strong security protocols for certain aspects, but, ultimately, a business is responsible for protecting its own data in the cloud. The best first step is installing an effective security program. Adopt multifactor authentication and encryption, and you can reduce the likelihood of a breach.

Insufficient Identity, Credential and Access Management

According to the CSA report, “data breaches and enabling of attacks can occur because of a lack of scalable identity access management systems, failure to use multifactor authentication, weak password use, and a lack of ongoing automated rotation of cryptographic keys, passwords, and certificates.” Consider that identity systems must be scalable in order to handle lifecycle management for millions of users, as well as managed service providers. If an employee leaves the company for any reason, or even changes roles within the company, identity management systems need to immediately update that level of access.

Malicious actors pretending to be legitimate users, operators or developers can extract, modify, and delete data. Any centralized storage mechanism containing data secrets – including passwords, private keys, and customer databases – is a valuable target for attackers. Centralizing passwords and keys is convenient, but it’s not the most secure. Monitoring and protecting identity and key management systems should be a major priority for any business. As these systems become more interconnected, MSPs can help reduce the need for user maintenance.

Insecure Interfaces and APIs

Cloud providers expose a set of software user interfaces (UIs) or application programming interfaces (APIs) for customers to use. These interfaces have to be designed to protect against both accidental and intentional attempts to get around policies. APIs and UIs are typically the most exposed part of a system, and as organizations and third parties build on these interfaces to offer value-added services to their customers, it can increase risk.

A business must understand the security implications around using, managing, orchestrating, and monitoring cloud services. Threat modeling applications and systems, including data flows and architecture, are crucial parts of the development lifecycle. Beyond just conducting security-specific code reviews, penetration testing goes from optional to mandatory.

System Vulnerabilities

System vulnerabilities are “exploitable bugs in programs that attackers can use to infiltrate a computer system for the purpose of stealing data, taking control of the system, or disrupting service operations.” Bugs aren’t anything new, but became exploitable remotely when networks were created. And as systems from different organizations are placed in close proximity, shared memory and resources have created a new attack surface.

Fortunately, basic IT processes can reduce these attacks: consistent vulnerability scanning, reporting system threats, and installing security patches and upgrades help tremendously. Unpatched system vulnerabilities are extensive and expensive – the cost of putting IT processes in place in order to discover and repair any vulnerabilities pales in comparison to the potential damage they’re capable of. This is particularly important for highly-regulated organizations, like banks or government institutions. Vulnerability scenarios must be created to ensure all activities are properly documented and reviewed before being validated and closed out. If an alternative method of handling a threat is used, including elimination, transference or acceptance, that method must be documented and tracked as well.

Account Hijacking

Phishing, fraud, and exploitation of software vulnerabilities continue to be an effective method of obtaining sensitive data. Cloud platforms, including AWS and Azure, only add a new wrinkle to things: “if an attacker gains access to your credentials, they can eavesdrop on your activities and transactions, manipulate data, return falsified information, and redirect your clients to illegitimate sites.” Especially if you’ve built up a reputation of trust, an attack or two like this can really damage your credibility.

With stolen credentials, attackers can access critical areas of the cloud, stealing data, impacting services, harming reputations, and a whole lot more. To avoid this, organizations should refrain from sharing account credentials among users and services. Embracing strong two-factor authentication is a good move, too. As is keeping track of all accounts and account activities. If it can’t be traced back to a human owner, that’s a red flag.

Malicious Insiders

The European Organization for Nuclear Research defines an insider threat thusly:

“A malicious insider threat to an organization is a current or former employee, contractor, or other business partner who has or had authorized access to an organization’s network, system, or data and intentionally exceeded or misused that access in a manner that negatively affected the confidentiality, integrity, or availability of the organization’s information or information systems.”

This is one of the areas where cloud providers can struggle. Encrypted implementations can still be vulnerable to attack. But with constant monitoring, auditing, and logging of activities, an organization can avoid insider threats. A company can also control access and the keys themselves – our DACMA offering is one such tool for this – in order to assign duties and restrict access by role.

A good reminder, as well: an “Insider Threat” doesn’t necessarily mean someone is acting maliciously. An employee could simply upload sensitive data in a public forum by accident, for example.

These six threats can be damaging to your company, but by taking the steps discussed here, you’ll be ahead of the game. Check back on the blog soon as we cover the remaining six threats to look out for in the cloud, and how you can best combat them. In the meantime, feel free to check out the Cloud Security Alliance site for more information and upcoming events. As a CSA member, we’re well-positioned to report on these threats, and are happy to help answer any additional questions, as well.