Instructions on how to set time_zone Session Parameter with RDS

After much search and finding refrences like these that deem this impossible, even by AWS support, we have figured out how to set the default time zone for every session.

The reason AWS doesn’t support this is because it messes with the Replication/Multi-AZ and other aspects of the proprietor MySQL architecture on RDS.

Amazon RDS doesn’t allow you to change timezone, It keeps same UTC time zone across all regions.

The time_zone variable in the parameter group is read only, however if you have had to deal with these limitations you might be familiar with the init_connect command, the only problem is that if you use init_connect to change the time you can totally mess up your database when the rdsadmin user does DBA procedures on your MySQL database.

You can change the time zone on each connection or session by making a procedure in default mysql database and call this function on each init connection as long as the session does not belong to the SUPER privileged, automatically created and necessary rdsadmin user.

1- Create the procedure where -4 is the time difference with UTC

CREATE DEFINER=`mysql`@`%` PROCEDURE `fix_time`()
IF CURRENT_USER()<>’rdsadmin@%’ THEN
SET SESSION time_zone =’-4:00′;

2- Update your custom parameter group to call this stored procedure at the beginning of each session:

You can create/edit Parameter Groups from the AWS RDS web console, or use aws-cli like this to set the init_connect to CALL fix_time():

aws rds modify-db-parameter-group --db-parameter-group-name parameter_group_name --parameters "ParameterName=init_connect, ParameterValue=CALL mysql.fix_time, ApplyMethod=immediate"

3- Finally make sure your instance uses this parameter group, reboot an Valla!



Amazon CloudFront Now Support Configurable Default TTL and Max TTL

Amazon CloudFront now allows you to set two new values, a Default TTL (Time To Live) and a Max time-to-live, so that you can control how long CloudFront caches your objects in each CDN node. This dramatically increases your control over the cache duration which previously only allowed you to set the Minimum TTL. Learn more about setting cascading cache rules for CloudFront here.

You can now set a TTL without setting cache control headers on each object at the origin, If you can’t set cache-control headers at your origin that was the case for many people who were using a third-party CMS.

Override cache-control headers set by your origin so that they don’t rely on the cache-control headers set by your origin specially when you don’t control the origin server, you can now easily override the cache-control headers by setting the same value for Max TTL, Min TTL and Default TTL.

Ensure that TTLs are always within a range you specify when setting both a Min TTL and a Max TTL, you can override origin configurations that might cause objects to be cached for longer or shorter periods than you intended.

There are no additional charges for configuring Min TTL, Max TTL, or Default TTL. You can learn more about these new features by reading the Specifying How Long Objects Stay in a CloudFront Edge Cache section on the Amazon CloudFront Developer Guide.

Mod Security & Amazon Cloud Front Problems

Misuse of CloudFront by hackers can get your CDN blocked by your server, this can be a problem. Unfortunately for security reasons you do not want to allow CloudFront to by pass mod security, as this can be exploited by Mod Security: # lfd: (mod_security) mod_security (id:210410) triggered by (US/United States/ 5 in the last 3600 secs – Thu Mar 12 22:13:57 2015 # lfd: (mod_security) mod_security (id:950103) triggered by (US/United States/ 5 in the last 3600 secs – Sun Mar 15 23:38:33 2015 # lfd: (mod_security) mod_security (id:220030) triggered by (US/United States/ 5 in the last 3600 secs – Mon Mar 16 07:07:34 2015

We are considering to make an effort to build something to allow Mod Security to block X-IP-ADDRESS header instead of the actual IP which belongs to the CDN, meanwhile the best thing you can do is to make sure while mod security blocks risky requests, it doesn’t become black listed.
Here is the full list of IP address ranges used by Amazon Cloud Front up to this date, add them to your “Firewall Allow IPs” list:

Amazon Route 53 Changing Health Checking IP Ranges

If you’re using Route 53 health checks, you must ensure that your router and firewall rules allow inbound traffic from the IP addresses used by Route 53’s health checkers, so that Route 53 can access the endpoints that you specify in your health checks.

As we have explained earlier in our forum post [ ], we are adding new IP ranges to the existing ranges.

The following is the list of existing IP ranges currently used by Route53 health checking service:

In addition to the list above, the following is the list of new IP ranges from which Route 53 will be conducting health checks:

Please ensure that the router / firewall rules for all of your endpoints that you are health checking with Route 53 are configured to allow incoming traffic from both existing and new IP ranges.

AWS SDK Loader Module For Prestashop

We have finished the first version of the Prestashop Module to load the AWS SDK Loader. The purpose of this module is to allow developers and site owners to use and develop custom scripts and modules that work with the Amazon Web Services PHP SDK, with the separation of concerns and preventing conflict between multiple modules as a result of each loading the SDK independently.


Here are some of the features of the AWS SDK Module for Prestashop:

  • Load The Aws SDK onto every PHP page with the option to choose the SDK to load in the back office, front office, or both.

  • Load only the Classes you need for your application for performance optimization and security concern, for instance you can only choose to load the code for Amazon S3.

  • Allow other modules to use the AWS SDK without conflict or the need to load and maintain the SDK individually.

  • All patches and updates will be automatic with backward compatibility for dependent modules.

With a single click install you will be able to use AWS SDK on anypage by simply using the following syntax and declaring the namespace:

use AwsCommonAws;

// Instantiate the service builder
$aws = Aws::factory(‘/path/to/your/config.php’);

// Instantiate S3 clients for example
$s3v2 = $aws->get(‘s3’);


PrestaShop Amazon Web Services Module

ColumbusSoft has submitted the PrestaShop Amazon Web Services Module to the Official PrestShop Addons site.

This Module will allow you to load the AWS SDK for PHP, to be used by other modules or custom scripts without any conflicts as a result of each loading the SDK separately. Once enabled, you can access the AWS SDK from any php file in Prestashop.


We have developed this free module in the process of the Amazon S3 Bucket Upload Module that we are currently building for prestashop. All developers can take advantage of this module as a requirement.


This module has the following benefits:
1- Access the AWS SDK for php anywhere in presta shop with the same syntax offered by the SDK and examples:
2- Install and use Multiple AWS Modules without conflict.
3- PrestaShop users can write custom code and scripts in PrestaShop php files by simply delaring the AWS namespace.
4- This Module allows other developers to create their own AWS modules that will run alongside other AWS Modules without any conflict as it is not possible to load the AWS-SDK twice, so modules can require this Module as a requirement before installation. For example the AWS S3 Bucket Module by ColumbusSoft.
5- Developers do not have to worry about applying AWS SDK upgrades and backwards compatibilities, a good seperation of concerns.



1- Access the AWS SDK for php anywhere in presta shop with the same syntax offered by the SDK and examples:

2- Use Amazon S3 Bucket, and use Amazon S3 Stream Wrapper:

3- Use AWS CloudFront, Transcoder and anyother AWS Solution to wish to implemend.


Minimum requirements – To run the SDK, your system will need to meet the minimum requirements, including having PHP 5.3.3+ compiled with the cURL extension and cURL 7.16.2+ compiled with OpenSSL and zlib.


This Module will allow you to load the AWS SDK for PHP, to be used by other modules or custom scripts that need this SDK without any conflicts as a result of each module loading its own SDK. Once this module is enabled, you can access the AWS SDK from any php file in Prestashop as you would normally by declaring the namespace,
This module should be used for all AWS Modules to allow them to work simultaneously and efficiently. You can use with the same naming conventions and syntax AWS developers are used to.

Check out the Amazon S3 Module For Presta Uploads.

Mobile Detected
Tablet Detected
Desktop Detected
Large Screen Detected
Retina Display Detected