If you’re considering migrating your business applications to a public cloud, the chances are that you’ve looked into Amazon Web Services. With its higher capacity and wide range of cloud services, AWS has become the most popular choice for businesses looking to take advantage of the scalability and cost-effective storage that cloud computing offers.

Security in AWS is based on a shared responsibility model: Amazon provides and secures the infrastructure, and you are responsible for securing what you run on it.  This model gives you greater control over your traffic and data, and encourages you to be proactive. However, before migrating your applications to AWS, here are some tips on how to manage and enforce security for maximum protection across your AWS and on-premise environment

Understanding security groups

Amazon offers a virtual firewall facility for filtering the traffic that crosses your cloud network segment; but the way that AWS firewalls are managed differs slightly from the approach used by traditional firewalls.

> See also: The great IT myth: is cloud really less secure than on-premise?

The central component of AWS firewalls is the ‘security group’, which is essentially what other firewall vendors would call a policy, i.e. a collection of rules. However, there are key differences between security groups and traditional firewall policies that need to be understood.

Firstly, in AWS, there is no ‘action’ in the rule stating whether the traffic is allowed or dropped. This is because all rules in AWS are positive and always allow the specified traffic – unlike traditional firewall rules.

Secondly, AWS rules let you specify the traffic source, or the traffic destination – but not both on the same rule. For Inbound rules, there is a source that states where the traffic comes from, but no destination telling it where to go.

For Outbound rules it the other way around: you can specify the destination but not the source. The reason for this is that the AWS security group always sets the unspecified side (source or destination, as the case may be) as the instance to which the security group is applied.

Thirdly, AWS is flexible in how it allows you to apply these rules. Single security groups can be applied to multiple instances, in the same way that you can apply a traditional security policy to multiple firewalls.

AWS also allows you to do the reverse: apply multiple security groups to a single instance, meaning that the instance inherits the rules from all the security groups that are associated with it.  This is one of the unique features of the Amazon offering, allowing you to create security groups for specific functions or operating systems, and then mix and match them to suit your business’ needs.

Managing outbound traffic

AWS does manage outbound traffic, but there are some differences in how it does this compared to conventional approaches that you need to be aware of.  With AWS, the user is not automatically guided through the settings for outbound traffic during the initial setup process.

The default setting is that all outbound traffic is allowed, in contrast to the default setting for inbound traffic which denies all traffic until rules are created.

Clearly, this is an insecure setting which can leave your organisation vulnerable to data loss, so it’s advisable to create rules that allow only specific outbound traffic, and protect data that is truly critical.

Because the AWS setup wizard doesn’t automatically take you through the outbound settings, you will need to create these rules manually and apply them.

Auditing and compliance

Once you start using AWS in production, you need to remember that these applications are now subject to regulatory compliance and internal audits. Amazon does offer a couple of built-in features that help with this: Amazon CloudWatch, which acts as a health monitor and log server for your instances, and Amazon CloudTrail, which records and audits your API calls. However, if you are running a hybrid data centre environment, you will require additional compliance and auditing tools.

Depending on which industry you’re in and what type of data you handle, your business will be subject to different regulations – for example, if you process credit card information, you will be subject to PCI.

> See also: Catastrophe in the cloud: what the AWS hacks mean for cloud providers

So if you want to use your AWS cloud platform for this sensitive data, then you will need the right third-party security management products in place to provide you with the same reporting facilities that you would get with a conventional firewall.

The most important thing you need from a third-party solution is visibility of the policies from all security groups and of your whole hybrid estate, together with the same analysis and auditing capabilities as an on-site infrastructure, to give you a holistic view and management of your security environment.

Ultimately, it is your responsibility to secure everything that you put onto an AWS environment. Considering these points and following the steps I’ve outlined will help to ensure that you protect your data and comply with regulatory requirements when migrating to AWS.