devopsy.kinsta.cloud

Tag: AWS

  • Best Practices for User Management Models in AWS

    Best Practices for User Management Models in AWS

    Amazon Web Services (AWS) gives organizations the flexibility of using several different methods for managing user accounts. In this article, we will take a look at some of the best user account management practices and their potential pros and cons.

    The Ins and Outs of AWS Accounts

    AWS accounts provide comprehensive access to resources created during the account creation process. The first account is created when the user provides his payment details. from then on, the user is considered a root user. Additional users and accounts can be set up through an AWS service called Identity Access Management (IAM). We can use this service to create users with granular-level roles and permissions.

    Two unique identifiers are assigned to each account during its creation:

    • AWS Account ID
    • Canonical user ID

    AWS Account ID is a unique 12-digit number meant as a reference point for each and every user. It also helps to differentiate between users and resources.

    Canonical User ID is a long string used for enabling cross-account access on S3 buckets. It is achieved by using any other AWS account’s canonical user ID while writing an S3 bucket policy.

    AWS Account Detailing

    AWS account has a versatile set of features and functions. The resources and features help define the boundaries between the application and the service running in AWS account is set. There are six different types of the properties and behaviors:

    • Security and Access Controls
    • Communication
    • AWS Service Limits
    • Cost and Billing
    • Resource sharing
    • Account Linkage and Consolidated Billing

    Security and Access Controls

    IAM

    Identity Access Management and AWS identity exist for every account made on AWS. It offers control over access and permissions within an AWS account. It allows users and roles to be created as well as permission sets, which control access to resources within the account.

    The default IAM configuration prevents any unauthorized access to users not associated with the AWS account. Cross-account access is possible, too. An AWS account is best in when organizations are divided into business units: Within each business unit, the users, roles and permissions are created specific to the unit.

    Security Groups

    The security groups in EC2 are used to control ingress and egress requests from Elastic Compute Cloud (EC2) instances. In other words, security groups can be configured to control the open ports used for inbound and outbound requests to the EC2 instance. They allow access to the use of Instance ID, CIDR range or by referencing existing security groups. Unlike CIDR, other security groups just work within the AWS account.

    Advantages:

    • Accidental configurations allowing access across accounts can be avoided easily.
    • The responsibilities of departments within the organization/business unit are clearly defined.

    Communication

    AWS virtual private clouds (VPCs) are logically isolated sections of the system within the EC2 environment, which facilitate the construction of discrete networks for workload or organization. They empower users to gain not only control over the subnets but also access to the routing tables, internet connectivity, etc. IAM controls the access to VPCs. Security groups control ingress and egress at the EC2 instance level and access control lists (ACL) control the access to subnets at the VPC layer.

    By default, it is impossible for instances within different VPCs to communicate privately with each other. But using the unique feature of VPC Peering, it is possible to connect routing traffic between IP spaces for two different VPCs. Communication between subnets within two or more VPCs is possible as well. To initiate a VPC Peering connection, the requester has to send the request to the target or Peer VPC and then the request must be accepted by the administrator associated with the target or Peer VPC. Once the connection is established, all the routing tables can be modified, enabling the flow of traffic between the connected VPCs. If there are no particular IAM configurations, the person initiating the VPC Peering request might possess permissions to accept the request from the target VPC, allowing inter-VPC access.

    Cross-account peering is possible using VPC peering, but the administrative control of AWS accounts is usually segregated.

    AWS Service Limits

    A lot of AWS service limits exist by default. They are region-specific and provide the control over the number of different types of resources that could be created.

    Examples of AWS Service limits include:

    screen-shot-2016-10-05-at-1-48-32-am

    Although most of the limits that are specified are soft and can be increased or decreased easily on request, changes are not instantaneous. AWS support needs 24 hours to remove service limits after receiving business need-based requests. If an organization is using separate AWS accounts, it will end up with multiple sets of these AWS service limits. Putting a logical boundary in place is a good practice whenever there are multiple, independently functioning business units within any organization.

    Cost and Billing

    The AWS account can be seen as a billing entity that functions as a boundary for the allocation of the cost associated with the resources within the account. There may be different payment modes for different AWS accounts, and can produce detailed billing statements. Tagging is used for identification of the individual resources within an AWS account, making accurate cost allocation models possible.

    Note: There might be some resources that do not use tagging and will not be represented in detailed reports. If, for example, an organization is sharing an AWS account for several different entities that need their cost to be apportioned, then the best way to deal with this will be to use separate AWS accounts.

    The following list of resources that cannot be tagged:

    • Ingress or Egress Bandwidth from EC2
    • VPC endpoints
    • VPC flow logs
    • Elastic IPs
    • Ingress or Egress Bandwidth from S3

    When it comes to the cost optimization, reserved instances (RIs) play a vital role. RIs allow customers to access the significant amount of discounts over on-demand EC2 instances by committing to an instance type, region availability, period and level of utilization. RIs are not allowed to be moved between accounts, but it is possible to sell an unwanted RI on Reserved Instance Marketplace.

    Sharing Resources

    While there are several methods to prevent cross-account sharing, there are some that facilitate sharing it. Cross-account interaction with appropriate security controls is provided through VPC Peering.

    Some methods that facilitate sharing of resources between accounts are:

    • EC2 Amazon Machine Images (AMIs)
    • EBS volume snapshots
    • RDS Backup
    • Amazon S3 Buckets

    These mechanisms are used for sharing data from critical services. Even without relying on these tools, transfer of the data can be done manually, which is often prone to errors and security risks. This is not recommended.

    Linking Accounts and Consolidated Billing

    In AWS, linking multiple accounts in parent-child model is an efficient way to organize accounts for organizations. This method, called Linked Accounts, provides customers a holistic view of billing from multiple child AWS accounts into the single master AWS account. Through a single billing report that also includes separate reports per child account, Linked Accounts gives the user an integrated view on the resource charges for a cluster of AWS accounts. It provides more visibility into an organization’s spend throughout all AWS, still utilizing the AWS account as a boundary.

    When a linked account model is set up, a best practice is to make an empty master AWS account strictly for consolidated billing. When AWS resources are created within the master account, it adds complexity to the consolidated billing configuration/data and accounts holding payment.

    Consolidated billing is also beneficial at the time of purchasing RIs for an optimizing cost. RIs bought at the master account level could be linked at instance startup time to any child accounts  linked to the master account.

    Account Usage Patterns

    Training accounts can be used for different purposes:

    • Single Account Model
    • Autonomous Model
    • Single Master Hierarchy Account Model
    • Multiple Master Hierarchy Account Model

    Single Account Model

    In this model, all AWS resources are contained within a single AWS account employed by an organization. It’s a preferred model for smaller organizations that require simplistic workloads or fewer workloads within their AWS account. It also can be leveraged by an organization that centrally manages the IT and business functions. Using this model, a customer for a single payment method would receive a single billing report—the client is not required to handle numerous accounts for access management or communications.

    Pros:

    • Less complicated.
    • Cross-account configuration is not required.
    • Sharing of resources is held within an account.
    • Financial governance is easier and can be easily centralized.
    • Customer is provided with a single payment method and billing report.

    Cons:

    • With the increase in the usage, the account limits are required to be frequently raised.
    • Configuration and resource issue in one environment will adversely affect other settings (including production).
    • There is no way to isolate the access controls independent of IAM policies.
    • Erroneous changes to Security Group or IAM policies can have adverse effects.
    • Production and non-production workloads are not independent of each other.

    Autonomous Model

    This model leverages multiple AWS unlinked accounts to provide the advantages of the single account model. This permits independent IT or business functions to operate independently. It also allows each division or department to have a decentralized model to administer their functioning.

    Pros:

    • Decreased complexity for all accounts in the model.
    • Sharing of resources is held within the account.
    • Cross-account configuration is not required.
    • Individual billing reports for each AWS account.
    • Payment modes for every AWS account and business unit.
    • Decentralized governance across AWS resources.
    • Impact of erroneous changes to items such as IAM policies or Security Group changes reduced to a lone organizational unit

    Cons:

    • Assigning as a single account to manage a business unit reduces the impact of erroneous change outside the business unit. But this also has the drawback of single account model.
    • With no centralization available, the construction of multiple accounts becomes a challenge to manage.
    • Managing IAM policies with the different independent account may result in a drift of standards and access control, for instance, the user management.
    • Duplication of efforts because the organization manages several different billing and payment reports.

    Single Master Hierarchical Model

    In this one-to-many connected account model, a single master account helps the organization integrate the control and governance of AWS spending while allowing some autonomy for the business units. The Single Master Hierarchical Model is preferred by big organizations with centralized finance having several workloads throughout functional groups or projects. This model uses distinct subordinate AWS accounts for isolating the application environments within the organization.

    Pros:

    • Provides for a central managing system.
    • A single payment mechanism and integrated billing report across several accounts.
    • One single billing statement that covers subordinate accounts.
    • Provides the ability for attributing the costs, taggable or not, to an individual business unit.
    • Less prone to incorrect changes in the IAM policies, as the impact is contained within limited accounts.
    • Business units can be empowered to carry out administrative and IT duties.
    • RIs can be purchased at the master account level and used for the child accounts.

    Cons:

    • Managing IAM users and other policies can be tricky, as each account requires duplicate configuration.
    • Manual linking is required for setting up the new subordinate AWS account.
    • Consolidated billing that includes child accounts may produce multiple reports, making it difficult for efficient data analysis.

    Multiple Master Hierarchical Model

    This model also knows as, multi-master account structure, is preferred by large organizations or enterprises with numerous business units or governing bodies. These groups usually want their business units to function independent of each other, for legislative, political or financial reasons. In this model, several master payer accounts are set up, followed by dependent child accounts. This model retains benefits of the single-master model while allowing cost-allocation on a master-by-master account basis to payers and payment methods.

    Pros:

    • A centralized governing body yet separation between the child accounts.
    • Separate payment methods for each account as dictated by the needs of business divisions and units.
    • Reduced collateral damage from mistakes, such as security breach or IAM changes (constrained to individual accounts).
    • Business units and project groups can be empowered to carry out administrative and IT duties.
    • RI buyouts can be done at every master account level, enabling RI improvement inside every business unit.

    Cons:

    • IAM clients, policies and roles can be more tricky and intricate to manage because of the presence of AWS master and sub-accounts.
    • Consolidated billing over several master AWS accounts with numerous child accounts results in complex billing documents.
    • Multi-master arrangement will typically lose some of the cost efficiencies by limiting RI buys to every master account.
    • No nesting approach for setting multiple master records into a n+ various leveled structure

    Using a single account for all AWS resources will reduce complexity but increases risk, as issues with one account can impair several business applications. A single-report model should be used only for simple or singular use cases.

    Eventually, there’s no definite answer to what is the best account model. The choice of model is a subjective decision based on the requirements. However, some aspects of the Linked Accounts model can be a good fit for most real-world scenarios. It’s tricky to set up, but the behaviors and efficiencies of Linked Accounts model would overshadow the cash outlay for its setup. A structure should be chosen with an eye toward the future. Can this structure support rapid growth? Can it help growing communication in near future? These are the questions that should be addressed before choosing a model.

    Simplifying Your AWS Account Strategy

    Leveraging a single AWS account pattern may result in operational challenges. Managing and setting up IAM users, roles and groups consume a lot of time and could cause trouble and unexpected behaviors. While Identity Provider federation or cross-account IAM can be used to reduce the overhead, their configuration settings may be complex.

    AWS has a lot of human specialists who can assist with configuration, organization and administration of AWS assets. They can also help simplify operations of AWS infrastructure.

    AWS IAM Configuration Setup And Management

    With IAM, users can be allowed cross-account IAM role. One should remove the root account access to console and API. Also, a parent account could be created with access to specific AWS resources as an administrator or in read-only/read-write mode. As a best practice, roles and policies should be defined on the role. Then when the users are created, they can be allowed to be part of a particular role as needed.

    Consolidated Billing

    Consolidated Billing could be used for consolidating payments for several AWS accounts or AISPL (Amazon International Services Pvt. Ltd) accounts within a company by defining any of those accounts as the payer account. Consolidated Billing is a free service and offers a collective view of all the account changes, along with cost report for accounts associated with the payer account at the individual level. Usually, AISPL and AWS cannot be consolidated together; however, service providers could tie these two accounts and offer Consolidated Billing.

    Consolidated Billing offers the simplicty of one bill for multiple accounts. Account charges and cost data tracking is available in CSV format. And, in the case of multiple accounts, AWS integrates the use of all accounts, making the user eligible for a volume pricing discount.

    Summary

    By following the usage patterns discussed in this white paper, operational issues can be addressed through proper planning, automation and additional tooling.

    — Sudhi Seshachala

  • Orchestrating Continuous Delivery to Amazon ECS with Jenkins

    RECORDING

    SLIDES

    [seoslides embed_id=”7994ca2fcf11″ script_src=”https://devopsy.kinsta.cloud/embed-script/cd-amazon-ecs-jenkins/17635/” overview_src=”https://devopsy.kinsta.cloud/slides/cd-amazon-ecs-jenkins/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”CD with Amazon ECS and Jenkins” /]

  • DevOps Q&A: SUMO Heavy’s Brodie on the Hybrid Cloud

    DevOps Q&A: SUMO Heavy’s Brodie on the Hybrid Cloud

    Not every expert says DevOps will enable the hybrid cloud. One says it never will. Find out why in this Q&A with Bob Brodie, partner and CTO of SUMO Heavy, a digital commerce design and development firm.

    David Geer: How will DevOps enable the hybrid cloud?

    Brodie: I do not feel that DevOps enables the hybrid cloud. Hybrid clouds are very complex, and DevOps would need to be supported by a team of network and system engineers. The beauty of being on the cloud is that it’s API-driven. You can provision servers and configure and deploy with tools that are easy to set up.

    Bringing dedicated servers into that environment which do not have tooling to match the cloud counterpart means that it can’t be solely maintained by a DevOps team, but rather needs much more support. We have worked in hybrid cloud environments, and have experienced firsthand the amount of effort and resources required to create and maintain a hybrid cloud environment.

    Geer: What makes hybrid clouds more complex than being either fully in the cloud or fully dedicated?

    Brodie: When mixing dedicated servers with cloud servers on the same network, you will likely need parallel VPNs set up so you are not sending your data unencrypted over the internet and so that if there is a networking issue there is a fallback. Setting up full-duplex, parallel VPNs can require both expensive hardware and specialized resources to configure and maintain that hardware.

    Geer: Why have tools such as some of the ones AWS is building (OpsWorks On-Premises) not hit the inflection point where these are making it easier to enable the hybrid cloud? What other tools are examples of this?

    Brodie: OpsWorks On-Premises is just one tool that AWS has. They also have VPNs to connect your dedicated hardware to your virtual private cloud. These tools aren’t necessarily to make it easier to run a hybrid cloud, but they allow you to utilize existing AWS provisioning and deployment tools to set up and deploy to your existing infrastructure.

    Geer: Why do you think these tools never will make it easier to enable the hybrid cloud?

    Brodie: Hybrid cloud infrastructure is inherently more complex than being fully dedicated or fully cloud-based. They are two different types of ecosystems, and are managed differently. They require different skill sets and levels of experience within those ecosystems.

    Geer: Please expand on your following statement: “The problem is that the methodologies behind the two schools of thought (Separate sysops and dev versus DevOps) are vastly different in thought and practice, and to really bring dedicated hardware into a cloud-based architecture is very cumbersome, especially if the dedicated environment is not utilizing complex virtualization.” What does the difference in schools of thought have to do with it? What does bringing dedicated hardware in have to do with it?

    Brodie: My point here is that “DevOps” is often misused. It isn’t a tool, it is a mindset. It’s a combination of development and sysops. A “hybrid cloud” is a mix of dedicated hardware and cloud infrastructure. My main point here is that DevOps practices do not make managing enterprise developments easier across hybrid cloud environments. Hybrid cloud environments are inherently more complex than the alternatives (dedicated hardware or fully cloud-based).

    The reason for this is that development is becoming more and more intertwined with sysops. For example, five years ago you could download MAMP onto your Mac and be fully set up with a PHP & MySQL development environment. Modern PHP development requires a developer to understand specific versions of PHP and MySQL, how to manage them, how various applications communicate with each other and, often times, many other applications (Redis, MongoDB, Queueing systems, etc.). These can be complex to maintain, and even if they are distributed to developers from the ops team, it will often be in the form of Vagrant boxes or Docker files, which the developer will be required to understand.

    This is the nature of the “DevOps” school of thought, versus the traditional “SysOps separate from development” school of thought. The target environment needs to be considered when developing an application. For example, if the application will reside on AWS then the developer will need to have a solid understanding of the tools available on AWS (RDS, EC2, ElastiCache, etc.). The maintenance of these becomes part of the developer’s job, which was not present in previous times. Adding the extra complexity of a hybrid cloud means that the developer needs to understand the underlying network architecture of that system.

    Geer: In what way is the hybrid cloud a settling point, mostly built on marketing?

    Brodie: Hybrid cloud environments are not ideal. They are costly to maintain and provide more points of failure because of the networking between them. What it can do is provide a halfway point for CIOs that are reluctant to move to the cloud, so they can see some of the benefits on the cloud side and hopefully move their organization to the cloud.

    Geer: What are organizations afraid to let go of?

    Brodie: Many organizations are scared to move to the cloud. They may have a CIO/CTO that is afraid of “losing control.” I have seen many environments such as this.

  • Cohesive Networks Customers Validate VNS3 4.0 Elevates AWS Security

     Newly Released 5-Star Rated Application-Layer Network and Security Software Now Available
    AWS SUMMIT – LONDON, UK – 6 July, 2016 – Cohesive Networks, a cloud-native security and networking company, today announced the availability of VNS3 version 4.0 in the AWS Marketplace, and all cloud environments. Cohesive Networks’ innovative approach to application-focused security differentiates VNS3 as the first software-only virtual network appliance that offers end-to-end encrypted networking capabilities at the application layer. VNS3 4.0 includes a new, hardened underlying Operating System (OS), delivering deeper insight into network security, and elevating the level of application protection beyond what was previously available.
    “We went from 90% on-premises to 99% in the cloud in about 30 – 45 days,” said Chris Cata, Manager Network Operations at Foley Carrier Services. “Our cloud migration project almost didn’t happen without Cohesive Networks. VNS3 helped us achieve the flexible, multi-site VPN connectivity we needed, while Amazon’s built in VPN products did not.”
    Over 2,000 VNS3 users have shaped the direction of the product, from an encrypted IPsec VPN device to a more robust product family that offers network management, cross-cloud connectivity, and high availability. VNS3 customers have been successfully running cloud networks for over 800 million hours without any major, reported outages.
    “Years of experience in enterprise networking and security have taught us to look further into the future, beyond predictions or fears,” said Patrick Kerpan, CEO of Cohesive Networks. “5-star sentiment in the AWS Marketplace validates that VNS3 offers the end-to-end control cloud users need to flexibly connect and secure their applications.”
    VNS3 4.0 Update Includes:
    With VNS3 4.0 customers can build secure overlay networks on top of AWS cloud networks to enable network capabilities such as transitive routing, multicast protocols, as well as networking functions including reverse proxy network intrusion detection (NIDS) and load balancing.
    VNS3 version 4.0 includes security focused updates for VNS3:net, VNS3:ms, and VNS3:ha software products. The VNS3 virtual appliance is built on Ubuntu Linux and incorporates Docker container systems.
    Availability:
    VNS3 is available in over 20 public, private, and hybrid clouds. Cloud and virtual environments that feature VNS3 products include: Amazon EC2 and VPC, Microsoft Azure, CenturyLink Cloud, VMware vCloud, IBM Softlayer, Google Compute Platform, ElasticHosts, and Rackspace.
    VNS3 4.0 is available in beta on the cloud Marketplaces of Amazon AWS, and will soon be available on Microsoft Azure, and ElasticHosts. Contact Cohesive Networks to get started today: sales@cohesive.net
    Release notes: find out more about the technology behind VNS3 at Cohesive.net/support/release-notes
    About the VNS3 Product Family:
    VNS3 products help enterprises secure and connect their critical applications deployed to the cloud. VNS3 secures and connects applications above hypervisors, infrastructure, or data centers control. All Cohesive Networks products are software-only virtual appliances, available for most public, private, and hybrid clouds.
    VNS3 has recently won the 2016 Network Computing Awards Network Project of the Year – Private Sector Award, the 2015 Cloud Innovation World Cup for Industry 4.0, a finalist in the Cyber Security Awards for Best Security Company of 2015, listed in the CIO Review’s Top 20 Most Promising Enterprise Security Companies of 2015, won the 2014 EuroCloud Awards for Best Offering IaaS/PaaS, and won the 2014 Cloud World Series Best Security Solution Award.
    About Cohesive Networks:
    Cohesive Networks provides cloud-class security and networking software for enterprises. Over 2,100 customers use VNS3 virtual appliances to secure products and services at the application layer. With VNS3, enterprises can extend networks into public, private and hybrid clouds to provide security, connectivity, and integration.
    Cohesive is a member of the Amazon Partner Network, an Amazon Marketplace Seller, a member of the Microsoft Partner Network, Microsoft Azure certified, a Google Cloud Platform Authorized Technology Partner, a CenturyLink Cloud Marketplace Provider, certified HPE Helion Ready, and an IBM Business Partner. To find out more, visit www.cohesive.net
    ——————————————————-
    ###
    Media Contact:                      
    Heidi Groshelle
    Groshelle Communications
    @heidigro
    Cohesive Networks Sales Contact:                      
    Chris Purrington
    19 Eastbourne Terrace
    Paddington, London W2 1BA

  • mLab Launches Private Environments on AWS

    Developers can now peer their AWS VPCs to their mLab Private Environments to create their own private networks isolated from the rest of the cloud datacenter
    San Francisco – June 22, 2016 – mLab, the fully managed cloud database service featuring automated provisioning, scaling, and management of MongoDB databases, today announced the private beta of Private Environments. mLab Private Environments are virtual private networks that customers can provision to house their various database deployments hosted with mLab.
    Private Environments provide the security benefits of self-hosting database deployments without the headache of self-hosting. With Private Environments, customers can use all of the traditional network security best-practices and techniques for designing their application. Customers can:
    • isolate their database from public networks while allowing secure access to their application infrastructure
    • create sophisticated network topologies to ensure least privilege access to their database deployments using CIDR ranges and AWS Security Groups
    • auto-scale their application tier without having to modify database firewall rules

    “As an early beta user of Private Environments, we’ve appreciated the added level of security it provides,” said Chris Lambert, CTO, Lyft. “The private network created by Private Environments keeps our infrastructure secure as we continue to grow, and makes it easy for our team to provision new application servers and auto-scale without needing to modify database firewall rules. We’ve been using mLab’s cloud-hosted MongoDB for several years and it has played a big role in helping Lyft scale.”

    The new solution is engineered to be a novel way for customers to use virtual private networks through a DBaaS provider. With Private Environments, mLab has created an isolated and self-contained solution that securely and seamlessly integrates into an existing stack as though the databases were inside a customer’s own VPC. The result is network security that is both operationally easy and flexible.

    mLab’s cloud database-as-a-service platform hosts over 300,000 MongoDB deployments, powering companies like Turner, Lyft, and Whole Foods Market. Private Environments is the first of several releases slated for 2016 as mLab continues to debut new cloud infrastructure capabilities.

    “mLab is hands-down the easiest way to run MongoDB on AWS,” said Will Shulman, CEO, mLab. “We believe that constantly managing database infrastructure isn’t something most developers should have to worry about; mLab’s platform and tools are designed to automatically provision, host, scale, monitor and backup your MongoDB databases. Private Environments is a powerful new capability that furthers mLab’s goal of providing cloud infrastructure solutions that are both simple and secure. We’re excited for developers to try it out.”

    Resources

    About mLab

    mLab is a fully managed cloud database service featuring automated provisioning and scaling of MongoDB databases, backup and recovery, 24/7 monitoring and alerting, web-based management tools, and expert support. mLab’s Database-as-a-Service platform powers hundreds of thousands of databases across AWS, Azure, and Google and allows developers to focus their attention on product development instead of operations.

    Headquartered in the Mission/Potrero area of San Francisco, mLab is backed by premier venture and angel investors including Foundry Group, Baseline Ventures, Upfront Ventures, Freestyle Capital, and David Cohen of TechStars.

  • SecureWorks Counter Threat Platform Brings New Security Layer to Customer Workloads on AWS with Expanded Monitoring Capabilities

    Organizations can add security bolstered by threat intelligence as they pursue the potential of cloud computing and hybrid IT.

    Atlanta, June 13, 2016 – SecureWorks Corp. (NASDAQ: SCWX) is expanding the capabilities of its vendor-agnostic, data analytics engine — the Counter Threat Platform (CTP) TM — to now provide security monitoring of client applications and data being hosted on Amazon Web Services (AWS). The solutions are designed to enhance the security of an organization’s applications and data being hosted on AWS.

    For 17 years, SecureWorks has helped protect on-premises environments across the globe. Now, SecureWorks is leveraging its up-to-the-minute threat intelligence, the expertise of its Counter Threat Unit TM research team, and the native logging features of AWS to extend its portfolio of security solutions to the cloud.  The first of its offerings, which are purpose-built for AWS, include:

    • Monitored AWS EC2 server instances
    • Monitored Firewall and Web Application Firewall on AWS (support for multiple industry-leading firewall and web application firewall technologies)
    • iSensor Intrusion Prevention System TM on AWS

    SecureWorks’ iSensor Intrusion Prevention System on AWS can inspect both outbound and inbound traffic to an organization’s cloud environment and block new and emerging threats.

    SecureWorks also takes advantage of AWS-specific data sources and collects logs and telemetry from the technologies running in AWS, including when they spin up and down. SecureWorks supports multiple sources of log data, including logs from Amazon CloudWatch and CloudTrail.

    These new offerings, combined with the company’s award-winning on-premises security solutions  and Emergency Cyber Incident Response service on AWS, offer a comprehensive answer for security considerations for both on-premises environments and in the cloud, allowing  organizations to pursue hybrid environments. Organizations benefit from a comprehensive view into the security of their data and applications regardless of where they reside.

    “Organizations need to understand they have to play an active role in securing their cloud assets too,” said Frost & Sullivan Research Director Frank Dickson. “Moving to the cloud is not a binary decision; it is not all or nothing. Every enterprise will have some portion of its enterprise resources on-premises and some portion in the cloud, a hybrid reality that needs to be proactively addressed.  Security providers like SecureWorks who bring a mix of threat intelligence and security expertise to customers that is applied across on-premises, cloud and hybrid environments provide critical value to customers as they further embrace the opportunities enabled by the cloud.”

    As organizations continue to pursue hybrid environments with data and applications both on premises and in the cloud, the new solutions will allow the SecureWorks CTP to deliver security from the data center to the cloud.  The CTP aggregates over 180 billion events a day from SecureWorks’ clients and blocks those determined to be cyberattacks. With the CTP, SecureWorks can deliver countermeasures and generate valuable intelligence, as well as context about the intentions of the attackers, that can then be applied to secure cloud environments.

    “As the leader in New Zealand, Australia and the UK in cloud accounting software for small businesses, we take security seriously,” said Aaron McKeown, Lead Security Architect at Xero. “The protection of sensitive financial data of our 700,000 global subscribers is our most important priority. Working closely with SecureWorks technology provides us with the advanced threat intelligence and integrated visibility we need for seamless security and scale on Amazon Web Services.”

    “We hear every day that security is top of mind as organizations migrate to the cloud,” said Matt Eberhart, executive director of global product management at SecureWorks. “Our new solutions enable our clients to confidently embrace the cloud by extending security visibility and protections alongside cloud workloads and the traditional datacenter environments we have been protecting for 17 years. Our Counter Threat Platform will seamlessly extend your security program into the cloud with visibility across your traditional security controls, enabling your business to feel confident about your cloud security position as well as your cloud security posture.”

    The Monitored AWS EC2 server instances, Monitored Firewall and Monitored WAF solutions are available globally except in Japan. The Managed iSensor service is expected to be available in the fall of 2016. Language support is in English at this time.

    “SecureWorks is a partner we trust to keep our cloud infrastructure secure as we evolve and expand our banking customer base and ensure valuable financial data is protected,” Greg Judy, senior vice president and information technology officer at Colony Bank.

    About SecureWorks

    SecureWorks is a leading global provider of intelligence-driven information security solutions exclusively focused on protecting our clients from cyberattacks. Our solutions enable organizations to fortify their cyber defenses to prevent security breaches, detect malicious activity in real time, prioritize and respond rapidly to security breaches and predict emerging threats. As of April 29, 2016, SecureWorks served over 4,300 clients across 59 countries. For more information, individuals can also visit www.secureworks.com.

    ###

    Media contacts:

    Brian Prince

    SecureWorks

    bprince@secureworks.com; 201-406-2657

    www.secureworks.com

    or

    Elizabeth W. Clarke

    Director of Media Relations

    eclarke@secureworks.com; 404-486-4492

  • Enterprise Cassandra Deployments

    Enterprise Cassandra Deployments

    Successful Cassandra deployment in the cloud takes a certain amount of skill and knowledge. In this blog I will share best practices for a successful Cassandra deployment in the cloud such as Amazon Web Services (AWS) and Google Cloud Platform (GCP). I will also discuss how you can protect and recover the data in your Cassandra cluster when deployed in the public cloud.

    Cassandra Deployments in the Public Cloud

    There are two main ways to have successful enterprise Cassandra deployments in AWS:

    • Use a ‘managed’ Cassandra deployment. This is a reasonable approach; the only downside is the inability to customize data placement beyond what is typically provided by the vendor.
    • Manage the cluster yourself, if you want to have full control over your Cassandra deployment and customize it to scale and perform according your business needs.

    Please refer documentation from Datastax or Apache Cassandra for detailed best practices for Cassandra deployments. The following best practices are reiterated here to simplify deployment of a scalable Cassandra cluster in AWS.

    Storage

    Both AWS and GCP offer two types of local storage options for their compute instances. For AWS, the options are Elastic Block Storage (EBS) and Ephemeral Storage. In GCP, the options are Persistent Disks and Local SSD. Both options have their own trade-offs. Pick the one that best suits your deployment.

    Persistent Storage

    EBS volumes have performance characteristics similar to network storage such as a NAS or SAN. Because storage from EBS volumes is multitenant in nature, it is not suitable for distributed, log structured databases such as Cassandra. If you want to ensure reliable performance through EBS volumes, use “EBS optimized instances” with “provisioned IOPS.” Since the IO traffic to EBS volumes goes over the instance network, EBS optimized will provide reliable performance, but does not guarantee any increased performance. To get the most performance out of EBS volumes, use instances with multiple disks and separate the volumes used for “Data” and “Commitlog.”

    If you have to use EBS Volumes, go with “EBS Optimized Instances,” with “Provisioned IOPS” and split data and Commit Log on different volumes.

    Ephemeral Storage

    Ephemeral storage is a great option to use for downstream Cassandra environments such as test/dev and staging. Since ephemeral volumes are typically SSDs, there is no need to separate the data and commitlog into separate drives. To optimize performance, choose EC2 instances with multiple ephemeral storage drives and stripe them together into one logical volume. Send data and commitlog to the logical volume. Remember that when you stop the EC2 instance, the data in Ephemeral storage will be deleted.

    Stripe all Ephemeral drives into a single volume to get maximum performance.

    Data Distribution

    Cassandra uses Snitch to determine the topology of the cluster. The Snitch is also used to determine the data center and rack for each node in the cluster. Replication strategy is used to determine the placement of data across the different nodes in the cluster.

    AWS

    1. EC2Snitch works well for single region deployments.
    1. Ec2MultiRegionSnitch works well for cluster distributed across multiple AWS regions. Please note, Multi-DC, Active-Active configuration makes your cluster resilient to region failures and for multi-dc cluster, use “local quorum” to improve performance.

    Google Cloud Platform (GCP)

    1. Use GoogleCloudSnitch for Cassandra deployments in GCP.
    1. GoogleCloudSnitch treats regions as Cassandra data centers and availability zones as racks.

    Other Features

    Both AWS and GCP offer a series of operational capabilities that seem to make it easier to maintain high uptime on Apache Cassandra cluster. These capabilities have to be chosen carefully depending your deployment needs.

    1. Load Balancing: Network-level load balancing service is offered by both AWS (Elastic Load Balancer) and GCP. It is not recommended to put a load balancer in front of Cassandra. It is better to use a client connector that can handle this, consider open source utilities such Presto and Astyanax
    1. Autoscaling: Both AWS and GCP offer Autoscaling facility for compute instances. However, although this functionality looks very enticing, putting all C* nodes in an autoscaling group will not produce the desired result. Instead, create a separate autoscaling group of ‘1 node’ for every node in your cluster. This will ensure that anytime a node goes down, it is automatically brought back up. This will ensure the cluster data placement is not disturbed when nodes go down and nodes coming up do not cause excessive data movement.

    Scalable Backups and Reliable Point-in-Time Recovery

    Backing up your data is a must-have for enterprise organizations. The impact of data loss is so high that no enterprise wants to risk relying alone on replication. Protecting data in a public cloud environment may seem daunting, but there are several options available that can make this easier compared to an on-premise deployment. A simple option may look like one of the native snapshots:

    Storage Snapshots

    I have seen few customers use snapshots of EBS volumes as a way to protect the data in their cluster against logical and/or operational errors. This solution will work but with some severe limitations. On top of the overhead of maintaining the scripts to take snapshots, there is a large overhead in storage costs. Taking a snapshot of volumes does not allow for incremental backups of your data. This causes an exponential bloat in the amount of data stored in snapshots, leading to high cost of the backup solution.

    Amazon S3 or Google Cloud Storage

    Using an S3 bucket as the secondary storage enables enterprises to use low-cost, highthroughput storage, while reducing overall operating costs for storing backup data. Here are a few recommendations when using S3:

    1. S3 Region: Amazon S3 buckets are region-specific. A bucket created in one region will provide better performance characteristics to other infrastructure in the same region. Subsequently, it is important to ensure the S3 bucket used as the secondary storage is in the same region as the production database being protected and the Datos IO cluster.
    1. Storage Class and Lifecycle Policy: Amazon S3 allows users to create lifecycle policies on buckets. These policies dictate the performance and response time characteristics of objects in the bucket. STANDARD_1A is more suitable for longer lived and less frequently access data, and is not suitable as secondary storage. Additionally, do not turn on any lifecycle policies on the buckets used for the secondary storage. All buckets should be in the standard storage class.

    Conclusion

    As enterprises leverage the agility provided by public cloud environments, it’s important to understand the various facets of Cassandra deployments to ensure the efficient use of your money and time.

  • Data Protection for Operational Reporting Platforms

    Data Protection for Operational Reporting Platforms

    Making real-time business decisions based on data from social, mobile and cloud platforms is a requirement in today’s world. That’s why an ecosystem of next-generation operational reporting platforms such as Spark, Apache Cassandra, Kafka, Docker, Mesos, Marathon and more have come to life. Enterprises are using these technologies to re-architect their data storage and processing frameworks to achieve lower costs, scalability and faster response times. However, as enterprises onboard business-critical applications on this next-generation technology stack, they need to prepare for failures or errors that may disrupt customer-facing applications.

    One of the key benefits that operational reporting platforms provide is real-time visibility, which allows businesses to make strategic decisions based on actionable insights. However, the new applications generate a large amount of data and archaic operational reporting platforms (those based on traditional data warehouses, data marts and ETL logic) are unable to catch up and, as a result:

    • Business decisions are based on stale data
    • Fragmented data increases the risk of errors
    • Multiple copies of data increase storage costs

    These issues have driven many progressive, data-centric enterprises to re-architect their operational reporting platforms. In this new architecture, Kafka serves as a persistent message bus that ingests data from relational stores and provides failure resiliency and message buffering. Spark or Spark Streaming may be used for transformation, aggregation and other lightweight stream processing. These processing nodes may be deployed in Docker containers. Finally, Apache Cassandra serves as a distributed data storage layer that provides linear scalability and high-availability. Kafka also enables the ability to add multiple data consumers such as Hadoop/HBase through Flafka.

    Datos IO - operational reporting platforms

    However, as enterprises adopt operational reporting platforms, they want to ensure that bad data feeds and human error do not result in data loss. Apache Cassandra natively replicates data but that does not provide the capability to go back in time to recover data efficiently and at scale.

    As enterprises onboard their critical applications to achieve development agility, scalability and lower operating costs, they must also explore data protection solutions that are specifically dedicated for scale-out databases.

  • Rackspace Becomes AWS DevOps Competency Partner

    SAN ANTONIO, TX–(Marketwired – April 14, 2016) – Rackspace® (NYSE: RAX) has achieved Amazon Web Services™ (AWS) DevOps Competency within the AWS Partner Competency Program, which recognizes members of the AWS Partner Network who have completed a rigorous third-party audit demonstrating their expertise in DevOps practices, tools, and proven customer success. Customers can access this expertise and 24×7 operational support through Fanatical Support® for AWS architects and engineers, who collectively hold over 270 AWS Professional and Associate certifications across the globe.

    Historically, the process of deploying and managing applications has been manually intensive and customized. Manual deployment and management of applications generally leads to outcomes such as fewer release cycles, longer lead times, and unpredictable quality, all of which impact time to market and stable operations. Applying those manual and custom practices in a cloud environment negates the inherent advantage of software defined infrastructure. DevOps is the use of practices, tools and automation that can improve the efficiency of how businesses run applications in the cloud.

    Fanatical Support for AWS provides businesses access to certified AWS experts who can help implement and operate workloads on AWS using DevOps practices and tooling, both from AWS and leading 3rd parties. Rackspace DevOps expertise can help customers improve the speed, frequency, and quality of their software deployments and the accompanying operational processes. Customers using the Aviator™ service receive ongoing support for native AWS DevOps tools such as AWS OpsWorks, AWS CloudFormation, AWS CodeDeploy, AWS CodePipeline and AWS CodeCommit. As an additional service, Rackspace engineers can utilize a broad range of leading third-party DevOps tools, such as Chef™, SaltStack, and Ansible to help ensure that customers have choice around their preferred DevOps toolset.

    “Rackspace has been active in DevOps practices since 2012, working to help customers increase speed and consistency in their operations. We are excited to be recognized by AWS and to apply our knowledge to customers working on the AWS platform,” said Chris Cochran, senior vice president and general manager of AWS at Rackspace. “Not all customers start with a high degree of expertise in this area, but Rackspace can help these businesses continually improve their efficiency with running apps in the cloud.”

    For more information about Rackspace’s achievement of the AWS DevOps Competency, please visit http://blog.rackspace.com/rackspace-achieves-aws-devops-competency/.

    For more information on Fanatical Support for AWS, please visitwww.rackspace.com/aws.

    About Rackspace
    Rackspace (NYSE: RAX), the #1 managed cloud company, helps businesses tap the power of cloud computing without the challenge and expense of managing complex IT infrastructure and application platforms on their own. Rackspace engineers deliver specialized expertise on top of leading technologies developed by AWS, Microsoft, OpenStack, VMware and others, through a results-obsessed service known as Fanatical Support®. The company has more than 300,000 customers worldwide, including two-thirds of the FORTUNE 100. Rackspace was named a leader in the 2015 Gartner Magic Quadrant for Cloud-Enabled Managed Hosting, and has been honored as one of Fortune’s Best Companies to Work For in six of the past eight years. Learn more atwww.rackspace.com.

    Forward Looking Statement
    This press release contains forward-looking statements that involve risks, uncertainties and assumptions. If such risks or uncertainties materialize or such assumptions prove incorrect, the results of Rackspace Hosting could differ materially from those expressed or implied by such forward-looking statements and assumptions. All statements other than statements of historical fact are statements that could be deemed forward-looking statements, including any statements concerning expected development, performance or market acceptance associated with Fanatical Support for AWS; anticipated operational and financial benefits from Fanatical Support for AWS; any statements of expectation or belief; and any statements of assumptions underlying any of the foregoing. Risks, uncertainties and assumptions including the possibility that expected benefits from Fanatical Support for AWS may not materialize because this product is not generally accepted in the marketplace, which could occur due to certain factors including (i) a failure to market the product cost effectively, differentiate the product from competitive products or communicate differentiations effectively, (ii) the reliability, quality or compatibility associated with the product, (iii) changes in technology which adversely effect the product’s benefit, (iv) slowdowns in the general economy or technology industry that impact consumer spending habits, (v) internal strategy decisions that impact the product, and (vi) other risks that are described in Rackspace Hosting’s Form 10-K for the fiscal year ended December 31, 2015, filed with the SEC on February 26, 2016. Except as required by law, Rackspace Hosting assumes no obligation to update these forward-looking statements publicly, or to update the reasons actual results could differ materially from those anticipated in these forward-looking statements, even if new information becomes available in the future.

    Media Contact:
    Brandon Brunson
    brandon.brunson@rackspace.com
    210-312-1357

  • Threat Stack Cloud Security Platform™ Achieves AWS Security Competency

    Threat Stack Earns Competency for Comprehensive Security and Seamless Customer Experience

    BOSTON – April 7, 2016 – Threat Stack, a leader in cloud security management and compliance, today announced that it has achieved the Amazon Web Services (AWS) Security Competency as part of the AWS Competency Program for the Threat Stack Cloud Security PlatformTM(CSP).

    “Security starts with visibility and Threat Stack offers unparalleled visibility across our systems and cloud infrastructure,” said Chris Haag, Director of Engineering, Agari. “The Threat Stack Cloud Security Platform offers both intelligent anomaly detection and a highly flexible rules engine to detect suspicious behaviors such as privilege escalation, data exfiltration and unusual network activity.”

    The AWS Competency Program is designed to highlight members of the AWS Partner Network (APN) who have demonstrated technical proficiency and proven customer success in specialized solution areas such as Security. The Threat Stack Cloud Security Platform™ attained security competency based on proven success in building products and solutions on AWS to support customers in the area of configuration and vulnerability analysis.

    “We strongly believe that a layered approach to cloud security is best, which makes Threat Stack CSP an essential complement to AWS,” said Brian Ahern, chairman and CEO, Threat Stack. “Threat Stack provides the deep visibility needed to identify insider threats and intrusions, prevent data loss and meet compliance regulations when building and running on AWS. Achieving AWS Security Competency Partner recognition demonstrates our commitment to protecting customers’ workload and broader environment from threats.”

    Threat Stack CSP is an industry leading, fully integrated cloud security suite. Cloud-native and platform-independent, Threat Stack CSP measurably reduces the expense and complexity required to identify threats, keep data protected and automate compliance requirements. Threat Stack CSP offers instant visibility and deep correlated context that enables companies to operate efficiently, prevent data loss and identify and verify threats.

    About Threat Stack

    Threat Stack enables growth-driven companies to scale with confidence by identifying and verifying insider threats, external attacks and data loss in real-time. The only fully integrated, cloud-native continuous monitoring solution that gives companies instant visibility and automatically responds to changes in their environment, Threat Stack provides the coverage needed to run secure and compliant, in all environments, without sacrificing speed and efficiency. For more information, or to start a free trial, visit threatstack.com.