dokucama

You've loaded an old revision of the document! If you save it, you will create a new version with this data.

AWS CLI:\\
[[https://blog.ipspace.net/2021/02/vpc-subnets-aws-azure-gcp.html]]
\\
Note we will use the cli account for Terraform as well (more below).

* This is to setup cli access (no mfa): [[https://cloudacademy.com/blog/how-to-use-aws-cli/|External Link]]

aws configure --profile jaimecli

* Now we add the mfa to the cli access [[https://www.redpill-linpro.com/techblog/2020/02/18/awscli.html|External Link]]
    * Go to IAM and be sure the cli user has an virtual mfa device created
    * Collect from IAM these IDs: 
      * arn:aws:iam::XXXX:mfa
      * arn:aws:iam::XXXX:user/myuser

* With that, we can configure the credentials and config file as per above link

./refresh_mfa.py jaimecli    # to refresh the token with my mfa (it'll be a new entry in ~/.aws/config)
  aws --profile jaimecli sts get-caller-identity    # to test all is good. Do not forget the profile

Refreshing workaround for error "...The security token included in the request is expired": **disruptive**
  mv .aws/credentials credentials.bak2
  aws configure
  ./refresh_aws_mfa.py jaimecli

SIMPLER SETUP. remove credentials when done and set them up again when start working:
  # or just keep credentials but gran/revoke 'AdministratorAccess' policy during works : 
  # https://us-east-1.console.aws.amazon.com/iamv2/home?region=us-east-1#/groups/details/gr2?section=permissions
  rm /home/pi/.aws/credentials*
  aws configure 
  aws sts get-caller-identity
  ! when logging off
  rm /home/pi/.aws/credentials*

----

aws ec2 describe-vpcs | jq .[]
  aws ec2 describe-subnets
  aws ec2 describe-internet-gateways
  aws ec2 describe-network-acls --query NetworkAcls[1]   # this is just to output the 2nd acl
  aws ec2 describe-instances --region us-east-1 | jq -r .Reservations[].Instances[].PublicIpAddress  # lists all addresses: public and elastic
  aws ec2 describe-regions --output text
\\
  aws ec2 describe-regions  | jq -r "[[.Regions[].Endpoint[]]"     # to parse json output

Find all instances in all regions:
  for region in `aws ec2 describe-regions --profile jaime-personal --output text | cut -f3`
  do
       echo -e "\nListing Instances in region:'$region'..."
       aws ec2 describe-instances --profile jaime-personal --region $region
  done

Find all IPs (elastic and public) for instances in all regions. Or this other **WAY: [[https://panda314159.duckdns.org/doku.php?id=virtualization:cloud:aws:publicips|External Link]] **
  for region in `aws ec2 describe-regions --output text | cut -f3`
  do
       aws ec2 describe-instances --region $region | jq -r .Reservations[].Instances[].PublicIpAddress  
  done

Find all IPs (elastic and public) for LB in all regions:

# ALB LOAD BALANCERS
  for region in `aws ec2 describe-regions --output text | cut -f3`
  do
       aws elbv2 describe-load-balancers --region $region | jq -r .LoadBalancers[].DNSName
  done

# ELB LOAD BALANCERS
  for region in `aws ec2 describe-regions --output text | cut -f3`
  do
       aws elb describe-load-balancers --region $region | jq -r .LoadBalancerDescriptions[].DNSName
  done

----
AWS TERRAFORM
\\
[[https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli|Install]] Terraform ; [[https://developer.hashicorp.com/vault/tutorials/getting-started/getting-started-install|Vault]]

* [[https://spacelift.io/blog/importing-exisiting-infrastructure-into-terraform|Import]] existing infrastructure to start playing with
  * AWS Global Networking in Terraform: [[https://github.com/arpcefxl/aws-networking-terraform|github-resources]] + {{ :virtualization:cloud:awsglobalnetworkinginterraformlatest1680549344295.pdf |}}

----

** AS14618 ; ASN15509 **
\\
For a full current amazon IPs, see [[https://ip-ranges.amazonaws.com/ip-ranges.json|THIS]]

* **VPC**: Analogy with a distribution layer (one for qa, one for prod, one for eat...) A virtual private cloud (VPC) is a virtual network dedicated to your AWS account. Components [[http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Networking.html|External Link]] & some definitions (from [[https://aws.amazon.com/vpc/faqs]] )
  * ** Public IP (ephemeral** , with public=true in the api call): They change when the instance reboots.
  * ** ELASTIC IP ~= PUBLIC-PERMANENT**:  Is a reserved public IP associated with the User Account. It exists until it is explicitly removed, and remains associated with the account even while it is associated with no instance. Is not free. 
  * **Elastic network interfaces (ENI)**: Can moved between ec2 and takes the **mac address with it**.
  * VPC Endpoints [vpce] : 'gateways' to aws services (mainly S3 and DynamoDB). Access to AWS services is done normally via public IPs (not really going out to internet). With vpc endpoint, we can do it via internal IPs. See [[https://medium.com/awesome-cloud/aws-vpc-endpoints-overview-intro-getting-started-guide-91ca23b5af8d|External_Link]] 
    * There is one vpce per vpc and per service
    * rtb are required with one end on the vpce and the other in the vpc
  * SUBNETS: Public private or hybrid (egress only) subnet is an category we give, depending on how traffic is routed. Is not an AWS concept.
    * A subnet can only live in one AZ. Nornmally for high availability we have three tier-subnets in each VPC
    * Do not confuse the concept of subnets with routes. A route has a next hop (target)
  * **SECURITY GROUP**: Defined on an Instance Basis they work up to layer 4. Ideally used to east to west traffic and sometimes for north-south (but we can use 3rd party instances like fw. We can define one by one but not really scalable. Better approach is to define it for multiple instances, Virtual firewall that controls the traffic for one or more instances. VPC router enables Amazon EC2 instances within subnets to communicate with Amazon EC2 instances in other subnets within the same VPC.
  * ACL [acl]: Stateless and defined on a VPC level
  * NAT GATEWAY [ngw] : Associated to a subnet. NAT is used to allow traffic outbound and __**prevent traffic inbound**__.
    * It requires an elastic IP attached to it.
    * One option is: igw-1 --subnet1( ngw-1 rtb-1[0/0-igw-1] ) -- subnet2( rtb-2[0/0-ngw-1]
  * INTERNET GATEWAY [igw]:
    * ipv4: 
      * Inbound is permitted (providing sec. group and acl allow) but normally enabled by adding a load balancer)
      * Outbound (with a nat gateway)
    * ipv6: For ipv6 we use egress-only internet gateway [eigw]
  * ROUTE TABLES [rtb]: they have 'destination' (the subnet for what we want the route) and 'target' (which can be equated to the 'gateway'
    * A rtb lives in a subnet or subnets (associated)
    * An example, rtb for a vpc endpoint: destination: pl-7ba54012(com.amazonaws.us-est-2.s3) (this represents the subnet of the service) + target: vpce-aa852c
      * vrf ~= multiple rts/subnets. Which is not 💯 true because different subnets/rts can talk to each other by default

There's really one route table attached to each interface and all goes through gre tunnels. Nonetheless, logically there are multiple rts.\\
All rts are egress except the IG.\\
Ingress table only happens on the IG. It is **specially named rt called 'gateway-rt'**

\\
From the IG to the VPC (in case dst is not the vm, ie: firewall in the dmz or similar):
  * EGRESS: RT pointing to the fw-nic, the fw to igw.
  * INGRESS (return traffic!):
    * Easy but no nice solution is to have natted outbound in the firewall (to an private IP then natted again in the igw towards the world).
    * Best solution (So we can keep the vms source IPs) is to make use of the IG INGRESS ROUTE TABLE CALLED 'GATEWAY-ROUTE-TABLE). That versatile table allows inbound packet forwarding to be directed to the fw nic
{{:virtualization:cloud:ingress-rt_gatewat_rt-vpc-ingress.jpeg?200|}}

Another use case for the gateway-rt is the network-firewall:\\
The trick here is for the traffic coming from internet, the gateway-rt routes traffic destined to the vpc prefix to the firewall nic instead (see picture)

{{:virtualization:cloud:ingress-rt_gatewat_rt-network-firewall.jpeg?200|}}

Egress Only IG (eigw) is needed for IPv6 because they get the public ipv6 straight in the ec2 interfaces, therefore there is not natgw. eigw is the only way to have an outbound only internet connection.\\

* VPN: two options.
    * VIRTUAL PRIVATE GATEWAY **vgw**: The Amazon VPC side of a VPN connection. Scalable but only one per vpc. Note that a vgw can be used also as a termination for the direct connect 
    * EC2

* **TRANSIT GATEWAY [tgw]** : Similar to transit vpc but more 'router-like'. For hub and spokes type deployments. 
    * VPCs, on-premise stuff and so on, all can connect to the tgw : In the transit gatewaym, we create VPC attachments, then in the VPC we can leave the deafult table (automatically created) or add custom routes with target [tgw]
    * If we want traffic between __different regions__ we can do it but peering together transit gateways.
    * Manages/abstracts all the vpn tunnels. [[https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/transit-gateway-vs-transit-vpc.html|External Link]]
    * You can create attachments from the tgw to subnets
  * VPC PEERING **pcx**: A peering connection enables you to route traffic via private IP addresses between two peered VPCs.
    * The VPCs can be in __different Regions__ (also known as an inter-Region VPC peering connection).
      * Traffic always stays on the global AWS backbone, and never traverses the public internet. You use the VPCs private ranges.
  * PRIVATE LINK: Differently from vpc peering because allows you __**to publish**__ an “endpoint” that others can connect with from their own VPC. A bit like service provider flavour.
    * Unidirectional, natted and optimized (ie supports more spoke VPCs)
    * Interface VPC Endpoints: **vpce-svc** An interface VPC endpoint (interface endpoint) enables you to connect to services powered by AWS PrivateLink
    * It can work inter-region on top of vpc peering. See [[https://dev.to/aws-builders/aws-privatelink-for-more-secure-and-cost-effective-inter-service-communication-38hh|Link]]
  * Transit vpc is a bit of a //hack//. not really an aws contruct but a solution we can build ourselves with a vpc. [[https://aws.amazon.com/blogs/aws/aws-solution-transit-vpc/|LINK]]
  * AWS service endpoints: To connect programmatically to an AWS service

----

**DIRECTCONNECT [dgw] ** [[https://docs.aws.amazon.com/directconnect/latest/UserGuide/WorkingWithVirtualInterfaces.html|External Link]]

* VIF
  * **DirectConnect Gateway**: We can think of it as a ROUTE REFLECTOR. Not in the forwarding plane. [[https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways-intro.html|External Link]]. It then connects to one the these two:
    * virtual private gateway [vpg] between itself and the vpcs ([vpg] are not just for ipsec)
    * [tgw]
  * Directconnect can be used with multiple regions single [dgw] connects to multiple [vpg] in different regions.
  *  Directconnect can be used with multiple accounts: [dgw] belongs to account Z, then accounts A and B send 'association requests' from their [vpg]]
  * Depending on what we want to access we can create the following interfaces (VIFs) in DirectConnect:
    * Private virtual interface
    * Public virtual interface
    * Transit virtual interface
  * BGP MP is not supported. MD5 is enabled by default.
    * Peering can/should be done from rfc1918. 
    * Shorter-prefix, Local-pref, AS-prepending, MED aand [[https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html|Communities]] can be used to influence traffic.

----

* Amazon CloudWatch: Used to obtain network usage statistics from your instances.
  * To connect to Internet: When you spin up an instance in the default VPC, then you do get a public IP, public DNS, IGW and route assigned. When you create your own VPC, you need to **create your own IGW and attach it to the VPC, add the IGW to a route table that you assign to each subnet, enable auto-assign public IP (or do that during instance launch), and enable DNS host names at the VPC level if you want a public Amazon provided dns name.**

----
**LoadBalancers ELB( ALB/NLB)**:\\
See [[https://blog.cloudcraft.co/alb-vs-nlb-which-aws-load-balancer-fits-your-needs/|External Link]]
  * ELB: Used to be called Classic (was the first)
  * ALB (Application): They use target groups (more like netscaler). The ALB comes with a lot of built-in features. See the comparison table at the end of the article.
  * NLB (Application): They use target groups (more like netscaler). The NLB comes with a few rough edges and requires more experience and care.

* **Target groups**: Used to route requests to one or more registered targets (your backed EC2 instances)
  * **Listeners**: Process that "TCP Listens" for requests from clients.
    * Important: listeners are NOT the backend servers. They are **INSTANCES-COPIES of the main elb** (place holder). Normally we need one listener per AZ.

* The lb gets a url per region of the type **elb.amazonaws.com**. That url (without route 53) has multiple A records corresponding to the multiple listeners.  
  * ELB: Inbound. One ELB per vip, so we will likely run several of them.
  * ALB (Application): above plus augmented feats.
    * ALB is an instance but under Aws control.sni. Aka reverse proxy: one connection to the alb, then it creates another to the backend and Then a third one from the customer to the backend! 1<-- ,2 <-- <--- , 3 <-----
)

----
TO FIND THE SECURITY GROUP SG FROM AN IP (normally that IP is from an ELB but this works the same for instances): 
  - section-EC2: go to network interfaces and search for that IP. You will get an eni interface, copy the description (an elb description, trim the elb bit)
  - section-EC2 go to load balancers and paste the descriptio. You will see the lb containing that IP. **scroll down and the SG is there ;-) **

----

**DNS**:\\
Options:
  * In vpc dns + can use DHCP options
  * 169.254.169.253 or prefix +2 
\\
__ROUTE 53__
  * They have their own kind of 'alias' records which are not cname. They map to things like ELB. It can hide the elb default URL (cname) and also help with multi region load balancing.\\
  * Geolocation fails quite a lot. GEOPROXIMITY [[hhttps://acloud.guru/forums/aws-certified-cloud-practitioner/discussion/-LREacg_SpSVK0YaoYts/Diff%20between%20geolocation%20and%20geoproximity%20routing%3F|External Link]] works better.
  * ALIAS is functionally equivalent to CNAME but with less requests to the DNS resolver 
    * Builds the whole set of lookup trees for the same fqdn. So route53 selects the best one.this works only for a and aaaa records 
  * HEALTH CHECKS:
    * r53 pings and endpoint (simple healthcheck)
    * also more complex hcks, like verifying a set of servers
    * cloudwatch alarms
      * number of queries, which hcks are passing/failing
  * Possible limitations: 
    * Not easy to do blackholing
    * Not easy to detect if dns requests are tunneled
    * How they implement security records like:
      * CNAME (for mail redirection (mx is not mandatory) , DKIM (emcryption between mail exchanges with TXT record), SPF (Sender Policy Framework, policies, via TXT, eg: "v=spf1 include:zoho.eu ~all" )

----

**AWS GATEWAY LOAD BALANCER  (ipspace) **\\
GWLB is used for NVAs (network virtual appliances) that can be provided by 3rd parties. 
Geneve tunnels between gwlb and the nvas\\
Review traffic flow ig has ingress table!\\
{{:virtualization:cloud:ingress-routing-in-ig.png?400|}}

----

**AWS FIREWALL (ipspace) **\\

Ingress tablet Only happens on the IG (that's why we need IG to redirect to the firewall rt (and when using natgw we have peculiar placement of natgw see ipspace:
\\
Flow: \\
  * instance > natgw-rt > firewall > IG
  * IG-ingress-table > firewall  > nat-gw-rt > instance

* ~ Managed gateway load balancer. Bump in the wire.
  * Two subnets needed App-RT and FW-RT for the filtered traffic towards internet (0/0)
  * For IG/NAT-GW. Tweaks for inter VPC firewall. Cannot filter intra-vpc traffic.
  * Suricata open source firewall. Layer 4.
  * IGW - FW - **NGW** - SRV
  * The FW needs to be attached to each of the AZs
  * FIREWALL POLICY (just a set of policies). Stateless and stateful rules.
    * rule groups
    * inspection vpc << to achieve inter vpc firewalling.

----

LAN TO AWS VPN TUNNEL:\\
[[https://onan-labs.com/2015/10/27/26/|Meraki to AWS VPN]]\\
Always two tunnels to the vgw. If need very high speec (up to 25G), use a EC2-based-vpn (vendor specific).

----

* AMI: Amazon Image type (ie: amazon type of linux. There are a pletora of them.
  * IAM: identity and access management [[https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html|External Link]] (same name in oci)
\\

Cisco Intercloud extender: from private cloud (OVA) format to AWS (AMI format)

----
**CFT** (Cloud Formation Templates)
Allow to create a whole environment on demand. Consider that we pay for what we use in aws, therefore whatever infrastructure not in used shouldn't be deployed empty.\\
There are just txt templates that can be invoked via API (by the own dev team and/or the application)·

----
AWS LIMITS:\\
  * number of rules per security group: 250
  * VPCs per region: 5
  * CIDR blocks per VPC 	5
More info  [[https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/amazon-vpc-limits.html|here]]
\\

----
MONITORING:\\
  * Cloud watch
  * VPC mirroring:
    *  Is rspan with VXLAN udp-4789 as transport. Target doesn't need to filter vxlan but we need to consider the 60B added by vxlan so we don't get over the mtu.
    * In reality the nitro nic (hypervisor's smart nic) does acl does sg does rspan and cloudwatch metrics(review this))

----
Aws global accelerator:
for those applications that cannot spell dns. \\
Traffic hits an Anycast address and then goes through Aws internal network.\\ 
Aws internal network uses public space.\\
Your endpoint needs to have public IP, eg alb or nlb

----

For my tests:\\
Instance types: Instance Type (tX X is the number, edition):
Price: T3a instances offer an additional 10% cost savings over T3 instances. T3 instances are 10% cheaper than the older T2 instances and offer up to a 30% better price to performance ratio. \\

* amzn2-ami-hvm-2.0.20190823.1-x86_64-gp2 - ami-0b69ea66ff7391e80
  * t3a.nano
  * NAT gateway is pricy. For outbound internet access, is much cheper to use a ''gateway endpoint'' just for being on. ~60$ month
    * Gateway VPC endpoints provide reliable connectivity to Amazon S3 and DynamoDB without requiring an internet gateway or a NAT
  * EC2 instances in 'stopped' state they do generate charges!

To control **charges**:
  * CloudWatch billing alerts and alarms, budgets, and CloudTrail. For more information on these services and their features, please review the documentation links below:
  * [[https://aws.amazon.com/cloudtrail/getting-started/]]
  * [[http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch.html]]
  * [[http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html]]

----

STORAGE:
  * Block Storage (EBS)
  * File storage (EFS)
  * Object storage (S3)

----
SECURITY FOR PROGRAMATIC ACCESS:
\\
{{ :virtualization:cloud:aws_security.pdf |}} slides by from Michael J. Shannon (oreilly presentation aws security crash course)_
  * Have a look at **aws secret manager**
  * IAM manage policies
    * they are basically json files. 
    * **Policies attach to >> >GROUP< gets users << attached**
    * Three main kind of categories for policies: Administrator
      * all access: ''AdministratorAccess''
  * role: is like an 'impersonation', like a mask!. IAM entity permissions can be Assumed by another entity

----
**REGIONS AND AVAILABILITY ZONES**
  * TODO
  * Subnets and high avaiability HA [[https://blog.ipspace.net/2021/02/vpc-subnets-aws-azure-gcp.htmlExternal-Link]]

----
**AWS EDGE LOCATIONS**
  * CloudFront, Route 53, WAF
  * Entry points for aws cloud. Not strictly in the aws cloud.
  * Between the edge location and the outside world, there's a local caching data center.

----
AUTOESCALE CLOUD INFRASTRUCTURE:
AWS autoescaling features only deal with EKS (workers) or EC2 instances. If we want to dynamically allocate other resources like, subnets, directconnects, vpc peerings ans so on, we can use:
  * [[https://networktocode.com/nautobot/nautobot-cloud/]]

----
Amazon VPC Flow Logs - TODO

Edit summary

Note: By editing this page you agree to license your content under the following license: CC Attribution-Share Alike 4.0 International

dokucama

User Tools

Site Tools

Page Tools