DEV Community: Mike Ng

Signing Ethereum and Tron transaction with AWS KMS Key

Mike Ng — Tue, 18 Mar 2025 11:11:05 +0000

In the world of blockchain technology, managing cryptographic keys securely is crucial. The AWS KMS Signer library offers a robust solution for developers looking to integrate secure signing operations into their Ethereum and Tron applications. This article introduces the AWS KMS Signer library, highlighting its features, usage, and the benefits of using AWS Key Management Service (KMS).

What is the AWS KMS Signer Library?

The AWS KMS Signer library is a powerful tool that leverages AWS KMS to perform cryptographic signing operations. It is designed to enhance the security of blockchain applications by managing keys within the secure AWS environment, eliminating the need to handle plaintext private keys directly.

Key Features:

Secure Key Management: Utilizes AWS KMS to securely manage cryptographic keys.
Multi-Network Support: Compatible with both Ethereum and Tron networks.
TypeScript Support: Provides type definitions for enhanced development experience.
Comprehensive Test Suite: Ensures reliability and security through extensive testing.

Why Use AWS KMS?

AWS KMS provides a secure and resilient infrastructure for key management, ensuring that your keys are protected by hardware security modules (HSMs) that are FIPS 140-2 validated. Here are some key benefits:

Security

Key Isolation: Keys are stored in a secure environment and never leave the AWS infrastructure.
Access Control: Fine-grained permissions can be set using AWS Identity and Access Management (IAM) policies, allowing you to control who can access and use your keys.

Compliance and Auditing

Audit Logging: AWS CloudTrail provides logs of all key usage, helping you meet compliance and regulatory requirements. This ensures transparency and accountability in key management operations.

Scalability

AWS KMS is designed to scale with your needs, making it suitable for large-scale blockchain applications that require robust key management solutions.

How the AWS KMS Signer Works

The library interacts with AWS KMS to perform signing operations, ensuring that private keys never leave the secure AWS environment. This integration provides a seamless experience for developers, allowing them to focus on building their applications without worrying about key management.

Usage Example:

Ethereum Signer Usage:

import { EthereumSigner } from "aws-kms-signer";

// Initialize the signer
const signer = new EthereumSigner({
  keyId: "your-kms-key-id",
  rpcUrl: "any-ethereum-rpc-endpoint",
});

// Get the Ethereum address
const address = await signer.getAddress();

// Sign a message
const message = "Hello, Ethereum!";
const signature = await signer.signMessage(message);

// Sign a transaction
const transaction = {
  to: "0x...",
  value: ethers.parseEther("0.1"),
  // ... other transaction parameters
};
const signedTx = await signer.signTransaction(transaction);

Tron Signer Usage:

import { TronSigner } from "aws-kms-signer";

// Initialize the signer
const signer = new TronSigner({
  keyId: "your-kms-key-id",
});

// Get the Tron address
const address = await signer.getAddress();

// Sign a message (TIP-191 compliant)
const message = "Hello, Tron!";
const signature = await signer.signMessageV2(message);

// Sign a transaction
const transaction = await tronWeb.transactionBuilder.sendTrx(
  "recipient-address",
  1000000, // amount in SUN
  address,
);
const signedTx = await signer.signTransaction(transaction);

Benefits of Using the AWS KMS Signer

Security

By using AWS KMS, the AWS KMS Signer ensures that private keys are never exposed, significantly reducing the risk of unauthorized access.

Ease of Use

The library is designed to be easy to integrate into existing blockchain applications, providing a seamless experience for developers.

Flexibility

With support for both Ethereum and Tron networks, the AWS KMS Signer is versatile and can be used in a variety of blockchain applications.

Conclusion

The AWS KMS Signer library offers a secure, scalable, and easy-to-use solution for managing cryptographic keys in blockchain applications. By leveraging AWS KMS, developers can enhance the security of their applications while simplifying key management. Whether you're building on Ethereum or Tron, the AWS KMS Signer provides the tools you need to protect your assets and ensure compliance.

Additional Resources

How to send large batch transaction to EVM-based blockchain network using AWS serverless service

Mike Ng — Thu, 30 Mar 2023 19:03:43 +0000

This article is just a start, there will be more updates coming up like extracting the gas fee wallet to a separate wallet either using the private key in Secrets Manager or the KMS key and also setting up multiple workers for the minting process in the ERC721 smart contract. Which enables a higher volume of transactions executions performance.

This article illustrates sending a large batch of transactions from a single EOA on any EVM-based Blockchain network.

The entire solution used Lambda, Step Function, and SQS. At first, this solution will keep it simple as possible and continue to update.

To get started on this solution, please make sure you have development experience with any EVM-based blockchain network and ether.js.

As we all know, when sending transactions on any EVM-based blockchain will have a nonce. The nonce is the number of transactions sent from a given address which acts as a one-time code that prevents replay attacks or double-spending.

This means when sending batch transactions in an EVM-based blockchain, you have to wait until the recently sent transaction has been mined in the latest block, then you can get the latest nonce and send the next transaction.

If the application is sending the transaction in a synchronous manner, the overall performance and execution experience will be very poor. This means the entire transaction-sending process must be refactored and extracted to become an asynchronous process.

This solution has used a FIFO queue to ensure the transaction has been sent in an absolute order for processing. The example ERC-721 has been written to demonstrate large batch or minting process execution in Lambda function.

For the detail configuration and setting you can see directly in the CDK Github repository.

How to implement serverless to optimize the flexibility of your architecture on AWS

Mike Ng — Fri, 26 Aug 2022 09:23:23 +0000

In this blog post, we will explore what serverless is and how to implement it on AWS.

Serverless is a new way of building and deploying applications. It's a way to build applications that have no servers, but still benefit from the scale and reliability of AWS. This can be useful for your team if you want to build more modularized apps with less overhead, or if you want to scale up quickly without worrying about managing infrastructure or configuring an operating system for each instance of your application.

If serverless sounds like something that would help you, read on!

What is serverless?

Serverless is an architecture that abstracts the infrastructure layer. It’s similar to virtual machines or containers in that it offers a higher level of abstraction, where you don’t need to explicitly manage resources on your own.

Serverless allows developers and organizations to build applications quickly without having to worry about managing servers or infrastructure.

Serverless architectures are an abstraction of the infrastructure layer similar to virtual machines or containers. They provide a way to build software without having to worry about how it gets deployed, scaled and managed. The concept has been around for years but only recently has become popular due to its simplicity and flexibility.

Serverless applications can be thought of as any type of application that does not have its own infrastructure (i.e., servers). This includes web apps, mobile apps, IoT devices and more—allowing you greater control over your application’s resources than you would have otherwise had with classic cloud hosting options like AWS Lambda or Azure Functions."

They offer a higher level of abstraction, where you don’t need to explicitly manage resources.

You don't need to manage infrastructure.
You don't need to manage scaling.
You don't need to manage security.
You don't need to manage operations, monitoring and logs (or backups).

Instead, you simply focus on writing code.

You can focus on writing code instead of managing infrastructure.

You don't have to worry about scaling.
You don't have to worry about infrastructure, operations and capacity planning, or cost management.

Why go serverless?

There are many reasons to consider going serverless. Some of the main advantages include:

Manage infrastructure and operations independently of your application code. You can scale up or down your infrastructure without changing the code and without affecting end users. This gives you more flexibility in how much compute resources you need and when they need it, which helps reduce costs by eliminating wasted hardware or idle servers, as well as simplifies management through fewer monitoring points (no need for an internal IT team). You also get better visibility into resource utilization so that if there's an issue with one part of the system it won't take down another part at the same time—allowing you to fix them separately instead of having everything come down at once!

Reduce time-to-market by building faster than before; save money on cloud hosting fees because AWS already exists within most organizations' existing infrastructures; give developers access directly from their favorite development toolset rather than forcing them onto something new - which means less learning curve & faster adoption rates across teams."

Serverless can help you build scalable applications quickly without thinking about infrastructure and operations.

You can focus on building your application instead of managing infrastructure. You can scale your application without having to worry about infrastructure. And finally, you can deploy your application without having to worry about infrastructure

Ever increasing demand for scalability and availability has made it difficult to estimate the future capacity needs of your application infrastructure.

Serverless computing has been gaining popularity as a cost-effective way to scale your application infrastructure. As it becomes easier and more affordable, more and more organizations are adopting serverless architectures to meet their business needs.

Serverless computing can help you improve scalability, security and time-to-market by removing the burden of managing servers from your organization. Here’s why:

It decreases operational costs by eliminating the need for manual maintenance or updates in the cloud management layer of an application stack (e.g., AWS Lambda). This allows you to focus on building new features instead of maintaining old ones; however, there will still be some extra work involved because you may need someone else (or several people) within the company who understands how things work under “the hood” when using these tools in order for them not only maintain but also grow faster than possible without this kind approach.*

Serverless allows you to run code on as-needed basis without worrying about scaling.

You only pay for what you use and therefor have more control over the development process.

It's a great solution when it comes to building applications with microservices or any other kind of distributed architecture where multiple teams are working in different locations.

This means that you only pay for what you use, which leads to significant cost savings compared to maintaining a fixed scale or overprovisioning resources.

You don't need to worry about infrastructure: Serverless allows you to focus on developing your products without having to manage the underlying infrastructure. This frees up time and energy so that it can be spent on other things like building features and adding value for customers.

The ability to deploy functionality without worrying about infrastructure can improve time-to-market significantly by letting developers focus on building the applications instead of deploying them.

This is because serverless allows you to run code on as-needed basis without worrying about scaling, so if your application grows in size and complexity, there's no need for additional servers or servers that scale up with more load.

Serverless technology also has a significant impact on security because it enables developers to focus on building their applications rather than managing their own infrastructure.

It also gives more control over the development process as teams can make fast deployments without being dependent on other groups such as IT operations or networking teams.

Serverless architecture also gives more control over the development process as teams can make fast deployments without being dependent on other groups such as IT operations or networking teams. In addition, it allows developers to focus on building applications instead of deploying them, which makes it easier for them to build faster and more scalable solutions.

There are many cloud providers who support serverless solutions - such as AWS, Azure, Google Cloud Platform and IBM Cloud Functions - with AWS Lambda being the key player in this area currently because of its mature implementation and strong user community.

However there are still some details that need to be taken into account when choosing a provider: firstly it’s important to understand which features you need to implement on your own platform. Secondly what type of data will be used by your application? Lastly how will you manage costs based on demand?

Conclusion

I hope this blog post has given you an understanding of serverless and how it can help you build scalable applications. If you’re interested in learning more about serverless architectures and how they can be implemented on AWS, check out our other blog posts on the topic:

How Web3.0 technology influent traditional Cloud industry

Mike Ng — Fri, 26 Aug 2022 09:13:00 +0000

Introduction

Web3.0 technology is a disruptive concept that has the potential to revolutionize the way people use technology and interact with data. Since its inception, Web3.0 has gained widespread popularity, mainly due to its ability to provide decentralized solutions over centralized implementations of cloud computing. Web3.0 can be applied in many industries such as healthcare, finance, media and entertainment (M&E), transportation, education etc which will help businesses create smart solutions using cutting edge tools like AI technologies and blockchain platforms like Ethereum or Neo network

Web3.0 Technology Introduction

Web3.0 is a network of decentralized applications (dApps) and protocols that are not controlled by any single entity. It allows users to interact with each other through their computers instead of having to go through an intermediary company or individual.

The first step in understanding web3 is understanding what it isn't: It's not about blockchain technology, which we'll talk about later in this article. Instead, web3 refers to a new way people can build software applications; you could think of it as "web 2.0" for the next generation—and yes, that's still happening!

Potential Influence Area of Web3.0 Technology

Web3.0 is a new generation of cloud computing technology that integrates blockchain and cloud computing, which could be the future direction of digital transformation.

Web3.0 technology has been developed by companies such as Amazon, Google and Microsoft to provide users with better services through decentralized networks (distributed ledgers) in exchange for fees paid by consumers or businesses using their services through smart contracts on Ethereum’s blockchain network (ETH).

How Web3.0 technology influent traditional Cloud industry

The cloud has been around for a while now, but it is still an industry that is growing and expanding. However, there are many ways in which Web3.0 technology can help to improve the traditional Cloud industry by providing better solutions for businesses of all sizes.

In this article we will look at how Web3.0 technology influent traditional Cloud industry and its future potentials for growth as well as how it can improve upon current practices within the industry

Web3.0 could finally empower the adoption of cloud computing

Web3.0 technology could be the key to unlocking the potential of cloud computing.

The emergence of Web3.0 is already changing how we interact with technology and with each other, but it's not just about replacing existing companies or products; it also has the potential to empower new ways of doing business—and this time around, they're more than just nice-to-have luxuries.

Conclusion

Although cloud computing has been around for years, it is still in its infancy. Web3.0 technology, on the other hand, has been around for a few years and is already being used by many organizations as a way to make their computing needs more flexible and efficient. With Web3.0 technology becoming more popular each day and having the potential to change how we interact with information on our devices, hopefully we can soon see how these two technologies work together to bring even more innovation into our lives!

How to secure and ensure the internet-facing application load balancer only allow traffic from CloudFront?

Mike Ng — Sat, 07 Nov 2020 19:33:23 +0000

For every created internet-facing load balancer in AWS, they will have a public hostname. At most of the situation, a CloudFront distribution will be sitting in front of the load balancer for caching the static content and accelerate the delivery. And a WAF web ACL may create along and associate with the CloudFront distribution to provide application security. Or some Lambda@Edge function may create for customizing the content on the CloudFront distribution.

And now the problem is if the public hostname of the load balancer was exposed to the internet, the hacker on the internet can be bypassing the web ACL at the CloudFront distribution to attack the application. The only way is to only allow inbound traffics from CloudFront distribution.

To achieve this restriction, for every inbound request, the CloudFront distribution will insert a custom header X_Request_From_CloudFront with a hash value when the request passing through, and next forward to the load balancer. And the load balancer will have another associated WAF web ACL, to validate if the X_Request_From_CloudFront custom header exists and matching the hash value. The web ACL will reject the request if the custom header not exists or the value does not match.

In order to hide the custom header X_Request_From_CloudFront, and its hash value from the client-side and server-side, the 'Drop invalid header fields' is required to enable in the load balancer.

According to the document, Load balancer attributes

Indicates whether HTTP headers with header fields that are not valid are removed by the load balancer (true), or routed to targets (false). The default is false. Elastic Load Balancing requires that message header names contain only alphanumeric characters and hyphens.

Since the custom header X_Request_From_CloudFront contains underscores, the load balancer will consider it as an invalid header and remove the custom header and its value when the request passing through, which means it only exists in the request between the CloudFront distribution and the load balancer.

Reference

Adding Custom Headers to Origin Requests
Load balancer attributes

Best Practices for Running Container WordPress on AWS (ECS, EFS, RDS, ELB) using CDK

Mike Ng — Sat, 31 Oct 2020 16:20:49 +0000

Introduction

Recently I helped my friend migrate her eShop from WordPress.com to AWS. Since her business keeps growing to a larger scale, a third-party eCommerce hosting platform no longer fulfill her business needed. To satisfy the growing business needed, I have designed, transform, enhance, and migrated to a high availability architecture on AWS for her WordPress eCommerce business.

To reuse the infrastructure and simplify the deployment, I have used the AWS CDK. Cloud Development Kit is an open-source framework to define the infrastructure as code using familiar programming languages. I have written the infrastructure using Typescript, and after the CDK is compiled, a CloudFormation template will be generated and deployed on AWS.

AWS CDK

During the migration, I find out there aren't many documents or information about hosting WordPress on AWS, that why I written this blog post.

In this post, I won't explain so much about what those AWS services usage and benefit, and only talk about the reason I use it and how I configure it. This blog post is more like the extension of the WordPress: Best Practices on AWS.

AWS has provided the Best Practice document WordPress: Best Practices on AWS. After I read the document, I find out it still has a lot of room for improvement, it also doesn't take care much of the security of the WordPress application.

Other than that, there are some interesting ideas I have implement in this solution. Like:

How to secure the admin page(wp-admin)?
How to ensure your internet-facing application load balancer only allow traffic from CloudFront?

❗❗❗Please ensure you have read through the Best Practice document before reading down.❗❗❗

❗❗❗Also please ensure you have the basic knowledge of AWS cloud or any other cloud providers.❗❗❗

Architecture

Basically, the architecture can split it into multiple pillars:

Compute
Storage
Database
Cache
CDN
DNS
Security
Backup

Compute

According to the best practice document, it used EC2 for hosting. But I choose to containerize the WordPress application because Docker runs above OS, which means the container is much lighter than an EC2 instance, also the startup speed is faster and uses much less memory.

For running a containerized application on AWS, I am hosting the WordPress application using Fargate on ECS. By using Fargate, I don't need to provision and manage any EC2 servers, only need to allocate how much vCPUs and memory for the container. And recently, Fargate Spot has announced which can take up to 70% of cost-saving.

AWS Fargate

This architecture takes advantage of the capability of the capacity provider on the ECS cluster, using the default capacity provider strategy to launch multiple tasks mixed with Fargate and Fargate Spot launch type. For the first 3 tasks in the services, it will be standard Fargate launch type, which provided a baseline for high availability. And for the rest of the tasks, for every 3 tasks, 2 tasks will be the regular Fargate launch type, and the rest 1 task will be the Fargate Spot launch type. This strategy which can provide high availability service but also maximize the cost optimization.

To distribute the incoming request to the multiple running containers equally, an application load balancer has been set up. I have chosen to use the LOR algorithm instead of the regular round-robin algorithm. Because the round-robin algorithm will not consider the capacity or utilization of the target containers, this led to over-utilization or under-utilization of the target containers when the request has long process times. Whit the LOR algorithm, now the application load balancer can router the requests to the least number of an outstanding request, which further reduces the response time and balanced the utilization for each container.

There are 3 containers for each task, Nginx, PHP FPM, and X-Ray daemon. The reason I choose Nginx instead of Apache is the plugin W3 Total Cache support set up the page caching on Nginx instead of the application level. The X-Ray daemon was created for the AWS X-Ray plugin in WordPress, the plugin which collects the performance and information of each request and sends it to AWS X-Ray through the daemon.

Storage

WordPress is a stateful application, which means for each time you do some changes to the configuration, the files of WordPress will be changed. But Docker is a stateless service, which will lose all of it changes when every time you restart the container. If the WordPress application running in such an environment, its configuration will be lost when scale-in or scale-out events. To handle such a situation, I have used AWS EFS to store the WordPress application. EFS is a distributed file system, which means when every time the WordPress application file changed, the other running container will still using the same file instead of a local isolated file. Also, I have set up the lifecycle rule for the files where hasn't use over the past 90 days, to change the storage class to infrequent access, which to lower the cost.

Amazon EFS

The WordPress application has a lot of static files, like Javascript, CSS, images, videos, etc. Intending to lower the response time and the request counts to the WordPress application, I have used a plugin WP Offload Media to offload the static files to S3. This plugin will upload the newly created media to S3 whenever I upload any images or videos.

Database

To start a WordPress application, a MySQL database is required. Amazon RDS is a managed database service, which means I don't need to take care of database setup, patching, and backup. RDS support multiple databases, Aurora is one supported database in RDS. Amazon Aurora is developed by AWS and it is a relational database with MySQL and Postgres-compatible, It provides 5-times faster than a regular MySQL database, and the security, availability, and reliability of commercial databases at 1/10th the cost.

Amazon RDS

Aurora has 2 types of database - Provisioned and Serverless. The provisioned cluster is a regular database cluster, a master node, and multiple read replica. Another type is Serverless and I have chosen to use Aurora Serverless to running the MySQL database because I am not sure what size of the node type should be used. The Aurora Serverless was a little different from the provisioned type, it simular to Fargate. I only need to allocate how many ACU it need on startup and the maximum ACU it can scale, it natively provides auto-scaling features according to the CPU usage and number of connections of the database. Also, the Aurora Serverless support auto-pause, when your database has zero activity for a period of time, the database will be closed, and the database will back online when there is an activity to the database. I have disabled the auto-pause features since when the database went sleep, it needs to take at least 30 seconds to back online.

But be noticed! Aurora Serverless database divided into 3 layers:

Proxy
Compute
Storage Although the proxy and storage layer are multi-AZ, the compute layer was SINGLE-AZ, which means when your database went down at the compute layer, it takes more time to back online compare to the provisioned cluster.

Amazon Aurora
Amazon Aurora Serverless

IF YOUR REQUIRE FOR RUNNING A HIGH AVAILABILITY DATABASE, DO NOT USE AURORA SERVERLESS. AND PLEASE USE THE AURORA PROVISIONED CLUSTER.

Cache

I have chosen Memcached as the in-memory cache storage instead of Redis. And using Amazon ElastiCache for running the Memcached cluster. Amazon ElastiCache is a fully managed in-memory data store compatible with Redis and Memcached, which means I don't need to take care of the setup and patching.

Amazon ElastiCache for Memcached

The Memcached has better performance than Redis, according to these 2 blog posts.
Should I use Memcached or Redis for WordPress caching?
and Redis & Memcached Cache for WordPress on VPS or Cloud

To reduce the response time and put the cache into Memcached from WordPress, I have installed W3 Total Cache in WordPress. This plugin can setup different cache like Page Cache, Database Cache, Object Cache, and Fragment Cache into Memcached. As above mentioned, I am using Nginx for running the WordPress application, and the W3TC support setting up the Page Cache at Nginx level instead of WordPress application, which means when a request comes in, the Nginx will first search for the Memcached for the page caching, if any cache hit, Nginx will return the hit page cache instead forward the request to PHP-FMP, which further reduce the response time.

W3 Total Cache

CDN

To further reduces the response time, a CloudFront distribution has set up in front of the application load balancer. The distribution will cache the static content or requests into the edge location around the globe. When any user browsing the WordPress application, if the requested content is hit at the edge location, the distribution will return the hit cache instead of forward the request to the servers. The edge locations are usually located around the user which provided the lowest latency and faster delivery speed.

Amazon CloudFront

DNS

There are 2 hosted zones in Route 53, a public and a private. The public hosted zone will have multiple records including an alias A record of the WordPress and an alias A record of the static file of the CloudFront distributions.

The private hosted zone is associated with the VPC and in the private hosted zone, multiple A records were created for the different AWS resources hostname, including the Aurora Serverless cluster, the EFS file system, the ElastiCache Memcached cluster, the Elasticseach domain, and the private application load balancer. It provides identical and memorizable names With these records to various created AWS resources.

Amazon Route 53
Working with private hosted zone

Security

Network Security

Unlike the usual subnet division, the VPC is consists of 3 types of the subnet, Public, Private, and Isolated. The first 2 types of subnets are the same as usual, the outbound-traffic in the Public subnet route through internet gateway, the outbound-traffic in the Private subnet route through NAT gateway. The traffic in the Isolated subnet will not have any internet access and only have local routing accessibility, which can ensure the resources inside are absolutely safe and isolated away from the internet.

VPC with public and private subnets (NAT)

Also, a network access control list has been set up for the created VPC, which can ensure any traffics comes in are for browsing WordPress application.

Network ACLs

Encryption

To encrypt data in transit, both application load balancer and CloudFront distribution have set up using the signed TLS certificate in ACM. With the benefit of the L2 constructor in CDK, these TLS certificates will create in ACM also create DNS records in Route 53 hosted zone for validation. For further to restrict user must connect to WordPress application using HTTPS, both CloudFront distribution and application load balancer has set up redirect HTTP to HTTPS.

For security consideration, all of the stored data will be encrypted using the AWS managed keys in AWS KMS. The AWS managed keys are fully managed by AWS including the rotation. The Aurora Serverless cluster, EFS file system, static and logging file bucket in the S3 bucket all are encrypted using different AWS managed keys in KMS.

AWS Certificate Manager

Application Security

To secure the WordPress application away from the common web exploits, web ACLs have been set up on the CloudFront distribution. For the web ACL on the CloudFront distribution, I have assigned multiple AWS managed rule groups, they are CommonRuleSet, KnownBadInputsRuleSet, WordPressRuleSet, PHPRuleSet, SQLiRuleSet, and AmazonIpReputationList, please be reminded, part of the rules in some of the rule groups has been excluded, otherwise, it will block most of the requests to your WordPress application. With the above rules groups, the web ACL now can provide general protection against a wide variety of common threats and vulnerabilities.

AWS WAF

AWS Managed Rules for AWS WAF

DDoS Protection

DDoS is the most popular attack over the internet, with AWS Shield it can provide always-on detection and automatic inline mitigations that minimize application downtime and latency. AWS Shield Standard is automatically enabled for the CloudFront distribution and Route 53 hosted zone, which can protect against all known infrastructure (Layer 3 & 4) attack.

AWS Shield

Record and evaluate configuration

AWS Config has enabled to record and evaluate the configuration of the created resource. Multiple managed rule in AWS Config has been configured. A tag aws-config:cloudformation:stack-name will be associated with every created resource during the CDK deployment. And for every rule in AWS Config was set to use tag-based policy to record the tagged resources. If the AWS Config recorded any configuration changed and non-compliance to the changed configuration, it will send an email using SNS to the administrator to notify the non-compliance situation.

AWS Config

Advanced Security

In the following section, I will talk about

How to ensure your internet-facing application load balancer only allow traffic from CloudFront?
How to secure the admin page(wp-admin)?

How to ensure your internet-facing application load balancer only allow traffic from CloudFront?

How to secure and ensure the internet-facing application load balancer only allow traffic from CloudFront?

Mike Ng for AWS Community Builders ・ Nov 7 '20

#aws #cloudfront #security

The value of the custom header will be defined during the CDK deployment, and it will be a base64 encoded domain name of the public hosted zone, the hash value will be the same at the CloudFront distribution and the associated WAF web ACL, else all requests will be blocked.

How to secure the admin page(wp-admin)?

Anyone who has ever used WordPress will know wp-admin is the admin page, which causes huge loopholes in web security, which allow hackers to use brute force cracking methods similar to unlimited loops to crack the admin password.

There are 2 methods were implement to secure the admin page in the solution. The first is to add a whitelist IP addresses list, second is set up a client VPN to access the private application load balancer.

Whitelisting IP Address

For the first method, the whitelist IP addresses list need to fill in before the CDK deploy. After deployment, an IP set will be created in WAF. The WAF web ACL associated with the application load balancer will check the inbound request that comes from the CloudFront distribution, will also validate the IP address of the request with the 'admin' prefix in the path. If any other IP addresses that not on the whitelist attempt to enter the admin page will be blocked.

This should be the easiest way to protect the WordPress admin page, but it requires the end-user to have a static public IPV4 address. The whitelist needs to update whenever the IP address update or changes.

Using Client VPN

For the second method, it should be the most secure, feasible, and flexible. AWS client VPN is a managed VPN client-based services that allow end-user to access the private or restricted resource on AWS or on-premise securely, and it can run on any OpenVPN-based client. An AWS client VPN will be created in the VPC, for every end-user who connected to this VPN will have internet access through NAT and access to the private resources. A private application load balancer has been created, and its created for the connected VPN end-user which allows access to the WordPress application including the admin page securely.

AWS Client VPN

Backup

Although Aurora Serverless cluster the snapshot and back in RDS, AWS Backup is set up to manage backups across the AWS services that WordPress used, including the Aurora Serverless cluster and the EFS file system.

AWS Backup

Deployment

mikeng-io / aws-serverless-wordpress

AWS Serverless WordPress

Introduction

Please read the blog post for introduction and explanation Dev.to: Best Practices for Running WordPress on AWS using CDK

WordPress Plugin Used

W3 Total Cache
WP Offload Media Lite
ElasticPress
Multiple Domain
HumanMade - AWS-XRay (Working on making it work...)

Architecture Diagram

Deployment - (To be update)

Before getting started

Please make sure you have/are

Using bash
Node.js installed
NPM and Yarn installed
Installed and running Docker
Installed and configured AWS CLI
Installed the latest version of AWS CDK CLI

Please be notice, this stack only can deploy into us-east-1 0. You should have a public hosted zone in Route 53

Initialize the CDK project, run make init
Deploy the CDK Toolkit stack on to the target region, run cdk bootstrap aws://AWS_ACCOUNT_ID/AWS_REGION --profile AWS_PROFILE_NAME
Copy the config.sample.toml and rename to config.toml
Run make easy-rsa-init gen-cert import-cert to generate the certificate for the Client VPN
Modify the…

View on GitHub