How To Run Craft CMS On AWS

Setting up AWS Account and Prerequisites

Creating and Configuring AWS Account

Getting started with AWS begins with creating an AWS account. This provides you access to AWS services and allows you to provision resources like EC2 instances, S3 buckets etc.

When creating the account, choose the appropriate AWS region. The region determines the physical location where your resources will reside. Consider factors like proximity to users, compliance requirements and service availability when selecting the region. London and Ireland are good options for UK-based users.

Also, decide if you need multiple AWS accounts. Separate accounts provide isolation and access control boundaries. For example, you can have separate dev, test and prod accounts.

Cross-account access can be enabled via IAM roles.

Once the account is created, configure IAM (Identity and Access Management) correctly. IAM allows managing users, groups, roles and their permissions to access AWS services.

Best practices are to use the root account sparingly, like just for initial setup. Create individual IAM users for each person accessing AWS. Manage permissions at the group level by creating groups like admins, developers, read-only etc. Assign users to groups to inherit the permissions. Define granular permissions based on the principle of least privilege.

Enable MFA (multi-factor authentication) for all users to add extra security. Use access keys for programmatic access via SDKs or CLIs. Rotate access keys periodically.

Understand the difference between IAM roles and users. Roles are meant for applications and AWS services while users are for personnel.

Understanding AWS Services and Concepts

AWS offers over 200 cloud services spanning compute, storage, database, analytics, networking, security etc. Some key services are:

• EC2 - Virtual servers to run applications. Allows complete control over OS, updates, configurations etc.

• S3 - Object storage service used for data lakes, backups, static websites etc. Provides high scalability and durability.

• RDS - Managed relational databases like MySQL, Postgres, Oracle with auto OS patching and backups.

• DynamoDB - Fully managed NoSQL database for high performance web apps.

• Lambda - Serverless compute to run event-driven functions without managing infrastructure.

• CloudFront - Content Delivery Network to cache and distribute static assets across edge locations.

• VPC - Virtual Private Cloud to provision logically isolated networks in AWS and control IP addressing.

Some key concepts to grasp are:

• Regions - Physical locations with multiple availability zones

• Availability Zones - Isolated data centers within a region for high availability

• VPCs - Logical isolated networks to control IP addressing and security

• Subnets - Segments within a VPC to isolate resources like apps, databases etc.

• Route Tables - Rules to determine how subnets route network traffic internally and externally

Understanding these building blocks will help in designing reliable and secure AWS architectures.

Setting up IAM Users, Roles and Groups

IAM (Identity and Access Management) allows managing access to AWS services and resources securely.

For giving personnel access, create individual IAM users and assign them appropriate permissions. Start with minimum permissions and grant additional access as needed.

Use IAM groups to manage permissions collectively. For example, have an Admins group with full permissions, Developers group with access just to EC2 and S3 etc. Add users to groups to inherit permissions.

IAM roles are meant for giving access to AWS services and applications. For example, Lambda functions can be assigned a role to access S3 and DynamoDB.

Use access levels like read-only or power-user to restrict privileges. Enable MFA for additional security, especially for sensitive accounts like admins.

Configure a password policy that enforces minimum length, special characters, rotation etc. Integrate AWS accounts with on-premises identity providers via federation.

Monitor IAM activity via tools like CloudTrail. Regularly audit permissions and remove stale accounts/roles to implement least privilege access.

Proper IAM setup is crucial for security and compliance. Restricting permissions to just what is absolutely necessary prevents accidental data leaks or modifications. It limits damage in case credentials are compromised. Implementing least privilege access and separation of duties are vital best practices for IAM.

Provisioning AWS Infrastructure

Launching EC2 Instance

EC2 allows provisioning virtual servers to run applications. For Craft CMS, start with an Amazon Linux 2 AMI. Choose an instance type like t3.medium which provides a balance of CPU, memory and network.

For production workloads, use the Auto Scaling feature to allow automatic scaling up or down based on demand. Coupled with a load balancer, this provides high availability.

Place the instance in a public subnet to allow incoming traffic on port 80 and 443. But disable SSH remote access and enable only via Systems Manager Session Manager for extra security.

Use VPC security groups like a virtual firewall to control inbound and outbound network access. Open only necessary ports required by the application, like 80,443 and block everything else.

Attach an Elastic IP to associate a static public IP address to the instance. This remains fixed during instance restarts and scaling events.

Encrypt the EBS root volume for data at rest security. Enable detailed CloudWatch monitoring for visibility into disk, network, CPU usage. Use AWS Systems Manager to manage fleet updates, configurations, troubleshooting etc.

For storage, use separate EBS volumes for data, logs, backups etc. based on the performance needs - gp2 for low-latency apps and io1 for large databases. Enable encryption and snapshots to protect from data loss.

Creating RDS Database Instance

RDS provides fully managed databases like MySQL, Postgres, Aurora etc. For Craft CMS, Aurora MySQL is a good fit for its performance and scalability.

Choose an instance class like db.t3.medium to get a balance of CPU, memory and network bandwidth. Monitor the usage and scale up or down as needed.

Place the database in a private subnet with no direct internet access. Allow traffic only from the app servers via VPC security groups. Use SSL for secure connectivity over port 3306.

Enable daily automated backups with a 2-week retention so database can be restored to any previous point within the window. Test restores periodically to verify backups are valid.

For high availability, create a Multi-AZ setup with standby replica in another availability zone. Enable auto failover so RDS automatically fails over to standby if the primary instance goes down.

Monitor database using CloudWatch metrics like CPU, connections, freeable memory etc. Create SNS alerts for critical thresholds like high CPU or storage usage.

Enable encryption at rest to secure data. Rotate credentials periodically. Use IAM roles and groups to restrict database access only to authorized users and apps.

Configuring VPC, Subnets, Route Tables

VPC allows creating a private virtual network on AWS and controlling IP addressing. Start with a /16 CIDR covering 65K IPs. Span it across multiple availability zones for high availability.

Create public and private subnets - public ones hold resources like load balancers while private ones hold backend instances and databases.

Ensure subnets have non-overlapping CIDR ranges within the VPC. Use NAT gateways in public subnets so private instances can access the internet for updates etc.

Configure route tables to allow public subnets to directly route external traffic to the internet gateway. Private subnets should route external traffic via the NAT gateway.

Use VPC security groups like virtual firewalls to allow traffic only between resources that need to communicate, e.g. app servers and databases. Block everything else.

Implement VPC flow logs to monitor network traffic for security and troubleshooting. Connect on-premises data centers to VPC via VPN or AWS Direct Connect.

Isolate sensitive resources like databases in private subnets with no internet access and access only from app servers. Restrict incoming traffic on databases via security groups only to 3306 port.

Properly securing AWS networking resources is crucial to prevent data leaks or malicious attacks. Restrict access tightly between VPCs, subnets, instances and lock down inbound internet traffic.

Installing Craft CMS on EC2

Connecting to EC2 Instance

To install Craft CMS, you first need to connect to the EC2 instance securely. Avoid using SSH which exposes the server to attacks if credentials are compromised.

Instead, use AWS Systems Manager Session Manager. It allows starting an interactive shell on the instance without opening inbound ports. Session data is encrypted and access can be controlled via IAM.

To enable Session Manager, install the SSM agent on the instance and attach an IAM role granting session manager permissions. Then start a session via the AWS console, CLI or SDK.

Session Manager leaves no persistent access like SSH keys on the instance. Sessions can be recorded and audited for compliance. You get centralized access control and encryption versus SSH.

Downloading and Installing Craft CMS

Once connected to the instance via Session Manager, install the prerequisites like PHP, MySQL client, httpd server etc. using the yum package manager.

Then download the Craft CMS codebase from https://github.com/craftcms/cms. You can use git or wget the zip file.

Next, use Composer to install PHP dependencies. On RHEL/CentOS systems install Composer via:

php -r "copy('https://getcomposer.org/instal...', 'composer-setup.php');"

php -r "if (hash_file('sha384', 'composer-setup.php') === '756890a4488ce9024fc62c56153228907f1545c228516cbf63f885e036d37e9a59d27d63f46af1d4d07ee0f76181c7d3') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"

php composer-setup.php

php -r "unlink('composer-setup.php');"

Then run composer install to pull in Craft CMS dependencies. This scaffolds the complete CMS codebase.

Configuring File System and Permissions

Craft CMS requires proper filesystem configurations for optimal performance and security.

Use a separate EBS volume for uploads and assets storage instead of the root volume. Mount it under the /var/www/html/web/cpresources path.

Ensure the craft, templates, vendor folders under web/ are owned by apache user and group. The startup script web/index.php should also be owned by apache:apache.

Set recursive permissions of 0755 for folders and 0644 for files underneath web/. The exception is storage/ and cpresources/ which should be 0775.

This allows the httpd server to read/write files created by Craft during runtime. File changes are restricted from other users for security.

Enabling memcache provides performance gains for database query caching. Install it via:

yum install memcached php-pecl-memcache

And update php.ini to enable the memcache extension. Restart httpd for the changes to take effect.

For file uploads, configure Craft to store on S3 instead of EBS for high scalability. Generate a bucket policy granting the EC2 IAM role access to the S3 bucket.

Setup CloudFront CDN in front of the S3 bucket and restrict public bucket access. This improves upload speed from anywhere.

Craft CMS benefits greatly from a performant and secure filesystem configuration. Proper ownership, permissions and utilizing managed services like S3 and CloudFront improve the administrative experience as well as front-end site delivery.

Migrating Database to RDS

Exporting Database from Local

When installing Craft CMS initially, the database starts on the local EC2 instance for simplicity. This should be migrated to RDS for better reliability, scaling and backups.

To migrate, first export a SQL dump from the local database using:

mysqldump -u root -p database_name > database_backup.sql

This exports the schema and data into a SQL script that can be imported elsewhere. Be sure to take a backup first in case anything goes wrong.

For large databases, use the --single-transaction option for a faster optimized dump. Compress the SQL file to minimize transfer time to RDS. Encrypt it as well for security.

Optionally use AWS Schema Conversion Tool to convert schemas like MySQL to PostgreSQL for migration between database engines.

Importing Database to RDS

Start by launching a Aurora MySQL RDS instance with proper sizing and VPC connectivity. Enable encryption and backups.

Create a database corresponding to the local one and a user with necessary permissions. Ensure VPC and security groups allow access only from the app servers.

Use the mysql client to connect to RDS and create the database:

mysql -h endpoint -u username -p

CREATE DATABASE database_name;

Then import the SQL dump from local:

mysql -h endpoint -u username -p database_name < database_backup.sql

This restores the full schema and data. Monitor overall progress from CloudWatch metrics.

Once imported, verify by checking record counts match and querying sample data. Test core app functionality end-to-end.

Updating Craft CMS Config for RDS

After migrating the database to RDS, update Craft CMS config to point to the new DB endpoint:

Edit config/db.php:

'redriver' => 'mysql',

'server' => 'RDS endpoint',

'user' => 'RDS username',

'password' => 'RDS password',

'database' => 'RDS database name'

Also, update .env with the RDS credentials. Restart the httpd server for changes to take effect.

In the Craft admin, double check the DB connection settings under Settings > Database. Test critical functionality like content editing, plugin usage etc.

Migrating from a local database to a fully managed service like RDS improves reliability, security, scalability and backup/restore capabilities. With the CMS configured against RDS, you get better performance and resilience.

Configuring Asset Storage in S3

Creating IAM User for S3 Access

Craft CMS allows storing assets like images, videos, downloads etc. in S3 instead of local storage.

Start by creating an IAM user exclusively for Craft S3 access. Attach a policy granting permissions like:

• s3:GetObject

• s3:PutObject

• s3:DeleteObject

• s3:ListBucket

This allows the IAM user to upload, retrieve, delete objects in the S3 bucket but not modify the bucket itself.

Use access keys to provide programmatic access. Never hardcode these keys in code or config. Instead utilize environment variables or secrets manager.

Grant minimum permissions needed for asset management only. Don't use an admin level account to restrict blast radius in case of a breach.

Pointing Craft Asset Volumes to S3

First, create an S3 bucket for Craft assets. Enable default encryption for security.

Configure a bucket policy allowing the IAM user access to the bucket objects. Set CORS permissions to allow cross-domain uploads.

In the Craft admin, go to Settings > Assets and create a new volume. Select Amazon S3 as the type.

Provide the bucket name, sub folder if needed, region, credentials etc. Set the URL format for generating public URLs.

Test uploading some sample assets and ensure they are properly saved in the bucket. Fix any permissions issues.

Now configure Craft to use this S3 volume by default for asset storage instead of local disk.

Setting Proper S3 Permissions

Use least privilege permissions for secure S3 access:

• Make the bucket private and disable public access

• Allow upload and edits only via the IAM user

• Use IAM policies instead of bucket ACLs

• Restrict access to specific path prefixes if needed

Enable default encryption on the bucket for data protection.

Use CloudFront in front of S3 to leverage caching, gzip and HTTPS. Set origin access identity for access between CloudFront and S3.

Enable S3 versioning to recover from unintended overwrites or deletes. Enable object lock for worm-like retention.

Audit asset access and updates via CloudTrail logging. Use MFA for deleting or overwriting objects.

Properly securing S3 assets is important to prevent unauthorized access or tampering. Craft CMS combined with IAM, S3 permissions and CloudFront delivers robust, scalable asset management.

Setting up CloudFront CDN

Creating CloudFront Distribution

CloudFront provides a global CDN for caching and distributing content quickly. To accelerate Craft CMS delivery, create a CloudFront web distribution.

Select the S3 bucket or EC2 instance as the origin source. Restrict bucket access only to CloudFront via an origin access identity.

Enable all supported HTTP methods like GET, PUT, POST, DELETE etc. Set viewer protocol policy to redirect HTTP to HTTPS.

Configure caching based on file types - 1 day for images/CSS/JS, 1 hour for HTML, custom for Craft CP resources. Set forwarding cookies to whitelist Craft session cookies.

Select price class like 100 for European/US regions. Enable logging to analyze access patterns.

Set up Lambda@Edge functions if needed for dynamic manipulation of requests/responses.

Add custom headers or rewrite URLs via Edge compute.

Once created, confirm the CloudFront domain is delivering content properly from origins. Monitor metrics like hit rate, latency, cache usage etc. in CloudWatch.

Adding Custom Domain and SSL

Use Amazon certificate manager to provision and manage SSL certificates for domains and subdomains on CloudFront.

Request or import certificates for the exact domain names being used. This provides free TLS certificates and renewals.

In CloudFront, attach the certificates to the distribution. Update alternate domain names to add custom domains and subdomains needing SSL.

Configure DNS settings for the domains - create CNAME records pointing to the CloudFront URL. This maps custom domains to the CloudFront distribution.

Test accessing the site via HTTPS on the custom domains to validate SSL functioning correctly end to end.

Configuring Caching and Compression

Optimize CloudFront performance for Craft CMS by configuring:

• Caching policies based on path pattern - cache images/js/css more aggressively

• Forward cookies and headers like Cookie, Authorization that need to pass through

• Enable GZip compression to reduce payload sizes

• Minimum, maximum and default TTLs tailored to file types

• Origin failover for auto recovery from outages

• Lambda@Edge functions for dynamic manipulation

Enable access logs to analyze caching effectiveness and visitor trends.

Set up invalidations for programmatic cache clearing when content is published or updated.

Load test from clients across regions to measure improvements in site performance. Monitor metrics like cache hit ratio in CloudWatch.

CloudFront accelerates content delivery and improves user experience on Craft CMS websites through caching, compression and SSL terminiation. Proper configuration optimizes cost and performance.

Securing Craft CMS on AWS

Restricting Server Access

Securing access to the EC2 servers running Craft CMS is crucial to prevent unauthorized entry. Start by placing the instances in private subnets with no direct internet routing. Then limit incoming traffic to only ports 80 and 443 through tight VPC security groups. Utilize NAT gateways and route tables to provide the instances filtered outbound internet access for critical updates and patches.

Enable AWS Systems Manager Session Manager for "bastion-less" SSH access into the servers. This removes the need for open SSH ports while providing encrypted and auditable admin sessions. Disable password-based SSH authentication entirely and enforce key-based access only. Harden the instances themselves by removing unnecessary packages, closing unused ports and dialing up kernel tweaks like SYN flood protection.

For monitoring, deploy the CloudWatch agent for visibility into OS and application metrics.

Furthermore, leverage AWS Systems Manager capabilities for centralized fleet management like patch management and configuration changes. Attach strict IAM roles to the instances instead of using EC2 credentials. Schedule auto-scaling features like health checks and automated remediation to limit drift. Enable termination protection to prevent accidental deletion of critical instances.

Enforcing HTTPS

All traffic for both the Craft CMS control panel and public frontend websites should be secured with HTTPS encryption. This can be accomplished by terminating SSL connections on the load balancer using Amazon Certificate Manager to manage TLS certificates. Additionally, configure VPC security groups to redirect any incoming HTTP requests to HTTPS.

Enable HTTP strict transport security (HSTS) headers for added security. Front the sites with CloudFront CDN for performance gains while using dedicated IP ranges. Within Craft CMS itself, explicitly set both the public and admin URL settings to HTTPS. Lastly, configure the "secure" flag on cookies generated by Craft to prevent transmission over unencrypted connections.

Taken together, these measures ensure end-to-end encryption of all administrative and public user access for complete security assurance.

Enabling AWS WAF Protection

To filter and block malicious requests targeting the Craft CMS sites, utilize AWS Web Application Firewall (WAF). Craft custom WAF rules tailored to your specific application configuration and patterns. Set up rules to proactively block known attack vectors and common exploits. Enable IP blacklisting capabilities to counter brute force login attacks by temporarily blocking repeat offenders.

For the CMS control panel, configure IP whitelists to restrict access to authorized networks only. Keep the WAF rules frequently updated with protections against new vulnerabilities or threat intelligence. Complement WAF with AWS Shield for DDoS resiliency against volumetric floods.

Enable detailed logging and analytics around all requests filtered by WAF to continuously refine the protection and identify gaps. Further hardening like regular penetrating testing, misconfiguration scans and DDoS simulations will strengthen the overall security posture.

Following AWS and Craft CMS best practices combined with leveraging services like WAF and Shield provides robust 360 degree protection and significantly minimizes risk from attacks and unauthorized access.

Performance Optimization

Database Optimization

Optimizing the Craft CMS database is key for fast administrative operations and front-end delivery.

For tables being queried frequently, add indexes on commonly filtered columns to improve search performance. Avoid indexes rarely used as they incur overhead on writes.

Enable Redis or Memcached caching to reduce database hits. Cache full rendered pages, database queries and API calls.

Setup a read replica database to serve read traffic and offload work from the primary instance. Route frontend queries to the read replica.

Analyze slow queries in the MySQL logs. Add explanatory comments for complex app queries. Restructure inefficient queries and procedures.

Use EXPLAIN to analyze query execution plans. Look for full table scans or missing indexes causing delays.

Scale up RDS instance size if CPU or RAM is bottlenecked. Enable Multi-AZ for failover.

Front-end Optimization

Speed up front-end performance of Craft CMS websites by:

• Minifying HTML, CSS and JS assets using Grunt or Gulp

• Enabling asset caching and compression in CloudFront

• Configuring Nginx caching of static assets

• Using image optimization services like Optimizely

• Lazy loading images below the fold

• Generating static page caches where possible

• Analyzing page speed and web vitals using Lighthouse

• Resizing and compressing images for faster loading

• Removing unnecessary plugins, JavaScript from pages

Load test using distributed clients and tools like Siege. Monitor metrics like TTFB, requests per sec etc.

Enabling GZip Compression

GZip compressing HTML, CSS, JS and images accelerates Craft CMS sites by reducing payload sizes.

On the EC2 servers, install mod_deflate for Apache. For Nginx, enable gzip compression in the config.

Configure gzip policies in CloudFront as well to compress forwarded requests.

In Craft, enable gzip responses via config settings like compressedResponses => true

Verify compression using browser developer tools or curl:

curl -I -H "Accept-Encoding: gzip" https://example.com

Monitor CloudFront and EC2 metrics for compression savings and confirm improvements in page load times.

GZip improves performance especially for mobile users with limited bandwidth. But balance against compute overhead of compression on the servers.

Monitoring and Logging

CloudWatch Metrics and Dashboards

CloudWatch provides metrics, logs and alarms for monitoring Craft CMS performance.

Key metrics to track are request rates, latency, 5xx errors on the load balancer and origin. For EC2, monitor CPU, network, disk metrics.

Capture database metrics like connections, slow queries, queue depth from RDS to detect bottlenecks.

Set up dashboards visualizing metrics correlated to business metrics. Craft CMS plugins provide additional custom metrics also.

Configure alarms to trigger notifications for critical outages or service degradation. Set up auto healing for some failures like instance recoveries.

Enable detailed request tracing to analyze individual request latencies. Use this during testing to identify optimization opportunities.

Build scripts leveraging API calls to retrieve metrics for further analysis. Utilize third-party tools like DataDog as well for extended visualizations.

Server Access and App Logging

Capture Linux server logs like SSH accesses, cron job output etc. for security and audit purposes.

Enable and aggregate HTTP access logs from the load balancer, CloudFront and EC2 instances. Feed them into analytics tools to analyze trends.

For debugging, output Craft CMS application logs across environments. Log messages help replicate and pinpoint issues.

Stream PHP-FPM, Nginx logs to CloudWatch Logs for central aggregation. Search logs for failure spikes or errors.

Enable MySQL slow query, general and audit logging. Slow queries help optimize database performance.

Fix log rotations and persistence to prevent loss. Mask any sensitive data before logging.

Application Performance Monitoring

For deeper app performance insights, use tools like New Relic or Scout.

They provide metrics on request times, apdex score, host utilization etc. Instrument key transactions and measure their performance.

Get visibility into database queries, calls between services, external API latency etc.

Configure custom events and alerts tailored to the application domain.

Perform root cause analysis by tracing transactions end-to-end. See impact of optimizations across environments. Fix bottlenecks.

Integrate APM metrics with business KPIs in dashboards to track correlations.

Robust monitoring and logging provides visibility into the health and performance of Craft CMS on AWS. This enables proactive optimization and rapid diagnosis of issues.

Automating Deployments

Scripting and CLI Tools

Automate AWS infrastructure for Craft CMS using CLI tools like AWS CLI and SDKs.

For example, write Bash scripts leveraging AWS CLI commands for provisioning resources like:

aws ec2 run-instances --image-id ami-123 --count 1 --instance-type t2.micro

Use CLI tools in automation serverlessly via Lambda functions as well.

Build scripts for datastore migrations, testing deployments, configuration management etc. Embed AWS API calls for automation.

Leverage SDKs like Boto3 for Python for programmatic access from scripts. SDKs simplify working with AWS services.

Parameterize configurations for reuse across environments. Keep scripts version controlled for auditing changes.

Infrastructure as Code Solutions

Manage infrastructure as code using solutions like AWS CloudFormation, Terraform and CDK.

They allow creating templatized, reproducible stacks using code.

For example, define Craft CMS infrastructure stacks in YAML/JSON and deploy the resources idempotently.

Updating the templates automatically modifies the associated resources. IaC enables version controlled, consistent and compliant environments.

Develop modular, reusable infrastructure components and architectures for productivity.

Use IaC to coordinate deployments across regions, accounts and environments.

CI/CD Pipelines

Build continuous integration pipelines to test infrastructure and app changes before deploying.

Use GitHub Actions, Jenkins, AWS CodePipeline to automate build, test, release processes.

Integrate infrastructure as code with pipelines for automated environment provisioning.

Add deployment stages across dev, test, prod mimicking the software release lifecycle.

Implement approval gates before deploying to production. Enforce testing rigor for pull requests.

Automatically rollback failed updates. Provide pipeline visibility via notifications, dashboards.

Coupling automation with practices like immutable infrastructure, blue-green deployments and progressive rollouts provides stability and reliability

Infrastructure as code, CI/CD pipelines and scripting help automate provisioning, updates and testing. This increases deployment velocity and consistency while reducing risks.