Skip to content

Commit

Permalink
Merge pull request #50 from bcgov/dev
Browse files Browse the repository at this point in the history
Public Cloud Azure documentation
  • Loading branch information
abibat-adesina authored Nov 19, 2024
2 parents 52eb9bd + e9adb93 commit 1910f78
Show file tree
Hide file tree
Showing 73 changed files with 20,326 additions and 188 deletions.
2 changes: 1 addition & 1 deletion catalog-info.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ kind: Component
metadata:
name: "public-cloud-techdocs"
title: "Public cloud development guide"
description: "Learn about building and deploying applications through B.C. government AWS landing zone"
description: "Learn about building and deploying applications through B.C. government AWS and Azure landing zones"
annotations:
github.com/project-slug: bcgov/public-cloud-techdocs
backstage.io/techdocs-ref: dir:.
Expand Down
Binary file removed docs/.DS_Store
Binary file not shown.
Original file line number Diff line number Diff line change
@@ -1,7 +1,9 @@
# Networking within the AWS Secure Environment Accelerator (ASEA)

Last updated: **January 5, 2023**

## Introduction

This document simplifies the centralized networking of the AWS Secure Environment Accelerator (ASEA) and provides best practices for networking on the platform. Our goal is to make ASEA's networking easy to understand for anyone working on the platform within the guardrails of the BC Gov ASEA. Networking plays a crucial role as the backbone of cloud technology, connecting everything, ensuring safety, and facilitating smooth operations. Understanding it is essential for maximizing the benefits of cloud tools.

## Network architecture
Expand All @@ -15,8 +17,6 @@ These resources are accessible through AWS Resource Access Manager (RAM), which

This streamlined approach eliminates the need for duplicating resources across multiple accounts reducing the operational burden associated with managing resources in each individual account.



The distinction between the Shared Networking and Perimeter accounts is driven by the need for "separation of duties" in networking and security. In essence, ASEA's networking architecture guarantees centralized, well-organized, and secure communication. This is achieved through Transit Gateway routing, distinct security measures for the Perimeter VPC, and efficient resource management in the Shared Network account, as depicted in the B.C. Government ASEA's networking diagram below:

![networking-architecture](../images/networking/network-architecture.png)
Expand All @@ -31,9 +31,9 @@ For further reading beyond this document please visit the [AESA network architec

In the Perimeter account, we employ a [Gateway Load Balancer (GWLB)](https://aws.amazon.com/elasticloadbalancing/gateway-load-balancer/) to evenly distribute traffic load among our firewall instances. These instances, operating in a highly available pair, utilize Checkpoint Firewalls obtained from the AWS Marketplace. The Checkpoint Firewall Manager, coupled with Checkpoint's Smart Console, is instrumental in configuring traffic rules.

Our firewall setup strictly permits only HTTP/HTTPS traffic, with all other forms of traffic being blocked. This includes SSH egress traffic, which might affect accessing git repositories and other services relying on SSH. For git repository access, we recommend using HTTPS instead of SSH.
Our firewall setup strictly permits only HTTP/HTTPS traffic, with all other forms of traffic being blocked. This includes SSH egress traffic, which might affect accessing git repositories and other services relying on SSH. For git repository access, we recommend using HTTPS instead of SSH.

If your application necessitates non-HTTP/HTTPS traffic, please don't hesitate to reach out to the team by contacting them by email at [email protected]
If your application necessitates non-HTTP/HTTPS traffic, please don't hesitate to reach out to the team by contacting them by email at <[email protected]>

## Transit gateway

Expand Down Expand Up @@ -77,11 +77,12 @@ Workload VPCs are strategically structured for Development (Dev), Testing (Test)
- CIDR blocks define the IP address range for each VPC, ensuring unique and non-overlapping address spaces
- Enables proper addressing and routing


In summary, Workload VPCs are organized by environments (Dev, Test, Prod, Tools), share resources through AWS RAM for centralized management via Shared Networking account, and each VPC is configured with a /16 CIDR block to define its IP address range. This structure and configuration support the secure and scalable hosting of applications across different stages of development and testing in the ASEA.

### Subnets

All subnets within Workload VPCs, including Web, App, and Data, are private. This subnet configuration ensures a secure and organized environment, with each subnet tailored for distinct purposes within the ASEA infrastructure.

- **Differentiation between Public and Private Subnets**
- All subnets in a Workload VPC are designated as private. There is no distinction between public and private subnets within the Workload VPCs.

Expand Down Expand Up @@ -109,6 +110,7 @@ All subnets within Workload VPCs, including Web, App, and Data, are private. Thi
- All workload accounts in the same VPC/subnet share the same IP address pool.

### Security groups and NACLs

Security Groups and Network Access Control Lists (NACLs) play distinct roles in ensuring the security of Workload VPCs, with Security Groups acting as instance-level firewalls and NACLs providing an additional layer of defense at the subnet level

- **Difference between security groups and NACLs**
Expand Down Expand Up @@ -142,6 +144,7 @@ Security Groups and Network Access Control Lists (NACLs) play distinct roles in
### Exposing services to the internet

Generally, in the ASEA we recommend one of two methods of exposing services to the internet:

- API Gateway
- Application Load Balancer (ALB)

Expand All @@ -151,22 +154,23 @@ Making strategic choices between AWS API Gateway and ALBs is essential for optim
For general instructions on how to cerate an API gateway and safely expose it to the internet please see this [AWS documentation on HTTP APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html). For ASEA specific examples deployed using Terraform via GitHub Actions please see our [serverless, or container based sample applications](../design-build-and-deploy-an-application/deploy-an-app-to-the-aws-landing-zone.md#sample-applications). Creating resources via Terraform/ automation is always preferred.

**Benefits of using API Gateway and VPC Link**
- **Security and isolation** API Gateway and VPC Link provide a secure and isolated connection between your internet-facing API and backend services within a VPC. AWS WAF can also be used alongside your API gateway.

- **Scalability**

- **Security and isolation** API Gateway and VPC Link provide a secure and isolated connection between your internet-facing API and backend services within a VPC. AWS WAF can also be used alongside your API gateway.

- **Scalability**
API Gateway scales automatically to handle varying levels of traffic, ensuring the availability of your internet-facing services.
- **Managed service**

- **Managed service**
API Gateway is a fully managed service, reducing operational overhead and allowing you to focus on building and improving your APIs.

**When to use ALBs**
While API Gateway is recommended for modern applications, there is still a use case for ALBs with legacy applications where it may be difficult or impossible to use an API Gateway. If your application is unable to accommodate an API Gateway, then please reach out to [email protected] for integration support.
While API Gateway is recommended for modern applications, there is still a use case for ALBs with legacy applications where it may be difficult or impossible to use an API Gateway. If your application is unable to accommodate an API Gateway, then please reach out to <[email protected]> for integration support.

## Serverless resources

Serverless resources within the AWS Secure Environment Accelerator (ASEA) possess the flexibility to operate within or outside a VPC. When deployed within a VPC, these resources are assigned an Elastic Network Interface (ENI), utilizing an IP address from the corresponding subnet's IP pool. Access to VPC resources, including critical databases such as RDS, is exclusive to serverless resources configured **within** the VPC, ensuring a controlled and secure networking environment.

## Related pages

- [AESA network architecture docs](https://aws-samples.github.io/aws-secure-environment-accelerator/latest/architectures/sensitive/network/)
- [GWLB architecture](https://aws-samples.github.io/aws-secure-environment-accelerator/latest/architectures/sensitive/images/perimeter-NFW-GWLB.png)

Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ The following sections describe the requirements for building your application o

## Limitations of the AWS Landing Zone

Take the following into consideration when building your application on the AWS Landing zone:
Take the following into consideration when building your application on the AWS Landing zone:

* There is no direct (private) connectivity to the B.C. government network. Any application requiring access to data on this network must use a public endpoint

Expand All @@ -28,27 +28,27 @@ Take the following into consideration when building your application on the AWS

* IAM Users and their access keys can only be generated by the [IAM User management service](../design-build-and-deploy-an-application/iam-user-service.md), which is created and managed by the Public Cloud team


## Other requirements and best practices

To use GitHub Actions for deploying your application, [OpenID Connect (OIDC) authentication](../design-build-and-deploy-an-application/deploy-an-app-to-the-aws-landing-zone.md#configuring-github-action-oidc-authentication-to-aws) is required.
To use GitHub Actions for deploying your application, [OpenID Connect (OIDC) authentication](../design-build-and-deploy-an-application/deploy-an-app-to-the-aws-landing-zone.md#configuring-github-action-oidc-authentication-to-aws) is required.

To deploy your application:
To deploy your application:

* Use a CI/CD pipeline
* Use infrastructure as code, such as Terraform
* Set up a monitoring solution for your application
* Through the [Product Registry](https://registry.developer.gov.bc.ca/login) configure budgets to receive notifications when your quota is close to being exceeded
* Through the [Product Registry](https://registry.developer.gov.bc.ca/login) configure budgets to receive notifications when your quota is close to being exceeded
* Only grant access to your AWS accounts for those who actually need it

## Local deployment
To facilitate local deployments into AWS, from your machine. The process involves using Terraform as an Infrastructure as Code (IaC) tool, AWS CLI and Visual Studio Code (VSCode) as an Integrated Development Environment (IDE).

To facilitate local deployments into AWS, from your machine. The process involves using Terraform as an Infrastructure as Code (IaC) tool, AWS CLI and Visual Studio Code (VSCode) as an Integrated Development Environment (IDE).

* Install Terraform by following the [official Terraform guide](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli),
* Understand and install [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
* Set up [Visual Studio Code](https://code.visualstudio.com/docs/setup/setup-overview)

After all the tools have been installed, you can provision S3 bucket in AWS using Terraform:
After all the tools have been installed, you can provision S3 bucket in AWS using Terraform:

Save this code in a file with a ".tf" extension, for example, main.tf.

Expand Down Expand Up @@ -76,43 +76,47 @@ To apply this configuration, follow these steps:

Ensure you have AWS credentials, obtainable by visiting the AWS login page and clicking on the `Click for Credentials` button for the desired authorization role as shown in the image below. ![aws-credential-cli](../images/requirements-for-building-your-application/aws-credential-cli.png)

2. Copy the credential
2. Copy the credential

![aws-credential-cli](../images/requirements-for-building-your-application/click-credential.png)

3. Paste the copied credential

![aws-credential-cli](../images/requirements-for-building-your-application/terminal.png)


4. Initialize your Terraform configuration:

```
terraform init
```

5. Create an execution plan:

```
terraform plan
```

6. Apply the changes to create the S3 bucket:

```
terraform apply
```

7. Confirm by typing yes when prompted.

This script creates an S3 bucket with the specified configuration. Adjust parameters as needed for your specific use case.

For deploying to AWS using Terraform, [find this comprehensive tutorial](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/aws-build ).
For deploying to AWS using Terraform, [find this comprehensive tutorial](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/aws-build ).
This combined approach of Terraform AWS CLI and VSCode streamlines the deployment process, promoting ease of use and efficiency in AWS infrastructure management.

## Next steps

- [Deploy an application to the B.C. Government AWS Landing Zone](../design-build-and-deploy-an-application/deploy-an-app-to-the-aws-landing-zone.md)
* [Deploy an application to the B.C. Government AWS Landing Zone](../design-build-and-deploy-an-application/deploy-an-app-to-the-aws-landing-zone.md)

## Related pages

- [Provision a project set](get-started/provision-a-project-set.md)
- [Account access](get-started/provision-a-project-set.md#account-access)
- [Configuring GitHub Action OIDC Authentication to AWS](../design-build-and-deploy-an-application/deploy-an-app-to-the-aws-landing-zone.md#configuring-github-action-oidc-authentication-to-aws)
- [Deploy an application to the B.C. Government AWS Landing Zone](../design-build-and-deploy-an-application/deploy-an-app-to-the-aws-landing-zone.md)
* [Provision a project set](get-started/provision-a-project-set.md)
* [Account access](get-started/provision-a-project-set.md#account-access)
* [Configuring GitHub Action OIDC Authentication to AWS](../design-build-and-deploy-an-application/deploy-an-app-to-the-aws-landing-zone.md#configuring-github-action-oidc-authentication-to-aws)
* [Deploy an application to the B.C. Government AWS Landing Zone](../design-build-and-deploy-an-application/deploy-an-app-to-the-aws-landing-zone.md)
10 changes: 10 additions & 0 deletions docs/aws/design-build-and-deploy-an-application/sample-apps.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
# AWS Sample applications

Last updated: **October 16, 2024**

We have several example applications to help you get started with building and deploying applications in the AWS Landing Zone.

* Container-based application: [AWS Startup Sample Application (Containers)](https://github.com/bcgov/startup-sample-project-aws-containers)
* Serverless-based application: [AWS Startup Sample Application (Serverless)](https://github.com/bcgov/startup-sample-project-aws-serverless-TFC)

For additional guidance on application architecture, please refer to the [AWS Architecture Center](https://aws.amazon.com/architecture/).
Loading

0 comments on commit 1910f78

Please sign in to comment.