How to set up a Cloud Competence Centre

CATEGORIES

Blog

To be able to talk about the Cloud Competence Centre model, a bit of background is needed. There’s usually a set of typical phases in a company’s Cloud Journey. You might start off with a few teams experimenting with cloud platforms for new application development, and, with the experiences gained from these projects, you can start planning how to move existing workloads to the cloud. As time goes by you realise that you’re running many different types of production workloads in the cloud with dependencies on each other and on-premise environments.

It’s quite typical at this point to realise that all these environments should be managed with a proper Governance Model. The cloud provides a wide set of tools to extract many of the things that required a lot of work in the past. This includes managed databases, managed load balancers, virtual networking etc. At the same time, the Cloud Platform itself has to be managed in some way and certain questions need to be asked. How do we design our AWS Account or Azure Subscription structure? How do we provide and monitor access to these environments? How is networking managed? Should we have a baseline for security components across the environments?

Managing a cloud platform requires ownership, typically seen in a Cloud Owner and a Cloud Steering Group. It also requires a centralised function to onboard cloud customers, do cloud platform development and maintain best practices for cloud deployments. Setting up a Cloud Competence Centre addresses exactly these needs.

What does a Cloud Competence Centre do?

A Cloud Competence Centre is a support function to increase developer productivity and maintain a consistent and secure cloud platform. The two key processes are Cloud Platform Development and Cloud Customer On-boardingCloud Platform development consists of setting up a Landing Zone and maintaining it. There’s requirement coming from development teams, Cloud Steering Group and the Cloud Competence Centre itself for shared services, security components, best practice architectures and template solutions. All of these are implemented and maintained by the Cloud Competence Centre.

Cloud Customer On-boarding is the process of introducing a development team to the Cloud Platform and making sure they follow best practices for architecture, security, and cost management. The Cloud Competence Centre also sets up any required accounts, networking and access for the team to quickly get started with the actual development.

What are the typical challenges in setting up a Cloud Competence Centre?

  • There’s limited understanding on public cloud platforms and how to leverage them in the organisation
  • As cloud is a new concept, it’s hard to figure out who owns it in the organisation
  • The new function requires a budget to operate which can be hard to get
  • Some development teams feel they can manage the platform themselves without the support of a Cloud Competence Centre
  • A lot of projects are already running in the cloud without a proper governance model

How can you mitigate these challenges?

  • Create a Cloud Governance Model early on in the Cloud Journey
  • Make sure all stakeholders understand the importance of managing the cloud platform and supporting development teams
  • Train the people on the benefits and new concepts of public cloud platforms
  • Get support from a skilled partner to set up the Cloud Competence Centre working together with your own team

The key thing to keep in mind when setting up a Cloud Competence Centre is that it has to provide value to its customers (the development teams). The Cloud Competence Centre has to be very skilled in the selected cloud platform and also be able to communicate and document how to leverage the cloud. When you provide the teams a service that speeds up their work and makes their journey to the cloud easier, there will be less Shadow IT and more consistent, secure and automated environments across all business units.

If you would like more information on how Nordcloud can help you set up your business’s Cloud Competence Centre, visit our services page, or contact us here.

Blog

Starter for 10: Meet Jonna Iljin, Nordcloud’s Head of Design

When people start working with Nordcloud, they generally comment on 2 things. First, how friendly and knowledgeable everyone is. Second,...

Blog

Building better SaaS products with UX Writing (Part 3)

UX writers are not omniscient, and it’s best for them to resist the temptation to work in isolation, just as...

Blog

Building better SaaS products with UX Writing (Part 2)

The main purpose of UX writing is to ensure that the people who use any software have a positive experience.

Get in Touch

Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.








    Is it safe to use AWS S3 after all the news about data breaches?

    CATEGORIES

    Blog

    There has recently been a lot of news about data breaches on AWS S3 (Simple Storage System). Sensitive data, passwords and access credentials have been exposed to the whole world.

    For many, this might have led to the assumption that S3 itself would be insecure and it would be better to avoid using it. The truth is quite the opposite. S3 is totally suitable for storing even sensitive data. As in most cases, the S3 data breaches happened because of human error and misconfiguration, not because of security issues in the service itself.

    What is S3 and how do data leaks happen?

    So, let’s rewind a bit to get to the bottom of this. What is S3? It’s a managed, highly available and highly scalable object storage which is used over an API. Typically, you access this API with secure credentials created for an AWS user. You create “Buckets” and store your objects (files) inside these buckets. You don’t provision any storage beforehand; you just use as much as you like and pay for what you use. S3 was one of the first services introduced by AWS over 10 years ago and has been truly battle-tested on performance, security and availability. It’s also one of the backbone services of AWS and is widely used by other AWS services too.

    So how do data leaks happen? The simple reason is that you can make your buckets or single objects inside a bucket public. This means that anyone with the correct URL can access that object. This is a very useful feature for sharing files to your users and it is widely used to deliver the static content of web applications. But no data inside S3 is ever public by default. You need to separately enable this.

    There are multiple ways to make objects public on bucket and object level including Bucket policies, Bucket ACLs and Object ACLs. This can be confusing but luckily AWS has recently introduced extremely good indication in the Management Console on what data is public and why. It takes some effort and lack of understanding to get this wrong if you make use of this information. In addition to this, there are AWS services like AWS Config and Trusted Advisor that can also give you reports on your publicly open buckets.

    Why do data leaks happen then?

    There are few typical explanations for this:

    1. The main reason is the lack of governance in the organisation. Governance and standards should be in place to ensure that best practices of the platform, as well as company cloud policies, are followed. This includes access management of S3 buckets.
    2. Without proper AWS knowledge, developers or operators don’t understand how S3 works. They might open the buckets for public access just to be able to access the data from an application that could use access credentials instead. They might not understand that “public” means “public”. It requires understanding of AWS Identity and Access Management together with IAM policies and Bucket policies to get this right.
    3. It might be that some “convenient” pre-created S3 Bucket is used for multiple different types of data including sensitive data and the bucket is exposed publicly for the original use case. Again, it comes down to understanding how S3 works.
    4. Some 3rd party tools that upload files to S3 might have default or optional settings to make the objects’ public with an object ACL during the upload. In some cases, it might be that these tools are used and that’s the reason for the public access. Again, understanding how S3 and AWS in general works would mitigate this.

    Understand the AWS platform

    To recap, it all comes down to basic training and understanding on the AWS platform. And this is not limited to S3. In some cases, there’s public access to services because AWS networking, firewall and access management concepts are not understood correctly. It might be that you don’t have proper authentication settings in place in the actual AWS accounts. Or it might be just that general security principles like proper patching plan are not followed.

    There’s a lot to learn when starting a cloud journey and a proper cloud foundation must be built for networking and security together with educating people on how to use the services. Luckily, we are here to help you out with all of that!

    Blog

    Starter for 10: Meet Jonna Iljin, Nordcloud’s Head of Design

    When people start working with Nordcloud, they generally comment on 2 things. First, how friendly and knowledgeable everyone is. Second,...

    Blog

    Building better SaaS products with UX Writing (Part 3)

    UX writers are not omniscient, and it’s best for them to resist the temptation to work in isolation, just as...

    Blog

    Building better SaaS products with UX Writing (Part 2)

    The main purpose of UX writing is to ensure that the people who use any software have a positive experience.

    Get in Touch

    Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.








      5 AWS services that help you create and monitor secure environments in the cloud

      CATEGORIES

      Blog

      One typical concern when moving your infrastructure to Amazon Web Services is that you may lose control over it, but the truth is quite the opposite; AWS will take care of everything on the physical side of your infrastructure (while being compliant with basically every relevant certification and regulation) so you can focus on managing and monitoring the services that you use – and there are plenty of tools on AWS to do that.I will introduce five important services that are connected to managing security and monitoring your environment in the AWS Cloud. I won’t go too deep into details here but rather give an overview of these services and how they work together.

      Virtual Private Cloud (VPC)

      A Virtual Private Cloud (VPC) is your own private cloud inside AWS. Here you define all the networking details and manage how your instances can be accessed. You can use things like Route Tables and Network Access Control Lists to manage traffic flow in and out of (and within) your environment. In addition to EC2 instances, you can also put your relational databases (RDS) inside a VPC to make sure that they can only be accessed by your application servers. You have complete control over how your instances can be accessed and you can even limit this to a VPN connection from your on-premise environment. VPC has way too many features to be described in one blog post but you definitely want to learn to build VPCs as your first steps towards the AWS Cloud!

      CloudWatch

      Once you have deployed your instances to a VPC, you want to monitor them. CloudWatch is a service that automatically collects metrics from your infrastructure and also from basically every managed service that AWS has to offer. You can use this data to trigger alarms that can, for example, send you e-mails or launch more EC2 instances to an Auto Scaling group. You can view graphs of your metrics from the past two weeks in the CloudWatch console or send those metrics to 3rd party services like DataDog for further analysis. CloudWatch is one of the main tools to create automation for your infrastructure so that you don’t need to manually react to traffic peaks or issues in your environment.

      CloudTrail

      While CloudWatch is great for monitoring your infrastructure, it doesn’t track access to your AWS environment. CloudTrail is a service that you can enable per region and it will track all API calls (meaning all actions) that are done by your AWS users or roles. All of this data is stored in S3 and you can send it to CloudWatch Logs or 3rd party services for further analysis. CloudTrail will give you detailed information on who did what and when. This can also be very useful for audit purposes.

      AWS Config

      If CloudTrail is for tracking each and every action users make, then AWS Config is a service that will track the state of your environment. You will get detailed information on changes that are made to your resources and also reports on the state of your whole infrastructure. AWS Config provides point in time snapshots of your resources. You can also create Config Rules that are evaluated against changes in your resources and the rules can alert you on unwanted changes and possible security issues.

      Simple Notification Service (SNS)

      Simple Notification Service is a service that delivers messages to subscribers. It is widely used by other AWS services, including the ones listed here, to send you notifications on things that happen in your environment. You can use it together with alarms that you create in CloudWatch to get notifications when an alarm is triggered. You create Topics and publish messages to these Topics. A Topic can have multiple subscribers that will receive all messages published to the Topic. The subscribers can be a number of things from HTTP endpoints to e-mail and Lambda functions.

      Security in the cloud starts with good knowledge of your infrastructure and extensive monitoring. The services I have described here can be used to achieve just that. There is of course, a lot more to consider when talking about the security of your environment. If you would like to talk to Nordcloud more about your cloud environments, contact us here.

      Blog

      Starter for 10: Meet Jonna Iljin, Nordcloud’s Head of Design

      When people start working with Nordcloud, they generally comment on 2 things. First, how friendly and knowledgeable everyone is. Second,...

      Blog

      Building better SaaS products with UX Writing (Part 3)

      UX writers are not omniscient, and it’s best for them to resist the temptation to work in isolation, just as...

      Blog

      Building better SaaS products with UX Writing (Part 2)

      The main purpose of UX writing is to ensure that the people who use any software have a positive experience.

      Get in Touch

      Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.