This solution will deploy an AWS API Gateway, multiple AWS SNS topics and AWS SQS queues that will fan out incoming requests. It will utilize a custom domain and certificate for incoming requests.
- An Amazon Route 53 (public) forward zone, that has its respective nameservers pointed to it (e.g. you've registered a domain with your preferred registrar and have pointed the
nameserver
entries to the Amazon Route53 public forward zone) - An Amazon Certificate Manager wildcard certificate (OR a certificate issued to the
custom_domain_name
value set incdk.json
) issued to the valuehosted_zone_name
incdk.json
- Set the following in
cdk.json
:- Set the Amazon Route53 forward
zone name
that was defined in step #1 (e.g.troydieter.com
) ashosted_zone_name
- Set the Amazon Route53 forward
ID
name that was defined in step #1 ashosted_zone_id
- Set the Amazon Certificate Manager
ARN
defined in step #2 ascert_arn
- Set the
custom_domain_name
to the preferred custom domain name, that aligns to the value set in3.1
(e.g. api.troydieter.com) - Set the
alarm_email
to your email address, which will subscribe to the Amazon SNS topic that handles alerts
- Set the Amazon Route53 forward
If you have any questions, need clarification a step -- please open a Github issue! I'm always open to feedback and here to help.
In this example we have an API Gateway with a "/SendEvent" endpoint that takes a POST request with a JSON payload. The payload formats are beneath.
When API Gateway receives the json it automatically through VTL routes it to an SNS Topic, this Topic then has two subscribers which are SQS Queues. The difference between the two subscribers is that one looks for a property of "status":"created" in the json and the other subscriber looks for any message that doesn't have that property. Each queue has a lambda that subscribes to it and prints whatever message it recieves to cloudwatch.
To send to the first lambda
{ "message": "hello", "status": "created" }
To send to the second lambda
{ "message": "hello", "status": "not created" }
The cdk.json
file tells the CDK Toolkit how to execute your app.
This project is set up like a standard Python project. The initialization
process also creates a virtualenv within this project, stored under the .env
directory. To create the virtualenv it assumes that there is a python3
(or python
for Windows) executable in your path with access to the venv
package. If for any reason the automatic creation of the virtualenv fails,
you can create the virtualenv manually.
To manually create a virtualenv on MacOS and Linux:
$ python3 -m venv .env
After the init process completes and the virtualenv is created, you can use the following step to activate your virtualenv.
$ source .env/bin/activate
If you are a Windows platform, you would activate the virtualenv like this:
% .env\Scripts\activate.bat
Once the virtualenv is activated, you can install the required dependencies.
$ pip install -r requirements.txt
At this point you can now synthesize the CloudFormation template for this code.
$ cdk synth
To add additional dependencies, for example other CDK libraries, just add
them to your setup.py
file and rerun the pip install -r requirements.txt
command.
cdk ls
list all stacks in the appcdk synth
emits the synthesized CloudFormation templatecdk deploy
deploy this stack to your default AWS account/regioncdk diff
compare deployed stack with current statecdk docs
open CDK documentation
Enjoy!