Product docs and API reference are now on Akamai TechDocs.
Search product docs.
Search for “” in product docs.
Search API reference.
Search for “” in API reference.
Search Results
results matching
results
No Results
Filters
Migrate From AWS Security Groups to Cloud Firewalls
Traducciones al EspañolEstamos traduciendo nuestros guías y tutoriales al Español. Es posible que usted esté viendo una traducción generada automáticamente. Estamos trabajando con traductores profesionales para verificar las traducciones de nuestro sitio web. Este proyecto es un trabajo en curso.
Amazon Web Services (AWS) Security Groups are virtual firewalls that control inbound and outbound traffic to AWS resources like EC2 instances. They operate at the instance level and allow administrators to define traffic rules based on IP addresses, protocols, and ports.
Cloud Firewalls on Akamai Cloud is a network-level firewall service that lets users control traffic for Linode instances and NodeBalancers, Akamai Cloud’s load balancing service. Cloud Firewalls support inbound and outbound traffic management for Linode instances and inbound traffic for NodeBalancers. They operate at Layers 3 and 4 of the OSI model (see diagram below), providing IP, protocol, and port filtering.
This guide includes steps on how to migrate a basic security setup from AWS Security Groups to Cloud Firewalls. It covers planning, documenting your configuration, creating equivalent rules with Cloud Firewalls, and testing results to ensure network security after migration.
Feature Comparison
Before beginning the migration process between service providers, it’s important to understand the capabilities and specifications of both AWS Security Groups and Cloud Firewalls. This can help optimize your results by identifying which rules can be migrated directly and which may require additional configuration.
Features of AWS Security Groups
AWS Security Groups allow you to create sets of firewall rules that control traffic based on IP addresses, CIDR blocks, ports, and protocols. Security groups are stateful (i.e. return traffic is automatically allowed) and attach directly to the network interfaces of your AWS resources.
Features of Cloud Firewalls
Cloud Firewalls on Akamai Cloud is a Layer 3/4 stateless packet filter designed for simplicity and performance. It allows users to specify rules that allow or deny traffic based on source IP, destination port, and protocol (e.g. TCP, UDP, ICMP, and IPEncap). The Cloud Firewalls service does not inspect application-layer traffic; however, it is effective at managing access to services based on IP and port-level rules.
What’s Not Directly Portable
Since Cloud Firewalls doesn’t currently support Layer 7 inspection, features such as pattern matching, geographic filtering, and rate limiting cannot be replicated natively. These must be implemented at the application level using reverse proxies like NGINX or other third-party services.
Before You Begin
Complete the following prerequisites prior to following the steps in this guide.
Follow our Get Started guide to create an Akamai Cloud account if you do not already have one.
Create a personal access token using the instructions in our Manage personal access tokens guide.
Install the Linode CLI using the instructions in the Install and configure the CLI guide. See our API reference for comprehensive documentation of Linode CLI functionality.
You need an AWS account with a user or role that has permission to list, view, and modify EC2 networking settings and Security Groups.
Ensure the version 2 of the AWS CLI is installed locally and configured (via
aws configure) for the appropriate credentials and default region.
Example Environment Used in This Guide
The example used throughout this guide involves an AWS Security Group associated with a single Amazon EC2 instance. The EC2 is configured for multiple services:
- Web traffic handled by NGINX on ports
80and443 - PostgreSQL database on port
5432 - SSH on port
22 - Redis on port
6379
The AWS Security Group is configured with inbound rules to restrict access to known IP addresses.
The equivalent setup on Akamai Cloud uses a single Linode instance running the same services. The Cloud Firewalls service is used to recreate the access controls previously handled by the AWS Security Group.
Document Your Current Configuration
Before making changes, it’s essential to fully understand your existing AWS EC2 and Security Group configuration. Document and template how traffic flows to your EC2 instance by noting which ports are open and which services are bound to each port. This can help you set up equivalent access controls using Cloud Firewalls.
Review AWS Security Group Rules
Use the AWS Console or aws CLI to export or list your active Security Group rules.
In the AWS Console, navigate to the EC2 service.
Select the appropriate EC2 instance to view its details.
Under the Security tab, select the Security Group associated with the EC2 instance to view a list of inbound rules for the Security Group:
The example in this guide only has inbound rules, with traffic allowed for specific IP addresses. The inbound permissions for the example in this guide are diagrammed below:
Plan Your Rule-Mapping Strategy
After documenting your AWS configuration, plan how to translate those rules using the Cloud Firewalls syntax and feature set.
In this example, core services are exposed on ports 22, 80, 443, 5432, and 6379. The AWS Security Group allows access to certain ports (5432 and 6379) only from an approved IP allowlist, while traffic from any source can reach ports 22, 80, 443. These rules must be recreated on Akamai Cloud to maintain equivalent protection.
It can be helpful to create a side-by-side comparison, mapping AWS Security Group rules to their Cloud Firewalls equivalents. For example, a rule that allows PostgreSQL traffic (TCP 5432) from a specific IP should be represented as a Cloud Firewalls rule allowing TCP traffic on port 5432 from that same IP.
Back up Your Existing Configuration
Before disabling or removing AWS services, create a backup of all relevant configuration data.
Export your existing Security Group configurations by running the following command and saving the output to a file:
aws ec2 describe-security-group-rules \
--region AWS_REGION \
--filters Name=group-id,Values=SECURITY_GROUP_ID \
--output json \
> sg-rules.jsonCreate Equivalent Rules with Cloud Firewalls
Once planning and documentation are complete, begin building your new network firewall configuration in Akamai Cloud.
Cloud Firewalls rules can be managed through the Cloud Manager web interface or via the Linode CLI. This section demonstrates both methods.
Enable Cloud Firewalls
While logged into Cloud Manager, navigate to the Firewalls dashboard, and click Create Firewall.
Specify a label for the Cloud Firewall and accept the defaults for the inbound and outbound policies, and click Create Firewall. Initially, you do not need to assign any services. You can focus on rule creation first, then associate services later.
Once the Cloud Firewall has been created, you should see an initially empty list of inbound and outbound firewall rules.
Recreate Rules
Recreate each of the rules documented from your AWS Security Group.
Select your Cloud Firewall, and create a new rule by clicking Add An Inbound Rule.
Specify a label and description for the rule. For example:
Next, select the protocol and which ports to apply this rule to. You can select from commonly used ports or select Custom to specify a custom port range. For example:
For Sources, specify whether you want the rule to apply to all IPv4 or IPv6 addresses, or if you want to provide specific IP addresses. If providing specific IP addresses, add them one at a time. See our guide on managing firewall rules for syntax specifications.
Finally, decide whether the rule is meant to serve as an allowlist (Accept) or denylist (Drop). For this example migration from AWS Security Groups, the action would be Accept. Click Add Rule.
Repeat the steps above to recreate all the equivalent rules from the AWS Security Group configuration.
After adding all rules, click Save Changes.
Attach Instances to the Firewall
You can attach multiple Linodes or NodeBalancers to the Cloud Firewall. Note that inbound and outbound rules apply to Linode instances, whereas only inbound rules apply to NodeBalancers.
See our additional migration documentation for guidance on migrating other services – such as compute instances – to Akamai Cloud.
Navigate to the Linodes tab for your Cloud Firewall and click Add Linodes to Firewall:
From the list, select which Linode (or Linodes) to assign to the Cloud Firewall and click Add:
The firewall rules you specified should now be applied to the Linode (or Linodes) you have added.
Test and Validate Your Configuration
After applying rules to your Cloud Firewalls, confirm that they behave as expected under real traffic conditions. Note that your firewall configurations may require different testing methods than those listed in this section.
Simulate Expected and Blocked Traffic
From an IP on the allowlist, test access for each service and confirm that the connection succeeds to your instance’s endpoint. Use ssh to test connections from any IP address.
In all examples, replace SERVER_IP_ADDRESS with the IP address of the instance assigned to your Cloud Firewall (e.g. 172.236.228.122).
Use
curlto test HTTP traffic through NGINX:cURL HTTP Connection Attemptcurl -I http://SERVER_IP_ADDRESSHTTP/1.1 200 OK Server: nginx/1.24.0 (Ubuntu) Date: Mon, 28 Apr 2025 21:00:32 GMT Content-Type: text/html Content-Length: 615 Last-Modified: Mon, 28 Apr 2025 20:58:01 GMT Connection: keep-alive ETag: "680febd9-267" Accept-Ranges: bytesSimilarly, you can also use
curlto test HTTPS traffic through NGINX:cURL HTTPS Connection Attemptcurl -I https://SERVER_IP_ADDRESSHTTP/1.1 200 OK Server: nginx/1.24.0 (Ubuntu) Date: Mon, 28 Apr 2025 21:02:02 GMT Content-Type: text/html Content-Length: 615 Last-Modified: Mon, 28 Apr 2025 20:58:01 GMT Connection: keep-alive ETag: "6434bbbe-267" Accept-Ranges: bytesNote If you generated a self-signed certificate, skip certificate verification by adding the
-kflag:curl -Ik https://SERVER_IP_ADDRESSAttempt to connect to the PostgreSQL server with the
psqlclient from an allowed IP address, replacing PSQL_PORT (e.g.5432), PSQL_USERNAME (e.g.testuser), and PSQL_DATABASE (e.g.testdb):Successful PostgreSQL Connection Attemptpsql --host SERVER_IP_ADDRESS \ --port PSQL_PORT \ --username PSQL_USERNAME \ --dbname PSQL_DATABASE \ --passwordPassword: ******** psql (17.2 (Ubuntu 17.2-1.pgdg20.04+1), server 16.8 (Ubuntu 16.8-0ubuntu0.24.04.1)) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off, ALPN: none) Type "help" for help. tesdb=#In contrast, if you attempt to connect to the PostgreSQL server with the
psqlclient from an IP address not allowed through the Cloud Firewall rules, the execution hangs after prompting for the password:Blocked PostgreSQL Connection Attemptpsql --host SERVER_IP_ADDRESS \ --port PSQL_PORT \ --username PSQL_USERNAME \ --dbname PSQL_DATABASE \ --passwordPassword: ********Attempt to connect to Redis with
redis-clifrom an allowed IP address, replacing REDIS_PORT (e.g.6379):Successful Redis Connection Attemptredis-cli -h SERVER_IP_ADDRESS -p REDIS_PORTThe result should be similar to the following:
172.236.228.122:6379> INFO Server # Server redis_version:7.0.15 … executable:/usr/bin/redis-server config_file:/etc/redis/redis.conf io_threads_active:0Now attempt to connect to Redis with
redis-clifrom an IP address that is not on the allowlist:Blocked Redis Connection Attemptredis-cli -h SERVER_IP_ADDRESS -p REDIS_PORTThe connection attempt simply hangs:
Log and Monitor Behavior
The Cloud Firewalls service does not show per-packet or rule-level logging. To verify behavior, rely on logs from the services themselves. For example:
- NGINX access logs, as configured in individual virtual server configuration files, are found in
/etc/nginx/sites-available. - SSH authentication logs are located at
/var/log/auth.log. - Redis logs are typically found in
/var/log/redis/redis-server.log, though this is configurable in/etc/redis/redis.conf. - PostgreSQL logs are typically found in
/var/log/postgresql/, though this is configurable in/etc/postgresql/[PATH-TO-VERISON]/postgresql.conf.
Connection and activity logs from these services can help to confirm whether traffic is reaching them as expected.
Monitor Post-Migration Performance
Ongoing monitoring helps identify any overlooked configuration issues or unexpected traffic patterns. Continue observing application logs and metrics post-migration. Make sure services are available to intended users and there are no spikes in error rates or timeouts.
If legitimate traffic is being blocked or malicious traffic is being allowed, refine your Cloud Firewalls rules. It may take a few iterations to achieve parity with your original AWS Security Group behavior.
Finalize Your Firewall Migration
Once you’ve validated the new firewall configuration, clean up legacy resources and update internal references:
- Find components that were connecting with your AWS EC2 instance.
- Create equivalent rules with Cloud Firewalls to allow traffic from legitimate components.
- Remove the AWS Security Group.
- Remove the AWS EC2 instance.
Update runbooks, internal network diagrams, and configuration documentation to reflect the new firewall architecture based on Cloud Firewalls.
More Information
You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.
This page was originally published on
